演示成功，往往只是因为问题挑得好
项目汇报时，团队通常挑资料完整、问法标准的样本。AI 回答顺畅，领导觉得可以上线。真正用户不会这样配合：客户名称写错、文件缺页、同一规则有两个版本、问题只说一半。系统一进入真实环境，演示里的准确就可能迅速下降。
FDE 处在客户现场和产品之间，最清楚哪些错误会影响业务。OpenAI 的 FDE 职位把 eval-driven feedback 直接列入成功标准，说明评测不再只是研究团队的工作，而是生产交付的一部分。没有评测，现场反馈只能停留在“最近好像不太准”。
评测的第一步，是把业务人员的判断说清楚
客服说“这条回复不能发”，FDE 要继续追问：是事实错误、语气不当、缺少来源，还是越过了退款权限？销售说“这个方案不实用”，到底是没有结合客户历史，还是缺少下一步动作？把模糊评价拆成可观察标准，才有可能重复测试。
一个可用评测集应包含常见样本、边界样本和失败样本。每条保留输入、期望结果、依据来源、风险级别和人工判断。对于开放式内容，不必追求唯一标准答案，但必须定义不可接受的错误和需要人工确认的条件。
- 从真实历史任务中选样本，不只用团队自编问题。
- 把事实、权限、格式、语气和行动分别评分。
- 高风险错误设置一票否决，不被平均分掩盖。
评测不是上线前考一次，而是每次变更都要回归
模型升级、知识库更新、提示模板调整和接口字段变化，都可能让旧能力退化。今天修好了售后回答，明天却可能影响销售方案。FDE 要把核心样本变成回归测试，每次变更前后对比，而不是等一线员工投诉才发现问题。
评测结果还要能指导取舍。某个新模型平均分更高，但在合同金额上出现严重错误，就不适合直接替换；一个功能能提高速度，却让人工修改率上升，也要重新判断价值。评测不是为了证明技术好，而是帮助项目做稳妥决定。
未来优秀 FDE 的差别，会体现在能否建立学习闭环
会接 API、会做页面的工程师会越来越多。更难的是把客户现场的失败信号整理成样本，推动产品、模型和流程共同改进。OpenAI 对 FDE 和管理岗位都强调把现场模式沉淀为工具、playbook 和产品反馈，这正是评测发挥作用的地方。
企业选择 FDE 型团队时，可以直接问：评测样本从哪里来，谁定义通过标准，模型或知识更新后怎样回归，失败记录如何进入下一版。如果这些问题没有答案，项目即使演示很顺，也很难长期稳定。
要点总结
- 因为他需要把现场业务要求转成上线标准，并用失败反馈推动系统和产品改进。
- 不建议，应以真实历史任务为主，并由业务负责人确认风险和期望结果。
- 可以分事实、来源、权限、格式、语气和行动等维度，并定义不可接受错误。
参考来源说明
本文围绕“FDE 的评测能力为什么越来越重要？上线不能只看演示顺不顺”展开，结合 9 份公开资料及一路凯歌在“FDE 能力趋势”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。