AI 工程师的前 90 天：一份在六周文档失效期内依然有效的入职指南

新员工打开入职文档。文档指向了十一个月前的一个服务架构图、一个最后更新于十月的名为 “我们的 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 天：指导性贡献与三项必需的交付物

加载中…