我不逐行读AI的代码了，而是改查这四样

使用 Cursor、GitHub Copilot 或 Claude 辅助写代码几个月后，很多资深工程师都会经历一个心理转折点：不再逐行阅读 AI 生成的代码实现。

这并不意味着盲目信任。相反，大模型生成的代码通常排版整洁、命名优雅，甚至比多数初级开发者更遵守 PEP8 或 ESLint 规范。死盯那些 for 循环或临时变量，往往是在把时间浪费在最不容易出错的地方。

AI 生成代码的致命问题，几乎从不在于语法实现，而在于它对系统上下文的理解偏差。当代码生成的边际成本趋近于零，审查（Code Review）的重心必须从「语法校对」升维为「系统边界把控」。

如果不再逐行读代码，究竟该检查什么？

---

一、检查测试用例，而不是实现逻辑

检验一段代码最快的方式不是人脑单步调试，而是让测试跑起来。

审查 AI 产出的第一步，是直接拉到测试文件：

• 测试是否覆盖了失败路径？ AI 天生喜欢写“快乐路径”（Happy Path），即输入符合预期时的理想情况。它很少主动为网络超时、空值注入、非法入参编写断言。
• 测试是不是伪命题？ 大模型有时会写出一种滑稽的测试：为了让断言通过，把 Mock 对象的返回值直接硬编码成期望值，根本没有测到真实逻辑。

先确认测试用例切中了业务关键，再运行测试套件。只要测试足够健壮，具体内部实现哪怕是三行递归还是一组高阶函数，重要性都会大幅降低。

---

二、排查隐性假设与边界条件

AI 缺乏物理世界的常识，更缺乏业务领域的痛点记忆。它的代码往往建立在“理想世界”这一假设之上。

在审阅时，需要重点排查以下几种隐性漏洞：

1. 并发与竞态条件：高并发访问下，这段逻辑是否会导致数据库死锁或缓存击穿？
2. 幂等性保障：如果消息队列推送了重复消息，或者用户在前端重复点击，接口会不会扣两次款？
3. 资源泄漏：数据库连接池、文件句柄、Redis 客户端是否在异常分支中被妥善释放？

这些地方往往只需寥寥几行代码就能掩盖严重的线上隐患，靠粗略扫视实现细节很难发现，必须带着预设的“攻击性思维”去审视。

---

三、追踪状态变更与副作用

函数式编程强调纯函数，但真实业务系统到处都是副作用。AI 最容易在不经意间破坏系统状态。

审查时要把注意力聚焦在“外部交互”节点上：

• 数据流向了哪里？ 它有没有在无意中修改全局对象？有没有直接篡改传入的请求上下文？
• 事务边界在哪里？ 涉及跨表写入时，事务是在何时开启、何时提交的？是否存在在事务中调用第三方 HTTP 接口的低级错误？
• 日志与监控埋点：关键状态流转是否有可观测性支撑？发生异常时打出的日志是否包含了排查所需的关键 traceId？

---

四、审查依赖项与接口契约

AI 有一个臭名昭著的习惯：幻觉式引入依赖。

它可能会为了实现一个简单的深拷贝，就随手 npm install 或 pip install 一个鲜为人知的库，甚至凭空捏造一个不存在的包名。这不仅会带来供应链安全风险，还会让项目的依赖树变得臃肿不堪。

检查变更文件列表时，优先看配置文件的变化：

• 是否引入了不必要的三方依赖？现有标准库或项目内置工具能否解决？
• API 契约（入参和出参定义）是否破坏了向后兼容性？字段命名是否契合团队内部的已有规范？

---

总结：从“打字员监工”到“系统架构师”

代码生成的工业化，正在倒逼软件工程师回归工程的本质。

逐行读代码是手工作坊时代的产物。在人机协同编程的阶段，工程师的职责不再是逐字确认标点符号，而是作为系统的守门人，把控接口契约、制定验证标准、防范系统性风险。

把实现交给模型，把约束留给自己。这是开发效率发生质变的唯一路径。