requirement-convergence · diff
git:20260901.b347ae2 to git:20260923.86a3d79
19 added, 8 removed. Audit A to A.
---
name: requirement-convergence
description: 将变更必须产生的结果与为达成该结果而提出的需求区分开来，记录用户明确排除的内容，并根据结构对成本进行分级评估。当需求进入某个工作流时、设计开始之前，或提到“做到什么程度/范围外是什么/是否值得做”时使用。
---
# 需求收敛
## 目的
收到的需求往往过于臃肿、含糊不清，或指向错误的目标。能力足够的模型会将这三者调和为一个连贯的计划，并忠实地构建它——当被要求的内容本身就是错的时，也精确地交付被要求的内容。
本技能收敛的是**要构建什么**。如何构建，以及该变更需要哪些文档，都在“要构建什么”确定之后再解决。
## 收敛字段
| 字段 | 通过条件 |
|-------|----------------|
| `outcome` | 一个可观测的结果。不服务于该结果的需求即为多余。 |
| `requirements[]` | 每个与构建相关的项都标注为 `current-state` 或 `desired-future`。 |
| `nonGoals[]` | 由用户撰写，或用户声明没有范围外项。 |
| `cost` | 一个带有结构性依据支撑的分级，加上仍然存在的未知项。 |
`cost` 是一个粗略的分级，不是工作计划据以排期的工作量估算；需求无法支撑以人天为单位的估算。其未知项在决策权重上比其规模更重要。
- 将请求信号分类为评估性请求、设想性想法或指定的实现机制，并在当前收敛上下文中仅作为供判断参考的候选项保留。只有在用户明确确认之后，候选项才能进入 `requirements[]` 及长期保留的文档。
+ 依据所保留的用户原话进行分类，而不是依据分析器对原话的转述。要求评估的措辞、描述设想性想法的措辞，或建议某种机制的措辞，在当前收敛上下文中仅作为供判断参考的候选项保留。只有在用户明确确认之后，候选项才能进入 `requirements[]` 及长期保留的文档。
每个字段都带有各自的就绪标签：`ready`、`weak`，或 `weak-but-explicit`（弱，且用户同意暂不解决）。只有用户可以设置 `weak-but-explicit`。当所有适用字段都为 `ready` 或 `weak-but-explicit` 时，需求即视为已收敛。
各字段的判断规则见：[references/criteria.md](references/criteria.md)。
## 询问协议
使用现有的范围与成本依据来引出信息并做出判断，然后只就仓库无法回答的产品选择进行提问。仅当某个答案会改变分析目标或所需的范围依据时，才重新分析范围与成本。
在开始前登记以下步骤，并在每个步骤完成时记录其依据：
| 步骤 | 动作 | 完成依据 |
|------|--------|---------------------|
- | 1 | 陈述现有的范围事实，然后单独说明这些事实对需求意味着什么 | 列出事实及其分析依据 |
- | 2 | 就低于 `ready` 的字段提问，每条消息最多两个问题 | 每个低于 `ready` 的字段一个问题 |
- | 3 | 将每个答案记录为该字段的值 | 该值为用户选择的选项，或用户提供的措辞 |
- | 4 | 当已记录的值仍未通过其通过条件时，重新询问一次；若用户同意将第二次回答维持原状，则将该字段标记为 `weak-but-explicit` | 两次已记录的答案，或用户同意停止 |
- | 5 | 依据每个字段的通过条件进行判断，并完成该记录 | 一份每个字段都已标注的收敛记录 |
+ | 1 | 按下方格式呈现范围确认，只就低于 `ready` 的字段提问 | 每条事实都注明其来自哪份分析输出，且**待用户决定事项**中每个低于 `ready` 的字段各有一个问题 |
+ | 2 | 将每个答案记录为该字段的值 | 该值是用户明确选定的选项，或用户自己提供的措辞 |
+ | 3 | 当已记录的值仍未通过其通过条件时，重新询问一次；若用户同意将第二次回答维持原状，则将该字段标记为 `weak-but-explicit` | 两次已记录的答案，或用户同意停止 |
+ | 4 | 依据每个字段的通过条件进行判断，并完成该记录 | 一份每个字段都已标注的收敛记录 |
+ ## 范围确认
+
+ 在每个需求确认停止点都按此格式呈现，无论是否进行了询问；只纳入可能改变用户需求决定的内容。
+
+ | 部分 | 内容 |
+ |------|------|
+ | **已确认范围** | 用户已经陈述或明确选定的需求和排除项，使用用户自己的措辞或所选的选项 |
+ | **判断依据** | 每个实质性条目都标明是观察所得、推断还是提议，并附上其来源以及它可能对范围、成果或成本带来的改变，其中包括成本分级及其仍然存在的未知项 |
+ | **待用户决定事项** | 每个尚未解决的产品、UX 或运营问题，以及其实质上不同的答案分别对范围、成果或成本产生的影响 |
+
+ 将这几部分分开呈现，用户才能分辨哪些是自己已定下的边界、哪些是仓库观察结果、哪些仍是待决的问题。只有用户的明确答复或选择才能将某项移入**已确认范围**。调用方工作流自己的路由事项（如结构规模）放在这几部分之外，且只在会呈现它们的停止点呈现。
+
## 存储协议
| 载体 | 承载内容 |
|---------|-------|
| 当前收敛记录 | 每个字段及其就绪标签 |
| PRD 的 `成功标准` 和 `范围外` | `outcome`；用户撰写的 `nonGoals` |
| 设计文档的 `需求收敛` | 在没有 PRD 时承载同样内容，且在任何情况下都承载被标为 `weak-but-explicit` 的字段 |
不产生上述任一文档时，将记录保留在当前上下文中。
## 引用协议
1. 从提示词中读取收敛记录。
- 2. 将 `nonGoals` 视为当前变更排除在外的内容，将 `desired-future` 需求视为可构建的范围。未被采纳的评估性请求、设想性想法和指定的实现机制不产生任何实现义务；已被采纳的 ADR 可以将已评估过的选项保留作为决策历史。
+ 2. 将 `nonGoals` 视为当前变更排除在外的内容，将 `desired-future` 需求视为可构建的范围。未被采纳的评估性请求、设想性想法、指定的实现机制以及由智能体提出的能力不产生任何实现义务；已被采纳的 ADR 可以将已评估过的选项保留作为决策历史。
3. 将 `weak-but-explicit` 的字段视为已记录的悬而未决的问题，而非已敲定的决策，当工作依赖于该问题的解决时应上报处理。
## 质量检查清单
- - [ ] 范围事实在提问之前已呈现
+ - [ ] 在提出任何问题之前，范围确认已将已确认范围、判断依据和待用户决定事项分开呈现
- [ ] `nonGoals` 来自用户，或用户声明没有范围外项
- [ ] 每个适用字段都为 `ready`，或经用户同意后为 `weak-but-explicit`
## 参考资料
- [references/criteria.md](references/criteria.md) — 各字段的判断规则、成本输入、挑战力度、伪装成方案的需求测试