30 天 Prompt 见习计划：当“阅读代码”失效时，如何入职工程师

一位资深工程师在周一加入你的团队。到了周五，他们已经交付了一个涉及 11 个文件的 TypeScript 重构，并在通过评审时仅有两个小细节（nits）需要修改。两周后，这位工程师打开了路由智能体（routing agent）的系统提示词——240 行指令、三个编号的示例块、四个“绝不允许”子句，以及底部一段读起来像道歉的段落——然后盯着它看了一个小时。他们无法告诉你如果删除第 87–94 行会发生什么。六个月前写下这些内容的工程师也无法告诉你。

这是没人会写在入职文档里的鸿沟。一个重度依赖提示词的代码库看起来像是个代码库：它存在于同一个仓库中，运行相同的 CI，并在相同的 PR 中接受评审。但它的语义却存在于别处：存在于一个团队中没人构建的模型观察到的行为中，针对的是一个没人能完全枚举的输入分布，其失败模式表现为添加一句话的 PR，而不是错误报告。传统的代码阅读工具——类型、签名、测试、命名——几乎不起作用。一个试图“阅读代码”的新员工无法了解为什么每一行都在那里，而一个只交给他们 Notion 文档和 Slack 频道的团队，实际上是在默认将入职培训“外包”给提示词的最初作者。

解决办法不是提供更好的文档，而是一个课程：一个结构化的 30 天学徒制，教会工程师像推理函数一样推理提示词——通过询问其行为，而不是解析其文本。以下是这样一套课程的样子，团队为了使其运行必须维护哪些产出物，以及当这些产出物不存在时每个团队最终都会陷入的失败模式。

为什么“阅读代码”对提示词失效

一个 200 行的 TypeScript 模块拥有类型签名、公开 API、一套单元测试，以及包含详尽描述性提交消息的 Git 历史记录。读者可以从命名推断意图，从类型缩小范围，并通过运行测试来重现行为。在系统提示词中，这些信号都不存在。文本就是整个产出物。在“提示词做什么”和“它怎么做”之间没有界限。

更糟糕的是，提示词的行为是整体性的。为了“语气”插入的一句话可能会悄悄削弱十行前设置的约束。一个新的少样本示例（few-shot example）可能会使输出偏离一个罕见但重要的边缘情况。在顶部添加的“保持简练”可能会与底部的“务必引用来源”产生互动，这种互动只有在团队没想过测试的输入下才会显现。最近的从业者文章为此起了一个名字——指令遵循偏移（instruction adherence drift），即随着提示词变得越来越复杂，模型会逐渐降低关键约束的优先级——而这对于阅读静态文本的人来说是不可见的。

差异历史（diff history）也救不了你。典型的提示词修改提交消息通常写着“修复路由边缘情况”，只有一行描述，且没有指向触发该修复的输入的链接。今天阅读第 142 行的工程师无法知道这一行的加入是因为三个月前，一个企业客户的税务报表上传导致智能体静默截断了其响应。语义存在于失败中，而不是代码行中。

因此，如果向一名新工程师展示提示词并告诉他们“读一下”，就是在要求他们去做一件连提示词最初作者在不重新运行评估（evals）的情况下都做不到的事：预测每条指令换回了什么价值。静态文本不是规范，它是过去失败的残留物。要针对它进行入职培训，你必须教授这些“残留物”，而不是文本本身。

第一周：阅读失败案例库，而不是提示词

学徒期的第一天不是打开提示词文件，而是打开“失败案例库（failure gallery）”——这是一个经过整理的记录，包含了提示词表现糟糕到必须进行修改的每一个生产环境输出，并配有修复它的修改方案。每个条目由四个部分组成：触发失败的输入、模型生成的错误输出、解决该问题的提示词差异（diff），以及现在用于防止回归的评估案例。

按顺序阅读，这个案例库会教会工程师提示词“对手”的轮廓。他们会了解到，这个路由智能体在历史上一直会被混合语言输入搞混。他们会了解到，当之前的指令被放宽时，模型开始过度引用。他们会了解到，团队曾经发布过一个“更具对话性”的调整，结果破坏了工具调用（tool-call）格式，且花了一周时间才检测到。到本周末，工程师没有阅读提示词的任何一行文本。他们将其阅读为一系列它必须抵抗的力量（forces it had to resist），这与它的实际语义更加吻合。

这不是大多数团队的入职方式。更常见的模式是给工程师一个描述提示词预期功能的 Notion 页面，将文件链接给他们，并指派一名资深工程师回答问题。Notion 页面总是过时的，而且描述的是意图而非行为。资深工程师变成了机构记忆的单点故障。新工程师将提示词视为一个静态产出物而非控制系统来学习，并且无法继承对哪些行是“承重行”的直觉。

建立失败案例库并非毫无成本。它要求在修复落地之前，每一个提示词事故都要产生记录，且记录是可搜索和带标签的，还需要有人进行整理，以免案例库沦为一堆半记不清的错误报告。投入建立这一产出物的团队将其描述为防止重复错误的机构知识——这种东西你只需要建立一次，但无法廉价地事后补救。

第二周：消解 Prompt 并观察评估套件

第二周是学徒期的技术核心。工程师会得到一个可以运行的评估套件——运行速度快到可以在几秒钟内完成，确定性足以进行运行对比——并被要求进行消融实验。挑选一个段落。删除它。重新运行套件。阅读分数差异。恢复该段落。再选另一个。

这是学习 Prompt 中哪些行是“承重”的唯一可靠方法。如果一行代码在被删除后，导致三个评估类别的分数各下降了 8 分，那么这一行就在发挥实际作用。如果删除一行没有产生可衡量的变化，那么它要么是多余的，要么是它的保护作用已被后来添加的另一条指令悄悄吸收了。工程师通过尝试来学会区分这两者。

这种技术反映了成熟的 Prompt 团队在回归测试中已经做的事情——衡量单个指令的贡献，而不是将 Prompt 作为一个整体来衡量。将其应用于入职培训的新颖之处在于，消融是一种 学习 工具，而不不仅仅是维护工具。一名花了 5 天时间删除段落并观察分数变化的工程师，会对 Prompt 的解剖结构产生一种直觉，这是任何阅读都无法产生的。他们会了解到，两条看起来相似的指令可能有截然不同的影响，指令的位置很重要，示例有时比规则更有效，而且 Prompt 很少像其作者认为的那样写得严丝合缝。

加载中…