卖给你大模型的人，正在告诉你要检查大模型的答案。
如果你还在相信「把需求喂给AI，产品就能自动跑起来」，你可能正站在2023年的起跑线上，而规则已经在2025年改写。OpenAI、Anthropic这些公司的首席产品官们反复强调同一件事，评估系统（Evals）是构建AI产品时最重要的能力。不是提示词工程，不是模型选择，是评估。
这意味着什么？
意味着那些看起来最枯燥的工作，在电子表格里逐行标注「这个回答是好是坏」，恰恰决定了你的AI产品能不能活过第一个用户投诉。
Aman是Arise的产品负责人。他曾经在自动驾驶团队工作，那时候团队每周都要坐下来，看着车载摄像头拍下的录像，一帧一帧地标注「这个决策对不对」「车该不该这么做」。换到AI产品开发，逻辑一模一样，只是场景从马路换成了聊天框。Peter是一位资深PM，跑步速度不快但对跑鞋很挑剔。他们决定用一个真实案例，完整演示如何为On跑鞋品牌搭建一个客服Agent，并把整个评估流程拆开来看。
On是欧洲的跑鞋品牌，最近几年在北美很火。他们的官网上已经有一个AI客服，能回答退货政策、推荐鞋款、处理订单问题。这不是Demo，是真实在线的产品。Peter打开网站，在对话框里输入「我想退货我的On Cloud跑鞋」，几秒钟后收到回复，语气轻快，还带着emoji，最后给出三个可点击的建议选项。看起来很流畅。
但这种流畅背后藏着多少次迭代？
第一步：写提示词之前，先搞清楚Agent需要知道什么
Aman打开Anthropic的Console工具，这是一个专门用来搭建Agent的在线环境。他没有从零开始写提示词，而是用了一个叫「生成」的功能，让Claude帮忙起草初版。他在输入框里写道，「设计一个客服机器人的提示词，用于处理On跑鞋的客户咨询。需要三个输入变量，用户问题、产品信息、政策信息，然后给出有用的回答。」
点击生成。几秒钟后，Claude吐出了一个完整的提示词模板，里面已经用大括号标出了变量位置，甚至还附上了一个示例对话。Aman说，「这个工具最大的好处是它会用最佳实践帮你搭好框架，省掉很多从零摸索的时间。」
但提示词只是个空架子。真正的内容来自On官网的政策页面和产品目录。Aman打开On的退货政策页，把整页文字复制下来，粘贴进「政策信息」变量里。然后他让ChatGPT去On官网抓取鞋子的名称、价格、描述，整理成结构化文本，再填进「产品信息」里。
「你可以手动复制，也可以让AI帮你干这些脏活。」Peter说。
现在有了提示词，有了上下文，该测试了。Peter提了个刁钻的问题，「我两个月前买了Cloud Monster，现在想退货，但我不喜欢了。」点击运行。Claude Sonnet返回了一段回复，礼貌地告知Peter已经超过30天退货窗口，政策上不支持退货，但可以联系客服看看有没有其他解决方案。
Peter看了看说，「听起来符合政策，也算有帮助，但有点太长了。」
Aman点点头，「对，这只是第一版回复。你不能看一个例子就觉得可以上线了。」
问题是，接下来该怎么办？
第二步：定义什么叫「好」
Aman新建了一个Google Sheets，第一列写「用户问题」，第二列写「AI回答」，然后又加了三列，「产品知识」「政策遵循」「语气」。每一列下面都有评分标准，好、一般、差。
「产品知识」指的是Agent是否了解On的产品线。「政策遵循」指的是回答是否符合退货规则、联系方式等公司政策。「语气」指的是回复是否友好、简洁、符合品牌调性。这三个维度是他们讨论后定下来的最小评估集，不是最终版，但足够起步。
接下来是最关键的一步，填数据。
Aman换了个问题，「我三周前买了Cloud Monster，但把鞋盒扔了，现在想退货。」跑一遍，复制AI的回答，粘贴到表格里。然后两个人开始标注。
Peter说，「产品知识是好的，它知道Cloud Monster。但这主要是个政策问题。」
AI的回复说，「好消息，你还在30天退货窗口内，但你把鞋盒扔了。我建议联系客服团队。」
Peter皱眉，「我觉得政策里应该写清楚丢了鞋盒怎么办，或者鞋子损坏了怎么办。但现在政策里没有，所以AI把皮球踢给了人工客服。这算好还是不好？」
Aman反驳，「但如果政策里没写，AI是不是应该直接说『抱歉，这不在政策覆盖范围内』，而不是让用户去找另一个团队？那样只会增加客服工作量。」
他们争论了一会儿，最后在「政策遵循」那一栏标了「一般」，并在备注栏写道，「需要更完善的政策来处理边缘情况。」
但真正糟糕的例子出现在第五行。
用户问，「我45分钟前下了订单，但现在想改配送地址，可以吗？」AI回答说,「很遗憾，因为已经过了45分钟，超过了我们60分钟的订单取消窗口。」
Peter笑了，「大模型数学很烂。45分钟明明没超过60分钟。」
Aman在「政策遵循」那一栏直接标了「差」，备注写「LLM数学错误，需要在提示词中强调检查计算」。
这五行数据，花了他们二十多分钟。
但这二十分钟才是整个AI产品开发流程中最不可替代的环节。
第三步：让AI当自己的评委
手动标注五行数据可以，五十行呢？五百行呢？
这时候就需要「LLM as a Judge」，让大模型来给自己打分。但这不是直接让GPT-5去评价GPT-5的输出，而是把你刚才在表格里定义的评分标准，翻译成一个新的提示词，专门用来做评估。
Aman在Arise平台上新建了一个评估器，输入内容是，「根据以下标准，判断这个回答是好、一般还是差。产品知识，回答中是否准确提到了On的产品名称和特性。政策遵循，回答是否符合退货政策和联系信息。语气，回答是否友好、简洁、不过于正式。」
然后他把那五行数据导入平台，点击运行。几秒钟后，每一行后面都多了三列自动生成的评分。AI给所有回答都打了「好」。
Peter问，「它为什么全都是好？」
Aman调出其中一条的解释，「它说这条回答完全遵循了公司政策。」但明明刚才他们手动标注时，这条被标成了「一般」。
这就是关键点，你需要人类标注的数据来校准AI评委的判断。如果AI评委和人类评委的判断一致率只有20%，那这个评估系统根本不可信。你得回去调整评估提示词，让它更严格，或者更宽松，直到它和你的判断基本对齐。
Aman在平台上创建了一个「人类标注队列」，把五行数据重新标了一遍，然后运行「匹配率」功能。结果显示，产品知识的匹配率是100%，但语气的匹配率只有20%。
「看到了吗？这说明我们的语气评估提示词写得不好，AI觉得长回复也没问题，但我们觉得太啰嗦了。」
接下来他要做的，就是回到评估提示词里加一条，「如果回复超过三句话且没有提供实质性新信息，标记为『语气不佳』。」然后再跑一遍，再看匹配率，再调整。
这个循环可能要重复十次、二十次。
想想你上次在超市买电钻，你不是在买电钻，你是在买墙上的那个洞。
做AI产品评估也是一样。你以为自己在做的是「让AI更聪明」，但其实你是在定义「什么叫聪明」。这个定义藏在电子表格的每一个标注里，藏在你和同事争论「这条回复到底算不算好」的每一次拉锯里。没有这个定义，再强的模型也只是一个会说话的随机数生成器。
理论上，LLM能生成无限种回答。但用户能接受的「好回答」只有有限的几种模式。评估系统的作用，就是把这个无限空间压缩成有限空间，并且让AI学会在这个空间里稳定输出。
但这套方法不是万能的。
如果你的产品需求本身就模糊不清，或者你的团队对「什么是好产品」根本没有共识，那再精密的评估系统也救不了你。评估不会替你做产品决策，它只会放大你的决策。如果你的决策是错的，它会让你更快地把错误规模化。
另外，用户的真实反馈和你的评估标准可能会打架。比如用户给了差评，但你的评估系统显示这条回复完全符合标准。这时候该信谁？Aman说，「这是最难的时刻，因为用户可能只是因为政策本身不满意，而不是AI回答得不好。你得回去看数据，一条一条分析。」
Aman最后说了一句话，「大家总想找银弹，但产品经理理解这套流程，才是让AI产品在真实世界里不那么烂的唯一办法。」
Peter没接话。他关掉了On的客服页面，在表格里又新增了第六行测试用例。屏幕上，那个鞋盒丢失的问题还没标完。