惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

The Cloudflare Blog
小众软件
小众软件
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
T
Tailwind CSS Blog
WordPress大学
WordPress大学
有赞技术团队
有赞技术团队
博客园 - 司徒正美
V
Visual Studio Blog
G
Google Developers Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
月光博客
月光博客
aimingoo的专栏
aimingoo的专栏
博客园_首页
Blog — PlanetScale
Blog — PlanetScale
博客园 - 聂微东
S
SegmentFault 最新的问题
T
The Blog of Author Tim Ferriss
D
Docker
Vercel News
Vercel News
Recent Announcements
Recent Announcements
Last Week in AI
Last Week in AI
爱范儿
爱范儿
J
Java Code Geeks
大猫的无限游戏
大猫的无限游戏

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
AI 产品经理如何从 0 到 1 搭建测试集:以智能购车问答为例 –...
Tuer AI · 2026-06-07 · via 人人都是产品经理

AI产品的验收标准正成为行业痛点,从购车问答到权益核销,模型幻觉与评测缺失让产品经理陷入主观判断的泥潭。本文深度拆解测试集设计七步法,揭示如何将业务风险转化为结构化指标,从模型选型到Prompt优化的全链路避坑指南,为AI产品经理提供从玄学到工程化的实战方法论。

AI 产品验收的困境

这两年做 AI 产品的产品经理越来越多,但一个现实问题很快浮现,AI 功能到底怎么验收?传统功能可以看流程是否跑通、接口是否返回正确结果,但 AI 问答完全不一样。同一个问题模型每次措辞可能都不同,答案看起来似乎都没什么毛病,今天测试体验不错不代表明天换参数后还能稳定。没有测试集,产品验收靠感觉,这个版本好像回答得更自然了但说不清好在哪里;Prompt 优化变成玄学,改一句提示词试几条就上线;Bad Case 修掉了但下个版本又复现,因为没有回归机制。

为什么购车问答需要单独的评测体系

智能购车问答和普通闲聊最大的区别是它会直接影响用户决策。我们遇到过一个典型 case,用户问这款车适合三口之家吗,模型回答适合,空间大续航长,看起来没毛病,但产品 review 时发现这个答案不合格。真正有帮助的回答应该结合空间数据、安全配置、用车场景和预算来回答,而不是笼统说一句空间大。

更要命的是,有次模型在回答优惠时自行编造了一条本月购车赠送充电桩的权益,运营团队发现后紧急下线处理。这件事之后团队才真正意识到,在购车这种高决策成本场景中,AI 问答的质量不能只看顺不顺,还要看参数是否准确、信息是否完整、是否抑制了幻觉和过度承诺。测试集的意义,就是把好答案的标准从主观判断变成可复用、可评测的样本集合。

测试集的核心设计思路

很多团队一开始做测试集时容易当成收集一百条问题的任务。我们早期也犯过这个错,第一批只有五十条问题,全是 XX 车型续航多少这类简单问答题。结果 Prompt 一改,简单问题都答得很好,但用户实际常问的家用选哪款、和 XX 比怎么样全翻车了。

真正可用的测试集不是问题数量的堆叠,而是对用户决策链路的覆盖,至少包括七类,基础知识类(参数准确不能模糊)、价格权益类(与业务规则强相关最易出幻觉)、决策辅助类(把用户需求映射到卖点而非罗列参数)、对比类(考验知识结构化程度)、流程服务类(引导试驾预约和下订等下一步)、边界问题(测试模型是否知道自己不知道)、幻觉高风险类(看模型在诱导下能否克制)。

每条测试样本也应结构化,包含用户问题、场景分类、期望要点、知识来源、是否需要检索、是否允许归纳、幻觉风险和评分维度。这样当模型答错时,才能判断是知识库缺失、检索未命中、模型未用检索结果还是 Prompt 约束不足。

评测指标与团队协作中的摩擦

评测指标的设计本身也是不断对齐的过程。我们一开始只看准确性,但很快发现准确性高的答案不一定有用。用户问这车怎么样,模型准确回答了百公里加速和续航,但用户真正想问的是适不适合上下班通勤。

后来我们拆成五类指标,准确性看事实是否正确、召回完整性看关键信息是否遗漏、相关性看回答是否对准意图、可用性看能否帮用户做下一步决策、幻觉控制看有没有编造。这五个指标刚推出来时研发团队不理解,产品经理为什么管评测,不是算法的事吗。直到一次回归测试发现模型编造了一条不存在的置换补贴,如果上线涉及虚假宣传的法律风险公司承担不起,研发团队才主动要求每次 Prompt 变更必须跑完完整测试集。测试集就这样成了业务风控的一环。

测试集要贯穿全链路迭代

测试集应该贯穿模型选型、Prompt 优化、知识库建设和版本回归的每个环节。模型选型时我们对比过两个模型,A 在通用对话评测上分数更高,差点直接选 A,但用业务测试集一跑发现 A 在价格权益类问题上的幻觉率高出 B 将近一倍,最终选了 B。通用排行榜和业务表现可能是两回事。

Prompt 优化也有教训,有次我们把引导语从请基于以下知识回答改成请基于以下知识准确回答,加了准确两个字后核心用例通过率提升了,但幻觉专项测试集里有一条从通过变成了失败。模型为了准确反而不敢说任何推断性内容了。如果没跑完整测试集,这个回归问题就带着上线了。样本多了之后需要分层管理,核心集高频高价值每次必须回归、扩展集覆盖长尾场景测泛化能力、Bad Case 集防止历史问题反复、幻觉集专门卡控编造风险、上线验收集作为发布前的准入标准。

回头看从零搭建测试集的过程,就是 AI 产品经理从感觉判断到数据说话的过程。没有评测体系的时候,你说这个版本变好了,研发说那个版本也不错,争论半天谁也说不动谁。有了测试集,每次改动是好是坏跑一遍就知道,线上出 Bad Case 也能归因到具体环节。更重要的是,当产品经理用测试集和指标来定义上线标准,他在团队中的角色就从提需求的变成了定标准的。

测试集不是一次性文档,也不是技术团队的专属工具,而是 AI 产品长期运营的基础设施,更是 AI 产品经理走向工程化思维的第一步。

本文由 @Tuer AI 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自 Unsplash,基于CC0协议