为什么对 AI Agent 管得太细，反而会让它们变笨？

今天，随便打开一个现代 GitHub 仓库里的 system_prompt.txt，你会看到什么？通常是一面密密麻麻、充满焦虑的规则墙：“绝对不要做 X。你必须严格输出三个要点。永远不要使用这个库。”

开发者们正把人类历史上最先进的推理引擎，当成脆弱的正则表达式脚本来对待。

从历史角度来看，这种偏执完全说得通。就在一两年前，早期的 LLM 还需要保姆级的指导才能勉强不跑题。但时代变了。现代模型已经聪明得令人难以置信，然而我们写提示词的方式，却还像是在给 20 世纪 80 年代的微波炉编程。我们正试图把智能“硬编码”进去。

最近 Vercel 发生了一件很有意思的事，刚好证明了这一点。他们的工程团队发布了一篇复盘文章，详细拆解了他们是如何改进 v0 产品的，其中提到了一步反直觉的操作：他们删除了 Agent 80% 的工具。

结果呢？系统并没有崩溃。实际上它变得更好了。通过剥离那些过度预设的工具和死板的护栏，他们减少了模型的困惑，让它能够做自己最擅长的事——通过逻辑推理解决问题。摩擦越少，生成的代码质量反而越高。

对于现在任何正在用 AI 构建产品的人来说，这里有一个深刻的教训：给原则，而不是定死规矩。

当你一步步死板地告诉 LLM 该怎么做时，你其实是在强迫它把有限的注意力（算力）消耗在“循规蹈矩”上，而不是“提升质量”上。你剥夺了它利用海量训练数据去寻找更优雅解决方案的能力——而这往往比你硬编码的方案要好得多。

为了看清这种区别，我们来看看大多数开发者是如何写 Agent 提示词的，以及他们应该怎么写。

糟糕的做法（死板的规则）：

“写一个 Python 函数来获取用户数据。你必须使用 requests 库。你必须用 try/except 块来处理错误。你必须返回一个字典，且只能包含 'name'、'email' 和 'status' 这三个键。不要使用 async。给每一行都加上注释。”

优秀的做法（原则与目标）：

“写一个健壮的 Python 函数来获取用户数据。尽量使用现代的标准库。代码应该是生产级别的，这意味着它能优雅地处理网络故障和边缘情况。优先保证可读性和清晰的架构，不要过度炫技。下游系统期望接收标准的用户画像（name、email、status）。”

注意到这种转变了吗？第一个例子把 AI 当成了一个不值得信任的初级开发者（Junior）。第二个例子则把它当成了一个理解目标和上下文的高级工程师（Senior）。你告诉它好的输出是什么样的以及为什么，然后你退后一步，让它自己去解决怎么做的问题。

当然，这个规则有一个重要的例外。

当 Agent 与其他 Agent 对话时——或者当上游 Agent 将数据传递给死板的下游数据库解析器时——你需要绝对的严谨。机器到机器的交接需要精确、严格的 JSON Schema。但对于推理、生成和解决问题呢？请适度放权吧。

如果你今天想立刻升级你的编程助手，请将下面这段内容原封不动地复制粘贴到你的 claude.md、memory.md 或 Agent 的核心系统提示词中：

## Prompt Writing Philosophy
When writing LLM prompts (system prompts, skill specs, subagent prompts): **give principles, not rigid rules.**
- Tell the LLM what good output looks like and why — let it figure out how
- Avoid prescribing exact fields, counts, or formats unless the output is a machine-consumed intermediate
- Exception: structured handoffs between agents can be rigid because downstream agents need consistent field names

别再试图对机器进行“微操”了。相信现代的 LLM 吧。当我们不再把它们当成巨婴来对待时，它们会表现得更快、更聪明，能力也远超你的想象。