我最近看 Claude Code 的功能体系时，最大的感受不是它又多了多少新名词，而是它已经越来越像一个小型工程组织。里面有长期记忆，有临时技能，有外部工具连接，有独立工作线程，有事件触发器，还有可以打包分发的插件体系。单独看每个功能都不难，真正容易混乱的是，什么时候该用CLAUDE.md，什么时候该写 Skill，什么时候该拉一个 Subagent，什么时候该接 MCP，什么时候该把规则写成 Hook。很多团队刚开始接入 Claude Code 时，很容易犯一个工程师式的错误，看到功能就想配置。项目根目录放一个很长的CLAUDE.md，再加几个 Skill，再接一堆 MCP server，过两天又开始写 Hook。结果 Claude Code 每次启动都背着一大包上下文，执行时还要在很多相似规则之间做判断，反而没有变聪明，只是变得更忙。更合理的做法，是把 Claude Code 看成一个有不同工作方式的工程同事。不同功能不是平级替代品，而是对应不同的协作目标。目标越清楚，配置越简单。目标不清楚，功能越多越容易互相干扰。常驻上下文适合放进CLAUDE.mdCLAUDE.md最适合承载那些每次对话都应该知道的项目事实。比如我们团队统一使用pnpm而不是npm，提交前必须跑测试，前端状态管理只允许走某个 store 层，后端服务里禁止直接拼 SQL。这些都不是某个任务临时需要的信息，而是项目的工作方式。把这些内容放进聊天窗口里，短期能用，长期会丢。新的 sessio