“测试全绿代码却烂到推倒重来”这个场景最近在 AI 编程工作流里出现得越来越频繁。可能的过程是开发者把需求丢给 AIAI 一口气生成了实现代码和配套单元测试本地一跑全部通过覆盖率也不低于是直接提 PR。到了评审阶段或者联调阶段才发现逻辑与真实需求完全错位边界条件根本没处理团队成员只能把整个模块推倒重来。危险的点不在于 AI 写错了而在于它用一套“看起来很专业的测试”掩盖了问题让人误以为质量已经被验证过了。今天这篇文章不讨论怎么让 AI 写出更多代码而是讨论怎么避免 AI 写出的代码成为下一个技术债炸弹。我会用一个订单折扣计算的完整反例拆解“测试全绿”背后隐藏的回音室测试、弱断言、语义错位三大问题再给出可以直接套用的 AI 编程提示词模板、测试策略、评审返工边界以及一套可落地的 AI 编程工作流。这篇文章适合正在用 AI 辅助编程、会把 AI 生成代码直接放进项目的人也适合负责代码评审和架构决策的开发者。如果你经历过“AI 代码跑通了但没人敢维护”的状态这篇文章可以直接收藏。1. 什么是“测试全绿但代码烂”先给结论测试全绿只说明一件事就是当前这组测试断言全部通过了。它不能证明代码满足需求不能证明代码边界健壮也不能证明代码在真实业务场景里可以运行。测试通过是质量下限不是质量保障。在实际项目里“代码烂”通常体现在四个层面。第一是结构烂。AI 可能在一个函数里堆出几百行逻辑命名混乱、职责不清、抽象过度或抽象不足导致后续任何改动都需要通读上下文。第二是语义烂。AI 对业务规则的理解有偏差比如把“满 100 减 20”实现成“满 100 打 8 折”把“金卡会员打 9 折”实现成“有金卡标识就打 8 折”。单元测试如果来自 AI 自己生成的实现就会按照错误语义去断言。第三是边界烂。空值、负数、超长文本、并发请求、精度问题这些场景在 AI 生成的代码里很容易被忽略。测试只覆盖了 happy path边界条件完全没有被验证。第四是维护烂。AI 不理解项目的历史背景和代码风格生成结果可能与整体架构冲突引入不必要的依赖或全新的设计模式导致维护成本陡增。“测试全绿但代码烂”真正可怕的地方在于它把问题藏在了绿灯的假象后面。测试通过似乎证明了一切正常实际上只是证明 AI 的测试和 AI 的实现互相印证。这种代码如果直接进入主干等到集成交付时才发现问题返工成本比“一开始就不通过”要高得多。从适用场景看这套问题主要出现在“需求没有拆解清楚、测试由 AI 自写自证、开发者对 AI 输出过度信任”的工作流里。如果你只是拿 AI 做原型验证或一次性脚本“全绿但烂”的影响尚可容忍如果这是生产代码、对账逻辑、支付链路问题会被成倍放大。另外要注意AI 生成代码可能涉及版权和合规风险尤其在公司项目里不能盲目复制来源不明或 AI 拼接出的代码片段必须确认组织对 AI 生成代码的使用政策。2. AI 编程最容易出现的三类“假绿”不是所有全绿都是假绿但有三种情况非常容易在 AI 编程场景出现。2.1 回音室测试所谓回音室测试就是 AI 先写了一个实现然后根据这个实现反向生成测试用例测试只是为了验证实现里已经写死的判断分支。整个过程中真实需求并没有被拆解成可验证的契约测试和实现互相复读。这类测试的典型特征是测试数量看似不少分支覆盖率可能也很高但把需求文档拿出来对照会发现很多关键输入根本没测过。比如 AI 实现了一个calculate_discount(price, quantity, member_level)函数测试用例只覆盖了它内部存在的if分支却没覆盖“quantity10 的边界”“会员等级大小写”“非法等级抛异常”这类真正的业务约束。在这种情况下全绿没有任何意义。要打破回音室不能依赖 AI 自己生成测试而应该由开发人员先根据需求列出边界和契约让 AI 按这些用例去实现。如果 AI 先给实现也必须由人重新写一组独立的需求级测试而不是用 AI 给的测试做最终验证。2.2 断言太弱很多 AI 生成的测试喜欢写“函数不报错就通过”的弱断言。看起来是测试实际上只检查了返回值存在没有检查返回值正确。举一个常见的例子def test_discount_returns_float(): result calculate_discount(100, 1, gold) assert isinstance(result, float)这个测试全绿但它完全没有验证折扣是否正确、金卡是否真的打了 9 折、金额是否保留了两位小数。更弱一点的断言还会写成assert result is not None那就更难发现问题。AI 生成弱断言是因为它更关注“让测试通过”而不是“验证真实业务规则”。人在评审时不能只看测试文件里有多少个def test_而要看每个测试是否对结果做了精确断言。数值计算要有精确期望值异常路径要有pytest.raises边界值要同时覆盖临界点的两侧。2.3 需求语义错位这是最隐蔽也最致命的一种情况。AI 对自然语言的理解能力很强但对业务规则的“言外之意”理解有限。一个需求写着“数量满 10 件打 85 折金卡会员再打 9 折”AI 可能很自然地理解成两个条件互斥只要满足一个就返回而不是叠加计算。当实现和测试都基于同一套错误理解时测试全绿是必然的。只有把需求真正转换成测试用例并且把“叠加”“互斥”“取最大值”“取最小值”这类关系在提示词里显式写清楚才能避免语义错位。为什么 AI 编程场景更容易踩这个坑因为 AI 生成速度快开发者倾向相信结果因为 AI 看不到整个项目上下文容易忽略全局约束还因为生成代码看起来结构完整、有注释、有测试天然降低人的警惕性。后面第三部分会用一个完整例子说明问题怎么一步步被掩盖。3. 反例完整复盘一次让团队推倒重来的订单折扣实现假设需求是实现一个订单折扣计算函数输入单价、数量和会员等级输出原价总额、折后总额、总折扣率和折扣原因。业务规则如下单价必须大于等于 0数量必须大于 0否则抛出ValueError。数量大于等于 10 时原价总额打 85 折。金卡会员打 9 折铂金会员打 8 折。数量折扣与会员折扣可以叠加。会员等级忽略大小写非法等级抛出ValueError。金额保留两位小数。3.1 AI 初版实现把需求简单描述后丢给 AIAI 在几秒内给出了这样的代码def calculate_discount(price, quantity, member_level): if price 100: return price * 0.9 if quantity 10: return price * 0.85 if member_level gold: return price * 0.8 return price这个版本从任何角度看都是错的没有校验参数没有乘以数量三个if是互斥关系而不是叠加关系金卡折扣写成了 0.8和需求要求的 0.9 不一致金额没有保留两位小数单价满 100 触发折扣的条件也是凭空捏造的。3.2 AI 配套生成的测试关键是AI 还生成了配套测试而且这些测试会全部通过def test_high_price_discount(): assert calculate_discount(100, 1, normal) 90 def test_quantity_discount(): assert calculate_discount(50, 10, normal) 42.5 def test_gold_member_discount(): assert calculate_discount(50, 1, gold) 40 def test_no_discount(): assert calculate_discount(50, 1, normal) 50测试全绿了但问题非常明显test_high_price_discount验证的是“单价满 100 打 9 折”这个规则需求里根本没有。test_quantity_discount期望值是 42.5这是50 * 0.85的结果没有乘数量和“原价总额”语义不一致。test_gold_member_discount期望值是 40恰恰验证了错误实现里price * 0.8的 bug。四个测试没有一个覆盖参数非法、等级大小写、数量边界、折扣叠加。表面上测试覆盖率很高实际上每条断言都在复读错误实现。这就是典型的“测试全绿代码烂到推倒重来”。3.3 理清需求后的正确重构在引入 AI 编程时第一版代码烂不可怕可怕的是测试没有发现问题。下面这个版本把需求逐条落地并且用类型和结构约束了函数行为from dataclasses import dataclass from enum import Enum class MemberLevel(Enum): NORMAL normal GOLD gold PLATINUM platinum dataclass(frozenTrue) class DiscountResult: original_amount: float final_amount: float discount_rate: float reason: str def calculate_discount(price: float, quantity: int, member_level: str) - DiscountResult: if not isinstance(price, (int, float)) or not isinstance(quantity, int): raise TypeError(price must be int/float, quantity must be int) if price 0 or quantity 0: raise ValueError(price must be 0, quantity must be 0) try: level MemberLevel(member_level.lower()) except ValueError: raise ValueError(funknown member_level: {member_level}) original_amount price * quantity rate 1.0 reasons [] if quantity 10: rate * 0.85 reasons.append(quantity10) level_rates { MemberLevel.GOLD: 0.9, MemberLevel.PLATINUM: 0.8, } if level in level_rates: rate * level_rates[level] reasons.append(f{level.value}_discount) final_amount round(original_amount * rate, 2) reason_text .join(reasons) if reasons else no_discount return DiscountResult( original_amountoriginal_amount, final_amountfinal_amount, discount_rateround(rate, 4), reasonreason_text, )3.4 由人主导的严格测试重构之后的测试不再由 AI 自说自话而是完全从需求出发覆盖边界、异常和核心规则import pytest from discount import calculate_discount, MemberLevel, DiscountResult def test_quantity_over_ten_only(): result calculate_discount(price50, quantity10, member_levelnormal) assert result.original_amount 500 assert result.final_amount 425.0 assert result.discount_rate 0.85 assert result.reason quantity10 def test_gold_member_with_quantity_discount(): result calculate_discount(price50, quantity10, member_levelgold) assert result.original_amount 500 assert result.final_amount 382.5 assert result.discount_rate 0.765 assert result.reason quantity10 gold_discount def test_zero_price_is_allowed(): result calculate_discount(price0, quantity1, member_levelnormal) assert result.original_amount 0 assert result.final_amount 0 def test_invalid_quantity_rejected(): with pytest.raises(ValueError): calculate_discount(price10, quantity0, member_levelnormal) def test_member_level_is_case_insensitive(): result calculate_discount(price100, quantity1, member_levelGOLD) assert result.final_amount 90.0 def test_unknown_member_level_rejected(): with pytest.raises(ValueError): calculate_discount(price100, quantity1, member_levelvip) def test_mutation_detects_wrong_gold_rate(): # 如果实现把 gold 折扣写成 0.8这个断言会失败 result calculate_discount(price100, quantity1, member_levelgold) assert result.final_amount 90.0对比初版测试这一组测试的最大差异是每条断言都能定位到一条真实需求。这里的test_mutation_detects_wrong_gold_rate还用了变异测试的思路故意设想实现里有一个错误折扣率验证测试能否发现。这类测试才能真正拦住烂代码。4. AI 编程提示词怎么写很多人以为 AI 编程翻车是因为模型能力不够其实提示词边界是否清晰往往比模型本身更能决定结果。下面给出一套可以套用的提示词模板核心原则是先让 AI 输出测试用例再让它写实现。任务实现订单折扣计算函数 calculate_discount。 功能需求 1. 入参为 price(float)、quantity(int)、member_level(str)。 2. price 必须大于等于 0quantity 必须大于 0否则抛出 ValueError。 3. 数量大于等于 10 时原价总额打 85 折。 4. 会员等级 gold 打 9 折platinum 打 8 折normal 不打折。 5. 数量折扣与会员折扣可以叠加。 6. 会员等级忽略大小写非法等级抛出 ValueError。 7. 返回 DiscountResult包含原价总额、折后总额、总折扣率、折扣原因。 8. 金额保留两位小数。 约束 - 不要引入缓存、异步、类继承、第三方依赖。 - 命名保持简单逻辑优先于抽象。 - 先输出覆盖上述需求的 pytest 测试用例再输出实现代码。 - 如果需求有歧义先列出 3 个问题再写代码。这段提示词里有几个关键点。第一把边界条件显性化。price 0、quantity 0、忽略大小写、非法等级抛异常这些都是 AI 凭自然语言理解容易遗漏的细节。拿到“边界条件清单”的 AI生成质量会明显提升。第二要求先输出测试用例。提示词里明确写了“先输出 pytest 测试用例再输出实现代码”这会把 AI 从“自证正确”模式切换到“按契约实现”模式。你可以在测试用例阶段就人工纠正而不是等实现代码全生成之后再统一检查。第三限定抽象范围。“不要引入缓存、异步、类继承、第三方依赖”这条在生成复杂业务代码时非常管用。AI 有很强的过度设计倾向一条简单业务逻辑也会被包出三层继承。限制它的实现自由度能大幅降低评审负担。第四让 AI 在歧义时提问。很多 AI 编码工具支持多轮对话你可以在提示词里加一句“如果有歧义先列出问题”。这能避免 AI 把错误假设直接写进代码。如果你用了 Cursor、Copilot 这类 AI 编程工具可以把这段模板沉淀成项目级指令让 AI 后续每次生成代码都默认遵守。同样重要的是不要在一个提示词里塞太多功能一次只让 AI 完成一个函数或一个组件能显著提高可控性。5. 测试策略怎么拦住烂代码提示词写好了AI 生成的代码只是“起点更好”不代表可以直接合入。真正决定代码能不能用的是测试策略和评审机制。5.1 测试先行而不是实现先行正确的顺序是人先写需求级测试AI 再写实现。如果条件不允许至少要让人重新根据需求补写测试不能用 AI 给的测试当作最终验证。需求级测试和实现级测试的最大区别是前者从接口契约和业务规则出发后者从实现代码的分支出发。拿上面的订单折扣函数来说你可以在提示词里要求 AI 先生成测试也可以在本地先用 pytest 写好一组边界用例再让 AI 基于这些用例补全实现。后者更符合 TDD 思路对 AI 的输出约束力最强。5.2 边界值清单要覆盖真实业务一个通用的边界值检查清单至少包括0、负数、空字符串、None、超长文本、特殊字符、极大数、极小数、浮点精度、并发重复请求、数据库中不存在的主键、第三方接口超时。真实业务里还要额外关注金额计算的精度、时区转换、闰年、节假日、小数点四舍五入、同一用户重复下单。AI 生成的代码往往只覆盖正常路径所以你需要在测试里人工补齐这些容易出事的输入。5.3 增加契约测试和集成测试单元测试只能证明一个函数在隔离环境里的行为证明不了它和其他模块配合时依然正确。如果 AI 生成的代码要调用内部服务、数据库、第三方 API要先用契约明确输入输出格式再用契约测试保证接口语义没有被 AI 悄悄修改。最典型的问题就是 AI 把方法签名改了比如把price从float改成Decimal或者把返回类型从DiscountResult改成tuple。如果调用方代码没有跟着改编译器不会报错但运行结果已经完全变化。契约测试能在第一道防线拦住这种情况。5.4 用变异测试思路验证断言强度变异测试的思想是故意改错一行实现代码比如把0.9改成0.8然后跑一遍测试。如果测试没有失败说明现有断言没有覆盖到这个关键行为。你不用引入完整的变异测试框架只需要在评审时人工抽查几行核心逻辑手动改错跑一次测试就够了。上面重构后的test_mutation_detects_wrong_gold_rate就是这个思路的直接应用。这个步骤能快速暴露“测试全绿但决策逻辑没被验证”的问题。5.5 把检查规则沉淀到 CI 批处理当你人工发现一类问题就应该把它转成自动化校验。比如规定所有新增代码必须包含参数校验、必须覆盖边界值、必须通过契约测试然后把规则写进 CI 脚本。这篇文章讨论的是一套 AI 编程工程实践不是某个外部 API 服务所以我不会给出具体的接口调用示例。但核心思路是把检查规则变成批处理任务让每次提交都自动跑一遍。无论 AI 生成了多少代码只要 CI 里挂满需求级测试、契约测试和静态检查烂代码就很难混进主干。6. 评审与重写什么时候该返工测试全绿不能阻止推倒重来评审机制才能帮你判断“该修还是该重写”。这里给一个比较实用的判断标准。6.1 什么情况该修如果 AI 生成的代码只是局部逻辑错误接口契约没问题需求理解也没问题修复成本在十几行以内那就直接修改不需要重写。典型场景包括参数校验漏掉了一个条件、某个分支的返回值写错、命名不符合项目规范、缺少类型标注。这类问题边界清晰修起来风险低重要的是修复后要有测试把问题钉死避免 AI 再次生成同样的错误。6.2 什么情况该重写如果出现下面这些信号建议推倒重写而不是在烂代码上打补丁需求语义完全错位AI 实现的业务规则和文档对不上。边界值大面积缺失依赖测试逐条补会花太多时间。架构上有根本性错误比如应该用接口抽象却写死在实现里或者所有逻辑堆在一个函数里。代码与现有系统风格严重冲突后续每个维护者都要花额外精力理解。AI 引入了不必要的复杂抽象比如一行逻辑被包装成三层类继承。从成本角度看重写也不一定比修补更贵。如果修补需要理解一堆 AI 产生的混乱逻辑改完也不知道有没有引入隐藏 bug那直接基于清晰测试用例重写反而更稳。重写时AI 生成的初版可以作为参考但不能作为基础。6.3 用 AI 辅助评审但人来决策AI 也能用来评审 AI 生成的代码。你可以把代码贴回对话问几个针对性问题这段代码在哪些输入下会崩溃这个函数是否违反了单一职责有没有隐藏的并发问题这里的异常处理是否合理这段代码能否在不改变接口的情况下简化AI 辅助评审的价值在于“快速找疑点”但它同样可能漏判或误判。最终是否修改、是否重写必须由人来决策。尤其是支付、权限、安全相关逻辑AI 输出只能作为草稿人工 review 必须多轮进行。6.4 重写时的成本控制如果真的走到推倒重来这一步不要直接删代码。先把 AI 生成的代码保存到分支或备份文件里作为思路参考再把需求拆成清晰的测试用例最后从核心逻辑开始重新实现。这样即使第二次 AI 生成仍然不理想你也已经积累了完整的需求级测试整个重写过程是可控的。重写不是浪费时间它是一次把需求、边界和测试彻底对齐的机会。7. 可落地的 AI 编程工作流与效果验证把前面所有方法整合成一套工作流可以这样执行。7.1 七步工作流拆任务。每个任务控制在 5 到 20 分钟内可以完成 review 的规模不要一次性让 AI 生成整个模块。写契约和边界条件。明确输入输出、异常规则、精度要求。要求 AI 先输出测试用例。这一步可以在提示词里完成也可以在本地用 pytest 先写好。人工确认测试用例。确认每条用例都能对应到一条真实需求并且覆盖了边界。让 AI 生成实现代码。按照第 4 节的提示词模板执行。本机运行测试并人工评审。不要跳过评审尤其要关注实现是否偏离了测试契约。合入 CI。CI 里跑完整的需求级测试、契约测试和静态检查发现失败立即回到第 5 步修复。这套流程会让 AI 的角色从“代码生成器”变成“结对编程助手”人的角色从“复制代码”变成“定义契约和做最终决策”。7.2 如何验证工作流是否有效判断一套工作流有没有用可以统计四个指标AI 代码返工率即评审不过需要重写的比例。测试失败率即提交到 CI 后被红灯拦下的比例。评审问题数每次评审平均发现的问题数量。线上事故率部署后暴露出来的问题数量。建议从项目里挑一个业务逻辑集中、容易出边界问题的模块用这套流程跑两周。记录问题类型的变化第一周可能集中在需求和边界缺失第二周应该能看到 AI 生成代码的质量明显提升。另外每次发现问题就补充一条测试用例到项目里。这样 AI 再生成相似代码时CI 里的需求级测试会自动帮忙把关而不是每次都要人工重新解释一遍需求。8. 常见问题与排查方法下面整理一份常见问题排查表方便在 AI 编程工作流里快速定位问题。问题现象可能原因排查方式解决方案测试全绿但评审发现逻辑错提示词只描述了功能没描述业务规则和边界对照需求文档检查测试用例在提示词中补齐边界条件让 AI 先写测试再写实现AI 生成的测试和实现互相印证测试由 AI 在实现后补写形成了回音室抽查测试断言是否覆盖到关键需求改为由人先写需求级测试或要求 AI 先输出测试再实现覆盖率接近 100% 仍有 bug测试只覆盖实现细节没有覆盖需求语义用变异测试思路改错关键逻辑跑一次测试补充需求级断言增加边界值用例代码推倒重来太频繁任务拆得太大AI 一次性生成的代码量超出可审查范围检查每次生成的代码量把任务拆成 5 到 20 分钟内可 review 的小块AI 生成代码与项目风格不一致提示词里没给项目规范和代码示例对比现有模块的写法在提示词中加入项目风格要求或参考代码片段不确定 AI 生成代码是否合规没有检查代码来源和许可证查询生成代码的来源、确认公司政策来源不明时重写敏感业务必须人工 review这里最容易被忽略的是最后一行。AI 生成代码可能来自训练数据中的既有代码片段直接复制进商业项目会带来版权和许可证风险。建议在团队层面形成规则生产代码必须经过来源检查和合规确认不能因为测试全绿就直接合入。9. 最佳实践与合规提醒最后把值得长期坚持的实践和边界提醒放在一起。第一小步提交。一次 AI 生成任务的粒度控制在 5 到 20 分钟内可以完成 review 的规模。任务越小评审越容易出问题后定位也越快。第二让 AI 先给方案再做实现。在编码之前先让 AI 用自然语言描述它将如何设计这个函数、会遇到哪些边界情况、异常如何处理。方案确认后再让它写代码能提前拦下很多设计错误。第三一个 PR 只做一个主题。不要在一个 PR 里混入多个 AI 生成的功能否则评审人很难逐条验证。主题集中回滚也安全。第四人工 review 不可替代。AI 能生成代码、能写测试、能辅助分析但它没有业务上下文也无法为线上事故负责。支付、权限、安全、数据一致性相关代码必须进行多轮人工审查。第五确认 AI 生成代码的合规性。公司项目要遵守组织对 AI 编程工具的规章制度不要直接复制来源不明的整段代码也不要盲目信任 AI 生成的第三方依赖版本。第六记录和复盘。每次 AI 代码返工记录失败原因每次测试覆盖到新边界把测试用例沉淀到 CI 里。AI 编程是一个持续迭代的过程不是换一个更强模型就能解决所有问题。总结与下一步“测试全绿”和“代码可维护”是两件事。测试全绿是底线不是目标真正的目标是人能理解这套代码、能安全修改这套代码、能保证它在真实业务场景里稳定运行。AI 生成只是起点不是终点。如果你今天只做一件事建议拿当前正在开发的某个模块把边界条件补进提示词要求 AI 先输出测试用例再生成实现然后跑一轮变异测试看看你现有的测试能不能发现被故意改错的逻辑。大概率会发现之前的“全绿”并不像表面上那么可靠。AI 编程最大的坑不是模型不够聪明而是我们过早相信了“测试通过”这个信号。把需求、测试、评审这些工程环节重新牢牢握在自己手里AI 才能真正从“快速制造问题”变成“快速解决问题”。
