以前 review 代码，是看一个人怎么想。
现在 review AI 代码，常常是看一堵墙。
Agent 说“完成了”。你打开 diff：30 个文件，1200 行变化，测试全绿。你往下滚， 看到一些熟悉的模式、一些合理的抽象、一些看起来没问题的类型。滚到一半，你开始 加速；滚到最后，你点下 approve。
两周后有人问：“这个模块为什么变成这样？”
你答不上来。因为你当时也没有真正看懂，只是没有找到明显的错。
这不是某一个人的懒，而是 review 这件事在 AI 时代失效了。
一、Review 的对象变了
传统代码 review，表面上是在看代码，实际上是在看三件事：
- 这个人想解决什么问题；
- 他为什么这样改；
- 这个改动会不会破坏现有系统。
AI 把第一件事说得很清楚：“我完成了导出功能。” 但它很少把后两件事讲清楚：
- 为什么新增了一个服务？
- 为什么要把表格组件重写？
- 为什么这条依赖从 A 变成了 B？
- 哪些是需求，哪些是它顺手做的？
代码量越大，这些“为什么”越难从 diff 里还原。
Review 的对象其实已经从“代码”变成了“代码 + 意图 + 结构”。但大多数 review 工具只给你代码。
二、为什么 review 会崩？
1. Diff 太大，注意力先崩
一个人能认真 review 的代码量是有限的。超过那个量，人就会从“逐行判断”切换到 “模式识别”：
- 看起来像那么回事；
- 测试过了；
- 没有明显语法问题；
- 应该没事。
这不是 review，是盖章。
2. AI 代码看起来太“合理”
AI 写代码通常很整齐：命名一致、类型完整、注释像模像样。这种一致性会让人放松 警惕。
但“看起来合理”不等于“决策正确”。它可能在一个错误的位置写了很漂亮的代码， 也可能用一个很优雅的方式实现了不该做的需求。
3. 结构变化藏在行级 diff 里
一个模块被拆了，在 diff 里可能只是几个 import 和文件移动；一条跨层依赖出现了， 可能只是多了一行 import。
你看到的是行，系统发生的是结构变化。
4. 测试通过带来虚假安全感
测试通过只能说明“已覆盖的行为没坏”，不能说明：
- 结构是否合理；
- 是否引入了不必要的依赖；
- 是否把临时逻辑写进了长期代码；
- 是否偏离了原始需求。
测试是底线，不是 review 的替代品。
5. 没有“停止点”
人类 review 可以问作者：“这里为什么这么改？” AI 的默认流程是继续写，直到完成。它不会主动说“这个改动已经超出你的要求了， 要不要先确认？”
于是 review 成了唯一的刹车。但 review 已经超载了。
三、Review 不是逐行读，而是分层判断
我现在更愿意把 review 拆成四层：
- 意图：这次到底要解决什么问题？
- 结构：有没有新增模块、依赖、公开实体变化？
- 范围：有没有碰到不该碰的目录和文件？
- 实现：关键代码是否合理，测试是否覆盖？
这四层里，最贵的不是第 4 层，而是第 1 到第 3 层。因为它们决定“这次改动该不该 进入系统”。
如果一上来就扎进 1200 行代码，等于把最贵的判断留到最后，而那时注意力已经没了。
四、Jin 想补的是前三层
Jin 不试图让代码 review 变成一键通过。它做的是把意图、结构和范围先摆出来：
- 提案里有目标、范围、验收标准；
- 目标架构和当前架构有结构化差异；
- 差异里能看到新增/删除/变更/移动的模块、实体和依赖；
- 变更有版本，v1、v2 各自做了什么可以对比；
- 决策有记录：谁批准、什么时候、针对哪个目标哈希；
- 应用后有漂移检查，提醒架构和代码是否还对得上。
这样 review 的顺序可以变成：
- 先看提案：方向对不对？
- 再看架构 diff：结构有没有意外变化？
- 再看变更文件：范围有没有越界？
- 最后看关键代码：实现有没有问题？
- 跑测试和 CI：行为有没有坏？
它不是把 1200 行变成 12 行，而是先告诉你：这 1200 行在结构上意味着什么。
五、一个更现实的 review 策略
即使没有 Jin，也可以用这些原则减少“review 崩溃”：
- 限制一次 review 的规模。 超过自己认真看的量，就要求拆批，而不是假装看完。
- 先要“改了什么、为什么”的摘要。 不是让 AI 写一篇作文，而是列结构变化和风险点。
- 按风险抽样。 核心路径、权限、数据迁移、公共 API 重点看；格式化和小改动可以略过。
- 把“范围”当 review 项。 对照任务目标，看有没有非目标里的改动。
- 要求停止点。 结构变化先提案，不要写完再解释。
- 不要用 LGTM 代替判断。 如果说不清这次改动的结构影响，就不算 review 完。
六、审批不等于 review
这里要特别说清楚：Jin 的审批不是代码 review 的替代品。
批准一个提案，意味着你认可这次架构决策；不意味着你确认了每一行实现都正确。 代码层的 bug、边界条件、性能问题，仍然需要 review、测试和 CI。
Jin 解决的是 review 的入口问题：
- 先让你看见结构；
- 再让你决定要不要深入；
- 把“为什么”留在提案和历史里，而不是聊天记录里。
这不会让 review 变轻松，但会让 review 变得有可能做完。
七、Review 崩溃不是个人问题
如果你发现自己越来越不想 review AI 代码，不要先怪自己不够认真。
这更像是流程设计的问题：
- 一次给太多；
- 只给代码，不给意图；
- 只给行级 diff，不给结构；
- 只给结果，不给决策记录；
- 把测试通过当成可以合并的信号。
AI 写代码的速度已经超过了人类逐行 review 的速度。继续用“逐行看完”要求自己， 只会得到两种结果：要么累垮，要么放水。
更好的方式不是看快一点，而是先看更少、更关键的东西。
项目地址：
v2.0.32-jin.1 下载：
中文完整指南：
Jin 是 OpenCode 的社区分支，不是 OpenCode 官方产品。审批门不替代代码 review、 测试和 CI。
