AI 编程中的提示词如何变成技术债务

技术债务一直是熟悉的问题，而 AI 有双面影响：它能帮助清理过去过于繁琐的工作，也能让人更容易在不了解代码的情况下不断增加代码。我想讨论 Sean Goedecke 提出的相关观点：提示词本身也会成为技术债务。

项目指令文件就是一个例子。我已经怀疑 T3 Code 仓库中的 AGENTS.md 过时了，甚至可能造成问题。与代码一样，指令会在项目变化过程中不断累积；但与编译错误不同，它们造成的问题可能不会主动显现。

Goedecke 从代码带来维护成本这一观点说起。新功能需要代码，但未来的改动必须与已有内容共存。足够大的系统无法全部装进一个人的脑海，因此工程师需要方法来浏览和理解各个部分。

我记得早期有人期待 AI 工具能把整个代码库直接装入越来越大的上下文窗口。实际使用中，搜索相关文件的方法可能更有用。我并不是说某一种检索方法总会胜出，而是说大上下文窗口不会自动让人或智能体可靠理解每一行代码。

提示词有许多形式：AGENTS.md 或 CLAUDE.md、子目录指令、技能、工具描述，以及应用动态组合的系统提示词。例如，T3 Chat 会根据选择的工具和模型调整系统提示词。这种灵活性同时也带来了需要维护的配置。

小幅调整提示词可能改变模型行为。我见过供应商为不同模型测试指令和工具描述。我提到过不同运行框架之间据称存在性能差异，但具体数字取决于基准和配置，不能证明某个工具对所有模型都有固定比例的提升。

例如，我提到一位开发者在发布前花时间测试 Gemini 的提示词，以减少不必要的工具调用。更广泛的启示是，让模型表现良好需要做模型名称之外的工作。系统提示词不是神秘的秘密，但开发和评估它们确实可能需要工程投入。

改变工作流程也会改变智能体能看到什么、如何行动。增加技能、插件或 MCP 服务器，可能引入新指令或工具，具体取决于产品和配置。把所有看起来有趣的东西都装上，可能消耗上下文并促使模型使用无关工具，因此我建议检查实际启用了什么。

Goedecke 认为，不应在定制编程环境上花过多时间，因为提示词调整可能高度依赖具体模型。新模型可能以不同方式理解过去有用的指令，维护智能体的公司也可能需要为新版本重新调整工具描述。我自己测试时就遇到过类似变化。

这会产生一种隐蔽的失败方式。精心设计的指令可能在模型更新后过时，甚至产生负面影响，但智能体依然可能给出看似合理的结果。人们可能把问题归咎于模型或应用，却没有注意到旧的定制配置正在影响结果。

我喜欢从最小配置开始，在遇到具体需求时再增加能力。我以较朴素的方式使用 Pi 编程智能体，部分原因是想看清底层模型擅长和不擅长什么。它的可定制性很有用，但我不会认为每种可用定制都必须启用。

我比较了不同运行框架可能用于指令和工具的上下文数量。我提到的数字来自特定版本和配置，并不是普遍适用的当前 token 数量。重要的是检查自己的设置，理解有用指导与智能体必须处理的额外内容之间的取舍。

提示词债务可能悄悄恶化。一条旧指令的语法仍然有效，却可能把智能体悄悄引向错误方向，尤其是在模型或项目变化后。传统代码也可能静默出错，但提示词行为的问题在没有代表性评估时尤其难以发现。

我检查 T3 Code 的 AGENTS.md，发现其中仍把仓库描述为早期开发项目并鼓励大范围改动，还写着我认为已经不再适用的 Codex 优先架构。那条宽泛指令过去曾有用途，但我现在怀疑它可能鼓励我们不希望出现的改动。

正确更新文件不只是随意删除文本：理想情况下，我们应该用真实任务测试修改后的指导，看看行为是否改善。团队一直忙于发布功能，这正是代码库不断变化时，指令文件容易被忽略的原因。

对于另一个项目 Lakebed，我描述了一种不同的智能体文件：它更像一封解释项目目的和期望做法的信，而不是目录地图。我认为解释“为什么”以及“是什么”都可能有价值。难点是它仍然比普通代码更不确定，失败也可能悄无声息。

固定使用同一个模型也许能避免部分变化，但在模型快速进步时，Goedecke 和我怀疑冻结配置是否总是可行。这是对当时进展速度和取舍的判断，不是说所有应用都必须立即升级，也不是说新模型总会胜出。

他给许多用户的建议是选择有人维护的编程工具，并限制自定义配置，让工具维护者在模型变化时负责评估提示词。这也是 T3 Code 的部分动机：提供一个界面，同时利用维护底层智能体工具的团队所做的工作。

实际建议是避免不必要的技能和工具，让项目指令聚焦具体事实。对泛泛的行为引导，以及无人审查、由模型生成的大段指令，要保持谨慎。这些是偏好和经验法则，并不证明每个较长的指令文件都有害。

我倾向于有意识地编写或审查指令，并移除不再有帮助的内容。我的全局指令很短，但有时连这些也会碍事。对于许多项目，我开始时不设置项目专属智能体文件，等反复出现的需求明确后再增加指导。

检查提供给智能体的 Markdown 文件、系统提示词和其他指令。确认它们是否仍准确描述当前项目，每条指令是否有助于完成真实任务。我自己的仓库就是这种疏忽很容易发生的例子：代码多次变化，指导文件却一直没有更新。