大多数人把 Claude Code 当聊天机器人，它其实是 AI 智能体的完整操作系统

大多数人把 CLAUDE CODE 当聊天机器人用。它其实是一套为 AI Agent 打造的完整操作系统。 2026 年 7 月 7 日 · 11 分钟阅读 · 查看原文 ↗ Claude MCP AI 自动化 我看一个开发者在直播里用 Claude Code 构建了一整个项目。没有幻灯片，没有理论。只有终端。然后在某个时刻我意识到：六个月来，我大概只用了这个工具的 15%。 不是因为功能藏得深。它们就在眼前。只是我们大多数人装上 Claude Code、输入一句 prompt、拿到答案，就再也没往深里走。我们把它当成一个更聪明的自动补全。而它底下的真实架构有六层之深，你每开启一层，都会以难以言说的方式改变这个工具能做的事。 下面是每一层、它做什么，以及为什么跳过它会让你付出比想象更多的代价。 如果你对开发工具、AI，以及那些能让你在别人还没反应过来之前就拿到真正优势的玩法感兴趣，关注我。我会定期分享这方面的干货。 第 0 层：循环 在看功能之前，先理解引擎。 Claude Code 不是一个聊天机器人。它是一个 while 循环。它接到任务，挑一个工具（读文件、跑 bash 命令、web 搜索、调 MCP），运行它，看输出，决定下一步做什么，然后一直继续，直到任务完成、或者需要你的输入。 这个循环就是下面一切能运转的原因。Skills、hooks、subagents、MCP 服务器，全都插在这个循环的不同阶段上。如果你把 Claude Code 想成"我输入，它回应"，你就永远看不出这些功能为什么重要。如果你把它想成"我给它一个活儿，它跑一个循环直到把活儿干完"，整个架构就豁然开朗了。 第 1 层：CLAUDE.md。你项目的宪法。 这是 Claude 在每个会话开始时读的那个文件。它放在你的项目根目录里。它告诉 Claude 它是谁、要遵守什么规则，以及你的项目是怎么运作的。 大多数人要么完全跳过它，要么把能想到的所有东西全倒进去。这两种都错了。 一份好的 CLAUDE.md 很短。500 token 以内。它只包含那些 Claude 否则会搞错的规则。如果 Claude 在没人告诉的情况下已经能把某件事做对，就别写下来。你在浪费上下文。 该放在这里的： 语言和框架约定（"我们用 Pydantic v2，不是 v1"） 文件结构规则（"永远不要编辑 /generated 里的文件"） 测试要求（"说'完成'之前先跑 pytest"） 风格约束（"所有函数都要有类型注解"） 不该放在这里的： 长工作流（放进 skills） 自动化规则（放进 hooks） 研究流程（放进 subagents） 实用的判断很简单。如果一条指令必须对每个会话的每一轮都成立，它就进 CLAUDE.md。如果它只是有时才要紧，它就属于别处。 还有一件事。如果你的 CLAUDE.md 超过大约 60 行，Claude 就会开始忽略其中一部分。不是因为它读不了，而是因为重要的规则淹没在噪音里了。毫不留情地修剪。 第 2 层：Skills。按需加载的领域知识。 一个 skill 是 .claude/skills/<name>/ 里的一个 SKILL.md 文件。它有 frontmatter（name、description、可选的工具白名单）和一段包含说明、模式或检查清单的正文。 它和 CLAUDE.md 的关键区别在于：skills 只在相关时才加载。Claude 读描述，判断当前任务是否匹配，只在需要时才把 skill 正文拉进来。这就是渐进式披露（progressive disclosure）。你的上下文保持干净，直到需要领域知识的那一刻。 好的 skill 例子： 一份部署检查清单（"这是我们上生产环境的方式"） 一份迁移指南（"这是我们处理数据库迁移的方式"） 一份 PR 审核模板（"批准之前检查这 8 项"） 一份调试手册（"当 CI 里的测试失败时，先检查这些"） 经验法则：如果你已经把同一段说明给 Claude 输入过两次，那它第一次就应该是一个 skill。Skills 是可复用的知识。CLAUDE.md 是永久规则。别把两者搞混。 你也可以用斜杠命令（/skill-name）显式调用 skills，或者让 Claude 根据任务描述自动挑。两种都行。 第 3 层：Hooks。永远不会忘的自动化。 大多数人的配置就停在这一层。而有趣的正是从这里开始。 一个 hook 是一个脚本，会在 Claude 工作流中的特定节点自动触发。工具运行之前。工具运行之后。会话开始时。Claude 即将停下时。subagent 完成时。 hooks 和 CLAUDE.md 说明的关键区别在于：CLAUDE.md 是建议性的。Claude 可能照做，也可能不照做。Hooks 是确定性的。它们以代码形式运行。如果你写了一个 hook 来阻止写入 /migrations，那个目录就被锁死了。就这么定了。再多的 prompt 工程也覆盖不了它。 三个值得第一天就配上的 hook： **1. 编辑后自动格式化。** 每次 Claude 编辑一个文件，hook 就跑你的格式化器（prettier、black、rustfmt）。你从此再也不用审未格式化的代码了。 **2. 拦截危险命令。** 一个 pre-tool hook，拦截 bash 命令并阻止任何匹配某个模式的命令（rm -rf、DROP TABLE、强制推送）。自动模式下的安全网。 **3. 说"完成"前先跑测试。** 一个 stop hook，在 Claude 宣布任务完成之前跑你的测试套件。如果测试失败，Claude 就继续干。这一个 hook 消除了最常见的失败模式：看起来对、但跑不起来的代码。 你可以在 .claude/settings.json 里手动配 hooks，或者干脆让 Claude 去做："写一个 hook，在每次文件编辑后跑 eslint。"Claude 会替你写好。 一共有 17 个 hook 事件。大多数项目只需要 2 到 3 个。别想太多。从上面三个开始。 第 4 层：MCP 服务器。把 Claude 连到其他一切。 MCP（Model Context Protocol，模型上下文协议）是 Claude Code 跟外部工具对话的方式。一个 GitHub MCP 服务器让 Claude 能读 issue、建 PR、查 CI 状态。一个数据库 MCP 服务器让 Claude 能直接查你的表。一个浏览器 MCP 服务器让 Claude 能抓页面、读文档。 配置就一条命令： claude mcp add <name> <url> 就这么简单。MCP 服务器会作为一组 Claude 可以在循环里使用的工具出现。从 Linear 读 issue。发帖到 Slack。查你的 Postgres 数据库。看监控面板。从 Figma 拉设计。工具生态正在快速扩张，因为 MCP 是一个开放协议，而且每个严肃的产品都在发服务器。 实际的影响是：Claude 不再是一个只能看到你本地文件的工具。它变成了一个能看到你的文件、你的工单、你的数据库、你的 CI 流水线、你的文档和你的监控的工具。全都在同一个上下文里。全都在同一个循环里。 这里要紧的不是某一个单独的集成，而是复合效应。Claude 读那条失败的测试，查数据库确认 schema，看相关的 GitHub issue 了解上下文，修代码，跑测试，再把总结发到 Slack。一个 prompt。一个循环。五个工具。 没有 MCP，这些全得靠你自己 alt-tab 来回切换。听着耳熟吗？ 第 5 层：Subagents。上下文窗口问题，解决了。 这是改变我使用 Claude Code 方式的那个功能。 问题是这样的：上下文窗口会被填满。经过一小时的研究、写作和编辑之后，Claude 已经消耗了太多上下文，以至于忘了你一开始研究的是什么。自动压缩（auto-compaction）有帮助，但它是有损的。重要的细节会消失。 Subagents 通过拆分工作来解决这个问题。一个 subagent 拿到自己全新的上下文窗口、自己的工具权限、自己的指令。它做一个有边界的任务，然后返回一个结果。你的主对话保持干净。 Claude Code 内置了三个 agent： Explore（用 Haiku，又快又便宜，只读，当你问"X 在哪？"时触发） Plan（继承你的模型，只读，在 plan 模式里做研究用） General-purpose（完整工具权限，用于复杂的委派任务） 但真正的威力在自定义 agents。它们以 markdown 文件的形式放在 .claude/agents/ 里： --- name: researcher description: Deep web research on any topic tools: WebSearch, WebFetch, Read, Glob, Grep model: sonnet mcpServers: - perplexity - firecrawl --- You are a research specialist. Search thoroughly, cite sources, and return structured findings. 现在当你说"研究 OAuth 2.1 规范的最新变化"时，Claude 就会在自己的上下文里启动 researcher agent。研究在隔离环境里发生。你的主上下文保持干净。研究结果以结构化报告的形式返回。 心智模型：subagents 是你为特定活儿雇的专家。主 Claude Code 会话是协调它们的经理。经理不需要把所有研究、所有审核、所有实现细节同时装在脑子里。它委派。 什么时候用 subagents： 会消耗太多上下文的研究任务 代码审核（让一个 review agent 在隔离环境里检查 diff） 安全审计 文档生成 任何中间工作量大、但结果紧凑的任务 第 6 层：Plugins。把所有东西打包在一起。 Plugins 是最新的一层。一个 plugin 把 skills、hooks、subagents 和 MCP 服务器打包成一个可安装的单元。运行 /plugin 就能浏览市场。 与其为一个常见工作流手动配置每一层，不如装一个 plugin，直接拿到整套栈。一个代码智能 plugin 给 Claude 精确的符号导航，以及编辑后的自动错误检测。一个部署 plugin 给 Claude 发布代码所需的 skills、hooks 和 MCP 连接。 把 plugins 想成"最佳实践捆绑包"。有人为某个特定工作流摸清了 skills、hooks 和 agents 的正确组合，打包好并分享了出来。你一条命令就能装上。 把它们串起来的那套模式 真正的工作流不是"输入 prompt，拿到答案"。它是： 研究 → 计划 → 执行 → 审核 → 发布 而且每一个 Claude Code 功能都对应到其中一个阶段： 阶段 功能 研究 Subagents（隔离上下文、web 搜索、文档） 计划 Plan 模式、CLAUDE.md 约束 执行 Skills、MCP 服务器、bash、文件编辑 审核 Hooks（自动测试、自动 lint、自动格式化） 发布 Hooks（pre-commit 检查）、MCP（CI/CD、PR） 大多数人只用"执行"阶段。他们输入"构建这个功能"然后让 Claude 跑。这对小任务够用。对任何不平凡的任务，你都需要完整的循环。而完整的循环只有在这几层都配好的时候才能运转。 如果你一直"裸用" Claude Code，该从哪开始 别试图一次性把一切都配上。下面这个顺序，能让你投入的每一分钟都拿到最大回报： 第 1 周：写一份短的 CLAUDE.md（60 行以内）。加入你的项目约定、测试要求和文件结构规则。 第 2 周：加三个 hook。编辑后自动格式化。拦截危险命令。停下前跑测试。 第 3 周：连 1 到 2 个 MCP 服务器。从 GitHub 开始，再加上你团队用来管工单的那个。 第 4 周：为研究创建一个自定义 subagent。把它指向一个 web 搜索 MCP 服务器。用它，而不是在你的主上下文里做研究。 之后：为你向 Claude 解释过不止一次的任何工作流搭建 skills。装相关的 plugins。迭代。 每一步只要 10 到 15 分钟。一个月后的复合效应是惊人的。你从"终端里的聊天机器人"，变成一个完全编排好的 agent 系统——它会研究、计划、执行、审核和发布。自己干。而你则专注于那些真正需要人来做的决策。 结论 Claude Code 配置好了会很强大。它也很容易被过度配置。一份臃肿到 Claude 直接无视的 CLAUDE.md。十二个你从来用不上的 MCP 服务器。给那些放进主上下文就绰绰有余的任务也建 subagents。拖慢每次编辑的 hooks。 正确的配置，是能解决你实际问题的那个最小配置。从精简开始。当你感受到某一层能解决的痛时，再加那一层。而不是在那之前。 还有一件事：Claude Code 不是魔法。它是一个带着工具的 agent。它会犯错。它会幻觉出文件路径。它会写出能编译、却不是你要求的东西的代码。hooks 和审核层之所以存在，恰恰是因为执行层并不完美。价值不在于 Claude 能把所有事都做对。价值在于这个循环能在你之前抓到错误。 这里的干货，在它铺满每个角落之前就已经在这儿了。 标签：# X # Claude # MCP # AI # 自动化 # 指南 # Sonnet 相关文章 Graph Engineering replaced RAG at Microsoft, Stanford and Anthropic. Here's how it works. 收藏这个并关注——我是 Sprytix，一个打造 AI 系统和自动化流水线的开发者，把技术变成真正的收入。私信开放。 Claude AI MCP 自动化