---
name: requirement-convergence
description: 将变更必须产生的结果与为达成该结果而提出的需求区分开来，记录用户明确排除的内容，并根据结构对成本进行分级评估。当需求进入某个工作流时、设计开始之前，或提到“做到什么程度/范围外是什么/是否值得做”时使用。
---

# 需求收敛

## 目的

收到的需求往往过于臃肿、含糊不清，或指向错误的目标。能力足够的模型会将这三者调和为一个连贯的计划，并忠实地构建它——当被要求的内容本身就是错的时，也精确地交付被要求的内容。

本技能收敛的是**要构建什么**。如何构建，以及该变更需要哪些文档，都在“要构建什么”确定之后再解决。

## 收敛字段

| 字段 | 通过条件 |
|-------|----------------|
| `outcome` | 一个可观测的结果。不服务于该结果的需求即为多余。 |
| `requirements[]` | 每个与构建相关的项都标注为 `current-state` 或 `desired-future`。 |
| `nonGoals[]` | 由用户撰写，或用户声明没有范围外项。 |
| `cost` | 一个带有结构性依据支撑的分级，加上仍然存在的未知项。 |

`cost` 是一个粗略的分级，不是工作计划据以排期的工作量估算；需求无法支撑以人天为单位的估算。其未知项在决策权重上比其规模更重要。

依据所保留的用户原话进行分类，而不是依据分析器对原话的转述。要求评估的措辞、描述设想性想法的措辞，或建议某种机制的措辞，在当前收敛上下文中仅作为供判断参考的候选项保留。只有在用户明确确认之后，候选项才能进入 `requirements[]` 及长期保留的文档。

每个字段都带有各自的就绪标签：`ready`、`weak`，或 `weak-but-explicit`（弱，且用户同意暂不解决）。只有用户可以设置 `weak-but-explicit`。当所有适用字段都为 `ready` 或 `weak-but-explicit` 时，需求即视为已收敛。

各字段的判断规则见：[references/criteria.md](references/criteria.md)。

## 询问协议

使用现有的范围与成本依据来引出信息并做出判断，然后只就仓库无法回答的产品选择进行提问。`requirements[]` 和排除项的询问都依据用户提出的能力构建；分析中发现的相邻能力两者都不纳入，因此用户无需拒绝一项自己并未提出的能力。仅当某个答案会改变分析目标或所需的范围依据时，才重新分析范围与成本。

在开始前登记以下步骤，并在每个步骤完成时记录其依据：

| 步骤 | 动作 | 完成依据 |
|------|--------|---------------------|
| 1 | 陈述现有的范围事实，然后单独说明这些事实对需求意味着什么 | 列出事实及其分析依据 |
| 2 | 就低于 `ready` 的字段提问，每条消息最多两个问题 | 每个低于 `ready` 的字段一个问题 |
| 3 | 将每个答案记录为该字段的值 | 该值是用户明确选定的选项，或用户自己提供的措辞 |
| 4 | 当已记录的值仍未通过其通过条件时，重新询问一次；若用户同意将第二次回答维持原状，则将该字段标记为 `weak-but-explicit` | 两次已记录的答案，或用户同意停止 |
| 5 | 依据每个字段的通过条件进行判断，并完成该记录 | 一份每个字段都已标注的收敛记录 |

## 存储协议

| 载体 | 承载内容 |
|---------|-------|
| 当前收敛记录 | 每个字段及其就绪标签 |
| PRD 的 `成功标准` 和 `范围外` | `outcome`；用户撰写的 `nonGoals` |
| 设计文档的 `需求收敛` | 在没有 PRD 时承载同样内容，且在任何情况下都承载被标为 `weak-but-explicit` 的字段 |

不产生上述任一文档时，将记录保留在当前上下文中。

## 引用协议

1. 从提示词中读取收敛记录。
2. 将 `nonGoals` 视为当前变更排除在外的内容，将 `desired-future` 需求视为可构建的范围。未被采纳的评估性请求、设想性想法、指定的实现机制以及由智能体提出的能力不产生任何实现义务；已被采纳的 ADR 可以将已评估过的选项保留作为决策历史。
3. 将 `weak-but-explicit` 的字段视为已记录的悬而未决的问题，而非已敲定的决策，当工作依赖于该问题的解决时应上报处理。

## 质量检查清单

- [ ] 范围事实在提问之前已呈现
- [ ] `nonGoals` 来自用户，或用户声明没有范围外项
- [ ] 每个适用字段都为 `ready`，或经用户同意后为 `weak-but-explicit`

## 参考资料

- [references/criteria.md](references/criteria.md) — 各字段的判断规则、成本输入、挑战力度、伪装成方案的需求测试