AI 工程团队的 OKR——怎么设才有意义

适读人群：AI 工程团队的 Leader，参与制定 OKR 的工程师 | 阅读时长：约12分钟 | 核心价值：用真实经历说清楚 AI 团队 OKR 的特殊挑战，以及什么起了作用、什么是形式主义

去年年初，我们团队要交 Q1 的 OKR。

我坐在那里盯着屏幕，第一次意识到，我不知道怎么给一个 AI 工程团队设有意义的 OKR。

传统工程团队的 OKR 有现成模式：交付 XX 个需求、系统可用性 99.9%、接口响应时间 < 200ms、代码覆盖率 > 80%……这些指标很客观，很好量化。

但 AI 工程团队呢？

我们的核心工作是：把 RAG 系统的回答准确率从 70% 提升到 85%，探索 Agent 在某个业务场景的可行性，把模型调用成本控制在预算内。

这些目标里，很多不确定性不是因为团队不努力，而是因为我们在做的东西本来就不确定。RAG 准确率能不能到 85%，不只取决于团队的工作质量，还取决于任务的难度、数据的质量、模型的能力。

那次写 OKR 写了三个版本，每个版本交出去都觉得哪里不对。

这篇文章是我把那次经历和后续两年的实践梳理一遍，说说我觉得什么有用、什么是面子工程。

AI 团队 OKR 的三个特殊挑战

挑战一：效果难以量化，而且"量化了"不等于"有意义"

这是最根本的挑战。

LLM 应用的效果评估本身就是个难题。准确率这个数字，取决于你怎么定义"准确"，取决于你用什么测试集，取决于谁来标注。两个团队都说"准确率 80%"，这个数字可能完全不可比——一个用了严格的人工标注测试集，另一个用了半自动生成的测试集，数字一样，含义差很远。

OKR 里写"RAG 系统准确率达到 85%"，看起来很量化，但如果测试集和评估方法没有定义清楚，这个 85% 可以通过"换一套更容易的测试集"来实现，而不是真正的系统提升。

挑战二：外部变量太多，团队努力和结果之间的因果不清晰

传统工程里，性能优化的结果相对可预测：你投入 X 的工程时间，产出大约在一个估计范围内。

AI 工程里，外部变量多到惊人：

• 模型供应商更新了模型版本，你的系统效果可能突然变好或变差
• 用户的使用方式发生了变化，准确率指标的分布跟着变
• 业务需求扩展，新加进来的知识库文档质量参差不齐，把整体指标拉低了

在这种情况下，OKR 达成或者没达成，和团队的实际工作质量之间的关系，经常不是线性的。

挑战三：技术债和新功能的优先级，在 AI 团队里特别难平衡

AI 工程的技术债不只是烂代码，还有：过时的 Prompt、没有更新的知识库、积压的评估任务、没有写的评估管道……这些债不还，系统会慢慢腐化，但它们在 OKR 里很难体现，因为"维护系统健康"这件事不像"新功能上线"那样有明确的完成标志。

我设过的几个 OKR：什么起了作用

说几个具体的，有好的有坏的。

OKR 案例一（失败）："RAG 回答准确率提升到 85%"

这是我写的第一个 OKR，后来复盘是错的。

错在哪里：没有定义评估方法，导致在 Quarter 结束时，团队内部关于"是否达成目标"有争议。有人说"测试集上 84%，算没达到"，有人说"用户满意度明显提升，实质上达到了"。这种争议本身就说明这个 OKR 设计有问题。

另一个错误：这个目标把结果和过程绑死了，但团队的可控部分（工程实现）和不可控部分（基础模型能力、数据质量）没有分开。

OKR 案例二（部分成功）："建立 RAG 评估体系，每两周产出评估报告"

这个目标的好处是：完全在团队控制范围内，而且是一个过程指标——不依赖最终效果，只要团队做了这件事就算达成。

问题：这个 OKR 有"面子工程"的风险。你可以每两周产出评估报告，但报告质量很差，对实际改进没有指导价值。

后来我在这个基础上加了一个约束：评估报告必须在下次迭代里有至少一个可操作的改进建议被实际采纳。这个约束把过程指标和结果关联起来，减少了形式主义的空间。

OKR 案例三（有效）："把模型 API 月成本控制在 XX 元以内，同时维持核心指标不下降"

这是我觉得最接近有意义的 AI 团队 OKR 形式。

• 它是完全可量化的（账单数字不会说谎）
• 它有条件约束（"不能为了省钱牺牲效果"）
• 它完全在团队控制范围内（可以通过缓存策略、模型路由、Prompt 优化等手段实现）

最终这个 OKR 我们达成了，而且过程中做的工程优化（语义缓存、模型分层路由）是真实有用的工程工作，不是面子工程。

OKR 案例四（有效）："上线 X 功能，并在上线后 30 天内完成效果评估，给出下一步迭代方向"

这个 OKR 把"交付"和"评估"绑在一起，不允许只上线不管效果。

在 AI 工程里特别有价值，因为很多团队有一个坏习惯：上线了就结了，等到出问题才回头看。把评估作为上线 OKR 的一部分，强制了这个回路的闭合。

几条经验性原则

整理了几条，不是教条，是我踩过坑之后的判断：

原则一：OKR 的分母必须定义清楚

"准确率 85%"——谁测的？用什么测试集？谁来标注？多少条样本？

如果写进 OKR 的指标没有清晰的测量方法定义，这个 OKR 不管写什么数字都是假的。

原则二：分清"团队可控的"和"不可控的"

一个实用的检验方式：如果团队所有人都全力以赴，这个 KR 能达成吗？如果答案是"不一定，因为还依赖外部模型的能力"，那这个 KR 需要重新拆解。

把不可控的部分变成可控的：不是"准确率达到 85%"，而是"做完以下工程改进（列出具体工作），并评估每项改进对准确率的实际影响"。

原则三：过程指标和结果指标要配合使用

纯结果指标（准确率 85%）有可控性问题，纯过程指标（做了哪些工作）有面子工程风险。

最有效的设计是：用过程指标描述团队承诺做的工作，用结果指标描述我们期望看到的影响，同时明确两者之间的因果假设。

比如：

• 过程 KR：完成混合检索的实现和测试
• 结果 KR：检索召回率从 70% 提升到 80%（假设混合检索能带来约 10% 的提升，基于之前的实验结论）
• 因果假设：明确写出来，如果结果没达到，回头检验假设，而不是直接判断团队没努力

原则四：把"系统健康维护"显性化

AI 工程里有大量不在任何 OKR 里的维护工作：Prompt 版本管理、知识库更新、模型版本迁移、评估管道维护……

如果这些工作不出现在 OKR 里，它们的优先级就会一直被新功能压着，直到系统腐化到出了大问题。

我的做法是：在每个季度的 OKR 里，保留 20-30% 的 capacity 专门用于这类工作，在 OKR 里明确体现出来。不是拆成具体的 KR，而是作为一个原则写进来："本季度确保 XX% 的工程时间用于系统健康维护，不受新功能需求挤压"。

这条写进 OKR，才有权利在被 PM 压新功能的时候说"这是 OKR 里承诺的"。

原则五：OKR 复盘比 OKR 制定更重要

我见过太多团队，OKR 制定花了一周，复盘用了半小时。

AI 团队的 OKR 尤其需要认真复盘，因为：

• 目标没达成，是因为团队执行不力，还是因为目标设定本身不合理？
• 目标达成了，是真实改进，还是测量标准变了？
• 哪些"不确定性"在 OKR 制定时没有预见到？下次怎么处理？

这些问题的答案，是制定下一个季度 OKR 最宝贵的输入。没有这个回路，OKR 就只是一个季度结束一次的仪式。

---

AI 工程团队设 OKR 没有完美的答案，因为这个领域本身就在快速变化，很多"最佳实践"还没有形成。

但有一条我越来越确信：OKR 的价值不在于它设计得有多漂亮，在于它是否真实反映了团队在做什么、为什么做、期望得到什么结果。

一个粗糙但真实的 OKR，远比一个精致但脱离实际的 OKR 有价值。