追问会话

启动步骤

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

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 格式

结构

md
# {上下文名称}

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

## 语言

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

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

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

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

规则

• 有主张。 当多个词指代同一概念时，选最好的那个，其余列入 _避免使用_。
• 定义简洁。 最多两句话。定义它是什么，而非它做什么。
• 只收录项目上下文专属术语。 通用编程概念不属于这里。
• 出现自然聚类时分组。 若所有术语属于同一领域，平铺即可。

单上下文 vs 多上下文

单上下文（多数仓库）： 根目录一个 CONTEXT.md。

多上下文： 根目录 CONTEXT-MAP.md 列出所有上下文及其关系：

md
# 上下文地图

## 上下文

- [Ordering](./src/ordering/CONTEXT.md) — 接收和追踪客户订单
- [Billing](./src/billing/CONTEXT.md) — 生成发票和处理付款
- [Fulfillment](./src/fulfillment/CONTEXT.md) — 管理仓库拣货和发运

## 关系

- **Ordering → Fulfillment**: Ordering 发出 `OrderPlaced` 事件；Fulfillment 消费它以启动拣货
- **Fulfillment → Billing**: Fulfillment 发出 `ShipmentDispatched` 事件；Billing 消费它以生成发票
- **Ordering ↔ Billing**: 共享 `CustomerId` 和 `Money` 类型

推断当前结构：

• 若 CONTEXT-MAP.md 存在，读取它来定位上下文
• 若只有根目录 CONTEXT.md，则为单上下文
• 若都不存在，在第一个术语确定时懒创建根目录 CONTEXT.md

多上下文时，推断当前话题关联哪个上下文。不确定时，问。

参考：ADR 格式

ADR 存放在 docs/adr/，使用顺序编号：0001-slug.md、0002-slug.md……

懒创建 docs/adr/ 目录——只在第一个 ADR 需要时创建。

模板

md
# {决策的简短标题}

{1-3 句话：背景是什么，我们决定了什么，为什么。}

一个 ADR 可以只有一段话。价值在于记录做了什么决策以及为什么——而非填满各个章节。

可选章节

仅在确有价值时才加。大多数 ADR 不需要。

• Status（proposed | accepted | deprecated | superseded by ADR-NNNN）— 决策被重新审视时有用
• 备选方案 — 仅当被否决的替代方案值得记住时
• 后果 — 仅当存在不显而易见的下游影响时

编号

扫描 docs/adr/ 找到当前最大编号，加一。

什么适合做 ADR

• 架构形态。 "我们使用 monorepo。" "写模型使用事件溯源。"
• 上下文间的集成模式。 "Ordering 和 Billing 通过领域事件通信。"
• 有锁定效应的技术选型。 数据库、消息总线、认证提供商、部署目标。
• 边界与范围决策。 "Customer 数据由 Customer 上下文拥有；其他上下文只通过 ID 引用。"
• 对显而易见路径的刻意偏离。 让未来读者不会误以为是 bug 而"修复"它。
• 代码中不可见的约束。 "因合规要求不能使用 AWS。"
• 被否决方案的理由不明显时。 防止六个月后有人重新提出同样建议。