AI 入职差距：为什么工程师无法学习他们无法测试的东西

一名新工程师加入了一个重度依赖 AI 的团队。入职第三天，他们发现系统指令中有一个措辞别扭的双重否定。看起来像是个 bug。于是他们把它清理了——这是任何合理的人都会做的小小优化。两小时后，一条关键流水线的客户端分类准确率从 91% 跌至 74%。没有人知道原因。

这种情景以某种形式发生在几乎每一个基于 LLM 构建系统的团队中。新工程师并不粗心。那个提示词看起来确实有问题。但那个双重否定在某种意义上是"承重墙"——只有写下它的人才真正理解，而那是在经过数周实验之后才领悟到的。他们从未把这种理解写下来。

这就是 AI 入职差距：AI 代码库表面上的行为与实际行为之间的鸿沟，以及为什么这个鸿沟在有人掉进去之前是不可见的。

为什么 AI 代码库抵制传统调试

当传统代码库的资深工程师告诉新人"不要在运行完整测试套件之前动 X"时，这个建议是可以执行的。测试套件几分钟内就能运行完。它要么通过，要么不通过。如果某人的改动破坏了什么，git bisect 可以定位到具体的提交。因果关系是可追溯的。

对于基于 LLM 的系统，这些方法都无法干净地运作。

根本问题在于不确定性。相同的提示词、相同的模型、相同的零温度设置，在不同运行中可能产生截然不同的输出。这不是 bug——这就是这项技术的工作方式。但它让"我的改动是否破坏了什么？"这个基本工程问题变得出奇地难以回答。单次测试运行不能作为证据。即使完美通过也不意味着你的改动是安全的。

这就产生了所谓的"无法二分的故障"问题。当一个生产 LLM 系统开始出现异常行为时，回归可能是由以下原因引入的：

• 提示词变更（最明显的候选，但不总是正确的）
• 模型版本升级，改变了边缘情况下的行为
• 用户输入分布的变化
• 上下文长度变化导致早期指令的权重不同
• 提示词组件之间的交互效应，在单独测试时不可见

正在调试回归的新工程师通常会检查显而易见的事情——有人改了提示词吗？有人改了代码吗？——而错过不那么明显的原因。他们还没有建立起这样的心智模型：知道模型在长对话之后解释指令的方式与对话开始时不同。他们不知道你的 RAG 系统的检索阈值是专门为了补偿特定模型处理不确定性的怪癖而调整的。他们不可能知道，因为那些知识在代码库中无处可寻。

部落知识问题最为严峻的地方

每个工程组织都会积累部落知识——关于事物为何如此的隐性理解，存在于个人头脑中而非文档里。AI 工程团队以异常高的速度积累这类知识，因为提示词开发的迭代循环是快速、非正式且不留痕迹的。

当开发者写了一个函数并且它能正常工作时，测试覆盖率告诉你它能工作。当开发者完善了一个提示词并且它能正常工作时，证据通常是"我运行了几次，看起来不错"。导致最终提示词的推理过程——失败的变体、发现的故障模式、那些反直觉但有效的措辞——很少被记录下来。

考虑一下新工程师实际上需要知道什么才能安全地处理 LLM 流水线：

• 为什么系统提示词使用这种特定结构而不是更自然的结构？
• 提示词的哪些部分对改写敏感，哪些不敏感？
• 开发过程中发现了哪些故障模式，当前提示词是如何解决它们的？
• 是否存在已知的模型可靠崩溃的边缘情况，这是经过深思熟虑的权衡吗？
• 这个提示词是针对哪个模型版本进行调优的，不同版本之间的行为差异有多大？

这些信息都不在代码里。代码显示了提示词是什么。它对于它被测试了什么、它替换了什么、或者如果你改变它会发生什么，什么都没说。

这比传统软件中的部落知识问题更为极端，因为"为什么"通常是经验性的，而不是逻辑性的。你无法通过推理来理解为什么某种特定的提示词措辞有效——你必须在多次运行中观察它。如果那个观察从未被记录，它就消失了。

加载中…