pedro-oscar/shorts-ai

领域建模

在设计过程中，主动构建和精炼项目的领域模型。这是一项需要积极投入的实践：挑战术语、编造边界场景、并在术语和决策刚成形时立即记录下来。（仅仅阅读 GLOSSARY.md 来了解词汇并非该技能的范畴——那是任何技能都能完成的一行习惯。本技能适用于你在改变模型，而非仅仅消费它。）

文件结构

大多数仓库只有一个上下文：

/
├── GLOSSARY.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

如果根目录下存在 GLOSSARY-MAP.md，则仓库有多个上下文。该映射文件指向每个上下文所在的位置：

/
├── GLOSSARY-MAP.md
├── docs/
│   └── adr/                          ← 系统级决策
├── src/
│   ├── ordering/
│   │   ├── GLOSSARY.md
│   │   └── docs/adr/                 ← 上下文特定决策
│   └── billing/
│       ├── GLOSSARY.md
│       └── docs/adr/

懒创建文件：仅当你有内容要写时才创建。如果尚不存在 GLOSSARY.md，在第一个术语确定时创建它。如果尚不存在 docs/adr/，在需要第一个 ADR 时创建它。

在会话期间

对照术语表进行挑战

当用户使用的术语与 GLOSSARY.md 中已有的语言冲突时，立即指出。“你的术语表将‘取消’定义为 X，但你似乎指的是 Y。是哪一个？”

精炼模糊语言

当用户使用模糊或过载的术语时，提出一个精确的规范术语。“你提到‘账户’：你是指客户还是用户？它们是不同的东西。”

讨论具体场景

当讨论领域关系时，用具体场景进行压力测试。编造那些探测边界情况的场景，迫使用户精确区分概念之间的界限。

交叉引用代码

当用户描述某事物如何工作时，检查代码是否一致。如果发现矛盾，明确指出：“你的代码取消了整个订单，但你刚刚说可以部分取消。哪个是正确的？”

内联更新 GLOSSARY.md

当一个术语确定后，立即更新 GLOSSARY.md。不要批量处理：在它们发生时即时捕获。使用 GLOSSARY-FORMAT.md 中的格式。

GLOSSARY.md 应完全不含实现细节。不要将 GLOSSARY.md 视为规格说明、草稿纸或实现决策的存储库。它只是一个术语表，仅此而已。

谨慎提供 ADR

仅当以下三个条件同时满足时，才提议创建 ADR：

1. 难以逆转：改变主意代价高昂
2. 脱离上下文则令人费解：未来的读者会疑惑“他们为什么这么做？”
3. 真正的权衡结果：确实存在替代方案，且你基于特定原因选择了其中一种

如果三个条件中任何一个不满足，跳过 ADR。使用 ADR-FORMAT.md 中的格式。