3 篇博文 含有标签「team-process」

新员工打开入职文档。文档指向了十一个月前的一个服务架构图、一个最后更新于十月的名为 “我们的 LLM 技术栈” 的 Confluence 页面，以及一个 “我们使用的模型供应商” Notion 表格。这些文档都没有告诉他们哪个提示词是针对哪种失败模式优化的，哪些评估案例是在哪次事故后添加的，当模型从 4.5 升级到 4.6 时哪个评判模型被重新校准了，或者为什么支持代理的系统提示词有一段谁都不敢动的奇怪的三行前导内容。入职两周后，他们提交了一个 “小的提示词清理” PR，删除了这段前导内容。评估套件通过了。不到一天，生产环境的准确率下降了四个百分点。

标准的新员工入职指南 —— 阅读架构文档、配置电脑、在第二周前完成第一个 PR —— 是为加入服务端的工程师设计的。AI 工程师加入的是一种不同的制品。他们要编辑的不是某个主任工程师写的 5000 行 Go 服务；而是一个经历了 11 次事故和 17 次评估驱动重写的 30 行提示词，而这 30 行代码的意义只存在于团队中两个人的脑子里。你的入职文档无法捕捉到这些，而尝试写一份更长的文档是错误的修复方案。

翻开任何一个运行了一年的生产系统提示词（system prompt）的 git blame，你都会发现一些工程团队不愿承认的事实：这个文件有三个作者，而他们对“变更”的定义各不相同。上个月重构指令块的工程师将提交记录标为“无功能变更，仅为了清晰起见重新排序”。每季度读一次该文件的产品经理会这样描述同样的差异：“你改写了语气——客户会察觉到的”。运行回归测试套件的 ML 工程师会说：“你搞坏了第三个少样本示例（few-shot example），从那以后评估结果（eval）就一直变红了”。

这三者都是正确的。提示词同时具备代码、规范和超参数的属性。任何长期交付 AI 功能的团队都会发现，该文件的提交历史是一场缓慢进行的三方署名权争议，CODEOWNERS 无法捕捉到这一点，diff 查看器也无法体现出来。

我最近合作的一个团队失去了一位资深机器学习工程师。两周后，每个 PR 的评估套件（eval suite）依然全绿——847 个案例全部通过，裁判一致性（judge agreement）达到 92%。六周后，一位客户发现了一个回归问题，而这个问题本该被“支持质量”桶里的第一个评估案例捕获。当团队进行调试时，没人能解释为什么要写那个案例，它本该捕获哪种失败模式，或者为什么裁判提示词（judge prompt）是按 1–4 分评分而不是二元评分。那个案例依然通过了，但它并没有测试任何有人能说清楚的东西。

这就是评估的公交车系数（eval bus factor）：一种无声的失败模式。在这里，决定 AI 功能“正确”含义的人，也是策划测试用例、校准裁判模型并吸收了大脑中每一个隐含标注权衡的人。当他们离职时，评估套件虽然依然保持绿灯，但却不再能产生可靠的发布/拒绝信号——因为没有其他人能扩展它、调试不稳定的裁判，或评估新的失败模式是否属于测试集。