可进入评审的 Markdown
生成结果适合放进工单、PR 或设计评审。它应在实现开始前写清责任人、决策、证据和后续工作。
# 功能规格：重试失败的发票扣款 责任人：Billing platform 非目标：不更换支付渠道 验收证据： - 重复点击只创建一次 payment_attempt - 支付渠道超时后，发票保持可重试状态 - 客服后台显示 pending provider confirmation
功能规格生成器
填写表单，获取即用的规格文档。复制或下载 Markdown。
spec.md
这个工具实际会产出什么
导出之后
把生成的功能规格当成起点，而不是最终答案。替换示例值，补证据，指定评审人，删掉团队不会维护的字段。
- 把输出放在实现工作旁边。
- 每条验收项都要映射到测试或评审证据。
- 不要粘贴密钥、客户数据或私有事故细节。
什么是功能规格？
功能规格是一份简短的结构化文档，在编写任何代码之前，定义功能做什么、如何验证（验收标准）以及可能出现什么问题（边界情况）。它让产品、工程和 QA 团队围绕一个共同的真相来源保持一致。
先写规格再编码可减少返工，尽早发现误解，并使 AI 辅助开发更加可靠。团队获得的不是模糊的需求，而是可测试、可审查的契约。
了解更多：什么是规格优先开发？或浏览我们的功能规格模板。
如何用好这个生成器
先写决策，不要先写界面
命名团队真正承诺的产品行为。“联系人去重”比“加一个去重按钮”更好，因为它能引出数据规则、自动化、权限和恢复策略的讨论。
实现前先写非目标
非目标保护范围。它告诉评审者第一版不做什么，也让工程师有明确依据拒绝范围膨胀，而不是每次都重新争论。
每条验收标准都要对应证据
每一条前提/操作/预期都要决定如何证明：单元测试、集成测试、契约测试、手工 QA 记录、日志检查或上线指标。没有证据的验收标准只是愿望。
用边界情况暴露隐藏工作
空输入、重复、权限、并发、时区、重试、限制和回滚，往往是“小功能”变复杂的地方。提前列出，团队才看得到取舍。
评审者应该能回答的问题
范围
用户、API、数据模型或工作流到底变了什么？这一版明确不改变什么？
正确性
哪些例子能证明行为正确？哪些失败路径是预期内的，哪些应该阻止发布？
发布安全
这个改动能否灰度、能否在线上观察、能否在不丢数据和不误导用户的前提下回滚？
弱目标和强目标对比
弱目标
“优化账号设置页，让用户更容易更新偏好。”这句话听起来合理，但没有说明谁能改、改什么、默认值如何处理、历史数据是否迁移，也没有告诉测试该观察什么。
强目标
“允许工作区管理员更新新成员的通知默认值。现有成员保留当前设置。变更写入审计日志，并显示在管理员活动流。”这类写法能直接引出权限、数据、审计和验收标准。
把生成结果用于 AI 编码工具
带边界地提示
把生成的 Markdown 作为上下文输入，并要求 AI 只实现 Goal、Acceptance Criteria 和 Edge Cases 中明确出现的行为。没有写进规格的字段、路由、后台任务或状态，不应自动补充。
按证据评审
评审输出时，不只看代码能不能跑，而是逐条对照规格：每个验收标准是否有测试，每个非目标是否被遵守，每个边界情况是否有可观察结果。
什么时候用轻量说明就够了
纯文案改动
如果只是替换静态文案，没有状态、权限、数据写入或分析埋点变化，一段说明和截图通常足够。
一次性探索
用于验证方向的探索性原型，可以先写问题和限制，等要进入交付阶段再补完整规格。
无用户可见行为
完全内部的机械重构可以使用更轻的技术检查清单，但如果会影响接口、性能或回滚，仍应写成规格。
导出之后怎么落地
先让三类角色各看一遍
产品确认目标和非目标，研发确认数据、接口和状态变化，QA 确认验收标准是否能直接测试。三类角色都能独立复述第一版范围后，才适合进入实现。
把非目标保留到发布后
非目标不是临时删除的需求，而是防止范围蔓延的边界。发布后复盘时再决定哪些非目标进入下一版，避免实现中途被口头需求慢慢扩大。
用验收证据关闭任务
任务关闭时不要只看代码合并。每条验收标准都应有测试、截图、日志或手工验证记录，证明实现确实符合当初写下的规格。
完成后的功能规格应该证明什么
团队同意第一版切片
好的功能规格会说明现在交付什么、暂不做什么、哪些角色受影响、哪些状态会变化，以及团队如何判断第一版完成。它应该减少代码评审阶段的范围争论。
测试可以直接拆出来
QA 应该能把验收标准直接转成测试用例，而不需要反复追问作者。如果测试仍依赖私下解释，规格还没有准备好进入实现。
导出后如何进入评审
先做范围检查
在讨论实现方案前，先确认目标、非目标和第一版可交付切片是否明确。如果范围仍在变化，团队应该先解决这个问题，再进入技术设计或排期讨论。
把每条验收标准变成证据
每条验收标准都应对应测试、截图、日志、查询结果或手工验证步骤。导出的规格只有能指向证据，才真正能支撑发布判断。
功能规格常见问题
一份功能规格应该多长？
长到足以消除歧义，短到评审者能一次读完。大多数功能工作里，一两页精准要点，比一篇把决策藏起来的长文更有用。
什么时候用模板而不是生成器？
如果你想在文档里手写，用 功能规格模板。如果你想通过表单引导、实时预览、草稿恢复和快速导出 Markdown，用这个生成器。
这个工具如何设计和复查
来自规格评审失败
表单重点覆盖目标、非目标、验收标准、边界情况、交付物、依赖和评审问题，因为这些空白最容易在实现阶段变成返工。
按实现准备度复查
生成结果会检查评审者是否能看出第一版可交付切片、所需证据、排除范围和 AI 编码边界，而不需要再开一次说明会。
由编辑维护
作者与编辑：Daniel Marsh。复查流程：编辑政策。纠错与工具问题：联系。最近复查：2026 年 4 月 28 日。