DoorDash 的评估平台实践：让非工程师也能给 AI 打分
关联
给 AI 产品做评估(evals,即系统地衡量 AI 输出质量)，听起来是纯工程活，但 DoorDash 的经验恰恰相反：真正难的不是写测试框架，而是把领域专家的判断装进质量体系——而这些专家不是工程师，是产品经理、战略运营人员，甚至外部标注合作伙伴。分享这件事的是 DoorDash 的 Gen AI 平台团队的 Swaroop 和 Nachiket,这是一个横向团队，为所有产品团队提供 AI 基础设施，核心是帮产品团队平衡三股力量：准确性、延迟和成本 。
他们的平台有四大支柱：LLM 网关(可以在不同模型间轻松切换)、智能体网关(连接工具和其他智能体，统一解决认证和智能体身份，让安全团队集中认可)、开源权重模型托管(成本是当下头号关注点，他们押注开源模型已见显著成效)，以及今天的主题——evals。
评估为什么是团队运动
他们跟内部各产品团队一聊，发现需求五花八门：购物助手团队需要会话级质量判断，个性化机器学习团队需要扩展人类判断的方式，多智能体系统则需要基于轨迹的评估。共同点浮出来了：必须赋能领域专家。联合创始人 Andy Fang 给的指导是 UI 优先——先做出非工程师也能用的界面；后来演化为 API 优先，让工程师不被中央平台阻塞；随着编程智能体出现，又变成了工作流优先，运营和产品经理能直接操作平台。
Nachiket 把分工讲得很清楚：战略与运营人员定优先级和质量标准，产品人员把需求转化成评分标准(rubrics)和工作流，运营团队跑标注，工程团队提供 API、遥测、数据集和评审器——「从追踪到数据集再到评分机制，这基本上是一项团队运动」。整个质量体系被他们归纳成一个持续迭代循环：追踪 → 抽样缩减到你想细看的小集合 → 用领域知识标注 → 审查 → 生成黄金数据集(用来衡量和校准的基准)→ 校准评审器 → 持续监控 → 再来一轮。
平台怎么落地
平台分两层：遥测层存所有追踪记录、分数和观测数据，可通过 MCP、SDK 和 API 访问；工作流层是产品团队干活的地方——设置标注任务、审查黄金数据集、创建和校准评审器。所有能力都由一套稳定 API 支撑，UI 只是建在上面的一层。
标注环节最关键的一步棋：因为做了 API 优先，他们让战略运营团队直接用 Codex 或 Claude Code「vibe coding」(用自然语言让 AI 生成代码)出自己的标注 UI。不同团队有图像标注、手动测试等不同用例，但底层模式相似——与其平台团队为每个用例建专门界面，不如把工作流交到运营人员手里，让他们自己造。一个餐厅菜单标注界面，看起来不花哨，但干净、能用、拿到需要的标注。
评审器校准(LLM as a judge,即用一个 LLM 按提示词给输出打分)也做成了自助流程：从某个裁判提示词起步 → 在追踪记录上跑出基线分数 → 用 JEPA 这个常用的提示词优化库跑迭代循环 → 团队满意后把提示词定为正式评审器。产品经理或运营人员在自助 UI 上设配置就能自己跑校准，任选模型(Gemini、Claude、OpenAI 都行)。两点设计很讲究：一是可视化——把原始提示词和校准后的提示词并排展示给合作团队，「让他们在构建过程中建立信任」;二是灵活配置——有的团队提示词归战略运营管，有的归产品经理，有的归工程团队，这给组织自己摸索演进留了空间。
结果
自助式标注平台直接带来了成本下降：DoorDash 每周有数千行数据要标注，规模下成本相当可观，自助化后每条标注成本大幅降低、速度提升。各团队在完全自助的环境里校准自己的评审器，迭代循环快了一大截。
本集带走
- 评估先想清楚「谁来贡献判断」：领域知识在运营和 PM 手里，平台要 UI 优先降低他们参与的门槛，而不是把 evals 锁在工程团队里。
- API 优先是解锁 vibe coding 的前提：先把稳定 API 建好，各团队就能用编程智能体生成自己的标注界面，平台团队不必为每个用例定制 UI。
- 校准循环做进自助 UI:基线分数 → 提示词优化迭代 → 满意后提升为正式评审器，非工程师设个配置就能自己跑，还能任选模型。
- 让校准过程可审查：并排展示校准前后的提示词，黑盒变透明，合作团队才敢信任这套东西。
- 成本账要算在标注上：每周数千行标注在规模化下很贵，自助标注平台同时压低了每条成本、加快了迭代循环。
每个人都能使用编程智能体，而我们实际上在 API 优先的方式上加倍投入。
Everybody has access to coding agents, and we actually doubled down on that API-first approach.
—— Nachiket Paranjape · [09:19]
顺着「智能体」挖下去
- Braintrust CEO Ankur Goyal:做 AI 评估的纪律八年不变，但玩法正在剧变同概念:LLM 即评审器 (LLM as a judge)、智能体 (agent)、评估 (evals)
- 做 evals 不是写单元测试，是从看数据开始的错误分析同概念:LLM 即评审器 (LLM as a judge)、智能体 (agent)、评估 (evals)
- 9亿美元管道背后:Unify CTO 谈怎么把销售智能体的成本打下来同概念:LLM 即评审器 (LLM as a judge)、智能体 (agent)、评估 (evals)
换个口味
- 评测优先:Braintrust 创始人谈 AI 产品开发的真正工程同概念:智能体 (agent)、评估 (evals)
- Claude Code 产品负责人:AI 时代 PM 的生存法则同概念:智能体 (agent)、评估 (evals)
- DevOps 之父 Patrick Debois：AI 时代组织比技术更难成熟同概念:智能体 (agent)、评估 (evals)