你的提示词专家只有 14 个月的半衰期

每一家在生产环境中上线 AI 功能的公司，都有那么一两个无法承受其离职损失的工程师，而大多数公司直到收到辞职邮件时，才意识到这些工程师是谁。

那个关键人物很少是办公室里嗓门最大的。他们是那个记得在第二季度的问题升级后，通过三行系统提示词（system-prompt）修改修好了客服摘要语气的人；是那个在模型供应商悄悄更改默认采样（sampling）的那周，在评估套件（eval suite）中添加了六个案例的人；也是那个在上次有人“清理”评分细则（rubric）时，发现评判标准校准（judge calibration）发生偏移的人。这些内容都没有被记录在继任者能找到的地方。它只存在于一个人的脑子里，而这个人的脑子大约每两周就会收到一次猎头发来的加薪 25% 的消息。

令人不安的并不是这个工程师可能会离职。工程师离职是常态。令人不安的是，你的组织正在使用的职级晋升体系、薪酬范围和知识管理规范，都是为一个与此人的实际工作内容完全不符的角色而设计的。通用的 IC（个人贡献者）职级标准对 AI 工程能力的预测准确性，就像 2018 年的晋升细则预测 2026 年的情况一样——也就是说，根本无法预测。而那些被职级体系忽视的工程师，恰恰是掌握着核心知识的人。

为什么标准职级体系看不见他们

大多数工程晋升细则衡量的是交付范围：一个新的服务、一次系统重构，或者一次有清晰前后对比的迁移。衡量影响力的隐含单位是根据路线图交付的代码行数。这个单位在过去的十五年里是一个合理的代理指标，但在现在的 AI 工作中，它极具误导性。

看看一个高产出的季度对提示词专家来说意味着什么。他们诊断出了一种导致客服团队需要手动修正的幻觉（hallucination）模式，将其追踪到检索提示词（retrieval prompt）中一个模糊的指令，并通过一个 30 行的 diff 修复了它，使评估切片（eval slice）提升了两个百分点。他们为 11 个评估案例添加了溯源元数据，以便下一任工程师知道每个案例是为了防范哪次事故。他们在模型版本升级后重新运行了评判标准校准，并在上线前捕获了一个回归（regression）问题。

这是巨大的价值。但在传统的晋升报告中，这几乎是不可见的。这里没有 5,000 行的代码产物，没有一个写着该工程师名字的轮值服务。对于任何不了解该切片两个百分点提升意味着“功能上线”与“项目流产”之间巨大差异的人来说，评估指标的提升听起来微不足道。根据职级细则的定义，这些工作看起来就像是维护——而维护在晋升评估中总是输给“构建”。

这种偏见长期以来一直在惩罚那些防止了无人察觉的停机事故的工程师，而奖励那些在全员大会上被点名表扬的功能开发者。AI 工程并没有创造这种偏见，它只是把大部分重要工作推向了这种偏见的对立面。优秀的 AI 工程产物通常是一个具有实测效果的小型 diff，而不是一个具有可见规模的大型 diff。一个无法认可这种价值的职级体系，就是一个无法晋升你最核心人才的体系，而看不到晋升路径的工程师就会选择离开。

薪酬范围是根据一个已不存在的职位制定的

人才流失问题还有第二个机制，而且纯粹是财务方面的。“负责提示词和评估的工程师”这个角色在 18 个月前基本不存在。担任这些职位的人最初是以其他身份被聘用的——后端、ML 或通才软件工程师——而他们的薪酬范围仍反映了最初的职级。

与此同时，外部市场对该技能的需求已经完全脱离了这一范围。普华永道（PwC）的《2025 年全球 AI 就业晴雨表》显示，AI 技能的薪酬溢价为 56%，高于一年前的 25%——溢价本身在 12 个月内翻了一番。LLM 微调（fine-tuning）和评估方面的专家比通才工程师的薪水高出 25% 到 40%。内部薪酬范围的变化速度跟不上这种节奏，因为内部范围是每年评审一次，而市场则是每季度重新定价。

结果是，你的提示词专家的薪水与下一个雇主愿意支付的薪水之间的差距越来越大。2025 年工程师的平均任期在两到三年左右，平均跳槽者仅通过变动工作就能获得两位数的加薪。对于一个处于溢价翻倍市场中的专家型工程师来说，这笔账算得很清楚。他们不需要感到不快乐才会离职，他们只需要算算算术。

如果你的薪酬评审周期是年度的，而你的留才策略是等到有人辞职的那周才给出反制邀约（counteroffer），那你已经输了。反制邀约是最昂贵且最低效的调薪形式：它比主动加薪成本更高，它传达了你只有在受到威胁时才会支付市场价的信号，而且它通常只是延迟了离职，而不是阻止了离职。根据市场情况为 AI 工程定价——并采用与市场变动速度相匹配的更新频率——比在核心人才离职后进行“考古项目”要划算得多。

离职：一场为期六个月的考古工程

以下是导致 AI 工程师离职比传统工程师离职后果更严重的本质原因。当一名后端工程师离职时，他们的工作大部分体现在代码库中。代码经过版本控制、评审，并且至少通过其自身的结构实现了部分文档化。新来的工程师可以阅读并理解它。

但当一名提示词（Prompt）专家离职时，他们的大部分工作成果都留在记忆里。提示词虽然在仓库中，但其背后的“原因”却不在。评估（Eval）用例存在，但每个用例所防范的故障模式却没有记录。评判器（Judge）有评分标准，但校准历史——什么时候调优了什么，以及为什么要调优——却消失了。接手的工程师继承了一个可以运行但不知为何能运行的系统，这意味着他们无法安全地对其进行修改。离职后的第一次模型迁移变成了一场法医学式的溯源调查：某些环节断裂了，却没人知道它破坏的是团队刻意构建的保证，还是团队从未注意到的意外。

这就是“巴士系数”（Bus Factor）问题，而 AI 系统由于知识异常含蓄，这一问题显得尤为严峻。解决方法并非靠个人英雄主义，而是将机构知识视为一种产物，并应用与代码同等的评审纪律：

• 每一个提示词都应带有文档字符串（Docstring）。 这不是在描述它做了什么——代码差异（Diff）已经体现了这一点——而是陈述意图，并列出塑造其当前形式的事件或评估失败案例。下一名工程师在决定删除某句话之前，应该能够读懂它存在的原因。
• 每一个评估用例都应带有溯源信息（Provenance）。 这是一个元数据块，标明了它所防范的故障模式以及产生该用例的特定事件。没有溯源信息的用例在未来的清理中会被删除，并随之带走一份隐形的保障。
• 每一个评判器都应带有版本化的评分标准（Rubric）和校准日志。 记录标准何时被更改、由谁更改，以及更改前后的校准情况。如果没有这些记录，评判器的漂移是不可见的。
• 每一个提示词仓库都应有一个 CODEOWNERS 文件并指定一名继任者。 这里指的不是原作者，而是第二个实际参与过变更评审并能回答问题的人。如果该文件只列出了一个人，那么这就是你被白纸黑字记录下来的“巴士系数”风险。

这些都不依赖于原工程师的留任。这正是核心所在。目标是将一次离职从一场为期六个月的考古工程，转变为一次为期三周的交接。

在知识固化之前进行轮转

文档纪律可以减少离职带来的损失。但它本身并不能降低知识集中在一个人身上的“概率”——因为编写提示词的人积累背景信息的速度自然比他们记录下来的速度要快。集中化是默认状态，你必须主动去对抗它。

杠杆在于有意识的轮转。在一名工程师对提示词或评估层面的掌控使其知识变得不可逆地成为核心支撑之前，应该让第二名工程师参与实际工作：评审重要的代码改动、负责一部分评估套件、在第一名工程师作为备份而非主导的情况下执行模型迁移。这并非没有成本——短期内速度会变慢，就像结对编程在短期内会变慢一样——但这是唯一能将巴士系数提高到 1 以上的方法。

对待单一负责人维护的提示词领域，应像成熟代码库对待由单一作者贡献超过 80% 的文件那样：将其视为已标记的风险，显示在仪表盘上，并由负责人负责降低这一比例。在关键人员离职后能幸存下来的团队，并不是那些拥有最完善文档的团队，而是那些在有人提出离职申请之前，知识就已经存在于两个大脑中的团队。

领导力视角的重塑

这里的大部分失败都可以归结为一个范畴错误：将 AI 工程师视为软件工程师的一个子类，只是碰巧引入了不同的 SDK。在这种框架下，现有的晋升阶梯、薪酬范围和知识沉淀实践似乎都是足够的，因为它们对软件工程师有效，而这“仅仅”也是一名软件工程师。

事实并非如此。这是一个拥有自身晋升信号的角色——通过衡量的评估效果来实现微小改动、在迁移中幸存下来的评判器校准、捕获了回归错误的评估套件、AI 维度是根本原因的复盘分析。它拥有自身的市场动态，其溢价正以每年翻倍的速度增长。它还有自身的知识保存问题，因为它的工作更多地存在于记忆中，而非仓库里。

如果一个组织用通用的晋升阶梯对待这个角色，就会不断晋升那些工作成果“看起来很美”的工程师，而不断流失那些通过 30 行改动默默支撑起产品的工程师。半衰期并不是自然规律，而是一个为不同工作性质而设计的系统所产生的可预见结果。这周给你的提示词专家发消息的猎头并不是问题的根源，他们只是你刚好能看到的那部分问题。