最近组里的评审队列肉眼可见地膨胀我一度怀疑是某个版本迭代密集上线导致的翻了翻数据才确认真正的元凶是 AI 写代码太多评审跟不上。团队里几位主力开始习惯用 AI 编程助手生成初稿之后单周新增待审的变更量翻了将近三倍而评审人力没变平均排队时间从十二小时被拉到了两天以上。这篇文章不聊行业大趋势只聊我最近几个迭代里实际做的事怎么识别 AI 生成的代码里那些看着正常、实际埋雷的地方怎么把评审流程从“所有的人都审所有代码”改成能扛住高吞吐的流水线以及自动化工具能在哪一步帮我们分担多少。如果你也是团队里的评审主力或者正在为 AI 代码的合入速度头疼这篇应该能给你一些可以直接落地的思路。1. 为什么 AI 一旦接管“初稿”评审就先失守1.1 代码量增幅是线性的评审注意力是稀缺的先摆一个我自己统计过的事实在大家还没开始用 AI 编程助手的时候团队里一个普通合并请求的 diff 通常在 300 行上下这已经包含了测试文件。开始使用 AI 工具后的六个迭代里diff 中位数涨到了 1200 行最夸张的一个 PR 一次性提交了 3400 行里面包含五个新文件和三个“顺手重构”的文件。最直观的体验是评审队列从“每天上班先看一眼”变成了“打开页面就想关掉”。人类评审的速度其实不取决于读了多少行而取决于需要建立多少个心智模型。读一段两百行、逻辑清晰的循环可能只需要三分钟但两千行代码里藏着一堆相互调用的辅助函数光是把调用关系在脑子里理清楚就要反复跳转十几次文件。我经常跟团队成员用一个类比手工时代评审像校对一篇短稿AI 时代的评审像拿着放大镜在百科全书里找出所有被改写过的词条前者可以逐字看后者必须先决定哪些词条值得看。这个矛盾的本质很简单代码量的增幅几乎是线性的而评审者每天能投入的高质量注意力是硬性稀缺资源。人不可能通过“再看快一点”来弥补这种缺口省下来的时间最终都变成了某些代码没有被真正审过。1.2 信任模型被破坏了作者自己也说不清这段逻辑以前代码评审默认有一个信任前提这段代码是作者逐行写的他一定知道每个函数为什么存在、为什么放在这个文件、为什么采取这种写法。哪怕写得不好评审者跟作者沟通时对方至少能给出一个具体的回答。但这个前提在 AI 参与写代码之后变得越来越不成立了。我自己就撞见过一次。一位同事用 AI 助手生成登录注册模块PR 打开一看里面除了基本逻辑还多了一个缓存装饰器、一个防重放工具类、三个配置开关。我问他缓存为什么要加他愣了几秒说他没注意到。这段 AI 生成的代码确实语法漂亮、命名规范几乎可以直接合并但它引入了一次业务上完全不需要的副作用还悄悄改变了对用户数据一致性的假设。这种“作者也不完全知情”的情况直接破坏了评审的根基。以前你可以信任作者至少陈述了代码意图现在你必须默认 AI 生成的部分可能藏了作者没读懂的语义。而要消除这种怀疑只能靠评审者自己逐行读成本就又回到上一节提到的注意力黑洞。更麻烦的是当作者自己都答不上来的时候评审者连“找谁问”这件事都要先花时间去判断。1.3 评审文化的隐性倒退队列一旦拉长很多评审者都会不自觉地开始走捷径。我看到过最典型的退化是“只看 CI 绿点就 Approve”美其名曰“自动化已经把关了”。我随手统计过最忙的几周里团队 PR 的平均评论数从 4.2 条掉到了 1.1 条而“无评论直接通过”的比例从 15% 涨到了 49%。这些数字并不代表大家变懒而是代表大家在满负荷状态下做出了“先保住吞吐量”的选择。但坏就坏在这种“少了也没人说什么”的默契一旦形成下一次真正有问题的代码进来时没有人愿意当发现问题的那个。因为指出问题意味着要给这段 AI 代码重新建立心智模型这比写代码本身更累。所以我后来慢慢意识到如果只谈工具和流程、不解决文化问题任何优化方案都会在执行环节被悄悄稀释掉。2. 先学会识别“AI 污染型”提交五类最常见的问题2.1 过度抽象为不存在的变化预留接口AI 在生成代码时默认策略是提供“最强的可扩展性”因为它不知道你真实的业务边界在哪里。于是你会在 diff 里看到一个状态机只有两种状态却套了两层抽象基类和四个子类一个只被一处调用的方法被放进独立的工具类所有配置都加了开关哪怕根本没有切换场景。# 一个只有两种状态的简单流程AI 生成成了这样 class OrderFlow: def __init__(self, handler: BaseHandler): self._handler handler def run(self, order): return self._handler.handle(order) class BaseHandler: def handle(self, order): raise NotImplementedError class NormalOrderHandler(BaseHandler): def handle(self, order): # 真正的业务逻辑其实只有这一行 return order.mark_as_paid()真正的业务逻辑只有一句其余全是脚手架。评审时遇到这种结构我一般会直接问一句如果未来三年只有一种订单需要走这个流程这一层抽象存在的意义是什么大多数情况下对方都答不上来因为这是 AI 生成的惯常路径不是业务需要。这里我给个容易落地的判断标准如果去掉某个接口或基类现有代码完全不受影响那它就是纯装饰应该在当前 PR 里删掉而不是留着等一个不存在的未来。2.2 有异常就接住成了默认行为AI 对错误的默认反应是“兜底”。生成代码里最常见的模式是 try 包住一切except Exception 后打印一条日志再返回 None。这种代码在正常路径的测试里永远全绿可一旦支付接口超时或外部服务返回异常数据订单状态直接就变成了未知问题通常会延迟到上线后由用户来发现。try: charge_result payment_provider.charge(user_id, amount) except Exception as e: logger.error(e) return None # 后续的订单状态直接被跳过了评审这类代码我的关注点不在“有没有 try”而在“异常分支是否改变了业务状态”。如果兜底行为会导致订单无法继续流转那必须显式写明可接受的降级策略比如返回一个领域对象而不是 None或者干脆让异常向上抛由外层统一处理。一个简单有效的提问方式把 except 里的内容去掉系统会发生什么如果答案包含“数据丢失”或“状态不可知”那这段兜底就是不合格的。2.3 拆得稀碎的业务逻辑一个业务请求本来只需要三步校验参数、调用服务、落库。AI 硬生生把它拆成八个函数、两个回调、一个状态对象里的十个方法。每个方法都很短看起来都符合“单一职责”但连起来读你会发现距离业务本身越来越远评审者的思考连续性被切得稀碎。我之前评审过一个订单创建功能正常实现大概三十行AI 版本拆出了一个OrderBuilder、一个OrderContext、一个OrderPersistenceGateway还加了一个策略接口。每个文件单独看都挺合理但想还原整个流程评审者得在五个文件里来回跳转中间还不能被打断不然十分钟后又得从头来。对作者来说写这么碎的好处是每一块都容易测试但对读者来说理解成本翻倍都不止。所以评审时我会优先看一段核心路径从入口函数开始把关键分支串起来。如果发现一路跳了四五个文件才看到一个实际业务操作我就会建议把这些分散的步骤合并成两个明确的大函数宁愿函数长一点也要保证业务流程可读。这不是反对抽象而是反对为结构性美观牺牲阅读连贯性。2.4 命名科班语义却偏离领域习惯AI 擅长使用标准的、教科书式的命名但这不代表命名符合代码库自己的领域语言。比如团队内部一直用creator表示订单创建人AI 生成的新代码却叫orderInitiator再比如团队约定status只表示订单状态AI 生成时为了区分不同状态引入了situation这种英文词实际含义不明。评审这种代码靠的是“语感”。熟悉业务代码库的人往往一眼就能看出不对劲但很难具体说清楚。我的建议是别停在“名字好不好”这种主观讨论上直接把领域术语表拉出来当面比对如果这个术语在现有模块里已经有固定表达那新代码必须沿用不管它看起来多么规范。语言统一是降低长期维护成本最便宜的手段这一点 AI 生成的代码尤其容易出问题因为它学习的语料是全网通用的不是你们代码库自己的。2.5 测试数量漂亮断言却无效AI 生成测试时特别喜欢“数量取胜”。每个函数都配了测试但断言基本是“结果不为空”、“没有抛异常”这一类根本无法捕捉行为回归。这类测试跑起来全绿代码覆盖率还挺高真正到了生产环境行为一改数组越界了测试里根本看不出来。def test_calculate_discount(): result discount_service.calculate(100, VIP) assert result is not None # 只验证了“有返回值”没检查金额是否为 88评审时看到这类断言我会直接要求补充一条针对数值边界或关键字段的硬断言或者把断言改成比对整个结果对象。把单元测试当成一份可执行的契约来写输入是什么输出必须是什么边界情况怎么处理。这一条对 AI 生成代码尤其重要因为它生成的测试往往是被格式和命名包装过的“空壳”不验证实质行为。2.6 把识别经验固化成“提交标签”前面五条单靠脑子记很难坚持更稳妥的做法是把它塞进团队的合并请求模板和评审检查单里让提交者在写描述的时候就必须过一遍。我在团队里增加了一个字段AI 辅助范围提交人必须从“整段生成 / 局部生成 / 未使用”里选一个并在描述里简述哪些地方是亲手改过的。这个字段不光是给评审者看也是让作者在提交前强制复盘一遍。实践下来很多问题就是在填这一栏时被作者自己发现的。3. 评审流水线把单行道改成三级管线3.1 三级分层的准入标准核心思想很简单不是每个合并请求都值得用同样的时间成本去审。评审者最宝贵的资源是上下文切换分层的目的就是把深度评审集中在小批量高风险的变更上让简单变更快速走完。我在团队里推了一套三级分层标准级别触发条件评审深度目标时间绿灯快速通道改动少于 50 行只涉及文案/配置/测试未触碰公共模块一名同学形式确认重点看意图是否与需求一致2 小时内黄灯标准评审改动涉及核心业务逻辑、新增接口、数据迁移模块负责人加一名相关同学完整走查调用链24 小时内红灯深度评审涉及支付/权限/跨服务协议/并发改造模块负责人牵头分工逐文件审必要时线下过一次48 小时以上3.2 人员匹配新人也有适合的战场分层不只是划标准也得配合人员调度。绿灯快速通道我一般安排给新加入的同学这类变更风险低能练手也能快速建立对代码库的熟悉度。黄灯由模块负责人加一名相关同学共同完成负责人在技术深度上把关相关同学从使用方角度验证。红灯深度评审就必须提前约定时间不能让它出现在临时插队的列表里。因为深度评审需要预留六十到九十分钟的连续专注时间被打断两次质量就明显打折。这套机制运行下来最大的好处是让有经验的同学从大量低风险 diff 里解脱出来把注意力留给真正需要判断的地方。对团队整体来说评审不再是“谁的 PR 排在前面谁就倒霉”而是变成了一种按风险和资源匹配的生产流程。3.3 要求提交者自报“AI 辅助范围”这个规则我在第二章提过这里再展开说说执行细节。我要求合并请求描述里必须写三点哪些代码由 AI 生成初稿、哪些是人工修改、哪些是完全手工创建。刚推行时确实有人觉得麻烦但执行两周后大家发现填写这个字段本身就是一个低成本的自我评审为了写清楚你必须回想一遍这段代码是怎么来的往往写着写着就意识到某段 AI 初稿压根没读懂需求。对评审者来说这个字段就是个观看指南。看到“整段生成”就自动切到挑战模式重点怀疑抽象层次、异常处理和业务语义是否真被消化过。看到“未使用”但 diff 里明显有一堆泛化封装那就是一个该追问的信号。这种反馈闭环会让作者意识到提交说明不是走过场而是评审流程的一部分。3.4 可以直接抄的合并请求模板我把模板贴出来有需要的可以直接改改用。## 变更摘要 - 需求来源 - 本次改动 - AI 辅助范围□整段生成 □局部生成 □未使用 - 若使用 AI哪些部分需要重点审为什么 ## 测试说明 - 已做手动测试 - 已补充单元测试 - 测试覆盖率变化 ## 风险点 - 是否影响存量行为 - 关键异常分支处理 - 是否需要回归测试这个模板的目的不是让作者填字应付而是逼他把“做了什么、为什么这么做、哪里没把握”写清楚。实际执行的时候我会重点看“风险点”那一栏如果作者写了“无”而 diff 里有大量异常兜底逻辑那基本可以判断这段描述是复制粘贴凑的。4. 让自动化先跑第一轮把机械审查交给机器4.1 静态检查的门槛设置代码评审里最耗体力的部分其实是识别那些格式、复杂度、明显死代码的问题。这些工作完全可以让静态分析工具先做一轮。我在团队的持续集成里接入了 ESLint、Mypy 和 SonarQube并设了硬性门禁。AI 生成代码特别容易触发这几个指标圈复杂度高、重复代码多、类型标注不规范。检测指标建议阈值处理动作圈复杂度不超过 10超过则必须人工解释设计理由重复代码不超过 3%超过由模块负责人决定是否重构类型检查0 error有错不允许合并新增代码测试覆盖率≥ 80%不足则要求补充用例或说明原因注意阈值不要一开始就定得太严否则团队会想办法绕过门禁比如拆函数、加忽略注释。我更喜欢只卡硬指标太主观的门禁反而制造对抗。4.2 用“LLM 评审助手”做预筛除了传统静态分析我还自己搭了一个小工具把 diff 文本发给内部部署的大模型让它按固定格式返回可疑点。不是让它写代码也不让它替代人而是让它先跑一遍“阅读”工作把最值得人类注意的行号列出来。实际用的提示词大概是这样请检查这个 diff重点关注 - 是否存在被吞掉的异常分支 - 是否存在未使用但被引入的抽象层级 - 是否存在走不到的业务分支 - 是否存在断言无效的测试 - 只报告可疑点不要修改代码按“行号 问题描述 建议行动”的格式输出实测下来它能比较准确地标出“异常吞掉”“断言太弱”这类模式也会漏掉大量业务语义问题。但没关系我的定位很清楚它是第一轮预筛员把一千二百行的 diff 缩到二十个需要打开的行号让评审者可以把精力集中在可疑区域。配合人工看代码整体评审效率提升很明显。4.3 给自动化结果接上闭环自动化工具最容易变成摆设因为扫描结果发在群里过两天就没人记得了。所以我在 CI 流程里把静态检查结果直接串联到机器人被标记的文件会自动在评审页面追加评论。作者必须逐条说明处理结果或者提交新的变更消除问题否则评审状态一直是“未通过”。这个闭环很关键它能确保机器发现的问题真的被跟进而不是变成一堆没人理的报告。5. 人工评审的重心从“读实现”到“挑战决策”5.1 一页纸评审检查单自动化跑完之后人工评审要看的就不是“代码规范不规范”了而是更上层的决策问题。我自己平时就靠一张一页纸的检查单贴在评审页面旁边不用看太久这个变更是否真的解决了需求描述的问题还是只实现了字面意思关键状态变更是否清楚异常路径下状态是否可恢复新引入的依赖、抽象、工具类是否都找到了必要的使用场景外部输入校验是否完整有没有未处理的类型边界性能上是否存在不必要的重复计算或无缓存增长问题命名和术语是否与当前代码库一致这张清单最值钱的是第一条。AI 生成代码特别容易出现“实现很完整但做的完全是另一件事”的情况因为模型对需求的理解很表面。评审者如果一头扎进函数细节里反而离真相最远。5.2 用提问让作者反思而不是直接给答案面对 AI 生成的复杂代码最有效的评审方式不是“告诉你哪里错了”而是“问你一个关键问题让作者自己去验证”。比如看到一段缓存逻辑你说“把缓存去掉”太粗暴不如问这个缓存装饰器在什么条件下会失效用户信息更新后是不是会返回旧缓存当作者需要回去读一遍代码、找到触发条件、再回答这个问题时他其实正在完成一次深刻的自我评审。这种提问式评审还能减少防御心理。直接下结论容易让作者觉得被否定尤其是当他也不完全理解 AI 生成代码的时候更容易陷入“保住面子”的状态。而一个开放问题会把焦点转移到代码本身让作者和评审者站在一起解决问题而不是对立着争论对错。5.3 整体设计跑偏时宁可要求重写也不要打补丁如果你读完整段代码确信这批 AI 生成的结构从一开始就跑偏了最省事的做法是写一条总评把设计层面的理由和期望落点说清楚而不是在三十七处细节上打补丁。我在一次评审里吃过这个亏刷了十几条小意见作者改完回来新版本整体思路还是错的等于双方都白忙了一场。所以我的建议是看完开头三分之一如果已经确认方向有问题先暂停把总评写出来和作者对齐设计预期。总评要包含三个部分当前路径为什么不对、期望的设计方向是什么、可以参考代码库里的哪个模块。这种“重写阈值”判得越早团队整体浪费的时间就越少。5.4 把评论写成可执行的动作评审意见最怕模糊比如“这里设计得不太好”作者收到之后根本不知道要改什么。我习惯把意见写成这样这里的问题是什么希望达成什么约束给出两个可行方案让作者选。例如这里的异常兜底返回 None 会把订单状态置为未知建议改成抛出领域异常或者返回一个可预期的降级对象二选一。明确的选项比大段论述更容易被执行也更容易在下一轮评审时验证是否真的改了。6. 实测踩坑记录六个悄悄拖垮评审质量的现场6.1 问题速查表流程执行初期总会踩到一些坑我把自己踩过的整理成了一张速查表方便团队自查。现象根本原因处理建议写着“小改动”的 PR点开是 800 行重构分层标准只看描述没看行数与文件数用自动化机器人强制校验行数与文件数超限自动升档无评论直接通过的占比回升评审者注意力耗尽走了形式强制要求绿灯也必须有一条实质评论哪怕一句话点明意图“AI 辅助范围”字段经常不填没跟合并流程绑定填不填都行CI 校验该字段缺失则阻断合并静态检查结果发群里没人跟进缺少闭环作者不知道要处理由 Bot 自动追加评论文本状态未解除前不可合并绿灯通道涌入大型 PR作者想走捷径按文件数、行数自动升档不允许人工手动标低风险深度评审时频繁被打断红灯评审没有预约时间红灯 PR 必须提前在日历上分配两小时不进临时队列这里面最让我意外的是第一条。分层刚推行时大家对“小改动”的定义差异很大后来用脚本在 CI 上自动数行数超过阈值就升档才算堵住这个口子。6.2 三个更隐蔽的成本比表面问题更重要第一是评审者的上下文切换成本。一次评审被打断三次想重新进入状态通常要五分钟以上。所以我现在坚决要求深度评审用整块时间完成宁可让简单 PR 多等一小时也不让负责人来回切频道。第二是 AI 生成的“审美习俗”会反向传染。团队里逐渐有人开始模仿 AI 那种过度抽象的风格手写代码也带上了接口套接口的味道。我在评审时会额外留意这段代码的写法是模仿上下文来的还是被工具带偏了维护一个代码库不只是维护功能也是在维护一种能被人类顺畅理解的结构习惯。第三是工具依赖的惯性。用了 AI 助手之后部分同事遇到问题第一反应是丢给工具而不是自己先思考。我试过一段时间不加干预结果发现几个初级同学调试能力明显变弱。后来我们约定调试类问题先自己分析半小时拿不准了再让 AI 参与。这个约定很简单但很有用。6.3 我们迭代之后沉淀下来的一条准则团队现在有个共识代码评审不是一场“找茬比赛”而是所有参与者对“这段代码是否值得进入系统”的共同决策。AI 写代码不该改变这个判断本身它只是把决策的频率拉高了。想保住决策质量就得在流程前面加分层、旁边加自动化、后面加复盘而不是指望每个评审者都是不知道累的超人。这一点听起来不像技术结论但在我的实际经验里它恰恰是整套方案里最难执行也最有效的一条。最后分享一个我现在每天都会做的固定动作。每个合并请求打开第一眼我先看提交说明里的“AI 辅助范围”。标了“整段生成”的我不急着看具体函数先翻整个文件的结构和调用顺序如果两三页翻下来发现某个函数只是为了凑外观存在我会直接把作者拉到屏幕前让他给我讲一遍这段代码的意图。讲得越流畅说明 AI 初稿确实被消化过讲得支支吾吾那我就不再提议小修小补而是请他回到需求层面重新梳理。这个方法帮我挡掉好几次看似正常、实际跑偏的大型 PR。如果你现在也被 AI 写代码太多、评审跟不上的问题压着我的建议只有一句话别追求让评审变得更快而是让评审变得更有选择。把有限的注意力留给真正需要人类判断的决策点剩下的交给流程、工具和一层合理分层的制度。方向对了AI 依然能当高产队友评审这关也才真正喘得过气来。
最近组里的评审队列肉眼可见地膨胀我一度怀疑是某个版本迭代密集上线导致的翻了翻数据才确认真正的元凶是 AI 写代码太多评审跟不上。团队里几位主力开始习惯用 AI 编程助手生成初稿之后单周新增待审的变更量翻了将近三倍而评审人力没变平均排队时间从十二小时被拉到了两天以上。这篇文章不聊行业大趋势只聊我最近几个迭代里实际做的事怎么识别 AI 生成的代码里那些看着正常、实际埋雷的地方怎么把评审流程从“所有的人都审所有代码”改成能扛住高吞吐的流水线以及自动化工具能在哪一步帮我们分担多少。如果你也是团队里的评审主力或者正在为 AI 代码的合入速度头疼这篇应该能给你一些可以直接落地的思路。1. 为什么 AI 一旦接管“初稿”评审就先失守1.1 代码量增幅是线性的评审注意力是稀缺的先摆一个我自己统计过的事实在大家还没开始用 AI 编程助手的时候团队里一个普通合并请求的 diff 通常在 300 行上下这已经包含了测试文件。开始使用 AI 工具后的六个迭代里diff 中位数涨到了 1200 行最夸张的一个 PR 一次性提交了 3400 行里面包含五个新文件和三个“顺手重构”的文件。最直观的体验是评审队列从“每天上班先看一眼”变成了“打开页面就想关掉”。人类评审的速度其实不取决于读了多少行而取决于需要建立多少个心智模型。读一段两百行、逻辑清晰的循环可能只需要三分钟但两千行代码里藏着一堆相互调用的辅助函数光是把调用关系在脑子里理清楚就要反复跳转十几次文件。我经常跟团队成员用一个类比手工时代评审像校对一篇短稿AI 时代的评审像拿着放大镜在百科全书里找出所有被改写过的词条前者可以逐字看后者必须先决定哪些词条值得看。这个矛盾的本质很简单代码量的增幅几乎是线性的而评审者每天能投入的高质量注意力是硬性稀缺资源。人不可能通过“再看快一点”来弥补这种缺口省下来的时间最终都变成了某些代码没有被真正审过。1.2 信任模型被破坏了作者自己也说不清这段逻辑以前代码评审默认有一个信任前提这段代码是作者逐行写的他一定知道每个函数为什么存在、为什么放在这个文件、为什么采取这种写法。哪怕写得不好评审者跟作者沟通时对方至少能给出一个具体的回答。但这个前提在 AI 参与写代码之后变得越来越不成立了。我自己就撞见过一次。一位同事用 AI 助手生成登录注册模块PR 打开一看里面除了基本逻辑还多了一个缓存装饰器、一个防重放工具类、三个配置开关。我问他缓存为什么要加他愣了几秒说他没注意到。这段 AI 生成的代码确实语法漂亮、命名规范几乎可以直接合并但它引入了一次业务上完全不需要的副作用还悄悄改变了对用户数据一致性的假设。这种“作者也不完全知情”的情况直接破坏了评审的根基。以前你可以信任作者至少陈述了代码意图现在你必须默认 AI 生成的部分可能藏了作者没读懂的语义。而要消除这种怀疑只能靠评审者自己逐行读成本就又回到上一节提到的注意力黑洞。更麻烦的是当作者自己都答不上来的时候评审者连“找谁问”这件事都要先花时间去判断。1.3 评审文化的隐性倒退队列一旦拉长很多评审者都会不自觉地开始走捷径。我看到过最典型的退化是“只看 CI 绿点就 Approve”美其名曰“自动化已经把关了”。我随手统计过最忙的几周里团队 PR 的平均评论数从 4.2 条掉到了 1.1 条而“无评论直接通过”的比例从 15% 涨到了 49%。这些数字并不代表大家变懒而是代表大家在满负荷状态下做出了“先保住吞吐量”的选择。但坏就坏在这种“少了也没人说什么”的默契一旦形成下一次真正有问题的代码进来时没有人愿意当发现问题的那个。因为指出问题意味着要给这段 AI 代码重新建立心智模型这比写代码本身更累。所以我后来慢慢意识到如果只谈工具和流程、不解决文化问题任何优化方案都会在执行环节被悄悄稀释掉。2. 先学会识别“AI 污染型”提交五类最常见的问题2.1 过度抽象为不存在的变化预留接口AI 在生成代码时默认策略是提供“最强的可扩展性”因为它不知道你真实的业务边界在哪里。于是你会在 diff 里看到一个状态机只有两种状态却套了两层抽象基类和四个子类一个只被一处调用的方法被放进独立的工具类所有配置都加了开关哪怕根本没有切换场景。# 一个只有两种状态的简单流程AI 生成成了这样 class OrderFlow: def __init__(self, handler: BaseHandler): self._handler handler def run(self, order): return self._handler.handle(order) class BaseHandler: def handle(self, order): raise NotImplementedError class NormalOrderHandler(BaseHandler): def handle(self, order): # 真正的业务逻辑其实只有这一行 return order.mark_as_paid()真正的业务逻辑只有一句其余全是脚手架。评审时遇到这种结构我一般会直接问一句如果未来三年只有一种订单需要走这个流程这一层抽象存在的意义是什么大多数情况下对方都答不上来因为这是 AI 生成的惯常路径不是业务需要。这里我给个容易落地的判断标准如果去掉某个接口或基类现有代码完全不受影响那它就是纯装饰应该在当前 PR 里删掉而不是留着等一个不存在的未来。2.2 有异常就接住成了默认行为AI 对错误的默认反应是“兜底”。生成代码里最常见的模式是 try 包住一切except Exception 后打印一条日志再返回 None。这种代码在正常路径的测试里永远全绿可一旦支付接口超时或外部服务返回异常数据订单状态直接就变成了未知问题通常会延迟到上线后由用户来发现。try: charge_result payment_provider.charge(user_id, amount) except Exception as e: logger.error(e) return None # 后续的订单状态直接被跳过了评审这类代码我的关注点不在“有没有 try”而在“异常分支是否改变了业务状态”。如果兜底行为会导致订单无法继续流转那必须显式写明可接受的降级策略比如返回一个领域对象而不是 None或者干脆让异常向上抛由外层统一处理。一个简单有效的提问方式把 except 里的内容去掉系统会发生什么如果答案包含“数据丢失”或“状态不可知”那这段兜底就是不合格的。2.3 拆得稀碎的业务逻辑一个业务请求本来只需要三步校验参数、调用服务、落库。AI 硬生生把它拆成八个函数、两个回调、一个状态对象里的十个方法。每个方法都很短看起来都符合“单一职责”但连起来读你会发现距离业务本身越来越远评审者的思考连续性被切得稀碎。我之前评审过一个订单创建功能正常实现大概三十行AI 版本拆出了一个OrderBuilder、一个OrderContext、一个OrderPersistenceGateway还加了一个策略接口。每个文件单独看都挺合理但想还原整个流程评审者得在五个文件里来回跳转中间还不能被打断不然十分钟后又得从头来。对作者来说写这么碎的好处是每一块都容易测试但对读者来说理解成本翻倍都不止。所以评审时我会优先看一段核心路径从入口函数开始把关键分支串起来。如果发现一路跳了四五个文件才看到一个实际业务操作我就会建议把这些分散的步骤合并成两个明确的大函数宁愿函数长一点也要保证业务流程可读。这不是反对抽象而是反对为结构性美观牺牲阅读连贯性。2.4 命名科班语义却偏离领域习惯AI 擅长使用标准的、教科书式的命名但这不代表命名符合代码库自己的领域语言。比如团队内部一直用creator表示订单创建人AI 生成的新代码却叫orderInitiator再比如团队约定status只表示订单状态AI 生成时为了区分不同状态引入了situation这种英文词实际含义不明。评审这种代码靠的是“语感”。熟悉业务代码库的人往往一眼就能看出不对劲但很难具体说清楚。我的建议是别停在“名字好不好”这种主观讨论上直接把领域术语表拉出来当面比对如果这个术语在现有模块里已经有固定表达那新代码必须沿用不管它看起来多么规范。语言统一是降低长期维护成本最便宜的手段这一点 AI 生成的代码尤其容易出问题因为它学习的语料是全网通用的不是你们代码库自己的。2.5 测试数量漂亮断言却无效AI 生成测试时特别喜欢“数量取胜”。每个函数都配了测试但断言基本是“结果不为空”、“没有抛异常”这一类根本无法捕捉行为回归。这类测试跑起来全绿代码覆盖率还挺高真正到了生产环境行为一改数组越界了测试里根本看不出来。def test_calculate_discount(): result discount_service.calculate(100, VIP) assert result is not None # 只验证了“有返回值”没检查金额是否为 88评审时看到这类断言我会直接要求补充一条针对数值边界或关键字段的硬断言或者把断言改成比对整个结果对象。把单元测试当成一份可执行的契约来写输入是什么输出必须是什么边界情况怎么处理。这一条对 AI 生成代码尤其重要因为它生成的测试往往是被格式和命名包装过的“空壳”不验证实质行为。2.6 把识别经验固化成“提交标签”前面五条单靠脑子记很难坚持更稳妥的做法是把它塞进团队的合并请求模板和评审检查单里让提交者在写描述的时候就必须过一遍。我在团队里增加了一个字段AI 辅助范围提交人必须从“整段生成 / 局部生成 / 未使用”里选一个并在描述里简述哪些地方是亲手改过的。这个字段不光是给评审者看也是让作者在提交前强制复盘一遍。实践下来很多问题就是在填这一栏时被作者自己发现的。3. 评审流水线把单行道改成三级管线3.1 三级分层的准入标准核心思想很简单不是每个合并请求都值得用同样的时间成本去审。评审者最宝贵的资源是上下文切换分层的目的就是把深度评审集中在小批量高风险的变更上让简单变更快速走完。我在团队里推了一套三级分层标准级别触发条件评审深度目标时间绿灯快速通道改动少于 50 行只涉及文案/配置/测试未触碰公共模块一名同学形式确认重点看意图是否与需求一致2 小时内黄灯标准评审改动涉及核心业务逻辑、新增接口、数据迁移模块负责人加一名相关同学完整走查调用链24 小时内红灯深度评审涉及支付/权限/跨服务协议/并发改造模块负责人牵头分工逐文件审必要时线下过一次48 小时以上3.2 人员匹配新人也有适合的战场分层不只是划标准也得配合人员调度。绿灯快速通道我一般安排给新加入的同学这类变更风险低能练手也能快速建立对代码库的熟悉度。黄灯由模块负责人加一名相关同学共同完成负责人在技术深度上把关相关同学从使用方角度验证。红灯深度评审就必须提前约定时间不能让它出现在临时插队的列表里。因为深度评审需要预留六十到九十分钟的连续专注时间被打断两次质量就明显打折。这套机制运行下来最大的好处是让有经验的同学从大量低风险 diff 里解脱出来把注意力留给真正需要判断的地方。对团队整体来说评审不再是“谁的 PR 排在前面谁就倒霉”而是变成了一种按风险和资源匹配的生产流程。3.3 要求提交者自报“AI 辅助范围”这个规则我在第二章提过这里再展开说说执行细节。我要求合并请求描述里必须写三点哪些代码由 AI 生成初稿、哪些是人工修改、哪些是完全手工创建。刚推行时确实有人觉得麻烦但执行两周后大家发现填写这个字段本身就是一个低成本的自我评审为了写清楚你必须回想一遍这段代码是怎么来的往往写着写着就意识到某段 AI 初稿压根没读懂需求。对评审者来说这个字段就是个观看指南。看到“整段生成”就自动切到挑战模式重点怀疑抽象层次、异常处理和业务语义是否真被消化过。看到“未使用”但 diff 里明显有一堆泛化封装那就是一个该追问的信号。这种反馈闭环会让作者意识到提交说明不是走过场而是评审流程的一部分。3.4 可以直接抄的合并请求模板我把模板贴出来有需要的可以直接改改用。## 变更摘要 - 需求来源 - 本次改动 - AI 辅助范围□整段生成 □局部生成 □未使用 - 若使用 AI哪些部分需要重点审为什么 ## 测试说明 - 已做手动测试 - 已补充单元测试 - 测试覆盖率变化 ## 风险点 - 是否影响存量行为 - 关键异常分支处理 - 是否需要回归测试这个模板的目的不是让作者填字应付而是逼他把“做了什么、为什么这么做、哪里没把握”写清楚。实际执行的时候我会重点看“风险点”那一栏如果作者写了“无”而 diff 里有大量异常兜底逻辑那基本可以判断这段描述是复制粘贴凑的。4. 让自动化先跑第一轮把机械审查交给机器4.1 静态检查的门槛设置代码评审里最耗体力的部分其实是识别那些格式、复杂度、明显死代码的问题。这些工作完全可以让静态分析工具先做一轮。我在团队的持续集成里接入了 ESLint、Mypy 和 SonarQube并设了硬性门禁。AI 生成代码特别容易触发这几个指标圈复杂度高、重复代码多、类型标注不规范。检测指标建议阈值处理动作圈复杂度不超过 10超过则必须人工解释设计理由重复代码不超过 3%超过由模块负责人决定是否重构类型检查0 error有错不允许合并新增代码测试覆盖率≥ 80%不足则要求补充用例或说明原因注意阈值不要一开始就定得太严否则团队会想办法绕过门禁比如拆函数、加忽略注释。我更喜欢只卡硬指标太主观的门禁反而制造对抗。4.2 用“LLM 评审助手”做预筛除了传统静态分析我还自己搭了一个小工具把 diff 文本发给内部部署的大模型让它按固定格式返回可疑点。不是让它写代码也不让它替代人而是让它先跑一遍“阅读”工作把最值得人类注意的行号列出来。实际用的提示词大概是这样请检查这个 diff重点关注 - 是否存在被吞掉的异常分支 - 是否存在未使用但被引入的抽象层级 - 是否存在走不到的业务分支 - 是否存在断言无效的测试 - 只报告可疑点不要修改代码按“行号 问题描述 建议行动”的格式输出实测下来它能比较准确地标出“异常吞掉”“断言太弱”这类模式也会漏掉大量业务语义问题。但没关系我的定位很清楚它是第一轮预筛员把一千二百行的 diff 缩到二十个需要打开的行号让评审者可以把精力集中在可疑区域。配合人工看代码整体评审效率提升很明显。4.3 给自动化结果接上闭环自动化工具最容易变成摆设因为扫描结果发在群里过两天就没人记得了。所以我在 CI 流程里把静态检查结果直接串联到机器人被标记的文件会自动在评审页面追加评论。作者必须逐条说明处理结果或者提交新的变更消除问题否则评审状态一直是“未通过”。这个闭环很关键它能确保机器发现的问题真的被跟进而不是变成一堆没人理的报告。5. 人工评审的重心从“读实现”到“挑战决策”5.1 一页纸评审检查单自动化跑完之后人工评审要看的就不是“代码规范不规范”了而是更上层的决策问题。我自己平时就靠一张一页纸的检查单贴在评审页面旁边不用看太久这个变更是否真的解决了需求描述的问题还是只实现了字面意思关键状态变更是否清楚异常路径下状态是否可恢复新引入的依赖、抽象、工具类是否都找到了必要的使用场景外部输入校验是否完整有没有未处理的类型边界性能上是否存在不必要的重复计算或无缓存增长问题命名和术语是否与当前代码库一致这张清单最值钱的是第一条。AI 生成代码特别容易出现“实现很完整但做的完全是另一件事”的情况因为模型对需求的理解很表面。评审者如果一头扎进函数细节里反而离真相最远。5.2 用提问让作者反思而不是直接给答案面对 AI 生成的复杂代码最有效的评审方式不是“告诉你哪里错了”而是“问你一个关键问题让作者自己去验证”。比如看到一段缓存逻辑你说“把缓存去掉”太粗暴不如问这个缓存装饰器在什么条件下会失效用户信息更新后是不是会返回旧缓存当作者需要回去读一遍代码、找到触发条件、再回答这个问题时他其实正在完成一次深刻的自我评审。这种提问式评审还能减少防御心理。直接下结论容易让作者觉得被否定尤其是当他也不完全理解 AI 生成代码的时候更容易陷入“保住面子”的状态。而一个开放问题会把焦点转移到代码本身让作者和评审者站在一起解决问题而不是对立着争论对错。5.3 整体设计跑偏时宁可要求重写也不要打补丁如果你读完整段代码确信这批 AI 生成的结构从一开始就跑偏了最省事的做法是写一条总评把设计层面的理由和期望落点说清楚而不是在三十七处细节上打补丁。我在一次评审里吃过这个亏刷了十几条小意见作者改完回来新版本整体思路还是错的等于双方都白忙了一场。所以我的建议是看完开头三分之一如果已经确认方向有问题先暂停把总评写出来和作者对齐设计预期。总评要包含三个部分当前路径为什么不对、期望的设计方向是什么、可以参考代码库里的哪个模块。这种“重写阈值”判得越早团队整体浪费的时间就越少。5.4 把评论写成可执行的动作评审意见最怕模糊比如“这里设计得不太好”作者收到之后根本不知道要改什么。我习惯把意见写成这样这里的问题是什么希望达成什么约束给出两个可行方案让作者选。例如这里的异常兜底返回 None 会把订单状态置为未知建议改成抛出领域异常或者返回一个可预期的降级对象二选一。明确的选项比大段论述更容易被执行也更容易在下一轮评审时验证是否真的改了。6. 实测踩坑记录六个悄悄拖垮评审质量的现场6.1 问题速查表流程执行初期总会踩到一些坑我把自己踩过的整理成了一张速查表方便团队自查。现象根本原因处理建议写着“小改动”的 PR点开是 800 行重构分层标准只看描述没看行数与文件数用自动化机器人强制校验行数与文件数超限自动升档无评论直接通过的占比回升评审者注意力耗尽走了形式强制要求绿灯也必须有一条实质评论哪怕一句话点明意图“AI 辅助范围”字段经常不填没跟合并流程绑定填不填都行CI 校验该字段缺失则阻断合并静态检查结果发群里没人跟进缺少闭环作者不知道要处理由 Bot 自动追加评论文本状态未解除前不可合并绿灯通道涌入大型 PR作者想走捷径按文件数、行数自动升档不允许人工手动标低风险深度评审时频繁被打断红灯评审没有预约时间红灯 PR 必须提前在日历上分配两小时不进临时队列这里面最让我意外的是第一条。分层刚推行时大家对“小改动”的定义差异很大后来用脚本在 CI 上自动数行数超过阈值就升档才算堵住这个口子。6.2 三个更隐蔽的成本比表面问题更重要第一是评审者的上下文切换成本。一次评审被打断三次想重新进入状态通常要五分钟以上。所以我现在坚决要求深度评审用整块时间完成宁可让简单 PR 多等一小时也不让负责人来回切频道。第二是 AI 生成的“审美习俗”会反向传染。团队里逐渐有人开始模仿 AI 那种过度抽象的风格手写代码也带上了接口套接口的味道。我在评审时会额外留意这段代码的写法是模仿上下文来的还是被工具带偏了维护一个代码库不只是维护功能也是在维护一种能被人类顺畅理解的结构习惯。第三是工具依赖的惯性。用了 AI 助手之后部分同事遇到问题第一反应是丢给工具而不是自己先思考。我试过一段时间不加干预结果发现几个初级同学调试能力明显变弱。后来我们约定调试类问题先自己分析半小时拿不准了再让 AI 参与。这个约定很简单但很有用。6.3 我们迭代之后沉淀下来的一条准则团队现在有个共识代码评审不是一场“找茬比赛”而是所有参与者对“这段代码是否值得进入系统”的共同决策。AI 写代码不该改变这个判断本身它只是把决策的频率拉高了。想保住决策质量就得在流程前面加分层、旁边加自动化、后面加复盘而不是指望每个评审者都是不知道累的超人。这一点听起来不像技术结论但在我的实际经验里它恰恰是整套方案里最难执行也最有效的一条。最后分享一个我现在每天都会做的固定动作。每个合并请求打开第一眼我先看提交说明里的“AI 辅助范围”。标了“整段生成”的我不急着看具体函数先翻整个文件的结构和调用顺序如果两三页翻下来发现某个函数只是为了凑外观存在我会直接把作者拉到屏幕前让他给我讲一遍这段代码的意图。讲得越流畅说明 AI 初稿确实被消化过讲得支支吾吾那我就不再提议小修小补而是请他回到需求层面重新梳理。这个方法帮我挡掉好几次看似正常、实际跑偏的大型 PR。如果你现在也被 AI 写代码太多、评审跟不上的问题压着我的建议只有一句话别追求让评审变得更快而是让评审变得更有选择。把有限的注意力留给真正需要人类判断的决策点剩下的交给流程、工具和一层合理分层的制度。方向对了AI 依然能当高产队友评审这关也才真正喘得过气来。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
