拆了 4756 个源码文件,我才明白为什么你的 AI Agent 总是不听话

有人花了很长时间，把 Claude Code 的源码翻了个底朝天。

4756 个文件。

翻完之后他说：这玩意儿的秘密，不在 prompt 里。

这句话我反复想了很久。因为我们大多数人搭 AI 系统的时候，几乎把全部赌注都压在 prompt 上。prompt 写得好，模型就乖；prompt 写得差，模型就乱跑。整个认知框架就这么简单。

但真的是这样吗？

先说一个你大概经历过的场景

你花了两小时写了一个很精心的 prompt，让模型帮你改代码。结果它改完之后，顺手又加了三个你完全没要求的功能，还删掉了一段注释，理由是”这段注释是多余的”。

你气得重新跑了一遍，这次加了一句”不要自作主张”。

它老实了一次。

下一次又犯。

你以为问题出在措辞上，开始反复打磨 prompt，”请严格按照要求””不要做任何额外修改””只改我指定的部分”……

有没有效果？有一点。根本解决了吗？没有。

因为你搞错了问题的根源。

关于 Vibe Coding：它解放了你，但也放大了你的盲区

在说 Claude Code 的设计原则之前，我想先聊一件事。

最近有个词很火，叫 Vibe Coding。意思是不用懂代码，全程靠感觉跟 AI 对话，描述你想要什么，AI 帮你写出来。很多人靠这个几天就搭起了一个能跑的产品。

这是真的。这也是好事。

但有一个问题没人说——Vibe Coding 降低了入门门槛，但没有降低系统腐烂的速度。

你用感觉驱动着 AI 把代码写出来了，但你不知道里面发生了什么。下次出了 bug，你继续用感觉让 AI 去修。AI 修完了，顺手又动了三个地方。你不知道它动了什么，也不知道会不会有后遗症，只知道眼前能跑了。

就这样迭代十几轮之后，这个系统变成了一个没有人真正理解的黑箱。

Vibe Coding 最大的风险不是写不出来，是写出来的东西你不敢改，也不知道哪里会坏。

那怎么办？答案不是”你必须学会看代码”——那等于把入门门槛重新堵死。

答案是：你要学会管理模型的行为，而不是只管理你自己的输入。

Claude Code 拆出来的这五条原则，恰好就是这件事的答案。

第一条：不要信任模型的自觉性

问题不是模型不够聪明，而是你把所有事情都押宝在了它的”自觉”上。

好行为要写成制度，不能依赖临场发挥。

你希望模型先读代码再改代码，不要靠提示，要把这条逻辑写进 prompt；你希望模型不乱加功能，不要靠祈祷，要写明白；你希望模型遇到风险操作停下来确认，光靠说不够，要在 runtime 层加权限检查。

把它类比成管人。

一个靠谱的团队，不是因为每个人天生自律、天生懂事，而是因为有 SOP，有流程，有 checklist。新人来了，不需要凭感觉猜什么该做什么不该做，照规矩来就行。

模型也一样。你希望它有什么行为，就把那个行为变成约束，而不是期望。

对 Vibe Coder 来说，这条原则的实操版本是：每次让 AI 干活之前，先花两分钟写清楚”不能动哪里””只改什么”。这不是多此一举，这是在帮你的系统建 SOP。

期望会落空，制度不会。

第二条：把角色拆开

至少把”做事的人”和”验收的人”分开。

你可能会说，我现在就一个模型，哪来的分工。

但这不是资源问题，是结构问题。

想想看，一个工程师自己写代码、自己做 Code Review，会发生什么？会发生他永远觉得自己写得没问题这件事。

不是他故意的，是人类（和模型）的天然倾向——实现者会对自己的实现产生依恋，会不自觉地美化自己的决策。

所以一个 Agent 又负责做事、又负责验收，它的验收几乎是形式大于实质的。

解法很简单，但很有效：哪怕是同一个模型，也要把”实现”和”验证”拆成两次独立的对话，第二次从零开始审，假装完全不知道第一次是怎么想的。

Vibe Coder 的版本：让 AI 写完代码之后，新开一个对话，把代码贴进去，说”帮我找这段代码的问题，不要放水”。两次对话，两个视角，找出来的问题比你想象的多得多。

第三条：工具调用要有治理

你给 Agent 接了一堆工具——能查数据库、能发邮件、能修改文件。模型说”调这个”，系统就调了。

但谁来验证模型的判断是对的？谁来检查传入的参数有没有问题？如果调用失败，接下来怎么处理？

都没有。这就是没有治理的工具调用。看起来系统很强大，实际上是在裸奔。

打个比方。你雇了一个助理，说”去帮我从财务部拿一份报告”。

没有治理的系统：助理直接冲进去，不管谁在开会，不管有没有权限，拿到就跑，拿不到也不说话。

有治理的系统：助理先确认你有没有权限要这份报告，进去之前敲门，拿到之后确认是不是正确版本，如果失败了回来告诉你原因。

两者的”能力”一样，但稳定性差了不是一个量级。

对 Vibe Coder 来说：让 AI 帮你实现任何”写入”操作（改文件、发请求、存数据库）之前，先让它告诉你它准备干什么，确认了再执行。这一步慢三秒，能救你很多次。

第四条：上下文是预算

这条对做产品的人来说，是真的要命的一条。

演示 demo 的时候，没人在乎 token 浪费。几百块成本，老板觉得这是”投资”。

真的跑产品了，每天几万次调用，每次多塞了一大堆没用的上下文，成本直接爆炸。

但问题不只是钱。

上下文有限，塞进去的信息越多，模型就越容易”走神”——关键信息被淹没，无关信息干扰判断。这就是为什么你有时候会发现，给模型的信息越多，它反而做得越差。

Claude Code 的策略是：能缓存的缓存，能按需加载的不要一开始就塞进去，能压缩的压缩。

Vibe Coder 的直觉版：每次开新对话，只贴跟这次任务有关的代码，不要把整个项目全扔进去。上下文是工作台，工作台堆满了不相关的东西，人也干不了活。

第五条：生态的关键是模型感知

你花了几个月，给系统接了十个插件：能搜索、能画图、能查日历、能发消息……功能很强大，演示起来很好看。

然后你发现模型就是不用这些工具，或者用错了，或者在该用工具的时候凭空编一个答案。

为什么？

因为模型不知道自己有什么武器。

你以为接了插件模型就知道了，但不是。你还需要在对的时机、以对的方式，让模型看到自己的能力清单，知道什么场景该用哪个工具。

扩展能力的最后一公里，不是接口，是感知。

Vibe Coder 实操：每次让 AI 帮你解决问题，先告诉它你有什么资源——”我有这个 API，有这个数据库，有这个文件”。别让它在不知道的情况下瞎猜，它会猜错，然后你会以为是它不够聪明。

回头看这五条

它们解决的不是”模型够不够强”的问题。

它们解决的是：怎么让一个不够可靠的模型，在一个不够完美的环境里，做出相对可靠的行为。

这个问题，比”模型够不够强”更有价值，也更有意思。

因为模型越来越强这件事，你控制不了。但你能控制的，是你搭的这套系统有多稳。

Claude Code 的源码拆完，没有发现什么魔法 prompt，没有发现什么秘密咒语。发现的是一套很朴素的工程理念：行为要制度化，角色要分离，工具要治理，上下文要管理，能力要可感知。

这五条，不只是 coding agent 的设计哲学。几乎任何需要 LLM 完成复杂任务的系统，都适用。

最后说一句实在的

Vibe Coding 让更多人有机会把想法变成产品，这是好事，不应该被鄙视。

但”感觉对了就行”只能带你到第一步。

从 Vibe Coder 升级的方式，不是去学编程，而是去学管理——管理模型的行为，管理系统的边界，管理你自己对”能跑”和”可靠”的判断。

你不需要把这五条全部做完才能开始改进。

找到你系统里最薄弱的那一环——是模型行为不可控？是工具调用总出问题？是上下文超限？是新接的功能模型完全不知道用？

从那一环开始补。

补一层，系统就稳一个台阶。稳一个台阶，你对它的信任就多一分。信任多一分，你才敢把更重要的事交给它做。

这是个正循环，而它的起点，就是你今天愿意停下来，想清楚这套系统到底哪里在漏水。

你现在用 AI 搭的系统或者工作流，最容易出问题的环节是哪里？评论区聊聊，说不定大家踩的是同一个坑。