提示词同样是技术债务：为何应谨慎定制

提示词同样是技术债务

说“所有代码都是技术债务”是常见且正确的。添加代码是开发新功能的必要之恶：你几乎总是要这么做，但每行代码都会增加系统的复杂性和维护负担。系统未来所有的变更都必须与现有代码协同工作，或至少避免破坏它。一旦系统积累了足够多的代码，它们就变得让一个人无法理解：你无法通过阅读代码并理解其功能，而必须依赖猜测、理论和启发式方法¹。明智的工程师会尽可能少写代码。

然而，他们却写大量提示词！许多大型项目现在都有一套特定于代码库的提示词文件：AGENTS.md、CLAUDE.md，以及子目录中的类似文件和技能文件。如果你正在构建使用人工智能²的程序，你会为各种能力和每个工具准备单独的提示词，还有一整套系统提示词。

提示词很重要。对LLM提示词的微小调整可以带来显著的性能提升。如果同一个模型在Codex、Cursor、OpenCode和Copilot上感觉不同，那几乎肯定是因为提示词的细微差异。人工智能公司花费大量时间测试和调整他们的提示词，因此工程师花大量时间调整他们项目的AGENTS.md文件³也就合情合理了。我甚至会把切换工具或工作流程视为一种提示词形式。如果我开始把代理包装进Ralph循环、引入新的技能文件或安装MCP服务器，那仍然是对我提示词的更改，尽管不是我写的。

我认为花大量时间调整一个定制的代理编码环境是个坏主意。考虑到提示词调整能带来很多价值，为什么这么说呢？因为提示词调整是针对特定模型的。之前我提到人工智能公司花费大量时间调整提示词。实际上，他们每次发布新模型都要花这么多时间。在GPT-5.4上运行良好的提示词不一定能在GPT-5.5上同样好用。每次你都得“学会如何把握模型”。

换句话说，你今年一月精心制作的一套提示词，到了二月可能就过时了，甚至有害。更糟的是，你可能根本注意不到。模型能力本来就很难精确把握（除非你通过不同模型和工具运行每个问题），即使弱人工智能系统在某些问题上也出奇地好。你可能会想“嗯，新的Anthropic模型并没有宣传的那么令人印象深刻”，或者“哇，Claude Code最近变差了”。

从这个意义上说，提示词是比代码更糟糕的技术债务形式。当技术债务爆发时，通常会导致错误或在你试图理解代码时明显变慢。提示词则会无声地腐烂。此外，即使糟糕的代码在无人触碰时往往相对稳定，但每次模型升级都可能把一个功能正常的提示词变成失效的。

你能干脆决定不升级模型吗？有些人正在尝试这么做，但改进的速度太快，这实际上并不可行。围绕GPT-4.1精心设计的代理框架总是比不上围绕Opus 4.7构建的简陋框架。在未来的某个时间点，当模型改进速度放缓（或者模型能力足够强，你不需要额外的智能来完成常规工程任务）时，这也许是一个明智的策略，但我认为今天不是。

在我看来，大多数人应该只选择一个由第三方公司维护的人工智能编码工具（Claude Code、Codex、Cursor、Copilot等），并尽可能保持不配置，这样就能借力于那些针对每个新模型评估和调整提示词的工程师团队的工作。除非绝对必要，否则避免使用MCP和技能，并默认关闭它们。至少这样，如果其中一个团队搞砸了，用户最终会注意到并抱怨。

当你编写AGENTS.md文件时，尽量避免行为引导（比如现已过时的“一步一步思考”、“你是一位熟练的工程师”或“如果任务完成得好，我会给你200美元小费”）。把它们限制在关于项目的具体、明确事实上。不要让模型在AGENTS.md中塞入数页未经仔细审阅的文本，就像你不会让它们在你的代码库中塞入数页未经仔细审阅的代码一样。自己编写提示词，并且一有机会就删除它们。

¹ 你可能会被雇去工作的几乎所有系统都属于这一类（如果不是系统本身的代码，那么它的依赖和库也是）。 ² 而不是仅仅用人工智能来构建程序。我在GitHub Models上工作时，这种区别真的很麻烦。 ³ 如果你喜欢这篇文章，可以考虑订阅邮件通知以获取我的新文章，或者在Hacker News上分享它。