人工 Review 的时代
Vibe Coding 时代，人工 Review 代码似乎变成了件稀罕事。在频繁迭代的项目中，我看着提PR 后，AI 自动根据 diff 生成的review 建议出了神，好像少了些什么，是没有了以往人工 review 的一问一答的仪式感吗？感觉没了一群人对着一行代码在解释意图，在argue 为什么这么写的场景，回忆一下
┌─────────────────────────────────────────────────────────┐
│ 人工 Review： │
│ │
│ 同事提 PR，你看完发现 useReducer 那段 │
│ 你：「为啥用 useReducer？useState 不更简单？」 │
│ 同事：「因为 loading 和 count 是绑定的，我试过 useState │
│ 但 dispatch 调用太散，后来改成 useReducer 好维护」 │
│ 你：「哦，那确实，继续审后面」 │
│ │
│ → 你和同事共享「这段代码的来龙去脉」 │
│ 因为他能从你解释里更新他对代码的理解 │
└─────────────────────────────────────────────────────────┘先拆一下：人工 review 里，"问意图"在解决什么问题
你同事写了段代码，你问「为什么用 useReducer」，本质不是为了听一个故事，而是为了回答三个隐藏问题：
Q1：他有没有意识到 useState 和 useReducer 在场景上的区别？
如果他根本没想过，那这段代码可能就是随手选的
Q2：他有没有考虑过后续修改成本？
如果他用的是「写的时候方便」的逻辑，半年后别人改会踩坑
Q3：他有没有发现他自己都没意识到的问题？
解释清楚反而暴露漏洞------"我本来以为 loading 独立管理， 但你看这里 dispatch 调用其实依赖了 count ...
拆下来："问意图"是 review 的一种诊断手段，不是目的。目的是让 reviewer 确认代码背后的假设是成立的。
人工Coding 时代，你是执行者，你得理解你写的代码，思路要清晰。
AI Coding 的时代
当代码是 AI 生成的，你是指挥者，那事情就变了。
场景换成：你让 AI 写了一个登录表单，自己审的时候点开一段代码问：「为什么这里用 useReducer？」
AI 会给出一个技术上合理的解释：「因为状态之间有依赖关系，用 reducer 可以让逻辑集中在一个地方，比三个 useState 更容易单测。」
这段回答是对的，但和人工 review 里的回答有一个本质区别------
它不是从决策历史里来的，而是从代码结构反向推理出来的。
你问人工 reviewer「你当时为什么这么选」，指向的是一个真实的思考过程：他试过 useState，被 linter 报了错，或者从 stackoverflow 抄的。
你问 AI「为什么这么写」，指向的是一个概率分布。模型选了 useReducer 不是因为它「决定」了要这么做，而是因为那个 token 在当前上下文的概率最高。
AI 没有意图。
所以当你追问「你有没有考虑过 X 方案」「这个接口为什么这么设计」，AI 的回答都是对代码的正确解读 ，而不是对设计意图的正确复现。
"问意图"这件事本身，在 AI 时代还重要吗？
我觉得分两层：
第一层：不需要的
arduino
"你当时为什么这么设计" → 这个意图已经不存在了
"你是从哪个方案折中过来的" → 折中过程是 AI 的，不是你的
"你有没有考虑过 X 方案" → 你也没考虑过，是 AI 选的这些问题的"你"这个主语已经没意义了。 因为写这段代码时，真正的「决定者」不是人，而是模型的 token 预测。
第二层：仍然需要的------但换了主语
arduino
"这段代码符合我想要的功能吗" ← 现在问这个
"如果我用 X 方案替代，会不会更好" ← 现在问这个
"这里有没有我漏掉的边界情况" ← 现在问这个意图审查的主体从「写代码的人」变成了「提需求的人（你）。」 你不再问「你当时为什么这么选」，而是问「这个选择对不对得上我要的东西」。
所以 review 的重点从什么迁移到了什么
| 传统 review | AI 时代 review | |
|---|---|---|
| 核心问题 | 这个人有没有想清楚？ | 这段代码有没有做到位？ |
| 诊断手段 | 问意图 → 暴露盲区 | 跑验证 → 暴露错误 |
| AI 扮演的角色 | 不存在 | 写代码的人（你没法问它） |
| Reviewer 扮演的角色 | 同行审假设 | 验收者审结果 |
在 AI 生成代码的背景下，reviewer 最该做的事其实是：
而且这些 review，不止发生在PR 阶段，在编码vibe 阶段就应该多问 多跑验证 多review
1. 验证：AI 写的代码真的做了我要的事情吗？
AI 最擅长的能力之一是写出「看起来合理但跑不通」的代码。它给你生成一个 hook，结构完美，但你一跑发现依赖项漏了，或者某个 props 在子组件里拿不到。这不是代码风格问题，是功能正确性问题。
2. 边界：有没有漏掉某些边界情况？
AI 生成的代码通常覆盖的是「大部分情况」。loading 状态、空数据、并发请求、用户快速点击------这些是 AI 最容易忽略的部分，因为训练数据里 happy path 占主导。
3. 一致性：这段代码和你项目里的其他代码风格一致吗？
AI 的「风格」来自训练数据，不是来自你的项目。它可能用了一个你没听过的模式、写了一个和你现有规范不符的命名、或者把业务逻辑放在了你约定放组件外部的位置。
4. 安全：AI 从训练数据里学的写法有没有坑？
AI 可能用了一个看起来对的但不安全的方法，或者引用了一个有已知漏洞的库。这些问题不来自设计意图，来自训练数据的噪声。
5. 可维护：半年后别人改得动吗？
AI 写的代码有一个常见的极端：要么过度复杂（把简单问题用设计模式堆出来），要么过度简化（把本该拆的逻辑挤在一行里）。这两种都让后续维护变得困难。
那当前 AI review 工具，解决的是什么问题？
arduino
"把代码审得更好" → 审完比人工审漏的少
"把代码审得更快" → 同样的审核质量，耗时更少AI review 工具主要解决的是第二个，顺便在第一个问题上做了妥协。
1. 让 reviewer 不用读 diff 全貌就能知道「这个 PR 改了什么」
你最痛的场景之一：打开一个 800 行 diff 的 PR，不知道从哪下手。
arduino
以前：逐行读 diff，15 分钟才能建立全局图景
现在：AI 先给你一个 summary------
"改了登录组件的状态管理，拆了 3 个 hook，改了 2 个路由配置，
影响范围涉及 4 个页面"解决的是：信息压缩。 人脑读 diff 是线性扫描的，AI 一次性通读给出摘要。这不是审得更细，是让你更快决定从哪看起。
2. 让 reviewer 不用在每行写"这个可以优化一下"这种废话
arduino
以前：reviewer 看到可以提取变量、可以换个方法名的地方
也写一两句 comment（因为"既然看了就顺便提一下"）
→ PR 上 60% 的评论是这类"锦上添花"而非"必须修"
现在：AI 把所有"锦上添花"都提前说了
→ reviewer 只需要处理真正该修的问题解决的是：评论信噪比。 让 reviewer 少写废话，多关注真正该修的问题。
3. 在 reviewer 还没看之前，先筛掉低级错误
arduino
以前：reviewer 打开 PR，第一眼看到------
"拼写错了" "import 重复了" "eslint 没跑" "没加类型"
→ 审了 5 分钟发现全是格式问题
现在：AI 在 reviewer 打开之前就已经发现了这些
→ reviewer 直接跳过这些，看真正的问题解决的是：reviewer 的时间浪费。 让 reviewer 的精力集中在真正需要人工判断的部分。
4. 让"安全扫描"变成自动的，不用等 CI 跑完
以前：CI pipeline 跑 CodeQL + ESLint → 10 分钟 → 报一批告警
现在：AI review 在 PR 创建时同步跑 → 20 秒 → 贴到 PR 上解决的是：反馈延迟。 不是更安全，是更快地知道不安全。
所以，「问意图」还重要吗？
更加重要了，但问法变了。 只是不再问「你为什么这么选」，而是问「这个选择对不对得上我要的东西」。
你不必纠结PR 阶段，Review 的 agent 是否能理解设计思路，而是关注AI 给的建议是否能更好的实现你的需求。
以下这些问题 Review 的 agent 没办法给出答案：
arduino
✗ "这段代码到底对不对得上你要的东西" ← 意图在你手里，AI 不懂
✗ "半年后这个写法会不会变成技术债" ← 需要项目演化历史
✗ "这个架构决策和上个月的决策有冲突吗" ← 需要团队记忆
✗ "这个组件为什么叫 xxx，不叫 yyy" ← 需要命名来源
✗ "这个改法在其他项目里出过什么坑" ← 需要跨项目经验所以代码写不写得好，AI 能判断；但代码值不值得写，只有你知道。