怎么让AI编程助手更强？

多加几个Agent？搞个复杂的协作框架？用RAG增强检索？训练专门的编程模型？

Claude Code对这个问题给出了一个反常识的答案：以上全都不要。

摒弃多Agent

想象一下你是一个创业公司老板，有个紧急任务要完成。你有两个选择：

• • 选项A：找一个能力很强的全栈员工，把任务交给他，让他从头到尾搞定。
• • 选项B：搭一个"完美团队"——产品经理、前端、后端、测试、运维，让他们协作完成。

表面上看，B 似乎更专业、更"大厂"。但当任务紧急、需求模糊的时候，A 的效率几乎总是碾压 B。

为什么？因为 B 有太多"中间环节"：

• • 产品经理要和前端对齐需求
• • 前端要和后端商量接口
• • 后端改了逻辑，得通知测试
• • 测试发现 bug，又要开会讨论……

每个环节都有信息损耗，每次对齐都有误解的可能。更要命的是，一旦某个环节出问题，你很难定位是谁的锅。

Claude Code 选择的就是"选项A"——一个强大的模型，加上一套趁手的工具，直接干活。

Claude Code 把所有的对话历史都维护在一个扁平的消息列表里。

你让它改一个 bug，它读代码的过程、思考的过程、修改的动作、验证的结果……全部按时间顺序记在同一个列表里。模型每次回答，都能看到完整的上下文。

这有什么好处？

1. 1. 信息不丢失：不存在"代理A告诉代理B的时候漏了一句关键信息"的问题
2. 2. 可追溯：出了问题，你翻历史记录就能完全还原当时发生了什么
3. 3. 可调试：开发者能直接看到模型"在想什么"，不用猜

当然，Claude Code 也不是完全没有"分工"。遇到特别复杂的任务，它还是会派生子代理来处理子任务。子代理的结果会原样写回主消息列表，变成一条"工具响应"。

这个设计精髓在于：该简单的地方极致简单，该复杂的地方用工程手段兜底。

不用 RAG，让 LLM 自己当搜索引擎

RAG 是目前较为主流的"让大模型获取外部知识"的方案。但 Claude Code 不用 RAG。

为什么？

想想 RAG 要做对多少件事：

1. 1. 文档怎么切块？按段落？按 token 数？按语义？
2. 2. 用什么模型做向量化？
3. 3. 相似度阈值设多少？
4. 4. 返回多少条结果合适？
5. 5. 如果最相关的信息正好跨了两个切块怎么办？

每一个决策都可能出错，而且错了你很难发现。你只会看到最终结果不太对，但不知道是哪个环节出了问题。

Claude Code 的做法是：直接让大模型用命令行工具搜索代码库。

它会用 ripgrep（高性能文本搜索工具）、find（查找文件）、jq（解析 JSON）这些工具，像一个熟练的程序员一样在代码库里翻找需要的信息。

这个设计妙在哪？

1）搜索行为是显式的、可观察的

模型要查什么、查到了什么、为什么觉得这条有用，全部记录在对话历史里。出了问题，你能复盘整个搜索过程。

2）搜索策略是可学习的

模型可以根据搜索结果调整策略——这次用关键词搜没搜到，那试试用正则？这个函数名太通用了，加个路径过滤试试？

这就像人类程序员查代码的过程：先试一种方法，看结果，不行就换个思路，反复迭代直到找到需要的信息。

3）不需要提前建索引

RAG 方案需要提前把代码库向量化、建索引。代码一改，索引就可能过期。而 grep / find 这种方案永远是实时搜索，不存在"索引没更新"的问题。

AI 系统设计要避免"黑盒依赖"

这个设计选择背后有一个更深的原则：能用显式、可观察的方式解决的问题，就不要用隐式、黑盒的方式。

RAG 的向量检索是黑盒——你不知道为什么这篇文档排前面、那篇排后面。
LLM 用 grep 搜索是白盒——搜索命令就在那里，结果就在那里，因果关系一目了然。

当系统出问题的时候，白盒系统让你能定位问题、修复问题、持续改进。黑盒系统只会让你抓瞎。

提示词工程

传统软件开发，我们习惯把规则写在代码里。这个按钮点了跳转到哪个页面、那个输入框怎么校验、异常情况怎么处理……全是代码逻辑。

但 LLM 应用有一个根本不同：你没法用代码"指挥"模型的每一步行为。模型是根据提示词理解任务、自主决策的。

Claude Code 的应对策略是：把大量的逻辑、规则、案例，全部写进提示词里。

• • 系统提示词：约 2,800 tokens
• • 工具说明：约 9,400 tokens
• • 项目规则文件（claude.md）：通常 1,000-2,000 tokens

加起来，每次对话模型要先"读"1万多 token 的"说明书"，然后才开始干活。

翻开 Claude Code 的提示词，你会发现它非常"工程化"：

1）大量的正例和反例

不是抽象地说"要写好代码"，而是：

<good-example>
xxx
</good-example>
 
<bad-example>
xxx
</bad-example>

为什么要这么具体？因为LLM 从例子中学习比从抽象规则中学习更可靠。你说"变量名要有意义"，模型可能理解各有偏差；但你给它看 10 个好例子、10 个坏例子，它就能学到你真正想要的风格。

2）强调词的策略性使用

提示词里充满了 IMPORTANT、NEVER、ALWAYS 这种强调词。

这不是因为作者喜欢大喊大叫，而是基于实践摸索出来的：对于某些关键行为边界，普通的陈述句不够"重"，模型可能会在边缘情况下违反。

这种写法能有效提高模型遵守规则的概率。

3）结构化标记

这么做的好处是：模型能更清晰地理解不同部分的边界和层级关系，减少信息混淆。

把"模糊地带"消灭在提示词里

很多 AI 应用效果不好，原因是开发者觉得"大模型应该能理解"，于是提示词写得很简略。

结果模型在无数模糊地带自由发挥，输出质量非常不稳定。

Claude Code 的做法相反：假设模型是个一板一眼的执行者，所有边界情况都提前想到、提前写清楚。

这是一个思维转变：好的 LLM 应用，不是让模型"自由发挥"，而是用精心设计的提示词，把模型的行为空间约束到"正确区间"里。

"一把好刀"胜过"十八般兵器"

在设计 AI Agent 能用的工具时，一个常见的直觉是：工具越多越好，覆盖的场景越全。

查文件？一个工具。写文件？一个工具。搜代码？一个工具。运行测试？一个工具……搞着搞着，工具清单就有几十个。

然后问题来了：模型在每一步都要从几十个工具里选一个。选错了，整个任务就可能跑偏。选择越多，出错概率越大。

Claude Code 的工具数量控制得很克制，而且有清晰的层次：

• • 底层工具：Bash（执行命令）、Read（读文件）、Write（写文件）
• • 中层工具：Grep（搜索）、Glob（模式匹配）、Edit（编辑）
• • 高层工具：WebFetch（抓网页）、getDiagnostics（获取语法错误）等

大小模型的协同

Claude Code 在底层会调用 Claude 模型。但有个细节你可能不知道：超过一半的调用，用的是 Claude 3.5 Haiku（小模型），而不是 Claude 4 Sonnet/Opus（大模型）。

哪些任务交给小模型？

• • 读取大文件并摘要
• • 解析网页内容
• • 总结 Git 历史
• • 格式转换、数据提取等结构化任务

哪些任务必须用大模型？

• • 理解复杂需求
• • 做架构决策
• • 生成核心代码
• • 调试疑难 bug

小模型的成本大约是大模型的 1/10 到 1/5。如果能把 50% 的调用下放给小模型，整体成本能降低 40-50%。

但这不只是省钱。

小模型响应更快。你让大模型总结一个万行文件，可能要等好几秒；小模型可能一两秒就搞定。在交互式编程场景，响应速度直接影响用户体验。

小模型更适合"确定性"任务。格式转换、信息提取这类任务，输入输出关系比较明确，小模型完全够用。把大模型浪费在这种任务上，是大材小用。

系统设计要有"分层"意识

很多 AI 应用的思路是"用最强的模型端到端搞定一切"。这在 Demo 阶段没问题，但做产品就会遇到成本和延迟的瓶颈。

Claude Code 的做法是：把任务分解成不同难度等级，用匹配的模型处理。

这其实和传统软件架构的思想一致：缓存处理简单请求、复杂请求才打到数据库；CDN 处理静态资源、动态请求才回源……

好的系统设计，不是让最强组件包打一切，而是让每个组件做它最擅长的事。

TodoList

LLM 有个特点：上下文越长，早期信息的记忆力就越弱。

在长时间的编程会话中，这会导致一个问题：模型忘了最初的目标，开始在细节里迷失。

你让它重构一个模块，它改着改着就跑偏了，花大量时间在某个边缘情况上死磕，忘了整体任务还有哪些部分没完成。

Claude Code的解决方法很朴素，让模型自己维护一个Todolist。

这个 TodoList 会持续出现在上下文里，起到"提醒"作用——不管对话进行到哪一步，模型都能看到"还有哪些事情没做完"。

很多 AI Agent 失败的根本原因，不是模型能力不够，而是在复杂任务中丢失了全局视角。

TodoList 机制相当于给模型装了一个"外部工作记忆"：

• • 任务分解的结果显式记录下来
• • 每完成一步，显式标记完成
• • 发现新问题，显式添加到待办

这让模型的行为更可预测、更可控。

尾声

模型能力是基础，但工程设计决定上限。

同样的基座模型，不同的架构设计、提示词工程、工具设计，能做出天差地别的产品效果。

Claude Code 用一套看起来很"土"、很"笨"的方法，做出了最好的效果。这本身就是最好的回答。