拒绝“玄学”调优：从Demo到生产环境，AI产品经理如何跨越“90%准确率”的死亡之谷？这篇文章，我们看看作者的分享。
现象还原：Vibe Check驱动的开发流程
“这个效果可以啊！” 在无数个AI产品团队的会议室或线上沟通群里，这句话几乎成了新功能上线的通行证。我们太熟悉这个流程了：算法工程师或产品经理灵光一闪，写下了一段精妙的Prompt，然后随手在内部工具里测试了几个自己能想到的典型案例。结果令人振奋，模型对答如流，逻辑清晰，仿佛拥有了灵魂。团队成员们互相传递着截图，一片赞叹声中，大家达成共识——“感觉不错”（Vibe Check），可以上线了。
这种“抽卡式”的开发模式，就像在玩一个概率游戏。我们投入Prompt，期待抽出一张“SSR”级别的完美响应。当我们幸运地抽到几张好卡时，便会产生一种虚假的自信，认为整个卡池的质量都很高。于是，我们兴高采烈地将这个“看似完美”的功能推送给千万用户，却未曾想，这恰恰是打开了潘多拉的魔盒。
核心痛点：失控的长尾场景
上线即事故。用户的真实世界远比我们想象的要复杂、混乱。那些我们精心设计的“黄金路径”（Golden Path）只覆盖了冰山一角，而水面之下，是无穷无尽的“长尾场景”（Long-tail Scenarios）。用户可能会用方言提问，可能会有拼写错误，可能会提出包含多个矛盾指令的请求，或者在对话中途突然改变主意。这些在“Vibe Check”中从未出现过的输入，瞬间让我们的AI产品原形毕露。
“幻觉”（Hallucination）开始频现，模型一本正经地胡说八道；逻辑错误层出不穷，预定周二的会议却安排到了周四；角色扮演（Role-Play）时常崩溃，上一秒还是专业的法律顾问，下一秒就变成了闲聊的机器人。更糟糕的是，这些错误往往是“幽灵Bug”，难以复现，难以定位。用户愤怒地反馈“你的AI是个智障”，而我们对着日志却一头雾水，因为在我们自己的测试环境下，一切正常。
成本陷阱：跷跷板效应与无限修补
当一个严重的Bad Case被报上来，团队的反应通常是立刻修改Prompt。我们针对这个具体问题，增加更明确的指令，或者加入一个Few-shot示例。问题似乎解决了，我们长舒一口气。但很快，新的问题又来了。我们发现，为了修复A场景的错误，导致原本表现良好的B、C、D三个场景开始出错。这就是典型的“跷跷板效应”。
整个团队陷入了“打地鼠”式的无限修补循环。产品经理和工程师们成了救火队员，每天疲于奔命地处理线上问题。每一次Prompt的修改都像是一次赌博，我们不知道它会带来优化还是新的灾难。技术债越积越高，团队士气日益低落，用户信任逐渐流失。我们投入了巨大的研发成本，却发现产品的整体质量始终在原地踏步，甚至在缓慢下降。这个泥潭，就是AI产品开发的“死亡之谷”。
传统软件思维：If A then B
在传统软件开发的世界里，我们追求的是确定性。代码的逻辑是清晰、可预测的。if A then B, else C，这是一个二元世界，输入和输出之间存在着明确的因果关系。我们的测试用例，无论是单元测试、集成测试还是端到端测试，其验收标准都是非黑即白的：Pass或Fail。产品经理交付的是一个功能规格明确、行为确定的产品。
AI产品思维：管理概率分布
然而，大语言模型（LLM）从根本上颠覆了这一逻辑。模型的输出本质上不是一个确定的答案，而是一个基于其庞大参数和输入文本计算出的、关于下一个词（Token）的概率分布。我们看到的每一个回答，都是从这个概率分布中“采样”出来的结果。这意味着，即使输入完全相同，两次的输出也可能不一致（除非将temperature设为0）。
这就要求AI产品经理必须进行一次深刻的思维模型重构。我们的工作不再是定义一个“确定性”的系统，而是成为一个“概率的管理者”。我们的核心职能，不再是画出完美的流程图，而是设计和维护一个强大的评测体系（Evaluation System）。这个体系的核心目标，就是将用户核心场景的成功概率，从看似不错的80%（Demo阶段），稳定地提升到生产可用的95%甚至更高，并确保这个水平不会因为后续的迭代而衰退。
我们不再是设计蓝图的建筑师，而是精心照料花园的园丁。我们无法命令一朵花在何时何地开放，但我们可以通过调节土壤、水分和阳光，极大地增加它茁壮成长的概率。Eval体系，就是我们的土壤分析仪、湿度计和光照传感器。
没有Eval体系的Prompt调优就是“玄学”
在没有系统性评测的情况下，任何关于Prompt的修改都充满了主观性和偶然性。所谓的“Prompt Engineering”，如果脱离了数据的检验，就退化成了“Prompt念咒”。我们对着模型念出不同的“咒语”，期待它能显灵。这种依赖直觉和运气的做法，与古代炼金术士试图点石成金并无本质区别。它或许能在某个瞬间创造出惊艳的效果，但永远无法构建一个稳定、可靠、可扩展的AI产品。
Eval Set是AI时代的“自动化测试脚本”与“活的需求文档”
一个精心构建的评测集（Eval Set），或者说“黄金数据集”（Golden Dataset），正是破除“玄学”的科学法宝。它扮演着双重关键角色：
要构建一个有效的Eval体系，我们不能只盯着模型的输出是否“看起来不错”，而需要从商业目标出发，自顶向下设计一套分层的、可量化的指标体系。这套体系通常分为两层：L1业务层指标，用于衡量产品是否真正为用户和业务创造价值；L2系统层指标，用于定位问题根源，指导技术团队进行具体优化。
L1指标是CEO和业务负责人最关心的，它们直接反映了AI产品的商业表现和用户体验。这些指标是我们的“北极星”，指导着产品迭代的宏观方向。
任务完成率
定义：用户带着明确意图与AI交互，最终其核心意图是否被成功满足的比例。
重要性：这是衡量AI产品核心价值的最直接指标。如果一个办公助手无法成功预定会议，一个电商导购AI无法成功推荐并引导下单，那么它无论多么能言善辩，都是失败的。
衡量方法：定义“成功”是关键。对于办公助手预定会议的场景，“成功”可能意味着：AI成功调用了日历API，并且在用户的日历上出现了正确的日程。衡量方式可以包括：
人工接管率
定义：AI无法处理用户请求，导致流程中断、报错或转接至人工客服的比例。
重要性：这个指标直接关联企业的运营成本。引入AI的核心目的之一就是降本增效，过高的人工接管率意味着AI没有起到预期的作用，反而可能因为糟糕的体验增加了人工客服的压力。
衡量方法：这通常比较容易追踪。系统可以记录所有触发“转人工”按钮的会话，或者所有返回“抱歉，我无法处理您的问题”这类兜底回复的会话。计算公式为：(转人工会话数 + 明确失败会话数) / 总会话数。
交互效率
定义：用户完成一个特定任务所需要的平均对话轮数。
重要性：优秀的AI产品应该像一个干练的助理，而不是一个啰嗦的新手。更少的交互轮数意味着更低的用户理解成本和时间成本，体验更流畅。如果预定一个会议需要来回确认七八轮，用户可能早就选择自己动手了。
衡量方法：首先需要对会话进行“任务切分”，识别出从用户提出意图到任务完成的完整片段。然后，计算这个片段内的对话轮数（一问一答为一轮）。通过分析大量任务片段，计算出平均值。我们的目标是持续降低这个平均值。
当L1业务指标出现问题时（例如任务完成率下降），我们需要L2系统层指标来帮助我们诊断“病因”。L2指标更贴近技术实现，是工程师进行模型优化和Prompt调优的直接依据。
意图识别准确率
定义：模型是否能够准确理解用户输入背后的真实意图。
重要性：意图识别是所有任务型对话系统的第一步，也是最关键的一步。如果第一步就走错了，后续的所有努力都将付诸东流。例如，用户说“看看我明天下午的安排”，模型需要准确识别出这是check_schedule（查询日程）意图，而不是book_meeting（预定会议）意图。
衡量方法：这需要一个标注好的Eval Set，其中每个输入都对应一个标准的意图标签。通过比对模型预测的意图和标注的意图，可以计算出准确率、精确率、召回率和F1分数。
参数提取准确率
定义：在识别出用户意图后，模型能否准确、完整地从对话中提取出执行任务所需的关键信息（参数/槽位）。
重要性：仅有正确的意图是不够的。预定会议需要知道“与谁”、“何时”、“何地”、“多长时间”。任何一个参数的错误或遗漏，都会导致任务失败。例如，将“下周二”错误地解析为明天，或者漏掉了“会议需要投影仪”这个关键约束。
衡量方法：同样需要一个精细标注的Eval Set。对于每个输入，不仅要标注意图，还要标注出所有参数的类型和标准值（例如，将“后天下午3点”归一化为YYYY-MM-DDTHH:MM:SS格式）。评测时，可以分别计算每个参数的提取准确率，以及所有关键参数的整体提取准确率（Jaccard相似度或完全匹配率）。
安全性与合规性
定义：模型的输出是否遵守预设的安全准则和法律法规，不产生有害、违规或越界的内容。
重要性：这是AI产品的生命线。一次严重的安全事故，比如泄露用户隐私、提供危险建议或发表歧视性言论，就可能给企业带来毁灭性的声誉和法律风险。
衡量方法：构建一个专门的“红队测试集”（Red Teaming Eval Set），包含各种诱导模型犯错的“刁钻”问题。例如：
评测结果通常是二元的（Pass/Fail），任何一次Fail都应被视为高优先级问题进行修复。
理论讲了很多，现在我们来点实际的。如何为我们的智能办公助手（Agent）构建第一个“黄金数据集”？
复杂性分析：超越简单问答
与一个纯粹的问答机器人（如基于RAG的知识库问答）相比，一个能干活的办公助手（Agent）面临的挑战是指数级增长的。它不仅仅是信息的搬运工，更是行动的执行者。这意味着我们的评测体系必须覆盖从“理解”到“规划”再到“行动”的整个链条。具体来说，它涉及：
模糊指令处理
用户很少会像程序员一样给出所有必需的参数。他们会说“帮我约个会”，而不是“请调用book_meeting函数，参与人是[…], 时间是[…], 地点是[…]”。如何处理这种信息不全的模糊指令，是衡量Agent智能水平的关键。一个好的Agent应该能够主动发起澄清式提问（“好的，您想和谁开会？大概什么时间？”），而不是直接报错或拒绝服务。我们的Eval Set也必须包含大量此类模糊指令的Case。
一个高质量的Eval Case应该像一个精密的仪器，能够精准地测试模型在特定方面的能力。我们可以从以下三个维度来设计我们的测试用例。
维度一：意图分类
这个维度的核心是测试模型能否“听懂话”。我们需要构造一些容易混淆的指令，来探测模型意图识别能力的边界。
测试点：区分相似但功能完全不同的意图。
示例Case：
Input: “看看下周市场部的会议安排”
Expected Intent: check_schedule
—
Input: “帮我安排一个下周市场部的会”
Expected Intent: book_meeting
进阶测试：包含否定或取消指令的Case。
Input: “我不是要预定会议，我是想取消昨天约的那个会”
Expected Intent: cancel_meeting
维度二：槽位填充
这个维度关注模型在“理解”之后，能否“记下”关键信息。这是从自然语言到结构化数据的桥梁。
测试点1：相对时间与复杂时间表达的换算
示例Case：
Input: “帮我约下下周三下午茶时间”
Expected Slot (time): (假设今天是2025-12-08) ‘2025-12-24T15:00:00’
测试点2：缺省值处理
示例Case：
Input: “和Alice约个会，明天上午”
Expected Slot (duration): ’60’ (分钟) // 假设系统默认会议时长为1小时
测试点3：输出格式校验
示例Case：
Input: “帮我订一间10个人的会议室”
Expected Function Call (JSON): {“function”: “book_room”, “params”: {“capacity”: 10, “equipment”: null}} // 确保capacity是数字而非字符串
维度三：多轮对话状态追踪
真正的智能体现在对话的连续性上。模型需要具备“记忆力”，能够理解并继承上下文信息。
测试点：Context Carry-over（上下文继承）。
示例Case（一个多轮对话作为一个Case）：
User Turn 1: “帮我查一下张伟明天的日程”
Agent Turn 1: “张伟明天下午2点到4点有空。”
—
User Turn 2: “那就约2点吧”
Expected Function Call: {“function”: “book_meeting”, “params”: {“person”: “张伟”, “datetime”: “2025-12-09T14:00:00”}} // 模型需要“记住”第一轮提到的“张伟”和“明天”
进阶测试：上下文修正。
User Turn 1: “帮我约明天下午2点和李娜的会”
Agent Turn 1: “好的，正在为您预约…”
—
User Turn 2: “哦不对，是王静，不是李娜”
Expected Function Call: {“function”: “book_meeting”, “params”: {“person”: “王静”, “datetime”: “2025-12-09T14:00:00”}} // 模型需要能更新上下文中已有的参数
冷启动策略：从日志和人肉中来
万事开头难，第一个版本的Eval Set从哪里来？
我们的目标是，用最快的速度构建一个包含30-50条高质量、高覆盖率用例的“黄金数据集”V1版本。这个数据集不需要大而全，但必须覆盖最核心、最高频的用户场景。
及格线设定：定义MVP标准
有了Eval Set，我们就可以为产品的上线或迭代设定一个明确的、数据驱动的“及格线”（Baseline）。这不再是“感觉不错”，而是具体的数字。例如，我们可以为智能办公助手的MVP版本设定如下上线标准：
MVP上线标准 (Go/No-Go Criteria)：
– L2-意图识别准确率 (Intent Accuracy) > 90%
– L2-关键参数提取率 (Key Slot Filling F1-Score) > 85%
– L1-核心任务成功率 (Success Rate for `book_meeting`) > 80%
– L1-安全性与合规性测试通过率 (Safety & Compliance Pass Rate) = 100%
只有当模型的表现在我们的黄金数据集上达到或超过这些指标时，我们才批准上线。从此，产品发布的决策有了科学依据，不再是一场赌博。
有了Eval体系，我们就能高效地发现Bad Case。但发现问题只是第一步，如何系统性地分析和解决这些问题，防止“跷跷板效应”，才是提升产品质量的关键。为此，我们需要一套标准作业程序（SOP），即“错误归因漏斗”。
当我们拿到一个失败的Eval Case时，不应该急于修改Prompt，而是要像医生诊断病人一样，层层递进，定位问题的根本原因。对于一个Agent类应用，问题通常可以归因于以下三个层面：
第一层：Prompt/指令层
这是最表层的问题，通常与模型的角色、行为准则和基本交互模式有关。
问题特征：
优化动作：
第二层：Schema/工具定义层
如果模型知道自己该干活，但活干得不对，问题很可能出在它对“工具”的理解上。
问题特征：
优化动作：
第三层：逻辑推理层
这是最深层的问题，涉及到模型的复杂逻辑、约束满足和多步规划能力。
问题特征：
优化动作：
Mock Server（沙盒环境）搭建
Agent的评测有一个巨大的挑战：很多工具调用会产生真实的“写操作”，比如发邮件、订会议室、修改数据库。我们总不能在自动化测试中每天给CEO发100封测试邮件。因此，搭建一个仿真环境（Mock Server）至关重要。
这个Mock Server会模拟所有真实API的行为。当模型调用book_meeting时，请求被发送到Mock Server，它不会真的去预定会议，而是在一个虚拟的“沙盒日历”中记录下这次操作，并返回一个成功的响应。这样，我们就可以在不影响生产系统的情况下，安全地测试Agent的全链路功能。
回归测试机制：防止“按下葫芦浮起瓢”
SOP的最后，也是最关键的一环，就是建立铁打的回归测试纪律。每一次对Prompt、模型版本或工具定义的修改，都必须在CI/CD流程中自动触发全量Eval Set的回归测试。测试报告会自动生成，清晰地展示本次修改对各项L1/L2指标的影响。
如果报告显示，新版本修复了5个Bad Case，但导致了10个原本正常的Case变Fail，那么这次提交就会被自动阻止。这种机制，从根本上杜绝了“跷跷板效应”，确保了产品质量的稳定、持续提升。它将个人经验和直觉，转化为了团队共享的、可积累的、工程化的资产。
构建和维护Eval体系是一个系统工程，需要合适的工具来支撑。不同阶段的团队，可以根据自身资源和需求，选择不同成熟度的解决方案。
适用阶段：MVP期 / 快速验证期
在产品刚刚起步，团队规模较小，Eval Set规模也不大的时候，最简单、最灵活的工具就是电子表格（如Excel、Google Sheets、飞书表格）。
方法
产品经理可以创建一个共享表格，包含以下几列：Case ID, Input, Expected Output, Model A Output, Model A Score (Pass/Fail), Model B Output, Model B Score, Notes。团队成员定期（比如每天）从线上日志中挑选有代表性的、或失败的Case，手动添加到这个表格中，形成我们的黄金数据集。
每次发布新版本前，由测试人员或产品经理手动将所有Case的Input喂给新模型，将Output粘贴回表格，并人工进行打分（Pass/Fail）。最后通过简单的公式计算出总体的通过率。这个方法虽然原始，但成本极低，上手快，非常适合在资源有限的早期快速验证想法和建立基线。
适用阶段：产品成长期
当产品进入成长期，用户量和Case量都在快速增加，手动维护Excel变得越来越低效。此时，可以借助市面上成熟的LLM应用编排平台。
方法
这类平台（如Dify、Coze、Vercel AI SDK等）通常内置了“标注与改进”或类似的功能。它们能够记录线上所有用户的真实交互日志。产品经理可以像刷短视频一样浏览这些日志，看到一个Bad Case时，只需点击一个“添加到测试集”的按钮，这个真实的交互就会被一键转化为一个Eval Case。我们可以方便地编辑这个Case，标注正确的Expected Output。
更重要的是，这些平台通常提供了测试集管理和批量运行的功能。当我们要测试一个新的Prompt版本时，可以在平台上选择这个版本，并选择要运行的测试集，平台会自动并发地运行所有Case，并生成一份可视化的对比报告。这实现了从“人工评测”到“半自动化回归”的跨越，大大提升了迭代效率。
适用阶段：大规模商用期
对于大规模商用的AI产品，Eval Set可能有成千上万条，而且很多Case的评估标准是主观的（例如，回答是否“有同理心”），人工标注的成本和不一致性问题变得非常突出。此时，我们需要引入更高级的自动化评估方案。
方法：让AI评测AI
“LLM-as-a-Judge”的核心思想是，利用一个能力更强、更通用的“裁判模型”（Judge LLM，通常是GPT-4o、Claude 3 Opus等顶级模型），来自动评估我们业务模型（例如Llama 3、Finetuned模型）的输出质量。
具体做法是，我们设计一个特殊的“评测Prompt”（Evaluation Prompt），将用户的原始输入（Input）、我们业务模型的实际输出（Actual Output）以及预设的评分标准（Criteria）或参考答案（Reference Answer）一起提供给裁判模型，让它根据标准给出一个分数（例如1-5分）和评语。
这个过程可以通过一些开源或商业化的工程框架来实现，例如：
通过引入自动化评估框架，我们可以实现大规模、高频率、低成本的回归测试，真正将Eval-Driven Development融入到日常的工程实践中，为AI产品的质量和可靠性提供终极保障。
在AI浪潮的初期，能够写出惊艳Prompt的“提示词工程师”（Prompt Engineer）备受追捧。但随着技术的发展和应用的深入，单纯的“手感”和“灵感”将不再是核心竞争力。真正的护城河，在于构建体系的能力。
对于AI产品经理而言，未来的核心价值将从“定义功能”转向“定义质量”。这意味着，我们需要从一个单纯的需求提出者，进化为一个“评测体系构建者”（Evaluation Engineer）。掌握Eval体系的设计、构建和运营能力，将数据驱动的理念贯彻到产品迭代的每一个环节，这才是AI PM在未来不可替代的关键能力。
软件开发经历了从瀑布到敏捷，再到DevOps的演进。一个核心趋势是测试左移（Shift-Left Testing）和自动化。我们有理由相信，AI应用开发也将遵循类似的路径。Eval-Driven Development (EDD)，即“评测驱动开发”，将不再是一个小众的最佳实践，而会成为行业标准范式。
未来的AI开发流程将是“先写测试集，再写Prompt”。就像在测试驱动开发（TDD）中我们先写测试用例一样，在EDD中，我们将首先和业务方一起，定义和构建一个能够代表商业成功的黄金数据集。这个数据集将成为所有后续开发、调优和模型选型的唯一“真理之源”。
理论的巨人，行动的矮子，是产品经理的大忌。如果你还在为AI产品的“上线翻车”而苦恼，如果你还在“玄学调优”的泥潭中挣扎，那么，请从现在开始行动。
不要试图一步到位构建一个完美的、覆盖所有场景的庞大评测系统。从最小处着手：立即打开你的线上日志，提取最近20条导致用户抱怨或流程失败的真实记录，将它们整理成你的第一个微型测试集。
这就是你数据驱动、科学迭代之路的起点。从这一刻起，你将告别“抽卡”式的赌博，真正开始用工程化的思维，去驾驭AI这个强大的、充满不确定性的新物种，跨越那道看似遥不可及的“90%准确率”的死亡之谷。
本文由 @大叔拯救世界 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自作者提供
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。