# 客户从不给你指标，只给你抱怨

> FDE 要把“机器人回答很差”变成双方都签字认可的通过/不通过标准和评测集。

原文: https://fdetimes.net/zh/guides/turn-customer-complaints-into-evals/

与客户的第一次会议，往往以这样一句话收尾：“机器人的回答很差，改好一点。”没有数据，没有具体例子，也没人说“好一点”要好到什么程度。可两周后，决定项目成败的正是这个人。

很多优秀的工程师就卡在这里。你能写出很强的提示词，也能搭出干净的 RAG 管道，但如果不知道“好”意味着什么，你就是在朝一个谁都看不见的目标优化。这里要学的技能，是把客户的抱怨转化为标准：模型的输出要么达标，要么不达标。

## 为什么这是 FDE 的活，而不是别人的？

PostHog 把前线部署工程师（FDE）描述为嵌入客户团队内部的工程师。这个位置给了你总部研究团队没有的东西：真实的数据、真实的用户、真实的抱怨。正因如此，企业把定义成功的任务明确交给了这个岗位。

Cursor 的 FDE 招聘启事要求工程师与客户的工程师一起主导需求发现，找到真正的瓶颈，从一开始就定义清晰的成功指标，然后端到端负责整个解决方案。端到端负责意味着你不能诊断完就交出去，而要证明问题已经解决。

SecondTalent 上一份面向 AI FDE 的技能指南指出，这种证明就是一套评测框架，用来表明系统达到了双方约定的“好输出”定义。

PostHog 介绍的 OpenAI 案例说明，评测的作用还不止于此：一位 FDE 在一家正在把呼叫中心自动化的客户那里搭建了评测来验证效果，随后把这些数据带回研究团队，推动进一步改进。评测既是给客户的证据，也是给产品的信号。

## 从失败出发，而不是从指标出发

很多人的第一反应是挑一个流行指标，比如“有用性”评分或文本相似度，然后直接跑。Hamel Husain 和 Shreya Shankar 提醒，把通用评测当作质量衡量标准，既浪费时间，又会制造虚假的信心。他们建议基于错误分析构建定制的评估器。

两位作者认为，错误分析是评测中最重要的环节，因为它决定了该写哪些评测。

Anthropic 的文档补充了一条原则：标准必须具体。不要说“性能好”，而要说“情感分类准确”。标准还必须与应用的用途挂钩：引用准确性对医疗应用可能至关重要，对闲聊机器人则没那么要紧。

## 一个完整的实例

假设你是一家零售企业的 FDE。客户部署了一个客服机器人，抱怨“机器人的回答很差”。第一步不是打开代码，而是追问：“能给我看看最近你觉得最糟糕的三段对话吗？”

假设这三段对话暴露出完全不同的问题：机器人说错了退货政策；机器人承诺了一笔它无权批准的退款；机器人回答正确，但啰嗦冗长。“差”其实是三种失败，严重程度各不相同。

接下来你再要几十条日志，逐条阅读，为每一条糟糕的输出写一行失败描述。

归类之后，假设未经授权的退款承诺很少见，但法律风险最大；政策错误则出现得最频繁。你把这张表带回给客户，对话的性质就彻底变了：不再是“改好一点”，而是“你想优先解决哪种失败，能接受什么阈值？”

然后是标准。Husain 和 Shankar 更倾向于二元的通过/不通过判断，而不是 1-5 分制，因为这会逼着写标准的人想得更清楚，标注也更一致。在这个例子里，标准可以是这样：

| 抱怨 | 具体失败 | 通过/不通过标准 |
|---|---|---|
| “机器人答错了” | 说错退货政策 | 所述每一项退货条件都与现行政策文档一致，则通过 |
| “机器人很危险” | 无权限却承诺退款 | 输出承诺退款且未转交人工，则不通过 |
| “机器人太啰嗦” | 回答过长 | 在约定的长度限制内解决问题，则通过 |

最后是阈值。Anthropic 举过一个例子，把“输出安全”这一目标转化为：在 10,000 次试验中，被内容过滤器标记为有害的输出少于 0.1%。具体任务、阈值、试验次数，这个结构正是你需要摆到客户面前请对方签字确认的东西。

对退款承诺，你可以提议一个接近零的阈值；对回答长度，客户可能接受宽松得多的标准。

## 评审没测过，就别信它

输出量上来之后，你会用 LLM 当评审自动打分。这也是最容易自欺欺人的地方。Husain 和 Shankar 强调，任何做判断的评估器，都必须用人工标注的样例来测试，而且样例要恰好对应它要检测的那种失败。

在上面的例子里，你可以和客户的一位客服人员坐下来，给一批输出标注通过/不通过，再把这些标注与评审的结果对比。如果人能发现的退款承诺，评审漏掉了很多，那你仪表盘上的“通过”数字就毫无意义。

这种对比也是赢得客户对评测信任的好办法，因为“正确”的定义有他们自己人参与。一个值得做的练习：针对一条标准，自己标注 20 条输出，让 LLM 评审给同样的 20 条打分，数一数两者有几处分歧。

每一处分歧，都是你在给客户任何数字之前必须能回答的问题。

**要点:** 一个指标只有同时满足三点才有价值：对应真实的失败，有客户认可的阈值，评审经过真人校验。

## 常见错误

最常见的错误，是拿到抱怨就直接去改提示词。你也许恰好修好了自己猜的问题，但真正让客户难受的在别处，而且你无法证明取得了进展。

第二个错误是用 1-5 分制，因为它看起来更专业。两个人给同一条输出分别打 3 分和 4 分时，平均分帮不了任何人做决定。第三个错误是把评测当成一次性工作：真实数据一变，失败类别也会变，你得重新读 trace。

最后一个错误更隐蔽：自己定义“好”，却没让客户确认。只有 FDE 自己写的评测，是 FDE 的评测；客户签了字的评测，才是合同。

## 求职时如何展示这项技能

阅读 FDE 职位描述时，留意“define success metrics”“build evals”“discovery”这类表述，它们说明公司需要的正是这项技能。简历上不要写“提升了聊天机器人质量”，而要写你从多少条 trace 中归类出失败、定义了哪些标准、通过率如何变化。

面试中如果被问到“客户说产品不好用，你怎么办？”，不要急着给技术答案。把流程讲一遍：要例子、读 trace、归类失败、写二元标准、和客户一起定阈值、测试评审。

能讲清完整闭环，是证明你懂得把抱怨变成度量、而不只是会修问题的最直接方式。会修问题的人很多；能让客户对一个数字点头的人，才会拿到下一个项目。

**本周动手试试:**

- 取你正在开发的 AI 功能最近 30 条输出，逐条阅读，为每一条糟糕的输出写一行失败描述
- 把笔记归为 3-5 个失败类别，挑出最大的一类，为它写一条通过/不通过标准
- 从团队 backlog 里挑一个模糊目标，按“具体任务、阈值、试验次数”的模板重写

## 信源

- [Forward Deployed Engineer (Cursor, Accel job board)](https://jobs.accel.com/companies/cursor-2-379534b5-1a2a-49fd-86d0-ccd3e256c4f0/jobs/83110824-forward-deployed-engineer)

- [WTF is a forward deployed engineer? (and why everyone is hiring them)](https://posthog.com/blog/forward-deployed-engineer)

- [AI Forward Deployed Engineer: Key Skills & Responsibilities in 2026](https://www.secondtalent.com/occupations/ai-forward-deployed-engineer/)

- [AI Evals: Everything You Need to Know](https://hamel.dev/blog/posts/evals-faq/)

- [Define success criteria and build evaluations](https://platform.claude.com/docs/en/docs/test-and-evaluate/define-success)