AI Review #

← 返回 AI 合集

在时代快速变化的当下，相信不少程序员都和我一样，会有一种“恍如隔世”的感觉。甚至一年前还在坚持的工作方式，今年就已经快被定义成“古法编程”了。

但这也没办法，时代的车轮就是这样往前滚。更何况，AI 编程确实是真的好用。

今天想分享一下我对 AI Review 的一些实践思路。

从 Code Review，到 AI 时代的分层 Review #

有“古法编程”经验的人应该都知道 Code Review。这是提升代码质量非常有效的一种手段。

如果团队里有经验丰富的程序员，Code Review 往往能拦截很多问题：设计缺陷、边界遗漏、潜在 bug、风格不统一，甚至一些长期维护风险。

但现实情况通常是，受限于团队配置、业务节奏和个人精力，真正能够持续产出高质量 Review 的场景并不多。

到了 AI 时代，这件事反而变得更重要了。因为很多时候，Review 可能已经变成工程师在自己权力边界内，最后一道真正能把控质量的关卡。

但我觉得，Review 不应该只停留在 Code Review 这一层。

我现在更倾向于做一套分层 Review,当然其实其他层面也需要Review,这里我只聚焦于程序员一般的责任边界。

• Design Review
• Code Review

Design Review #

我一直觉得，Design 才是程序员真正的工作重心。

这里面包含的，不只是“怎么写代码”，而是：

• 对问题的理解和定义
• 对需求边界的梳理
• 对整体流程的拆解
• 对模块职责和规则的组织
• 对异常场景和未来演进的预判

尤其是在 AI 时代，这一点变得更加重要。

以前在“古法编程”时代，程序员通常对自己写出来的代码有非常强的掌控感。很多事情虽然文档里没写清楚，但只要把代码翻一遍，往往就能学到很多东西。

有句名言说得很直接：

Talk is cheap, show me the code.

过去这句话成立，是因为代码本身就是最真实、最直接的表达。很多没有说透的设计，最后都沉淀在代码里。

但到了 AI 时代，情况开始发生变化。

代码本身正在变得越来越“廉价”。程序员投入在具体编码上的精力会越来越少，很多局部实现会直接交给 AI 生成。这样带来的一个问题是：工程师对代码细节的掌控感，实际上是在下降的。

尤其是在老项目中，这个问题会更加明显。因为系统本来就复杂，如果还把主要精力放在局部代码实现上，人的注意力很容易被淹没。

所以我现在的看法是：

在 AI 时代，程序员的掌控力应该上升一层，变成对“模型、结构、规则、行为”的掌控。

程序员不一定需要清楚项目里每一个角落的具体代码，但至少应该对这些内容做到足够熟悉：

• 整体架构是怎么分层的
• 关键模块之间是怎么协作的
• 核心行为链路是怎么串起来的
• 系统规则和约束落在哪些位置
• 一旦出问题，应该能快速定位到是哪个环节、哪个节点出了问题

至于局部代码实现，我想大家应该都已经见识过 AI 的编码能力了。在局部代码生成这件事上，AI 在很多场景里已经明显强于普通程序员。

但也正因为如此，Design Review 变得比以前更重要。

因为如果设计层面没控住，AI 只会更快地把问题放大、复制、扩散。

Design Review 需要审核哪些点 #

我现在理解的 Design Review，不只是“看方案有没有写出来”，而是要审核下面几个层面。

1. 问题定义是否准确 #

先看是不是把问题真正说清楚了：

• 要解决的核心问题是什么
• 这是用户问题、业务问题，还是技术问题
• 当前痛点在哪里
• 成功标准是什么
• 哪些内容在范围内，哪些内容不在范围内

很多方案一上来就在讲实现，但连问题本身都没定义清楚。
这种情况下，后面的设计越细，偏差可能越大。

2. 流程是否完整串联起来 #

一个好的设计，不应该只是几个零散的模块图，而应该能把流程完整串起来：

• 输入是什么
• 中间经过哪些步骤
• 每一步做什么转换
• 产出是什么
• 异常路径怎么走
• 回滚、重试、兜底怎么处理

也就是说，要让行为流程能够串联静态结构，而不是只看到组件，不知道它们怎么真正运转。

3. 结构、行为、规则是否闭环 #

这是我现在特别关注的一点：

• 结构：有哪些模块、对象、边界
• 行为：这些模块在什么条件下怎么动作
• 规则：这些动作受到什么约束

一个设计是否扎实，关键看这三者能不能闭环。

比如：

• 模块有了，但行为没说清楚
• 行为有了，但规则没定义
• 规则有了，但没有落实到具体模块
• 异常分支存在，但没有规则兜底

这些都说明设计还没完成。

4. 模块职责是否清晰 #

需要看：

• 模块边界是不是明确
• 谁负责校验，谁负责转换，谁负责存储，谁负责展示
• 是否出现职责重叠
• 是否出现“一个模块什么都做”的情况
• 是否有过度耦合

如果职责不清晰，AI 往往会“顺手”把逻辑写进最方便的地方。短期看效率很高，长期看维护性会越来越差。

5. 规则是否足够明确、可执行、可测试 #

很多设计文档的问题，不是没有规则，而是规则写得“不够落地”。

比如：

• “异常情况做合理处理”
• “超限时给出友好提示”
• “兼容常见场景”
• “必要时自动修正”

这种描述看起来没错，但几乎不能直接指导实现，也不能直接指导测试。

Design Review 要追问到足够具体：

• 什么算异常
• 什么算超限
• 提示文案是什么
• 自动修正怎么修
• 哪些情况 reject，哪些情况 warning，哪些情况 silent adapt

只有规则足够明确，AI 才不会在实现时自己“脑补”。

6. 方案的收益、风险和代价是否说清楚 #

一个设计方案不能只讲“能做什么”，还要讲：

• 带来的好处是什么
• 会引入哪些风险
• 对性能、稳定性、兼容性、维护成本有什么影响
• 有没有技术债
• 后续扩展是否方便

这一步review的时候也可以顺便根据情况来生成

7. 是否便于定位和排查问题 #

所以设计必须考虑可观测性：

• 日志打在哪里
• 错误码怎么设计
• 关键状态怎么暴露
• 如何区分不同失败类型
• 出问题时能不能快速定位到模块和阶段

如果这一点没有提前设计，后面排查问题会非常痛苦。

8. 是否便于演进 #

设计不能只考虑“这次需求能上线”，还要考虑：

• 后面加新规则难不难
• 新增一个分支要改几个地方
• 是否支持配置化
• 是否容易扩展测试
• 是否容易被 AI 持续接手

如果一个方案第一次写出来就已经很“僵”，那后面每次改动都会变成风险放大器。

Code Review #

如果说 Design Review 负责把握方向、结构和规则，
那么 Code Review 就是在落地阶段，确保这些东西真正被正确实现。

AI 时代的 Code Review，我觉得比过去更需要“有明确参照物”。

因为以前是人在写代码，很多意图和上下文默认是在脑子里的；现在很多代码是 AI 生成的，如果没有明确的 Review 参照，Review 很容易变成“看起来差不多”。

所以我现在比较关注的 Code Review 参照主要有三类：

• 整体项目的架构风格和规范
• 根据需求生成的测试用例
• 语言特性和运行时层面的风险点

Code Review 需要审核哪些点 #

1. 是否符合设计 #

这是第一位的，不是先看“代码写得漂不漂亮”，而是先看：

• 是否真正实现了设计要求
• 主流程是否一致
• 异常分支是否覆盖
• 边界条件是否落实

很多 AI 代码局部看起来很好，但和设计一对，发现实现偏了。

2. 是否符合项目既有架构和风格 #

重点看：

• 有没有遵守项目分层
• 有没有把逻辑放到正确的模块
• 命名是否符合约定
• 是否复用了既有能力
• 有没有绕开公共组件另起一套
• 错误处理、日志、常量、配置是否符合已有规范

AI 很容易生成“自洽但不入乡随俗”的代码。单看没问题，放进项目里就显得很突兀。

3. 是否覆盖需求对应的测试点 #

Code Review 不能脱离测试点。

要对照看：

• 需求中的正常场景是否覆盖
• 边界场景是否覆盖
• 异常场景是否覆盖
• 回归风险点是否覆盖
• 是否有缺少断言的情况
• 是否只测了 happy path

最理想的状态是：
设计 -> 测试点 -> 代码实现 三者能互相映射。

4. 逻辑是否正确且一致 #

要重点看：

• 条件判断是否完整
• 分支之间是否互斥/重叠
• 默认值是否合理
• 状态转换是否正确
• 是否存在前后行为不一致
• 是否出现局部修补导致整体规则破坏

AI 很会“把一块补好”，但不一定能保证整体一致性。

5. 边界处理是否完整 #

重点检查：

• null / undefined / empty 处理
• 长度、范围、数量上限
• 非法输入
• 重复输入
• 极端输入
• 时间、时区、编码、精度等特殊问题

这部分通常最值得花时间看，因为很多 bug 就藏在这里。

6. 错误处理和提示是否清晰 #

要看：

• 错误有没有被吞掉
• 是否区分可恢复错误和不可恢复错误
• 提示是否准确
• 日志是否足够定位问题
• 是否有模糊报错
• 是否把不同原因混成同一种错误

AI 写代码时很容易“能跑就行”，但错误处理往往比较粗。

7. 是否存在重复代码和错误抽象 #

看这些点：

• 是否复制粘贴了相似逻辑
• 是否应该抽公共函数
• 是否为了复用而过度抽象
• 抽象层次是否合适
• 是否把本该分开的语义硬合并了

AI 有时候会两边都犯：要么复制很多相似代码，要么抽出一个非常“万能但难懂”的函数。

8. 性能和资源使用是否合理 #

不是每次都要做深度性能 review，但至少要看：

• 有没有明显重复计算
• 有没有不必要的大对象拷贝
• 循环里是否有昂贵操作
• I/O、网络、数据库调用是否合理
• 是否有潜在内存风险
• 数据规模变大后是否会明显退化

AI 在小样本代码里经常“能过就好”，数据量一大就容易出问题。

9. 是否利用了语言特性，但没有踩语言坑 #

这个部分很重要，尤其是不同语言各有不同风险。

需要关注：

• 异步/并发是否安全
• 可变对象是否被误共享
• 异常传播是否正确
• 类型系统有没有被绕开
• 精度、时区、编码问题是否处理好
• 生命周期、资源释放是否完整
• 语言中的隐式行为有没有造成风险

也就是说，AI 可以很会写“像这个语言的代码”，
但不一定真的避开了这个语言最常见的坑。

10. 可读性和可维护性是否足够 #

最后再看这些：

• 命名是否清晰
• 函数是否过长
• 嵌套是否过深
• 关键逻辑是否容易理解
• 注释是否解释“为什么”，而不是重复“做了什么”
• 后续修改一个规则时，影响范围是否可控

AI 生成的代码有时候表面上很整洁，但真正维护起来并不一定轻松。