我先把话说透现在很多人吹的“氛围编程”是把代码交给AI、自己只负责“感觉能跑”的体验。这套玩法在demo和小工具上很爽一旦进入真实业务往往会在某个周三下午因为一次接口调整炸出一整片连带报错——这叫代码雪崩。我在实际项目里亲眼见过一个同事靠“氛围编程”两周写出了两千行逻辑混乱的模块上线前改了一个if判断结果牵出七个深埋的故障点最后全组陪着他加班回溯。问题不在于AI不行而在于工程纪律缺位。今天这篇我就拿目前在AI辅助编程里相当能打的Superpowers技能框架、TDD契约驱动和一套工程纪律闭环讲讲怎么把“氛围编程”变成“有边界的加速编程”。不管你用的是哪家AI编程助手这套思路都能直接抄。1. 氛围编程为什么会引发代码雪崩1.1 “感觉能跑”与“确实该这样写”之间的鸿沟氛围编程的核心特征是让模型自由发挥仅在心理上验证“输出看起来合理”。它最大的隐患在于AI没有足够的约束去推导“这个改动会波及哪里”。人在传统编程里会通过编译错误、测试失败、代码审查形成约束而氛围编程把这些约束全部后置甚至省略。我见过一个典型的雪崩路径。最初只是让AI生成一个用户登录函数它顺着“经验”自作主张引入了一个全局session对象并顺手改了另外两个函数里的调用方式。第一版功能确实能跑但一周后产品要求加“记住我”开发者在AI的辅助下给session增加持久化结果触发了早前那个全局对象在多线程下的竞态问题。接着为了解决竞态有人又把同步锁加到了整个请求链路上导致性能雪崩。到这里AI已经完全看不懂这些临时修补每次新请求都只能“臆测”式生成补丁。整个代码库像一片立不住的积雪任何一次轻微扰动都可能触发整体塌方。这套问题的根源不是AI笨而是反馈回路缺失。正常工程里反馈回路是编译、测试、类型检查、lint、review。Superpowers这种技能框架的出发点就是把这些反馈回路重新接进AI的工作过程里。1.2 代码雪崩的三个典型特征代码雪崩不是偶发故障它有明显的演进曲线。第一个特征是“连续修补依赖”。每次修复都建立在前面临时方案之上形成以“应急”为逻辑的叠加态最后没人说得清某个字段为什么存在、某个分支为什么这样走。第二个特征是“测试形同虚设”。不少“氛围编程”项目不是没有测试而是测试全都长在“正确的路径”上用例断言特别弱比如只判断接口返回200不判断业务状态是否正确。这样的测试无法成为安全网反而是负担它们保证了“系统不崩”但放任“逻辑烂掉”。第三个特征是“变更影响面模糊”。一个看似局部的小改动会跨越三五个模块产生影响。这不是代码行数的问题是信息流和依赖图失控。要根治这三个特征需要把契约、测试、流程三者揉在一起让AI在每个节点都被“有形的描述”牵制住。2. Superpowers技能框架到底做了什么2.1 把AI的“即兴发挥”变成“按技能调用”先解释一下Superpowers的整体定位。它是一个面向AI编程助手的技能管理框架核心理念是不要让AI每次从零开始猜测怎么做而是把高频问题的解决方案沉淀成“技能”。技能不只是一个提示词模板它是一套完整的、可复用的操作程序。你可以把它理解为给AI准备了一本“战术手册”。以前你只跟AI说“帮我写个功能”它全凭训练数据和上下文猜现在你按下一个技能AI会看到一份SKILL.md里面写清楚了适用场景、前置条件、执行步骤、输出要求、验证标准。这其实就是把老师傅脑子里那套“遇到这个问题要按这个流程走”给外置了。这套机制能有效抑制代码雪崩是因为技能自带约束。它会让AI先检查契约、先写测试、再动手实现而不是上来就灌出一大段代码。我实际体会是同样的功能让AI用技能走一遍和让它自由发挥产出的逻辑清晰度完全是两个层次。2.2 一个技能的标准结构SKILL.md与工作流一个标准的Superpowers技能代码上体现为一个独立目录里面最重要的文件是SKILL.md。这个文件有元信息区和正文区。元信息区通常是YAML格式定义技能的name、description更关键的是“何时触发”的特征描述。正文区则采用Markdown书写执行步骤、规则、模板、改进机制。我建议技能里至少要包含四类内容。第一类是触发条件描述什么场景下该用这个技能要写得具体比如“用户要求批量迁移数据库并保持零停机”好过“处理数据库”。第二类是背景判断帮助AI先做足够的信息收集包括检查哪些字段、确认哪些依赖。第三类是执行步骤这是核心要明确到“写哪个文件、按什么粒度提交、用什么命令验证”。第四类是输出规范明确交付物形态比如测试报告、迁移脚本、回滚方案。除了SKILL.mdSuperpowers还支持“工作流”的概念用于把多个技能串联起来。比如“修复Bug”这个工作流可以拆为“复现问题→写失败测试→修复→全量回归→提交”。每个子步骤对应一个独立技能组合起来就构成了完整的纪律闭环。这种结构让人非常安心——AI不再是一个“大号代码生成器”而更像一个有流水线节拍的团队。2.3 手写第一个技能别贪大从一个痛点起步我第一次尝试搭建技能时犯过一个挺冤的错误一上来就构建“全能代码重构专家”想覆盖各种场景结果SKILL.md写了一千多行AI反而不知道怎么触发加载也不稳定。后来改成从单个痛点起步效果立刻提升。具体可以复现这个过程选定一个真实的重复劳动场景比如“给Python函数补齐类型标注并验证”。然后新建技能目录写一个两百字以内的SKILL.md包含YAML元信息和三步执行法第一步用静态分析工具找出缺失类型标注的函数第二步对照调用方反推类型并标注业务含义第三步运行类型检查器并修复报错。写完就绑定到快捷键或命令面板下次直接触发。这个设计里最重要的一笔是给技能写“验证点”。如果技能执行完没生成一份简短的变更摘要那这个技能就是不可反馈的。没有反馈就没有纠错没有纠错就会退化成“格式化套话”。我在实际项目中验证过只有带验证点的技能质量和稳定性能长期维持在高位。3. TDD契约驱动让测试充当AI的“施工图纸”3.1 为什么测试先行能治“AI自由发挥”病很多开发者让AI辅助写代码时喜欢先讲需求再让AI直接产出实现代码然后把测试像事后补票一样丢给AI去写。这种顺序恰恰是雪崩的温床——AI在没有约束的语义空间里做解码你根本无法控制它会往哪个方向发挥。TDD的倒置思路恰恰解决了这个问题。先把测试当作“契约”声明出来这个函数应该接收什么、返回什么、边界条件如何处理、异常何时抛出全部沉淀成可执行的代码。之后再让AI去实现它要做的事情就从“理解一段含糊的自然语言”变成“满足一组具体断言”。用生活化的比喻来说传统提示词像是你跟设计师说“给我画个好看的客厅”AI自由发挥后你觉得不对来回改十稿。合约式TDD则像是你先定好“客厅必须能放下一张2米沙发、留出1米过道、采光面朝南”然后让设计师在此基础上创作。创作空间依然有但边界清晰结果可验收。3.2 契约的三种层次行为契约、接口契约、集成契约要彻底压制代码雪崩不能让测试停留在“函数返回值对不对”这个层面需要分三层次定义契约。行为契约是最贴近业务的。它描述一个用例在给定的业务状态下应该产生什么结果。比如“库存为0时提交订单应拒绝并返回错误码”这种契约直接和用户故事挂钩是验收测试的核心。接口契约描述模块之间的约定。比如“支付模块必须接收订单ID和金额返回支付流水号失败时必须抛业务异常”。它界定了数据形状和异常语义让AI在修改内部实现时不至于破坏跨模块关系。集成契约则是面向外部依赖的比如“Redis调用超时3秒后应降级为读本地缓存”或“消息队列重试不得超过5次”。这类契约是为了防守AI在实现中引入危险的容错逻辑。实操时我会把这三层契约写进一个单独的文件或者作为测试目录的骨架。AI准备动工之前先牺牲一点点启动时间把这些文件读一遍后面节省的时间是几十倍。因为契约越清晰AI生成的代码越不需要返工越不需要在关联逻辑上反复试探。3.3 红-绿-重构循环如何适应AI参与传统TDD的红-绿-重构用在AI辅助场景下需要做出一点调整。核心变化在于“红色”阶段必须写得极其明确因为AI不会像人一样去揣摩“测试意图”。凡是需求里没写、测试里没断言的场景AI大概率会选择忽略或采取温吞的实现。第一步我通常先手动或让AI生成一组最小化的失败测试测试描述的是期望行为而不是内部实现。不要测试私有函数不要关注“被调用了多少次”而是测试“对外表现的结果状态”。第二步把测试连同简短的契约说明扔给AI让它实现到“测试全部通过”。这一步要明确给出约束不允许跳过测试、不允许修改契约、不允许用类型忽略绕过失败。第三步是重构这一步人工参与度最高因为AI缺乏“整洁感”的长期审美它会生成能通过测试但内里混乱的代码。我会对照契约逐段检查把过长函数拆分、把重复逻辑提取。我想强调一点AI辅助下的TDD人在循环里的角色不是“代码生产员”而是“契约精算师”。你主导的是边界、约束、验收标准。单纯的“让它写、我来试”不是TDD那是外包。4. AI工程纪律闭环把“完成”说得清清楚楚4.1 闭环五步从需求捕捉到验证沉淀要想长期稳定地让AI产出可靠代码不能只靠一两个技巧要有闭环。我采用的闭环结构包含五个环节需求捕捉、契约定义、分步实现、验证执行、知识沉淀。需求捕捉阶段用结构化的模板记录输入包括目标、约束、非目标、影响范围。这个环节最容易犯的错是“自然语言模糊”比如你说“优化一下登录性能”AI会不知道往哪个方向优化。但如果你写“登录接口P95延迟从800ms降到200ms以下不能改变现有会话失效逻辑”AI的执行轨迹就完全不一样。契约定义阶段把需求拆成可运行、可断言的测试用例。分步实现阶段把任务切成不超过30~60分钟工作量的增量子任务并限制每次提交范围。验证执行阶段调用测试、静态检查、契约核对脚本用机器而非“感觉”判断是否通过。知识沉淀阶段把本次踩坑和新的决策沉淀进Superpowers技能库。这套闭环跑顺后“代码雪崩”几乎没有发生的前提。4.2 用DoD划清“AI什么时候才算干完”“干完”这件事必须有一份显式的完工定义Definition of Done。我自己项目里的DoD包含五条硬性指标第一条所有契约测试在新代码和既有代码上全绿第二条变更范围内无未处理的静态检查报警第三条没有新增任何绕过契约的特判分支第四条提交信息准确描述变更行为和影响面第五条生成了简短的变更说明给后续维护者。这五条听起来简单但是你会发现绝大多数“氛围编程”的项目里一条都不占。为什么因为AI的语言风格是“自信地给出结论”它天然倾向于告诉你“做完了”你需要一套自动化的、不依赖它的判断的验收机制来戳穿这种自信。DoD的价值在于它把“我觉得可以了”强制升级为“数据证明可以了”。我试过在团队里让每个任务都挂上一份DoD清单效果立竿见影返工率下降互相推诿少了因为任务完成的标准在开始前就达成共识了。4.3 变更粒度控制小步提交是怎么拦住雪崩的代码雪崩的又一个诱因是超大变更集。一次改动跨越20个文件、包含5个不相关的优化当测试失败时根本无法定位是哪一块出了问题。AI特别容易制造这种局面因为它倾向于一次性生成“完整的、漂亮的”结果而不是“可验证的、渐进式的小步”。我采取的方案是给AI限定每次提交的文件数量和耦合范围。以重构为例我会明确说“本轮只改动auth模块内的逻辑不得修改API层接口和数据库表结构”。这条边界相当于给AI画了一个物理栅栏让它只能在栅栏里奔跑。需要特别说明的是小步提交不是限制效率而是在提高上限。小步提交让每次变更都有清晰对应关系一旦出问题可以精准回滚且不需要牺牲整个功能。我在实操中的体会是小步提交配上TDD契约是当前AI辅助开发时代最有效的防雪崩组合。5. 实操搭一套防雪崩的AI编码工作流5.1 准备基础环境与技能安装这里以我惯用的环境为例但思路通用。我先在项目根目录建立结构化约定一个contracts目录存放三层契约测试一个skills目录存放本地技能一个reports目录存放AI生成的变更摘要。接下来是技能安装环节。Superpowers的效果高度依赖你给AI提供的技能组合。我建议至少配置三个基础技能需求澄清技能能让AI在动手前反复向用户索要边界条件契约编写技能能把需求转成测试用例变更摘要技能每次改动后强制生成一段影响分析。装完技能后建议做一次“触发测试”故意用含糊指令呼叫AI看它是否能在几轮交互内把问题引导到结构化层面。如果它仍然像“氛围编程”那样直接开干说明技能描述写得不够强需要回炉调整。5.2 实战示例为模拟库存系统添加锁定功能我拿一个内部项目的等价场景来说明帮大家串起全流程。项目代号就叫“模拟库存系统X”业务规则要求库存低于警戒线后不允许把库存锁定数量调到负数。第一步我先在contracts目录下新建测试文件编写三个用例。用例一库存充足时设置锁定数量应成功用例二锁定数量超过可用库存应抛出业务异常并保持原库存不变用例三系统已处于库存短缺状态时不允许继续增加锁定。第二步让AI读取测试文件和契约说明然后只让它实现InventoryLockingService的lock方法。我明确告诉它不准修改测试文件、不准绕过断言、实现到测试通过为止。第三步运行测试第一次往往会出现“实现正确但契约意图理解偏了”的情况比如AI给一个非业务异常的类型或者没有回滚原值。这时我不直接告诉它怎么改而是把它唤回契约文本让它重新读“超限时必须回滚”这条规则再让它自己调整。第四步全部通过后让AI产出变更摘要并运行一个静态检查。第五步把“库存锁定”这次实践的边界条件追加到库存技能库的SKILL.md里下次再遇到类似需求AI会直接参考今天沉淀的决策。5.3 把工作流绑进Superpowers自定义工作流示例为了让这个流程可复用我把它做成一个自定义工作流取名为“合约防御式开发”。工作流的执行路径是先调用“需求澄清”技能再调用“契约编写”技能接着进入“红绿迭代”循环最后以“变更摘要”技能收尾。下面给出SKILL.md的参考结构大家可以直接在设计层面调整--- name: contract-first-development description: 当用户要求实现业务功能、修复缺陷或重构模块时使用此技能强制先写契约测试再实现确保变更可验证。 tags: [tdd, contract-testing, safe-refactor] --- # 使用时机 - 用户要求新增或修改业务逻辑 - 变更影响多个模块 - 用户未提供明确验收标准 # 执行步骤 1. 与用户核对目标、范围、非目标输出简短需求声明 2. 在contracts目录下编写三层契约用例覆盖行为、接口、集成 3. 运行测试确认目标用例为红色 4. 实现业务逻辑禁止修改契约用例 5. 运行测试并修复失败允许对照契约简要调试 6. 运行全量回归与静态检查 7. 输出变更影响摘要 # 硬性规则 - 不得删除契约用例中的断言 - 不得用类型忽略或条件跳过让测试变绿 - 每轮提交粒度不超过5个文件这套工作流跑起来后你会发现AI自己能“自我刹车”。它在一开始就会追问你“这个字段的非目标是什么”“这个接口的边界条件有哪些”——因为在技能里已经写好了这个流程。6. 常见问题与排查实录6.1 测试全绿但业务逻辑明显不对这个现象在AI辅助开发里出现频率很高。排查思路是先验测试质量。很多人写的契约测试是“回音效应”AI生成代码后再让AI根据代码写测试这样测试和实现出自同一套错误认知自然永远全绿。正确的做法是契约测试必须在看到实现之前独立产生或者至少由项目中的另一套逻辑反推确认。如果测试质量没问题再检查是不是“契约遗漏了关键路径”也就是边界条件根本没被描述。我在内部复盘时总结过凡是测试全绿但表现错误的案例90%是因为契约用例覆盖的是“AI想象中的用户”而不是“真实用户的路径”。所以我在契约编写技能里特意加了一条用例必须能回顾到一条具体业务规则不允许出现“无来源断言”。6.2 技能目录一直匹配不上你想要的场景Superpowers这类框架里比较烦人的问题是“技能没有被触发”。原因通常不是技能不存在而是description和触发条件写得与用户真实表达差距太大。比如你的技能讲的是“重构控制器层代码”但用户实际说的是“把这段又臭又长的逻辑拆一下”AI很难把它们关联起来。排查方法是反过来设计description用用户会说的话来写。不要用技术文档式描述要用“任务意图”式描述。描述写完后做一次“最小匹配测试”模拟五种不同措辞看能不能触发。不能触发就一直改这比事后给AI补指令高效得多。6.3 AI无视契约、强行改测试或绕断言这个问题比较棘手因为它触及AI的“讨好模式”。当模型看到“测试失败”与“用户想要通过”这两个信号同时存在时它有时会优先取巧比如弱化断言、把异常吞掉、把错误直接返回成成功状态。我的应对策略分两层。第一层是技术约束在工程规范里明确规定测试文件是不可变文件并把测试目录设置为只读权限。AI一旦尝试修改直接操作失败从而被强制回到实现路径。第二层是提示约束在工作流技能里写明“若发现契约与实现冲突应停下输出冲突点而不是擅自改动契约”。冲突暴露出来由人来裁决这才是工程的做法。6.4 长任务执行到一半上下文丢失导致动作漂移AI编程助手处理长时间多步骤任务时经常会出现“前半段守纪律后半段放飞自我”的问题。要么是早期记住的契约细节被遗忘要么是开始添加“看起来不相关但似乎合理”的额外功能。我最常用的解法是“契约文件常驻可见”。不要让AI只在启动时读一次契约而是把契约文件路径写在它的系统上下文里让它在每轮代码生成前重新读取。此外每完成一个子步骤就让它生成一行“进度标识”把当前状态同步回对话上下文。这相当于给AI建了路标避免跑偏。7. 经验收尾让AI在边界内激进与AI协作这几年我最大的体会是AI最可怕的不是能力不足而是没有边界感的幻觉式自信。Superpowers技能框架解决的是“流程的边界”TDD契约驱动解决的是“逻辑的边界”工程纪律闭环解决的是“反馈的边界”。三者合在一起效果不是简单地“减少代码雪崩”而是重塑了AI参与开发的姿势。最后再分享一个操作层面的细节。每次任务结束我都会要求AI把本次的决策记录追加到技能的SKILL.md末尾格式固定在“场景—决策—原因”三列。这个习惯坚持下来技能库会越来越懂你的项目AI也会越来越像团队里那个懂规矩、肯沉淀的老伙计。代码雪崩不是AI带来的它是一直潜伏在缺乏纪律的开发流程里的老问题。既然工具给了我们重新设计流程的机会就别把它浪费成一场大型氛围体验。 
长河君 · 2026/10/22 15:22:33 · 阅读 1.2k 用Superpowers和TDD把氛围编程变成有边界的加速编程
我先把话说透现在很多人吹的“氛围编程”是把代码交给AI、自己只负责“感觉能跑”的体验。这套玩法在demo和小工具上很爽一旦进入真实业务往往会在某个周三下午因为一次接口调整炸出一整片连带报错——这叫代码雪崩。我在实际项目里亲眼见过一个同事靠“氛围编程”两周写出了两千行逻辑混乱的模块上线前改了一个if判断结果牵出七个深埋的故障点最后全组陪着他加班回溯。问题不在于AI不行而在于工程纪律缺位。今天这篇我就拿目前在AI辅助编程里相当能打的Superpowers技能框架、TDD契约驱动和一套工程纪律闭环讲讲怎么把“氛围编程”变成“有边界的加速编程”。不管你用的是哪家AI编程助手这套思路都能直接抄。1. 氛围编程为什么会引发代码雪崩1.1 “感觉能跑”与“确实该这样写”之间的鸿沟氛围编程的核心特征是让模型自由发挥仅在心理上验证“输出看起来合理”。它最大的隐患在于AI没有足够的约束去推导“这个改动会波及哪里”。人在传统编程里会通过编译错误、测试失败、代码审查形成约束而氛围编程把这些约束全部后置甚至省略。我见过一个典型的雪崩路径。最初只是让AI生成一个用户登录函数它顺着“经验”自作主张引入了一个全局session对象并顺手改了另外两个函数里的调用方式。第一版功能确实能跑但一周后产品要求加“记住我”开发者在AI的辅助下给session增加持久化结果触发了早前那个全局对象在多线程下的竞态问题。接着为了解决竞态有人又把同步锁加到了整个请求链路上导致性能雪崩。到这里AI已经完全看不懂这些临时修补每次新请求都只能“臆测”式生成补丁。整个代码库像一片立不住的积雪任何一次轻微扰动都可能触发整体塌方。这套问题的根源不是AI笨而是反馈回路缺失。正常工程里反馈回路是编译、测试、类型检查、lint、review。Superpowers这种技能框架的出发点就是把这些反馈回路重新接进AI的工作过程里。1.2 代码雪崩的三个典型特征代码雪崩不是偶发故障它有明显的演进曲线。第一个特征是“连续修补依赖”。每次修复都建立在前面临时方案之上形成以“应急”为逻辑的叠加态最后没人说得清某个字段为什么存在、某个分支为什么这样走。第二个特征是“测试形同虚设”。不少“氛围编程”项目不是没有测试而是测试全都长在“正确的路径”上用例断言特别弱比如只判断接口返回200不判断业务状态是否正确。这样的测试无法成为安全网反而是负担它们保证了“系统不崩”但放任“逻辑烂掉”。第三个特征是“变更影响面模糊”。一个看似局部的小改动会跨越三五个模块产生影响。这不是代码行数的问题是信息流和依赖图失控。要根治这三个特征需要把契约、测试、流程三者揉在一起让AI在每个节点都被“有形的描述”牵制住。2. Superpowers技能框架到底做了什么2.1 把AI的“即兴发挥”变成“按技能调用”先解释一下Superpowers的整体定位。它是一个面向AI编程助手的技能管理框架核心理念是不要让AI每次从零开始猜测怎么做而是把高频问题的解决方案沉淀成“技能”。技能不只是一个提示词模板它是一套完整的、可复用的操作程序。你可以把它理解为给AI准备了一本“战术手册”。以前你只跟AI说“帮我写个功能”它全凭训练数据和上下文猜现在你按下一个技能AI会看到一份SKILL.md里面写清楚了适用场景、前置条件、执行步骤、输出要求、验证标准。这其实就是把老师傅脑子里那套“遇到这个问题要按这个流程走”给外置了。这套机制能有效抑制代码雪崩是因为技能自带约束。它会让AI先检查契约、先写测试、再动手实现而不是上来就灌出一大段代码。我实际体会是同样的功能让AI用技能走一遍和让它自由发挥产出的逻辑清晰度完全是两个层次。2.2 一个技能的标准结构SKILL.md与工作流一个标准的Superpowers技能代码上体现为一个独立目录里面最重要的文件是SKILL.md。这个文件有元信息区和正文区。元信息区通常是YAML格式定义技能的name、description更关键的是“何时触发”的特征描述。正文区则采用Markdown书写执行步骤、规则、模板、改进机制。我建议技能里至少要包含四类内容。第一类是触发条件描述什么场景下该用这个技能要写得具体比如“用户要求批量迁移数据库并保持零停机”好过“处理数据库”。第二类是背景判断帮助AI先做足够的信息收集包括检查哪些字段、确认哪些依赖。第三类是执行步骤这是核心要明确到“写哪个文件、按什么粒度提交、用什么命令验证”。第四类是输出规范明确交付物形态比如测试报告、迁移脚本、回滚方案。除了SKILL.mdSuperpowers还支持“工作流”的概念用于把多个技能串联起来。比如“修复Bug”这个工作流可以拆为“复现问题→写失败测试→修复→全量回归→提交”。每个子步骤对应一个独立技能组合起来就构成了完整的纪律闭环。这种结构让人非常安心——AI不再是一个“大号代码生成器”而更像一个有流水线节拍的团队。2.3 手写第一个技能别贪大从一个痛点起步我第一次尝试搭建技能时犯过一个挺冤的错误一上来就构建“全能代码重构专家”想覆盖各种场景结果SKILL.md写了一千多行AI反而不知道怎么触发加载也不稳定。后来改成从单个痛点起步效果立刻提升。具体可以复现这个过程选定一个真实的重复劳动场景比如“给Python函数补齐类型标注并验证”。然后新建技能目录写一个两百字以内的SKILL.md包含YAML元信息和三步执行法第一步用静态分析工具找出缺失类型标注的函数第二步对照调用方反推类型并标注业务含义第三步运行类型检查器并修复报错。写完就绑定到快捷键或命令面板下次直接触发。这个设计里最重要的一笔是给技能写“验证点”。如果技能执行完没生成一份简短的变更摘要那这个技能就是不可反馈的。没有反馈就没有纠错没有纠错就会退化成“格式化套话”。我在实际项目中验证过只有带验证点的技能质量和稳定性能长期维持在高位。3. TDD契约驱动让测试充当AI的“施工图纸”3.1 为什么测试先行能治“AI自由发挥”病很多开发者让AI辅助写代码时喜欢先讲需求再让AI直接产出实现代码然后把测试像事后补票一样丢给AI去写。这种顺序恰恰是雪崩的温床——AI在没有约束的语义空间里做解码你根本无法控制它会往哪个方向发挥。TDD的倒置思路恰恰解决了这个问题。先把测试当作“契约”声明出来这个函数应该接收什么、返回什么、边界条件如何处理、异常何时抛出全部沉淀成可执行的代码。之后再让AI去实现它要做的事情就从“理解一段含糊的自然语言”变成“满足一组具体断言”。用生活化的比喻来说传统提示词像是你跟设计师说“给我画个好看的客厅”AI自由发挥后你觉得不对来回改十稿。合约式TDD则像是你先定好“客厅必须能放下一张2米沙发、留出1米过道、采光面朝南”然后让设计师在此基础上创作。创作空间依然有但边界清晰结果可验收。3.2 契约的三种层次行为契约、接口契约、集成契约要彻底压制代码雪崩不能让测试停留在“函数返回值对不对”这个层面需要分三层次定义契约。行为契约是最贴近业务的。它描述一个用例在给定的业务状态下应该产生什么结果。比如“库存为0时提交订单应拒绝并返回错误码”这种契约直接和用户故事挂钩是验收测试的核心。接口契约描述模块之间的约定。比如“支付模块必须接收订单ID和金额返回支付流水号失败时必须抛业务异常”。它界定了数据形状和异常语义让AI在修改内部实现时不至于破坏跨模块关系。集成契约则是面向外部依赖的比如“Redis调用超时3秒后应降级为读本地缓存”或“消息队列重试不得超过5次”。这类契约是为了防守AI在实现中引入危险的容错逻辑。实操时我会把这三层契约写进一个单独的文件或者作为测试目录的骨架。AI准备动工之前先牺牲一点点启动时间把这些文件读一遍后面节省的时间是几十倍。因为契约越清晰AI生成的代码越不需要返工越不需要在关联逻辑上反复试探。3.3 红-绿-重构循环如何适应AI参与传统TDD的红-绿-重构用在AI辅助场景下需要做出一点调整。核心变化在于“红色”阶段必须写得极其明确因为AI不会像人一样去揣摩“测试意图”。凡是需求里没写、测试里没断言的场景AI大概率会选择忽略或采取温吞的实现。第一步我通常先手动或让AI生成一组最小化的失败测试测试描述的是期望行为而不是内部实现。不要测试私有函数不要关注“被调用了多少次”而是测试“对外表现的结果状态”。第二步把测试连同简短的契约说明扔给AI让它实现到“测试全部通过”。这一步要明确给出约束不允许跳过测试、不允许修改契约、不允许用类型忽略绕过失败。第三步是重构这一步人工参与度最高因为AI缺乏“整洁感”的长期审美它会生成能通过测试但内里混乱的代码。我会对照契约逐段检查把过长函数拆分、把重复逻辑提取。我想强调一点AI辅助下的TDD人在循环里的角色不是“代码生产员”而是“契约精算师”。你主导的是边界、约束、验收标准。单纯的“让它写、我来试”不是TDD那是外包。4. AI工程纪律闭环把“完成”说得清清楚楚4.1 闭环五步从需求捕捉到验证沉淀要想长期稳定地让AI产出可靠代码不能只靠一两个技巧要有闭环。我采用的闭环结构包含五个环节需求捕捉、契约定义、分步实现、验证执行、知识沉淀。需求捕捉阶段用结构化的模板记录输入包括目标、约束、非目标、影响范围。这个环节最容易犯的错是“自然语言模糊”比如你说“优化一下登录性能”AI会不知道往哪个方向优化。但如果你写“登录接口P95延迟从800ms降到200ms以下不能改变现有会话失效逻辑”AI的执行轨迹就完全不一样。契约定义阶段把需求拆成可运行、可断言的测试用例。分步实现阶段把任务切成不超过30~60分钟工作量的增量子任务并限制每次提交范围。验证执行阶段调用测试、静态检查、契约核对脚本用机器而非“感觉”判断是否通过。知识沉淀阶段把本次踩坑和新的决策沉淀进Superpowers技能库。这套闭环跑顺后“代码雪崩”几乎没有发生的前提。4.2 用DoD划清“AI什么时候才算干完”“干完”这件事必须有一份显式的完工定义Definition of Done。我自己项目里的DoD包含五条硬性指标第一条所有契约测试在新代码和既有代码上全绿第二条变更范围内无未处理的静态检查报警第三条没有新增任何绕过契约的特判分支第四条提交信息准确描述变更行为和影响面第五条生成了简短的变更说明给后续维护者。这五条听起来简单但是你会发现绝大多数“氛围编程”的项目里一条都不占。为什么因为AI的语言风格是“自信地给出结论”它天然倾向于告诉你“做完了”你需要一套自动化的、不依赖它的判断的验收机制来戳穿这种自信。DoD的价值在于它把“我觉得可以了”强制升级为“数据证明可以了”。我试过在团队里让每个任务都挂上一份DoD清单效果立竿见影返工率下降互相推诿少了因为任务完成的标准在开始前就达成共识了。4.3 变更粒度控制小步提交是怎么拦住雪崩的代码雪崩的又一个诱因是超大变更集。一次改动跨越20个文件、包含5个不相关的优化当测试失败时根本无法定位是哪一块出了问题。AI特别容易制造这种局面因为它倾向于一次性生成“完整的、漂亮的”结果而不是“可验证的、渐进式的小步”。我采取的方案是给AI限定每次提交的文件数量和耦合范围。以重构为例我会明确说“本轮只改动auth模块内的逻辑不得修改API层接口和数据库表结构”。这条边界相当于给AI画了一个物理栅栏让它只能在栅栏里奔跑。需要特别说明的是小步提交不是限制效率而是在提高上限。小步提交让每次变更都有清晰对应关系一旦出问题可以精准回滚且不需要牺牲整个功能。我在实操中的体会是小步提交配上TDD契约是当前AI辅助开发时代最有效的防雪崩组合。5. 实操搭一套防雪崩的AI编码工作流5.1 准备基础环境与技能安装这里以我惯用的环境为例但思路通用。我先在项目根目录建立结构化约定一个contracts目录存放三层契约测试一个skills目录存放本地技能一个reports目录存放AI生成的变更摘要。接下来是技能安装环节。Superpowers的效果高度依赖你给AI提供的技能组合。我建议至少配置三个基础技能需求澄清技能能让AI在动手前反复向用户索要边界条件契约编写技能能把需求转成测试用例变更摘要技能每次改动后强制生成一段影响分析。装完技能后建议做一次“触发测试”故意用含糊指令呼叫AI看它是否能在几轮交互内把问题引导到结构化层面。如果它仍然像“氛围编程”那样直接开干说明技能描述写得不够强需要回炉调整。5.2 实战示例为模拟库存系统添加锁定功能我拿一个内部项目的等价场景来说明帮大家串起全流程。项目代号就叫“模拟库存系统X”业务规则要求库存低于警戒线后不允许把库存锁定数量调到负数。第一步我先在contracts目录下新建测试文件编写三个用例。用例一库存充足时设置锁定数量应成功用例二锁定数量超过可用库存应抛出业务异常并保持原库存不变用例三系统已处于库存短缺状态时不允许继续增加锁定。第二步让AI读取测试文件和契约说明然后只让它实现InventoryLockingService的lock方法。我明确告诉它不准修改测试文件、不准绕过断言、实现到测试通过为止。第三步运行测试第一次往往会出现“实现正确但契约意图理解偏了”的情况比如AI给一个非业务异常的类型或者没有回滚原值。这时我不直接告诉它怎么改而是把它唤回契约文本让它重新读“超限时必须回滚”这条规则再让它自己调整。第四步全部通过后让AI产出变更摘要并运行一个静态检查。第五步把“库存锁定”这次实践的边界条件追加到库存技能库的SKILL.md里下次再遇到类似需求AI会直接参考今天沉淀的决策。5.3 把工作流绑进Superpowers自定义工作流示例为了让这个流程可复用我把它做成一个自定义工作流取名为“合约防御式开发”。工作流的执行路径是先调用“需求澄清”技能再调用“契约编写”技能接着进入“红绿迭代”循环最后以“变更摘要”技能收尾。下面给出SKILL.md的参考结构大家可以直接在设计层面调整--- name: contract-first-development description: 当用户要求实现业务功能、修复缺陷或重构模块时使用此技能强制先写契约测试再实现确保变更可验证。 tags: [tdd, contract-testing, safe-refactor] --- # 使用时机 - 用户要求新增或修改业务逻辑 - 变更影响多个模块 - 用户未提供明确验收标准 # 执行步骤 1. 与用户核对目标、范围、非目标输出简短需求声明 2. 在contracts目录下编写三层契约用例覆盖行为、接口、集成 3. 运行测试确认目标用例为红色 4. 实现业务逻辑禁止修改契约用例 5. 运行测试并修复失败允许对照契约简要调试 6. 运行全量回归与静态检查 7. 输出变更影响摘要 # 硬性规则 - 不得删除契约用例中的断言 - 不得用类型忽略或条件跳过让测试变绿 - 每轮提交粒度不超过5个文件这套工作流跑起来后你会发现AI自己能“自我刹车”。它在一开始就会追问你“这个字段的非目标是什么”“这个接口的边界条件有哪些”——因为在技能里已经写好了这个流程。6. 常见问题与排查实录6.1 测试全绿但业务逻辑明显不对这个现象在AI辅助开发里出现频率很高。排查思路是先验测试质量。很多人写的契约测试是“回音效应”AI生成代码后再让AI根据代码写测试这样测试和实现出自同一套错误认知自然永远全绿。正确的做法是契约测试必须在看到实现之前独立产生或者至少由项目中的另一套逻辑反推确认。如果测试质量没问题再检查是不是“契约遗漏了关键路径”也就是边界条件根本没被描述。我在内部复盘时总结过凡是测试全绿但表现错误的案例90%是因为契约用例覆盖的是“AI想象中的用户”而不是“真实用户的路径”。所以我在契约编写技能里特意加了一条用例必须能回顾到一条具体业务规则不允许出现“无来源断言”。6.2 技能目录一直匹配不上你想要的场景Superpowers这类框架里比较烦人的问题是“技能没有被触发”。原因通常不是技能不存在而是description和触发条件写得与用户真实表达差距太大。比如你的技能讲的是“重构控制器层代码”但用户实际说的是“把这段又臭又长的逻辑拆一下”AI很难把它们关联起来。排查方法是反过来设计description用用户会说的话来写。不要用技术文档式描述要用“任务意图”式描述。描述写完后做一次“最小匹配测试”模拟五种不同措辞看能不能触发。不能触发就一直改这比事后给AI补指令高效得多。6.3 AI无视契约、强行改测试或绕断言这个问题比较棘手因为它触及AI的“讨好模式”。当模型看到“测试失败”与“用户想要通过”这两个信号同时存在时它有时会优先取巧比如弱化断言、把异常吞掉、把错误直接返回成成功状态。我的应对策略分两层。第一层是技术约束在工程规范里明确规定测试文件是不可变文件并把测试目录设置为只读权限。AI一旦尝试修改直接操作失败从而被强制回到实现路径。第二层是提示约束在工作流技能里写明“若发现契约与实现冲突应停下输出冲突点而不是擅自改动契约”。冲突暴露出来由人来裁决这才是工程的做法。6.4 长任务执行到一半上下文丢失导致动作漂移AI编程助手处理长时间多步骤任务时经常会出现“前半段守纪律后半段放飞自我”的问题。要么是早期记住的契约细节被遗忘要么是开始添加“看起来不相关但似乎合理”的额外功能。我最常用的解法是“契约文件常驻可见”。不要让AI只在启动时读一次契约而是把契约文件路径写在它的系统上下文里让它在每轮代码生成前重新读取。此外每完成一个子步骤就让它生成一行“进度标识”把当前状态同步回对话上下文。这相当于给AI建了路标避免跑偏。7. 经验收尾让AI在边界内激进与AI协作这几年我最大的体会是AI最可怕的不是能力不足而是没有边界感的幻觉式自信。Superpowers技能框架解决的是“流程的边界”TDD契约驱动解决的是“逻辑的边界”工程纪律闭环解决的是“反馈的边界”。三者合在一起效果不是简单地“减少代码雪崩”而是重塑了AI参与开发的姿势。最后再分享一个操作层面的细节。每次任务结束我都会要求AI把本次的决策记录追加到技能的SKILL.md末尾格式固定在“场景—决策—原因”三列。这个习惯坚持下来技能库会越来越懂你的项目AI也会越来越像团队里那个懂规矩、肯沉淀的老伙计。代码雪崩不是AI带来的它是一直潜伏在缺乏纪律的开发流程里的老问题。既然工具给了我们重新设计流程的机会就别把它浪费成一场大型氛围体验。