Claude Code工程化六件套：从"高级聊天框"到AI工程团队

昨天看到有人吐槽：Claude Code用了一个月，感觉和ChatGPT差不多——写代码还行，但总得手把手教它"这个文件不能动""测试跑这个命令"。

说实话，我也经历过这个阶段。把Claude Code当"高级Copilot"用，每次开会前都要重新交代一遍规则，换了个任务就忘了项目结构。后来读了Anthropic官方文档，又翻了几篇团队工程化实战文章，才发现问题的根源不在模型，而在配置方式。

真正拉开差距的，不是谁家模型参数多，而是谁先把Claude Code搭成了"数字研发部"。

CLAUDE.md：不是文档库，是上岗须知

很多团队的第一反应是：把规则全写进CLAUDE.md。然后那个文件从50行膨胀到500行，塞满了编码规范、部署流程、安全红线、提交模板。

结果呢？Claude的指令遵循度越来越低。

CLAUDE.md里只放"事实"，不放"流程"。

什么是事实？构建命令是事实——mvn clean package -DskipTests。技术栈是事实——JDK 17、Spring Boot 3.2。目录结构是事实——web/ 放前端，core/ 放业务逻辑。

什么是流程？部署步骤是流程——先停服务、再备份数据库、然后迁移、最后重启。代码审查清单是流程——检查SQL注入、空指针、事务边界。这些不应该塞进CLAUDE.md，应该封装成Skills。

CLAUDE.md有三级加载机制：全局层（~/.claude/CLAUDE.md）放个人偏好，项目层（./CLAUDE.md）放技术栈宪法，模块层（./web/CLAUDE.md）放部门KPI。每一层只放当前作用域必须知道的事实。

写得毒比写得多重要。 "尽量不要改core模块"和"core模块为只读区，Write操作触发Hook拦截并终止会话"——后者才叫规则，前者叫建议。

Skills：按需加载的专项知识库

Skills是CLAUDE.md最容易被低估的搭档。

它的工作方式很简单：平时不加载，遇到匹配任务才调用。一个Code Review Skill可能包含50条检查项，但你写前端组件的时候根本不需要它——只有执行/code-review时才会加载那50条。

有人担心：技能库这么大，不会把上下文撑爆吗？

不会。ECC项目（GitHub 20万星）有246个Skills，作者的做法是按需加载——TypeScript项目用TS审查Agent，写Python测试时TDD Agent才启动。正式靠这种方式，才塞得下两百多个技能库。

Skill的核心价值是"轻启动、深执行"。 启动时只加载两行描述，执行时才展开全文。对比CLAUDE.md全程常驻的开销，这是质的区别。

实测数据：把团队Code Review清单做成Skill后，误报率下降41%，新人提问量减少63%。原因很简单——AI不再靠猜，而是按册索骥。

Hooks：不依赖模型自觉的硬约束

这是大多数人不知道的层级。

Hooks在生命周期事件上强制执行Shell命令——提交前跑lint、敏感操作前做安全检查、测试失败时阻止部署。它不依赖模型"是否记住了规则"，而是用代码强制保证关键动作一定发生。

一个典型场景：CLAUDE.md里写了"提交前必须跑单测"，但Claude偶尔还是会跳过。Hooks可以把这条规则写成硬约束——每次commit触发时，自动执行测试命令，失败则终止流程。

这就像电梯的安全制动器：每次关门之前必须校验，无法跳过。

Hooks的配置也很直接，在settings.json的hooks字段里定义事件类型和触发命令。事件类型包括pre-tool-call（工具调用前）、post-tool-call（工具调用后）、pre-response（输出前）等。

Subagents：隔离上下文，分工干脏活

复杂任务最怕污染主对话上下文。

Subagents的解法是把专项任务外包给独立实例——每个Subagent有独立的上下文窗口、独立的系统提示、独立的工具权限。主Agent委派任务，Subagent完成后只返回摘要，主对话干干净净。

一个实际的分工方案：主Agent负责架构设计和最终决策，Subagent A做代码探索（读大量文件但不影响主上下文），Subagent B做批量重构（跑测试、改代码），Subagent C做安全审查（扫描潜在漏洞）。

类比一下：主工程师把专项任务外包给独立实习生，实习生独立干活，只交报告，不占用主办公室的空间。

MCP：连接外部世界的桥梁

Claude Code原生支持文件系统读写和命令执行，但企业内部系统——Jira、Sentry、数据库——它碰不到。

MCP（Model Context Protocol）就是解决这个问题的协议。接一个Jira MCP Server，Claude就能直接查ticket描述；接一个数据库MCP Server，就能查表结构而不需要手动复制粘贴。

MCP让Claude从"孤岛"变成"节点"。 但它不是万能的——配置过多MCP会增加上下文复杂度，建议单个项目启用不超过10个，活跃工具控制在80个以内。

Plugins：把配置打包分发

前面五个层级解决的是"怎么用"的问题，Plugins解决的是"怎么传"的问题。

一个团队的CLAUDE.md、Skills、Hooks、MCP配置写好之后，怎么让新成员快速复用？手工复制配置文件？太慢了。

Plugins把整套配置打包成分发单元——安装一条命令，全套工程化配置到位。作者Affaan Mustafa把ECC开源后，其他人可以直接/plugin install ecc@ecc安装，61个Agent、246个Skills、76个命令开箱即用。

正确姿势：配置是养出来的，不是一次性写好的

最典型的错误是：团队开工前花一周时间把六件套全部配好，指望Claude Code第一天就变成资深工程师。

真实情况是：Claude Code第一次搞错某个约定，你把它写进CLAUDE.md；你反复输入同一段启动prompt，你保存成Skill；Claude第三次从浏览器复制数据，你接一个MCP Server。

配置是随着摩擦逐步长出来的，不是一开始就设计好的。 Anthropic官方文档明确给出了一组触发信号：第二次弄错就写CLAUDE.md，第三次粘贴同一段操作手册就沉淀成Skill，同一个多步骤流程超过三次就封装成Skills。

这套思路的本质是：把AI当作团队新成员，它的"入职手册"不是一天写好的，而是边工作边补充的。

配置前，先想清楚一个问题

我见过太多团队把六件套当成"功能清单"来配置——这个也要、那个也要，最后CLAUDE.md写了800行，Hooks配了十几个，Skills库比项目代码还大。

配置的目的是减少摩擦，不是增加复杂度。 每次新增一个配置项，问自己：这个摩擦出现了几次？如果只出现过一次，不值得配置；出现过三次以上，考虑；每次都出现，必须配置。

Claude Code本身只是工具，把它变成"AI工程团队"的是你的配置思路。六件套不是终点，是起点——真正的分水岭在于谁先用起来，而不是谁先看完文档。