工具

功能规格生成器

填写结构化表单，生成完整的 Markdown 功能规格。复制或下载——随时可用于你的代码仓库。

API 规格生成器

在一份规格中涵盖端点契约、请求/响应模式和错误码。

数据库规格生成器

表、字段、约束、索引和迁移计划。

事后复盘生成器

无责事故复盘：时间线、影响、根本原因、带责任人的行动项。

Gherkin 生成器

把用户故事和验收标准转成合法的 .feature 文件。

功能规格生成器预览

有用的输出不是长文，而是评审者能马上检查的范围、验收、证据和回滚。

# 功能规格：重试失败的发票扣款

非目标：
- 不新增支付渠道
- 不修改订阅套餐

验收：
- 过期卡返回 card_declined
- 重试沿用同一个 invoice_id
- 审计日志记录 retry_source

证据：
- 支付重试集成测试
- declined 状态截图
- 回滚开关：invoice_retry_v2

API 规格生成器预览

API 输出应该让接入方能实现，也让评审者能拦住有风险的变更。

# API 规格：创建退款

POST /refunds
幂等：必须传 Idempotency-Key

错误：
- 409 duplicate_refund
- 422 refund_window_expired

评审门禁：
- replay 契约测试
- 旧 SDK 兼容检查
- refund_status enum 发布说明

实现前

当任务需要先明确目标、非目标、验收标准、边界条件和实现备注时，用 功能规格生成器 起草第一版。

联调前

当多个客户端、服务或合作方需要统一请求结构、响应结构、错误行为和兼容规则时，用 API 规格生成器。

迁移前

当改动涉及表、约束、索引、回填或回滚策略时，用 数据库规格生成器，先把数据风险写出来。

用生成器起草，用清单评审

先快速生成结构化初稿，再对照 规格评审清单。生成器负责让文档成形，清单负责发现范围、上线、可观测性和测试证据的缺口。

把示例当作校准，不当作填充

每个工具都提供真实感示例，因为空字段很容易产出空泛规格。先加载示例，观察具体程度，再换成你自己的业务细节。

让生成文档靠近代码

把输出复制到 issue、设计文档或代码仓库。规格最有价值的时刻，是评审者能把实现 diff 和当初的验收标准直接对照。

小规格优于巨型文档

如果输出开始变长，就按决策拆开：功能规格、API 契约、迁移计划、复盘文档分别维护。小文档更容易评审，也更不容易过期。

产品决策未定时，先开会

如果团队还没有统一用户、成功指标、发布边界或失败行为，不要把生成结果当成最终批准。可以先用工具暴露空白，再让真正负责的人做决策。

长期契约要进仓库

API、迁移、账单规则、权限模型和平台行为，生成后应该进入版本控制。长期契约需要评审历史、负责人，以及实现变化后的同步更新。

事故先写复盘，不先写功能规格

如果工作源于线上事故，先用复盘生成器记录时间线、检测缺口、根因和行动项，再把需要修复的部分拆成规格或工单。

Gherkin 适合可执行示例

当示例会进入自动化测试或 QA 场景库时，Gherkin 很有用。如果只是一次快速评审，短清单可能比正式 .feature 文件更清楚。

放进同一个评审入口

不要让生成的 Markdown 停留在浏览器里。把它贴进 issue、PRD、设计文档或仓库里的 /docs/specs/，并让团队用同一个链接评审，避免不同人看到不同版本。

给每份输出指定负责人

功能规格通常由 PM 和技术负责人共同维护；API 契约需要服务 owner 批准；数据库规格需要负责迁移的人确认；复盘行动项必须写清负责人和截止日期。

上线前对照验收标准

生成器只负责结构化，不能替代验收。合并前应逐条检查：标准是否有测试、非目标是否被遵守、边界情况是否被验证、回滚条件是否可执行。

把示例改成真实业务语言

示例用于校准具体程度，不应原样进入团队文档。把“用户”“订单”“状态”等通用词替换成你们系统里的角色、对象、字段和错误码。

哪些内容留在浏览器

生成器在客户端运行，不要求登录。草稿恢复使用本地浏览器存储，方便同一浏览器中继续编辑。不要把密钥、生产 token 或受监管的个人数据粘贴进任何网页工具。

分享前要检查什么

把生成的规格发给同事或 AI 编码工具之前，先移除客户标识、内部域名、未发布价格、凭证，以及任何不应该离开项目工作区的信息。

先看评审者需要什么产物

如果评审者需要确认产品范围，用功能规格。如果需要客户端和服务端共享契约，用 API 规格。如果风险在数据迁移、约束或索引，用数据库规格。如果工作来自线上事故，用复盘工具。

把空字段当成风险信号

没有回滚、没有负责人、没有错误行为、没有测试证据，通常不是“稍后再补”的小事，而是说明团队还缺一个明确决策。生成器能帮你更早看到这些空白。

导出后删掉重复内容

生成结果不是越长越好。进入评审前，应保留具体决策、示例和证据，删掉重复或无法行动的句子，让团队更容易判断是否可以进入实现。

把草稿放进评审现场

导出的 Markdown 应放到真正做决策的地方：issue、PR 描述、设计文档、事故跟踪系统或仓库目录。只有团队能评论和对照实现，它才不只是本地草稿。

审批前替换成真实示例

把示例值换成你自己领域的一组请求、迁移步骤、行为场景或时间线。真实示例最容易暴露隐藏假设，也能让评审者判断内容是否足够具体。

实现后回填最终行为

如果实际实现和导出草稿不同，发布前要更新规格。工具生成的内容只有反映最终上线版本，才会成为可维护资产，而不是一次性文档。

这些工具能替代人工评审吗？

不能。它们帮助你产出结构化初稿。真正发现产品歧义、运维风险和兼容性问题的，仍然是团队评审。

应该先用哪个工具？

产品行为先用功能规格；服务边界先用 API；存储和迁移风险先用数据库；事故复盘先用复盘工具；可执行验收示例先用 Gherkin。