开发定制业务应用且领域知识需跨会话积累时，用 PDC…

在业务应用开发中，让 AI 通过 .tasks/domain.md 跨会话积累并复用内部术语、实体、关系和业务规则。

适用场景

解决思路

1. 在项目根目录查找 .tasks/domain.md。
2. 如果找到且为单文件（约 200 行以下）：在做任何工作前完整读取。
3. 如果找到且为索引 + 详情文件拆分结构：先读取根 .tasks/domain.md（Tier 1 核心上下文），再判断当前任务相关的 Tier 2 详情文件，只加载相关文件（见渐进披露）。
4. 如果未找到：提出使用 .tasks/domain.md 模板初始化一个。
5. 向用户确认：“我已加载 [Project Name] 的领域上下文。我熟悉 [N] 个实体和 [N] 个流程。”若为拆分模式，还说明：“我已加载核心上下文，会按当前工作按需拉入详情文件。”
6. 工作中使用 .tasks/domain.md 中定义的实体名、术语和缩写，保持完全一致。
7. 遇到未定义术语或实体时，就地标记 [UNKNOWN: <term>]。
8. 当实体之间关系不清楚时，标记 [RELATIONSHIP UNCLEAR: <entity-a> → <entity-b>]。
9. 当业务规则似乎隐含但未记录时，标记 [RULE INFERRED: <description>]。
10. 不要编造领域事实；只使用已记录或用户在会话中确认的内容。
11. 处理特定实体或流程时，如果其 Tier 2 详情文件存在且尚未加载，则加载它。
12. 会话结束时，始终在最终回复底部生成 ## 📋 Proposed Domain Updates 部分。
13. Proposed Domain Updates 中包含引用行：> 审查以下内容，并将确认的条目复制到你的 .tasks/domain.md。
14. 在 Proposed Domain Updates 中列出 ### New Entities Discovered（发现的新实体），每项含 **[EntityName]**: [Definition as understood from this session]，并列出 - Attributes: [list]、- Related to: [other entities]。
15. 列出 ### Terminology Clarified（术语澄清），格式 - `[term]` → [plain definition]。
16. 列出 ### Relationships Identified（识别出的关系），格式 - [Entity A] → [verb] → [Entity B]: [description]。
17. 列出 ### Business Rules Observed（观察到的业务规则），格式 - [Rule description]。
18. 列出 ### Open Questions（开放问题），格式 - [ ] [Question about something ambiguous or unresolved]。
19. 列出 ### Suggested .tasks/domain.md Sections to Add/Update（建议新增/更新的 .tasks/domain.md 章节），格式 - [ ] [specific section or entry to update]。
20. 所有更新只提出，不自动应用；由人工审查、编辑并手动更新 .tasks/domain.md，保持人是领域权威。
21. 采用渐进披露：领域文件增长后，Tier 1 核心始终加载；Tier 2 工作上下文按需加载；Tier 3 归档仅显式请求或回顾项目历史时加载。
22. Tier 1 核心放在根 .tasks/domain.md，始终在会话开始加载，典型 80–120 行，包含：## Project Overview（5 行说明是什么、谁用、业务目标）、## Domain Boundaries（范围内、支持性、明确排除，防止过度构建）、## Terminology Glossary（简写表）、## Entity Registry（仅实体名和一行描述，是实体的目录）、## State Models（命名枚举和合法状态转换，AI 必须将其视为唯一有效值）、## Business Rules（硬规则表，如 BR-001，AI 必须始终知道的 ground truth）、## User Roles（角色表）、## Stakeholder Map（具名人员、与系统关系、关键关注点、何时介入）、## Open Questions（当前未解决项）、## Detail Files（Tier 2 文件索引及一行摘要）。
23. Tier 2 工作上下文放在独立文件，按任务加载：完整实体规格（属性、生命周期、关系、说明、边界情况，每个主要实体一个文件）、完整流程描述（逐步过程走查，每个流程一个文件）、关系图（完整实体到实体表）、集成点（外部系统细节）。
24. Tier 3 归档放在独立文件，按请求加载：Changelog（逐会话学习历史）、Resolved questions（已关闭开放问题的历史记录）、Data migration notes（供应商目录细节、导入过程）、Vendor-specific details（价目表结构、门户访问说明）。
25. 当 .tasks/domain.md 超过约 200 行时，主动提议拆分。
26. 拆分提议话术：「The domain file is getting substantial — [N] lines with [N] entities and [N] flows. Want me to split it into an index file with detail files? This keeps sessions focused on what's relevant without losing anything.」
27. 如果用户同意，重构为分层文件布局（见拆分文件模式）；如果用户偏好单文件，尊重其偏好，这不是硬性要求。
28. 会话开始时按以下流程使用分层：1) 读取根 .tasks/domain.md（Tier 1，始终）；2) 理解当前任务；3) 判断哪些实体/流程相关；4) 只加载这些 Tier 2 文件；5) 工作，若任务扩展再加载额外 Tier 2 文件；6) 提出更新，注明每个更新属于哪个文件。
29. 示例：用户说「I need to update the PM renewal flow.」时，AI：读取根 .tasks/domain.md；加载 docs/domain/flows/pm-renewal.md；加载 docs/domain/entities/pm-renewal.md；不加载 docs/domain/flows/lead-distribution.md 或 docs/domain/entities/customer.md，因为它们与当前任务无关。
30. 拆分模式下提出更新时，## 📋 Proposed Domain Updates 要指定每个更新属于哪个文件：### Update: `.tasks/domain.md` (Tier 1 — core)；### Update: `docs/domain/entities/pm-renewal.md` (Tier 2)；### New File: `docs/domain/flows/engineering-review.md` (Tier 2)；### Update: `docs/domain/archive/changelog.md` (Tier 3)。
31. 在 .tasks/domain.md frontmatter 中维护版本头，格式 MAJOR.MINOR。
32. 版本规则：MAJOR 在根本范围变化（新业务流程、主要实体重构、领域边界变化）时递增；MINOR 在每次批准更新（新实体、新规则、流程调整、干系人新增）时递增。
33. 谁递增：系统在每次批准更新时自动递增 MINOR；团队决定领域根本扩展时手动递增 MAJOR。
34. 版本头示例放在 .tasks/domain.md frontmatter：> **Version:** 1.5、> **Last updated:** 2026-04-06 (Session 30)、> **Changes:** +Commission Report entity, +BR-013–015, updated Quote-to-Close flow。
35. 每次批准更新后，AI 必须：1) 递增版本号（MINOR +1）；2) 更新 Last updated 日期和会话引用；3) 用简短摘要更新 Changes 行；4) 在 Changelog 部分追加条目。
36. 如果系统使用 git，提交信息应镜像 Changes 行；版本头供 AI 和业务用户看，git 历史供工程看。
37. 单文件模式（约 200 行以下）使用这些顶层部分：## Project Overview（Tier 1）、## Domain Boundaries（Tier 1）、## Terminology Glossary（Tier 1）、## Entity Registry（Tier 1 名称 / Tier 2 细节）、## State Models（Tier 1）、## Relationship Map（Tier 2）、## Flow Catalog（Tier 2）、## Business Rules（Tier 1）、## Integration Points（Tier 2）、## User Roles（Tier 1）、## Stakeholder Map（Tier 1）、## Open Questions（Tier 1）、## Changelog（Tier 3）。在单文件模式中，所有层级在一个文件里；层级标签只是未来拆分的注释。
38. 拆分文件模式（超过约 200 行）使用布局：your-project/.tasks/domain.md 为 Tier 1 核心索引（始终加载）；docs/domain/entities/ 为 Tier 2，每个主要实体一个文件（如 quote.md、customer.md、product.md）；docs/domain/flows/ 为 Tier 2，每个业务流程一个文件（如 quote-to-close.md、pm-renewal.md）；docs/domain/relationships.md 为 Tier 2 完整关系图；docs/domain/integrations.md 为 Tier 2 外部系统细节；docs/domain/archive/ 为 Tier 3 历史记录（changelog.md、resolved-questions.md）。
39. 拆分模式下的根 .tasks/domain.md 完整包含 Tier 1 部分（Project Overview、Domain Boundaries、Glossary、Entity names table、State Models、Business Rules、User Roles、Stakeholder Map、Open Questions），并包含 ## Detail Files 索引，指向每个 Tier 2 文件及一行摘要。
40. ## Detail Files 索引示例表格列 File 和 Contents，包括如 docs/domain/entities/quote.md、docs/domain/entities/customer.md、docs/domain/flows/quote-to-close.md、docs/domain/flows/pm-renewal.md、docs/domain/relationships.md、docs/domain/integrations.md、docs/domain/archive/changelog.md 及各自内容摘要。
41. 如果不存在 .tasks/domain.md，初始化流程：1) 向用户询问 5 个种子问题（见 references/seed-questions.md）；2) 用答案填充模板；3) 写入草稿 .tasks/domain.md；4) 保存前提交审查。
42. 初始文件应远低于 200 行，先以单文件模式开始，增长后再拆分。
43. 持续增长循环：读取 .tasks/domain.md（拆分时加载相关 Tier 2 文件）→ 做工作（就地标记未知项）→ 提出更新（拆分时指定目标文件）→ 人工审查并批准 → 人工更新 .tasks/domain.md（或详情文件）→ 下一会话读取更新后的文件。
44. 增长生命周期：Session 1–3 单 .tasks/domain.md 约 60–80 行（仅 Tier 1）；Session 4–10 单文件约 100–200 行（Tier 1 + 2 混合）；Session 10+ 拆分为索引 + 详情文件（Tier 1 / 2 / 3 分离）；成熟项目采用完整三层结构并含 archive。
45. 当文件超过约 200 行时，主动提议拆分并说明话术：「The domain file is at [N] lines now — it covers [N] entities and [N] flows in detail. Want me to split it into a core index file with separate detail files? Each session would load just the parts relevant to what we're working on, and nothing is lost.」
46. 如果用户同意拆分，执行：1) 将 Tier 1 内容抽取到精简根 .tasks/domain.md（约 80–120 行）；2) 将每个实体的完整描述移到 docs/domain/entities/[name].md；3) 将每个流程的完整描述移到 docs/domain/flows/[name].md；4) 将关系图和集成点移到各自 Tier 2 文件；5) 将 changelog 移到 docs/domain/archive/changelog.md；6) 在根 .tasks/domain.md 添加 ## Detail Files 索引；7) 保存前提交新结构供审查。
47. 长期将 .tasks/domain.md 作为以下用途的唯一事实来源：新开发者 onboarding、未来 AI 会话（任意模型、任意工具）、文档与规格、测试用例 grounding。
48. 参考文件：.tasks/domain.md（初始化新领域文件的空白模板）、references/seed-questions.md（启动新领域时询问的问题）、references/entity-template.md（大型项目的单个实体文件模板）、references/anti-patterns.md（构建领域上下文时避免的常见错误）。

适用边界 · 注意事项

• 不适用于一次性脚本、通用库或无需跨会话积累业务领域知识的项目。
• 不适用于用户不允许 AI 读取/提议更新项目内知识文件，或不愿人工审核批准更新的场景。
• 不适用于希望 AI 自动写入领域知识库而非仅提出更新建议的场景。