新员工打开入职文档。文档指向了十一个月前的一个服务架构图、一个最后更新于十月的名为 “我们的 LLM 技术栈” 的 Confluence 页面，以及一个 “我们使用的模型供应商” Notion 表格。这些文档都没有告诉他们哪个提示词是针对哪种失败模式优化的，哪些评估案例是在哪次事故后添加的，当模型从 4.5 升级到 4.6 时哪个评判模型被重新校准了，或者为什么支持代理的系统提示词有一段谁都不敢动的奇怪的三行前导内容。入职两周后，他们提交了一个 “小的提示词清理” PR，删除了这段前导内容。评估套件通过了。不到一天，生产环境的准确率下降了四个百分点。
标准的新员工入职指南 —— 阅读架构文档、配置电脑、在第二周前完成第一个 PR —— 是为加入服务端的工程师设计的。AI 工程师加入的是一种不同的制品。他们要编辑的不是某个主任工程师写的 5000 行 Go 服务；而是一个经历了 11 次事故和 17 次评估驱动重写的 30 行提示词，而这 30 行代码的意义只存在于团队中两个人的脑子里。你的入职文档无法捕捉到这些，而尝试写一份更长的文档是错误的修复方案。
正确的修复方案是一个上手序列，让新员工置身于流动的组织知识之中 —— 在评估评审中、在受监督提交的提示词 diff 中、在端到端负责评判模型校准中 —— 这样他们就能像资深工程师那样学习：通过观察，通过在安全的方式下失败，以及通过亲自构建一小块功能。下面是一份 90 天指南，它将 AI 工程师的入职视为与服务端入职完全不同的学科，其里程碑针对的是 AI 工程师在实际工作中接触的真实制品。
为什么架构图会骗人（以及为什么你会停止更新它）
服务端入职之所以有效，是因为服务具有能够经受时间考验的形态。一个服务的 API 契约、其数据模型、其部署拓扑 —— 这些都是图表可以捕捉且文档可以描述的慢速移动的制品。AI 功能在关键层面上完全没有这种稳定性。有趣的状态存在于提示词仓库、评估套件、评判模型提示词、模型版本锁定以及事故回放数据集中。所有这些的编辑速度都很快，使得书面文档在几周内就会过时。
Meta 的工程团队在代码库层面也遇到了类似的问题，当时他们试图给 AI 智能体足够的上下文，使其在内部单体仓库（monorepo）中发挥作用。他们的解决方案很有启发性：他们构建了一个由一群专门的智能体维护的上下文文件预计算层，并定期进行验证运行以检测陈旧引用并自动修复偏差，因为他们发现衰减的上下文比没有上下文更糟糕。这个教训具有普适性 —— 一份指向已不存在的提示词的六周前的入职文档，比没有文档更有害，因为新员工信任并根据它采取行动。
因此，你应该维护那些衰减缓慢的入职制品。评估套件的形态是稳定的。提示词在仓库中的组织模式是稳定的。作为流程的评判模型校准结构是稳定的。那些不稳定的东西 —— 提示词的内容、具体的评估案例、当前的评判标准 —— 应该通过阅读仓库中的实时制品来学习，而不是通过阅读一份没人同意持续更新的文档副本。
这种重构之所以重要，是因为它告诉了你入职文档 应该 包含什么：指针、流程和出处，而不是快照。文档告诉新员工如何找到提示词，评估套件是如何构建的，以及事故日志在哪里。这些制品的当前状态应从仓库和负责它们的人那里读取。
第 1 到 30 天：先观察，再动手
前 30 天应该比服务端入职建议的节奏更慢。后端团队的新员工通常在第一周或第二周就会合并他们的第一个 PR —— 通常是配置微调、文档修复或小的重构。在这里，这样做是危险的。一个在内化提示词的失败模式历史之前就推送 “小的提示词清理” 的新员工，相当于在 AI 领域重构一个测试没有完全覆盖其行为的函数。
30 天的目标是理解，而不是贡献。具体来说，这意味着：
观察至少三次评估评审。在这些会议中，团队会查看最新的评估运行结果，决定哪些回归是重要的，并分配负责人。参加两三次这样的会议可以教会新员工团队如何区分 1 个点的随机波动与关键的回归，实践中 “这看起来像是评判模型的问题，而不是模型的问题” 听起来是怎样的，以及哪些评估被视为预警，哪些被视为全面测试。
阅读一个团队拥有的提示词在过去六个月的仓库提交历史。不是所有的提示词 —— 而是深入研究一个提示词。每个提交信息理想情况下都应该指向促成它的失败模式或评估增量。如果提交信息没有说明，新员工的第一个书面产出应该是一个回顾文档，通过 Slack 讨论、评估日志和与原作者的对话，重构每个非微不足道的提交背后的 原因 。这份文档仅供他们自己使用。
参与一周的值班轮换。大多数 AI 功能的失败方式都不会触发已有的告警 —— 流量评估下降四个百分点、评判模型校准在模型版本升级后出现偏差、下游功能开始引用一个幻觉事实。观察值班工程师排查这些问题可以教会新员工在这个技术栈中 “损坏” 到底是什么样子的，而这很少表现为堆栈跟踪。
这些都不会产生合并的 PR。这就是重点。第 30 天的产出是一个新员工，当在评审中看到提示词 diff 时，他们能提出正确的问题 —— “我们是否在长上下文切片上重新运行了回归评估”、“评判模型在这次提示词更改中是否稳定”、“这次提交是否引用了我们需要添加评估案例的事故”。如果他们能问出这些问题，他们就准备好进行引导式贡献了。如果不能，再观察两周比一次糟糕的合并成本更低。
第 31 到 60 天：指导性贡献与三项必需的交付物
第二个三十天从观察转向受监督的生产工作。新员工应该交付三项特定的产出物，每一项的选择都是为了迫使他们接触 AI 技术栈的不同层面，并为每项任务配备一名熟悉该领域的资深评审者。
第一项是受监督下的 Prompt 差异（Prompt diff）。他们选择——或者被分配——一个 Eval 表现陷入瓶颈的 Prompt，他们的任务是提出、评估并发布一个能提升相关指标的单一变更。约束条件是他们必须运行完整的 Eval 套件，而不仅仅是他们认为正在优化的那一部分，并且必须在 PR 描述中解释他们预期会改变什么以及实际改变了什么。这个练习的目的不在于 Prompt 变更本身；而在于让他们切身体会到，一个“无害”的 Prompt 修改是如何同时让 Eval 数字向三个不同方向变动的。
第二项是针对真实事故添加的 Eval 案例。团队可能积压了一堆从未被编码为 Eval 案例的事故——比如 3 月份支持代理幻觉出了退款政策，4 月份摘要功能丢失了用户的语言环境偏好，5 月份搜索 RAG 引用了过时的文档。新员工挑选其中一个，重构输入，编写 Eval 案例，验证它在产生事故的系统版本上失败，并确认它在当前版本上通过。这从真正重要的角度锻炼了 Eval 套件的使用能力：不是“我如何运行 Eval”，而是“我如何编写能够抓住那些没人发现的问题的 Eval”。
第三项是端到端的 Judge 校准（Judge calibration）。他们挑选一个已经上线一段时间的 Judge，抽取大约一百个左右的生产追踪（production traces），根据当前的 Judge 评分标准进行人工打分，计算人工标签与 Judge 自动标签之间的相关性，并确认 Judge 是否仍然保持一致，或者提出重新校准。广泛引用的目标——Judge 与人工标签之间的相关系数高于 0.7——应该是他们检查的基准。这个练习最能可靠地将一名强大的服务工程师转化为一个“懂” AI 工程的人，因为它迫使他们面对这样一个事实：对他们的工作进行评分的系统本身也是一段可能出错的软件。
到第 60 天，新员工在监督下已经接触了 Prompt 仓库、Eval 套件和 Judge 层。通过复现事故，他们掌握了失效模式的实战知识。他们已经准备好承担所有权（Ownership）了。
第 61 到 90 天：对窄界面的所有权 第三个月从受监督的贡献转向对系统一小部分的真正所有权。目标不是让新员工负责一切，而是让他们端到端地负责某件事，让他们暴露在定义 AI 工程的维护循环（maintenance loop）中，而不仅仅是构建循环（build loop）。
所有权的一个好目标是单个 AI 功能或具有定义明确的 Eval 界面的单个 Judge。新员工成为指定的负责人：他们负责该功能 Eval 回归的轮值，评审涉及该功能的 Prompt 变更，当模型版本升级需要重新校准时，他们是第一联系人，并且他们是下一轮 Eval 案例添加的作者。范围应该足够窄，以便他们能在脑海中掌握完整状态，同时又足够宽，使他们在剩下的三十天里至少遇到一次模型迁移、一次 Judge 漂移和一次生产事故。
这也是新员工产出第一份团队赖以生存的机构知识的时候。最实用的形式是附在他们现在拥有的功能或 Judge 上的简短文档——不是通用的文档，而是特定于功能的文档，列出每个 Eval 案例、该功能经历过的每一次事故，以及每一个值得理解的 Prompt 历史决策。这不是对代码库的说明；而是对代码库背后的“为什么”的说明，而这正是代码库中不存在的部分。如果你在第 90 天还写不出这份文档，说明你钻研得不够深；如果你能写出来，你就将原本只存在于一名工程师脑中的核心机构知识转化为了存在于两人脑中的知识。
什么会破坏这个方案（以及如何察觉） 最常见的失效模式是招聘经理将 AI 工程师的入职培训视为服务入职培训加上一个关于 LLM 的 Coursera 链接。新员工被告知阅读架构文档，搭建开发环境，并在第一周发布一些小东西。他们照做了，Prompt 退化了，团队将其视为一次学习经历，而潜在的成长路径问题从未被点名。六个月后，同一名工程师仍在询问该在哪个片段信任哪个 Judge，因为从来没有人让他深入研究过。
第二种失效模式是在新员工完成受监督贡献阶段之前，就让他并行负责多个功能。这种迹象出现在第 45 天的状态更新中，新员工正在修改三个不属于他的 Prompt，而他对其中任何一个都没有完整的 Eval 历史背景。把他们拉回到一个任务上。第 45 天的速度无关紧要；他在第 180 天的状态才是最重要的。
第三种失效模式是团队本身没有这个方案所假设的 Eval 评审、Prompt 历史纪律或事故到 Eval 案例的流水线。在这种情况下，新员工的入职就变成了对团队自身缺陷的诊断。这是一个有用的诊断——如果新员工因为基础设施不存在而无法执行此方案，那么团队下个季度的计划就已经为他们定好了。
文档腐化不是问题的核心 新员工入职文档在六周内就开始失效，其原因并非因为懒惰。而是因为文档所记录的底层交付物 (artifacts) 的更迭速度超过了任何文档能追踪的范围，而任何在 AI 工程领域取得成功的团队都会保持这种节奏。解决方案并不是写一份更好的文档。解决方案是让新员工融入处理这些交付物的“流程”中——包括评估审查 (eval reviews)、受监督的 Prompt 差异对比 (prompt diffs)、评判员校准 (judge calibrations)、以及对细分领域的端到端所有权——并接受这样一个事实：组织知识将存在于员工的大脑和工作代码库中，而不是没人有时间更新的 Confluence 页面上。
那些处理得当的团队所聘用的 AI 工程师，在第 90 天时就能在轮岗中产生净正收益，编写出能捕捉到真实回归问题的评估用例，并产出功能级的溯源文档，从而让下一位新员工的上手速度比他们自己更快。而处理不当的团队，其聘用的 AI 工程师在第 90 天时仍在询问哪些 Prompt 更改是安全的，而关键的组织知识将继续留存在那两个招聘人员每周二都会打电话“挖角”的核心人员身上。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
