使用 Managing Uncertain Requirements 将不确定需求逐步转化为可实施、可验证、可交付的工程任务。

在使用过程中发现，太过沉重，导致分析过度，还有在测试过程中，太复杂化,已经弃用，谨慎使用

一、Skill解决什么问题

$managing-uncertain-requirements 适合以下场景：

• 只有初步想法，需求还没有确定
• 需要先沟通需求，不希望AI直接修改代码
• 需要把需求分析、调研、架构、规格和开发过程保存为文档
• 涉及权限、金额、数据状态、异常处理等复杂业务规则
• 希望每个阶段由使用人确认后，才能进入下一阶段
• 希望AI按照SDD、Harness、Loop方式完成工程任务
• 希望避免AI自行补充需求、扩大范围或直接部署

整个流程遵守以下原则：

1. 先检查项目事实，再提出建议。
2. 区分现有事实、分析建议、已确认决定和待确认问题。
3. 每次只询问一个最关键的问题。
4. 每个阶段完成三次阶段出口审计。
5. 使用人确认当前阶段文档后，才能进入下一阶段。
6. 未明确授权时，不修改代码、不提交、不推送、不部署。

二、模式A：只沟通需求，不生成文件

适合需求刚刚出现，还不确定是否立项。

使用 $managing-uncertain-requirements。

项目目录：【项目路径】
初始需求：【需求想法】

当前只进行需求分析，不修改文件。

执行要求：
1. 先检查项目现有文档、代码和目录规范；
2. 从Discovery阶段开始；
3. 区分现有事实、分析建议、已确认决定和待确认问题；
4. 每次只问我一个最重要的问题，并给出推荐意见；
5. 不创建需求文档；
6. 不修改任何项目文件；
7. 完成三次阶段出口审计后，再让我确认Discovery结论；
8. 未经我的明确批准，不得进入下一阶段。

该模式下，需求分析结论只保留在当前对话中。

三、模式B：完整文档流程

适合正式项目，需要保存各阶段文档。

使用 $managing-uncertain-requirements 管理这个需求。

项目目录：【项目路径】
初始需求：【需求想法】
功能名称：【中文名称】
功能标识：【英文kebab-case，例如material-settlement】

允许创建和更新需求阶段文档。

执行要求：
1. 先检查项目现有文档、代码、测试和目录规范；
2. 如果项目已有等价的需求文档目录，沿用现有规范；
3. 如果没有现有规范，使用：
   docs/features/<feature-slug>/
4. 从Discovery阶段开始；
5. 区分现有事实、分析建议、已确认决定和待确认问题；
6. 每次只问我一个最重要的问题，并提供推荐意见；
7. 每个阶段必须完成三次阶段出口审计；
8. 必须由我确认当前阶段文档后，才能进入下一阶段；
9. 未经我的明确批准，不得进入实现阶段；
10. 未经授权，不得提交、推送、发布或部署。

四、阶段文档目录

如果项目没有现成的文档规范，默认使用以下目录：

docs/features/<feature-slug>/
├── 01-discovery/
│   └── discovery.md
├── 02-research/
│   └── research.md
├── 03-prototypes/
│   └── prototype.md
├── 04-architecture/
│   ├── architecture-design.md
│   ├── architecture-improvement.md
│   └── wayfinding.md
├── 05-spec/
│   ├── drafts/
│   │   └── spec.md
│   └── approved/
│       └── spec.md
├── 06-tickets/
│   └── tickets.md
├── 07-implementation/
│   └── implementation-log.md
├── 08-debugging/
│   └── diagnosis.md
├── 09-reviews/
│   └── review.md
└── 10-handoffs/
    └── handoff.md

注意：

• 一个需求只维护一个功能目录。
• <feature-slug> 使用小写英文和连字符。
• 例如：material-revenue-settlement。
• 架构阶段只创建当前使用的文档，不需要同时创建三个架构文档。
• 项目已有等价规范时，沿用原有规范，不创建第二套目录。

五、Discovery：需求分析

用于确认问题、用户、目标、范围、限制、风险和未知项。

使用 $managing-uncertain-requirements。

进入Discovery阶段。

项目目录：【项目路径】
初始需求：【需求想法】
功能名称：【中文名称】
功能标识：【英文kebab-case】

请完成以下工作：
1. 检查项目现有代码、文档和业务术语；
2. 明确要解决的问题；
3. 明确主要用户；
4. 梳理3至5个核心场景；
5. 明确功能目标和成功标准；
6. 明确本次范围和非目标；
7. 检查权限、金额、隐私、数据状态和数据丢失风险；
8. 区分事实、建议、决定和未知项；
9. 每次只问我一个最重要的问题；
10. 把结论保存到：
    docs/features/<feature-slug>/01-discovery/discovery.md

完成三次阶段出口审计后，让我确认Discovery文档。
未经确认，不得进入下一阶段。

确认用语：

批准Discovery结论，并进入【下一阶段名称】。

不批准时：

暂不批准Discovery结论。

需要修改：
【填写需要调整的内容】

请继续停留在Discovery阶段。

六、Research：外部调研

适合查询官方接口、第三方能力、产品价格、政策或技术事实。

使用 $managing-uncertain-requirements。

进入Research阶段。

项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
已经批准的调研问题：【填写具体问题】
来源要求：【例如只允许使用官方文档】

请完成以下工作：
1. 只研究已经批准的问题；
2. 优先使用官方文档和一手资料；
3. 区分已验证事实、合理推断和分析建议；
4. 记录来源和证据；
5. 不将调研建议自动视为业务决定；
6. 将结论保存到：
   docs/features/<feature-slug>/02-research/research.md

完成三次阶段出口审计后，让我确认Research文档。

确认用语：

批准Research结论，并进入【下一阶段名称】。

七、Prototype：原型验证

适合验证页面交互、状态流程或技术方案是否可行。

使用 $managing-uncertain-requirements。

进入Prototype阶段。

项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
需要验证的不确定性：【具体问题】
原型成功标准：【什么结果代表可行】

请完成以下工作：
1. 设计最小、可逆、可丢弃的验证方案；
2. 不把原型当成正式生产实现；
3. 不扩大验证范围；
4. 记录验证过程、结果和结论；
5. 说明原型结果对正式方案有什么影响；
6. 将结论保存到：
   docs/features/<feature-slug>/03-prototypes/prototype.md

完成三次阶段出口审计后，让我确认Prototype结论。

确认用语：

批准Prototype结论，并进入【下一阶段名称】。

八、Wayfinding：定位现有代码

适合不熟悉项目，不知道功能入口、模块归属或数据流时使用。

使用 $managing-uncertain-requirements。

进入Wayfinding阶段。

项目目录：【项目路径】
需要定位的问题：【填写问题】

请只检查现有项目，不设计新架构，不修改代码。

请梳理：
1. 功能入口；
2. 主要调用链；
3. 数据经过的模块；
4. 核心状态变化；
5. 数据库或外部服务依赖；
6. 模块职责和归属；
7. 已确认事实和未知项；
8. 可能受到影响的文件；
9. 下一步需要做出的决定。

将结果保存到：
docs/features/<feature-slug>/04-architecture/wayfinding.md

完成三次阶段出口审计后，让我确认Wayfinding结论。

确认用语：

批准Wayfinding结论，并进入【下一阶段名称】。

九、Architecture Design：新架构设计

适合新增模块、跨系统功能或重要技术决策。

使用 $managing-uncertain-requirements。

进入Architecture design阶段。

项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
需要解决的技术决策：【填写技术问题】

请完成以下工作：
1. 检查现有项目架构和约束；
2. 明确模块边界和职责；
3. 分析数据模型影响；
4. 分析外部服务和依赖；
5. 提供可选方案；
6. 比较每个方案的优缺点和迁移成本；
7. 给出推荐方案；
8. 说明不采用其他方案的原因；
9. 判断是否需要ADR；
10. 不直接修改代码。

将结果保存到：
docs/features/<feature-slug>/04-architecture/architecture-design.md

完成三次阶段出口审计后，让我确认Architecture design文档。

确认用语：

批准Architecture design，并进入【下一阶段名称】。

十、Architecture Improvement：现有架构改进

只适合已经存在代码，并且能够找到真实架构问题的项目。

使用 $managing-uncertain-requirements。

进入Architecture improvement阶段。

项目目录：【项目路径】
需要检查的模块：【模块或目录】

请先检查真实代码证据，不要根据猜测提出重构。

重点检查：
1. 模块职责是否混乱；
2. 是否存在重复所有权；
3. 是否存在边界泄漏；
4. 是否存在难以测试的接口；
5. 是否存在重复业务逻辑；
6. 是否存在不合理的跨层依赖；
7. 改进方案能否分步实施；
8. 改进可能带来的迁移风险。

当前只分析和设计，不修改代码。

将结果保存到：
docs/features/<feature-slug>/04-architecture/architecture-improvement.md

完成三次阶段出口审计后，让我确认Architecture improvement文档。

确认用语：

批准Architecture improvement，并进入【下一阶段名称】。

十一、Specification：正式需求规格

进入该阶段前，Discovery和必要的调研、原型或架构结论必须已经批准。

使用 $managing-uncertain-requirements。

进入Specification阶段。

项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】

请读取已经批准的：
- Discovery文档；
- Research文档；
- Prototype文档；
- Architecture文档。

根据已批准结论编写可测试的需求规格，必须包括：
1. 问题和目标用户；
2. 核心使用场景；
3. 功能范围；
4. 明确非目标；
5. 业务规则；
6. 输入和输出；
7. 用户权限；
8. 数据状态；
9. 正常流程；
10. 异常流程；
11. 失败恢复方式；
12. 验收标准；
13. 安全、隐私、金额和数据风险；
14. 明确排除项。

先生成草稿并保存到：
docs/features/<feature-slug>/05-spec/drafts/spec.md

未经我明确批准，不得复制到approved目录，不得拆分Tickets。

修改草稿：

暂不批准Specification草稿。

需要修改：
【填写修改要求】

请修改草稿，不要进入Tickets阶段。

批准规格：

批准这份Specification，用于拆分Tickets。

请将批准版本保存到：
docs/features/<feature-slug>/05-spec/approved/spec.md

十二、Tickets：拆分开发任务

使用 $managing-uncertain-requirements。

进入Tickets阶段。

项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】

请根据已批准的Specification拆分开发任务。

每个Ticket必须包括：
1. Ticket编号；
2. 单一目标；
3. 对应的Specification条目；
4. 前置依赖；
5. 预计修改范围；
6. 验收条件；
7. 测试要求；
8. 明确非目标；
9. 风险和注意事项；
10. 是否可以独立验证。

当前只拆分Tickets，不修改代码。

将结果保存到：
docs/features/<feature-slug>/06-tickets/tickets.md

完成三次阶段出口审计后，让我确认Tickets。

批准指定任务：

批准这些Tickets，并允许实现ticket T-001。

本次只授权T-001，不代表批准其他Ticket。

十三、Implementation：逐个实现

使用 $managing-uncertain-requirements。

进入Implementation阶段。

项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
本次批准实现的Ticket：【T-001】

执行要求：
1. 读取已批准的Specification和Tickets；
2. 检查项目开发规范和现有代码；
3. 检查测试、构建、类型检查和启动命令；
4. 先输出T-001的小步实现计划；
5. 只修改T-001涉及的范围；
6. 不添加无关功能；
7. 不进行无关重构；
8. 不擅自增加依赖；
9. 不擅自修改数据库、部署或生产配置；
10. 完成后运行对应测试；
11. 检查修改差异；
12. 报告修改文件、行为变化和验证证据。

将实现记录保存到：
docs/features/<feature-slug>/07-implementation/implementation-log.md

未经重新批准，不得实现下一个Ticket，不得提交、推送或部署。

批准下一个任务：

批准实现ticket T-002。

十四、Debugging：先诊断再修复

使用 $managing-uncertain-requirements。

进入Debugging阶段。

项目目录：【项目路径】

预期行为：
【填写应该发生什么】

实际行为：
【填写实际发生什么】

复现步骤：
【填写复现方式】

错误信息或日志：
【粘贴完整错误】

最近修改：
【如果知道则填写】

当前只进行诊断，不要直接修改代码。

请输出：
1. 已确认症状；
2. 可能原因；
3. 每个假设的验证方法；
4. 已排除原因；
5. 涉及的文件和调用链；
6. 推荐的最小修复边界；
7. 修复后的验证计划。

将诊断结果保存到：
docs/features/<feature-slug>/08-debugging/diagnosis.md

完成三次阶段出口审计后，让我确认Diagnosis。

批准修复：

批准这份Diagnosis。

允许按照文档中的最小修复边界进行修复。
不得扩大修改范围。

十五、Review：代码与需求审查

使用 $managing-uncertain-requirements。

进入Review阶段。

项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】
审查范围：【Ticket编号、分支、提交或修改范围】

请分别执行：
1. Standards Review：检查是否符合项目规范；
2. Specification Review：检查是否符合批准的需求规格。

重点检查：
- 功能是否满足验收标准；
- 是否存在范围外修改；
- 权限是否正确；
- 数据状态是否完整；
- 异常处理是否完整；
- 是否存在安全或隐私问题；
- 测试证据是否充分；
- 是否存在潜在回归。

按严重程度列出问题。
当前只进行Review，不直接修改代码。

将结果保存到：
docs/features/<feature-slug>/09-reviews/review.md

批准处理Review问题：

批准处理Review中的以下问题：
【问题编号】

只允许处理指定问题，不得扩大范围。

Review完成后：

批准Review处理结论，并进入Handoff。

十六、Handoff：交付说明

使用 $managing-uncertain-requirements。

进入Handoff阶段。

项目目录：【项目路径】
功能目录：【docs/features/<feature-slug>】

请整理：
1. 已交付范围；
2. 未交付内容；
3. 主要修改文件；
4. 功能入口和数据流；
5. 测试与验收证据；
6. 已知限制；
7. 遗留风险；
8. 技术债；
9. 认知债；
10. 部署和运行注意事项；
11. 出现问题时首先检查的位置；
12. 后续负责人需要完成的事项。

将结果保存到：
docs/features/<feature-slug>/10-handoffs/handoff.md

不要自动提交、推送、发布或部署。
完成三次阶段出口审计后，让我确认Handoff。

最终确认：

批准这份Handoff为完成状态。

十七、学习模式

如果希望理解整个工程过程，而不是只让AI完成代码，可以使用强Ownership模式。

使用 $managing-uncertain-requirements。

学习模式。
我想理解整个实现过程，不要直接修改代码，带我分析。

项目目录：【项目路径】
当前问题：【需求或Bug】

每个阶段请说明：
1. 为什么这样判断；
2. 功能入口在哪里；
3. 数据经过哪些模块；
4. 核心状态如何变化；
5. 最容易在哪里出错；
6. 为什么选择当前方案；
7. 为什么不选择其他方案；
8. 如何验证结果；
9. 出现问题时首先检查哪里；
10. 我还需要理解哪些知识。

涉及正确性、安全、金额、权限、数据丢失或部署风险的问题，
如果我还没有理解清楚，请将其标记为阶段阻塞项。

十八、三次阶段出口审计

每次进入下一阶段前，AI都需要完成以下检查。

第一次：完整性检查

检查：

• 当前阶段要求是否已经完成
• 是否存在矛盾
• 是否遗漏关键内容
• 是否把推断误认为事实
• 是否还有没有记录的决定

第二次：阻塞项检查

所有未解决问题必须分类为：

blocks-next-stage
defer-to-<stage>
out-of-scope

涉及以下内容的问题，默认会阻塞Specification、Tickets或Implementation：

• 业务规则
• 用户可见行为
• 权限
• 数据状态
• 金额与结算
• 失败处理
• 安全与隐私
• 数据丢失风险

第三次：阶段跳转检查

检查：

• 下一阶段是否真的有必要
• 当前阶段输入是否已经批准
• 是否还有阻塞项
• 下一阶段是否依赖尚未确定的内容

如果审计未通过，AI必须说明：

阶段出口审计未通过。

并继续停留在当前阶段。

十九、推荐日常总控提示词

以后处理新的不确定需求，可以直接复制下面这段：

使用 $managing-uncertain-requirements 管理这个需求。

项目目录：【绝对路径】
初始需求：【当前想法，可以很粗略】
功能名称：【中文名称】
功能标识：【英文kebab-case】

工作模式：【只沟通需求，不生成文件 / 完整文档流程】
Ownership模式：【lightweight / 学习模式strong】

执行要求：
1. 先检查项目现有文档、代码、测试和目录规范；
2. 从Discovery阶段开始；
3. 区分现有事实、分析建议、已确认决定和待确认问题；
4. 每次只问我一个最重要的问题，并提供推荐意见；
5. 优先沿用项目已有文档规范；
6. 如果没有现有规范，使用：
   docs/features/<feature-slug>/
7. 每次进入下一阶段前，执行三次阶段出口审计；
8. 必须由我确认当前阶段文档或无文档结论；
9. 未经确认，不得进入下一阶段；
10. 未经批准，不得进入Implementation；
11. 实现时一次只允许处理一个指定Ticket；
12. 不得自动提交、推送、发布或部署；
13. 任何“应该可以”“逻辑正确”都不能作为完成证据；
14. 必须使用测试、构建、接口、页面或人工验收结果证明完成。

二十、常用确认语句

批准Discovery结论，并进入Research。

批准Discovery结论，并进入Specification。

批准Research结论，并进入Architecture design。

批准Architecture design，并进入Specification。

批准这份Specification，用于拆分Tickets。

批准这些Tickets，并允许实现ticket T-001。

批准实现ticket T-002。

批准这份Diagnosis，允许按照最小修复边界修复。

批准Review处理结论，并进入Handoff。

批准这份Handoff为完成状态。

批准一个问题不等于批准整个阶段；批准需求文档不等于批准修改代码；批准实现不等于批准提交、推送或部署。

版权所有

版权归属：念宇

许可证：署名-非商业性-禁止演绎 4.0 国际 (CC-BY-NC-ND-4.0)