Claude Code 这类终端式 AI 编程工具真正有价值的地方，不是“它能聊天”，而是它能进入项目现场：读文件、跑命令、改代码、调用 MCP、执行 hooks。问题也随之出现：一个能动手的 AI，如果没有边界，就不是助手，而是一个很自信的实习生。

我的判断是：团队或个人项目要认真使用 Claude Code，第一步不是写更长的 prompt，而是配置 hooks、permissions 和项目级 settings。提示词负责意图，hooks 负责纪律。

实战配置思路

一个比较稳的做法，是把 Claude Code 的配置分成项目级和本地级。项目级配置放团队共享规则：允许读取哪些目录、常用测试命令、MCP server、提交前检查、禁止修改的文件。本地级配置只放个人机器相关的东西，比如本地路径、实验性插件、临时权限。

我通常会加三类 hooks。第一类是改代码前提醒：如果要修改 package.json、数据库迁移、权限模块，需要先说明影响范围。第二类是改代码后自动检查：运行 formatter、typecheck、关键测试。第三类是提交前拦截：如果测试失败，禁止生成“看起来很完整”的提交信息。

踩坑：不要让 hooks 变成新的噪音源

第一个坑是把 hooks 写得太重。每次小改动都跑全量测试，AI 会卡住，人也会烦。更好的方式是按目录区分命令：前端组件改动跑组件测试，API 改动跑接口测试，迁移文件改动再跑更完整的检查。

第二个坑是权限开得太大。很多人为了省事直接允许工具执行所有命令，短期确实顺滑，长期风险很高。AI 不一定恶意，但它会误解任务，也会尝试“合理”的捷径。rm、curl pipe sh、部署命令、数据库写操作，都应该显式拦住或要求人工确认。

第三个坑是没有给失败路径。hooks 失败后，如果只返回一大坨日志，AI 很容易继续猜。更好的做法是让脚本输出明确的下一步，例如“类型检查失败，请只修改 src/server/auth.ts，不要改测试快照”。AI 需要的不是更多日志，而是更清楚的约束。

适合谁现在动手

如果你只是偶尔让 AI 写脚本，没必要立刻折腾 hooks。但如果你已经让 AI 参与日常编码、重构、测试修复，hooks 就值得马上加。它不会让模型更聪明，但会让模型更像一个在项目规则里工作的成员。

对个人开发者尤其如此。一个人维护项目时，最大的问题不是没人写代码，而是没人帮你守边界。Claude Code hooks 的价值就在这里：它把一部分“别乱来”的工程常识，变成了可执行规则。

参考：Claude Code settings 文档：https://docs.anthropic.com/en/docs/claude-code/settings