正文分为上下两部分,第一部分 Claude Code 的设计哲学,第二部分为我的感悟发散
Claude Code,它为何这么狠?
摒弃多 Agent:用“全栈模型”干掉协作内耗
想象一下你是创业公司老板,有个紧急任务要完成。你有两个选择:
・选项 A:找一个能力很强的全栈员工,把任务交给他从头到尾搞定;
・选项 B:搭一个“完美团队”——产品经理、前端、后端、测试、运维齐上阵,让他们协作完成。
表面上看,B 似乎更“专业”、更“大厂范”😎,但当任务紧急、需求模糊时,A 的效率几乎碾压 B🚀。为什么?因为 B 有太多“中间环节”:
・产品经理要和前端对齐需求;
・前端得和后端商量接口;
・后端改了逻辑,得同步给测试;
・测试发现 bug,又要拉会对齐……
每个环节都有信息损耗,每次对齐都可能产生误解。更要命的是,出了问题你根本没法定位“是谁的锅”😫。
Claude Code 选的就是“选项 A”——一个强大的模型+一套趁手的工具,直接把活干完 💪。它把所有对话历史都维护在一个扁平的消息列表里:你让它改 bug,它读代码的过程、思考的逻辑、修改的动作、验证的结果……全按时间顺序整整齐齐排在列表里 📝。
模型每次回答,都能看到完整的上下文。这带来三个核心优势:
- 信息不丢失:不会有“代理 A 告诉代理 B 时漏了关键信息”的问题;
- 可追溯:出问题时,翻历史记录就能完全还原当时的情况 🔍;
- 可调试:开发者能直接看到模型“在想什么”,不用瞎猜 🤔。
当然,Claude Code 也不是完全没“分工”——遇到特别复杂的任务,它会派生子代理处理子任务,但子代理的结果会原样写回主消息列表,变成一条“工具响应”📩。这个设计的精髓在于:该简单的地方极致简单,该复杂的地方用工程手段兜底🔧。
不用 RAG:让 LLM 自己当“搜索引擎”
RAG 是目前主流的“让大模型获取外部知识”的方案,但 Claude Code 偏不用——为什么?
想想 RAG 要做对多少件事:
- 文档怎么切块?按段落?按 token 数?按语义?
- 用什么模型做向量化?
- 相似度阈值设多少?
- 返回多少条结果合适?
- 最相关的信息正好跨了两个切块怎么办?
每一个决策都可能出错,而且错了还很难查——你只会看到最终结果“不太对”,但根本不知道哪个环节出了问题 😫。
Claude Code 的做法很直接——让大模型用命令行工具搜代码库!它会用 ripgrep(高性能文本搜索)、find(找文件)、jq(解析 JSON)这些工具,像熟练程序员一样在代码库里翻找信息 💻。
这个设计的妙处在于:
- 搜索行为显式可观察:模型要查什么、查到了什么、为什么觉得这条有用,全记录在对话历史里——出问题时,你能完整复盘搜索过程 🔍;
- 搜索策略可学习:模型会根据结果调整策略——这次用关键词没搜到?试试正则!函数名太通用?加个路径过滤!就像人类程序员查代码:试方法 → 看结果 → 换思路,反复迭代直到找到想要的信息 🔄;
- 不用提前建索引:RAG 需要提前把代码库向量化、建索引,代码一改索引就可能过期;而 grep/find 是实时搜索,根本没有“索引没更新”的问题 ✅。
AI 系统设计的原则:能用显式、可观察的方式解决的问题,坚决不用隐式、黑盒的方式⚫️。RAG 的向量检索是“黑盒”——你不知道为什么这篇文档排前面、那篇排后面;而 LLM 用 grep 搜索是“白盒”——搜索命令就在那,结果就在那,因果关系一目了然 📊。
提示词工程:把规则“写进模型的脑子里”
传统软件开发中,我们习惯把规则写在代码里——这个按钮点了跳转到哪个页面、那个输入框怎么校验、异常情况怎么处理……全是代码逻辑。
但 LLM 应用不一样——你没法用代码“指挥”模型的每一步行为,模型是根据提示词理解任务、自主决策的 🤖。
Claude Code 的应对策略很实在——把大量逻辑、规则、案例全写进提示词里:
・系统提示词:约 2800 tokens;
・工具说明:约 9400 tokens;
・项目规则文件(claude.md):通常 1000-2000 tokens。
加起来,每次对话模型都要先“读”1 万多 token 的“说明书”,才会开始干活 📚。
翻开 Claude Code 的提示词,你会发现它特别“工程化”——像写代码一样严谨 🔧:
- 大量正例+反例:不是抽象说“要写好代码”,而是直接给例子:
<good-example>
// 好例子:变量名清晰易懂 const userLoginTime = new Date();
</good-example>
<bad-example>
// 坏例子:变量名模糊 const a = new Date();
</bad-example>
为什么这么具体?因为 LLM 从例子里学比从抽象规则里学更可靠——你说“变量名要有意义”,模型可能理解偏差;但给它看 10 个好例子+10 个坏例子,它立刻就能 get 你想要的风格 ✍️。
强调词的策略性使用:提示词里全是 IMPORTANT、NEVER、ALWAYS 这种“大写强调词”——不是作者爱大喊大叫,而是实践证明:对于关键行为边界,普通陈述句不够“重”,模型可能在边缘情况“翻车”;用强调词能大幅提高模型遵守规则的概率 ⚠️。
结构化标记:用
<good-example>、<bad-example>这种标签把内容结构化——好处是模型能更清晰理解不同部分的边界和层级,减少信息混淆 📑。
把“模糊地带”消灭在提示词里 ❌——很多 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 用一套看起来很“土”、很“笨”的方法,做出了最好的效果——这本身就是最好的回答 💯。
从 Claude Code 看世界
合上 Claude Code 的设计文档时,我突然想起年初做的那个 ToDo app——当时我总觉得“功能越多越好用”,加了番茄钟、habit tracker、日历视图,甚至还加了“好友比拼”,结果用户反馈“找不到北”,下载量惨不忍睹。直到后来砍到只剩“添加任务+标记完成+分类筛选”三个核心功能,才终于活了下来。
现在回头看,Claude Code 的设计哲学,本质上是用“简单的逻辑”解决“复杂的问题”——而这种逻辑,不仅适用于 AI 系统,更适用于产品设计、UI/UX,甚至我们的人生。
一、从“全栈模型”到产品设计:少即是“赢”
Claude Code 选“全栈模型”而不是“多 Agent 团队”,本质是聚焦核心能力——让模型端到端解决代码问题,而不是把问题拆给多个角色扯皮。这像极了产品设计里的“单点突破”:
微信早期只有“即时通讯”一个功能,没有朋友圈、没有支付,却干掉了飞信;Figma 早期只有“实时协作设计”,没有原型、没有评论,却颠覆了 Sketch;Notion 早期只有“模块化笔记”,没有数据库、没有看板,却成了生产力工具的天花板。
真正的好产品,从来不是“满足所有需求”,而是“把一个需求满足到让用户离不开”。就像 Claude Code 把“代码问题解决”做到极致,产品把“核心场景”做到极致,才能在竞争中活下来。
二、从“白盒工具”到 UI/UX:可见性=安全感
Claude Code 用 grep 而不是 RAG,核心是“让思考过程可见”——这和 UI/UX 里的“可见性原则”如出一辙:
去年做电商 app 结算页时,我一开始把优惠券、运费藏在“更多优惠”里,结果转化率比竞品低 30%。后来改成“全透明”:商品总价 → 优惠券抵扣 → 运费 → 实付,每一步都明确显示,转化率立刻涨回正常水平。用户说:“终于敢放心付钱了。”
人对“可预测的结果”有天然的安全感。RAG 是“黑盒”,用户不知道模型为什么选这段文档;而 grep 是“白盒”,搜索命令和结果都在眼前,用户能“看见”模型的思考过程。就像 iOS 控制中心滑动亮度条时,屏幕实时变暗——每一步操作都有反馈,用户才会安心。
三、从“提示词工程”到系统架构:显式规则=可预测性
Claude Code 的提示词写得像“工程说明书”,有正例反例、有强调词、有结构化标记——这对应系统架构里的“显式约束”:
前两年做项目时,团队没有明确的代码规范,结果代码风格乱得像“八国联军”:有人用单引号,有人用双引号;有人写注释比代码长,有人连函数名都叫“aaa”。后来我们制定了《代码规范手册》,明确“变量名用驼峰”“函数超过 10 行写注释”,甚至附了 10 个正例和 10 个反例,代码可读性提升了 80%。
隐式的规则会导致歧义,显式的规则才能统一行为。就像 Claude Code 用提示词约束模型的行为空间,系统架构用显式规则约束组件的交互,人生用“边界感”约束自己的行为——比如和朋友相处时,明确说“我不喜欢被催”,比“你看着办”更高效。
四、从“工具克制”到人生:少而精=不可替代
Claude Code 的工具很“克制”,没有几十个花里胡哨的功能,只有底层的 Bash、中层的 Grep、高层的 WebFetch——这让我想起学 React 的朋友小杨:
小杨刚入职时,什么都想学:HTML、CSS、JS、React、Vue、Node.js,甚至还学了 Python,结果面试时被问“React 的 fiber 架构”,他答不上来。后来他痛定思痛,只做 React,翻了三遍文档,写了 50 个 Demo,现在成了公司的 React 技术专家,薪资翻了三倍。
人的精力是有限的,把资源投入到核心能力上,才能产生最大的价值。就像 Claude Code 把每个工具用到极致,人生把“一件事”做到极致,才能成为“不可替代的人”。
五、从“大小模型协同”到待人处事:知人善用=效率
Claude Code 让小模型做“确定性任务”(比如摘要、格式转换),让大模型做“复杂任务”(比如架构决策、核心代码)——这对应待人处事里的“知人善用”:
去年做项目时,我让擅长细节的小周做测试,让擅长战略的小李做架构设计,让擅长沟通的小王做需求对齐,结果项目提前两周上线。而之前我总让“全能选手”做所有事,结果效率低得惊人。
每个人都有自己的优势,把合适的事交给合适的人,才能发挥最大的价值。就像小模型适合“确定性任务”,大模型适合“复杂任务”,职场里让擅长执行的人做落地,擅长思考的人做决策,才能事半功倍。
六、从“TodoList”到人生:全局视角=不迷路
Claude Code 用 TodoList 帮模型保持全局视角,避免在细节里“迷失”——这让我想起自己做项目时的经历:
上个月做一个电商系统,一开始我没列 TodoList,结果改着改着就跑偏了,花了三天时间死磕一个边缘情况的 bug,完全忘了“首页优化”这个核心任务。后来我每天早上列 TodoList,把“首页优化”放在最前面,才终于按时完成项目。
人生就像一场长跑,没有全局视角,很容易在细节里“迷路”。就像 Claude Code 的 TodoList 提醒模型“还有哪些事没做完”,人生的 TodoList 提醒我们“不要忘了最初的目标”。
结语:简单不是放弃,而是“把复杂留给自己”
现在回头看 Claude Code 的设计,才明白“简单”从来不是偷懒,而是把复杂的逻辑藏在背后,给用户呈现最核心的价值:
它的提示词写了 1 万多 token,把所有规则、正例、反例都写进去,只为让模型输出更稳定;它的工具克制,是因为把每个工具都打磨到极致;它的全栈模型,是因为把代码理解、bug 定位、修改验证都整合到一个流程里。
这像极了我学骑自行车的经历——小时候总想着“要保持平衡,要踩踏板,要握车把”,结果摔了好几次。爸爸说:“你别想那么多,盯着前方的路,往前骑就行。”后来我照做了,果然学会了。
所谓“简单”,就是“不被复杂的表象迷惑,专注于核心”。
Claude Code 用“简单的设计”解决了“复杂的代码问题”,我们用“简单的生存法则”解决“复杂的人生问题”:
- 产品设计:聚焦核心场景,少即是多;
- UI/UX:可见性原则,给用户安全感;
- 系统架构:显式规则,让行为可预测;
- 人生职场:专注核心能力,少而精;
- 待人处事:知人善用,发挥优势;
- 人生目标:保持全局视角,不迷路。
合上电脑时,窗外的天已经亮了。想起 Claude Code 帮我改 bug 的瞬间,突然觉得:所有的“复杂”,最终都要回归“简单”——这,就是 Claude Code 教给我的“人生课”。
愿我们都能在复杂的世界里,找到自己的“核心”,做“简单的事”,成“不简单的人”。
- 本文链接:https://fridolph.top/posts/2026-01-07__clude
- 版权声明:本博客所有文章除特别声明外,均默认采用 CC BY-NC-SA 许可协议。