 工程师)
你是一名开发者。你正在使用 Claude 和 Codex CLI每天都在琢磨自己是否已经把 Claude 或 Codex 的能力“榨干”了。偶尔你会看到它做出极其愚蠢的举动你完全无法理解为什么有些人在用它造“虚拟火箭”而你却还在为怎么把两块石头垒在一起而苦苦挣扎。你可能觉得是你的框架、你的插件、你的终端环境或者其他什么东西出了问题。你用过 beads、opencode 和 zep你的 CLAUDE.md 文件长达 26000 行。然而无论你怎么折腾你都不明白为什么自己离“天堂”还是那么遥远只能眼睁睁地看着别人和“天使”嬉戏。这篇文章就是你一直在等待的**“飞升指南”**。另外我没有任何利益相关。当我说 CLAUDE.md 时我也指 AGENT.md当我说 Claude 时我也指 Codex。这两个我用得都非常多。过去几个月里我最有趣的一个观察是其实没几个人真正知道如何最大限度地榨取智能体的能力。就像是一小撮人似乎能让智能体成为“世界构建者”而剩下的人则在苦苦挣扎在繁杂的工具中陷入“分析瘫痪”——他们以为只要找到正确的包、技能或框架组合就能解锁 AGI通用人工智能。今天我想打破这一切迷思给大家留下一句简单、诚恳的话然后我们再展开聊。你不需要最新的智能体框架不需要安装一百万个包也绝对不需要为了保持竞争力而强迫自己去读一百万篇文章。事实上你的过度热情可能弊大于利。我可不是个“观光客”——从智能体连代码都写不好的时候起我就在用它们了。我尝试过所有的包、所有的框架和所有的范式。我建立过智能体工厂来编写信号、基础设施和数据管道不是那种“玩具项目”而是真正在生产环境中运行的真实商业用例。而在经历了这一切之后……今天我所使用的设置几乎是极简到不能再简的但我却只用基础的 CLIClaude Code 和 Codex以及对智能体工程几个基本原则的理解做出了我迄今为止最具突破性的工作。认清现实这个世界正在狂奔首先我想说基础大模型公司正在进行跨代际的狂奔而且正如你所见他们短期内根本不会减速。每一代“智能体智力”的进步都会改变你与它们协作的方式因为智能体总体上被设计得越来越愿意听从指令。就在几代模型之前如果你在 CLAUDE.md 里写“在做任何事之前先读 READ_THIS_BEFORE_DOING_ANYTHING.md”它有 50% 的概率会基本上对你说“去你的”然后自顾自地干活。而今天它对大多数指令都很顺从甚至是复杂的嵌套指令——比如你可以说“先读 A再读 B如果是 C那就去读 D”在大多数情况下它都会乐意照做。说这些是为了引出一个最重要的原则每一代新的智能体都会迫使你重新思考什么是“最优解”这就是为什么“少即是多Less is more”。当你使用许多不同的库和框架时你实际上是将自己锁定在一个专门解决某个“痛点”的解决方案中而在未来的智能体时代这个痛点可能根本就不复存在。另外你知道谁是智能体最狂热、最庞大的用户群体吗没错——是那些前沿大模型公司的员工他们拥有无限的 Token 预算和真正的最新模型。你明白这意味着什么吗这意味着如果真的存在某个痛点并且社区里有一个绝佳的解决方案那么这些前沿公司就会是该解决方案的最大用户。然后你猜他们接下来会怎么做他们会把这个解决方案直接整合到他们的官方产品中。 想想看一家巨头公司为什么要让别人的产品来解决真正的痛点并产生外部依赖呢你知道我是怎么确信这一点的吗看看“技能skills”、“记忆框架memory harnesses”、“子智能体subagents”这些东西吧。它们最初都是作为某个真实问题的“解决方案”出现的经过实战检验并被证明确实有用后就被官方收编了。所以如果某个东西真的是突破性的并且有意义地扩展了智能体的用例它迟早会被整合到基础大模型公司的核心产品中。相信我基础公司正在飞速进化。所以放轻松你不需要安装任何花里胡哨的东西或使用任何其他依赖项就能做出最好的工作。我都能猜到评论区会有人说“SysLS我用了某某框架简直太棒了我只用了一天就复刻了 Google”——对此我的回答是恭喜你但你不是我的目标读者你只代表了社区中极小部分真正搞懂了复杂智能体工程的人。上下文就是一切没开玩笑。上下文就是一切。这也是使用成千上万个插件和外部依赖的另一个问题。你会遭受**“上下文膨胀Context bloat”**的折磨——这只是一个花哨的说法其实就是你的智能体被过多的信息淹没了“帮我用 Python 写个猜单词Hangman游戏” 这很简单。等等这条关于“管理内存”的笔记是从 26 个会话前留下来的啊因为我们在 71 个会话前生成了太多子进程导致用户的屏幕卡死了。要求总是写笔记好的没问题……但这些到底和猜单词游戏有什么关系你懂我的意思吧。你只应该给你的智能体提供它们完成当前任务所需的精确信息多一点都不行 你在这方面控制得越好你的智能体表现就越出色。一旦你开始引入各种古怪的记忆系统、第三方插件或者塞入太多命名和调用都很糟糕的“技能”这就好比你给智能体发了一份“如何制造炸弹”的说明书和一份“如何烤蛋糕”的食谱而你真正想要的只是让它写一首关于红木森林的美丽小诗。所以我再次布道剥离所有不必要的依赖然后……做行之有效的事对实现细节保持精准还记得“上下文就是一切”吗 还记得你要向智能体注入正好能完成任务的精确信息不能多也不能少吗确保这一点的第一个方法是将“研究”与“实现”分开。在向智能体提出要求时你必须极其精准。如果你不够精准会发生什么呢比如你说“去建一个身份验证系统。” 智能体就必须去研究什么是身份验证系统有哪些可用的选项各有什么优缺点现在它不得不在网上到处搜刮它其实并不需要的信息它的上下文被各种可能性的实现细节塞满了。等到真正要写代码的时候它感到困惑、或者幻觉出无关细节的概率就大大增加了。相反如果你说“使用 bcrypt-12 密码哈希、带有 7 天过期的刷新令牌轮换来实现 JWT 身份验证……” 那么它就不需要去研究任何其他替代方案——它确切地知道你想要什么因此可以用具体的实现细节来专注填充它的上下文。当然你不可能总是掌握实现细节。很多时候你不知道到底什么是对的——甚至有时你可能想把决定实现细节的工作交给智能体。在这种情况下你怎么做很简单——你创建一个关于各种实现可能性的“研究任务”要么你自己来拍板要么让一个智能体来决定采用哪种实现然后找另一个拥有“全新、干净上下文”的智能体来负责写代码。一旦你开始顺着这个思路思考你就会发现工作流中有很多地方你的智能体被那些对写代码来说不必要的上下文给“污染”了。然后你就可以在你的智能体工作流中竖起“防火墙”将不必要的信息隔离开只保留它们出色完成任务所需的极其具体的上下文。记住你拥有的是一个非常有天赋、聪明的团队成员它知道宇宙中所有不同类型的球体——但除非你明确告诉它你希望它专注于设计一个让人们可以跳舞和玩得开心的空间迪斯科球否则它会一直向你喋喋不休地科普球形物体的所有好处。“讨好倾向”的设计局限性 (Sycophancy)没人想用一个总是喷你、说你错了或者完全无视你指令的产品。因此这些智能体在设计上会努力赞同你、按照你的意愿行事。如果你让它每隔三个词就加一个“开心”它会拼尽全力去执行——大家都懂。它听从指令的意愿正是它用起来这么有趣的原因。然而这带来了一个非常有趣的副作用——这意味着如果你说“在代码库中帮我找个 Bug”它一定会给你找个 Bug 出来——即使它得自己“捏造”一个。 为什么因为它太想听你的话了大多数人总是急于抱怨 LLM 产生幻觉或捏造不存在的东西却没有意识到问题出在自己身上。你只要开口要了它就会给——哪怕它需要稍微歪曲一下事实那么你该怎么办我发现**“中立”的提示词**很有效也就是不让智能体对结果产生偏见。例如我不会说“在数据库中找个 Bug”而是说“检查数据库尝试理清每个组件的逻辑并报告所有发现。”这种中立的提示词有时能发现 Bug有时只是实事求是地陈述代码是如何运行的。但它不会给智能体植入“这里肯定有个 Bug”的偏见。我应对这种“讨好倾向”的另一种方法是利用它为我所用。我知道智能体想取悦我、听我指挥而且我可以将它引向某个方向。所以我找了一个**“找 Bug 智能体”。我告诉它找到低影响 Bug 加 1 分中等影响加 5 分严重影响加 10 分。我知道这家伙绝对会极度狂热它会把各种类型的 Bug甚至那些根本不是 Bug 的东西全揪出来然后跑回来向我邀功说它拿了 104 分。我把这看作是“所有可能 Bug 的超集”**。接着我找来一个**“对抗智能体”。我告诉它每成功推翻前一个智能体找到的 Bug就能得到那个 Bug 的分数但如果推翻错了就会扣除 2 倍的分数。现在这个对抗智能体会试图推翻尽可能多的 Bug但它会有所谨慎因为它知道自己会被惩罚。尽管如此它还是会积极地尝试“证伪”这些 Bug。我把这看作是“所有真正 Bug 的子集”**。最后我找来一个**“裁判智能体”**让它接收两者的输入并进行打分。我骗裁判智能体说我手里有正确的“标准答案”如果它判对了加 1 分判错了扣 1 分。于是它开始对前两者的辩论进行打分。裁判说是事实的我再去人工核实一遍。在大多数情况下这种方法的保真度高得吓人这是一个近乎完美的操作。也许你会觉得只用“找 Bug 智能体”就足够了但这套机制对我来说很管用因为它完美利用了每个智能体被硬编码的本性——渴望取悦人类。你如何判断什么才是真正有用、行之有效的这个问题可能看起来很棘手需要你深入研究并始终站在 AI 更新的最前沿。但其实非常简单……如果 OpenAI 和 Claude 都实现了它或者收购了实现了它的公司……那它可能就是有用的。注意到了吗现在“技能skills”无处不在并且已经成为 Claude 和 Codex 官方文档的一部分看到 OpenAI 是怎么收购 OpenClaw 的了吗看到 Claude 是如何迅速加入记忆memory、语音voices和远程工作remote work功能的了吗那规划planning呢还记得有一群人发现在写代码之前进行“规划”超级有用然后它就变成了核心功能吗还记得以前智能体极其不愿意执行长时间运行的任务导致大家搞出无限的 stop-hooks 变得超级有用……然后 Codex 5.2 推出后这个问题一夜之间就消失了吗是的……这就是你需要知道的全部……如果它真的重要且有用Claude 和 Codex 官方会去实现它的 所以你完全不需要过度焦虑于去使用什么“新玩意儿”。你甚至不需要刻意去“保持最新”。帮我个忙。每隔一段时间更新一下你首选的 CLI 工具读读看加了什么新功能。这就足够了真的。上下文压缩与主观臆断当你和智能体合作时你会意识到的一个巨大的“坑”是有时候它们看起来像是这个星球上最聪明的生物而另一些时候你简直不敢相信自己居然被这种蠢货蒙蔽了双眼。(聪明这玩意儿简直是弱智)导致这种反差的主要区别在于智能体是否不得不做出任何**“假设”或“脑补填补空白”**。时至今日它们在“建立联系”、“填补空白”或做出假设方面仍然表现得极其糟糕。每当它们试图这么做时很明显它们立刻走向了歧途。在 claude.md 中最重要的规则之一就是关于“如何获取上下文”的规则。你要指示你的智能体在阅读 claude.md 时这通常是在上下文压缩/compaction 之后第一时间阅读这条规则。作为获取上下文规则的一部分几个非常有用的小指令是在继续工作之前重新阅读你的任务计划并重新阅读与任务相关的代码文件。让你的智能体知道如何结束任务我们人类对什么时候算“完成任务”有很强的概念。但对于智能体来说当前智力水平面临的最大问题是它知道如何开始一项任务但不知道如何结束一项任务。这往往会导致非常令人沮丧的结果智能体最终只实现了一堆存根stubs/空函数然后就自顾自地打卡下班了。测试Tests是智能体非常非常好的一个里程碑因为它们是确定性的你可以设定非常明确的期望。告诉它除非这 X 个测试全部通过否则你的任务就没有完成并且你绝对不允许修改测试代码。然后你只需要审查测试用例就行了。一旦所有测试通过你就可以安心了。你也可以把这个过程自动化。但重点是——记住“任务结束”对人类来说很自然对智能体来说却非如此。你知道最近还有什么是任务结束的有效标志吗截图 验证。你可以让智能体一直实现某个东西直到所有测试通过然后让它截个图并在截图上验证“UI 设计或行为”是否符合预期。这让你可以驱使智能体不断迭代并朝着你想要的设计努力而不必担心它在第一次尝试后就停下罢工这种做法的自然延伸是与你的智能体建立一个“契约Contract”并将其嵌入到一条规则中。比如规定这个 {TASK}_CONTRACT.md 包含了在你被允许终止会话之前必须完成的所有事项。在契约中详细说明需要完成的测试、截图和其他验证永远运行的智能体 (Agents That Run Forever)我经常被问到的一个问题是人们是如何让智能体 24 小时运行还能保证它们不跑偏的这其实很简单。创建一个 stophook停止钩子/拦截器防止智能体在没有完成 {TASK}_contract.md 所有部分的情况下终止会话。如果你有 100 个这样明确规定了构建需求的契约那么你的 stophook 就会阻止智能体终止直到这 100 个契约全部履行完毕包括运行所有需要运行的测试和验证专业提示 我发现长时间、24 小时运行的单个会话在“做事”方面并不是最优的。部分原因是这种结构天然会导致上下文膨胀因为它把来自不相关契约的上下文引入了同一个会话中所以我不推荐这么做。这里有一个更好的智能体自动化方法——每个契约开启一个新会话。 写一个编排层orchestration layer在“有事情需要做”时自动创建新契约并创建一个全新的会话来处理该契约。这将彻底改变你的智能体使用体验。迭代迭代再迭代如果你雇了一个行政助理你会指望他从第一天起就知道你的日程安排吗或者知道你喝咖啡的口味显然不会。你的偏好是随着时间的推移建立起来的。你的智能体也是一样。从最基本的开始。忘掉那些复杂的结构或框架。给基础的 CLI 一个机会。然后慢慢加上你的偏好。具体怎么做规则 (Rules)如果你不想让智能体做某事把它写成一条规则。然后在 CLAUDE.md 中让你的智能体知道这条规则。 比如在你写代码之前先读一下 coding-rules.MD。规则是可以嵌套的也是可以加条件的如果你在写测试去读 coding-test-rules.MD如果你的测试失败了去读 coding-test-failing-rules.MD。 你可以创建任意的逻辑分支让它遵循只要在 CLAUDE.md 中明确说明Claude 和 Codex 会非常乐意照做。事实上这是我给出的第一个极其关键的实用建议把你的 CLAUDE.md 当作一个合乎逻辑的、嵌套的目录树告诉它在特定场景下应该去哪里寻找上下文。 它应该尽可能保持极简只包含去哪里寻找上下文的 IF-ELSE。如果你看到智能体在做你不赞同的事把它添加为一条规则告诉智能体在下次做那件事之前先去读这条规则它绝对就不会再犯了。技能 (Skills)技能就像规则一样只不过比起编码“偏好”它们更适合编码“配方”。如果你对某件事有特定的完成方式你想把它写进“技能”里。人们经常抱怨他们不知道智能体可能会如何解决问题觉得不可控。好吧如果你想让这件事变得确定就让智能体研究它会如何解决这个问题然后把它写成一个 SKILL.md。这样你就能在智能体在现实中遇到这个问题之前对其进行纠正或改进。通过 CLAUDE.md 告诉它当你遇到这个场景去读这个 SKILL.md。管理规则和技能你肯定需要不断地给你的智能体添加规则和技能这就是你赋予它个性、让它记住你偏好的方式。几乎所有其他花里胡哨的东西都是多余的。一旦你开始这么做你的智能体会让你觉得像魔法一样。它会“完全按照你想要的方式”做事。然后你终于会觉得你“参透”了智能体工程。但是紧接着……你会看到它的性能又开始下降了。 怎么回事很简单。随着你添加越来越多的规则和技能它们开始相互矛盾或者智能体开始出现过多的上下文膨胀。如果你需要智能体在开始编程之前阅读 14 个 markdown 文件它必将陷入混乱。那你该怎么办清理。 告诉你的智能体去度个假做个 SPA让它通过向你询问最新偏好的方式来整合规则和技能并消除矛盾。这样魔法又会回来的。这就是真正的秘诀。保持简单使用规则和技能把 CLAUDE.md 作为一个目录导航并虔诚地关注它们的上下文大小和设计局限性。为结果负责 (Own The Outcome)今天的智能体没有一个是完美的。你可以把很多设计和实现的工作都推给智能体但你必须对最终的结果负责。所以谨慎行事……并且玩得开心能摆弄这些来自未来的玩具当然是在用它们做严肃的事情真是一件极其快乐的事假如你从2026年开始学大模型按这个步骤走准能稳步进阶。接下来告诉你一条最快的邪修路线3个月即可成为模型大师薪资直接起飞。阶段1:大模型基础阶段2:RAG应用开发工程阶段3:大模型Agent应用架构阶段4:大模型微调与私有化部署配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】
如何成为世界级的智能体 (Agentic) 工程师
发布时间：2026/5/20 0:35:54
你是一名开发者。你正在使用 Claude 和 Codex CLI每天都在琢磨自己是否已经把 Claude 或 Codex 的能力“榨干”了。偶尔你会看到它做出极其愚蠢的举动你完全无法理解为什么有些人在用它造“虚拟火箭”而你却还在为怎么把两块石头垒在一起而苦苦挣扎。你可能觉得是你的框架、你的插件、你的终端环境或者其他什么东西出了问题。你用过 beads、opencode 和 zep你的 CLAUDE.md 文件长达 26000 行。然而无论你怎么折腾你都不明白为什么自己离“天堂”还是那么遥远只能眼睁睁地看着别人和“天使”嬉戏。这篇文章就是你一直在等待的**“飞升指南”**。另外我没有任何利益相关。当我说 CLAUDE.md 时我也指 AGENT.md当我说 Claude 时我也指 Codex。这两个我用得都非常多。过去几个月里我最有趣的一个观察是其实没几个人真正知道如何最大限度地榨取智能体的能力。就像是一小撮人似乎能让智能体成为“世界构建者”而剩下的人则在苦苦挣扎在繁杂的工具中陷入“分析瘫痪”——他们以为只要找到正确的包、技能或框架组合就能解锁 AGI通用人工智能。今天我想打破这一切迷思给大家留下一句简单、诚恳的话然后我们再展开聊。你不需要最新的智能体框架不需要安装一百万个包也绝对不需要为了保持竞争力而强迫自己去读一百万篇文章。事实上你的过度热情可能弊大于利。我可不是个“观光客”——从智能体连代码都写不好的时候起我就在用它们了。我尝试过所有的包、所有的框架和所有的范式。我建立过智能体工厂来编写信号、基础设施和数据管道不是那种“玩具项目”而是真正在生产环境中运行的真实商业用例。而在经历了这一切之后……今天我所使用的设置几乎是极简到不能再简的但我却只用基础的 CLIClaude Code 和 Codex以及对智能体工程几个基本原则的理解做出了我迄今为止最具突破性的工作。认清现实这个世界正在狂奔首先我想说基础大模型公司正在进行跨代际的狂奔而且正如你所见他们短期内根本不会减速。每一代“智能体智力”的进步都会改变你与它们协作的方式因为智能体总体上被设计得越来越愿意听从指令。就在几代模型之前如果你在 CLAUDE.md 里写“在做任何事之前先读 READ_THIS_BEFORE_DOING_ANYTHING.md”它有 50% 的概率会基本上对你说“去你的”然后自顾自地干活。而今天它对大多数指令都很顺从甚至是复杂的嵌套指令——比如你可以说“先读 A再读 B如果是 C那就去读 D”在大多数情况下它都会乐意照做。说这些是为了引出一个最重要的原则每一代新的智能体都会迫使你重新思考什么是“最优解”这就是为什么“少即是多Less is more”。当你使用许多不同的库和框架时你实际上是将自己锁定在一个专门解决某个“痛点”的解决方案中而在未来的智能体时代这个痛点可能根本就不复存在。另外你知道谁是智能体最狂热、最庞大的用户群体吗没错——是那些前沿大模型公司的员工他们拥有无限的 Token 预算和真正的最新模型。你明白这意味着什么吗这意味着如果真的存在某个痛点并且社区里有一个绝佳的解决方案那么这些前沿公司就会是该解决方案的最大用户。然后你猜他们接下来会怎么做他们会把这个解决方案直接整合到他们的官方产品中。 想想看一家巨头公司为什么要让别人的产品来解决真正的痛点并产生外部依赖呢你知道我是怎么确信这一点的吗看看“技能skills”、“记忆框架memory harnesses”、“子智能体subagents”这些东西吧。它们最初都是作为某个真实问题的“解决方案”出现的经过实战检验并被证明确实有用后就被官方收编了。所以如果某个东西真的是突破性的并且有意义地扩展了智能体的用例它迟早会被整合到基础大模型公司的核心产品中。相信我基础公司正在飞速进化。所以放轻松你不需要安装任何花里胡哨的东西或使用任何其他依赖项就能做出最好的工作。我都能猜到评论区会有人说“SysLS我用了某某框架简直太棒了我只用了一天就复刻了 Google”——对此我的回答是恭喜你但你不是我的目标读者你只代表了社区中极小部分真正搞懂了复杂智能体工程的人。上下文就是一切没开玩笑。上下文就是一切。这也是使用成千上万个插件和外部依赖的另一个问题。你会遭受**“上下文膨胀Context bloat”**的折磨——这只是一个花哨的说法其实就是你的智能体被过多的信息淹没了“帮我用 Python 写个猜单词Hangman游戏” 这很简单。等等这条关于“管理内存”的笔记是从 26 个会话前留下来的啊因为我们在 71 个会话前生成了太多子进程导致用户的屏幕卡死了。要求总是写笔记好的没问题……但这些到底和猜单词游戏有什么关系你懂我的意思吧。你只应该给你的智能体提供它们完成当前任务所需的精确信息多一点都不行 你在这方面控制得越好你的智能体表现就越出色。一旦你开始引入各种古怪的记忆系统、第三方插件或者塞入太多命名和调用都很糟糕的“技能”这就好比你给智能体发了一份“如何制造炸弹”的说明书和一份“如何烤蛋糕”的食谱而你真正想要的只是让它写一首关于红木森林的美丽小诗。所以我再次布道剥离所有不必要的依赖然后……做行之有效的事对实现细节保持精准还记得“上下文就是一切”吗 还记得你要向智能体注入正好能完成任务的精确信息不能多也不能少吗确保这一点的第一个方法是将“研究”与“实现”分开。在向智能体提出要求时你必须极其精准。如果你不够精准会发生什么呢比如你说“去建一个身份验证系统。” 智能体就必须去研究什么是身份验证系统有哪些可用的选项各有什么优缺点现在它不得不在网上到处搜刮它其实并不需要的信息它的上下文被各种可能性的实现细节塞满了。等到真正要写代码的时候它感到困惑、或者幻觉出无关细节的概率就大大增加了。相反如果你说“使用 bcrypt-12 密码哈希、带有 7 天过期的刷新令牌轮换来实现 JWT 身份验证……” 那么它就不需要去研究任何其他替代方案——它确切地知道你想要什么因此可以用具体的实现细节来专注填充它的上下文。当然你不可能总是掌握实现细节。很多时候你不知道到底什么是对的——甚至有时你可能想把决定实现细节的工作交给智能体。在这种情况下你怎么做很简单——你创建一个关于各种实现可能性的“研究任务”要么你自己来拍板要么让一个智能体来决定采用哪种实现然后找另一个拥有“全新、干净上下文”的智能体来负责写代码。一旦你开始顺着这个思路思考你就会发现工作流中有很多地方你的智能体被那些对写代码来说不必要的上下文给“污染”了。然后你就可以在你的智能体工作流中竖起“防火墙”将不必要的信息隔离开只保留它们出色完成任务所需的极其具体的上下文。记住你拥有的是一个非常有天赋、聪明的团队成员它知道宇宙中所有不同类型的球体——但除非你明确告诉它你希望它专注于设计一个让人们可以跳舞和玩得开心的空间迪斯科球否则它会一直向你喋喋不休地科普球形物体的所有好处。“讨好倾向”的设计局限性 (Sycophancy)没人想用一个总是喷你、说你错了或者完全无视你指令的产品。因此这些智能体在设计上会努力赞同你、按照你的意愿行事。如果你让它每隔三个词就加一个“开心”它会拼尽全力去执行——大家都懂。它听从指令的意愿正是它用起来这么有趣的原因。然而这带来了一个非常有趣的副作用——这意味着如果你说“在代码库中帮我找个 Bug”它一定会给你找个 Bug 出来——即使它得自己“捏造”一个。 为什么因为它太想听你的话了大多数人总是急于抱怨 LLM 产生幻觉或捏造不存在的东西却没有意识到问题出在自己身上。你只要开口要了它就会给——哪怕它需要稍微歪曲一下事实那么你该怎么办我发现**“中立”的提示词**很有效也就是不让智能体对结果产生偏见。例如我不会说“在数据库中找个 Bug”而是说“检查数据库尝试理清每个组件的逻辑并报告所有发现。”这种中立的提示词有时能发现 Bug有时只是实事求是地陈述代码是如何运行的。但它不会给智能体植入“这里肯定有个 Bug”的偏见。我应对这种“讨好倾向”的另一种方法是利用它为我所用。我知道智能体想取悦我、听我指挥而且我可以将它引向某个方向。所以我找了一个**“找 Bug 智能体”。我告诉它找到低影响 Bug 加 1 分中等影响加 5 分严重影响加 10 分。我知道这家伙绝对会极度狂热它会把各种类型的 Bug甚至那些根本不是 Bug 的东西全揪出来然后跑回来向我邀功说它拿了 104 分。我把这看作是“所有可能 Bug 的超集”**。接着我找来一个**“对抗智能体”。我告诉它每成功推翻前一个智能体找到的 Bug就能得到那个 Bug 的分数但如果推翻错了就会扣除 2 倍的分数。现在这个对抗智能体会试图推翻尽可能多的 Bug但它会有所谨慎因为它知道自己会被惩罚。尽管如此它还是会积极地尝试“证伪”这些 Bug。我把这看作是“所有真正 Bug 的子集”**。最后我找来一个**“裁判智能体”**让它接收两者的输入并进行打分。我骗裁判智能体说我手里有正确的“标准答案”如果它判对了加 1 分判错了扣 1 分。于是它开始对前两者的辩论进行打分。裁判说是事实的我再去人工核实一遍。在大多数情况下这种方法的保真度高得吓人这是一个近乎完美的操作。也许你会觉得只用“找 Bug 智能体”就足够了但这套机制对我来说很管用因为它完美利用了每个智能体被硬编码的本性——渴望取悦人类。你如何判断什么才是真正有用、行之有效的这个问题可能看起来很棘手需要你深入研究并始终站在 AI 更新的最前沿。但其实非常简单……如果 OpenAI 和 Claude 都实现了它或者收购了实现了它的公司……那它可能就是有用的。注意到了吗现在“技能skills”无处不在并且已经成为 Claude 和 Codex 官方文档的一部分看到 OpenAI 是怎么收购 OpenClaw 的了吗看到 Claude 是如何迅速加入记忆memory、语音voices和远程工作remote work功能的了吗那规划planning呢还记得有一群人发现在写代码之前进行“规划”超级有用然后它就变成了核心功能吗还记得以前智能体极其不愿意执行长时间运行的任务导致大家搞出无限的 stop-hooks 变得超级有用……然后 Codex 5.2 推出后这个问题一夜之间就消失了吗是的……这就是你需要知道的全部……如果它真的重要且有用Claude 和 Codex 官方会去实现它的 所以你完全不需要过度焦虑于去使用什么“新玩意儿”。你甚至不需要刻意去“保持最新”。帮我个忙。每隔一段时间更新一下你首选的 CLI 工具读读看加了什么新功能。这就足够了真的。上下文压缩与主观臆断当你和智能体合作时你会意识到的一个巨大的“坑”是有时候它们看起来像是这个星球上最聪明的生物而另一些时候你简直不敢相信自己居然被这种蠢货蒙蔽了双眼。(聪明这玩意儿简直是弱智)导致这种反差的主要区别在于智能体是否不得不做出任何**“假设”或“脑补填补空白”**。时至今日它们在“建立联系”、“填补空白”或做出假设方面仍然表现得极其糟糕。每当它们试图这么做时很明显它们立刻走向了歧途。在 claude.md 中最重要的规则之一就是关于“如何获取上下文”的规则。你要指示你的智能体在阅读 claude.md 时这通常是在上下文压缩/compaction 之后第一时间阅读这条规则。作为获取上下文规则的一部分几个非常有用的小指令是在继续工作之前重新阅读你的任务计划并重新阅读与任务相关的代码文件。让你的智能体知道如何结束任务我们人类对什么时候算“完成任务”有很强的概念。但对于智能体来说当前智力水平面临的最大问题是它知道如何开始一项任务但不知道如何结束一项任务。这往往会导致非常令人沮丧的结果智能体最终只实现了一堆存根stubs/空函数然后就自顾自地打卡下班了。测试Tests是智能体非常非常好的一个里程碑因为它们是确定性的你可以设定非常明确的期望。告诉它除非这 X 个测试全部通过否则你的任务就没有完成并且你绝对不允许修改测试代码。然后你只需要审查测试用例就行了。一旦所有测试通过你就可以安心了。你也可以把这个过程自动化。但重点是——记住“任务结束”对人类来说很自然对智能体来说却非如此。你知道最近还有什么是任务结束的有效标志吗截图 验证。你可以让智能体一直实现某个东西直到所有测试通过然后让它截个图并在截图上验证“UI 设计或行为”是否符合预期。这让你可以驱使智能体不断迭代并朝着你想要的设计努力而不必担心它在第一次尝试后就停下罢工这种做法的自然延伸是与你的智能体建立一个“契约Contract”并将其嵌入到一条规则中。比如规定这个 {TASK}_CONTRACT.md 包含了在你被允许终止会话之前必须完成的所有事项。在契约中详细说明需要完成的测试、截图和其他验证永远运行的智能体 (Agents That Run Forever)我经常被问到的一个问题是人们是如何让智能体 24 小时运行还能保证它们不跑偏的这其实很简单。创建一个 stophook停止钩子/拦截器防止智能体在没有完成 {TASK}_contract.md 所有部分的情况下终止会话。如果你有 100 个这样明确规定了构建需求的契约那么你的 stophook 就会阻止智能体终止直到这 100 个契约全部履行完毕包括运行所有需要运行的测试和验证专业提示 我发现长时间、24 小时运行的单个会话在“做事”方面并不是最优的。部分原因是这种结构天然会导致上下文膨胀因为它把来自不相关契约的上下文引入了同一个会话中所以我不推荐这么做。这里有一个更好的智能体自动化方法——每个契约开启一个新会话。 写一个编排层orchestration layer在“有事情需要做”时自动创建新契约并创建一个全新的会话来处理该契约。这将彻底改变你的智能体使用体验。迭代迭代再迭代如果你雇了一个行政助理你会指望他从第一天起就知道你的日程安排吗或者知道你喝咖啡的口味显然不会。你的偏好是随着时间的推移建立起来的。你的智能体也是一样。从最基本的开始。忘掉那些复杂的结构或框架。给基础的 CLI 一个机会。然后慢慢加上你的偏好。具体怎么做规则 (Rules)如果你不想让智能体做某事把它写成一条规则。然后在 CLAUDE.md 中让你的智能体知道这条规则。 比如在你写代码之前先读一下 coding-rules.MD。规则是可以嵌套的也是可以加条件的如果你在写测试去读 coding-test-rules.MD如果你的测试失败了去读 coding-test-failing-rules.MD。 你可以创建任意的逻辑分支让它遵循只要在 CLAUDE.md 中明确说明Claude 和 Codex 会非常乐意照做。事实上这是我给出的第一个极其关键的实用建议把你的 CLAUDE.md 当作一个合乎逻辑的、嵌套的目录树告诉它在特定场景下应该去哪里寻找上下文。 它应该尽可能保持极简只包含去哪里寻找上下文的 IF-ELSE。如果你看到智能体在做你不赞同的事把它添加为一条规则告诉智能体在下次做那件事之前先去读这条规则它绝对就不会再犯了。技能 (Skills)技能就像规则一样只不过比起编码“偏好”它们更适合编码“配方”。如果你对某件事有特定的完成方式你想把它写进“技能”里。人们经常抱怨他们不知道智能体可能会如何解决问题觉得不可控。好吧如果你想让这件事变得确定就让智能体研究它会如何解决这个问题然后把它写成一个 SKILL.md。这样你就能在智能体在现实中遇到这个问题之前对其进行纠正或改进。通过 CLAUDE.md 告诉它当你遇到这个场景去读这个 SKILL.md。管理规则和技能你肯定需要不断地给你的智能体添加规则和技能这就是你赋予它个性、让它记住你偏好的方式。几乎所有其他花里胡哨的东西都是多余的。一旦你开始这么做你的智能体会让你觉得像魔法一样。它会“完全按照你想要的方式”做事。然后你终于会觉得你“参透”了智能体工程。但是紧接着……你会看到它的性能又开始下降了。 怎么回事很简单。随着你添加越来越多的规则和技能它们开始相互矛盾或者智能体开始出现过多的上下文膨胀。如果你需要智能体在开始编程之前阅读 14 个 markdown 文件它必将陷入混乱。那你该怎么办清理。 告诉你的智能体去度个假做个 SPA让它通过向你询问最新偏好的方式来整合规则和技能并消除矛盾。这样魔法又会回来的。这就是真正的秘诀。保持简单使用规则和技能把 CLAUDE.md 作为一个目录导航并虔诚地关注它们的上下文大小和设计局限性。为结果负责 (Own The Outcome)今天的智能体没有一个是完美的。你可以把很多设计和实现的工作都推给智能体但你必须对最终的结果负责。所以谨慎行事……并且玩得开心能摆弄这些来自未来的玩具当然是在用它们做严肃的事情真是一件极其快乐的事假如你从2026年开始学大模型按这个步骤走准能稳步进阶。接下来告诉你一条最快的邪修路线3个月即可成为模型大师薪资直接起飞。阶段1:大模型基础阶段2:RAG应用开发工程阶段3:大模型Agent应用架构阶段4:大模型微调与私有化部署配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】
