最近半年，我把不少重复性工作都交给了 Claude Code 打理。回头梳理这段经历时，我用了一个自己很喜欢的检验标准——费曼学习法：如果我没办法用大白话，把一个概念讲给完全不懂的人听懂，那说明我自己也还没真正理解它。
所以这篇笔记不打算堆术语，而是尽量把 Claude Code 的自动化能力拆成几个"能讲给同事听"的小故事，同时穿插一点赫伯特·西蒙（Herbert Simon）的学习观点：专家之所以比新手处理复杂问题更从容，并不是因为记性好，而是因为他们把零散的知识"组块化"（chunking）成了一个个可以整体调用的单元。这恰好也是 Claude Code 这套体系的设计哲学。
一、先把四个概念讲成大白话
Claude Code 的自动化能力建立在四层结构上：Skills（技能）、Agents（代理）、MCP Connectors（模型上下文协议连接器）、Plugins（插件）。如果只看官方文档的定义，很容易觉得抽象，我更喜欢这样类比：
- Skill 像一本「操作手册」：把某类任务的标准流程写成一份
SKILL.md 文件，Claude 会根据文件里的 description 字段判断"这件事该不该翻这本手册"，也可以让你手动用 /技能名 直接调用。
- Agent 像「执行的人」：主对话本身是一个执行者；遇到需要隔离上下文或并行处理的任务（比如同时审查上百份合同），可以派生出子代理（subagent）分头去干，互不干扰，最后再汇总结果；还可以设置成定时任务，在后台按计划自动运行。
- MCP Connector 像「数据管道」：让 Claude Code 直接接上 GitHub、Jira、Google Drive、数据库等外部系统，不用再手动复制粘贴信息进对话框。
- Plugin 像「一整套工具箱」：把多个 Skills、Agents、Hooks 和 MCP 配置打包在一起，团队里的人安装一次插件，就相当于把整套能力都装上了。
按西蒙的组块理论来理解：与其让 Claude 每次都从零思考"这件事该怎么做"，不如把常用的判断逻辑、操作步骤、外部连接方式，提前打包成一个个"组块"。这样一来，无论是 Claude 还是使用它的人，都能把注意力留给真正需要临场判断的部分，而不是浪费在重复搭建流程上。
二、四层结构分别长什么样
2.1 Skills：把流程写成一份"可被自动发现"的说明书
一个 SKILL.md 文件由 YAML frontmatter（元数据）和 Markdown 正文组成，例如：
---
name: nda-review
description: 按团队 playbook 审查 NDA 合同，输出修订建议并标记风险等级
allowed-tools: Read, Grep
disable-model-invocation: false
---
## 审查步骤
1. 对照关键条款清单逐项比对……
几个我踩过坑之后才搞清楚的细节：
description 字段是 Claude 判断"什么时候该用这个技能"的唯一依据，写得越具体（做什么 + 什么场景下用），触发越准确，写得太笼统反而会失灵。allowed-tools 可以提前给技能授权可用的工具，避免每次都要手动确认；但如果技能涉及有副作用的操作（比如部署、发送消息），建议加上 disable-model-invocation: true，让它只能被人手动触发，不能被 Claude 自主调用。- 技能正文建议控制在 500 行以内，超长的参考资料拆成
examples/、templates/ 等附属文件，按需加载，避免一次性把上下文塞满。
用费曼法自检一下：如果你没法用一句话说清楚"这个技能什么时候该被触发"，那这份 description 大概率也写不好，Claude 同样会判断失误。
2.2 Agents：知道什么时候该"分身"
主代理适合处理有连续对话、需要保留完整上下文的任务；但遇到批量、独立的任务（比如一次审查几十份合同、并行跑多个测试），更适合派生子代理，各自在隔离的上下文里工作，互不干扰，结束后再把结果汇总回主对话。
对于需要"无人值守"运行的场景，比如每周扫描一次即将到期的合同、把结果同步到 Slack，可以配置成定时任务，让它按计划自动执行，而不需要每次手动开对话。
2.3 MCP Connectors：接上真实世界的数据
MCP（Model Context Protocol）是一套开放协议，用来让 Claude Code 直接对接外部系统——GitHub、Jira、Notion、数据库、合同管理系统等等，通过 .mcp.json 或 claude mcp add 命令配置。有了它，工作流才能真正做到"端到端"：比如从 Jira 拉需求、写代码、提交 PR、回写工单状态，整个链路都不需要人工搬运数据。
2.4 Plugins：把能力打包分发给团队
一个 Plugin 可以把多个 Skills、Agents、Hooks 和 .mcp.json 配置捆在一起，通常包含 .claude-plugin/plugin.json 及对应目录结构，配上 README.md 说明安装方式。团队里把某个领域的经验（比如合规审查的完整流程）打包成插件后，其他人安装一次就能直接用，不用从零搭建。
三、我踩过坑之后总结的几条实践经验
- 技能描述要具体：
description 字段要同时说清"做什么"和"什么场景下用"，太笼统或太技术化，都会导致触发不准。
- 批量任务用子代理隔离：涉及多文档、多任务并行时，别让主对话背负所有上下文，交给子代理分头处理更稳。
- 监控类任务配合定时代理 + MCP：让系统自己按周期检查数据源、发通知，人只在需要决策时介入。
- MCP 优先用官方或社区成熟的连接器：自己手搓协议接入成本不低，且要留意授权范围，遵循最小权限原则。
- 插件遵循标准目录结构再分发：方便团队成员直接安装，也方便后续版本管理和迭代。
- 善用 Hooks 做自动化校验：编辑后自动格式化、提交前自动跑 lint，把容易漏检的环节交给程序而不是记忆。
- 明确目标后让 Claude 自己循环验证：设定好目标和验收标准，让它执行、自检、迭代，而不是每一步都要人工确认。
如果用西蒙的"刻意练习"视角看这份清单：真正让效率提升的，不是记住这七条本身，而是每次实践后回头问自己——"这次哪里卡住了，是不是可以再抽出一个新的 Skill 或 Hook，把这类问题组块化掉"。这也是我认为搭建自动化工作流最值得坚持的习惯。
四、几个需要留意的风险点
- 上下文和成本：子代理隔离、按需加载技能内容，能有效控制 token 消耗；大输出场景建议设置输出上限，避免一次返回过多内容拖慢流程。
- 可靠性：模型仍然可能出现幻觉或偏离预期，涉及生产部署、法律意见、财务决策等高风险任务，务必保留人工复核环节，并配合自动化测试或验收标准。
- 安全与隐私：接入 MCP 前要确认服务端可信，留意 prompt injection 风险；涉及敏感操作（比如删除、支付）应要求二次确认；跨系统集成时注意数据合规和权限最小化。
- 维护成本：流程一旦发生变化，要及时更新对应的 Skills 和 Plugins，建议纳入版本控制，避免"文档和实际流程脱节"。
- 不要把决策权全部交出去：自动化的目标是减少重复劳动，不是取消人的判断，保留必要的监督回路，尤其是在结果会影响到他人的场景里。
五、如果你也想上手，建议这样走
- 安装 Claude Code（终端、IDE 插件或桌面端均可，需要较新版本的 Node.js 环境）。
- 从一个最小可用的 Skill 开始：在项目里新建
SKILL.md，只写清楚一件小事，比如统一提交信息格式。
- 用
/技能名 手动测试一遍，确认触发和执行都符合预期。
- 遇到需要外部数据的场景，再引入一个 MCP 连接器，比如先接入你日常最常用的那个系统。
- 流程稳定之后，再考虑把多个 Skills、Agents 打包成 Plugin，方便自己复用或分享给团队。
- 每隔一段时间回顾一次："这段时间踩过什么坑，是不是能再抽象出一个新的组块"，把它写成新的 Skill 或 Hook。
结语
我越来越觉得，这套体系真正厉害的地方，不在于它能"自动做事"，而在于它逼着你把自己脑子里那些说不清、道不明的经验，写成一份别人也能看懂的说明书。这个过程本身就是费曼学习法在起作用——你写得出 SKILL.md，往往意味着你真的把这件事想透了；而当这些说明书越积越多，你处理复杂问题的方式也会像西蒙说的那样，从"逐步推理"变成"整体调用组块"，速度和从容感都会不一样。
参考资料：
