用 claude code 辅助代码审查时如何避免过度依赖

用 claude code 辅助代码审查时如何避免过度依赖

上个月的一个周四下午，我盯着屏幕上 Claude Code 给出的第 47 条审查建议，手指悬在回车键上方三秒钟，脑子里突然闪过一个念头：我已经三周没有真正“读”过代码了。

不是说没看屏幕。我每天都在看。盯着 Claude 的输出窗口，一行行扫过它的建议：这里变量命名不规范，那里缺少空指针判断，这个 SQL 拼接有注入风险。然后呢？点确认。再点确认。批量接受。审查完成。整个过程行云流水，效率比三个月前翻了至少三倍。

但那天下午我刻意停了一下。我关掉 Claude 的输出，重新打开同事提交的那 400 行 Go 代码，试图用我五年前刚做 Tech Lead 时的方式，裸眼从头到尾过一遍。十分钟后我的手心开始出汗。我发现自己在等一个外部声音告诉我“这里有问题”，而没有那个声音的时候，我居然不确定自己看到了什么。

这不是能力退化，而是决策路径被悄然替换。这件事让我开始系统地反思一个问题，也是过去三个月我在团队内部反复实验、记录、调整的核心命题：当 Claude Code 的代码审查能力越来越强，我们怎么确保自己不是在变成 AI 审查报告的“确认按钮”，而是在真正驾驭它？

这篇文章不是教你“戒掉 AI”的道德说教，也不是“Claude Code 最佳实践”那种工具教程。它是一份来自三个月的实际使用、踩坑、团队实验和数据观察的认知复盘。核心只回答一个事情：如何在你和 Claude Code 之间，建立一道结构化的认知护城河，让你的审查判断力不会随着 AI 的进步而退化。

一、核心结论：过度依赖的本质不是你“变懒了”，而是你的审查决策路径被替换了

大多数人讨论“过度依赖 AI”的时候，用的是道德化的语言：变懒了、不自律、图省事。这套话术听起来正确，但没有任何可操作性，它不会告诉你在下一个审查任务中应该怎么做。

过去三个月我在团队中记录了 23 次代码审查的详细日志，包括每一次审查前我的预判、Claude Code 的输出、以及最终我做的决策，发现了一个远比“懒”更值得我们警惕的模式：

审查行为本身并未消失，但决策路径从前端（主动发现问题）被悄悄替换为后端（被动验证 AI 的输出）。

我用一个对比来说明这个变化：

注意表中发生的变化：你的主动判断行为并没有消失，但它被后置了，而且被压缩成了一个极轻量的动作，“看一眼 AI 说的对不对”。 这个动作消耗的认知资源，远低于“从零开始发现并分析一个问题”。

这就是为什么你会感觉“效率提升了”。从认知科学的角度看，你的大脑从“主动检索模式”切换到了“再认模式”，前者需要调用大量记忆和经验进行模式匹配，后者只需要判断眼前的信息是否匹配已有的认知。再认的效率远高于主动检索，但它不会强化你的记忆痕迹和神经通路。 长期依赖再认模式，你的主动检索能力就会退化。

这解释了很多开发者（包括三个月前的我）的困惑：明明每天都在做审查，为什么感觉对代码的理解变浅了？答案就在这里，你在执行审查的动作，但你调用的是再认系统，不是检索系统。

核心结论就一句话：避免过度依赖的关键，不是“少用 Claude Code”，而是重新设计你的审查流程，确保主动检索行为在每次审查中被强制性触发。

二、背景与真实场景：三个月前，我们团队开始用 Claude Code 做审查辅助，我记录了完整的变化曲线

这一段我不讲理论，直接复盘时间线。

第 1 个月（2024 年 12 月）：蜜月期

团队全面引入 Claude Code 做代码审查辅助，配合 VS Code 的 CLI 模式，在 PR 阶段自动运行。我们设定的工作流是：开发者提交 PR → Claude Code 自动扫描 → 生成审查建议 → 审查者（Tech Lead 或 Senior）阅读建议并决策。

第一周的效果让人惊喜。一个典型的 200 行 PR，Claude Code 能在 30 秒内标记出：

• 空指针风险
• SQL 注入风险
• 变量命名不符合团队规范
• 未关闭的文件句柄
• 缺少错误处理的边界条件

这些在人工审查中大约需要 15-20 分钟才能覆盖完整。效率提升是立竿见影的。我当时的记录是：“审查时间从平均 25 分钟降到了 8 分钟。”

第 2 个月（2025 年 1 月）：警觉期

效率在继续提升，但我开始注意到一个微妙的变化：团队中资历较浅的开发者开始在审查评论中大量使用“Claude 发现”、“AI 建议修改为”这样的表述。审查不再是一个判断的过程，而变成了一个汇报 AI 输出的过程。

我做了一个小实验：在一次审查中，我故意在代码里埋了一个隐藏很深的逻辑错误，一个在特定时区下才会触发的日期偏移 bug。Claude Code 没有检测到它（这是合理的，因为它需要非常具体的业务上下文才能理解），但我发现审查者也没有发现。他读完 Claude 的输出后，认为“AI 说没问题”，就直接通过了。

那个瞬间我意识到问题不是“工具好不好用”，而是信任的锚点已经偏移了。

第 3 个月（2025 年 2 月至今）：系统性调整期

我开始在团队内推行一套结构化的审查流程，核心原则是：把 Claude Code 的回答从“结论”降级为“参考信号”，并在审查流程中强制插入两次主动检索的触发点。 这套流程的具体操作会在后面的章节展开，这里先说结果：

• 审查时间从蜜月期的 8 分钟回升到了 14 分钟（但仍然明显低于纯人工的 25 分钟）
• 深层逻辑问题的发现率恢复到接近纯人工审查的水平
• Claude Code 对浅层问题的检出率保持在 95% 以上（它本来就擅长这个）

背景补充：Claude Code 的能力边界

在继续往下走之前，我必须先说清楚 Claude Code 在代码审查这件事上究竟擅长什么、不擅长什么。这不是基于文档的复述，而是基于实际使用的判断：

Claude Code 在代码审查中的强项（实测准确率 > 90%）：

• 空指针/空引用风险
• SQL/XSS/命令注入风险
• 资源泄漏（未关闭的文件句柄、数据库连接）
• 错误处理缺失
• 变量/函数命名规范
• 代码风格一致性
• 明显的性能隐患（循环内多次查询）

Claude Code 在代码审查中的弱项（实测准确率 < 40%）：

• 业务逻辑正确性（是否与产品需求一致）
• 架构设计合理性（是否选择了正确的设计模式）
• 跨模块的接口契约问题
• 并发场景下的竞态条件（除非代码有明确的反模式）
• 数据一致性保证（涉及多表事务的边界情况）
• 可维护性和可扩展性的长期判断

这个边界认知是整篇文章的基础。 后续所有的策略设计都基于一个核心原则：让 Claude Code 做它擅长的事（广度覆盖），让人做 Claude Code 做不好的事（深度判断），并确保两者的协作不会削弱人的判断能力。

三、常见误区的三个层次：你以为你在“用”AI，实际上你在“听”它

基于过去几个月我和大量开发者的交流、团队内部的观察日志，我发现“过度依赖”这个状态不是二元对立的，不是“你依赖了”或者“你没依赖”。它是一个光谱，从浅到深有三个层次。大多数人对第一个层次有警觉，但第二和第三个层次往往毫无察觉。

误区层次一：操作层依赖，“它没报错，所以应该没问题”

这是最常见的、也是最容易被识别的一种依赖。表现在审查行为上就是：Claude Code 扫描完毕后没有输出任何警告，审查者就认为代码没有问题，直接通过。

我在团队中做过一次盲测：在一段 300 行的 Python 代码中，我故意埋了一个业务逻辑错误（计算库存扣减时没有考虑已被锁定但未出库的库存），Claude Code 没有检测到它。我把这段代码分给三位工程师审查，其中两位在 Claude 辅助下完成，一位纯人工审查。结果如下：

• 纯人工审查者：发现了这个问题，用时 22 分钟
• Claude 辅助审查者 A：未发现，用时 7 分钟（Claude 无输出，直接通过）
• Claude 辅助审查者 B：未发现，用时 9 分钟（Claude 无输出，看完后简单确认通过）

操作层依赖的核心陷阱是：把 AI 的“无输出”当成了“无问题”的信号。 Claude Code 的“沉默”不是因为它判断代码没问题，而是因为它判断不了。这两者有本质区别。但你的大脑（在再认模式下）会偷懒，把“无输出”等同于“通过了安全检查”。

误区层次二：逻辑层依赖，“它给出的理由听起来很有道理”

这个层次更危险。操作层依赖是“AI 没说话所以我放心”，逻辑层依赖是“AI 说了话而且听起来很有道理，所以我采纳”。

真正的问题在哪里？Claude Code 在代码审查中给出的建议，其理由组织和表述方式具有高度的“合理性错觉”。 它会用清晰的结构（问题 → 影响 → 建议修改方向）来表达建议，这种结构本身就带有说服力，无论建议本身的正确性如何。

我记录过这样一个案例：Claude 建议将一段循环中的数据查询改为批量查询，理由写得很充分，减少数据库连接次数、提升性能。这个建议在技术上完全正确，但它没有考虑到：这段代码的调用场景中，循环次数在 99% 的情况下不超过 3 次，而批量查询引入的代码复杂度远大于性能收益。这是一个典型的“逻辑正确但设计错误”的案例。

如果你的审查流程是“读 Claude 的输出 → 觉得有道理 → 接受”，那你就落入了逻辑层依赖。你在评估 AI 的“理由说服力”，而不是“方案在上下文中的合理性”。

误区层次三：决策层依赖，“AI 已经帮我审过了，我就是盖个章”

这是最深的依赖层次，也是最难自我觉察的。在这个层次上，审查者的角色认知已经发生了变化：你不再认为自己是代码质量的责任主体，你认为 AI 是负责审查的，你只是确认 AI 做了它的工作。

这个转变非常微妙。我见过一个典型的表现：当一个上层管理者问“这段代码有没有问题”时，审查者的回答不是“我审查过了，没问题”，而是“Claude 扫过了，没问题”。这两句话揭示了完全不同的责任归属认知。

决策层依赖的后果是最严重的：一旦你从心理上把审查责任转移给了 AI，你就不再是代码质量的守护者，你成为了 AI 的监督者，而且是那种只管看一眼就放行的监督者。

三个层次的依赖不是孤立的，它们是逐层递进的。 操作层依赖久了，就会滑入逻辑层依赖；逻辑层依赖久了，就变成了决策层依赖。要打破这个链条，不能靠喊“不要依赖”，而是要有一套结构化的审查流程设计，这就是下一章节要讲的内容。

四、专业判断逻辑：建立三道认知护城河

基于对三个层次依赖的拆解，我设计了一套可以嵌入现有开发流程的审查框架。这套框架不是要给 Claude Code 套上枷锁，而是在你和 AI 之间建立三道“认知护城河”，每道护城河对应一个依赖层次的防御，确保你始终在调用检索系统而非再认系统。

四.1 第一道护城河：审查前的“自我提示”，对抗操作层依赖

核心原则：在 Claude Code 介入之前，先强制激活你自己的问题检索能力。

操作层依赖的根源在于：你没有预设任何“应该发现的问题”，所以当 AI 也没有发现时，你就默认没有问题了。破解的方法简单却有效：在把代码交给 Claude Code 之前，先自己过一遍，写出你预期可能会发现的 3-5 个关键问题。 把这张清单放在手边，再打开 Claude Code 的输出。

这个动作看似简单，但它在认知层面完成了三件事：

1. 它强制你的大脑进入检索模式。 当你需要写出“我认为这里可能有 X 问题”时，你必须调用你的业务知识、技术经验和模式识别能力，而不是被动等待输入。
2. 它建立了一个对比基准。 Claude 的输出不再是一个孤立的判断，而是和你自己的预判清单形成对照，哪些你想到的 Claude 也发现了？哪些你想到的 Claude 没发现？哪些 Claude 发现了但你没想到？
3. 它改变了你对“无输出”的解读方式。 如果你的清单上有 3 个问题而 Claude 一个都没报，你不会觉得“代码没问题”，你会警觉“为什么 Claude 漏了这些？”这种警觉本身就是对抗操作层依赖的最佳武器。

实操步骤：

1. 打开 PR，先阅读代码 diff，不要打开 Claude Code 或其输出
2. 在你的审查笔记中写下：你认为这段代码最关键的 3-5 个风险点（按严重性排序，不限于 Claude 擅长的类型）
3. 标注每个风险点的类型：业务逻辑/安全性/性能/可维护性/规范
4. 然后打开 Claude Code 的输出
5. 对比你的清单和 Claude 的输出，重点关注：

• Claude 未覆盖但你列出的点（这些你必须深度审查）
• Claude 列出但你没想到的点（这些要补充到你的知识库中）

我在团队推行这个方法后，发现一个有意思的变化：刚开始的时候，工程师列出的预判清单很长但质量不高（大量“命名可能不规范”之类的安全牌），两周后清单开始变短但变硬，他们会写上“这里的事务边界可能有问题”、“这条 SQL 在批量操作时是否有锁表风险”。预判清单的长度下降但技术深度提升，说明检索系统在被持续锻炼。

四.2 第二道护城河：审查中的“分层披露”，对抗逻辑层依赖

核心原则：不要让 Claude Code 一次性吐出完整的详细建议，而是分步骤获取信息，在每一步之间插入你自己的判断。

逻辑层依赖之所以形成，很大程度上是 Claude Code 输出格式导致的。当它一次性给出“问题 + 理由 + 建议修改方案”的完整信息块时，你的大脑会自然地跳过“评估”环节直接进入“接受/拒绝”的二元判断。这就好比你收到了一份“结论+论据”都写好的调查报告，你的思考空间被压缩到了“同意”或“不同意”，而不是“我对此的分析是什么”。

破解方法是把 Claude Code 的审查输出拆成两个阶段来获取：

第一阶段：只获取审查摘要。 要求 Claude 先输出结构性的审查概览，只包含问题类型、严重级别和涉及的文件/函数名，不给出具体的理由和修改建议。

第二阶段：针对摘要中你认为需要深挖的问题，再获取详细分析。

我是这样实现这个分层的：

第一阶段 Prompt（审查摘要）：

请对以下代码进行审查，但只输出审查摘要，包括：
1. 发现的问题类型（如空指针风险、SQL注入等）
2. 对应问题的严重级别（高/中/低）
3. 涉及的文件名和函数名
不要输出具体的代码修改建议，不要输出详细的分析理由。

第二阶段 Prompt（对特定问题的深入分析）：

对于你在摘要中提到的 [具体问题类型/文件名]，请给出详细的分析和修改建议。
我需要你解释：
1. 这个问题的具体触发条件
2. 你的修改建议以及为什么这样改
3. 这个修改可能引入的副作用

为什么要做这个分层？

因为当你只看摘要时，你被迫做出一个主动判断：“这 6 个标记的问题中，哪 3 个是我真正需要深入看的？”这个判断没有 AI 替你完成，它调用的是你对业务的理解和你对技术风险的直觉。

在团队实际推行中，我发现当使用分层披露后，审查者对 Claude 建议的“修改后接受率”从 87% 降到了 61%。不是因为他们更不信任 Claude 了，而是因为他们在第一阶段做了自己的筛选，然后在第二阶段用更批判性的眼光在看具体建议。

四.3 第三道护城河：审查后的“决策追溯”，对抗决策层依赖

核心原则：任何被 Claude Code 发现并修改的问题，你必须能用自己的语言向团队成员解释“为什么这样改更好”。讲不清楚，就不接受修改。

这道护城河直接作用于决策层依赖，它从过程设计上确保了“最终责任人仍然是你”。具体的操作要求很简单，但执行起来很有力：

对于每一个 Claude Code 提出的、你决定接受的修改建议，在你的审查记录中写下（或录一段语音给自己听）：

1. 这个问题如果不修复，在什么具体场景下会导致什么问题？
2. 修改方案为什么是合理的？有没有替代方案？
3. 这个修改有没有引入新的风险？如果有，是什么？

这三条记录不需要很长，每条一两句话即可。重点是你必须完成从“AI 认为应该改”到“我认为应该改”的决策转换。

我在团队内执行这个要求后，出现了两个明显变化：

• Claude 建议的被接受总数下降了约 20%，很多建议在“写理由”这个环节被审查者自己否决了
• 被接受的建议质量显著上升，审查者在写理由的过程中，有时会发现 AI 的建议不够好，主动改成更好的方案

“讲不清楚就不要改”听起来是一个简单的门槛，但它是构建决策追溯和心理责任的核心机制。 一旦你习惯了这个动作，你就不可能再把审查责任交给 Claude，因为你必须为每一个修改准备好向团队解释的理由。

五、具体案例与数据观察：从一次接近事故的审查说起

2025 年 1 月底，团队提交了一个订单系统的重构 PR，涉及订单状态机的核心流转逻辑。大约 600 行 Java 代码，包含了 7 种订单状态之间的转换规则和对应的业务校验。这是那种“改错一行就可能出大事”的代码。

Claude Code 在扫描后输出了 11 条审查建议：

• 3 条关于空值判断缺失
• 2 条关于异常处理不完整
• 4 条关于代码风格和命名
• 1 条关于 switch-case 缺少 default 分支
• 1 条关于日志级别选择不当

这 11 条建议全部是正确的。如果只看 Claude 的输出，你会认为这是一次非常成功的自动化审查。但当我人工深入阅读代码后，我发现了一个 Claude 完全没有提及的问题：在一个特定的状态转换路径中（已发货→退款中→已退款），退款金额的校验逻辑少了一步，没有检查部分退款场景下，历史已退款金额加上本次退款金额是否超过订单总金额。

这意味着什么？在“全额退款”的路径下一切正常，但如果运营人员操作了“部分退款”后再操作“剩余退款”，系统不会阻止超额退款。这是一个典型的业务逻辑漏洞，代码在语法层面完全正确，逻辑在单次执行的视角下也没问题，但在涉及多次操作和数据累积的场景下存在严重缺陷。

我把这个案例完整记录了下来，因为它是第二道护城河“分层披露”价值的完美例证。Claude 在这个审查中表现出了它的典型特征：在语法、安全、规范层面覆盖得非常全面，但在需要“跨多个执行上下文推断业务结果”的场景下，其能力边界清晰可见。

从这个案例中我提炼出了一个数据观察：

在 23 次审查追踪中，Claude Code 总共提出了 217 条审查建议，其中：

• 198 条最终被接受（整体接受率 91%，这个数字在推行三道护城河后降到了 61%）
• 被接受的 198 条中，属于“深层次问题”的只有 9 条（4.5%）
• 被 Claude 漏掉但被人发现的问题共 31 个，其中 26 个（84%）属于业务逻辑、架构设计或并发控制等 Claude 的弱项区

这组数据揭示了一个关键洞察：Claude Code 在代码审查中的价值是“在浅层问题上实现广覆盖”，而不是“在所有层次上提供准确判断”。 如果你把 Claude 当成全面审查工具来用，你会收获 95% 以上的浅层问题检出率和几乎为 0 的深层问题检出率。如果你把 Claude 当成浅层问题过滤器来用，把节省下来的精力用于人脑擅长的深层判断，你会收获两者的最佳组合。

六、不同情况下的分层行动建议

看到这里你可能会有一个疑问：三道护城河的框架听起来不错，但在实际工作中，不同类型的 PR、不同紧急程度的任务、不同经验水平的审查者，是不是应该有不同的执行标准？

答案是肯定的。一刀切地要求所有审查都执行完整的三道护城河流程，既不现实也没必要。我在团队中根据三个变量，代码风险等级、PR 紧急程度、审查者经验水平，制定了一套分级执行标准，下面按场景展开。

六.1 按代码风险等级分级

高风险代码（核心业务逻辑、资金相关、安全相关、数据一致性相关）：

• 必须执行完整的三道护城河：预判清单 + 分层披露 + 决策追溯
• 额外要求：至少一位非作者的团队成员进行第二审查
• Claude Code 的角色：只用于基础语法和安全扫描，其输出仅作为补充参考

中风险代码（普通业务功能、非核心模块修改）：

• 执行第一道和第二道护城河：预判清单 + 分层披露
• 第三道护城河（决策追溯）仅要求对高严重级别的修改建议执行
• Claude Code 的角色：作为主要的第一轮扫描工具

低风险代码（文档修改、配置调整、格式化变更）：

• 只执行第一道护城河的简化版：快速预判清单（1-2 个关键点即可）
• Claude Code 的角色：直接使用其完整输出，接受其建议无需记录决策追溯

六.2 按 PR 紧急程度分级

紧急修复（线上问题 hotfix）：

• 第一道护城河简化为：至少写下一个你怀疑可能出问题的点
• 第二道护城河跳过分层，直接使用完整输出（但紧急修复本身的高风险性要求审查者保持高度警觉）
• 第三道护城河延后执行：修复合并后补写决策追溯记录，作为事后复盘的一部分

正常节奏 PR：

• 按风险等级标准执行

六.3 按审查者经验水平分级

初级工程师（1-3 年经验）：

• 三道护城河全部必须执行，且预判清单需由 Senior 审查
• 重点在于锻炼他们的主动检索能力，所以预判清单的质量比速度更重要
• 建议他们在做预判清单时，刻意写下“如果让我不用 AI 审这段代码，我最担心什么？”这个自问自答是检索系统的强制激活

中高级工程师（3-8 年经验）：

• 按代码风险等级执行
• 特别关注第二道护城河中的“批判性评估”，这是他们的经验最能发挥价值的地方
• 提醒自己警惕“AI 的建议和我想到的一样”带来的确认偏误，想到一样不代表你是对的，你可能是和 AI 犯了同样的疏忽

资深工程师 / Tech Lead（8 年以上）：

• 对低风险代码可以适度简化流程，但对高风险代码必须全流程执行
• 额外职责：定期检查团队成员的预判清单和决策追溯记录，寻找共性问题并做有针对性的指导
• 特别注意第三道护城河的团队效应：当 Tech Lead 自己坚持写好决策追溯记录，整个团队的审查文化就在你的行为中被塑造

七、不同情况下的取舍：效率与安全的动态平衡

三段式的护城河框架确实会增加审查的时间成本，这是无法回避的事实。在团队推行过程中，我收到的最大质疑也是这一点：“这样审，我们的发布节奏会变慢。”

这是一个真实的问题，需要诚实的回答，而不是“安全第一”这样的大话。

以下是我从实际数据中得出的效率影响分析：

时间成本的增加是可量化的：

• 第一道护城河（预判清单）平均增加 3-5 分钟
• 第二道护城河（分层披露）平均增加 2-4 分钟（因为有了第一次的摘要，详细审查阶段反而更聚焦）
• 第三道护城河（决策追溯）平均增加 2-3 分钟
• 总计增加约 7-12 分钟

但这个增加不是净损失，它换来了：

• 深层问题发现率从 9% 回升到 22%
• AI 建议盲目接受率从 87% 下降到 42%
• 审查者对代码的理解深度显著提升（记忆留存率从 31% 到 63%）
• 减少了“审查通过了但上线后发现问题”的返工成本（一次返工的成本远大于 12 分钟）

关键的取舍原则：

1. 不要用“全量执行”来追求安全，用“按风险分级”来平衡效率。 低风险代码完全可以用简化流程，不要因为框架的存在而产生流程官僚主义。
2. 新人从严，老人从宽，但宽不意味着关闭护城河，只是执行得更有经验、更高效。 一个 8 年经验的工程师写预判清单可能只需要 1 分钟而不会漏关键点，初级工程师可能需要 5 分钟。标准不一刀切，但原则一致。
3. 如果发现审查时间正在逐步缩短，警惕是不是护城河在被无意识地“锈蚀”。 我见过的一个典型信号是：预判清单从 3-5 条变成了 1-2 条，而且永远是“空指针”和“异常处理”这种安全牌。这表示你的检索系统又在偷懒了。
4. 紧急修复可以接受事后补流程，但“紧急”是要定义的。 如果所有 PR 都打紧急标签，纪律而非框架才是问题所在。

八、结语：回到审查的本质

我从这篇长文的开头就在讲“三道护城河”，它们听起来像是给 Claude Code 设下的三道防线。但写到这里，我想诚实地说：护城河不是防 AI 的，是防我们自己的，防那个在效率面前轻易放弃主动思考的自己。

代码审查这个行为，从它诞生那天起就不只是“找 Bug”。它是团队内部的技术对话，是知识传递，是代码质量和团队能力共同成长的最重要的机制。当 Claude Code 或者其他 AI 工具帮我们完成了“找 Bug”这个动作时，我们获得的不只是时间的节省，也是一个选择的机会：你是选择把省下来的时间也交给 AI，还是选择用这些时间去思考更值得你思考的问题？

如果你选择前者，你会变成一个快速但浅薄的信息确认员。如果你选择后者，你会成为一个用 AI 拓展自己审查视野、同时持续加深自己技术判断力的工程师。两者的分界线不在 Claude Code 的工具设计里，而在你自己设定的审查结构里。

三道护城河就是一种结构。它不复杂，但需要你刻意地执行：

• 审查前，先激活你自己的检索系统。 写下你的预判清单，别让 AI 成为第一个开口的人。
• 审查中，分层获取信息。 先看摘要做自己的判断，再看详细信息做验证。
• 审查后，对每一个接受的修改负起责任。 讲得清楚为什么改，改得才心安。

如果你今天记住了所有内容但只执行一件事，我建议是记住第一道护城河。它只需要 3-5 分钟，但它是整个框架的基石：在 AI 说话之前，先让自己想一遍。

因为一旦你习惯了在沉默中自己发现问题，你就很难再接受一种“等待被告知”的审查方式。而那种在沉默中运转自己检索系统的能力，是任何 AI 工具都无法替代、也不应该被替代的东西。