本期关键词

• 反馈环（feedback loop） —— 行动 → 看结果 → 据结果修正 → 再行动的闭环。人改完代码跑一遍测试、看报错、回去改，就是在手动转这个环；自检环就是把这一圈交给 Claude 自己转。
• hook（钩子） —— 在 Claude 调用工具的前后自动触发的一段脚本。它不是问模型「要不要跑」，而是由 Claude Code 这个程序在固定时机强制执行，不受模型当时心情影响。
• PreToolUse / PostToolUse —— 两个最关键的触发时机：工具调用之前和之后。前者管「这步准不准做」，后者管「这步做得对不对」。
• 自动验证（auto-verification） —— Claude Code 2.1 起的原生工作流：生成代码后自动跑 lint、类型检查、测试，对照通过标准，不过就自纠重试，过了才确认交付。

一、你每天在 Claude 改完代码后做的那几下，就是环

先把「反馈环」落到地上，否则全是空话。

你让 Claude 改一个函数，它改完说「好了」。你不会直接信——你跑一遍测试，看有没有红；跑一下 lint，看格式和未用变量；可能再跑一次构建，确认没编译错。哪一项炸了，你把报错贴回去，Claude 看着报错改第二版。改对了，这一轮才真的结束。

这一圈「跑检查 → 看输出 → 据输出修正」就是反馈环。问题只在于：现在是你在转这个环。每改一次都要你手动跑、手动看、手动把错误喂回去。Claude 交回来的是「我觉得好了」，不是「我跑过了确实好了」——这两者之间的差距，恰好就是你每天来回审的那些时间。

自检环要做的事，是把转环的人从你换成 Claude。你那几下手动检查不消失，它们被写成脚本，挂在 Claude 的工具调用上，由程序自动触发。

二、hook 是什么：不靠模型自觉，靠程序在固定时机扣动

把手动检查交给 Claude，最朴素的想法是写进提示词：「每次改完文件都跑一遍测试」。这条路不稳——模型有时记得，赶上上下文长了、任务急了就忘了，你没法保证每次都跑。

hook 解决的正是这个「不保证」。hook 是一段由 Claude Code 程序本身、在固定时机自动执行的脚本，不经过模型的判断。最典型的用法是配一个 post-edit hook：Claude 每改一个文件，程序就自动替它跑测试套件。测试挂了，报错直接回到 Claude 眼前，它在你看到之前先自己改。

两个最关键的触发点：

• PreToolUse：在 Claude 真正执行某个工具调用之前触发。它能拦——hook 返回「不允许」，这步就被挡下，理由回给 Claude，让它换个做法。比如挡住对生产数据库的写操作、挡住碰某些受保护的文件。
• PostToolUse：在工具调用之后触发。它管验收——这次行动的结果有效吗？测试过了吗？类型对吗？不过，错误回给 Claude，它修。

判断：hook 把「检查」从模型的自觉变成了系统的契约。提示词里写的检查是「请你记得」，hook 是「程序保证」。这是用确定性的脚本兜住模型的不确定性，而不是指望模型每次都自律——和你不会指望自己每次手动改完都记得跑测试、所以才写 CI 是同一个道理。

三、pre + post 合起来，就是一个会自己修的环

单看一个 hook 只是一道检查。pre 和 post 配成一对，才合成完整的自纠环。一次工具调用的生命周期变成这样：

Claude 想做一件事（改文件、跑命令、写数据）→ PreToolUse 问「这步允许吗」→ 不允许，拦下、把理由回给 Claude，它调整做法 → 允许，执行 → PostToolUse 问「结果有效吗」→ 无效，把错误回给 Claude，它修 → 有效，进入下一步。

这个环的关键不在「检查」，在「让模型看到自己的错误输出」。为什么看到报错就能自己修？因为模型本来就擅长读错误信息改代码——一段 TypeError: cannot read property 'x' of undefined 加一个行号，对它和对你一样是明确的修复信号。它之前不修，不是不会，是没人把这个信号自动递到它面前。hook 做的就是把这根递信号的线接上：错误产生的瞬间，自动回流给模型，不等你来当中转。

于是「人工 QA」这件事被整体前移——从「Claude 交付之后人来回审」前移成「Claude 交付之前机器先自查」。省下的不是某一步，是你在「收到半成品 → 发现问题 → 退回去 → 再收 → 再查」之间来回跑的那整段时间。

四、2.1 把这套环升成了原生工作流

上面这套环，更早的版本能搭，但要你自己动手——手写 hook 脚本、自己配触发时机、自己把检查脚本串起来才闭得上。Claude Code 2.1 把它升成了原生的自动验证工作流：生成代码 → 自动跑 lint 和类型检查 → 执行测试 → 对照通过标准核对 → 不过就自纠重试、过了才确认。

这步升级的意义是：自检环从「高级用户的自定义配置」变成了「默认行为」。原本要你懂 hook、愿意花时间配脚本才享受得到的闭环，现在开箱就转。这和它隔壁那条主线（Dynamic Workflows 把多 agent 编排做成原生能力）是一个方向上的两只脚——都是把「资深用户手搭的脚手架」收进产品默认层，让普通用户不必先成为工程脚手架专家。

但原生不等于万能。自动验证能自动跑的，是有客观判据的检查：测试过没过、类型对不对、lint 干不干净——这些机器能下判断。需要人来拍板的（这个产品决策对不对、这段逻辑符不符合业务意图、这个权限边界能不能开），机器自动验证不了，也不该假装能。环能关到哪，取决于你给它的判据有多客观。

对从业者意味着什么

这件事对不同人是不同的动作：

• 对天天用 Claude Code 的工程师：把你每天手动重复的那几下检查盘出来——跑测试、lint、构建、查格式——挑其中高频且判据客观的，写成 hook 挂上 PostToolUse。一旦挂上，Claude 改完会先自查再交，你少当一次人肉 QA。关键是「高频 + 客观」：偶尔才做一次的检查不值得上 hook，需要你主观判断的检查 hook 也兜不住。
• 同时是个提醒：别把所有检查都怼成 hook。每个 hook 都在每次工具调用时跑，挂太多会拖慢每一步、刷出一堆噪音，最后你为了清噪音反而把环关了。先上一两个最痛的（通常是「改完忘跑测试」），跑顺了再加。
• 对团队 / Tech Lead：自检环是能沉淀的团队资产。把团队约定的检查（提交前必跑哪套测试、哪些文件碰不得、哪类操作要拦）写成共享 hook，等于把「资深的人脑子里那套交付前 checklist」固化成每个人的 Claude 都自动执行的契约——新人不用记，程序替他记。
• 对所有人的判断：验证循环是产品本身，不是附加功能。当生成代码越来越不要钱，你的价值不在「让 AI 写出东西」，而在「定义清楚什么叫对、并把这个判据交给机器自动反复核验」。会写 prompt 让 AI 干活的人很多；会设计「怎么自动确认 AI 干对了」的人，才是真把环关上的那个。

引用

1. Claude Code 官方账号（ClaudeDevs）推文，本篇引子——「怎么让 Claude Code 在交回成果前检查自己的活？看你如何把手动检查编码进去，让 Claude 自己关上反馈环」（How do you get Claude Code to check its own work before handing it back? Watch how you can encode your manual checks so Claude closes its own feedback loop）：https://x.com/ClaudeDevs/status/2061900434722496604
2. Claude Code Hooks 官方文档（PreToolUse / PostToolUse 触发时机与机制参考）：https://docs.claude.com/en/docs/claude-code/hooks