入职缺口：为什么新工程师需要三个月才能上手 AI 技术栈

一个拥有八年经验的后端工程师加入了你的团队。在一般的代码库中，到第三周他们就能开始交付功能了。但在 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 变成了坟场，隐性知识依然留在同样那两颗脑袋里。

真正缩短入职适应期的产物

加载中…