我的 Vibe Coding 工程化体系：从需求到上线

姊妹篇《让 AI 写代码不难，难的是让 AI 不跑偏：Vibe Coding 的治理问题》讲了为什么：AI 把代码生产加速十倍之后，真正的瓶颈搬到了软件工程一侧——需求失真、验证缺位、状态丢失、自证正确。这一篇是操作层手册：从需求到上线，一共七步，每步给目的、输入、动作清单、产出物模板片段和常见失败模式。

先立三条总则，它们贯穿所有步骤：规格是唯一事实源（代码不得默默偏离已批准的规格）；人守两道门（需求批准与最终验收必须由人类拍板）；干活的不自审（每个产物由另一个角色独立复审后才能进下一关）。七步与治理门禁的对应关系：

text

立项(G0) → 需求与规格(G1·人类批准) → 设计(G2) → 开发(G3) → 测试(G4) → 验收(G5·人类) → 发布与复盘(G6)

第零步：立项——把”想法”压成”一个可验收的迭代”

目的：七步之前还有一步。它负责把一个发散的念头压缩成一次能走完闭环的交付：范围小到几个工作日内可完成，而且是纵向切片——从需求到能验收，一刀切穿，而不是先把某一横层全部铺完。

输入：上一轮复盘的遗留清单、闭环里沉淀的数据（哪些失败高频、哪些问题值得做）、你原本的想法。

动作清单：

• 迭代目标收敛成一句话；说不清目标，说明还没想清；
• 范围与非范围成对出现，非范围逐项写”为什么不做”；
• 成功指标直接写成门禁判据：“构建零错误""四篇内容过校验与扫描并入库”——每条都可勾选，杜绝”进展顺利”式指标；
• 风险表逐行配应对措施与升级路径（谁、在什么信号下、上报给谁）；
• 任务拆分标注前置依赖，形成甘特可排的顺序。

产出物模板：

text

迭代立项卡：目标｜范围（纵向切片）｜非范围｜成功指标=Gate 判据
｜风险×应对表｜任务拆分×前置

常见失败模式：多条线并行、条条收不了口；成功指标是形容词不是判据；“风险”一栏写”注意质量”等于没写。

第一步：需求——先证明”有人要”，再讨论”怎么做”

目的：把”我觉得该做”变成”有证据该做”。Vibe Coding 最大的浪费不是写错代码，而是用十倍的生产力写出了没人要的东西——优化商业反馈速度，永远优先于优化代码产量。

输入：用户反馈（原话比转述可信）；真实任务记录（做过什么、哪里卡住）；反复出现的问题（同类问题第三次出现，就是产品信号）；商业验证的最小问题（例如”是否有陌生人为这个能力付费”）。后两类尤其诚实——它们不产生”听起来不错”的需求，只产生”必须解决”的需求。

动作清单：

• 每条需求写清来源证据（谁的反馈/哪次任务/哪个数据），无来源的先标”假设”；
• 给优先级：P0（本迭代必须）/P1（应该）/P2（可选），并准备把 P2 说”不”；
• 明确目标用户是谁、不是什么（本站的取舍：优先服务不熟悉软件工程流程的超级个体、小型工作室与创业团队，而不是大厂平台团队）；
• 写一句”本迭代不做什么”清单——和做什么同等重要；
• 单迭代目标收敛为一句话，超出即拆分。

产出物模板：

text

立项卡：目标（一句话）｜范围｜非范围｜成功指标｜风险｜任务拆分

常见失败模式：需求以技术兴奋开头（“我想试试某框架”）而非问题开头；“非范围”缺失，边界全靠临场默契；一个迭代塞五个目标，最后零个完成。

第二步：规格——每条需求都必须”可验收”才允许开工

目的：把需求翻译成可以打勾的承诺，而不是方向感。

输入：第一步的立项卡。

动作清单（每条需求进技术设计前的就绪检查，九条）：

• 有唯一编号、用户价值和优先级；
• 明确范围与非范围；
• 正常、异常、边界三类流程都写清；
• 验收标准可验证，禁止”体验良好”式主观词；
• 关联页面、状态与原型；
• 有输入输出示例和数据长度约束；
• 数据、安全、隐私、兼容性约束明确；
• 外部依赖、风险和开放问题有结论或责任人；
• 人类产品负责人明确批准——任何核心项缺失，需求不得进入技术设计。

产出物模板：

text

REQ-XX-001 《标题》
用户价值：…  优先级：P0
范围：…  非范围：…
验收标准：1. …（每条可测）
开放问题：OQ-x（责任人/是否阻塞）

常见失败模式：验收标准写成形容词（“快速""稳定”）——测试时无从下刀；变更不回流规格（改了代码没改文档），规格失去事实源地位；开放问题靠口头共识”记得差不多就行”；输入不齐就硬开工——规格缺失的唯一合法回应是转”阻塞”并补齐，猜测是它最危险的替身。

第三步：设计——四问过关，决策留痕

目的：在写代码之前，证明”可实现、可测试、可部署、可回滚”四件事都成立。

输入：冻结的规格。

动作清单：

• 技术选型按”先简单后扩展”：没有真实需求不上队列、不为几十篇内容建大型检索平台、MVP 不上重型编排——每个”暂时不做”都写进设计，防止手痒；
• 每个有争议的选择出一页决策记录（ADR）：背景/决策/后果/被否的备选，只记为什么；
• 设计评审输出物检查：数据结构、接口契约、测试计划要点、回滚路径；
• 规格里留了钩子的（如”为 API 预留结构但第一版不实现”），设计必须显式回答”预留方式”；
• 数据访问顺序先立规矩：先做访问控制，再做检索与生成——不能先把全部内容取回来，再让模型决定哪些能展示。

产出物模板：

text

ADR-0001 标题
状态：Accepted｜决策人｜上游依据
背景 → 决策（一句话）→ 后果（正面/风险/缓解）→ 备选（为何否）

常见失败模式：设计文档变成选型愿望清单；重大决定散落在会话记录里，两周后没人记得为什么；为未来想象做架构（“以后要上千万用户”），为当下引入十倍复杂度。

第四步：开发——任务单先行，边界先于生产力

目的：让每一次 AI 执行都发生在明确的授权范围内，产出可追溯。

输入：设计基线 + 就绪的验收标准。

动作清单（子任务分派前必建任务单，核心要素十一项，缺一即视为未授权开工）：

• 编号/角色/目标与边界（明确不做什么）/输入/输出/完成判据/风险与升级路径/独立复审人/状态机/模型档位（按任务难度分级，默认低配，升级留痕）；
• 提交信息与任务编号关联，任何产物可反查到它服务的规格；
• 执行者交付时附三件套：变更清单、验证命令或测试结果、未完成项及风险；
• 协调角色只核对三件事：输入是否就绪、输出是否满足判据、证据是否可复现——协调者不得亲自代做专业产物；
• 执行者的输出是候选产物，经另一名角色独立复审（通过/返工，带理由）才进下一关；
• 返工有上限：连续多轮复审不过就升级给人裁决，不让 AI 与 AI 的循环烧掉整个排期。

产出物模板：

text

TASK-XX-00N 执行报告
0 任务单（十一要素）  1 已实现  2 自动化证据  3 实机证据
4 测试追踪  5 变更与未完成  6 独立复审结论

常见失败模式：不写边界——AI 的十倍生产力立刻溢出到你没要求的地方；“管理者顺手就写了”——复审链在最危险处断裂；口头”完成了”没有命令级证据，下一环无法核对。

第五步：测试——质量门禁不考”测没测过”，考”能不能证明”

目的：把”我看没问题”换成第三方可复现的证据。

输入：设计阶段同步产出的测试计划与用例。

动作清单：

• 每条需求的用例至少覆盖正向、异常、边界三类；
• 每条结论附可复现证据：命令 + 输出（截图留档），“我在本地跑过”不算数；
• 缺陷按四级分级管理：阻断/严重/一般/轻微——阻断与严重必须修复，一般延期需书面批准，轻微可进待办；安全、数据丢失、核心幂等类问题一律不得豁免；
• 机器可读与回归项每次全跑：构建零错误（元数据缺一个必填字段也算错）、结构化收录（新页面必须出现在 feed 与站点图中）、敏感信息扫描（红线词零命中）、可访问性自动检查零严重违例；
• 测试角色不得为了让测试通过而修改产品范围；
• 需求级”完成”之上还有迭代级”完成”：范围内需求全部达标、自动化全绿、无未关闭高危缺陷与未经批准的中危延期、发布说明与回滚说明齐备——五者缺一，迭代不宣布完成。

产出物模板：

text

测试报告摘要：用例 N 条｜通过 x｜失败 y（缺陷编号+级别）
阻塞项：无｜豁免项：（编号+批准记录）｜证据：命令/日志位置

常见失败模式：测试存在但从未运行（比没有测试更危险，制造虚假安全感）；用豁免清零缺陷；把”自动化测试通过”当质量本身，而不是当证据。

第六步：验收——AI 觉得完成不算完成

目的：在真实环境里，由人类确认”这确实是我要的东西”。

输入：候选版本 + 逐条对应验收标准的验收清单。

动作清单：

• 在真实运行环境（不是演示环境）逐条执行验收清单，每条记录”标准原文 → 实际结果 → 结论”；
• 有条件接受时，把条件、责任人和关闭期限写进记录——“先上线再说”不被允许；
• 允许人类在验收中改主意，但改动走变更控制回流规格，不允许静默改需求；
• 紧急deadline不构成跳过人类验收的理由。

产出物模板：

text

UAT-XX-00N：验收人（人类）｜环境｜清单勾选｜
结论：明确接受 / 有条件接受（条件：… 关闭期限：…）｜日期

常见失败模式：开发者自宣验收通过；UAT 变成”演示一遍没报错”；结果与用户预期不一致时，改验收标准而不是改产品。

一个本站的活例：这里的每一篇内容文章，发布前都走同一种验收——人类逐篇通读、在签署区留下意见与日期，签署记录是元数据里”人工已复核”字段置真的唯一前置条件；“允许发布”另需一次书面确认并留档。验收从来不只属于软件：知识资产的验收单位是”这条判断确实出自并认可于那个人”。

第七步：发布与复盘——发布是动作，复盘是燃料

目的：可回滚地交付，并让每一次发布变成下一轮需求的输入。

输入：验收通过的候选版本。

动作清单：

• 发布四件套：版本号与变更日志、回滚方案、验证步骤、遗留项归档（每条遗留带编号、级别、目标版本与批准记录）；
• 发布后验证：线上抽查关键路径，确认与验收环境一致；
• 每次运行留完整追踪数据——用了哪个能力与版本、耗时、token 成本、成功与否、人工介入点、用户反馈、产物的保留期限。字段可以精简，但每项运行都要有：否则”后台四问”没有证据可答——哪个能力有人用？哪些任务经常失败？哪个环节最贵？哪些问题值得写成下一篇文章？
• 复盘产出的每个”又是我手动兜底”的环节，回答一句：**这件事下次能不能让流程、工具或 Agent 完成八成？**答”能”的，进能力化待办；
• 实践结果回流内容：真实任务 → 文章或手册 → 清单/模板/评测用例 → 能力——这就是知识资产化的生产线。

产出物模板：

text

Release v0.x：变更｜回滚点｜验证记录｜复盘（做得好/踩坑/
下轮改进【含 80% 产品化候选】）｜Backlog 更新

常见失败模式：只发版不记录，两周后说不清改了什么；复盘写成情绪总结；运行数据丢弃，下一轮需求又回到”我觉得”。

附：一页速查与工件的家

步骤	一句话目的	核心产物	门禁
0 立项	想法压成可验收切片	立项卡	G0
1 需求	每条需求有来源证据	带优先级与边界的条目	—
2 规格	“完成”写成可打勾的承诺	PRD/REQ 条目	G1（人类）
3 设计	四问过关、决策留痕	设计文档 + ADR	G2
4 开发	有边界地执行	任务单 + 可复现证据	G3
5 测试	把”没问题”换成”可证明”	测试报告 + 缺陷分级	G4
6 验收	人类真实环境拍板	验收/签署记录	G5（人类）
7 发布复盘	可回滚交付，复盘变燃料	版本 + 回滚 + 待办归档	G6

这些产物还要有家：流程宪法与就绪/完成定义放治理目录；立项卡、规格、任务单与复审结论按迭代归档；决策记录单独一处；再加一份项目状态文件作为单一事实源——任何新会话先读它恢复上下文，再决定当前动作。文档不求多，求的是”找不到=没发生过”这一条纪律成立。

这套体系怎么长大

七步不是仪式。它的全部价值在于让判断可以被复读：一次人工审查过的代码风险，变成清单；清单跑熟了，变成工具；工具稳定了，变成能力；能力的每次运行又产生新数据。人工咨询与交付只是需求发现和训练数据的来源，不是终态——目标是让曾经只能做一次的判断，逐渐能稳定做一万次。

所以这份手册本身也标注版本与状态：实验版（experimental），意味着它预期会被自己的第七步反哺修订。你在用的每一个流程，都要经得起”发布后台四问”的检验——经不起的，就是流程在替你撒谎。

---

溯源表（发布随稿；每条实质性论断 → 素材出处）

编号：C4-SRC-01=总纲 十五章（15.1 冻结范围与基础能力/15.2 明确不做）；02=总纲 十六章（第 4/8/9/10 条）；03=总纲 十章（10.2 技术栈原则列）；04=总纲 十章（10.4 先访问控制再检索/10.5 可观测字段与后台四问）+十一章（预留结构）；05=治理体系参考文件（门禁链 G0-G6 与批准人/就绪九条/完成定义与缺陷分级/任务单十要素与交付核对/例外与复审规则/诊断五维）；06=本站公开工件（S1 PRD 任务单结构、S2 门禁记录与草稿流水线）；07=问题解答 CSV 第 7 答（第一用户口径）；08=总纲 八章 8.4（80% 产品化反问）+七章 7.2（内容生产顺序）。

#	论断	类型	出处	状态
1	三条总则（规格事实源/人守两道门/干活的不自审）	数据(制度)	05 宪法五则；01	有源
2	立项+七步与 G0-G6 映射（需求与规格归 G1）	观点(本文编排)	05 门禁表逐行归纳；已标注为本文映射	有源-解读
3	“用十倍生产力写十倍没人需要的代码/优化商业反馈速度”	观点(引文)	02 第 8 条	有源
4	目标用户=不熟悉软件工程流程的超级个体/小工作室/创业团队	数据(定位)	07；与 S1 路由表登记口径同源	有源
5	立项卡五要素（目标/范围/非范围/指标/风险）	数据(制度)	05 G0 必需产物	有源
6	“非范围清单与做什么同等重要”	观点(归纳)	01（15.2”第一版明确不做”以清单为正式工件的先例）	有源-解读
7	就绪检查九条全文要点	数据(制度)	05 就绪定义”需求进入技术设计”	有源
8	“核心项缺失不得进技术设计”/“不得以紧急为由跳过人类批准”	数据(规则原文)	05 就绪定义引言/例外规则引言	有源
9	变更须记录原因/影响/结论并经 PO 确认	数据(制度)	05 变更控制节	有源
10	设计四问（可实现/可测试/可部署/可回滚）	数据(制度)	05 门禁表 G2 通过条件	有源
11	ADR 结构与”下游不得悄然改方向”纪律	数据(制度)	05 编号规范（ADR 全局）；01（总纲文档规则句：冲突先更新总纲或记录 ADR）	有源
12	先简单后扩展三例（队列/检索平台/重型编排不上）	数据(制度)	03 原则列；01 §15.2（不上 K8s 等）	有源
13	“为 API/MCP/A2A 预留结构但不全实现”的预留回答义务	数据(基线)	01 §15.1 末条；04	有源
14	任务单十一要素与”缺要素=未授权开工”	数据+解读	05 任务单十要素+模型档位（合并为本文十一项清单）；“未授权”为本文强调表述	有源-解读，PO 核
15	提交-编号关联、八层追踪链精神	数据(制度)	05 编号规范	有源
16	交付三件套；协调角色三核对、禁代做	数据(制度)	05 交付核对/宪法 1	有源
17	候选产物+独立复审 Approved/Rework	数据(制度)	05 复审与门禁节	有源
18	模型按难度分级、默认低配、升级留痕	数据(制度)	05 子 Agent 规则	有源
19	用例三类覆盖；证据可复现	数据(制度)	05 完成定义（正向/异常/边界；证据更新）	有源
20	缺陷四级+豁免规则+“测试角色不得改范围让测试通过”	数据(制度)	05 缺陷分级表/子 Agent 规则	有源
21	机器可读回归项（构建零错误/收录/敏感扫描/可访问性）	数据(实践)	06（本站门禁判据与红线扫描工件）	有源
22	验收清单”标准→结果→结论”、有条件接受记录条件、明确接受方可发布	数据(制度)	05 门禁表 G5 行	有源
23	发布四件套与遗留项进待办	数据(制度)	05 门禁表 G6 行/完成定义迭代部分	有源
24	运行追踪字段与”后台四问”	数据(制度)	04 可观测性节	有源
25	80% 产品化反问；咨询是训练数据不是终态	观点(引文)	08 §8.4	有源
26	内容生产顺序链（实践→文章→清单/模板/用例→能力）	数据(制度)	08 §7.2 图	有源
27	“测试存在但从未运行比没有更危险（虚假安全感）”	观点(引文)	05 诊断成熟度 L2 判定	有源
28	“本文自身可被第七步反哺修订”（版本/状态标注的理由）	观点(归纳)	08 生产顺序；schema status 机制 06	有源-解读
29	第零步立项（一句话目标/纵向切片/指标即判据/风险×应对/依赖）	数据+实践	05 门禁表 G0 行；06（本站两份立项卡实形态）	有源
30	先访问控制再检索	数据(规则原文)	04 §10.4	有源
31	返工超数上限即升级	数据+泛化	06（S1 风险表”两轮不过升级”→本文泛化为”连续多轮”）	有源
32	迭代级完成五条件	数据(制度)	05 完成定义·迭代完成节	有源
33	内容验收活例（签署=复核字段唯一前置；发布另需书面确认）	案例	06（本站 loop-⑤ 与元数据纪律）	有源
34	工件归档布局与状态文件单一事实源、冷启动先读	数据(制度)	05 状态与交接规则；06（仓库结构实见）	有源
35	回改记录（2026-09-12）：首段平台互链”上一篇”改站内链接（REQ-S2-001 步骤 2 负向词修复）；summary 去除内部代号”见 C3”（公开口径化）	过程(修订)	终局复跑 FAIL-1 / 观察 O-F3	已改，PO 复签于 2026-09-12（复签轮）
G1	各步的”我的真实翻车实例”	案例	无素材（PO 授权跳过建议包轮，个人案例未提供）	待 PO 补（K1-K5）
G2	具体工具/模型/平台点名	—	一律泛化为类别词（PO③ 口径）	不适用