现在很多人已经接受 AI 可以改代码，但真正让它进入日常工作流的，不是“它会不会写”，而是“它每次写完之后会不会把仓库搞乱”。这也是为什么我觉得 Claude Code 现在最值得实战看的，不只是改文件能力，而是 hooks 和 subagents 这两个更工程化的点。

前者让你在关键节点自动执行检查和清理动作，后者让你把不同类型任务拆给不同角色。放在一起，正好可以搭一个很实用的本地开发流：改代码前先补上下文，改代码后自动格式化和测试，高风险操作前再做一次拦截。

为什么这比单纯聊天写代码更值得做

因为真实开发里最痛苦的部分，往往不是“写不出代码”，而是“代码写了，但后续清理、验证、回归都要自己补”。只要这些脏活还全靠人，你就很难把 AI 真正接进日常流程。hooks 和 subagents 的价值，就是把一部分原本散落在你脑子里的流程规则，变成可以自动触发的工作机制。

推荐的最小实战流

• Subagent 1：需求梳理 agent，只负责把任务写成明确步骤。
• Subagent 2：代码修改 agent，只负责改动实现。
• Hook 1：改完文件后自动跑 formatter。
• Hook 2：执行命令前检查是否属于高风险动作。
• Hook 3：任务结束前自动跑测试或至少跑 smoke check。

这样做的关键，不是把系统搞复杂，而是把原来混在一起的事情拆开。需求梳理和代码修改分开，自动格式化和高风险拦截分开，最后的检查也单独存在。每一层都不重，但叠在一起，稳定性会比“让一个 AI 自己发挥”高很多。

怎么开始搭

先从最不会出事的一步开始：文件改完自动格式化。因为这是低风险、高回报，而且一旦养成习惯，你会明显感觉仓库噪音下降。然后再加第二层：在 Claude 准备执行某些命令前做拦截，例如涉及删除、覆盖、批量改动时先提示确认。

等这两层跑稳之后，再上 subagents。别一开始就造五六个角色。先做两个就够：一个“整理需求”，一个“执行代码修改”。前者输出清单，后者按清单工作。这个结构很简单，但已经能显著减少上下文跑偏。

建议先做的三条规则：
- edit 后自动跑 prettier / biome / eslint --fix
- 执行危险命令前先确认
- 任务完成前自动跑最小测试集

一个很适合独立开发者的用法

如果你是一个人做产品，可以把 subagent 里的“需求梳理 agent”做成自己的轻量 PM。你给它一句自然语言需求，它先把目标、改动范围、风险点和验收方式整理出来，再交给代码修改 agent。这样你就不会一上来让 AI 直接改仓库，而是先把问题讲清楚。

这个变化很小，但很值钱。很多 AI 写代码翻车，不是因为模型不会写，而是因为人类自己没把需求说清楚，就急着让它动手。

别做过头：这不是让 AI 接管开发

我不建议把 hooks 配得像 CI 平台，也不建议把 subagents 搞成组织架构图。Claude Code 这套东西最适合的，是给个人开发流加几层轻量约束，而不是把一台笔记本上的编码会话做成企业级编排系统。复杂度一旦超过项目收益，你很快就会关掉它。

更稳的路线是：先自动格式化，再自动最小测试，再做高风险拦截，最后才考虑更复杂的角色分工。每加一层都问自己一句：它是真的减少了返工，还是只是让我感觉系统更高级？

结论

Claude Code 值得实战看的地方，不只是它能跨文件改代码，而是它开始提供了把“开发习惯”写进工作流的能力。hooks 让规则自动发生，subagents 让上下文不再乱成一团。对个人开发者来说，这比追求一个什么都能干的 AI 编程神话，更接近真实生产力。