系统提示词的行为克隆：在专家离职前留住专业判断

你最棒的系统提示词是由一位已经不在这里工作的人编写的。

那句话的杀伤力取决于你在组织中所处的位置。如果你是一名继承了一个管理着生产级 AI 功能的、未经文档记录的 3,000 token 提示词的工程师，你肯定已经经历过这种情况。你盯着像“除非上下文需要，否则不要包含补充数据”这样的条款，却完全不知道“上下文”意味着什么，是什么触发了这条规则，或者删除它会导致 5% 的质量提升还是灾难性的性能回归。如果你是一名团队负责人，你眼睁睁地看着制度性知识随着每一位资深工程师或提示词专家的跳槽而流失——而这些知识并没有进入文档，因为没有人意识到有什么需要记录的。

这就是系统提示词的知识管理问题，它比大多数团队意识到的还要严重。解决办法借鉴了机器人研究中的一个理念，并将其应用于一个深刻的人性化工程挑战：行为克隆 (behavioral cloning) —— 捕捉专家做了什么，以及背后的原因，在他们离职之前。

黑盒是逐渐积累起来的

系统提示词最初并不是不可维护的黑盒。它们始于由深刻理解问题的人编写的几行意图。然后它们开始演变。

为了处理来自客户投诉的边缘案例，添加了一条规则。三个月后，另一位工程师添加了一个说明，却微妙地反驳了原始规则。安全审查插入了一个约束。有人为了修复输出格式问题添加了一个短语，却没有意识到它略微改变了人设。等到团队拥有一个可运行的、生产级质量的提示词时，已经没有人能重构出单个指令与它们旨在产生的行为之间的因果链了。

关于 LLM 生产事故的研究证实了从业者已经察觉到的事实：提示词更新是已部署 AI 系统中导致生产环境回归的主要原因。而且其机制异常脆弱 —— 微小的词汇变化，一个同义词或重新表述的子句，都可能触发模型行为不成比例的巨大变化。工程师们报告说，在一项看起来只是修饰性措辞改进的变更后的几个小时内，结构化输出的错误率就会飙升。

脆弱性并不是问题的全部。真正的问题在于，当某些东西崩溃时，你无法追踪原因。而当原作者离开时，你完全失去了做出明智变更的能力。

为什么这不同于常规的代码文档

你可能会争辩说这只是个文档问题 —— 写注释、维护变更日志，搞定。但系统提示词与代码在一个关键点上有所不同：它们的行为是随机的 (stochastic)。

当你为一个函数编写文档时，你可以编写一个确定性的测试。运行它，观察输出，断言它匹配。如果输出匹配，函数就能工作。系统提示词不是这样工作的。同一个提示词，给同一个模型，在不同的运行中可能会产生显著不同的输出。你实际指定的是一种行为分布，而不是单一行为。

这改变了文档的含义。你不能通过运行一次提示词并记录它产生的内容来为它编写文档。你需要记录：

• 每个指令背后的意图 —— 它是为了防止哪种失败模式而编写的？
• 边界条件 —— 什么样的输入会触发或停用此规则？
• 可接受的输出分布 —— 不仅是正确答案的样子，还包括可以忍受多大的偏差以及如何衡量它
• 副作用 —— 哪些下游系统依赖于此提示词产生的特定输出模式？

典型的版本控制提交信息无法捕捉到这些内容。而且在创建的那一刻，几乎没有任何内容会被写下来，因为作者把这一切都记在脑子里。

行为克隆作为文档框架

在机器人学和强化学习中，行为克隆是一种通过观察演示来训练系统模仿专家的技术 —— 捕捉专家做了什么，而不是试图从基本原理出发进行规范。这一核心见解直接适用于系统提示词的知识管理。

你不是在试图从头开始写一份说明书。你是在尝试捕捉一个运行系统中已经存在的、可观察的行为，以及解释这些行为的推理过程。产出不是一份系统文档 —— 而是一个带有注释的提示词，其中每个非显而易见的指令都附带了一个理由链。

这种结构化方法如下：

组件级分解：将提示词视为离散组件的集合，而不是单一块状文本。分析真实世界 LLM 应用的研究识别出了七个经常出现的组件 —— 角色定义、指令、工作流、上下文、示例、输出格式和约束。每个组件都应该单独记录，并附带其自身的目的声明。这使得讨论和修改提示词成为可能，而无需将其视为一个不可分割的整体。

加载中…