跳到主要内容

AI 接班人计划:当了解提示词的团队离开时会发生什么

· 阅读需 13 分钟
Tian Pan
Software Engineer

负责构建客户支持 AI 的工程师离职去迎接新工作了。在他们的最后一天,你进行了一次离职面谈,并要求他们记录下所知道的一切。他们写了几段文字来解释系统的工作原理。六个月后,客户满意度评分开始下降。有人建议微调系统提示词(system prompt)的语气。另一位工程师进行了修改,运行了几次手动测试,然后上线了。三周后,你发现原始系统提示词中的一个特定措辞其实起到了没人知道的关键支撑作用——它是防止模型在周五下午过度升级工单的唯一机制,这是最初的工程师注意到并用一句话悄悄修复的模式。

没有人知道那句话的存在是有原因的。它看起来像是实现细节,但实际上是组织知识(institutional knowledge)。

这就是 AI 继任问题。与传统软件不同(在传统软件中,git blame 可以显示谁更改了某个函数,良好的提交信息可以解释原因),基于 LLM 的系统将其推理蕴含在自然语言中,无论这些语言是编码了关键意图还是在五分钟内写成的,看起来都一样。这种文档缺失是结构性的,而非偶然。它随着每一次模型升级、每一次提示词编辑以及每一位在不了解原作者意图的情况下接触系统的工程师而不断累积。

为什么提示词难以沿用传统的文档实践

在软件工程中,代码背后的意图在某种程度上是自文档化的。函数名、类型签名和测试用例传达了一段代码应该做什么。当这些信号不足时,工程师会编写注释或文档字符串。意图可以从实现中推导出来。

提示词不具备这种属性。一个 500 token 的系统提示词就是一堵自然语言墙。它的内部结构是不可见的。约束和功能交织在散文中。“你是一个得力的助手”与“你是一个得力的助手。当用户表达沮丧时,在尝试解决问题之前先承认这种情绪”之间的区别在表面上是看不出来的——直到第一个版本导致满意度评分明显下降,而你花了两个星期进行 A/B 测试才找回第二个版本。

核心问题在于:提示词的语义意图无法仅从其文本中恢复。要理解为什么提示词以特定方式表述,你需要知道:

  • 原作者试图诱导什么样的行为
  • 他们在防范哪些故障模式
  • 哪些评估结果导致了这种特定的表述
  • 尝试过并拒绝了哪些替代方案

这一切都不存在于提示词文件中。它存在于编写者的脑海里。

关于软件知识管理的研究表明,大约 42% 的组织知识存在于单个员工身上,而不是记录在系统中。对于 AI 团队来说,这个比例可能更糟,因为在 2024 年之前,捕捉提示词级别知识的工具几乎不存在。

提示词债务螺旋

当有关提示词的知识没有被记录下来时,你就会积累一种特殊的、看起来不像技术债的技术债。系统在持续运行。评估甚至可能通过。但是,支持进行自信更改的理解基础已经侵蚀。

第一个症状是提示词囤积。工程师们不愿编辑非本人编写的系统提示词,因为他们不确定会破坏什么。于是提示词越写越长。新指令只是被追加而非整合。矛盾不断累积。提示词变成了一个考古遗址,每一句话都有不同的年代感,而且没人知道哪些话仍然起着关键支撑作用。

第二个症状是模型迁移瘫痪。当你的 LLM 供应商弃用某个模型而你需要迁移时,在旧模型上有效的指令需要在新模型上重新评估。如果你不明白每条指令存在的原因,你就无法就保留什么、重写什么以及测试什么做出有原则的决定。记录了提示词的团队在几天内就能完成迁移。没记录的团队则需要数月——或者推迟迁移,直到旧模型彻底无法使用。

第三个症状是 Diff 问题。当提示词更改导致回归(regression)时,git diff 会显示更改了什么。但它不会告诉你为什么之前的版本是正确的。如果没有意图文档,你就是在凭直觉调试,这种方式既缓慢又不可靠。

提示词考古:重建你所丢失的东西

对于已经背负债务的团队,第一步是考古:在为时已晚之前,尝试重建现有提示词背后的推理。

这种方法是系统性的。从最关键的提示词开始——那些涉及用户交互行为或处理高风险决策的提示词。对于每一个提示词,在原作者还在职时与他们安排一次工作会议。目标不是记录提示词说了什么(文本已经在那里了),而是记录它的用途。

每个提示词的关键问题:

  • 什么样的特定行为失败促使了这条指令的产生?
  • 尝试过哪些替代方案?
  • 哪些评估或用户反馈验证了这种表述?
  • 你最不确定要更改哪些句子,为什么?

这些答案应该存在于提示词文件旁边的决策日志中。不是 Wiki,也不是幻灯片——而是与提示词本身一起进行版本控制的东西,并且对下一个打开该文件的人可见。

即便是部分考古也是有价值的。解释系统提示词中某条最违反直觉的指令原始意图的一个段落,其价值超过一百行关于 AI 系统目标的通用文档。

评测即文档:在测试中编码意图

最持久的提示词文档形式不是散文,而是评测(evaluations)。一个设计良好的评测套件将提示词预期的功能编码成可执行、受版本控制且在每次变更时都会进行回归测试的形式。

这重新定义了评测的角色。它们不仅是质量检查,更是意图的规范。当一个评测测试模型不会升级常规工单时,该测试传达了提示词文件中的任何注释都无法像这样可靠传达的信息:这种行为很重要,我们衡量了它,并且我们承诺维护它。

让“评测即文档”发挥作用的准则:

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates