先看一个很典型的场景。
团队要给后台加一个批量导出功能。AI 读完代码，很快补好了接口、查询逻辑和单元测试，顺手还把几处命名改得挺规范。PR 看起来很漂亮，测试全绿，代码也挑不出什么明显毛病。
结果到了联调阶段，大家才发现，它把“只能导出当前账号有权限查看的数据”，理解成了“导出当前筛选条件下的所有数据”。接口能跑，测试能过，甚至实现得还挺优雅，就是差点把不该看到的数据一起导出去。
这种情况以后可能会越来越常见。过去写一个功能，开发可能要花两天，Review 花半小时。现在 AI 很快就能生成大量代码，人还是习惯用原来的方式扫一遍。代码产量上去了，审查方式却没有变，最后就会出现一个很尴尬的局面：我们认真检查了命名、空指针和循环写法，却放过了真正决定系统是否安全的问题。AI 写代码以后，Code Review 确实需要重新定义一次。
代码越便宜，人的注意力越要往上移
先说清楚，格式、语法、命名、重复代码这些当然还要管。但它们已经不值得占用 Reviewer 最宝贵的注意力了。格式有自动格式化工具，语法有编译器，常见缺陷有静态检查，重复代码和低级错误也可以让 AI 先筛一遍。很多团队的 Review，仍然把大部分时间耗在“这个变量名能不能更准确”“这里要不要抽一个函数”“这段能不能写得更简洁”上。
能写成明确规则的，最好放进自动化门禁。机器先把格式、规范和常见缺陷挡在 PR 之外，人再把有限的注意力留给那些无法只靠规则判断的问题。
这些意见不能说错，只是优先级变了。当生成代码越来越便宜，真正稀缺的东西已经变成了对业务的理解、对系统边界的判断，以及对长期后果的负责。AI 很擅长根据眼前的上下文，给出一段局部看起来合理的实现；它很难天然知道，三年前为什么有人故意绕开了某张表，某个接口为什么只开放了只读权限，或者某条看似多余的校验背后曾经出过什么事故。
所以，新的 Code Review 至少要把注意力放到下面五件事上。
第一件事：它理解的需求，真的是我们要的需求吗？
AI 最容易犯的错误，往往不在代码里，而在它对问题的解释里。比如产品说“增加订单取消能力”，AI 很可能会补一个 cancelOrder 接口，把订单状态改成已取消，再写几个测试确认状态更新成功。单看代码，整个链路没什么问题。但真实业务里可能还有库存释放、优惠券返还、支付退款、消息通知和审计记录。更麻烦的是，不同订单状态能不能取消，取消以后是否允许恢复，也许根本没写在这次需求描述里。
人类开发通常会在会议、聊天记录和过往经验里补齐这些信息。Agent 拿到的上下文如果只有一个需求单和几份代码，它就很容易把“能运行”当成“已经完成”。
因此 Review 的第一个问题，要先确认它到底实现了什么。输入是什么，输出是什么，谁能触发，失败以后怎么办，有哪些没有写出来的业务约束，都要先讲明白。至于这段实现写得漂不漂亮，可以往后放一放。
我建议让 PR 描述强制回答三个问题：这次变更解决了谁的什么问题；哪些场景明确不在范围内；验收时观察什么行为，才能确认需求真的完成。只要这三个问题说不清楚，代码写得再完整，也不应该急着合并。
第二件事：为了完成局部任务，它有没有把架构边界撞穿？
AI 有一个非常自然的倾向：哪里能拿到数据，就从哪里拿；哪里改起来最短，就在哪里改。假设一个系统已经规定，订单模块只能通过库存服务查询库存。Agent 在写新功能时，发现直接查库存表更省事，而且仓库里刚好能找到数据库连接方式，它很可能就这么写了。功能很快完成，性能甚至还更好，但两个模块之间原本清晰的边界被悄悄打穿了。
这种代码很难靠普通测试发现。它今天能跑，下个月库存表改字段时才会暴露；或者等团队再加几个类似需求，订单模块已经到处依赖库存内部结构，谁也不敢动。
以前这类问题主要来自赶工和经验不足。AI 加入以后，风险会被放大，因为它生成局部最优解的速度实在太快了。只要仓库里没有明确约束，Agent 就可能在不同任务里发明不同路径：这次直接查表，下次复制一份工具类，再下次新建一个“临时”适配层。每一处看起来都有理由，合在一起却把系统变成了迷宫。
所以 Reviewer 要盯住模块边界、依赖方向和数据所有权。一个小需求为什么需要跨三个领域？为什么要引入新的公共层？仓库里是否已经有标准入口？这些问题比某个函数多写了十行重要得多。
第三件事：测试是在验证业务，还是陪着实现演戏？
AI 生成代码时，通常也会顺手生成测试。这很容易给人一种安全感：覆盖率涨了，测试全绿，应该没问题。
但实现和测试来自同一个模型、同一份上下文时，它们很可能共享同一个错误假设。AI 认为取消订单只需要修改状态，于是实现检查状态变化，测试也只检查状态变化。两边严丝合缝，真正遗漏的退款和库存释放反而完全没有出现。
还有一种常见情况，测试过度贴着实现写。函数调用了几次、某个内部方法收到了什么参数、Mock 返回什么就断言什么。这类测试看起来很细，实际上只能证明代码按照自己写下的路径走了一遍。一旦重构，测试碎一地；业务行为出了偏差，它又未必能拦住。
好的 Review 要重新检查测试的证据价值。用户能观察到的结果是什么？系统必须始终成立的规则是什么？失败路径有没有覆盖？权限不同的人执行同一个操作会发生什么？外部依赖超时以后，数据会停在哪个状态？
测试不只是代码的配套装饰，它应该是一份独立的行为契约。如果测试只是重复实现的思路，那它再多也只是在给错误增加信心。
第四件事：它带来了哪些权限、数据和依赖风险？
AI 写出的代码有时会为了尽快跑通任务，自然地扩大能力范围。缺一个接口权限，就给服务账户多加一个角色；查不到数据，就绕到更底层的存储；缺一个小工具，就引入一个新的第三方包。这些动作在本地环境里很顺滑，放进真实系统以后，每一项都可能扩大风险面。
还是开头那个导出场景，Reviewer 至少要检查：查询有没有经过原有的数据权限过滤；导出的文件会保存在哪里、保留多久；日志里会不会记录敏感字段；大批量导出会不会拖垮数据库；任务失败后生成的半成品是否会被别人访问。
依赖也一样。AI 很喜欢给出“安装一个包就能解决”的答案，但这个包由谁维护、最近是否还在更新、许可证是否兼容、会不会额外带进几十个间接依赖，都需要有人负责判断。代码生成省下来的十分钟，可能会换来几年的供应链维护成本。
这部分 Review 最关键的是别只看正常流程。要顺着权限、数据流和失败路径往下追：它拿到了什么能力，数据经过了哪里，出错之后留下什么，回滚时能不能收干净。
第五件事：代码库的信息熵，是下降了还是又涨了一点？
“信息熵”听着有点玄，放在代码库里其实很好理解。同一类功能有三套写法，同一个概念有五种命名，一个目录下同时放接口、脚本、临时工具和历史废弃代码；新同事想改一处逻辑，需要先找四个人确认哪条链路还在使用。这些都是信息熵上升的表现。
AI 会让这个问题变得更明显。过去团队一天产出的代码量有限，还有机会慢慢消化。现在一个人可以同时调度多个 Agent，在很短的时间内制造大量改动。如果每次变更都多加一层抽象、多造一个工具类、多留一个“以后再整理”的分支，代码库会以非常快的速度失去一致性。
所以 Review 还要问：这次改动沿用了仓库已有的模式吗？有没有重复已有能力？新抽象真的会被多个地方使用吗？旧逻辑能不能顺手删除？配置和例外是在减少，还是继续堆积？
说真的，AI 时代很容易把“产出更多代码”误认为“交付更多价值”。但一个功能如果用 200 行就能讲清楚，Agent 生成 800 行并不值得表扬。代码是资产，也是一种需要持续支付理解和维护成本的负债。
还有一个新标准：这次变更，对未来的 Agent 友好吗？
前面五件事，是在判断当前变更能不能安全合进去。但还有一项过去很少有人放进 Review 清单，未来却会越来越重要：这次变更，有没有让下一次修改变得更容易？
我们以前整理目录、统一命名、补充文档，主要是为了让下一位接手的人更容易理解。现在，代码库还有了另一类读者：以后会不断进入仓库干活的 Agent。
Agent 对代码库的理解高度依赖可见信息。如果关键规则只存在于老员工脑子里，它读不到；如果同一种操作散落着五种实现，它很难判断哪一种才是标准；如果测试经常失效、文档长期过期，它也无法获得可靠反馈。最后，它只能根据局部代码猜，然后继续生成更多局部合理、全局混乱的改动。
反过来，一个边界清晰、模式一致、测试可信、决策有记录的仓库，会让 Agent 的表现更稳定。它能更快找到该修改的位置，也更容易知道哪些地方不能碰。很多人研究怎么写更长的提示词、怎么给 Agent 塞更多上下文，其实仓库本身才是最重要的上下文工程。
每次 Review 都可以多问一句：新来的开发和 Agent，能不能只看代码、测试和文档，就理解为什么这么设计？如果答案是否定的，那这次交付也许完成了功能，却给未来留下了一笔上下文债务。
AI 研发团队，真正需要重构的是工作分工
再往前走一步会发现，AI 对研发流程的影响远不止“写代码更快”。它正在移动整个团队的瓶颈。过去，很多时间耗在把明确方案翻译成代码。现在这部分成本迅速下降，新的瓶颈转移到了定义问题、提供约束、验证结果和控制复杂度上。Reviewer 的角色也会跟着变化：少做代码表面的纠察，多做系统后果的判断。
这对团队的要求其实更高了。需求要写得更清楚，架构设计 的边界要能够被机器读取，测试要表达真实业务行为，权限和依赖要有自动化门禁，重要设计决策要留下记录。只有这些基础设施补上，Agent 才能在一个可控的轨道里加速。
否则，所谓 AI 提效很可能只是把代码从开发手里更快地送到 Reviewer 面前。生成速度大幅提升，理解和审查能力没有变化，PR 会越堆越多，系统风险也会跟着一起放大。
最后，我整理了一份自己会用的 AI 时代 Code Review 清单：
- 需求：实现解决的是原始问题吗？隐含约束、异常流程和范围边界讲清楚了吗？
- 架构：模块边界、依赖方向和数据所有权有没有被破坏？
- 测试：验证的是外部行为和业务规则，还是只复制了实现逻辑？
- 风险：权限是否扩大，敏感数据流向哪里，失败与回滚是否可控？
- 依赖：新增依赖真的必要吗？维护、安全和许可证成本评估过吗？
- 复杂度：这次变更减少了例外和重复，还是继续推高代码库的信息熵？
- Agent 可理解性：未来的人和 Agent，能不能更容易理解、修改并验证这块代码？
AI 可以帮我们把代码写得越来越快，但“应该写什么、允许怎么写、写完如何证明它是对的”，依然需要团队建立一套更成熟的工程系统。正如 云栈社区 上许多同行所讨论的那样，这不仅是工具的升级，更是整个研发思维的重构。
发表于 1 小时前
|
查看: 3|
回复: 0
