你最棒的系统提示词是由一位已经不在这里工作的人编写的。
那句话的杀伤力取决于你在组织中所处的位置。如果你是一名继承了一个管理着生产级 AI 功能的、未经文档记录的 3,000 token 提示词的工程师，你肯定已经经历过这种情况。你盯着像“除非上下文需要，否则不要包含补充数据”这样的条款，却完全不知道“上下文”意味着什么，是什么触发了这条规则，或者删除它会导致 5% 的质量提升还是灾难性的性能回归。如果你是一名团队负责人，你眼睁睁地看着制度性知识随着每一位资深工程师或提示词专家的跳槽而流失——而这些知识并没有进入文档，因为没有人意识到有什么需要记录的。
这就是系统提示词的知识管理问题，它比大多数团队意识到的还要严重。解决办法借鉴了机器人研究中的一个理念，并将其应用于一个深刻的人性化工程挑战：行为克隆 (behavioral cloning) —— 捕捉专家做了什么，以及背后的原因，在他们离职之前。
黑盒是逐渐积累起来的
系统提示词最初并不是不可维护的黑盒。它们始于由深刻理解问题的人编写的几行意图。然后它们开始演变。
为了处理来自客户投诉的边缘案例，添加了一条规则。三个月后，另一位工程师添加了一个说明，却微妙地反驳了原始规则。安全审查插入了一个约束。有人为了修复输出格式问题添加了一个短语，却没有意识到它略微改变了人设。等到团队拥有一个可运行的、生产级质量的提示词时，已经没有人能重构出单个指令与它们旨在产生的行为之间的因果链了。
关于 LLM 生产事故的研究证实了从业者已经察觉到的事实：提示词更新是已部署 AI 系统中导致生产环境回归的主要原因。而且其机制异常脆弱 —— 微小的词汇变化，一个同义词或重新表述的子句，都可能触发模型行为不成比例的巨大变化。工程师们报告说，在一项看起来只是修饰性措辞改进的变更后的几个小时内，结构化输出的错误率就会飙升。
脆弱性并不是问题的全部。真正的问题在于，当某些东西崩溃时，你无法追踪原因。而当原作者离开时，你完全失去了做出明智变更的能力。
为什么这不同于常规的代码文档
你可能会争辩说这只是个文档问题 —— 写注释、维护变更日志，搞定。但系统提示词与代码在一个关键点上有所不同：它们的行为是随机的 (stochastic)。
当你为一个函数编写文档时，你可以编写一个确定性的测试。运行它，观察输出，断言它匹配。如果输出匹配，函数就能工作。系统提示词不是这样工作的。同一个提示词，给同一个模型，在不同的运行中可能会产生显著不同的输出。你实际指定的是一种行为分布，而不是单一行为。
这改变了文档的含义。你不能通过运行一次提示词并记录它产生的内容来为它编写文档。你需要记录：
- 每个指令背后的意图 —— 它是为了防止哪种失败模式而编写的？
- 边界条件 —— 什么样的输入会触发或停用此规则？
- 可接受的输出分布 —— 不仅是正确答案的样子，还包括可以忍受多大的偏差以及如何衡量它
- 副作用 —— 哪些下游系统依赖于此提示词产生的特定输出模式？
典型的版本控制提交信息无法捕捉到这些内容。而且在创建的那一刻，几乎没有任何内容会被写下来，因为作者把这一切都记在脑子里。
行为克隆作为文档框架
在机器人学和强化学习中，行为克隆是一种通过观察演示来训练系统模仿专家的技术 —— 捕捉专家做了什么，而不是试图从基本原理出发进行规范。这一核心见解直接适用于系统提示词的知识管理。
你不是在试图从头开始写一份说明书。你是在尝试捕捉一个运行系统中已经存在的、可观察的行为，以及解释这些行为的推理过程。产出不是一份系统文档 —— 而是一个带有注释的提示词，其中每个非显而易见的指令都附带了一个理由链。
这种结构化方法如下：
组件级分解：将提示词视为离散组件的集合，而不是单一块状文本。分析真实世界 LLM 应用的研究识别出了七个经常出现的组件 —— 角色定义、指令、工作流、上下文、示例、输出格式和约束。每个组件都应该单独记录，并附带其自身的目的声明。这使得讨论和修改提示词成为可能，而无需将其视为一个不可分割的整体。
理由注释：对于提示词中的每个规则或约束，原作者（或与该作者进行的文档记录会议）在记录“是什么”的同时捕捉“为什么”。不是“除非上下文需要，否则不要包含补充数据”，而是：“在 2024-03 客户支持报告冗长的回复令非专家用户感到困惑后添加。上下文意味着：用户的消息展示了先前的领域知识。”这是专家离开时会丢失的关键部分。
边缘案例目录：最优秀的提示词工程师会维护一个心理目录，记录他们的提示词能正确处理的奇怪边缘案例。这些很少能进入文档。结构化的离职面试或文档冲刺可以显式地提取它们 —— “带我了解三个在你添加这条规则之前会产生糟糕输出的输入。”
回归锚点：对于提示词维持的每个显著行为特征，记录一个测试台 (test harness) —— 一组输入和预期的输出特征（不是精确的输出，而是分布和关键指标），可用于在变更后检测行为回归。
知识捕获过程
等到有人要离开时才开始捕获知识已经太晚了，但总比什么都不做要好。结构化的知识捕获环节，以 60-90 分钟为一个单元，即使是对于那些认为自己只是在做“显而易见”的事情的作者，也能从中提取出惊人数量的隐性知识。
有效的环节遵循以下模式：
首先从 Prompt 的历史开始，而不是它的现状。让作者回顾重大的变化——在 2.0 版本之前 Prompt 是什么样的？是什么问题触发了每次重大的更新？这些历史揭示了当前 Prompt 正在防范的失效模式，而这恰恰是未来的维护者所需要的。
然后转向作者对系统的心理模型。让他们预测 Prompt 会如何响应异常输入。这些预测本身就是文档——它们揭示了作者正在维持的隐含行为规律。当预测是“它会因为 Y 而做 X”时，这就是一个等待被记录下来的理由注解。
最后，询问他们从未改动过但思考过的事情。大多数资深的 Prompt 工程师都有一份考虑过但被拒绝的更改列表，而这些拒绝背后的推理往往是系统中价值最高的隐性知识。
哪些工具真正有用
Prompt 的版本控制工具链已经显著成熟。像 Langfuse、Braintrust 和 LaunchDarkly 的 Prompt 管理功能提供了机械层面的支持——不可变版本控制、元数据附加、跨 Prompt 版本的性能关联。关键在于强制捕获这些元数据：作者、时间戳、更改原因、关联的评估结果。
但是，没有流程的工具只是虚有其表。注解实践才是难点。一个允许你在不要求提供理由的情况下附加变更日志信息的 Prompt 管理系统，只不过是一个更高级的 git commit。这种纪律在于“要求”而非“允许”对意图进行文档记录。
一些团队正在构建轻量级的模式目录（Pattern catalogs）——具有文档化行为、已知边缘情况和经过测试的约束范围的可复用 Prompt 组件。工程师不再从头编写新的约束，而是从经过测试的模式库中进行选择，并清楚地了解他们得到的是什么。模式目录成为一种共享语言，使 Prompt 知识变得可传递。
当知识已经流失时
有些团队面临的情况是原作者已经离开，且没有任何文档。Prompt 勉强运行着，但没人敢去碰它。
取证式方法从行为重构而非文本分析开始。针对大量且多样的输入运行 Prompt，并对输出进行分类。寻找一致的模式——Prompt 始终在做的事情、始终避免的事情、可靠遵守的边界。这种行为画像就成了你反向推导的规范。
在此基础上，你可以对特定指令为何产生特定行为模式形成假设，通过系统性消融（每次删除一个子句并观察变化）来测试这些假设，并逐渐建立起对 Prompt 的注解式理解，即使无法联系到原作者。
这是从行为痕迹中反向工程系统 Prompt——事实证明，这是可行的。既然能从外部重构 Prompt，那么只要方法得当，同样的行为痕迹也能从内部重构它们。
前瞻性的总结
随着 AI 能力和组织需求的演进，系统 Prompt 的复杂性将持续增加。现在就将 Prompt 视为一等生产制品的团队——应用与复杂算法相同的注解纪律、与数据库模式相同的版本控制严谨性、以及与专业代码库相同的知识传递实践——将是两年后仍能理解并修改其 AI 系统的团队。
嵌入在调优良好的系统 Prompt 中的专家判断代表了真实的组织价值。它编码了数月或数年的边缘情况发现、对齐工作和行为校准。当工程师离职时丢失这些知识并非不可避免。这是一种文档记录的选择。
你要问的问题不是“这个 Prompt 能用吗？”，而是“不在场的人能否重建使其生效的推理过程？”如果答案是否定的，那么你距离一个黑盒只差一次职位变动。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
