1. AI提效300%背后的烂摊子先还原我遇到的那次事故1.1 一次看起来正常的线上事故复盘上周五晚上A同学把一版营销模块的PR推给我附带一句这次有Copilot帮忙快得很。我打开diff代码确实写得很干净注释也补得很完整单测也是绿的。但我在生产日志里翻了十分钟就找到了一个隐患优惠券库存在这种写法下会被并发请求打穿。原始代码大致长这样def distribute_coupon(user_id, coupon_id): quota get_quota(coupon_id) if quota 0: quota - 1 update_quota(coupon_id, quota) grant_coupon(user_id, coupon_id) return True return False粗看没有大问题先查库存再扣库存再发券。可问题是查库存和扣库存之间不是原子的。两个请求同时进来都读到 quota1都通过了 if最后库存变成0但券发出去两张。生产环境里库存、积分、余额这类资源一旦有并发写这种写法几乎必出问题。Copilot其实也帮忙优化过一版它加了行锁和事务def distribute_coupon(user_id, coupon_id): with db.transaction(): quota get_quota(coupon_id, lockTrue) if quota 0: return False decrease_quota(coupon_id) return grant_coupon(user_id, coupon_id)看着是不是专业多了但真正的问题并没有消失它仍然没有校验这个用户是否已经领过同一张券、没有校验用户是否在黑名单里、也没有处理grant_coupon失败但库存已经扣掉的回滚场景。我那天晚上专门让A同学去查用户表果然发现同一批活动里有用户重复领了两张。这不是Copilot的锅而是审查环节的锅。代码是AI写的但review它的人默认了AI写的应该没问题。1.2 3倍速写代码审查却还是1倍速很多人喊AI提效300%这个数字是怎么来的通常是用原来要写两小时的代码现在半小时写完了来算的。但提效只发生在生成代码这个环节后续的审查、测试、修Bug、上线监控一点都没变快甚至在变慢。原因很简单人类review自己写的代码时天然知道哪些地方可能是自己考虑不周的地方会带着怀疑去看。但review Copilot生成的代码时我们更容易把它当成外部专家给的答案默认它是对的。一旦这个默认成立审查就变成了走过场最关键的边界条件、业务语义、架构约束反而没有人认真看了。我见过不少团队PR的通过时间从平均一天缩短到两小时但上线后的故障率不降反升。效率提了3倍烂摊子也扩大到3倍只是烂摊子要等到上线后才显现出来。所以AI提效300%这个提法本质上是把成本从写代码转移到了修代码如果没有一套针对AI生成代码的审查机制提效越快埋雷越多。2. 盲区一AI的自信和人的自信叠在一起Review变成了点头机器2.1 流畅感是怎么骗过审阅者的这里有个很反直觉的心理现象一段代码越流畅、越漂亮、注释越完整review的人就越不认真。人类大脑会把表述流畅等同于内容正确因为平时我们读到通顺的文字时很少需要停下来怀疑它。Copilot生成代码的风格恰恰就是流畅、完整、没有任何犹豫它不会像新手那样写出乱糟糟的草稿也不会在代码里留下这里不确定的痕迹。这就像你问一个专家问题专家用非常笃定的语气给了你一个错误答案你反而比听到一个犹豫的答案更容易采信。Copilot在代码里展现出的自信会掩盖它其实没有真正理解上下文的事实。我举个例子。有个同事需要写一个取当天零点的工具函数Copilot给了他这样的代码const startOfDay new Date(new Date().setHours(0, 0, 0, 0));看起来没有任何问题跑起来也是当天零点。但只要服务器的时区是UTC而业务用户都在东八区这个零点就不是用户的零点而是伦敦的零点。线上很多报表数据错位、日期边界统计错误根源就是这类看起来对但假设错了的代码。人类review时会自然想到这个日期到底应该取哪个时区但Copilot只会根据你的代码风格生成一个通用正确的答案。这种通用正确的代码在数据库索引上也经常翻车。Copilot看到某个字段出现在where条件里就会建议加个索引但它不知道这张表已经有一个联合索引能覆盖这个查询也不知道这个字段的区分度低到加索引根本没用。审查的人看到加了索引这种标准优化动作往往会直接通过结果线上非但没有变快反而多了一个浪费空间、拖慢写入的冗余索引。2.2 我总结的反向审查自检清单后来我给团队定了一条纪律凡是AI生成的代码必须用反向审查的方式看也就是默认它有错再去想办法证明它有错。具体动作我整理成了一张清单代码表现需要警惕的问题函数只有3行且没有参数校验是不是把校验逻辑藏进了调用方调用方真的校验了吗用了通用工具类或全局单例是否符合当前项目的分层约束是不是绕过领域层直接操作了基础设施没有任何异常处理异常发生时资源会不会泄漏事务会不会悬挂注释非常完整注释是不是在解释代码做了什么而不是为什么这么做看起来优化过加了锁、缓存、异步这个优化是业务需要的还是AI自己脑补的我自己的经验是看到一段代码特别完美反而要花双倍时间去看它的边界。先试着把它弄坏——比如传一个空对象、传一个负数、模拟一次数据库超时、把时间调到跨年的最后一秒——如果它扛不住说明审查还不够。举个例子一个看起来人畜无害的日期转换函数你把时区改成UTC8以外的值跑一下可能立刻暴露出偏移问题一个看起来万无一失的缓存读取你把缓存服务临时停掉可能就会发现它根本没考虑降级。不要被代码写得好迷惑要去想什么情况下它会出错这才是审查AI代码的正确姿势。3. 盲区二代码逻辑看起来对业务语义却没人替你把关3.1 AI会写代码但不懂你的业务Copilot这类的AI编程助手本质上是一个语言模型它擅长的是根据上下文补全看起来合理的代码而不是理解你的业务规则。业务上的很多规则是隐性的某个字段在老系统里代表的意思和字面不同、某种情况下需要走审批流、某些用户类型不能享受折扣……这些信息不会出现在函数名里也不会出现在注释里但review代码的人应该知道。举个例子。一个订单模块需要计算税费业务规则是金额超过一定阈值后分段计税并且对某些渠道的商品免税。Copilot生成的版本可能长这样def calc_tax(amount, rate0.13): return round(amount * rate, 2)单看代码它没错是一个标准的乘法加四舍五入。但它完全没有体现分段和免税渠道这两个关键业务规则。更麻烦的是它看起来太正常了审查的人可能会忽略去对照需求文档。很多人review时只看代码内部逻辑自洽却忘了问这段代码真的实现了需求吗。还有一个我踩过的坑有次我们要做一个新客专属优惠券的发放接口业务规则是只有从未下过单的新客才能领。Copilot生成的代码里判断逻辑写成只要用户没有领过这张券就能领它把新客理解成了没领过券的人。代码本身没有语法错误测试也过了但上线后老用户全都能领到新客券运营活动预算直接被打穿。这就是典型的业务语义缺失AI不知道新客在系统里还有一个独立的判定标准而review的人被逻辑合理带偏了没有逐字去对需求文档。3.2 先把需求翻译成边界条件再让AI动手我现在的做法是在让AI写代码之前先把需求翻译成一张边界条件表然后把它作为审查的输入。比如还是税费这个功能我会先列出来场景输入期望输出普通商品金额100amount100按13%计税输出13.00免税渠道商品channelfree输出0跨档金额比如超过5000部分税率不同amount6000前5000按13%后1000按更高税率负数或0元退款场景amount-10抛异常或返回0不能算出负数税费有了这张表再来review Copilot生成的代码就不是看代码对不对而是跑测试用例过不过。代码可能写得花团锦簇但只要表里的场景有一个过不了就该打回去重写。这一步不要省。因为AI生成代码时你的需求描述越模糊它越会输出通用正确的代码而通用正确恰恰等于对你的业务不正确。把边界条件喂给它既是给它约束也是给审查人一个独立的参考标准。我还建议把这张表直接变成测试用例写进代码仓库里。比如用表格里的负数退款场景去测试一个简单的计税函数你会立刻发现它返回了一个负数税费这显然不符合业务直觉。多写几个这种业务语义测试AI生成的代码就算写得再漂亮也会被机器拦在第一道关卡根本走不到人工Review这一步。毕竟人的注意力是有限的你不能指望一个忙了一天的开发在晚上11点还能靠肉眼发现新客判断条件写错了这种隐藏很深的业务偏差。4. 盲区三AI生成的标准答案正在制造结构性技术债4.1 隐式依赖和看不见的假设前两个盲区更多是单次代码的问题第三个盲区更隐蔽它会慢慢腐蚀整个项目的架构AI生成的代码往往自带一大堆隐式假设。它假设某个全局变量存在、假设某个第三方库已经装好、假设某个配置项有默认值、假设某段代码的执行顺序。这些假设在单独看一个函数的时候完全看不出来但组合在一起就成了定时炸弹。我们项目里就出过这么一件事。Copilot在生成日志上报功能时自动引用了项目里一个顺手封装好的全局客户端但那个客户端只适用于内部服务调用不支持外部请求带上业务ID。结果日志全部打到了默认分组排查链路断了大半天。代码没有语法错误也没有测试失败纯粹是它自作主张选了看起来最省事的实现路径。这类问题靠review单次PR很难发现因为它符合现有代码风格也用了现有的工具类问题在于用错了语义。后来我们给团队加了一条硬约束AI生成的代码必须回答四个问题——它依赖了哪些外部组件它在哪里读取配置它有没有修改全局状态它跟现有的架构分层是否一致回答不上来就不允许合入。我还遇到过一个更典型的情况 Copilot生成了一段HTTP客户端调用代码直接写死了内网服务地址和一个固定的超时时间。它的依据可能是项目里某个老接口这么写过于是理所当然地复制了这种写法。但新服务的部署环境完全不同内网地址也是动态分配的这段代码一到新环境就全部超时。这种看起来有依据实际上没有验证的隐式假设是AI生成代码里最难防的一类。4.2 技术债的复利三个月后没人敢动这段代码技术债最可怕的地方是复利。第一周你只是觉得某段函数有点绕第二周有人模仿这段代码又写了一段类似的第三周出现了三种风格完全不同的类似实现第四周新的需求来了没人知道该改哪一段因为改任何一段都可能影响另外两段。AI把这段过程大大加速了因为它特别擅长生成风格统一的样板代码让团队在Review时放松警惕这些样板代码又会像种子一样迅速扩散。我见过一个从第三个月开始返工的项目线上Bug越来越多排查发现在核心链路里AI生成的代码重复实现了几十次校验库存的逻辑而且每种实现处理并发的方式都不一样。改了一个另外几个还在用老的、有竞态的逻辑。最后没办法只能抽出一周时间统一重构。如果只看单次PR每一段代码都说得过去但从系统层面看这些代码就是一堆互不相认的复制品维护成本爆炸式增长。这件事给了我一个教训审查AI代码不能只看一次提交还要看它在整个代码库里的扩散方式。如果同一个工具函数被复制了五份说明prompt里缺少复用现有函数的约束如果代码风格和项目规范不一致说明AI没有吃到足够的项目上下文。这些都要在审查阶段拦截而不是等它变成看不见的坑。我甚至会让团队在review时顺手用代码扫描工具查一下重复率一旦发现新增重复代码超过阈值就直接打回不管功能对不对。5. 让Copilot审查不埋雷我后来改用的可落地流程5.1 审查前置先把验收标准写进Prompt很多人用Copilot时只给一句帮我写一个XX功能然后坐等代码。这样生成的代码大概率是通用正确的。我现在会让需求方先写清楚验收标准再把这些标准直接放进prompt里让AI在写代码时就知道该遵守什么。一个比较靠谱的prompt模板是这样的请按以下要求实现[函数名]输入用户ID、优惠券ID输出发放成功返回true失败返回false且失败时不允许扣减库存约束同一用户对同一张券只能领取一次并发请求时库存不能为负发放操作必须和扣减在同一个事务里不允许调用未在项目依赖中声明的第三方库请复用[现有工具函数名]这样写AI生成的方向会被收敛很多review时也有了明确的依据不是靠直觉判断代码对不对而是逐条对照验收标准。我实际测试过明确写了失败时不允许扣减库存之后AI生成的回滚逻辑立刻完整了很多明确写了请复用现有工具函数之后它就不会再自己造一个新轮子。Prompt里的约束关系往往比你在代码审查时苦口婆心说十句都管用。5.2 三层审查业务语义、逻辑正确、代码风格我后来把审查过程拆成了三层每一层都安排不同的人来做避免一个人既看业务又看逻辑又看风格最后什么都看不细。审查层关注点谁来审第一层业务语义代码是否实现了需求文档中的规则边界条件表是否覆盖熟悉业务的产品或资深开发第二层逻辑正确并发、事务、空值、时区、异常回滚等技术正确性后端/对应技术方向的开发第三层代码风格是否复用现有函数命名是否一致有没有额外引入依赖任何有经验的同学用现有规范核对大多数团队的问题是这三层全挤在一个CR通过里。AI代码一多大家根本没时间同时想三件事于是默认既然测试过了大概没问题。分层以后至少每个问题都有明确的负责人漏网之鱼会少很多。这里有个小技巧第一层业务语义审查尽量安排在代码提交后的24小时内趁业务上下文还没凉第三层风格审查可以交给自动化工具先筛一遍人只处理机器不能判断的部分。5.3 给AI划边界一次只生成一个函数禁止自由发挥还有一个经验就是别让Copilot一次生成一大片代码。它的自信在大范围生成时最容易翻车因为上下文越长它越容易自洽地编造一些不存在的约束。我现在规定一次只让它写一个函数或者一个模块并且明确告诉它不要额外优化不要擅自引入设计模式不要修改非相关代码。一开始团队觉得这样做效率会变低但实际跑了两星期后大家都认同慢一点点但返工率明显下降。AI真正的提效不在于一次写出整个系统而在于让你把时间从敲键盘转移到看清楚问题上。如果它生成的东西有一半要返工那3倍速的快就是假的。我现在跟团队说得很直接Copilot是一次性的生成器不是一个可以对你的项目负责的程序员它把初稿写出来剩下的审查、改错、补边界条件才是我们真正的价值所在。5.4 让自动化测试替人肉背锅说一千道一万人的注意力是有限的与其靠自觉不如把边界条件变成自动化测试。我建议每段AI生成的核心逻辑至少配套以下测试正常路径输入合法数据验证输出边界路径0值、负数、最大值、空对象、空数组异常路径数据库超时、外部接口失败、事务回滚并发路径模拟多个请求同时到达。把这些测试写进CI里每次PR触发。这样review的人不需要在脑子里模拟所有场景机器会先帮他筛一遍。真正到了人工审查阶段人只需要聚焦业务语义和架构兼容性这两个AI最容易出问题、也最难测试的部分。我们团队现在的规矩是AI生成的代码不允许裸奔上线至少要有边界和异常两类测试兜底。这个规矩执行了两个月线上因为并发、空值、回滚导致的故障明显变少了。5.5 一张可以直接抄进团队规约的审查清单最后把我现在用的检查项整理成一张可复制的清单团队想直接用的照着抄就行[ ] 是否有验收标准有没有对应的边界条件表[ ] 该函数是否对应唯一一个明确的功能点而不是顺手改了不相关的逻辑[ ] 是否有隐式依赖全局变量、第三方库、配置文件[ ] 并发场景是否考虑读改写的原子性、锁、事务边界[ ] 失败场景是否会留下脏数据是否有补偿/回滚[ ] 是否有与业务规则相悖的通用正确实现[ ] 是否复用了现有工具函数而不是复制粘贴了第五份实现[ ] 测试是否覆盖了正常、边界、异常、并发四类场景我在实际使用中的感受是Copilot这类工具本身不是问题问题在于很多人把它当成了写完即正确的自动完成器。只要审查流程跟上让它生成代码时先交代清楚边界、依赖和验收标准它带来的效率提升确实是可以落地的。怕就怕AI提效300%审查原地踏步那300%的收益迟早会连本带利还给故障和重构。
1. AI提效300%背后的烂摊子先还原我遇到的那次事故1.1 一次看起来正常的线上事故复盘上周五晚上A同学把一版营销模块的PR推给我附带一句这次有Copilot帮忙快得很。我打开diff代码确实写得很干净注释也补得很完整单测也是绿的。但我在生产日志里翻了十分钟就找到了一个隐患优惠券库存在这种写法下会被并发请求打穿。原始代码大致长这样def distribute_coupon(user_id, coupon_id): quota get_quota(coupon_id) if quota 0: quota - 1 update_quota(coupon_id, quota) grant_coupon(user_id, coupon_id) return True return False粗看没有大问题先查库存再扣库存再发券。可问题是查库存和扣库存之间不是原子的。两个请求同时进来都读到 quota1都通过了 if最后库存变成0但券发出去两张。生产环境里库存、积分、余额这类资源一旦有并发写这种写法几乎必出问题。Copilot其实也帮忙优化过一版它加了行锁和事务def distribute_coupon(user_id, coupon_id): with db.transaction(): quota get_quota(coupon_id, lockTrue) if quota 0: return False decrease_quota(coupon_id) return grant_coupon(user_id, coupon_id)看着是不是专业多了但真正的问题并没有消失它仍然没有校验这个用户是否已经领过同一张券、没有校验用户是否在黑名单里、也没有处理grant_coupon失败但库存已经扣掉的回滚场景。我那天晚上专门让A同学去查用户表果然发现同一批活动里有用户重复领了两张。这不是Copilot的锅而是审查环节的锅。代码是AI写的但review它的人默认了AI写的应该没问题。1.2 3倍速写代码审查却还是1倍速很多人喊AI提效300%这个数字是怎么来的通常是用原来要写两小时的代码现在半小时写完了来算的。但提效只发生在生成代码这个环节后续的审查、测试、修Bug、上线监控一点都没变快甚至在变慢。原因很简单人类review自己写的代码时天然知道哪些地方可能是自己考虑不周的地方会带着怀疑去看。但review Copilot生成的代码时我们更容易把它当成外部专家给的答案默认它是对的。一旦这个默认成立审查就变成了走过场最关键的边界条件、业务语义、架构约束反而没有人认真看了。我见过不少团队PR的通过时间从平均一天缩短到两小时但上线后的故障率不降反升。效率提了3倍烂摊子也扩大到3倍只是烂摊子要等到上线后才显现出来。所以AI提效300%这个提法本质上是把成本从写代码转移到了修代码如果没有一套针对AI生成代码的审查机制提效越快埋雷越多。2. 盲区一AI的自信和人的自信叠在一起Review变成了点头机器2.1 流畅感是怎么骗过审阅者的这里有个很反直觉的心理现象一段代码越流畅、越漂亮、注释越完整review的人就越不认真。人类大脑会把表述流畅等同于内容正确因为平时我们读到通顺的文字时很少需要停下来怀疑它。Copilot生成代码的风格恰恰就是流畅、完整、没有任何犹豫它不会像新手那样写出乱糟糟的草稿也不会在代码里留下这里不确定的痕迹。这就像你问一个专家问题专家用非常笃定的语气给了你一个错误答案你反而比听到一个犹豫的答案更容易采信。Copilot在代码里展现出的自信会掩盖它其实没有真正理解上下文的事实。我举个例子。有个同事需要写一个取当天零点的工具函数Copilot给了他这样的代码const startOfDay new Date(new Date().setHours(0, 0, 0, 0));看起来没有任何问题跑起来也是当天零点。但只要服务器的时区是UTC而业务用户都在东八区这个零点就不是用户的零点而是伦敦的零点。线上很多报表数据错位、日期边界统计错误根源就是这类看起来对但假设错了的代码。人类review时会自然想到这个日期到底应该取哪个时区但Copilot只会根据你的代码风格生成一个通用正确的答案。这种通用正确的代码在数据库索引上也经常翻车。Copilot看到某个字段出现在where条件里就会建议加个索引但它不知道这张表已经有一个联合索引能覆盖这个查询也不知道这个字段的区分度低到加索引根本没用。审查的人看到加了索引这种标准优化动作往往会直接通过结果线上非但没有变快反而多了一个浪费空间、拖慢写入的冗余索引。2.2 我总结的反向审查自检清单后来我给团队定了一条纪律凡是AI生成的代码必须用反向审查的方式看也就是默认它有错再去想办法证明它有错。具体动作我整理成了一张清单代码表现需要警惕的问题函数只有3行且没有参数校验是不是把校验逻辑藏进了调用方调用方真的校验了吗用了通用工具类或全局单例是否符合当前项目的分层约束是不是绕过领域层直接操作了基础设施没有任何异常处理异常发生时资源会不会泄漏事务会不会悬挂注释非常完整注释是不是在解释代码做了什么而不是为什么这么做看起来优化过加了锁、缓存、异步这个优化是业务需要的还是AI自己脑补的我自己的经验是看到一段代码特别完美反而要花双倍时间去看它的边界。先试着把它弄坏——比如传一个空对象、传一个负数、模拟一次数据库超时、把时间调到跨年的最后一秒——如果它扛不住说明审查还不够。举个例子一个看起来人畜无害的日期转换函数你把时区改成UTC8以外的值跑一下可能立刻暴露出偏移问题一个看起来万无一失的缓存读取你把缓存服务临时停掉可能就会发现它根本没考虑降级。不要被代码写得好迷惑要去想什么情况下它会出错这才是审查AI代码的正确姿势。3. 盲区二代码逻辑看起来对业务语义却没人替你把关3.1 AI会写代码但不懂你的业务Copilot这类的AI编程助手本质上是一个语言模型它擅长的是根据上下文补全看起来合理的代码而不是理解你的业务规则。业务上的很多规则是隐性的某个字段在老系统里代表的意思和字面不同、某种情况下需要走审批流、某些用户类型不能享受折扣……这些信息不会出现在函数名里也不会出现在注释里但review代码的人应该知道。举个例子。一个订单模块需要计算税费业务规则是金额超过一定阈值后分段计税并且对某些渠道的商品免税。Copilot生成的版本可能长这样def calc_tax(amount, rate0.13): return round(amount * rate, 2)单看代码它没错是一个标准的乘法加四舍五入。但它完全没有体现分段和免税渠道这两个关键业务规则。更麻烦的是它看起来太正常了审查的人可能会忽略去对照需求文档。很多人review时只看代码内部逻辑自洽却忘了问这段代码真的实现了需求吗。还有一个我踩过的坑有次我们要做一个新客专属优惠券的发放接口业务规则是只有从未下过单的新客才能领。Copilot生成的代码里判断逻辑写成只要用户没有领过这张券就能领它把新客理解成了没领过券的人。代码本身没有语法错误测试也过了但上线后老用户全都能领到新客券运营活动预算直接被打穿。这就是典型的业务语义缺失AI不知道新客在系统里还有一个独立的判定标准而review的人被逻辑合理带偏了没有逐字去对需求文档。3.2 先把需求翻译成边界条件再让AI动手我现在的做法是在让AI写代码之前先把需求翻译成一张边界条件表然后把它作为审查的输入。比如还是税费这个功能我会先列出来场景输入期望输出普通商品金额100amount100按13%计税输出13.00免税渠道商品channelfree输出0跨档金额比如超过5000部分税率不同amount6000前5000按13%后1000按更高税率负数或0元退款场景amount-10抛异常或返回0不能算出负数税费有了这张表再来review Copilot生成的代码就不是看代码对不对而是跑测试用例过不过。代码可能写得花团锦簇但只要表里的场景有一个过不了就该打回去重写。这一步不要省。因为AI生成代码时你的需求描述越模糊它越会输出通用正确的代码而通用正确恰恰等于对你的业务不正确。把边界条件喂给它既是给它约束也是给审查人一个独立的参考标准。我还建议把这张表直接变成测试用例写进代码仓库里。比如用表格里的负数退款场景去测试一个简单的计税函数你会立刻发现它返回了一个负数税费这显然不符合业务直觉。多写几个这种业务语义测试AI生成的代码就算写得再漂亮也会被机器拦在第一道关卡根本走不到人工Review这一步。毕竟人的注意力是有限的你不能指望一个忙了一天的开发在晚上11点还能靠肉眼发现新客判断条件写错了这种隐藏很深的业务偏差。4. 盲区三AI生成的标准答案正在制造结构性技术债4.1 隐式依赖和看不见的假设前两个盲区更多是单次代码的问题第三个盲区更隐蔽它会慢慢腐蚀整个项目的架构AI生成的代码往往自带一大堆隐式假设。它假设某个全局变量存在、假设某个第三方库已经装好、假设某个配置项有默认值、假设某段代码的执行顺序。这些假设在单独看一个函数的时候完全看不出来但组合在一起就成了定时炸弹。我们项目里就出过这么一件事。Copilot在生成日志上报功能时自动引用了项目里一个顺手封装好的全局客户端但那个客户端只适用于内部服务调用不支持外部请求带上业务ID。结果日志全部打到了默认分组排查链路断了大半天。代码没有语法错误也没有测试失败纯粹是它自作主张选了看起来最省事的实现路径。这类问题靠review单次PR很难发现因为它符合现有代码风格也用了现有的工具类问题在于用错了语义。后来我们给团队加了一条硬约束AI生成的代码必须回答四个问题——它依赖了哪些外部组件它在哪里读取配置它有没有修改全局状态它跟现有的架构分层是否一致回答不上来就不允许合入。我还遇到过一个更典型的情况 Copilot生成了一段HTTP客户端调用代码直接写死了内网服务地址和一个固定的超时时间。它的依据可能是项目里某个老接口这么写过于是理所当然地复制了这种写法。但新服务的部署环境完全不同内网地址也是动态分配的这段代码一到新环境就全部超时。这种看起来有依据实际上没有验证的隐式假设是AI生成代码里最难防的一类。4.2 技术债的复利三个月后没人敢动这段代码技术债最可怕的地方是复利。第一周你只是觉得某段函数有点绕第二周有人模仿这段代码又写了一段类似的第三周出现了三种风格完全不同的类似实现第四周新的需求来了没人知道该改哪一段因为改任何一段都可能影响另外两段。AI把这段过程大大加速了因为它特别擅长生成风格统一的样板代码让团队在Review时放松警惕这些样板代码又会像种子一样迅速扩散。我见过一个从第三个月开始返工的项目线上Bug越来越多排查发现在核心链路里AI生成的代码重复实现了几十次校验库存的逻辑而且每种实现处理并发的方式都不一样。改了一个另外几个还在用老的、有竞态的逻辑。最后没办法只能抽出一周时间统一重构。如果只看单次PR每一段代码都说得过去但从系统层面看这些代码就是一堆互不相认的复制品维护成本爆炸式增长。这件事给了我一个教训审查AI代码不能只看一次提交还要看它在整个代码库里的扩散方式。如果同一个工具函数被复制了五份说明prompt里缺少复用现有函数的约束如果代码风格和项目规范不一致说明AI没有吃到足够的项目上下文。这些都要在审查阶段拦截而不是等它变成看不见的坑。我甚至会让团队在review时顺手用代码扫描工具查一下重复率一旦发现新增重复代码超过阈值就直接打回不管功能对不对。5. 让Copilot审查不埋雷我后来改用的可落地流程5.1 审查前置先把验收标准写进Prompt很多人用Copilot时只给一句帮我写一个XX功能然后坐等代码。这样生成的代码大概率是通用正确的。我现在会让需求方先写清楚验收标准再把这些标准直接放进prompt里让AI在写代码时就知道该遵守什么。一个比较靠谱的prompt模板是这样的请按以下要求实现[函数名]输入用户ID、优惠券ID输出发放成功返回true失败返回false且失败时不允许扣减库存约束同一用户对同一张券只能领取一次并发请求时库存不能为负发放操作必须和扣减在同一个事务里不允许调用未在项目依赖中声明的第三方库请复用[现有工具函数名]这样写AI生成的方向会被收敛很多review时也有了明确的依据不是靠直觉判断代码对不对而是逐条对照验收标准。我实际测试过明确写了失败时不允许扣减库存之后AI生成的回滚逻辑立刻完整了很多明确写了请复用现有工具函数之后它就不会再自己造一个新轮子。Prompt里的约束关系往往比你在代码审查时苦口婆心说十句都管用。5.2 三层审查业务语义、逻辑正确、代码风格我后来把审查过程拆成了三层每一层都安排不同的人来做避免一个人既看业务又看逻辑又看风格最后什么都看不细。审查层关注点谁来审第一层业务语义代码是否实现了需求文档中的规则边界条件表是否覆盖熟悉业务的产品或资深开发第二层逻辑正确并发、事务、空值、时区、异常回滚等技术正确性后端/对应技术方向的开发第三层代码风格是否复用现有函数命名是否一致有没有额外引入依赖任何有经验的同学用现有规范核对大多数团队的问题是这三层全挤在一个CR通过里。AI代码一多大家根本没时间同时想三件事于是默认既然测试过了大概没问题。分层以后至少每个问题都有明确的负责人漏网之鱼会少很多。这里有个小技巧第一层业务语义审查尽量安排在代码提交后的24小时内趁业务上下文还没凉第三层风格审查可以交给自动化工具先筛一遍人只处理机器不能判断的部分。5.3 给AI划边界一次只生成一个函数禁止自由发挥还有一个经验就是别让Copilot一次生成一大片代码。它的自信在大范围生成时最容易翻车因为上下文越长它越容易自洽地编造一些不存在的约束。我现在规定一次只让它写一个函数或者一个模块并且明确告诉它不要额外优化不要擅自引入设计模式不要修改非相关代码。一开始团队觉得这样做效率会变低但实际跑了两星期后大家都认同慢一点点但返工率明显下降。AI真正的提效不在于一次写出整个系统而在于让你把时间从敲键盘转移到看清楚问题上。如果它生成的东西有一半要返工那3倍速的快就是假的。我现在跟团队说得很直接Copilot是一次性的生成器不是一个可以对你的项目负责的程序员它把初稿写出来剩下的审查、改错、补边界条件才是我们真正的价值所在。5.4 让自动化测试替人肉背锅说一千道一万人的注意力是有限的与其靠自觉不如把边界条件变成自动化测试。我建议每段AI生成的核心逻辑至少配套以下测试正常路径输入合法数据验证输出边界路径0值、负数、最大值、空对象、空数组异常路径数据库超时、外部接口失败、事务回滚并发路径模拟多个请求同时到达。把这些测试写进CI里每次PR触发。这样review的人不需要在脑子里模拟所有场景机器会先帮他筛一遍。真正到了人工审查阶段人只需要聚焦业务语义和架构兼容性这两个AI最容易出问题、也最难测试的部分。我们团队现在的规矩是AI生成的代码不允许裸奔上线至少要有边界和异常两类测试兜底。这个规矩执行了两个月线上因为并发、空值、回滚导致的故障明显变少了。5.5 一张可以直接抄进团队规约的审查清单最后把我现在用的检查项整理成一张可复制的清单团队想直接用的照着抄就行[ ] 是否有验收标准有没有对应的边界条件表[ ] 该函数是否对应唯一一个明确的功能点而不是顺手改了不相关的逻辑[ ] 是否有隐式依赖全局变量、第三方库、配置文件[ ] 并发场景是否考虑读改写的原子性、锁、事务边界[ ] 失败场景是否会留下脏数据是否有补偿/回滚[ ] 是否有与业务规则相悖的通用正确实现[ ] 是否复用了现有工具函数而不是复制粘贴了第五份实现[ ] 测试是否覆盖了正常、边界、异常、并发四类场景我在实际使用中的感受是Copilot这类工具本身不是问题问题在于很多人把它当成了写完即正确的自动完成器。只要审查流程跟上让它生成代码时先交代清楚边界、依赖和验收标准它带来的效率提升确实是可以落地的。怕就怕AI提效300%审查原地踏步那300%的收益迟早会连本带利还给故障和重构。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
