Claude Code 底层真相：越简单越强大？AI 架构大反转

Chapter 01

Claude Code 的惊人表现与反常识发现

介绍 Claude Code 在业界引发的震撼效应，包括 Google 工程师、前特斯拉 AI 总监的惊叹，以及创始人 Boris 30 天内 4 万行代码 100% 由 AI 完成。Manus X 团队拦截分析后发现，它的强大来自于「什么都没做」的极简设计。

Claude Code 发布六个月年收入突破 10 亿美元。整个 AI 圈都在卷多智能体编排、复杂的 RAG 流水线、嵌套的 Agent，而 Claude Code 内部只有一条规则：Keep it simple。它践行了 AI 领域经典文章「苦涩的教训」，证明依靠通用算力和简单方法最终会打败花哨的人为设计。Manus X 团队拦截并分析了它的每一个网络请求，得出结论：它的强大恰恰来自于什么都没做。

Google 的手机工程师说 Claude Code 一小时内生成了他团队花了一年时间才完成的东西

它的强大恰恰是来自于它什么都没有做

历史的反复证明依靠通用算力和简单方法最终会打败那些花哨的人为设计

Claude Code 极简架构苦涩的教训年收入十亿

Chapter 02

为什么要拒绝多智能体架构？

深入分析多智能体系统的调试难题。每增加一层抽象，调试难度呈指数级上升。当系统出现 bug 时，需要在多个 Agent 之间回溯交接记录，工作量巨大且容易出错。越简单的设计越好。

Reddit 用户直言：每增加一层抽象，调试就难十倍。当有 A、B、C、D 多个 Agent 时，出现错误需要反推到 C、B、A 去找问题根源。Agent 之间的交接记录非常复杂，往往导致错误。即使是 Claude Code 这样的系统，用户也表示远没有达到 95% 的准确率。如果再增加 Agent，准确率还会下降。发生 bug 的几率基本是 100%，单一线程和只有一层子线程嵌套时，能很快顺着一条线找到 bug 源头。

每加一层抽象，调试就更难。高度怀疑那些 AI 应用是否需要这么多的多智能体

当我要调试的时候，我得顺着一条线去找到问题的根源。如果没有的话，你这个子线程嵌套很多的话，你人工要去回溯找，这个工作量是相当大的

更复杂的系统会导致更多的错误，越简单，设计的越简单越好

多智能体调试困难嵌套循环错误溯源

Chapter 03

单循环架构：只允许一层子 Agent

Claude Code 采用单一主循环设计，绝不嵌套多层 Agent。主循环只允许附加一个子 Agent 处理它搞不定的事情，子 Agent 完成后必须将结果写回主干线，不允许在子 Agent 里再起子 Agent。

Claude Code 只开了一个单一循环（single while loop）。模型返回工具就继续调用，返回文本就结束对话。对话历史是扁平的，子任务最多只允许一层分支。例如写 Python 脚本时，如果中途需要用 pip 安装包，就启动一个 Sub-Agent，装完后通知主进程继续往下走。结果必须写回主干线循环。每增加一层抽象，调试就难十倍，因此反对嵌套循环。

Claude Code 没有在 Agent 里面多加一层循环，所有的东西都是一层循环的

主线只允许附加一个子 Agent 去处理它搞不定的事情，处理完后再反过来通知主进程

不能在 Sub-Agent 里面再起一个 Sub-Agent，Claude Code 是反对这种嵌套循环的

单循环控制循环子Agent 扁平架构

Chapter 04

成本控制：小模型干脏活累活

Claude Code 的系统提示只有 2800 token，但工具提示长达 9400 token，把力气花在教模型使用工具上。超过 50% 的调用使用 Haiku 小模型，读文件、解析网页、渲染动画等脏活累活全交给小模型，只有核心代码生成才用 Sonnet 或 Opus。

系统提示 2800 token vs 工具提示 9400 token，力气花在教模型使用工具上。超过 50% 调用使用 Haiku 小模型处理读文件、解析网页、渲染加载动画等任务。开发者要算账：Haiku 跑夜间自动化一个月成本不到 10 美金，换用 Sonnet 账单可能涨到 100 美金以上。小模型、中等模型、大模型各有用途，是成本化考量的结果。

系统提示只有 2800 个 Token，但工具提示却长达 9400 个 Token

把力气花在教模型怎么去使用工具上，而不是教模型说你是谁

大于 50% 的调用都是用 Haiku 这个模型，脏活累活全部交给 Haiku，只有核心的代码生成才是给 Sonnet

成本控制 Haiku Sonnet 工具提示

Chapter 05

提示词工程：把说明书写到极致

每次请求强制注入 cloud.md 实现长期记忆，记录项目规则、忽略目录、强制使用的库、测试命令、代码风格等。使用 XML 做结构化标记，包含 good example 和 bad example。system reminder 提醒容易遗忘的小事情。

每次请求强制注入 cloud.md 实现协作式记忆，包含项目规则（忽略哪些目录、强制使用哪些库、测试命令、代码风格等）。使用 XML 做结构化标记，包含 good example（之前正确的处理方式）和 bad example（做得不好的案例）。system reminder 提醒容易遗忘的小事。cloud.md 占 1000-2000 token。工程师比喻：模型像最聪明的实习生，需要把规则写进 DNA。不要吝啬 token，详细明确的指令是压榨模型性能最有效的办法。

模型就像最聪明的实习生，你需要把规则写进它的 DNA，它才不会犯错

这就是为什么他们的提示词要比论文还厚的原因

不要吝啬于 token，详细明确带正反案例的指令是压榨模型性能最直接而有效的办法

提示词工程 cloud.md XML标记协作式记忆

Chapter 06

工具设计：让模型像人类一样操作

Claude Code 没有 RAG、没有向量数据库、没有嵌入模型、甚至没有分块策略。让模型直接生成 grep、find、jq、Python path 等命令，像人类程序员一样翻代码。相信模型理解能力胜过相似度算法。

Claude Code 没有 RAG、向量数据库、嵌入模型或分块策略。让模型直接生成 grep、find、jq、Python path 等命令，像人类程序员一样翻代码。背后逻辑是相信模型理解能力胜过相似度算法。LinML 架构师打比方：RAG 就像激光雷达外置复杂传感器，而 Claude Code 的方法是训练驾驶员直接端到端用眼睛看。随着模型能力提升，「眼睛」会越来越好用。模型到今天已经远超相似度算法模型。

Claude Code 没有 RAG，没有向量数据库，也没有嵌入模型，甚至没有分块策略

让模型直接去生成 grep 命令、find 命令、jq 命令，像人类程序员一样去翻代码

这个选择的背后是相信模型理解的能力，胜过相信相似度的算法

工具设计无RAG 命令行工具端到端

Chapter 07

三层工具架构与任务管理

工具分三层：底层用 Bash、Read 保证灵活性；中间层封装高频操作如 grep、edit；上层封装特定流程如抓取网页、IDE 诊断。todo writer 工具让模型自己维护待办列表，防止长对话中忘事，实现仓库级理解而非代码片段补全。

工具分三层：最底层用 Bash、Read 保证灵活性；中间层是高频操作（grep、edit、文件通用命令）；上层封装特定流程（抓取网页、MCP 诊断等）。todo writer 工具让模型自己维护待办列表，防止长对话中忘事，往 cloud.md 等文件写入和删除内容。知乎网友评论：它真的理解整个项目而不只是代码片段，是仓库级的理解，不只是简单的代码补全，要有项目级的理解能力才行。

工具分成三层：最底层保证灵活性用 Bash、Read，中间层是高频操作，上层封装特定流程

todo writer 工具让模型自己维护待办列表，防止长对话中忘事

它真的理解整个项目，而不只是代码片段。它是仓库级的，要有项目级的理解能力

工具层级 todo writer 仓库级理解三层架构

Chapter 08

可靠性设计：语气风格与规则强化

通过「笨办法」提升可靠性：禁止不必要的开场白、禁止解释动机、只有用户要求才用表情符号、避免解释后果。用大写字母强调重要规则（THIS IS IMPORTANT）。不为用户猜测，明确使用 grep 而非 find。

Anthropic 用「笨办法」提升可靠性：禁止不必要开场白、禁止解释动机或后果、只有用户要求才用表情符号，保证语气风格简洁克制。用大写字母强调规则（THIS IS IMPORTANT），虽然原始但在大模型时代最有效。NEVER 为用户猜测 UI，OBVIOUSLY 使用 grep 而非 find。不是简单堆砌 do 和 don't，而是写成算法步骤：1. 分析需求 2. 检查 todo 列表 3. 选择工具 4. 执行并验证。让模型思考而非机械遵守规则。

禁止不必要的开场白，禁止去解释动机，只有用户要求才用表情符号

用大写强调，THIS IS IMPORTANT，这种方法虽然原始，但在大模型时代依然是最有效的强制手段

NEVER 为用户猜测，OBVIOUSLY 使用 grep 而非 find 命令

可靠性语气控制大写强调规则设计

Chapter 09

流程化决策而非机械规则

不简单堆砌 do 和 don't，而是把决策步骤流程化：先分析需求、检查 todo 列表、选择工具、最后执行并验证。让模型思考而非机械遵守规则，使输出更简洁、直接、克制，更少 bug。

不是简单堆砌 do 和 don't 规则，而是写成算法步骤：第一，分析需求；第二，检查 todo 列表；第三，选择工具；最后，执行并验证。这是在 task 任务里完成的过程。流程化决策而非机械遵守，要让模型思考。因为有这些可控性设计（语言风格简单高效、用大写强调、写算法流程化），才会让它更简洁、直接、克制，最后输出的结果更加可读、更有效、更少 bug。

不是简单堆 do 和 don't，而是写成算法的步骤

把决策的步骤流程化，而非堆砌 do 和 don't

要让模型去思考，而不是机械的遵守规则

流程化算法步骤决策设计思考能力

Chapter 10

Claude Code 的核心启示

把复杂留给模型，把简单留给系统。不要急着搞多 Agent，不要迷信 RAG，不要过度设计。相信模型本身的能力，给它清晰的工具和边界，它就能表现得像资深开发者。克制比复杂更需要勇气也更有价值。

Claude Code 给我们的启示：把复杂留给模型，把简单留给系统。别急着搞多 Agent，不要迷信 RAG，不要过度设计。相信模型本身的能力，给它清晰的工具和边界，它就能表现得像资深开发者。系统写满原则：用绝对路径、避免 cd、修改前必须 read、重要操作前要写 todo。Claude Code 在克制的情况下比其他复杂过度设计、吹嘘多 Agent 的系统更强。在 language model 日新月异的今天，按照 Claude Code 的结论就能做得很好。

把复杂留给模型，把简单的东西留给系统

不要迷信 RAG，不要过度设计。相信模型本身的能力，给他清晰的工具和边界，他就能表现得像资深的开发者

真正负责的魔法就是没有魔法，全是基本的东西

克制设计极简主义 KISS原则模型能力

Chapter 11

KISS 原则：真正的魔法就是没有魔法

Claude Code 的成功证明，真正负责的魔法就是没有魔法，全是基本的东西。Keep It Simple, Stupid（KISS）原则在 AI 时代依然是最有效的。克制比复杂更需要勇气，简单往往是最有效的。

真正负责的魔法就是没有魔法，全是基本的东西。Keep It Simple, Stupid（KISS）是 Claude Code 给我们上的一课。克制要比复杂更需要勇气也更有价值。在这个 AI 框架满天飞的时代，简单往往是最有效的。这是 Manus X 分析 Claude Code 底层思路和底层架构得出的结论。

真正负责的魔法就是没有魔法，全是基本的东西

Keep It Simple, Stupid，这个是给我们上的一课

克制要比复杂更需要勇气也更有价值。在这个 AI 框架满天飞的时代，简单往往是最有效的

KISS原则极简哲学基本功克制

Chapter 12

System Prompt 核心结构解析

Manus X 拦截分析 Claude Code 的请求，解析出 System Prompt 核心结构：环境设定部分、工具使用策略（优先使用专用工具、修改前必须读文件、使用绝对路径避免 cd、重要操作前写 TODO）、代码风格约束（不必要的开场白、不解释动机、保持简洁专业）。

Manus X 拦截并解析 Claude Code 的请求，还原 System Prompt 核心结构。第一部分：环境设定（workdir、system、date 等）。第二部分：工具使用策略（优先使用专用工具、修改前必须先读文件因为最近记忆最好、使用绝对路径避免 cd、重要操作前写 TODO）。第三部分：代码风格约束（不必要的开场白、不解释动机或后果、只有用户要求才用表情符号、保持简洁专业、除非被要求不要添加注释、避免 find 使用 grep/glob、永远不要猜测或生成 UI）。

System Prompt 第一部分是环境设定，第二部分是工具使用策略

修改前必须先去读文件，读了文件之后你才能去做修改操作，因为最近的记忆是最好的

永远不要猜测或者去生成给用户的 UI

System Prompt 工具策略风格约束请求解析