正文分为上下两部分，第一部分 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 许可协议。
