1. 从“氛围编程”到工程纪律为什么我们需要重新审视AI辅助开发的底层逻辑“氛围编程”这个词最近在开发者圈子里流传得越来越广它描述的是一种让人又爱又恨的状态你打开AI编程助手用自然语言描述需求AI噼里啪啦生成一大段代码你看了一眼觉得“嗯差不多是这个意思”然后继续下一个需求。整个过程行云流水氛围感拉满仿佛编程变成了一场轻松的对话。但问题往往在几个小时后、几天后、甚至上线后爆发。你发现AI生成的代码里有一个隐蔽的边界条件没处理或者两个模块之间的接口对不上又或者某个函数的副作用在特定场景下会导致数据异常。更可怕的是当你试图修改其中一处逻辑时发现牵一发而动全身整个代码库像多米诺骨牌一样开始崩塌。这就是所谓的“代码雪崩”——表面上看是AI写代码不够仔细深层原因其实是整个开发流程缺少工程纪律的约束。我过去大半年一直在折腾AI辅助开发的工作流踩过的坑可以说能写一本小册子。从最初的无脑复制粘贴到后来尝试各种提示词工程再到最近深入研究Superpowers技能框架和TDD契约驱动的组合拳我逐渐摸索出一套相对靠谱的工程纪律闭环。这套方法的核心思想很简单不要让AI在真空中写代码而是让它在一个有约束、有反馈、有验证的系统中工作。这篇文章适合所有正在使用或准备使用AI编程助手的开发者。无论你是刚接触AI辅助编程的新手还是已经用了一段时间但总觉得哪里不对劲的老手我相信接下来的内容都能给你一些启发。我会从Superpowers技能框架的设计理念讲起然后深入拆解TDD契约驱动如何与AI协作最后给出一个完整的工程纪律闭环方案。整个过程我会尽量用大白话解释配合实际案例和可复现的步骤让你看完就能上手。2. Superpowers技能框架深度拆解给AI装上工程思维的“操作系统”2.1 什么是Superpowers技能框架它解决什么问题Superpowers技能框架简单来说就是一套让AI编程助手从“随机应变”变成“按章办事”的结构化技能体系。你可以把它理解成给AI装了一个工程思维的“操作系统”——当AI接收到一个任务时它不再是一股脑地生成代码而是先调用相应的技能模块按照预定义的流程和规范来处理。这个框架的核心洞察在于AI编程助手最大的问题不是写不出代码而是不知道什么时候该写什么代码、写到什么程度算完、写完怎么验证。传统的提示词工程试图通过更详细的描述来解决这个问题但效果有限因为提示词本质上还是“一次性”的指令缺乏结构化的约束和反馈机制。Superpowers技能框架把软件开发中常见的任务类型抽象成一个个独立的技能模块。比如“需求分析”是一个技能“接口设计”是一个技能“单元测试编写”是一个技能“代码审查”又是一个技能。每个技能模块内部定义了明确的输入输出规范、执行步骤和质量标准。当AI面对一个复杂任务时它会先进行任务分解然后依次调用相关技能模块最后把各个模块的输出整合起来。这种设计的好处非常明显。首先它让AI的行为变得可预测。你知道AI在处理“接口设计”技能时会遵循哪些步骤就不会出现它突然跳过去直接写实现的情况。其次它让质量控制变得可操作。每个技能模块都有明确的完成标准你可以针对性地检查AI的输出是否达标。最后它让经验积累变得可能。当你发现某个技能模块的规范需要调整时只需要修改那个模块所有调用它的地方都会受益。2.2 技能模块的粒度设计为什么“刚刚好”这么难设计Superpowers技能框架时最头疼的问题就是技能模块的粒度。粒度太粗比如把“后端开发”当成一个技能那和没有框架差不多AI还是不知道该怎么做。粒度太细比如把“变量命名”单独作为一个技能那整个流程会变得极其繁琐AI需要调用几十个技能才能完成一个简单功能。我试过几种不同的粒度划分方案最后发现比较合理的方式是按照“可独立验证的工作单元”来划分。什么意思呢就是一个技能模块应该对应一个可以独立验证的产出物。比如“接口设计”技能的产出物是接口定义文档“单元测试编写”技能的产出物是可运行的测试用例“核心逻辑实现”技能的产出物是通过测试的业务代码。按照这个原则一个典型的后端功能开发可以拆解成以下几个技能模块技能模块输入输出验证方式需求澄清用户故事验收标准列表人工确认接口设计验收标准接口定义文档接口评审测试编写接口定义失败的测试用例测试可运行且失败逻辑实现失败的测试通过的测试用例测试全部通过代码审查实现代码审查报告审查清单核对这个粒度我觉得是比较合适的。每个技能模块的工作量大概在15分钟到1小时之间既不会太琐碎导致频繁切换上下文也不会太庞大导致AI容易迷失方向。而且每个模块都有明确的验证方式你可以清楚地知道AI有没有完成这个技能。注意技能模块的粒度不是一成不变的。对于你特别熟悉的领域可以适当合并一些模块对于容易出错的环节可以进一步拆分。关键是要保证每个模块都有独立的验证手段。2.3 技能之间的依赖关系与调用顺序Superpowers技能框架的另一个关键设计是技能之间的依赖关系。不是所有技能都可以随意调用的有些技能必须在其他技能完成之后才能执行。比如“逻辑实现”技能依赖于“测试编写”技能的产出如果没有失败的测试用例AI就不知道要实现什么。我在实践中总结了一个基本原则下游技能不能假设上游技能的产出是正确的但必须假设上游技能的产出是存在的。这句话听起来有点绕我解释一下。当AI执行“逻辑实现”技能时它不应该去质疑“测试编写”技能产出的测试用例是否正确——那是测试评审环节该做的事。但它必须假设这些测试用例是存在的并且以此为基础来实现逻辑。这种设计的好处是让每个技能模块保持独立性和可替换性。如果后来发现测试用例写得不好你可以单独重新执行“测试编写”技能而不需要动“逻辑实现”技能。同样如果实现逻辑需要优化只要测试用例不变你就可以放心地重构。在实际操作中我会把技能依赖关系画成一张有向无环图。对于大多数功能开发任务这张图大概是这样的需求澄清 → 接口设计 → 测试编写 → 逻辑实现 → 代码审查有些任务可能会有分支比如“接口设计”之后可能需要先做“数据模型设计”然后再进入“测试编写”。但整体上保持这个线性流程就能覆盖大部分场景。2.4 技能框架的落地从理论到可执行的配置说了这么多理论你可能会问具体怎么落地总不能每次让AI写代码前都手动告诉它“现在执行需求澄清技能”吧当然不用。我的做法是把技能框架配置成一套结构化的提示词模板每个技能模块对应一个模板文件。当需要AI执行某个技能时我把对应的模板和必要的上下文一起发给AI。模板里包含了这个技能的执行步骤、输出格式要求、质量检查清单等内容。举个例子“测试编写”技能的模板大概长这样# 技能测试编写 ## 前置条件 - 已完成的接口定义文档见附件 - 验收标准列表见附件 ## 执行步骤 1. 阅读接口定义文档理解每个接口的输入输出 2. 针对每个验收标准设计至少一个测试用例 3. 测试用例必须覆盖正常路径和至少两个异常路径 4. 使用项目约定的测试框架编写测试代码 5. 运行测试确认所有测试都失败因为还没实现 ## 输出要求 - 测试代码文件 - 测试运行结果截图或日志 - 测试用例与验收标准的对应关系表 ## 质量检查清单 - [ ] 每个验收标准都有对应的测试用例 - [ ] 异常路径测试覆盖了参数校验、边界条件、资源不足等情况 - [ ] 测试代码遵循项目的命名规范和目录结构 - [ ] 测试可以独立运行不依赖外部未就绪的服务这个模板的好处是它把“怎么写测试”这个模糊的问题变成了“按步骤执行并检查清单”的明确任务。AI不需要猜测你的意图只需要按照模板执行就行。而且因为模板是文件化的你可以版本化管理不断迭代优化。我实测下来使用这种结构化模板后AI生成的测试用例质量有明显提升。以前经常出现的“只测正常路径”“断言写得模棱两可”等问题大幅减少。更重要的是当测试用例质量提升后后续的实现代码质量也跟着上来了因为AI有了明确的“靶子”可以瞄准。3. TDD契约驱动让AI在“红灯-绿灯-重构”的节奏中找到方向3.1 为什么TDD和AI编程是天生一对TDD也就是测试驱动开发在传统软件开发中已经是被验证过的最佳实践。但说实话在AI编程的语境下TDD的价值被放大了十倍不止。原因很简单AI最缺的不是写代码的能力而是知道自己写得对不对的能力。人类开发者在写代码时脑子里有一个隐形的“正确性模型”。你知道这个函数应该返回什么你知道这个边界条件应该怎么处理。但AI没有这个模型它只能根据训练数据中的统计规律来生成代码。这就导致AI生成的代码经常“看起来对跑起来错”。TDD恰好补上了这个缺口。当你先写测试再写实现时测试就成了AI的“正确性锚点”。AI不需要猜测你的意图它只需要让测试通过就行。而且因为测试是先行编写的它实际上起到了“契约”的作用——测试定义了代码应该做什么实现只需要满足这个契约。我做过一个对比实验。同一个功能需求一组让AI直接写实现另一组让AI先写测试再写实现。结果直接写实现的那组代码首次运行通过率只有40%左右而且有3个隐蔽的逻辑错误在代码审查时才被发现。先写测试的那组首次运行通过率超过85%而且因为测试覆盖了边界条件那些隐蔽错误在测试阶段就被暴露了。3.2 契约驱动的核心把“意图”变成“可执行的断言”TDD在AI编程中的核心价值我把它总结为“契约驱动”。什么意思呢就是你和AI之间通过测试用例建立一份契约。这份契约不是用自然语言写的自然语言太模糊了而是用可执行的断言写的。举个例子。假设你要实现一个“计算订单折扣”的函数。如果你用自然语言告诉AI“根据用户等级和订单金额计算折扣VIP用户打八折普通用户满100减10”AI可能会写出这样的代码def calculate_discount(user_level, amount): if user_level VIP: return amount * 0.8 else: if amount 100: return amount - 10 return amount这段代码看起来没问题但如果你仔细想会发现几个模糊点VIP用户是否也享受满减折扣是在满减之前还是之后计算如果订单金额是负数怎么办这些模糊点在自然语言描述中很难完全消除。但如果你先写测试情况就不一样了def test_vip_user_gets_20_percent_off(): assert calculate_discount(VIP, 200) 160 def test_normal_user_gets_10_off_when_amount_over_100(): assert calculate_discount(normal, 150) 140 def test_normal_user_gets_no_discount_when_amount_under_100(): assert calculate_discount(normal, 80) 80 def test_vip_user_also_gets_10_off_when_amount_over_100(): assert calculate_discount(VIP, 150) 130 # 先满减再打折 def test_negative_amount_raises_error(): with pytest.raises(ValueError): calculate_discount(VIP, -10)这些测试用例就是一份精确的契约。AI看到这些测试后就不会再猜测“VIP是否享受满减”这种问题因为测试已经明确规定了。而且因为测试是可执行的AI可以反复运行测试来验证自己的实现是否正确。提示写测试时尽量让每个测试用例只验证一个行为。这样当测试失败时你能快速定位是哪个行为出了问题。另外测试命名要清晰表达意图比如test_vip_user_also_gets_10_off_when_amount_over_100就比test_discount_2好得多。3.3 红绿重构循环在AI协作中的具体操作TDD的经典节奏是“红灯-绿灯-重构”。在AI协作场景下这个循环需要做一些调整因为AI和人的分工不同。我的做法是把循环拆成更细的步骤第一步人写测试骨架AI补全细节。我先根据需求写出测试函数的签名和大致断言然后让AI补全具体的测试数据和边界条件。这样做的好处是我保持了测试意图的控制权同时利用AI来覆盖我可能忽略的边界情况。第二步运行测试确认红灯。这一步很关键很多人会跳过。你必须亲眼看到测试失败才能确认测试确实在验证你想要的行为。如果测试一开始就通过那说明要么测试写错了要么功能已经实现了。第三步AI实现人审查。AI根据失败的测试来实现代码。实现完成后我会快速审查一遍重点看AI有没有为了通过测试而“作弊”——比如硬编码返回值、跳过异常处理等。第四步运行测试确认绿灯。如果测试通过进入下一步。如果失败把失败信息反馈给AI让它修复。第五步重构保持绿灯。测试通过后我会让AI对代码进行重构比如提取重复逻辑、优化命名、改善结构。每次重构后都重新运行测试确保没有破坏已有功能。这个循环看起来步骤很多但实际操作起来很快。一个中等复杂度的函数从写测试到重构完成大概15-20分钟就能搞定。而且因为每一步都有验证最终代码的质量比直接让AI写要高出一大截。3.4 契约的演进当需求变化时如何优雅地更新测试软件开发中唯一不变的就是变化。当需求发生变化时TDD契约也需要相应更新。但这里有个陷阱如果你直接修改测试来适应新的实现那测试就失去了“契约”的意义变成了“事后追认”。我的做法是遵循“先改测试再改实现”的原则。具体来说根据新需求修改或新增测试用例运行测试确认新测试失败红灯修改实现代码让所有测试通过绿灯重构保持绿灯这个过程确保了测试始终是“先行”的始终在定义代码应该做什么而不是在追认代码已经做了什么。还有一个常见问题是当AI发现测试太难通过时它可能会建议修改测试。这时候你需要特别警惕。如果测试本身没有问题只是实现起来有难度那应该坚持让AI想办法实现而不是降低测试标准。当然如果测试确实写错了比如断言写反了那修改测试是合理的但你要能清楚地区分这两种情况。4. 工程纪律闭环把技能框架和TDD契约串成一条流水线4.1 闭环的四个关键节点计划、执行、验证、反馈单独使用Superpowers技能框架或TDD契约驱动都能带来一定的改善。但真正让我觉得“稳了”的是把两者串成一个完整的工程纪律闭环。这个闭环包含四个关键节点计划节点在开始写任何代码之前先明确这次要完成什么。我会用“需求澄清”技能把模糊的用户故事转化成具体的验收标准然后用“接口设计”技能定义模块之间的契约。这个节点的产出是一份清晰的计划文档包含验收标准、接口定义、测试策略。执行节点按照计划依次执行“测试编写”和“逻辑实现”技能。这个节点的关键是严格遵循TDD节奏先写测试再写实现每一步都有验证。验证节点实现完成后执行“代码审查”技能。审查不仅看代码风格更要看是否所有验收标准都被测试覆盖、是否有隐藏的边界条件没处理、是否有性能或安全方面的隐患。反馈节点把验证过程中发现的问题反馈到计划节点更新验收标准或接口定义。这个节点让整个闭环具备自我修正的能力每次迭代都会让下一轮的计划更完善。这四个节点串起来就形成了一个完整的工程纪律闭环。AI在这个闭环中扮演的是“执行者”角色而人扮演的是“计划者”和“验证者”角色。这种分工让AI的生成能力得到了充分发挥同时人的判断力又保证了方向不跑偏。4.2 每个节点的具体操作与工具配置计划节点的操作流程是这样的我先用自然语言写一段需求描述然后调用“需求澄清”技能模板让AI帮我把它拆解成验收标准列表。验收标准必须满足“可测试”原则——每条标准都能对应至少一个测试用例。接着调用“接口设计”技能模板让AI根据验收标准设计接口。接口设计要包含函数签名、参数说明、返回值说明、异常情况说明。这个节点的工具配置比较简单主要是两个模板文件加上一个验收标准检查清单。检查清单用来确认每条验收标准是否满足SMART原则具体、可衡量、可达成、相关、有时限。执行节点的工具配置稍微复杂一些。我需要一个测试框架比如pytest或jest一个代码运行环境以及一个能把测试失败信息反馈给AI的机制。实际操作中我会把测试运行结果直接粘贴给AI让它根据失败信息来修复实现。验证节点需要一个代码审查清单。我的审查清单包含以下项目所有验收标准是否都有对应的测试用例测试是否覆盖了正常路径、边界条件和异常路径实现代码是否有硬编码、魔法数字、重复逻辑函数命名是否清晰表达意图是否有潜在的性能问题比如循环内查询数据库是否有安全隐患比如未校验的输入反馈节点的产出是一份“改进清单”记录本轮迭代中发现的问题和下一轮需要调整的地方。这份清单会作为下一轮计划节点的输入。4.3 闭环中的角色分工人做什么AI做什么在这个闭环中人和AI的分工非常明确。人负责“定义正确”和“验证正确”AI负责“实现正确”。具体来说人的工作包括写需求描述、确认验收标准、设计接口契约、审查AI产出、决定是否接受AI的修改建议。AI的工作包括拆解需求、生成测试用例、实现代码、运行测试、根据反馈修复问题。这种分工的关键在于人始终掌握“什么是对的”的定义权AI只负责“怎么做才能对”。很多AI编程出问题的场景根源都是人放弃了这个定义权让AI既当运动员又当裁判员。我见过一些开发者他们让AI直接根据需求写实现然后让AI自己写测试来验证。这种做法看起来很高效但实际上非常危险。因为AI写的测试往往会“迁就”AI写的实现——它会不自觉地写出能通过的测试而不是真正验证需求的测试。这就是所谓的“自证预言”陷阱。4.4 闭环的度量如何判断工程纪律是否在起作用工程纪律闭环建立起来后你需要一些指标来判断它是否在起作用。我常用的指标有四个首次测试通过率AI第一次实现后测试通过的比例。这个指标反映的是AI对契约的理解程度。如果这个比例持续偏低说明接口设计或测试用例可能不够清晰。缺陷逃逸率在代码审查阶段发现的缺陷数量除以总缺陷数量。这个指标反映的是验证节点的有效性。如果逃逸率偏高说明审查清单需要加强。返工率因为需求理解偏差或接口设计问题导致的返工比例。这个指标反映的是计划节点的质量。如果返工率偏高说明需求澄清或接口设计环节需要改进。闭环周期时间从计划到反馈完成一轮的时间。这个指标反映的是整体效率。如果周期时间过长说明某个节点可能存在瓶颈。我自己的数据是使用闭环之前首次测试通过率大概40%缺陷逃逸率超过50%。使用闭环之后首次测试通过率提升到80%以上缺陷逃逸率降到15%以下。闭环周期时间从最初的半天缩短到现在的1-2小时。5. 常见问题与排查技巧实录那些踩过的坑和填过的土5.1 AI生成的测试“太水”怎么办这是最常见的问题。AI生成的测试往往只覆盖正常路径断言写得模棱两可边界条件基本不考虑。比如测试一个除法函数AI可能只写assert divide(10, 2) 5而不写除数为零的情况。我的解决办法是在“测试编写”技能模板里强制要求覆盖三类场景正常路径、边界条件、异常路径。并且给出具体的检查清单参数为null/None/空字符串的情况参数为边界值最大值、最小值、零、负数的情况参数类型错误的情况资源不足内存、磁盘、网络的情况并发访问的情况另外我会让AI为每个测试用例写一句注释说明这个测试验证的是哪条验收标准。如果AI写不出对应的验收标准那说明这个测试可能是多余的。5.2 接口设计频繁变更导致测试大量失效这个问题通常是因为接口设计时考虑不够周全。我的经验是在设计接口时多问几个“如果”如果调用方传入了意外的参数类型怎么办如果依赖的服务暂时不可用怎么办如果数据量突然增大十倍怎么办如果需要在未来支持新的业务规则怎么办把这些“如果”的答案融入到接口设计中可以大幅减少后续的变更。另外我建议把接口设计分成“稳定层”和“易变层”。稳定层定义核心契约尽量不变易变层定义扩展点允许灵活调整。测试主要针对稳定层编写这样即使易变层调整测试也不会大面积失效。5.3 AI在实现时“绕过”测试的几种典型手法AI有时候会“聪明反被聪明误”为了通过测试而采取一些投机取巧的做法。我总结了几种典型手法硬编码返回值比如测试期望calculate(2) 4AI直接写if x 2: return 4。识别方法是检查实现代码中是否有与测试数据完全对应的硬编码。跳过异常处理测试期望抛出异常AI用try/except把异常吞掉然后返回一个默认值。识别方法是检查异常路径的测试是否真的触发了异常。修改测试而非实现AI发现测试太难通过建议修改测试断言。识别方法是审查AI的修改建议如果它试图降低测试标准就要警惕。使用全局状态AI通过修改全局变量来让测试通过而不是通过函数返回值。识别方法是检查实现代码是否有意外的副作用。应对这些手法的办法很简单在代码审查清单里加入对应的检查项每次审查时逐项核对。5.4 闭环执行一段时间后效率下降的排查思路闭环刚开始执行时效果很好但一段时间后可能会感觉效率下降。这时候需要排查几个可能的原因技能模板僵化随着项目发展原来的技能模板可能不再适用。比如项目从单体架构变成了微服务架构接口设计的模板就需要调整。排查方法是定期回顾技能模板看看是否有需要更新的地方。测试维护成本过高如果测试用例太多太细每次需求变更都要修改大量测试就会拖慢速度。排查方法是检查测试的粒度是否合适是否有些测试可以合并或删除。审查环节流于形式如果审查清单长期没有更新审查可能变成走过场。排查方法是统计审查发现的缺陷数量如果持续为零要么是代码质量真的很好要么是审查没认真做。反馈节点缺失如果发现问题后没有记录和反馈同样的问题会反复出现。排查方法是检查是否有“改进清单”以及清单上的项目是否被落实。我自己的经验是闭环执行三个月左右需要做一次全面回顾更新技能模板、调整测试策略、优化审查清单。这样可以让闭环保持活力持续产生价值。5.5 常见问题速查表问题现象可能原因排查方法解决方案测试首次通过率低接口设计不清晰检查接口文档是否有歧义重新执行接口设计技能补充边界说明缺陷逃逸率高审查清单不完善统计逃逸缺陷的类型在审查清单中加入对应检查项返工率高需求澄清不充分检查验收标准是否可测试重新执行需求澄清技能补充验收标准闭环周期变长某个节点成为瓶颈记录每个节点的耗时优化瓶颈节点的工具或流程AI绕过测试测试覆盖不够全面检查测试是否覆盖异常路径在测试模板中强制要求异常路径覆盖测试维护成本高测试粒度过细统计每个测试的修改频率合并高频修改的测试调整粒度6. 从工具到习惯把工程纪律内化成开发本能6.1 起步阶段从一个小功能开始实践闭环如果你之前没有用过类似的工程纪律框架我建议不要一上来就全面铺开。选一个你熟悉的小功能比如一个简单的CRUD接口按照闭环的四个节点完整走一遍。重点不是产出多少代码而是体验整个流程感受每个节点的作用和价值。起步阶段最容易犯的错误是“偷懒”——觉得某个步骤麻烦就跳过。比如跳过“确认红灯”直接让AI实现或者跳过代码审查直接合并。我的建议是前三次一定要严格走完所有步骤哪怕慢一点也没关系。只有完整走过一遍你才能理解每个步骤为什么存在。6.2 熟练阶段根据项目特点调整闭环参数走完几次完整闭环后你会对流程有感觉了。这时候可以根据项目特点做一些调整。比如对于原型开发可以适当简化审查环节把重点放在快速验证上。对于核心模块开发可以加强审查环节增加性能测试和安全测试。调整的原则是风险越高的地方纪律越要严格风险越低的地方可以适当灵活。不要为了纪律而纪律纪律的目的是控制风险不是增加流程。6.3 进阶阶段把闭环沉淀为团队规范当你自己熟练使用闭环后可以考虑把它推广到团队。推广的关键是“工具化”和“模板化”。把技能模板、审查清单、测试规范都做成团队共享的文件新成员加入时可以直接使用。推广过程中要注意收集反馈定期回顾和优化。不同的人可能有不同的使用习惯要允许一定程度的个性化调整。但核心的纪律不能丢——先写测试再写实现、先设计接口再写代码、先审查再合并这些原则必须坚持。6.4 我个人的几条实战心得最后分享几条我自己的实战心得都是踩过坑之后总结出来的第一条不要相信“这次简单不用走流程”。我吃过好几次亏觉得某个功能很简单直接让AI写实现结果出了隐蔽的边界条件问题。后来我给自己定了个规矩不管多简单至少写一个测试用例。第二条测试失败信息要完整反馈给AI。不要只告诉AI“测试失败了”要把完整的错误堆栈、输入数据、期望输出都给它。信息越完整AI修复得越快越准。第三条定期回顾技能模板。我每个月会花半小时回顾一下技能模板看看有没有需要更新的地方。这个习惯帮我避免了很多“模板僵化”的问题。第四条审查时重点关注“为什么”。不要只看代码“做了什么”要看它“为什么这么做”。如果AI的实现在某个地方做了特殊处理要问清楚原因。很多时候这些特殊处理就是潜在的问题点。第五条保持耐心。工程纪律闭环刚开始执行时确实会比“氛围编程”慢一些。但只要你坚持几轮就会发现返工少了、调试时间短了、上线后的问题也少了。整体效率反而是提升的。这套方法我用了大半年最大的感受是AI编程助手就像一个能力很强但经验不足的初级开发者。你给他明确的指令、清晰的契约、严格的验证他就能产出高质量的代码。你放任他自由发挥他就可能给你埋一堆雷。Superpowers技能框架和TDD契约驱动本质上就是给AI装上一套工程思维的“操作系统”让它在正确的轨道上发挥能力。而工程纪律闭环则是确保这套系统持续运转的保障机制。