AI 编码规格包生成器

在让 AI 编码工具修改仓库前，把模糊需求转成一组可评审的 Markdown 规格包。

proposal.md为什么做、影响、受影响用户
spec.md需求、场景、边界条件
design.md决策、取舍、上线回滚
evidence.md测试、截图、日志、停止信号

浏览完整案例 · 优惠码案例 · 通知案例

可检查输出

每个生成文件都对应一个评审决策。

这个工具只有在输出能进入代码评审时才有价值。下面这些文件让评审者在把规格交给 AI 编码 agent 之前，就能检查范围、任务和证据是否成立。

proposal.md说明为什么要做、影响谁、哪些风险值得先写规格。
spec.md写清需求、非目标、边界情况和约束实现的场景。
tasks.md把实现切成小步骤，避免一个大提示词改动无关代码。
evidence.md列出合并前需要的测试、截图、日志、指标和回滚信号。

1. 描述改动

先写粗糙版本，右侧输出会把它整理成评审结构。

2. 给 AI 编码加边界

规格包完成度

需要补充细节
0/100
    复制为
    加载示例

    复制到 issue

    当实现前需要多人评审时，用 复制完整规格包 把提案、行为规格、设计说明、任务计划和证据标准一次贴过去。

    下载进仓库

    如果团队把规格和代码放在一起，就用 ZIP 导出到 /docs/specs/ 或 /changes/feature-name/ 这类目录。

    给 AI 明确边界

    把规格包贴在编码提示词上方，并要求 diff 回到需求、任务和验收标准逐项对应。

    这个生成器负责解决什么问题

    把模糊点变成评审字段

    工具不会假装一个模糊需求已经足够安全。它会强制你填写负责人、受影响用户、约束、非目标、已知风险和上线观察信号。这些字段正是 AI 生成 diff 开始漂移时，评审者最需要的上下文。

    生成能放进仓库的文件

    输出使用 Markdown，是因为规格包应该出现在实现决策被评审的地方：issue、PR，或 /docs/specs/ 这样的目录。聊天记录很快会消失，小文件可以链接、diff 和持续更新。

    把证据放进提示词

    生成的 evidence 文件不是事后汇报表，而是在编码前告诉代理和评审者：合并前必须看到哪些证明，包括测试、截图、日志、指标、手工检查和停止信号。

    一个实用评审流程

    规格包应该在实现前使用，而不是实现后补文档。最稳的流程很简单：一个人起草规格包，一个评审者挑战边界，然后编码助手拿批准后的规格包作为指令来源。如果助手修改了规格外行为，评审者就可以直接要求改回，而不用重新争论真实意图。

    规格包应该保持短小。一个有用的 spec.md 通常一两页就够，但必须写出容易被回避的部分：本次不做什么、哪里可能出错、哪些用户受影响、用什么证据证明改动成立。很长但回避这些决定的规格仍然低价值；短但把这些说清楚的规格才有用。

    编码前

    填写表单，必要时加载示例，并编辑生成的 Markdown，直到范围和非目标足够明显。

    编码中

    把规格包放在 AI 提示词上方，并要求每个改动文件都对应任务和验收标准。

    合并前

    把最终规格包和证据摘要附到 PR，让评审者能用原始契约对照 diff。

    限制与评审责任

    生成器刻意保持确定性。它不知道你的代码库、发布流程或客户承诺。这不是缺陷，而是设计选择：工具负责给出稳定草稿结构，人类评审者负责补项目判断。把输出当成结构化起点，而不是实现批准。

    使用规格包前，要把占位内容换成具体名称。“运行测试”应该变成命令；“观察指标”应该变成具体 metric 或 dashboard；“不要影响现有用户”应该变成兼容规则、迁移步骤或回滚信号。这些替换动作，才是页面内容和你的项目产生独特价值的地方。

    如果某一项暂时填不出来，不要删除它。把它标记成开放问题，并在实现开始前找到负责人。空字段暴露风险，比假装已经清楚更有价值。

    最适合的使用场景

    小功能但有隐性风险

    当工单看起来简单，却触及数据迁移、金额、权限或公开 API 时，先用规格包收窄范围。

    交给 AI 编码前

    当助手需要一个窄而稳定的事实来源，再开始修改文件时，先生成规格包。

    PR 已经过大时

    当 diff 已经膨胀到难评审时，用规格包重新声明真正要实现的行为。

    什么时候不应该直接用生成结果

    如果需求涉及合规、合同承诺、安全事故、真实用户隐私或线上资金风险，生成结果只能当作草稿结构，不能代替专业评审。你仍然需要让负责人补充内部约束、审批要求和真实证据来源。

    如果团队对目标本身还没有共识，也不要把规格包交给 AI 直接实现。先用它暴露分歧：哪些问题还没答案、哪些风险没有负责人、哪些验收标准无法测试。把这些问题解决之后，规格包才适合进入编码环节。

    从模糊需求到可评审规格包

    弱输入

    优化通知设置。
让它不那么混乱，并支持移动推送。

    规格化输出

    目标：
- 明确邮件、站内信和推送偏好。

非目标：
- 不新增供应商
- 不调整价格

证据：
- 迁移 dry run
- 重复通知测试
- 旧移动端截图

    阅读完整通知迁移案例，或继续看 快速 before/after 改写示例。

    规格包应该用在哪里

    Prompt 之前

    把规格包贴在编码提示词上方，并要求 AI 只实现列出的范围。

    阅读工作流

    PR 里面

    附上验收标准和证据，让评审者能把 diff 和原始契约对照。

    打开评审清单

    作为仓库模板

    把生成文件放进 /docs/specs/，或挂到对应 issue 旁边。

    打开 SDD 模板

    FAQ

    这是 AI 代码生成器吗？

    不是。它生成的是限制 AI 编码范围的规格包。

    会保存输入吗？

    草稿在浏览器本地生成。不要输入密钥或客户隐私数据。

    什么时候可用？

    当评审者能据此拒绝范围膨胀，并用证据验证结果时就可以用。

    编辑说明

    这个浏览器工具作为编辑型实用工具维护。生成内容是草稿，使用它指导实现前仍应复核范围、风险和证据。