文档驱动标准化开发流程

很多项目不是死于写不出来，而是死于「先写代码、回头补文档」：设计在脑子里，接口在嘴上，修 bug 时不知道动了哪块老功能，交付时只甩一份源码让用户自己打包。这个技能把开发流程拆成可门禁的文档链，用规则强制每一环过完再进下一环。

它解决什么

• 文档与实现分叉：代码已经写完，PRD 还停在 v1.0。技能的第一条铁律是文档先行，发现「代码有了、文档没了」必须立刻停手补齐。
• 关联回归遗漏：改了登录态，却没发现支付页依赖同一个 token。测试阶段必须按 diff 检索历史版本文档，列出关联影响清单逐项回归。
• 交付物不可用：npm run build 的产物没打出来，用户拿到源码还得自己配环境。技能要求交付构建产物、安装包或可直接导入的目录。
• 版本号通胀：改个按钮就升 v2.0，旧文档对照失效。只有 UI 或功能大规模升级才升大版本，且必须经用户确认，其余一律 v1.0.1 式小版本。

两种模式，一条主线

模式 A（完整流程）适用于新项目或涉及 3 个以上模块的新功能，九个阶段依次推进：调研 → PRD → 交互文档 → HTML 原型 → 系统设计 → 编码 → 功能测试 → UI 测试 → 人机交互校验 → 交付打包。每个阶段有明确产出物和门禁，上一阶段未确认不得进入下一阶段。其中 HTML 原型是视觉基准，确认冻结后编码需 1:1 还原，有偏差即记缺陷。

模式 B（快速通道）适用于迭代、bug 修复、小调整：先用 2~3 句话写清「改什么、为什么、影响哪些模块」，然后定位修改、验证、同步文档、交付。零确认门禁，只在三类情况下停下来问：会删除或覆盖用户数据、方案代价高且差异巨大、版本控制检查需要用户决策。

两种模式共用五条铁律，外加一套 git 规则：init、commit、tag 默认都要过用户门禁，项目没有版本控制时不擅自引入。tag 名与文档版本号硬性绑定，docs/v1.0 对应 tag v1.0，禁止文档已到 v1.2 而仓库没有 tag。

适用边界

以下任务不触发该流程：纯问答、调研、写作；一次性临时脚本；数据分析、表格处理等不产出代码的任务；只改配置或文案且无功能行为变化的改动。边界模糊时按一个判断标准——是否产出需要测试和交付的代码，是就走流程，否就不走。

另外，references 下的模板与清单仅供模式 A 按阶段读取，模式 B 一个都不读。想先看完整流程长什么样，可以读 references/10-walkthrough-example.md。