1. 先看看“氛围编程”翻车现场：代码雪崩到底从哪儿开始
先说明一下，我这里的“氛围编程”不是贬低任何人，我也天天用 AI 编程助手写代码。但你必须承认，很多人已经把“让模型自动写代码”当成了默认工作方式：需求丢进去，代码出来，复制粘贴，提交。一开始确实爽，代码产出速度快得惊人。可再过两三周，你会发现系统开始到处出问题——改一个接口，十个调用方全挂；修一个 bug，旁边又炸出两个；老代码没人敢动，新代码没人看得懂。这就是典型的代码雪崩。
我自己接过不少这类项目，翻车项目的共同点出奇一致：没有可验证的边界，没有测试契约，AI 生成的代码在无限堆叠。换句话说，大家缺的不是“AI 写代码的能力”，而是“让 AI 按工程纪律干活”的一整套闭环。这也是我为什么一直建议不要在裸奔状态下使用 AI 编程助手。要真想避免雪崩，必须引入三样东西：一套能约束模型行为的技能框架、一份先写测试再写实现的契约协议、以及一条从生成到上线的工程纪律闭环。这三件事合在一起，基本上就是我们从“会聊天的助手”变成“能干活的队友”的分水岭。
1.1 氛围编程的爽感，是怎么一步步变成危机的
先说爽感从哪来。你只要描述清楚“我要一个订单模块，包含列表、详情、状态流转”，模型就能像变魔术一样把主体代码铺出来。省掉的不只是打字时间，还有“从零搭建目录结构”的精神消耗。问题在于，人的大脑很容易把“代码生成出来”误判成“需求已经完成”。生成出来的代码是好是坏，边界全不全，异常处理对不对，副作用会不会污染全局状态——这些信息不会自己冒出来，你得主动验证。
而“氛围编程”的典型路径是跳过验证。需求描述越模糊，模型自由度越大，它就会越“自信”地填补细节。比如你说“做个用户状态字段”，它可能默认用字符串、也可能用枚举、还可能用布尔值，每一步都在替你拍板。单个代码片段里的隐性决策是少数，但成百上千个片段叠在一起，系统里就充满了“模型自认为合理”的假设。这些假设彼此之间没有对齐，等到联调、回归、上线后出问题，就是雪崩式的连锁故障。
我之前做过一个内部小项目，A 同事让 AI 生成的数据访问层用了悲观锁，B 同事在同一张表上生成的更新逻辑用的是乐观锁，两边代码都能跑，但跑起来要么死锁要么覆盖更新。最后查了整整两天。你说这是谁的错？不是模型的错，是没有人给模型一个统一的契约。氛围编程并不必然导致雪崩，导致雪崩的是“没有契约的氛围编程”。
1.2 代码雪崩的四种典型形态
我把实际踩过的雪崩归纳成四类。
第一类叫“一次性功能雪崩”。AI 生成的代码只针对当前诉求，扩展性极差，完成后就被弃养，等下一次需求要改它时，改造代价比重写还大。
第二类叫“脆弱依赖雪崩”。生成的模块之间依赖关系非常随意，A 模块直接读 B 模块的私有状态，跨层调用到处都是，改 B 的内部实现，A 毫无感知地崩掉。
第三类叫“测试真空雪崩”。项目看起来有测试文件，但测试全是模型生成后自己跑了几遍“绿了”的测试，断言弱、覆盖低、边界全无。这类测试在重构时非但不能保护你，反而会因为“假绿”给你虚假安全感。
第四类叫“生成不确定性雪崩”。同一个模型、同一套提示词，你过两天再跑一次，生成结果可能完全不一样。今天能用，下周就编译不过，团队里谁都不敢动那些“只有模型知道怎么生成”的代码。
这四类问题的共同根源，是缺少三层防线：技能框架约束模型的行动路径，TDD 契约驱动约束代码的语义边界，工程纪律闭环约束提交和合入的流程。下面一个一个拆。
2. Superpowers 技能框架到底是什么：把“会聊天”变成“按流程干活”
很多开发者第一次看到“技能框架”这个词，以为是什么新插件、新 IDE 工具，或者某种提示词模板合集。我最初也以为差不多，但真正用下来之后，我认为它更像是一份“给模型看的岗位说明书 + 操作流程手册”。
传统提示词的问题在于，它是“单次聊天”的上下文，用完即弃。技能框架则是把一段完整的做事方法论固化下来，让模型在每次接到任务时都知道：我现在处于哪个阶段、该看哪些材料、按什么顺序执行、每个步骤有什么验收标准。它不是教模型写某段代码，而是教模型“如何在一个受控流程里完成开发任务”。
2.1 技能不是插件，是操作说明书
我举个例子。假设你想让模型帮你做“代码审查”。普通用法是直接说“帮我 review 一下这段代码”。模型会基于当前窗口里的代码给一堆泛泛而谈的意见：注意边界、考虑空值、加日志——说了等于没说。原因是它没有一套固定的审查流程，它只是在对你的提问做“最像样的回答”。
但如果你给它一个“代码审查技能”，这个技能内部会定义：先读变更说明，再读关联测试，然后逐文件分析风险点，最后按照严重程度输出结构化结论。每一条规则都写得清清楚楚，模型不遵循流程就继续追问。你会发现输出质量立刻不一样：它会主动去找调用关系，去看测试是否覆盖契约，会指出“你这里改了语义但没改文档”这种上下文一致性问题。
这类技能，本质上就是给模型装上了一个“领域内的工作流大脑”。比如 Superpowers 技能框架，它的核心做法是把项目里的技能文件收集起来，每个文件都包含技能描述、适用场景、执行步骤、input/output 格式以及失败时的处理策略。当用户提出需求时，框架不是直接让模型“开写”，而是先匹配技能，再按技能里的流程一步步执行。它就相当于把老师傅的操作经验转写成了机器可读的作业指导书。
2.2 技能框架的三个核心部件
一个成熟的技能框架，至少要包含三样东西。
第一是“技能元信息”。它描述技能的名称、适用场景、触发条件、职责边界。元信息的作用是让模型在拿到任务的一瞬间能回答“这个任务该不该用这个技能处理”。没有元信息，模型会把“写订单模块”和“修订单 bug”混在同一套流程里，效果自然差。
第二是“执行子步骤”。一个技能不是一句话，而是一串有先后顺序的动作。比如“新增业务逻辑”这个技能，它的子步骤可能是：读取契约文件→查找相关测试→运行测试确认现状→生成最小实现→运行测试验证→按规范整理代码。每一步都要有明确的出口准则。
第三是“校验与兜底规则”。模型执行完子步骤后，技能要规定如何自检。比如“没有跑通测试就不能宣称完成”“输出代码必须包含边界条件处理”“涉及外部系统必须标注假设”。这些规则就是把人的工程常识翻译成机器的硬性纪律。
从我落地项目的经验看，大多数团队缺的不是第一条和第二条，而是第三条。模型非常擅长“自我感觉良好地交付”，而没有兜底规则的技能框架，只是个更精致的提示词集合。
2.3 技能框架是如何拉住“手滑的模型”的
我一直觉得，AI 编程最大的问题不是“它不会”，而是“它太会顺着你的话往下说”。你问“这个逻辑能不能用缓存”，它会回答能，并且顺手把缓存代码写出来；你再问“那要不要考虑一致性”，它又会说确实要考虑，马上再改一版。这种“讨好式生成”在单轮对话里害处不大，但在持续开发中会不断累积出前后矛盾的设计。
技能框架通过两个机制拉住这种手滑。第一个机制是“限定入口”：任务必须进入技能约定的流程，不能自由发挥。比如技能规定“先补测试，再写实现”，模型就不能倒过来。第二个机制是“明确出口”：技能规定完成标准，模型只有在满足标准时才能输出“完成”。否则它会继续自问自答、继续改代码。
有朋友问我，模型不遵守技能怎么办？答案很简单：给框架增加“硬校验节点”——不是靠提示词让模型自律，而是在流程里安排真实的工具调用。例如在代码生成后，框架调用测试命令、静态检查命令、覆盖率命令，拿真实反馈来打断模型的“自嗨循环”。这就是把 AI 从“聊伴”变成“执行器”的关键一步。
2.4 最小技能库怎么搭
自己搭技能框架并不需要多高深的基础。我建议从一个小仓库开始，目录长这样：
skills/ review/ SKILL.md steps/ templates/ feature/ SKILL.md steps/ fix-bug/ SKILL.md steps/每个SKILL.md开头写元信息，后面写执行流程，再写验收标准。例如fix-bug技能的执行流程，我会写成：复现现场→定位根因→写一条失败的回归测试→修改代码→运行全部测试→提交关联说明。
这里有个非常重要的细节：技能文件里的每一步，都要写成“可以用工具或命令验证的动作”，而不是“请模型理解并执行”。比如“运行测试”就不要只写“并确保测试通过”，而要写具体的命令、预期的 exit code、失败时的回退动作。这样模型在执行时才有抓手。
实际落地时，先建三五个高频技能就够了，别一上来就搞几十个。技能太多，模型和人都记不住，最后只会变成摆设。先把“新增功能、修 bug、代码审查、重构”这四个高频场景跑顺，后面再慢慢沉淀。
3. TDD 契约驱动：先定不变量，再让模型输出
有了技能框架，模型的行为路径被约束了。但路径对了还不够，生成的代码语义是否正确，需要一个更硬的约束手段。我现在的答案是：TDD 契约驱动。听起来有点“方法论味道”，翻译成大白话就是——在让模型写任何实现之前，先把“什么算对”写好。
传统的提示词写的是“请给我实现一个折扣计算函数”，模型给出实现，你看着合理就收下了。TDD 契约驱动的写法是：先把输入、输出、边界、异常、不变量全写进测试，然后告诉模型“实现要满足这些测试，测试不过就不算完”。模型不再拥有“定义需求语义”的权力，它只有“实现你的契约”的任务。
3.1 契约为什么是 TDD 的灵魂
很多人一提 TDD 就想到“先写测试再写代码”这个动作，却经常忽略测试背后的核心：测试是在表达一份契约。契约包括三部分：输入空间（允许输入什么）、输出空间（必须输出什么）、行为约束（在什么边界内可执行、有什么副作用禁止发生）。
举个例子，要写一个订单折扣函数，契约可以这么定义：
// 契约：计算订单折扣 // 输入：订单总金额（非负整数） // 输出：折扣率，范围限定在 [0, 0.3] // 不变量： // - 金额为 0 时，折扣率必须为 0 // - 金额不超过 100 时，折扣率必须为 0 // - 金额大于 100 且小于 500 时，折扣率必须在 [0.05, 0.15] // - 金额大于等于 500 时，折扣率必须在 [0.1, 0.3]然后把这份契约翻译成测试用例。注意，这里最忌讳的是“模型自己写测试自己过”，那样等于“运动员给自己当裁判”。契约测试一定要由人来写，或者由人严格 review 过脚本后再交给模型实现。
模型拿到契约和测试用例后，它的工作就从“我猜你想干什么”变成了“我只要满足这些断言就行”。这大大降低了生成的随意性。更重要的是，当后续需求变化时，你只需要改契约，模型就能在原有代码上做收缩性修改，而不是推倒重来。契约是代码雪崩中最强的一根防滑桩。
3.2 一次完整的“先红后绿再收”回合
以我最近做的一个模拟项目为例，业务要求是“商品库存扣减”。我没有直接让模型写扣减逻辑，而是先写了一份库存契约。
契约关键点有三条：扣减后库存不能为负数；并发扣减同一商品时不能超卖；扣减失败必须回滚已加锁的库存记录。
对应的测试，我会主动补上这样几个用例：
test("正常扣减后库存等于原库存减扣减数", () => { ... }); test("扣减数量大于剩余库存时抛错且库存不变", () => { ... }); test("同一商品并发扣减 100 次，最终库存不为负", () => { ... }); test("扣减失败时释放写锁，后续可正常扣减", () => { ... });这些测试在实现之前跑一遍，必然是红的。红，不代表失败，代表的是“契约已经挂上钩了”。然后我把测试抛给模型：“实现一个满足以上全部测试的库存服务，无法运行通过时不要停，分析失败原因继续修。”模型会进入一个循环：运行测试→看失败信息→修实现→再运行测试。这个循环里，模型的“花式发挥”被测试死死摁住。
等到全绿，我会再加一道工序：让模型列出它为了通过测试而做的所有假设，特别是不在契约内的行为。比如它可能自己加了日志、加了重试机制、加了乐观锁版本号字段。这些假设我用“收”这个词来对待——要么明确写进契约，要么要求删掉。不加收敛动作的 TDD，往往会变成“模型自导自演的绿”。
3.3 把契约翻译成机器能懂的描述
多语言模型对自然语言的理解有歧义，所以就算你把契约写得像上文那么清楚，模型也有可能在实现时悄悄“放宽”。比如它觉得“折扣率不超过 0.3”意味着只要最大值不超过就行，至于金额在 100 到 500 之间能不能打 0.2 的折扣，它觉得无所谓。可你的业务规则可能是“该区间必须落在 [0.05, 0.15]”，两个语义看起来差不多，实际差很远。
所以，契约写作有一条铁律：每条业务规则都要对应至少一个可执行的、带具体数值断言的测试，而不是一句描述。更进一步的实践是“把契约做成数据”：
{ "id": "discount-rule-002", "input": { "amount": 200 }, "expected": { "discountRate": [0.05, 0.15] }, "onViolate": "reject" }把这个 JSON 作为输入喂给模型，让它先“解释”这个契约，再“生成断言代码”，最后“实现功能”。三层都做完了，人的检查就只剩确认“契约本身是不是业务想要的”，而不必再逐行追代码。这个转变非常大——你不再审实现细节，而是审契约定义。审契约比审代码容易十倍，因为它的变化点少，而且一旦错了，出错方向非常清晰。
4. 工程纪律闭环：从自然语言到合并上线的每一道关卡
技能框架管“路径”，TDD 契约管“语义”，但这两个东西都是静态的，它们本身没有执行力。真正让它们跑起来、能在每天 50 次 AI 代码提交中拦住问题的，是一套闭环系统。我管它叫“AI 工程纪律闭环”，本质上是把人工评审时代的“代码评审文化”，升级成“人机协作的分层关卡”。
很多人以为闭环就是“加个 CI、跑个测试、失败了不让合入”，道理对，但粒度太粗。模型生成一个 bug 的方式千奇百怪，单靠一次全量测试根本拦不住所有雪崩。你需要把整个流程拆成一道一道闸门，每个闸门只承担一个具体职责，任何一道闸门不过，代码就不能向下游流动。
4.1 闭环的五个闸门
我的项目里，AI 生成代码从进入到合入，至少要过五个闸门。
第一道是“需求闸门”。任何任务进来，都要有准确的问题陈述和验收标准。不允许“帮我优化下系统”这种自由飘移命题。这道闸门最容易被人忽略，但它决定后面所有工作的成败。
第二道是“契约闸门”。改动涉及的所有契约、测试、不变量，必须先行或在同一次提交中提供。没有契约就签合同？抱歉，过不了。
第三道是“验证闸门”。跑真实测试、静态分析、覆盖率检查，全部拿命令结果说话。模型说“我认为没问题”不算数，退出码 0 才算数。
第四道是“差异闸门”。模型往往会在“满足契约”的同时顺手改很多无关东西——重命名变量、加注释、改格式、删“看起来没用”的代码。这些额外改动本质上增加了审查面，却几乎不产生价值。必须限制变更集，让每次提交聚焦到一个契约，一个目的。
第五道是“人工确认闸门”。模型不能自审自批。最后的语义确认、契约确认和风险确认，必须有一个真实的人来签字。哪怕这个人只花十分钟看契约不看代码，也必须有这个过程。
五道闸门缺了任何一道，模型的天赋都会变成灾难。
4.2 一个可落地的最小闭环配置
理论讲完，给一个低成本可复制的落地结构。我假设你已经有一个代码仓库和一套 CI。最小闭环我会这么搭：
repo/ contracts/ # 契约与测试定义，人写为主 skills/ # Superpowers 技能文件 src/ # AI 生成的实现，但理由不充分不允许改 tests/ # 与契约映射的测试 .workflow/ gate-1-parse-request.md gate-2-apply-skill.md gate-3-run-contract-tests.sh gate-4-validate-diff.sh gate-5-human-signoff.md平时的工作流是：需求以文本形式进入.workflow/gate-1登记，然后由模型根据skills/中的技能定位执行方案。实现完成后，CI 先跑gate-3——也就是契约测试；再跑gate-4——检查 diff 里是否包含超出当前契约的改动，超了就自动打回。最后生成一份“请求人工验收”的任务单，上面有模型自己填的三个字段：我改了哪些契约、我新增了哪些假设、哪些测试是新增的。开发者只需要看这三项，就能快速判断这一编代码值不值得进主干。
这套配置里，自动化部分其实很少：一个测试脚本、一个 diff 检查脚本、一个文档模板。但它把 AI 的“自由发挥”压到了最低。成本不高，收益极高。
4.3 人机分工：谁把关卡，谁背锅
很多团队冲进 AI 编程时，最大的错觉是“以后人不用写代码了”。我不同意。准确地说，是“以后人不用亲自写大量样板代码了”，但人要承担的责任反而更聚焦了：定义契约、设计技能、裁决冲突、处理模型的模糊假设。
具体分工我会这么定：机器负责“在契约边界内生成和验证”，人负责“定义契约边界本身”。一旦契约错了，那是人的锅；一旦实现违背契约，那是模型/流程的锅。这样追责清晰，不会出现“看起来都对但上线崩了”的糊涂账。
在模拟项目里我们是这么做的：每周末做一次“契约复盘”，把所有本周上线的契约变更拉出来过一遍，看有没有哪条契约写得太宽、哪条测试断言太弱、哪个技能的流程里少了兜底规则。不去看具体代码行，只看“约束的有效性”。这个习惯帮我们拦下了大量潜在雪崩，因为大多数问题不是某一段代码写错了，而是约束给得太松。
5. 踩坑实录：典型故障怎么救，怎么把恢复变成流程一部分
这套流程已经跑过好几个项目了，坦白说，不是所有问题都能被预防。写到这里，我把印象最深的几个故障和排查逻辑整理出来，给大家当参考。这些坑大概率你们也会踩。
5.1 症状、根因和救法速查
| 症状 | 根因 | 救法 |
|---|---|---|
| 测试全绿，但线上行为完全不对 | 契约本身描述错了，测试断言的是错误期望 | 重新定义契约，先修测试，再改实现，禁止“测试适配代码” |
| 模型一次提交改了十几个文件 | 差异闸门失效，技能里没写“单契约单提交” | 收紧 diff 检查，超出范围的改动自动 reject |
| 同样的需求跑两次，代码长得不一样 | 模型参数或模型版本不一致，技能没锁运行时 | 固定模型版本和推理参数，把版本号写进技能元信息 |
| 模型反复“假报成功”，不运行测试就说通过 | 兜底规则只写在提示里，没有强制工具调用 | 改成在流程中调用真实测试命令，失败就绝不能进下一关 |
| 契约测试变绿后越改越松 | 测试被模型自动“修好了” | 契约测试的修改权限从模型手里收回，只允许人修改 |
| 模型加了大量注释和格式化改动 | 技能里没有“最小变更”规则 | 在技能中增加禁止项：解释型注释、无关格式化、删除未影响代码 |
这张表里的每一行，都是我们流过的血。尤其是“测试被模型修好了”这条，特别隐蔽——模型发现测试不通过，它不是去修实现，而是直接改测试断言，把范围放宽松，然后报告“测试已通过”。这是契约驱动最需要防的一个坑，防法只有一条：契约测试文件的修改权限永远锁在开发者的手里，绝不放给模型。
5.2 最容易骗过我们的三个幻觉
第一个幻觉叫“测试都过了，应该没问题”。注意，测试通过只说明“实现满足契约”，不代表“契约满足业务”。你的契约可能漏了并发条件、漏了幂等性、漏了权限校验。测试过只能证明你测过，不能证明你定义完整。每次看到全绿，我会逼自己再多问一句：这个契约的边界空气墙，是不是还有没画上的地方？
第二个幻觉叫“模型报错越详细，质量越高”。很多技能模板要求模型“详细列出每一步”。但实践下来，模型很擅长生成可视化风格的长篇报告，却可能在核心实现上偷工减料。我后来把输出规则改成“结果优先，日志其次”：先简短输出结果，附上测试命令输出，再是变更摘要。报告越长，越要警惕。
第三个幻觉叫“只要契约不变，实现就不会崩”。契约固定不代表实现稳定。模型可能因为上下文过长、细节被覆盖，或者模型版本微调，在同一个契约下生成行为完全不同的实现。所以在闭环里，每次模型升级或上下文结构变化后，都要强制重新跑一遍全部契约测试，别迷信“之前验证过”。
5.3 把回滚和恢复设计成流程的一部分
最后这点，是我踩坑最深的体会。无论纪律多好，雪崩总有防不住的时候。关键是，你要有“恢复预案”，而不是临时救火。
我会在每个项目开始时就写好一套“回滚三板斧”：第一，契约文件全部进版本库，任何契约变更都有历史可查；第二，技能文件遵循语义化版本，升级技能库之前先跑全部现有契约测试；第三，CI 里保留下一次“重建验证”的按钮，把某一时刻的契约和技能库整体还原到一个临时分支，重新生成实现，看能不能跑绿。
这么做的好处是：真出问题时，我们不靠“人工回忆当时怎么写的”，而是回到历史版本，用同一份契约、同一套技能、同一批测试，把“现场”重新拉出来。哪怕模型已经更新换代，我们也能在旧版本约束下做对比定位。
从我个人的实际感受来说，这套东西不是万能的，但它是目前我见过“花钱最少、见效最快、还能持续积累”的防雪崩方案。每次项目跑崩，本质都是人和约束之间先断了一层。技能框架补“路径约束”，TDD 契约补“语义约束”，工程纪律补“流程约束”。把这三条线一根一根系紧，AI 编程的雪崩，才会真正从“意外”变成“不太可能发生”。
