把模糊需求整理成可验收的规格

可以得到什么

一段原本模糊的"想加一个功能"被整理成可被 AI 助手和人类同时复用的规格：包含变更原因、用户场景、行为描述、验收条件、范围边界。Agent 在后续会话中能基于这份规格找到约束，而不是从零猜需求。

适合哪些情况

• 跨文件功能、需多文件协调的实现。
• 容易被 Agent 误解或上下文较复杂的任务。
• 需要和团队成员或后续 Agent 会话保持一致理解的项目。
• 验收标准不明确、容易出现"做完了但不是想要的"的情况。

需要准备什么

• 现有项目代码与目录结构。
• 这次变更的业务动机和范围。
• 至少能想到的几个用户场景和典型交互。
• 现有测试与运行方式（用于验收环节）。

常见做法

1. 用 proposal 写明"为什么做、范围是什么、什么不在这份变更里"。
2. 把用户场景、行为、验收条件写进 spec；每条验收条件尽量可被观察或测试。
3. 对复杂架构选择补充 design，记录关键技术决策、依赖与权衡。
4. 邀请 AI 协助起草与发现遗漏，但由人确认业务目标、技术边界和完成标准。
5. 草稿完成后让人/审阅者对照原始需求重读一遍，挑出歧义、缺漏、范围蔓延。

真实案例与教程

• OpenSpec-practise：仓库内的中文手册与实践材料示范 proposal / spec / design / tasks 的写法。
• 规格驱动开发（Spec-driven development）配合 AI 助手：完整方法描述。

限制和检查点

• 规格写错，AI 会更稳定地实现错误目标（见 规格驱动开发中规格错误被稳定放大的风险）。
• 一次性脚本或极小改动不适合走完整流程，前期文档成本不划算。
• "可验收"不一定是"可自动化测试"——某些验收条件仍需人工确认。
• AI 起草的规格必须由人审阅，不能直接交给 Agent 实施。

相关任务

• 让 coding agent 按任务清单逐项推进
• 为 AI 开发项目保留决策与实施历史

来源

来源：OpenSpec-practise，作者 ForceInjection。