做 AI 产品，路线图该数"实验"，而不是数"功能"
· · ·
团队花几周搭了一套复杂的 AI 系统。
你问一句：这次改动，是变好了还是变差了？
没人答得上来。
这是 AI 顾问 Hamel Husain 过去两年里，反复见到的场景。
他帮 30 多家公司做过 AI 产品。他发现一个规律：成功的团队，几乎不聊工具。
选哪个向量数据库、用哪家大模型、上哪个 Agent 框架......这些他们很少争论。
他们只痴迷两件事：度量，和迭代。
下面 6 条经验，每一条都很"朴素"，但都踩在要害上。
· · ·
↗一、最大的坑：跳过错误分析
"工具优先"，是 AI 开发里最常见的错误。
有位客户很得意地给 Hamel 展示评测仪表盘：一堆"有用性""连贯性"之类的通用指标。
Hamel 的评价很直接：通用指标比没有还糟。
原因有两个。
第一，它制造"在度量"的错觉。 团队为"有用性得分提升10%"庆祝，真实用户却连基本任务都完不成。就像网站加载速度越优化越快，结账流程却是坏的。
第二，指标太多，注意力被撕碎。 什么都重要，就等于什么都不重要。
那该怎么办？
答案是错误分析：AI 开发里最有价值、投入产出比最高的一件事。
第一站
一个真实案例
Nurture Boss 是一家做公寓行业 AI 助理的公司。创始人 Jacob 的团队做了这样几步：
1→
搭一个简单的查看器，逐条看 AI 和用户的对话
2→
每条对话旁写开放式笔记，记录哪里不对
3→
标注几十条后，规律浮现：用户说"两周后帮我约看房",AI 有 66% 会处理错日期
4→
针对日期问题归类、写专项测试、衡量改进
结果：日期处理成功率从 33% 提升到 95%。
第二站
自下而上，而不是自上而下
找错误类型有两种思路。
自上而下：从"幻觉""毒性"这类通用指标出发。方便，但容易漏掉你所在领域独有的问题。
自下而上：先看真实数据，让指标自己长出来。
Nurture Boss 的做法很土：
→
一张表格，一行一条对话
→
在每行写下"不对劲"的地方
→
让 LLM 帮忙归纳出失败类型
→
给每行打标签，数出各类问题的频次
结果令人意外：仅三类问题，就占了全部问题的 60% 以上。
工具是什么？Excel 数据透视表。
Jacob 的团队一下发现了太多可改进点，光修复就排了好几周。
· · ·
↗二、最该投资的东西：一个简单的数据查看器
Hamel 见过的最有价值的投入，不是花哨的评测平台。
而是一个为你的业务量身定制的数据查看器，让任何人都能看清 AI 到底在干什么。
为什么强调"定制"？
→
看公寓租赁对话，你得同时看到完整聊天记录和预约上下文
→
看房产问答，你得把房源详情和原始文档放在眼前
→
连元数据放哪、开放哪些筛选，都会决定这个工具是被爱用还是被嫌弃
用通用标注工具的团队，常常要在多个系统间来回跳：点进去看上下文，复制错误描述到另一张表，再切到别处核对信息。
摩擦累积起来，会直接劝退"系统性地看数据"这件事。
有好用查看器的团队，迭代速度快 10 倍。
更好的消息是：借助 Cursor、Lovable 这类 AI 编程工具，几个小时就能搭出来。
一个好的标注工具，至少做到这 5 点：
1→
所有上下文放在一个页面，不要让人到处找
2→
反馈成本极低：一键"对/错"，胜过冗长表单
3→
支持开放式备注，捕捉预设分类之外的细微问题
4→
能快速筛选、排序，比如按渠道（语音/文字/聊天）或某个楼盘过滤
5→
有快捷键，不碰鼠标也能翻页、标注
用什么技术栈不重要，用你熟的就行。
起步也不必完美：哪怕只是一张表格，也比什么都没有强。
· · ·
↗三、让"最不懂 AI 的人"来写提示词
一家教育创业公司的产品经理是学习设计专家。
她先做一份 PPT，讲教学原则和示例对话，交给工程师，再由工程师"翻译"成提示词。
Hamel 指出问题所在：提示词本来就是英文（中文）。
专家用 PPT 讲给工程师，工程师再翻回自然语言写进提示词，这一来一回，全是无谓的损耗。
做得好的团队反过来：直接给领域专家工具，让他们自己写、自己改提示词。
第三站
搭桥，而不是设卡
起点可以是提示词 Playground，比如 Arize Phoenix、LangSmith、Braintrust，能快速试提示词、喂样例、对比结果。
但很多团队漏掉了关键一步：把提示词开发嵌进真实的应用场景里。
多数 AI 应用不只是提示词，还有 RAG、多步编排和业务逻辑。
Hamel 把最有效的做法称为**"集成式提示词环境"**：本质上是真实产品界面的"管理员版"，在原界面上直接开放提示词编辑。
第四站
和领域专家沟通：少说黑话
这家教育公司的会议上，工程师总说"我们要做个 Agent 来干 XYZ"。
可实际要做的，只是写一段提示词。
结果，学习专家觉得自己插不上话，因为"不懂 Agent"。
律师、心理咨询师、医生，在各自行业的 AI 公司里都遇到过同样的事。
一个简单的"翻译表":
| 别这么说 | 换成这样说 |
|---|---|
| 我们在做 RAG | 我们要确保模型拿到回答问题所需的正确背景信息 |
| 要防范提示词注入 | 要确保用户没法忽悠 AI 无视我们的规则 |
| 模型有幻觉问题 | AI 有时会瞎编，所以得核查它的答案 |
这不是"降低门槛"，而是准确描述你到底在做什么。
术语并非一无是处，它在技术同行之间能提高沟通精度。关键是看对象说话。
· · ·
↗四、没有用户？先用合成数据启动
团队常说：没有足够的真实用户数据，没法做评测。
这像个死循环：要改进 AI 就得有数据，要有数据就得先有够好的 AI。
Hamel 的解法：合成数据。让 LLM 生成逼真的测试用例。
前 Hex AI 负责人 Bryan Bischof 说得很妙：
LLM 出奇地擅长生成优质且多样的用户提问......听起来有点像"大语言蛇在吃自己的尾巴"，我也很惊讶。我只能说：它有效，上线吧。
第五站
怎么生成"像样"的测试数据
先想清楚测试的维度，常见三类：
→
功能：AI 需要支持哪些能力？
→
场景：会遇到哪些情况？
→
用户画像：谁在用，怎么用？
以他与 Rechat 合作的房产 CRM 助理为例，组合出的查询长这样：
| 功能 | 场景 | 画像 | 生成的提问 |
|---|---|---|---|
| 房源搜索 | 多个匹配 | 首次购房者 | "想找河滨区50万美元以内的三居室，最好靠近公园，我们有小孩。" |
| 市场分析 | 无匹配 | 投资人 | "需要 123 Oak St 的可比房源，尤其想比较 2 英里内类似房产的租金回报。" |
关键是让合成数据扎根于真实的系统约束：
1→
使用数据库里真实存在的房源 ID 和地址
2→
纳入真实的经纪人日程与可预约时间
3→
遵守业务规则，比如看房限制和通知期
4→
加入地区细节，比如物业费要求、当地法规
第六站
5 条使用准则
1→
保证多样性：覆盖尽可能多的功能、场景与画像
2→
只生成用户输入，不生成期望输出：避免继承生成模型的偏见
3→
融入真实系统约束：比如测试预约功能，就用真实的时间窗口与规则
4→
验证场景覆盖：想测"无匹配"，就确认它真的返回 0 条结果
5→
先简单，后复杂：先建基线，再加边缘情况
很多公司里，合成数据起初只是权宜之计，后来成了评测基础设施的长期组成部分，即便真实数据来了也不会废弃。
· · ·
↗五、评测体系的"信任"，比评测本身更重要
很多团队有这样的经历：
评测体系搭起来了，慢慢却没人信了。
指标和线上现象对不上，或者评测复杂到没人看得懂。最后，团队回到凭感觉、听吐槽做决策，评测形同虚设。
怎么守住这份信任？
第七站
先认识"标准漂移"
论文《Who Validates the Validators?》里提到：
要给输出打分，人得先把评价标准说清楚；但打分的过程，恰恰又在帮人定义这些标准。
也就是说：在人工看过足够多的输出之前，不可能完整地确定评价标准。
Hamel 在与 Honeycomb 合作时也见到：Phillip Carter 在看到 LLM 的推理过程后，才发现自己对某些边缘案例的判断并不一致。
这不是计划不周，而是 AI 系统的固有特征。
聪明的团队不抗拒它，而是把评价标准当成会不断演进的"活文档"。
第八站
三个让评测可信的做法
1. 用二元判断，代替模糊打分
1~5 分的量表，会让评分者纠结 3 分和 4 分有什么区别，引入大量噪音。
而且业务最终还是要划一条"及格线"，本质上仍是二元决定。
二元的"通过/不通过"强迫评估者给出清晰判断。
细微差别并没有丢，只是挪到了随附的文字点评里。
2. 二元判断 + 详细点评
比如：
"AI 提供了所要求的市场分析（通过），但加入了与投资问题无关的社区人口细节，使回答过长且容易分散注意力。"
点评能逼专家把"隐性知识"说出口。
放进评审提示词作为 few-shot 示例，还能让 LLM 与人的一致率提高 15%~20%。
3. 持续衡量自动评测和人工判断的一致性
人天生容易过度信任 AI。
论文中提到一个例子：MIT 研究者发布预印本称 GPT-4 能通过 MIT EECS 考试，几小时内就被指出问题，原因正是让 GPT-4 给自己打分。
Hamel 与 Honeycomb 追踪 LLM 评审和专家的一致性，迭代了三轮，才把一致率拉到 90% 以上。
这笔投入换来的，是团队真正敢用的评测系统。
第九站
规模化，不等于全自动
很多团队一上量，就急着把人撤出评测。
更稳妥的节奏：
1→
前期高人工参与：让领域专家评估相当比例的输出
2→
研究一致性规律：搞清楚哪些情况下自动评测靠谱、哪些不靠谱
3→
策略性抽样：重点抽取信息量最大、一致性最弱的样本
4→
定期校准：规模再大，也要定期拿自动评测对照人工判断
· · ·
↗六、路线图要数"实验"，不是数"功能"
传统软件的路线图，是一串"功能 + 交付日期"。
放到 AI 上，会惨败。
"Q2 上线情感分析""年底部署 Agent 客服"，这类承诺很常见。结果往往是：技术根本达不到质量线。
要么硬着头皮交付一个劣质版本，要么直接延期。信任都在流失。
根本原因：传统路线图默认"我们知道什么是可行的"。而 AI，尤其前沿 AI，你一直在试探可行性的边界。
第十站
能力漏斗
Bryan Bischof 提出"能力漏斗"：把 AI 表现拆成逐级递进的效用层次。
以查询助手为例：
1→
能生成语法正确的查询
2→
能生成可以无错误执行的查询
3→
能生成返回相关结果的查询
4→
能生成符合用户意图的查询
5→
能生成最优查询，彻底解决用户问题
AI 的进展不是"有或无"，而是多个维度上的逐步提升，而不是"结果"。
Amazon 应用科学家 Eugene Yan 分享过他和管理层沟通的方式：
先花两周做数据可行性分析："我有合适的数据吗？"再花一个月做技术可行性分析："AI 能解决吗？"如果还行，再花六周做出能 A/B 测试的原型。
核心是：给探索设定时间盒，设立清晰的决策点，先证明可行，再投入全量开发。
"我会用时间盒让领导放心。三个月后如果有效，就上线；任何一步不行，就转向。"
第十二站
一个"反直觉"的案例
Eugene 曾被要求做内容审核。他对领导说：
"能否达成目标是不确定的，甚至数据是否支持、哪种技术奏效都不确定。但这是我的实验路线图，会尝试这些技术，每两周向你更新一次。"
结果呢？
头两三个月，什么都没起效。然后新技术出现，一个月内，问题解决了 80%。
如果是传统的功能路线图，项目可能在几个月的"失败"后就被砍掉了，错过后面的突破。
第13站
给 AI 团队的底座：评测基础设施
实验路线图能跑起来，前提是你有可靠的评测基础设施。
Hamel 回忆早期 GitHub Copilot：团队在离线评测上投入巨大。他们用 GitHub 上海量仓库里已有的单元测试，自动验证代码补全是否正确。
要大规模克隆仓库、配环境、跑测试、分析结果，还要应对各种语言、框架、测试方式。
这不是浪费时间，而是加速一切的地基。有了它，团队跑了数千次实验，可以自信地说"这次改动让质量提升了 X%"，而不是凭感觉争论。
第14站
另外两个小技巧
→
向高管沟通：把话题从"产出"转到"结果"。承诺一个能最大化业务结果的过程，而不是具体功能和日期。
→
建立分享失败的文化 ：Eugene 每周写一份"15-5"（写 15 分钟、读 5 分钟），既记成功也记失败，团队还有无需准备的分享会。把失败当成学习，而不是隐患。
· · ·
↗总结：6 条心法，送给每一个做 AI 产品的人
1→
看你的数据。 没有什么能替代看真实样本带来的洞察。
2→
做简单工具，消除摩擦。 定制化的数据查看器，胜过复杂的通用仪表盘。
3→
让领域专家参与。 最懂业务的人，往往最能改进你的 AI。
4→
策略性地使用合成数据。 没有真实用户，也能启动评测。
5→
守住评测的信任。 二元判断 + 详细点评，并定期校准人机一致性。
6→
路线图围绕实验，而不是功能。 承诺节奏，而不是具体结果与日期。
最成功的团队，从来不是工具最炫、模型最新的那一批。
而是把度量、迭代、学习这些基本功做到极致的那一批。
· · ·
最后留个问题：
你的团队现在，有一个"所有人都能看对话记录"的地方吗？
欢迎在评论区聊聊你们是怎么做错误分析的。
· · ·
*原文：Hamel Husain,《A Field Guide to Rapidly Improving AI Products》,*hamel.dev/blog/posts/...