SDD 2.0：用户故事的Prompt工程化重构
TL;DR
本文核心观点：
- 传统用户故事过时 — “作为X我想要Y”格式无法承载AI需要的上下文
- 三元组新结构 — 上下文-约束-验收标准成为最小完备单元
- Prompt即故事 — 精心设计的Prompt就是可执行的需求文档
- 需求工程升级 — 从文本描述到结构化意图表达的范式转移
用户故事的局限
💡 Key Insight
“作为用户，我想要登录功能”这种格式诞生于2001年，目的是促进对话。但在AI时代，我们需要的是可执行的需求，而不仅仅是谈话起点。
经典用户故事格式：
这个格式在敏捷初期是革命性的——它强迫产品经理思考”为谁”和”为什么”，而不仅仅是”做什么”。
💡 Key Insight
但这份”谈话起点”的定位，在AI时代变成了致命弱点：没有结构化上下文的Prompt，只能靠AI自行猜测，而猜测的结果往往与预期相差甚远。
但它有三个致命缺陷：
| 缺陷 | 说明 | 后果 |
|---|---|---|
| 上下文缺失 | 不知道用户当前状态、环境、前置条件 | AI生成代码频繁假设错误 |
| 约束模糊 | 性能、安全、合规要求难以表达 | 生成的代码需要反复修改 |
| 验收游离 | AC与故事分离，容易不一致 | 实现与期望偏差大 |
真实案例：
一个团队让AI实现”作为顾客，我想要查看订单历史”。AI生成了一个简单的列表页面。
但实际需求包括：
- 分页（每页20条）
- 按时间倒序
- 支持按状态筛选
- 移动端适配
- 3秒内响应
- 只显示近2年数据
这些约束散落在邮件、会议记录、口头沟通中——AI读不到。
三元组新范式
💡 Key Insight
AI需要的最小完备信息单元是三元组：上下文（Context）+ 约束（Constraints）+ 验收标准（Acceptance Criteria）。缺少任何一项，生成都可能偏离目标。
结构对比
| 维度 | 传统格式 | SDD 2.0 |
|---|---|---|
| 完整性 | 需人工补充 | 自包含 |
| AI可消费性 | 低（需解析） | 高（结构化） |
| 可验证性 | 模糊 | 明确 |
| 可追溯性 | 弱 | 强 |
| 版本管理 | 文本diff难读 | 结构diff清晰 |
Prompt即需求
💡 Key Insight
当Prompt可以被版本控制、被测试、被验证时，它就不再是”提示”，而是可执行的规格说明书。
Prompt作为需求的演进
早期的大模型应用实验中，Prompt只是一段随意写下的指令——写在聊天框里，说完即焚。团队靠口口相传或截图分享提示词，”优化Prompt”意味着反复手动尝试，靠直觉判断哪个版本更好。
随着AI进入生产流程，这种方式暴露了根本性的问题：无法追溯、不便对比、难以测试。Prompt工程开始借鉴软件工程的核心实践——版本控制（git）、自动化测试（eval suite）、持续集成（CI检查完整性）。当一个Prompt被提交到仓库、被CI验证、被code review审查时，它就不再是一段临时的聊天记录，而是一份可执行规格说明书。
这个转变的意义在于：Prompt第一次被当作”代码”而不是”文案”来对待。它可以被打tag、被diff、被回滚、被自动化测试覆盖。AI可消费性的问题，因此从根本上得到了解决。
Prompt工程 = 需求工程
传统需求工程的产出是一份PRD文档——PDF或Word文件，人可以阅读，但AI无法直接消费。产品经理写出”用户应该能够查看订单历史”，工程师自己判断实现细节，大量的上下文、约束、验收标准都隐含在”常识”里。
AI-Native需求工程的产出是一份结构化的Prompt（通常以YAML格式表达）。这份Prompt同时承载了三件事：AI生成代码时需要的所有上下文、约束和验收标准。YAML文件被测试框架解析为测试用例，被文档工具渲染为需求文档，被验证工具检查完整性——一份来源，多处使用，这是结构化需求表达的核心优势。
传统PRD是人读的消费物；SDD 2.0的Prompt既是人读的消费物，更是AI直接可执行的规格说明书。需求工程的范式因此从”文档驱动”转向”规格驱动”。
实战模板
💡 Key Insight
好的模板不是限制，而是思维的脚手架。它确保你不遗漏关键信息，同时保持表达的灵活性。
SDD 2.0 标准模板
异常路径： | 场景 | 输入 | 预期行为 | |——|——|———-| | 库存不足 | 剩余0张 | 按钮变灰，提示”已领完” | | 已领取过 | 用户已持有该券 | 提示”您已领取”，跳转卡包 | | 风控拦截 | 同IP领取超10次 | 提示”操作频繁”，要求验证码 | | 未登录 | 游客点击 | 弹出登录框，登录后继续 |
边界条件：
- 并发领取：1000人同时点击，不超卖
- 网络中断：领取中断网，支持重试
- 服务端错误：返回500时友好提示
结尾
从”作为 X 我想要 Y”到”上下文-约束-验收标准”三元组，SDD 2.0 的核心变化不是格式的修饰，而是消费对象的根本切换：需求文档不再只是写给人看的协议，而是写给 AI 的可执行规格。
这一点改变的不是工具，而是组织里最稀缺的那类人——能把业务意图精确表达为 AI 可消费结构的人。当表达变得可结构化、可版本化、可测试，需求工程第一次和软件工程站在同一份产出的两侧：一份来源，多处使用。
需求工程师的角色不会消失，反而更关键——只是他们的工作从”写文档”变成了”设计可被 AI 完美执行的意图”。
💡 Key Insight
当 Prompt 成为可执行的规格说明书，需求工程师的设计者角色比任何时代都更重要。
深度阅读时间：约 5 分钟
💬 评论
💡 使用 GitHub 账号登录 即可参与讨论