一个拥有八年经验的后端工程师加入了你的团队。在一般的代码库中，到第三周他们就能开始交付功能了。但在 AI 层面，他们仍然在私信里问问题，而且你能预测出他们在问哪两位资深工程师。入职三个月后，他们终于被信任可以修改系统提示词（system prompt）了 —— 这并不是因为提示词有多难，而是因为没有人能告诉他们，哪些评估（evals）能捕捉到退化（regression），而哪些会直接放行错误的输出。
这在通常意义上并不是招聘问题或文档问题。AI 代码库带有一种隐藏的领域知识税（domain-knowledge tax），这种税不会出现在代码审查中，不会出现在 README 中，静态分析器也无法察觉。这笔税体现在入职时间、对同一批人的重复提问，以及最终团队悄悄分化为“能动它的人”和“其他所有人”。
这种成本并非虚构。处于这种境地的资深工程师每周最终会花好几个小时回答同样的一组问题：为什么检索是这样过滤的，这个追踪仪表盘（trace dashboard）意味着什么，哪个 eval 对哪种行为起支撑作用。他们实际工作的队列因此积压。新员工失去了动力。当那两位资深工程师中的一位休假时，那一周提示词就不会被修改。
AI 代码库的隐藏课程
一个传统的服务端代码库如果你仔细阅读，它是自解释的。函数名、类型签名和测试描述了代码的功能以及如何扩展它。新工程师可以依靠代码作为规范，并将测试套件视为契约。他们提交 PR，CI 流水线标记出他们破坏的部分，他们修复它，然后交付。
AI 代码库并非如此运作。系统提示词是一段自然语言，其语义无法通过阅读一眼看穿。检索层（retrieval layer）的过滤器有着只存在于某些人脑海中的理由。Eval 套件包含的断言看起来很合理，但却是针对六个月前的模型版本校准的。追踪仪表盘显示的字段没有人命名，阈值也没有人记录。
更糟糕的是，这些知识中很大一部分之所以正确，仅仅是因为过去做出的决定，而这些决定后来被遗忘了。检索过滤器的存在是因为之前的模型在访问某种文档类型时泄露了个人身份信息（PII）。Eval 阈值之所以宽松，是因为收紧它会破坏一个从未被记录下来的客户流程。系统提示词中有一条看起来很奇怪的指令，是因为在上个季度的第 14 周删除它导致了功能退化。
盯着这段代码的新工程师无法推断出任何这些信息。他们看到的是一段英文和一个配置文件。赋予这些产物意义的逻辑是不可见的。所以他们只能提问。而唯一能回答的人，是那些在做每一个决定时都在场的人。
为什么文档解决不了问题
本能的反应是“我们应该写更多文档”。这在精神上是正确的，但在执行上几乎总是错误的。写出来的文档往往倾向于描述架构：Agent 循环的图表、工具列表、关于检索如何喂给提示词的解释。这些文档很有用，但并不是新工程师所缺失的东西。新工程师可以阅读代码并重建架构。
新工程师缺失的是为什么 ：为什么上个季度这个提示词修改被拒绝了，为什么这个 eval 案例是不容妥协的，为什么这个工具从目录中删除了且再也没有加回去。这是决策历史，而不是架构。大多数团队不写决策历史，因为在做出决定的那一刻这感觉像是一种额外开销 —— 决定对房间里的人来说显而易见，写下来感觉像是在向虚无解释自己。
六个月后，“虚无”变成了新工程师，而那个决定不再显而易见。产物依然留在代码中。推理过程已经挥发。
另一种失败模式是试图在单一文档中解释整个系统的 Wiki 页面。这些页面开始时很全面，一旦代码发生偏移就会产生误导。不到一个季度，一半的 Wiki 都是错的，新工程师无法分辨哪一半是错的，而资深工程师因为被误导过而不再信任 Wiki。Wiki 变成了坟场，隐性知识依然留在同样那两颗脑袋里。
真正缩短入职适应期的产物
有效的入职产物具有共同的特征：它们的范围足够窄以保持准确，与代码结合得足够紧密以至于在 PR 中能看到偏移，并且围绕新工程师实际需要做出的决定来构建。
Eval 运行手册（Runbook）导读。 一份挑选 5 到 10 个 eval 案例并逐一解释的文档：它捕捉了什么失败模式，什么样的更改会导致它失败，以及失败时的正确应对措施是什么。这比新工程师读不懂的 300 个案例的 eval 套件更有用。它教会他们如何思考这套套件，而不只是如何运行它。运行手册放在 eval 文件旁边，并在案例添加或删除时更新。
带有“为什么”的提示词更新日志。 每一个有意义的提示词修改都附带一段说明：更改了什么，解决了什么退化或能力问题，哪些 eval 验证了它。琐碎的编辑（拼写错误、格式）不需要记录。原则是在修改的那一刻、推理还新鲜的时候写下记录，而不是作为事后的补齐工作。做到这一点的团队会发现，当资深工程师试图回忆为什么会有某条特定指令时，更新日志成了他们 grep 的首选。阅读它的新工程师可以在一个下午吸收六个月的决策历史。
走读真实失败案例的追踪回放（Trace Replay）。 挑选上个季度的一个生产事故。写出追踪过程，叙述每一步显示的内容，指出模型失控的确切时刻，并解释团队是如何诊断和修复它的。这教会新工程师如何阅读仪表盘，哪些字段重要，以及真实的失败模式是什么样的 —— 这些单靠仪表盘本身是无法看出来的。
一个限定范围的首次提示词修改。 找一个范围小、边界清晰、有明确 eval 覆盖的提示词更改。在入职的前两周交给新工程师。重点不在于修改本身，而在于经历整个工作流的体验：阅读 eval 案例、进行更改、观察套件运行、解释输出、提交 PR。经过这次练习，新工程师在资深工程师已经验证路径安全的环境下，至少触碰过表面的每一个部分。
这些产物有一个重要的共同点：它们针对特定的决定或工作流，这意味着它们比泛泛的 Wiki 页面保持准确的时间更长。它们也直接构建在 eval 套件和追踪仪表盘之上，这意味着它们强化了团队已经在使用的工具，而不是与之竞争。
AI 代码库的人机工程学：一种招聘杠杆 大多数团队使用的视角是“我们需要更快地入职新工程师”。而能产生更好行为的视角是“AI 代码库的人机工程学决定了我们是否能招到 AI 工程师”。一个只有两个人能修改 Prompt 的代码库，其 AI 功能覆盖面无法在不增加这两个人负担的情况下增长，而人是无法线性扩展的。
这也会影响员工留存。如果新入职的工程师三个月都无法交付代码，他们会在心里默默质疑自己是否真的被需要参与 AI 工作。资深工程师也会形成类似的看法，质疑新员工是否有能力做出贡献。这两种观点往往会逐渐固化。最终团队会演变成：一个规模很小的 AI 核心小组和一大群绕过 AI 开发的工程师——这正是关于“巴士系数（Bus Factor）”的文献多年来一直在描述的双层结构。
记录隐性知识的团队能将巴士系数从 2 提升到这样一种状态：团队中的任何工程师都有可能接触 AI 技术栈。这并不是对质量的妥协。评估套件（Eval suite）依然把控着正确性。追踪仪表板（Trace dashboard）依然能发现回归问题（Regressions）。改变的是这些“关卡”对更多人来说是清晰易懂的，因此更多人可以安全地通过它们。
记录决策的自律 这一切最难的部分是文化转型，而非工具。每次修改 Prompt 时写一段笔记，在那一刻感觉像是额外的开销。在处理完重大事故后记录追踪回放（Trace replay），对于已经发布了修复补丁的团队来说，感觉像是额外的工作。随着评估套件的演进，维护一份 Eval-runbook 的操作指南，感觉像是枯燥的文档杂事。
那些将这种自律内化的团队，往往是曾经被反面做法伤害过的。他们目睹过资深工程师离职，导致团队在一个月内无法安全地修改 Prompt。他们也曾让新员工入职，却花了五个月而不是三个月，仅仅是因为没人写下哪些是核心评估案例。他们曾因评估标准失准导致回归漏洞，进而失去客户，而团队中没人有足够的背景信息在代码审查中发现这一点。
在经历过足够多的这类事件后，在修改时顺手写笔记就不再是负担，而是为了维持一个能让两人以上维护的 AI 功能模块所必须付出的成本。这些交付物不再是可选的。代码库不再是少数人的私密语言，而是成为了团队可以共同拥有的资产。
这种转型并不光鲜亮丽，也没有任何框架能直接实现它。但完成转型的团队会发现，下一位 AI 工程师的上手时间从 15 周缩短到了 5 周，资深工程师找回了自己的下午时光，而系统提示词（System Prompt）在周五也可以安全地进行修改。这些才是值得优化的结果，而一切都始于那项枯燥的工作：在你还记得的时候，写下你做出决策的原因。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
