追问会话

启动步骤

触发后，先执行以下检查：

1. 检查项目根目录是否已有 CONTEXT.md 或 CONTEXT-MAP.md，有则读取
2. 检查 docs/adr/ 是否已有 ADR 记录，有则了解已有决策
3. 然后开始追问

核心规则

针对方案的每一个方面进行不留死角的追问，直到我们达成共识。沿着设计决策树逐一走下去，逐条解决决策之间的依赖关系。每个问题给出你的推荐答案。

一次只问一个问题，等我回复后再继续下一个。一次抛出多个问题会让人无所适从。

如果某个事实可以通过探索代码库获得，就直接查找，不要问我。但决策权在我, , 每个决策都提给我，等我回答。

在我明确确认达成共识之前，不要开始执行方案。

---

领域建模（内置流程）

追问过程中，一旦有决策结晶，就立即建立和完善项目的领域模型, , 挑战术语、构造边界场景、在第一时间写下术语表和决策记录。

文件结构

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

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

如果根目录存在 CONTEXT-MAP.md，则表示仓库有多个上下文，地图指向各自位置：

/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← 系统级决策
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← 上下文专属决策
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/

懒创建, , 只在有内容可写时才创建文件。如果 CONTEXT.md 不存在，在第一个术语确定时创建它。如果 docs/adr/ 不存在，在第一个 ADR 需要时创建它。

追问过程中的行为

对照术语表质疑

当用户使用的术语与 CONTEXT.md 中已有定义冲突时，立即指出："你的术语表把'取消'定义为 X，但你现在似乎是指 Y, , 到底是哪个？"

磨尖模糊表达

当用户使用含糊或多义的词汇时，提出精确的规范术语："你说的'账户', , 是指 Customer 还是 User？这是两个不同概念。"

讨论具体场景

讨论领域关系时，用具体场景压力测试。构造探索边界条件的场景，迫使用户精确界定概念之间的边界。

与代码交叉验证

当用户陈述某物如何运作时，检查代码是否一致。如果发现矛盾，立即暴露："你的代码取消的是整个 Order，但你刚说可以部分取消, , 哪个是对的？"

即时更新 CONTEXT.md

术语一旦敲定，立即更新 CONTEXT.md，不要攒着批量处理。格式参见下方「CONTEXT.md 格式」章节。

CONTEXT.md 必须完全不含实现细节。不要把它当规格文档、草稿本或实现决策仓库。它只是术语表。

审慎提供 ADR

仅当以下三条全部成立时才创建 ADR：

1. 难以逆转, 将来改变主意的代价可观
2. 缺乏上下文则令人费解, 未来读者会困惑"为什么这样做？"
3. 确实是权衡的结果, 存在真正的替代方案，且你基于具体理由选了其一

---

参考：CONTEXT.md 格式

结构

# {上下文名称}

{一两句话描述这个上下文是什么、为什么存在。}

## 语言

**订单（Order）**:
{一两句话定义该术语}
_避免使用_: Purchase, transaction

**发票（Invoice）**:
向客户发送的交付后付款请求。
_避免使用_: Bill, payment request

**客户（Customer）**:
下订单的个人或组织。
_避免使用_: Client, buyer, account

注：示例语言应跟随项目主语言。中文项目用中文术语，英文项目用英文术语。

规则