让 AI 写代码不难，难的是让 AI 不跑偏：Vibe Coding 的治理问题
一次 63 小时的 AI 长程开发实证给出的结论：Vibe Coding 的瓶颈不在代码生成，而在需求、验证、状态与自证——软件工程是它的第二语法。
说明：本篇是单案例实验记录（n=1），样本与时间窗口的界定见文内实验设定，指标口径定义于姊妹篇另文说明。
当”让 AI 写一个完整项目”变成一句话的事，“能跑起来”这件事本身就不值钱了。演示越来越快，真正的成本却开始后移：三个月后再打开项目，代码还在不在按你当初理解的需求交付？测试有没有人真的跑过？换一个会话窗口，昨天做到哪一步、为什么这么做，还找得回来吗？
这篇文章的核心判断只有一句：**Vibe Coding 缺的从来不是代码生成能力，而是能让它持续下去的软件工程。**这个判断不是推演出来的，它来自一次完整实证：63 小时无人代做的开发、69 次提交、9 个以上任务全部经过独立复审、七道门禁（G0-G6）全部走通——验证的命题正是”Vibe Coding 加上软件工程治理，可以让 AI 长程自主开发可持续迭代的大型项目”。
一、“能跑起来”为什么越来越不值钱
代码生成被十倍加速之后，一个项目的”完成感”来得空前容易：第一天就能跑，第一周就很像样。问题在于，完成感是 AI 最容易伪造、也最容易自我强化的东西。它不会在某天早上主动告诉你：“昨天的实现已经偏离了第一版需求，而且没有任何文件记录这个偏离。”
于是长程项目普遍出现四种病症，每一种都和”生成代码的能力”无关：
- 需求失真：代码默默偏离了已批准的需求，偏离发生时没有信号；
- 验证缺位：测试存在，但从未有人执行；或者根本没有测试，发布凭感觉；
- 状态丢失：换一个会话，全部上下文要靠人脑回忆和口头补充；
- 自证正确：干活的一方宣布”做完了”，而裁判和运动员是同一个人。
这四个瓶颈，恰好对应一套治理体系诊断存量项目时的五个维度：规格完整性（需求到设计到实现到测试是否可追溯）、质量门禁（测试是否真实存在且有人执行）、状态管理（换一个会话能否恢复全部上下文）、变更控制（需求变化是有记录，还是口头推进）、交接能力（关键决策与环境坑是否有档）。更值得警惕的是诊断结论里的一条：“有治理文件但从不维护”比”完全没有治理”更危险，因为它会造成虚假安全感。
二、第一个解法：规格是唯一事实源
对治需求失真的规则只有一句话：“规格是需求、设计、实现、测试和验收的共同事实源。代码不得默默偏离已批准规格；需求变化时，先更新规格与影响分析，再调整代码与测试。”
这条规则真正的分量在它的两半：前半句管代码，后半句管变化。变化本身不是禁忌——体系专门给”需求变更”留了正式通道：任何改变范围、用户行为或验收标准的变化，必须记录变更原因与提出人、受影响的追踪链条（需求/设计/用例/验收编号）、工作量与风险影响、处理结论（本迭代接受、下迭代排期、还是拒绝），最后由人类产品负责人确认。技术实现的等价调整可以由工程经理决定，但必须同步设计与测试，不得改变已批准的产品行为。
换句话说：变更自由，静默犯罪。AI 时代最贵的事故不是写错代码，而是”改了需求没人知道，写偏了没人发现”。
体系同时写明五类必须升级给人类判断的事项：产品范围、交互或验收标准发生变化；隐私、安全、数据丢失风险显著改变；需要新增付费资源、外部账号或不可逆操作；影响迭代目标的关键阻塞；验收结果与用户预期不一致。日常实现细节则不必事事打扰产品负责人——治理与 micromanage 的分界线就在这里。
配套的还有一条纪律：当执行者发现输入不满足进入条件时，任务必须转为阻塞状态，由对应角色补齐，“不得通过默认猜测直接开发”。猜测，是 AI 长程开发最便宜也最危险的行为。
状态层同样有配套规则：项目状态统一为七态（草稿、评审中、批准、进行中、阻塞、待验收、已接受），所有状态变化写进同一份状态文件；新会话冷启动先读这份文件恢复上下文，再按决策表判定当前动作。每次任务交付还必须附上三样东西——变更清单、验证命令或测试结果、未完成项及其风险。目的很明确：让任何一个新会话、任何一个六个月后接手的人，不靠回忆也能把项目接上。
三、第二个解法：给 AI 团队做权力制衡
这套体系的第一段话是：“权力必须制衡——管理者不干活，干活者不自审，产品验收必须由人类拍板。“它展开成五条不可配置的红线：
- 管理角色禁代做：项目经理与研发经理只做计划、协调、指挥、只读审计、门禁和汇报，不得亲自实现需求、设计、代码、测试；“管理者的最终负责永远不替代专业角色的执行”。
- 两道强制人类门禁：需求批准与用户验收必须由人类明确确认；未获批准，不进入正式开发，不进入正式发布。
- 执行与复审分离：执行 Agent 不得复审自己的产物，所有专业产物进门禁前必须由另一名角色独立复审，给出通过或返工的结论及理由。
- 规格是事实源：即上一节。
- 例外必须留痕：紧急止损、时限例外、规格缺失、独立性例外，每一类都要记录触发原因、授权人、影响、补救措施和关闭结论。
七道门禁各有固定产物与批准人：迭代立项记录目标、范围、指标与风险；需求与原型门由人类批准；技术设计、开发完成、系统测试逐道由工程管理人与测试负责人核查 DoD；发布门要求版本、变更日志、回滚方案与复盘齐全。贯穿其间的是一条八层追踪链——产品愿景、需求、原型、设计、任务与代码、测试用例、验收用例、发布版本，后一级必须能追溯到前一级。门禁不是负担，它们让”交付”从形容词变成可核查的名词。
这五条里最容易被低估的是第一条。一个能调用一切资源的管理者，为什么被禁止亲自干活？因为一旦协调者可以”顺手”产出专业产物，复审链条就在最高危处断裂：产物是他写的，门禁是他把的，前文的”自证正确”就原样复活了。所以连例外通道都堵死了——执行者不可用或进度告急时，管理角色”只能重新分派、缩小已批准范围或升级给用户；不得亲自代做专业任务”。管理角色的日常职责被压缩成核对三件事：输入是否满足准入条件、输出是否满足完成判据、证据是否可复现。
而”产品验收必须人类拍板”这条，在体系设计时甚至被写成了问卷界面上的红线：批准角色必须由人类担任——AI 不得自我批准产品范围。理由朴素得近乎残酷：AI 生成内容的”完成度”判断，本身就是被评估对象的一部分。
四、出错是常态：体系不容忍的是掩盖
治理体系对”AI 会出错”的态度，全部藏在几个不起眼的机制里。
缺陷分四级：阻断、严重、一般、轻微；发布标准写着”安全、数据丢失和核心幂等缺陷不得豁免”——这三类问题不允许用”风险可控”话术放行。
例外规则的开篇就立了规矩：“不得以紧急为由跳过人类的批准权限。“紧急状态允许管理层做的只有暂停、回滚、留证据；恢复实施仍须重新分派给专业角色。例外留痕也不是一句态度，而是固定格式：编号、类型、触发时间与原因、授权人、影响范围、补救与复审期限、关闭结论，随迭代归档——可追溯是被格式逼出来的。
每道门禁有固定的产物和批准人，而且通用化时留下了一条明确判断：角色可以按项目裁剪，门禁链不可裁剪——没有测试角色，系统测试这道门照样必须由某个独立角色把住，否则这道门禁就名存实亡。
这些规则共同回答一个问题：为什么长程项目失败？多数时候不是因为 AI 不干活，而是因为出错之后，没有一个人或一个机制肯把问题摆到桌面上来。体系的本质，是给”不体面的失败”预铺一条有档可查的收口路径。
五、体系的第二次落地：这个网站自己
如果说上面的一切还来自”一个自托管播报/报表类项目”的 63 小时实证，那么此刻你访问的这个网站，是同一套体系的第二次落地——规格、复审、门禁，全部公开在这个仓库里，可以直接翻。
网站建设分迭代推进：每个迭代从立项记录开始（目标、范围、成功指标、风险），产品规格起草后交独立复审，复审给出带定位、带证据的结论，执行者逐项修复，最后由人类批准进入下一阶段。第一个迭代如此，第二个迭代也如此。第一个迭代的复审甚至是用命令核证的——对草案里”多少行、多少条、字段是否全覆盖”这类统计声明逐项实测，连一条不实的自检表述也被点名要求改实。数字不会替谁圆场，这正是独立复审的威慑所在。
一个活例子比流程描述更能说明”执行与复审分离”的价值：第二个迭代的内容规格里，有一条写法会把第一个迭代已经冻结并验证过的门禁行为事实上放宽——复审在核查时发现了这一点，要求拆成两态：引用目标不存在，维持构建错误不动；目标存在但未公开，才允许前台隐藏加告警。一处措辞的修正，保住的是一条已经立住的防线。这不是流程仪式，是独立视角真的咬合了一次。
甚至你正在读的这篇文章，也走的是同一个循环：素材指定、角度建议包、人类拍板、按”无源不写”起草、等待复核签署。它谈论治理，同时是治理的产物。
六、结语：软件工程是 Vibe Coding 的第二语法
回到标题。“Vibe Coding 真正的问题不是代码生成，而是软件工程”——因为代码生成这一极已经被模型能力解决了大半，而另一极没人替你解决：需求不失真、验证不缺席、状态不丢失、完成不自证。
63 小时与 69 次提交证明的不是”AI 开发有多快”，而是”治理之下的 AI 开发有多可持续”。让 AI 写代码，是 Vibe Coding 的第一门语法；让一千行之后、一百个会话之后，项目仍然按你批准过的规格交付，才是决定生死的第二门。
前者决定你能不能开始，后者决定你能不能继续。
溯源表（发布随稿，入仓时转内部工件；每条实质性论断 → 素材出处）
素材编号：C3-SRC-01=skill SKILL.md；02=references/workflow.md；03=references/task-order.md；04=references/definition-of-done.md；05=references/exceptions.md；06=references/remediation-playbook.md；07=技术方案 HTML；12=C3 建议包（角度与框架经 PO 拍板）；REPO-01=S1 门禁链文件（G0-ITERATION-S1、TASK-S1-002_REVIEW、S1 G1-GATE-RECORD、PRD v1.1）；REPO-02=S2 门禁链文件（G0-ITERATION-S2、G1-GATE-RECORD、TASK-S2-002_REVIEW）。
| # | 实质性论断 | 类型 | 出处 | 状态 |
|---|---|---|---|---|
| 1 | 核心命题”Vibe Coding+治理使 AI 长程自主开发可持续迭代大型项目” | 观点 | 01 正文¶2 | 有源 |
| 2 | 63 小时/69 提交/9+ 任务全独立复审/G0-G6 全走通 | 数据 | 01 metadata.provenance+正文¶2 | 有源 |
| 3 | 四病症框架（需求失真/验证缺位/状态丢失/自证正确）及与五维诊断的对应 | 观点 | 06 评估五维逐条；01 宪法¶1”权力制衡”三句（自证正确）；PO 拍板建议包角度 A 框架（12） | 有源 |
| 4 | “有治理文件但从不维护比没有更危险（虚假安全感）” | 观点 | 06 成熟度分级 L2 判定注 | 有源 |
| 5 | “规格是唯一事实源……先更新规格再调整代码”引文 | 数据(规则原文) | 02 §1；01 宪法 4 | 有源 |
| 6 | G1 基线后变更管理四要素+PO 确认+EM 不得改已批准产品行为 | 数据(制度) | 02 §6 | 有源 |
| 7 | “不得通过默认猜测直接开发”（Blocked 纪律） | 数据(规则原文) | 05 例外 3；01 宪法 4 括注；03 状态机 | 有源 |
| 8 | 宪法五条逐条内容 | 数据(制度) | 01 §宪法；五条与 07 §01 宪法层列表互证 | 有源 |
| 9 | 紧急时管理角色”只能重新分派、缩小已批准范围或升级，不得亲自代做” | 数据(规则原文) | 05 例外 2 | 有源 |
| 10 | PM/EM 只核对三件事（DoR/完成判据/证据可复现） | 数据(制度) | 03 交付核对 | 有源 |
| 11 | “AI 不得自我批准产品范围”（问卷界面红线） | 数据(制度) | 07 §03 两条不可配置红线 | 有源 |
| 12 | 缺陷四级+安全/数据丢失/幂等不得豁免 | 数据(制度) | 04 缺陷分级表 | 有源 |
| 13 | “不得以紧急为由跳过 PO 的 G1/G5 批准权限”；恢复实施须重新分派 | 数据(规则原文) | 05 引言与例外 1 | 有源 |
| 14 | “角色可裁、门禁不裁” | 数据(决策) | 07 §10 决策 #10 | 有源 |
| 15 | 6v1 站点两迭代按 G0→起草→独立复审→修订→人类批准推进、记录公开可查 | 案例 | REPO-01、REPO-02（门禁与复审文件均在仓库） | 有源(PO④授权) |
| 16 | 活例子：S2 复审发现对 S1 冻结门禁行为的事实放宽，要求拆两态修正 | 案例 | REPO-02 中 TASK-S2-002_REVIEW P-4（S2） | 有源(PO④授权) |
| 17 | 本文自身走”建议包→拍板→溯源起草→待签署”循环 | 数据(流程) | TASK-S2-003 §0 逐篇 loop + 本仓草稿工件 | 有源(PO④授权) |
| 18 | 第一节”完成感/偏离无信号”等开场现象描述 | 修辞铺垫 | 不含”我曾遇到”案例句式与可核查事实断言 | 不适用（非实质论断） |
| 19 | “治理=为不体面的失败预铺收口路径""猜测是最便宜也最危险的行为”等评语句 | 观点(规则解读) | 由 7/9/12/13 各规则文本归纳，无新增事实 | 有源-解读，PO 签署时核口径 |
| 20 | 五类必须升级人类判断的事项 | 数据(制度) | 02 §2 | 有源 |
| 21 | 状态七态、状态文件唯一事实源、冷启动先读状态再判定动作 | 数据(制度) | 02 §8；01 模式判定 | 有源 |
| 22 | 任务交付三件套（变更清单/验证证据/未完成项） | 数据(制度) | 03 交付核对 | 有源 |
| 23 | 门禁产物与批准人概览、八层追踪链 | 数据(制度) | 02 §3、§4 表 | 有源 |
| 24 | 例外记录固定格式与归档位置 | 数据(制度) | 05 记录格式节 | 有源 |
| 25 | S1 复审以命令核证统计声明、点名不实自检表述并修正 | 案例 | REPO-01（TASK-S1-002_REVIEW 维度四/六） | 有源(PO④授权) |