负责构建客户支持 AI 的工程师离职去迎接新工作了。在他们的最后一天，你进行了一次离职面谈，并要求他们记录下所知道的一切。他们写了几段文字来解释系统的工作原理。六个月后，客户满意度评分开始下降。有人建议微调系统提示词（system prompt）的语气。另一位工程师进行了修改，运行了几次手动测试，然后上线了。三周后，你发现原始系统提示词中的一个特定措辞其实起到了没人知道的关键支撑作用——它是防止模型在周五下午过度升级工单的唯一机制，这是最初的工程师注意到并用一句话悄悄修复的模式。
没有人知道那句话的存在是有原因的。它看起来像是实现细节，但实际上是组织知识（institutional knowledge）。
这就是 AI 继任问题。与传统软件不同（在传统软件中，git blame 可以显示谁更改了某个函数，良好的提交信息可以解释原因），基于 LLM 的系统将其推理蕴含在自然语言中，无论这些语言是编码了关键意图还是在五分钟内写成的，看起来都一样。这种文档缺失是结构性的，而非偶然。它随着每一次模型升级、每一次提示词编辑以及每一位在不了解原作者意图的情况下接触系统的工程师而不断累积。
为什么提示词难以沿用传统的文档实践
在软件工程中，代码背后的意图在某种程度上是自文档化的。函数名、类型签名和测试用例传达了一段代码应该做什么。当这些信号不足时，工程师会编写注释或文档字符串。意图可以从实现中推导出来。
提示词不具备这种属性。一个 500 token 的系统提示词就是一堵自然语言墙。它的内部结构是不可见的。约束和功能交织在散文中。“你是一个得力的助手”与“你是一个得力的助手。当用户表达沮丧时，在尝试解决问题之前先承认这种情绪”之间的区别在表面上是看不出来的——直到第一个版本导致满意度评分明显下降，而你花了两个星期进行 A/B 测试才找回第二个版本。
核心问题在于：提示词的语义意图无法仅从其文本中恢复 。要理解为什么提示词以特定方式表述，你需要知道：
原作者试图诱导什么样的行为
他们在防范哪些故障模式
哪些评估结果导致了这种特定的表述
尝试过并拒绝了哪些替代方案
这一切都不存在于提示词文件中。它存在于编写者的脑海里。
关于软件知识管理的研究表明，大约 42% 的组织知识存在于单个员工身上，而不是记录在系统中。对于 AI 团队来说，这个比例可能更糟，因为在 2024 年之前，捕捉提示词级别知识的工具几乎不存在。
提示词债务螺旋
当有关提示词的知识没有被记录下来时，你就会积累一种特殊的、看起来不像技术债的技术债。系统在持续运行。评估甚至可能通过。但是，支持进行自信更改的理解基础已经侵蚀。
第一个症状是提示词囤积。工程师们不愿编辑非本人编写的系统提示词，因为他们不确定会破坏什么。于是提示词越写越长。新指令只是被追加而非整合。矛盾不断累积。提示词变成了一个考古遗址，每一句话都有不同的年代感，而且没人知道哪些话仍然起着关键支撑作用。
第二个症状是模型迁移瘫痪。当你的 LLM 供应商弃用某个模型而你需要迁移时，在旧模型上有效的指令需要在新模型上重新评估。如果你不明白每条指令存在的原因，你就无法就保留什么、重写什么以及测试什么做出有原则的决定。记录了提示词的团队在几天内就能完成迁移。没记录的团队则需要数月——或者推迟迁移，直到旧模型彻底无法使用。
第三个症状是 Diff 问题。当提示词更改导致回归（regression）时，git diff 会显示更改了什么。但它不会告诉你为什么之前的版本是正确的。如果没有意图文档，你就是在凭直觉调试，这种方式既缓慢又不可靠。
提示词考古：重建你所丢失的东西
对于已经背负债务的团队，第一步是考古：在为时已晚之前，尝试重建现有提示词背后的推理。
这种方法是系统性的。从最关键的提示词开始——那些涉及用户交互行为或处理高风险决策的提示词。对于每一个提示词，在原作者还在职时与他们安排一次工作会议。目标不是记录提示词说了什么（文本已经在那里了），而是记录它的用途。
每个提示词的关键问题：
什么样的特定行为失败促使了这条指令的产生？
尝试过哪些替代方案？
哪些评估或用户反馈验证了这种表述？
你最不确定要更改哪些句子，为什么？
这些答案应该存在于提示词文件旁边的决策日志中。不是 Wiki，也不是幻灯片——而是与提示词本身一起进行版本控制的东西，并且对下一个打开该文件的人可见。
即便是部分考古也是有价值的。解释系统提示词中某条最违反直觉的指令原始意图的一个段落，其价值超过一百行关于 AI 系统目标的通用文档。
评测即文档：在测试中编码意图
最持久的提示词文档形式不是散文，而是评测（evaluations）。一个设计良好的评测套件将提示词预期的功能编码成可执行、受版本控制且在每次变更时都会进行回归测试的形式。
这重新定义了评测的角色。它们不仅是质量检查，更是意图的规范。当一个评测测试模型不会升级常规工单时，该测试传达了提示词文件中的任何注释都无法像这样可靠传达的信息：这种行为很重要，我们衡量了它，并且我们承诺维护它。
让“评测即文档”发挥作用的准则：
根据它们防止的失败来命名评测。 一个名为 no_friday_escalation 的评测比名为 test_case_47 的评测传达了更多信息。当新工程师阅读评测套件时，这些名称讲述了原始团队所关注的核心问题。
将评测链接到它们涵盖的提示词指令。 在提示词中添加一个简单的注释——# [参见评测: no_friday_escalation]——就能在指令和测试之间建立起可追溯的联系。评测解释了指令存在的原因，而指令则解释了评测正在测试的内容。
追踪评测添加的时间，而不仅仅是它们何时通过。 在生产环境事故后添加的评测是失败的记录。当你决定是否删除一个看似多余的指令时，这种上下文非常重要——如果覆盖该指令的评测是在事故发生后添加的，那么该指令可能并不多余。
将评测失败视为文档失败。 如果一名工程师编辑了提示词，触发了评测失败，却不明白原因，那么该评测就没有完成其文档工作。失败消息应该解释预期的行为是什么，以及为什么该行为很重要。
决策日志：提示词工程师缺失的版本控制 Git 给你历史。决策日志给你推理。对于提示词，你两者都需要。
提示词决策日志是关于重大变更的结构化记录，附加在提示词文件上或存储在其旁边。格式不需要太复杂：
[2025-11-12] 收紧了第 2 节中的确认性用语 原因：用户研究显示，原始表述（“我理解你的顾虑”）对于已经多次解释过问题的用户来说，读起来带有轻蔑感。 尝试过的替代方案：完全删除确认语——导致升级率增加了 8%。 决策：当前的表述（“我看到这件事情一直在持续”）已通过 A/B 测试验证。 评测：添加了 acknowledgment_tone_test 来覆盖此行为。 写下这些只需三分钟，却能在六个月后有人重新审视该决策时节省数小时的调试时间。关键字段包括：改变了什么、为什么之前的版本不够好、评估了哪些替代方案，以及现在哪个测试覆盖了该行为。
决策日志还可以作为入职文档。新工程师通过阅读系统提示词的日志，不仅能了解当前提示词的内容，还能了解它所应对的问题空间——失败模式、用户行为以及团队已经权衡过的各种取舍。这就是可以复原的制度性知识。
一些团队正在借鉴软件架构中流行的架构决策记录（ADR）格式来进行提示词变更。其结构映射非常清晰：上下文（为什么这个决策是必要的）、决策（改变了什么）、后果（这启用了哪些行为，限制了哪些行为）。针对提示词的关键调整是附上相关的评测套件，而 ADR 通常不包含这些。
构建能够经受人员变动的系统 反应式文档——在某人离开前抓取知识——总比没有好。但目标是让提示词文档成为正常开发的副产品，而不是由离职面谈触发的紧急措施。
以下几点实践能让这变得可持续：
要求为生产环境的提示词变更记录决策日志。 像对待库发布的变更日志（changelog）一样对待它们。门槛不需要太高——两三句话就足够了。习惯比详尽程度更重要。
通过评测运行来限制提示词部署。 如果每次提示词变更都要运行评测套件，团队就能清晰地掌握哪些行为被覆盖了，哪些没有。覆盖范围的缺口会表现为缺失的评测，在原始作者失去上下文之前，可以及时补上。
在团队交接期间审计提示词所有权。 在工程师转岗离开项目之前，审计他们拥有的提示词。识别哪些提示词缺乏决策日志。根据复杂性和生产环境的关键程度，优先安排文档补课。
将评测覆盖率作为健康指标。 追踪生产环境提示词行为中有多少比例被命名的、有意识的评测所覆盖。一个评测覆盖率仅为 30% 的系统存在交接风险；而一个覆盖率为 85% 的系统则是可转交的。这个指标让风险在变成危机之前就变得可见。
目标不是消除构建系统的工程师的知识优势，而是确保这种优势被编码在可访问的地方，而不是锁在某个人的脑子里。与系统共处了两年的工程师总是比刚加入的工程师跑得快。问题在于这个差距是三个月还是三年——而这个问题的答案，取决于你在原始团队还在时所建立的文档实践。
模型迁移测试 这是一个衡量继承就绪度的实际测试：在没有任何原团队成员在场的情况下，你的团队能否迁移到新的模型版本？
模型迁移会迫使你根据新的运行时环境重新评估每一个 prompt。如果你的 prompt 文档完善，迁移就是一项工程任务：你有一个能告诉你成功标准的评估套件（eval suite），有一份解释每条指令存在原因的决策日志，以及足够的上下文来对需要重写的内容做出有原则的决策。如果你的 prompt 没有文档记录，迁移就像是在搞考古：你在通过文本推测意图，凭直觉进行更改，并在生产环境中不断发现回归问题。
拥有强大 prompt 文档记录的团队通常能在几天内完成迁移。而缺乏记录的团队通常需要数月时间——或者完全避开迁移，从而在已弃用的模型上积累安全和功能债务。
继承问题和迁移问题其实是同一个问题。两者都要求你回答：我们是否理解这个 prompt 在做什么以及为什么要这样做？答案要么是“是”，因为我们记录了它；要么是“否”，因为我们假设最初的工程师会一直留在团队中进行解释。
基于 Prompt 的 AI 系统将其推理逻辑承载在自然语言中，这对任何非原作者来说都是不透明的。这不是媒介本身的 bug——而是一个需要刻意采取补偿性实践的特性：决策日志、命名的评估、明确的覆盖范围追踪，以及在关键人员离职前的结构化知识传递。
那些能够在数年跨度内可靠维护 AI 系统的团队，并不是那些雇佣了最优秀的 prompt 工程师的团队。而是那些建立了能让 prompt 知识可传递的制度化实践的团队。记录意图的评估套件、解释推理过程的决策日志、暴露缺口的覆盖率指标——这些正是 AI 系统中那些不起眼的基础设施，它们让系统能够真正经受住组织现实的考验。
你的供应商发布的下一个模型版本将要求你进行迁移。当那一天到来时，那个了解系统 prompt 中每一句话存在意义的工程师可能已经不在团队中了。你今天编写的文档，就是你届时所需的继承计划。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
