这篇回答一个高频困惑：AI 产品改进不知从何下手时，第一件事该做什么。

最值得拿走的是「错误分析优先」的工作流：先逐条看真实数据、归类失败模式，再决定动架构还是动提示词——NurtureBoss 仅三个问题就解释了 60% 的故障，日期处理成功率从 33% 提到 95%。最易误用之处是拿通用指标仪表盘自我安慰，作者称之为「工具陷阱」；另外合成数据要生成用户输入而非期望输出，否则会继承生成模型的偏见。

站内评测类内容多讲指标设计，这篇讲评测之外的组织与流程：让领域专家直接写提示词、二元判断加文字批评、人机一致率校准到 90% 以上，以及「路线图数实验而非功能」的能力漏斗沟通策略。对需要跨职能推动 AI 落地、要向业务方解释不确定进展的国内从业者尤其受用，能直接借来做向上沟通的模板。

本周就用 FastHTML 或表格搭一个最小会话查看器，拉上产品和业务同事一起标注 50 条真实对话，按失败模式归类统计频率。

—— FDEChina编辑部 · 实战派

大多数 AI 团队把精力用错了地方。这是我做咨询时常见的一幕：

AI 团队：「这是我们的 Agent 架构——这边是 RAG，那边是个路由器，我们还用了一个新框架来做……」

我：（抬手打断这位兴致勃勃的技术负责人。）「能给我看看，你们怎么衡量这些东西到底有没有用吗？」

……房间里安静了下来。

过去两年，这一幕上演了数十次。团队投入数周构建复杂的 AI 系统，却说不清自己的改动是在帮忙还是在帮倒忙。

这不奇怪。新工具和新框架每周都在涌现，人们自然倾向于关注自己能控制的具体事物——选哪个向量数据库、选哪家 LLM 供应商、用哪个 Agent 框架。但在帮助 30 多家公司构建 AI 产品之后，我发现成功的团队几乎不聊工具。他们痴迷的是衡量与迭代。

在这篇文章里，我会向你展示这些成功的团队究竟如何工作。你将学到：

  • 错误分析（error analysis）为什么总能揭示投资回报最高的改进点
  • 为什么一个简单的数据查看器是你最重要的 AI 投资
  • 如何赋能领域专家（而不只是工程师）来改进你的 AI
  • 为什么合成数据比你想象的更有效
  • 如何维持评测系统的可信度
  • 为什么你的 AI 路线图应该数实验，而不是数功能

我会用真实案例逐一讲解这些话题。虽然每个情况都独一无二，但你会看到一些模式，它们与你的领域和团队规模无关。

先从我最常见到的错误说起——这个错误会让 AI 项目还没开始就脱轨。

1. 最常见的错误：跳过错误分析

「工具优先」的思维是 AI 开发中最常见的错误。团队埋头于架构图、框架和仪表盘，却忽视了真正理解「什么有效、什么无效」的过程。

一位客户曾得意地向我展示他们的评测仪表盘：

这种仪表盘预示着失败。

这就是「工具陷阱」——一种信念：只要采用正确的工具或框架（在这个例子里是通用指标），你的 AI 问题就会迎刃而解。通用指标比无用更糟——它们会从两个方面主动阻碍进展：

第一，它们制造出一种「已经在衡量、已经有进展」的错觉。团队以为自己数据驱动，因为有了仪表盘，但他们在跟踪的是与真实用户问题毫不相关的虚荣指标。我见过团队为「帮助度分数」提升了 10% 而庆祝，与此同时他们的真实用户还在基本任务上挣扎。这就像在结账流程坏掉的情况下优化网站加载速度——你在错误的方向上越做越好。

第二，指标太多会撕裂你的注意力。你本该聚焦于对你的具体用例最重要的少数几个指标，却同时在多个维度上试图优化。当一切都重要时，就什么都不重要了。

那替代方案是什么？错误分析——AI 开发中最有价值的一项活动，也始终是投资回报最高的活动。让我用实践中的例子展示有效的错误分析长什么样。

错误分析的流程

当 Nurture Boss 的创始人 Jacob 需要改进他们面向公寓行业的 AI 助手时，他的团队构建了一个简单的查看器来检查 AI 与用户之间的对话。每条对话旁边留有一块空间，用来写关于失败模式的开放式笔记。

标注了几十条对话之后，清晰的模式浮现出来。他们的 AI 在日期处理上很吃力——当用户说「我们两周后约个看房吧」这类话时，66% 的情况会失败。

他们没有伸手去拿新工具，而是：1. 查看真实的对话日志 2. 给日期处理的失败类型分类 3. 构建专门捕捉这些问题的测试 4. 在这些指标上衡量改进

结果呢？他们的日期处理成功率从 33% 提升到了 95%。

下面是 Jacob 本人对这个流程的讲解：

自上而下 vs 自下而上的分析

在识别错误类型时，你可以采用「自上而下」或「自下而上」两种路径。

自上而下的方法从「幻觉」「毒性」这类常见指标加上任务专属指标开始。虽然方便，但它常常漏掉领域特有的问题。

更有效的自下而上的方法迫使你去看真实数据，让指标自然涌现。在 NurtureBoss，我们从一个表格开始，每行代表一场对话。我们对任何不期望的行为写下开放式笔记。然后我们用 LLM 构建一个常见失败模式的分类体系。最后，我们把每一行映射到具体的失败模式标签上，统计每个问题的出现频率。

结果令人震惊——仅仅三个问题就占了全部问题的 60% 以上：

Excel 透视表是个简单的工具，但它管用！

  • 对话流程问题（丢失上下文、尴尬的回复）
  • 转人工失败（没有识别出何时应转给人类）
  • 改期问题（日期处理吃力）

效果立竿见影。Jacob 的团队挖掘出了太多可执行的洞察，以至于他们需要好几周时间才能把已发现问题的修复做完。

如果你想看错误分析的实际操作，我们录制过一次现场演示。

这就引出一个关键问题：怎样让团队轻松地查看自己的数据？答案指向我认为任何 AI 团队都能做的最重要的一笔投资……

2. 最重要的 AI 投资：一个简单的数据查看器

我见过的最具影响力的单项投资，不是花哨的评测仪表盘——而是构建一个定制化的界面，让任何人都能检查自己的 AI 究竟在做什么。我强调「定制化」，因为每个领域都有独特需求，现成工具很少能覆盖。审读公寓租赁对话时，你需要看到完整的聊天历史和排期上下文。处理房产查询时，你需要房源详情和来源文档就在手边。即便是小的用户体验决策——元数据放在哪、暴露哪些筛选器——都可能决定一个工具是被人真正使用，还是被人绕着走。

我见过团队在通用标注界面里挣扎，为了理解一次交互要在多个系统间来回翻找。这种摩擦不断累积：点进不同系统看上下文、把错误描述复制到另外的跟踪表、在工具之间切换核对信息。这些摩擦不只是拖慢团队——它还在主动阻止那种能发现细微问题的系统性分析。

拥有精心设计的数据查看器的团队，迭代速度比没有的快 10 倍。关键是：借助 AI 辅助开发（比如 Cursor 或 Loveable），这些工具几个小时就能建出来。相比回报，投入微不足道。

让我展示我的意思。这是为 NurtureBoss 构建的数据查看器（前面讨论过的那个）：

  • 搜索和筛选会话
  • 标注并添加笔记
  • 汇总并统计错误

一个好的数据标注工具应该做到：

  • 把所有上下文集中在一处。不要让用户在多个系统之间搜寻才能理解发生了什么。
  • 让反馈的捕获毫不费力。一键的「对/错」按钮胜过冗长的表单。
  • 捕获开放式反馈。这让你能捕捉那些塞不进预定义分类体系的细微问题。
  • 支持快速筛选和排序。团队需要能轻松深入特定错误类型。在上面的例子里，NurtureBoss 可以快速按渠道（语音、短信、聊天）或想查看的特定物业来筛选。
  • 提供热键，让用户无需点击就能在数据样例之间导航并完成标注。

用什么 Web 框架无所谓——用你熟悉的就行。因为我是 Python 开发者，我目前最喜欢的 Web 框架是 FastHTML 搭配 MonsterUI，它允许我在一个小小的 Python 文件里同时定义后端和前端代码。

关键是先起步，哪怕很简单。我发现定制 Web 应用体验最好，但如果你刚起步，一个表格也比什么都没有强。随着需求增长，你可以相应演进你的工具。

这带来另一条反直觉的经验：最有条件改进你的 AI 系统的人，往往是最不了解 AI 的人。

3. 赋能领域专家编写提示词

我最近与一家教育创业公司合作，他们用 LLM 构建交互式学习平台。他们的产品经理是一位学习设计专家，会制作详细的 PowerPoint 演示文稿，解释教学原理和示例对话。她把这些讲给工程团队听，然后工程师把她的专业经验翻译成提示词。

但问题是：提示词就是自然语言。让教学专家通过 PowerPoint 传达教学原则，再让工程师把它翻译回英文提示词，制造了不必要的摩擦。最成功的团队颠覆了这个模式——给领域专家工具，让他们直接编写和迭代提示词。

搭桥，而不是当守门人

提示词游乐场（prompt playground）是很好的起点。Arize、LangSmith 和 Braintrust 之类的工具让团队可以快速测试不同提示词、灌入示例数据集、比较结果。下面是这些工具的截图：

  • Arize Phoenix
  • LangSmith
  • Braintrust

但有一个许多团队错过的关键下一步：把提示词开发整合进应用上下文。大多数 AI 应用不只是提示词——它们通常包括从知识库取数的 RAG 系统、协调多个步骤的 Agent 编排，以及应用特定的业务逻辑。与我合作过的最有效的团队走得更远：他们构建我称之为「集成式提示环境」的东西——本质上是真实用户界面的管理员版本，把提示词编辑暴露出来。

这是一个房产 AI 助手的集成式提示环境可能的样子：

  • 用户（房产经纪人）看到的界面。
  • 同一个界面，但带工程与产品团队用来迭代提示词、调试问题的「管理员模式」。

与领域专家沟通的技巧

还有一道障碍常常阻止领域专家有效贡献：不必要的行话。我曾与一家教育创业公司合作，工程师、产品经理和学习专家在会上各说各话。工程师一直说「我们要构建一个 Agent 来做 XYZ」，而实际要做的工作只是写一个提示词。这制造了人为的壁垒——作为真正领域专家的学习专家，觉得自己因为不懂「Agent」而无法贡献。

这种情况到处都在发生。我在法律科技公司的律师、心理健康创业公司的心理咨询师、医疗公司的医生身上都见过。LLM 的魔力在于它通过自然语言让 AI 变得人人可用，但我们常常用技术术语把一切都包裹起来，亲手毁掉这个优势。

下面是一个翻译常见 AI 行话的简单示例：

别说…… 改说……
「我们在实现一个 RAG 方案」 「我们在确保模型拥有回答问题所需的正确上下文」
「我们需要防止提示词注入」 「我们要确保用户没法骗 AI 忽略我们的规则」
「我们的模型有幻觉问题」 「AI 有时会编造内容，所以我们需要核对其答案」

这不是把话降级——而是对你真正在做的事保持精确。当你说「我们在构建一个 Agent」时，你具体在增加什么能力？是函数调用？工具使用？还是只是一个更好的提示词？具体化能帮所有人理解实际发生了什么。

这里有个细微之处。技术术语的存在有其理由——与其他技术相关者对话时，它提供精确性。关键是根据受众调整你的语言。

许多团队此时会提出质疑：「这些都很好，但如果我们还没有数据呢？刚起步时，我们怎么查看样例、怎么迭代提示词？」这就是我们接下来要谈的。

4. 用合成数据冷启动你的 AI 是有效的（哪怕零用户）

我从团队那里听到的最常见的拦路虎是：「我们还没有足够的真实用户数据，所以做不了像样的评测。」这制造了一个鸡生蛋、蛋生鸡的问题——你需要数据来改进 AI，但你需要一个还不错的 AI 才能获得产生数据的用户。

幸运的是，有一个出奇有效的解法：合成数据（synthetic data）。LLM 能生成覆盖你的 AI 将遇到的各种场景的真实感测试用例。

正如我在 LLM-as-a-Judge 那篇文章里写的，合成数据在评测中可以非常有效。Hex 前 AI 负责人 Bryan Bischof 说得极好：

「LLM 出奇擅长生成优秀且多样的用户提示词样例。这既能用来驱动应用功能，也能不动声色地拿来构建评测。如果这听起来有点像大语言蛇在吞自己的尾巴，我和你一样惊讶！我只能说：它管用，发出去。」

生成真实感测试数据的框架

有效合成数据的关键在于选择正确的测试维度。这些维度会因你的具体需求而异，但我发现从三个大类来思考很有帮助：

  • 功能（Features）：你的 AI 需要支持哪些能力？
  • 场景（Scenarios）：它会遇到什么情况？
  • 用户画像（User Personas）：谁在使用它，怎么用？

这些不是你唯一可能关心的维度——你可能还想测试不同的语气、不同的技术熟练程度，甚至不同的地区和语言。重要的是找出对你具体用例有影响的维度。

在我与 Rechat 合作的一个房产 CRM AI 助手项目中，我们这样定义维度：

features = [    "property search",      # 查找符合条件的房源    "market analysis",      # 分析趋势与定价    "scheduling",           # 预约看房    "follow-up"             # 看房后的跟进沟通]scenarios = [    "exact match",          # 恰好一个完美匹配    "multiple matches",     # 需要帮用户缩小范围    "no matches",           # 需要推荐替代选项    "invalid criteria"      # 帮用户修正搜索条件]personas = [    "first_time_buyer",     # 需要更多引导和解释    "investor",             # 关注数字与投资回报    "luxury_client",        # 期望高端贴心服务    "relocating_family"     # 有特定的社区/学校需求]

但定义好这些维度只是成功的一半。真正的挑战是确保你的合成数据真的能触发你想测试的场景。这需要两样东西：

  • 一个有足够多样性的测试数据库，能支撑你的各种场景
  • 一种验证方法，确认生成的查询确实触发了预期场景

对 Rechat，我们维护了一个房源测试数据库，我们清楚其中哪些能触发不同的边界情况。有些团队更喜欢用生产数据的匿名化副本，但无论哪种方式，你都要确保测试数据有足够的多样性来覆盖你关心的场景。

下面是一个示例，展示我们如何用这些维度配合真实数据，为「房源搜索」功能生成测试用例（这只是示意性的伪代码）：

def generate_search_query(scenario, persona, listing_db):    """Generate a realistic user query about listings"""    # Pull real listing data to ground the generation    sample_listings = listing_db.get_sample_listings(        price_range=persona.price_range,        location=persona.preferred_areas    )    # Verify we have listings that will trigger our scenario    if scenario == "multiple_matches" and len(sample_listings) < 2:        raise ValueError("Need multiple listings for this scenario")    if scenario == "no_matches" and len(sample_listings) > 0:        raise ValueError("Found matches when testing no-match scenario")    prompt = f"""    You are an expert real estate agent who is searching for listings. You are given a customer type and a scenario.    Your job is to generate a natural language query you would use to search these listings.    Context:    - Customer type: {persona.description}    - Scenario: {scenario}    Use these actual listings as reference:    {format_listings(sample_listings)}    The query should reflect the customer type and the scenario.    Example query: Find homes in the 75019 zip code, 3 bedrooms, 2 bathrooms, price range $750k - $1M for an investor.    """    return generate_with_llm(prompt)

它生成了这样真实感的查询：

功能 场景 画像 生成的查询
房源搜索 多个匹配 首次购房者 「想在 Riverside 地区找 50 万美元以下的三居室，最好离公园近一些，因为我们有小孩。」
市场分析 无匹配 投资人 「需要 123 Oak St 的可比成交数据。特别想对比两英里半径内类似物业的租金收益率。」

有用合成数据的关键在于把它锚定在真实的系统约束上。对房产 AI 助手来说，这意味着：

  • 使用他们数据库里真实的房源 ID 和地址
  • 纳入真实的经纪人日程与可预约时段
  • 遵守带看限制、提前通知期等业务规则
  • 包含 HOA（业主协会）要求、地方法规等市场特定细节

然后我们把这些测试用例喂给 Lucy（他们的 AI 助手）并记录交互。这给了我们一个丰富的数据集来分析，清楚展示 AI 在真实系统约束下如何应对不同情况。这种方法帮助我们在问题影响真实用户之前就修复它们。

有时你拿不到生产数据库，尤其是新产品。这种情况下，可以用 LLM 同时生成测试查询和底层的测试数据。对房产 AI 助手来说，这可能意味着创建带有真实属性的合成房源——符合市场区间的价格、使用真实街道名的有效地址、与每种物业类型匹配的配套设施。关键在于把合成数据锚定在真实世界的约束上，让它对测试有用。生成健壮合成数据库的具体细节超出了本文范围。

使用合成数据的准则

生成合成数据时，遵循以下关键原则以确保其有效：

  • 让数据集多样化：创建覆盖广泛功能、场景和画像的样例。正如我在 LLM-as-a-Judge 一文中所写，这种多样性帮你发现原本预料不到的边界情况和失败模式。
  • 生成用户输入，而不是输出：用 LLM 生成真实的用户查询或输入，而不是期望的 AI 响应。这能防止你的合成数据继承生成模型的偏见或局限。
  • 纳入真实的系统约束：把合成数据锚定在真实的系统限制和数据上。例如测试排期功能时，使用真实的可预约时段和预订规则。
  • 验证场景覆盖：确保生成的数据真的触发你想测的场景。一个本想测试「无匹配结果」的查询，在你的系统上运行时应当真的返回零结果。
  • 先简单，再加复杂：从直截了当的测试用例开始，再逐步加入细微差别。这有助于隔离问题，并在处理边界情况之前建立基线。

这套方法不只是理论——它已在数十家公司的生产环境中得到验证。许多最初作为权宜之计的做法，即使在真实用户数据可用之后，也成了评测基础设施的永久组成部分。

接下来看看，随着规模扩大，如何维持评测系统的可信度……

5. 维护评测系统的可信度至关重要

这是我反复看到的一种模式：团队搭建了评测系统，然后逐渐对它失去信心。有时是因为指标与他们在线上观察到的现象对不上；有时是因为评测复杂到无法解读。无论哪种，结果都一样——团队退回凭直觉和零散反馈做决策的状态，评测存在的意义被彻底架空。

维护评测系统的可信度，与最初搭建它同等重要。最成功的团队是这样应对这个挑战的：

理解「标准漂移」

AI 评测中最隐蔽的问题之一是「标准漂移」（criteria drift）——随着你观察更多模型输出，评测标准本身也在演化的现象。Shankar 等人在论文《Who Validates the Validators?》中描述了这一现象：

「要给输出评分，人们需要把评价标准外化并定义出来；然而，给输出评分的过程恰恰帮助他们定义这些标准。」

这造成了一个悖论：在见过大量输出之前，你无法完整定义评测标准；但你首先需要标准才能评测那些输出。换句话说，在人工评判 LLM 输出之前就完整确定评测标准，是不可能的。

我在与 Honeycomb 的 Phillip Carter 合作他们的 Query Assistant 功能时亲历了这一点。当我们评估 AI 生成数据库查询的能力时，Phillip 注意到一件有意思的事：

「看 LLM 如何拆解它的推理，让我意识到我在评判某些边界情况时标准并不一致。」

审读 AI 输出的过程，帮助他更清晰地表述了自己原本隐含的评判标准。这不是规划不善的信号——这是与产出多样、有时出人意料的输出的 AI 系统打交道的固有特征。

那些维持住评测可信度的团队拥抱这个现实，而不是与之对抗。他们把评测标准当作与自己对问题空间的理解同步演化的活文档。他们也认识到，不同相关者可能持有不同（有时互相矛盾）的标准，他们的做法是调和这些视角，而不是强推单一标准。

构建值得信赖的评测系统

那么，如何构建一个尽管存在标准漂移仍然值得信赖的评测系统？以下是我发现最有效的方法：

1. 优先使用二元判断，而非任意刻度

正如我在 LLM-as-a-Judge 一文中所写，二元决策提供的清晰度是更复杂的刻度常常遮蔽的。面对 1-5 分制时，评分者经常在「3 分和 4 分的区别」上纠结，引入不一致与主观性。「还算有帮助」和「有帮助」的区别究竟是什么？这些边界情况消耗不成比例的心智能量，并在评测数据中制造噪声。而且即便企业用了 1-5 分制，他们最终也不得不划定「足够好」或触发干预的界线，终究还是要做一个二元决策。

相反，二元的通过/失败迫使评分者做出清晰的判断：这个输出达成了它的目的没有？这种清晰也延伸到进度衡量——通过率提升 10% 立刻有意义，而 5 分制上提升 0.5 分则需要解读。

我发现抗拒二元评测的团队，往往是因为想保留细微差别。但差别并没有丢失——它只是转移到了伴随判断的文字批评（critique）里。批评提供了丰富的上下文：为什么通过或失败、哪些具体方面可以改进，而二元判断则就「是否需要改进」给出可行动的清晰结论。

2. 用详细的文字批评增强二元判断

二元决策提供了清晰度，而当它与详细批评配对、捕捉「为什么通过或失败」的细微差别时，效果最好。这种组合给你两全其美的东西：清晰、可行动的指标，加上丰富的上下文理解。

例如，评估一个正确回答了用户问题但包含不必要信息的响应时，一条好的批评可能这样写：

「AI 成功提供了所要求的市场分析（通过），但包含了与投资问题无关的、关于社区人口统计的过多细节。这让回复比必要的更长，并且可能分散注意力。」

这些批评的作用不止于解释。它们迫使领域专家把隐性知识外化——我见过法律专家从「感觉哪里不对」的模糊直觉，进步到清晰指出引用格式或推理模式上的具体问题，从而可以被系统性解决。

把这些批评作为少样本（few-shot）示例放进裁判提示词时，它们能提升 LLM 在复杂边界情况上的推理能力。我发现与没有示例批评的提示词相比，这种方法常常让人工评测与 LLM 评测的一致率提高 15-20%。这些批评还是生成高质量合成数据的绝佳原料，形成改进的飞轮。

3. 衡量自动化评测与人类判断的一致性

如果你在用 LLM 评估输出（规模化时这往往是必要的），定期检查这些自动评测与人类判断的一致程度至关重要。

考虑到人们天然倾向于过度信任 AI 系统，这一点尤其重要。正如 Shankar 等人在《Who Validates the Validators?》中指出的，缺乏验证评测器质量的工具令人担忧：

「研究表明人们倾向于过度依赖和过度信任 AI 系统。例如，在一次广受关注的事件中，MIT 的研究者在 arXiv 上发布预印本，声称 GPT-4 可以在 MIT EECS 考试中拿到高分。数小时内，这项工作就被证伪……原因正是过度依赖 GPT-4 给自己打分。」

这种过度信任的问题不止于自我评估。研究表明，LLM 会被诸如选项排列顺序这类简单因素影响，甚至提示词里看似无害的格式变化也会带来偏差。没有严格的人工验证，这些偏差会悄悄侵蚀你的评测系统。

与 Honeycomb 合作时，我们跟踪了 LLM 裁判与 Phillip 评测之间的一致率：

LLM 评测者与人类专家的一致率。更多细节见原文链接。

经过三次迭代，我们达到了 90% 以上的一致率，但这笔投入换来的是一个团队可以信赖的系统。没有这个验证环节，自动评测往往会随时间偏离人类预期，尤其当输入分布发生变化时。相关内容可以在 Hamel 的博客上读到更多。

Eugene Yan 的 AlignEval 之类的工具漂亮地演示了这个对齐过程。它提供一个简单的界面：上传数据，用二元的「好/坏」标注样例，然后用这些人工判断来评估基于 LLM 的裁判。它的有效之处在于简化了工作流——你可以快速看到自动评测在哪些地方与你的偏好背离，据此细化标准，并随时间衡量改进。这种做法强调：对齐不是一次性的配置，而是人类判断与自动评测之间持续的对话。

规模化而不失去信任

随着 AI 系统成长，你不可避免地面临减少评测人力投入的压力。这正是许多团队出错的地方——他们过快地自动化了太多东西，丢掉了让评测保持接地气的人类连接。

最成功的团队采取更审慎的路径：

  • 从高人力参与起步：早期，让领域专家评估相当大比例的输出。
  • 研究一致性的模式：与其急于自动化评测，不如先弄清自动评测在哪些方面与人类判断一致、在哪些方面背离。这帮你识别哪些类型的案例需要更细致的人工关注。
  • 策略性抽样：与其评估每一个输出，不如用统计技术抽样那些信息量最大的输出，特别聚焦一致性最弱的区域。
  • 保持定期校准：即使在规模化之后，也要继续定期把自动评测与人类判断对比，用这些对比来细化你对「何时可以信任自动评测」的理解。

评测的规模化不只是减少人力——而是把人力引导到能创造最多价值的地方。把人的注意力集中在最具挑战性或信息量最大的案例上，你就能在系统成长的同时守住质量。

现在我们已经讲完如何维持评测的可信度，接下来谈谈你在规划 AI 开发路线图上应该做出的一项根本转变……

6. 你的 AI 路线图应该数实验，而不是数功能

如果你做过软件开发，你熟悉传统路线图：一列功能，配上目标交付日期。团队承诺在特定截止日期前交付特定功能，成功与否以达成目标的程度来衡量。

这种方法用在 AI 上会惨败。

我见过团队承诺「二季度上线情感分析」「年底前部署基于 Agent 的客服」，结果发现技术根本达不到他们的质量线。他们要么为了赶截止日期发布不及格的东西，要么彻底错过截止日期。无论哪种，信任都被侵蚀。

根本问题在于：传统路线图假设我们知道自己能做到什么。对常规软件而言这通常成立——只要有足够的时间和资源，大多数功能都能可靠地构建出来。而对 AI，尤其是在技术前沿，你一直在试探可行性的边界。

实验 vs 功能

Hex 前 AI 负责人 Bryan Bischof 向我介绍了他称之为「能力漏斗」（capability funnel）的 AI 路线图方法。这种策略重构了我们对 AI 开发进展的思考方式。

能力漏斗不把成功定义为发布某个功能，而是把 AI 表现分解为渐进的效用层级。漏斗顶端是最基础的功能——系统能不能给出回应？漏斗底端是彻底解决用户的待完成任务（job to be done）。两者之间是效用递增的各个阶段。

例如，对一个查询助手，能力漏斗可能是这样：1. 能生成语法上有效的查询（基础功能）2. 能生成可以执行而不报错的查询 3. 能生成返回相关结果的查询 4. 能生成匹配用户意图的查询 5. 能生成解决用户问题的最优查询（完整方案）

这种方法承认 AI 的进展不是二元的——而是在多个维度上逐步提升能力。它还提供了一个框架，让你在尚未抵达最终目标时也能衡量进展。

与我合作过的最成功的团队，把路线图围绕实验而非功能来组织。他们不承诺具体结果，而是承诺一个实验、学习与迭代的节奏。

亚马逊应用科学家 Eugene Yan 分享了他如何向领导层规划机器学习项目——这个流程最初为传统机器学习设计，但同样适用于现代 LLM 开发：

「这是一个常见的时间线。首先我花两周做数据可行性分析，即『我有合适的数据吗？』……然后我再花一个月做技术可行性分析，即『AI 能解决这个问题吗？』在那之后，如果依然可行，我会花六周构建一个可以 A/B 测试的原型。」

虽然 LLM 可能不像传统 ML 那样需要同样的特征工程或模型训练，但底层原则不变：给探索设定时间盒（timebox），建立清晰的决策点，在投入完整实现之前先证明可行性。这种做法让领导层确信资源不会被无止境的探索浪费，同时给团队边学边调整的自由。

基石：评测基础设施

让基于实验的路线图运转起来的关键，是健壮的评测基础设施。没有它，你的实验有没有效果只能靠猜；有了它，你就能快速迭代、检验假设，并在成功之上继续构建。

我在 GitHub Copilot 的早期开发中亲眼见过这一点。大多数人不知道的是，那个团队在构建精密的离线评测基础设施上投入巨大。他们建立的系统可以用 GitHub 上的海量仓库语料来测试代码补全，利用高质量代码库中已有的单元测试作为验证补全正确性的自动化手段。这是一项巨大的工程——他们要构建能大规模克隆仓库、配置环境、运行测试套件、分析结果的系统，同时还要应对编程语言、框架与测试方法的惊人多样性。

这不是浪费时间——它是加速一切的基石。有了扎实的评测，团队运行了数千个实验，快速识别什么有效，并能满怀信心地说「这个改动把质量提升了 X%」，而不是凭感觉。评测的前期投入看似缓慢，但它避免了「改动到底是帮忙还是帮倒忙」的无尽争论，并在后期大幅加速创新。

向相关者传达这一切

当然，挑战在于高管们往往想要确定性。他们想知道功能什么时候发布、发布后能做什么。如何弥合这道鸿沟？

关键是把对话从产出（output）转向成果（outcome）。不要承诺在特定日期交付特定功能，而是承诺一个能最大化实现预期业务成果几率的过程。

Eugene 分享了他如何处理这类对话：

「我试着用时间盒安抚领导层。三个月结束时，如果可行，我们就推进到生产。在任何一步，如果不可行，我们就转向。」

这种做法给相关者清晰的决策点，同时承认 AI 开发固有的不确定性。它还有助于管理时间预期——你不是承诺六个月后交付功能，而是承诺三个月后对「这个功能是否可行」有清晰的认识。

Bryan 的能力漏斗提供了另一个有力的沟通工具。它让团队能够展示在漏斗各阶段上的具体进展，即使最终方案还没就绪。它也帮助高管理解问题出在哪里，从而就资源投向哪里做出明智决策。

通过分享失败建立实验文化

这种方法也许最反直觉的地方，是对从失败中学习的强调。在传统软件开发中，失败往往被隐藏或淡化。在 AI 开发中，失败是学习的主要来源。

Eugene 在他的组织里通过他称之为「fifteen-five」的机制把这一点制度化——一份写 15 分钟、读 5 分钟的周报：

「在我的 fifteen-five 里，我会记录我的失败和成功。在我们团队内部，我们还有每周的『免准备分享会』，讨论各自在做什么、学到了什么。我做分享时，会特意分享失败。」

这种实践把失败正常化为学习过程的一部分。它表明即使经验丰富的从业者也会走进死胡同，而公开分享这些经历能加速团队学习。通过赞美实验的过程本身而不只是结果，团队营造出一种让人们敢于冒险、敢于从失败中学习的环境。

一条更好的前进道路

那么，基于实验的路线图在实践中是什么样子？这是 Eugene 参与过的一个内容审核项目的简化示例：

「我被要求做内容审核。我说：『我们能不能达成那个目标，是不确定的。甚至用我们的数据这个目标是否可行、什么机器学习技术管用，都不确定。但这是我的实验路线图。这是我要尝试的技术，我会以两周为节奏向你们汇报。』」

这份路线图没有承诺具体的功能或能力。它承诺的是对可能路径的系统性探索，外加定期检查点以评估进展，并在必要时转向。

结果很有说服力：

「头两三个月，什么都不奏效。……然后突破出现了。……一个月之内，那个问题被解决了。所以你看，第一季度甚至头四个月毫无进展。……但随后你会看到，突然之间某个新技术、新范式、新的重构思路出现，一下子解决了 80% 的问题。」

这种模式——长时间的表面失败之后突然突破——在 AI 开发中很常见。传统的功能路线图会在数月「失败」之后杀掉这个项目，从而错过最终的突破。

聚焦实验而非功能，团队就为这类突破的出现创造了空间。他们还构建了让突破更可能出现的基础设施与流程：数据管道、评测框架和快速迭代周期。

与我合作过的最成功的团队，都先构建评测基础设施，再承诺具体功能。他们打造让迭代更快的工具，聚焦支持快速实验的流程。这条路起初似乎更慢，但从长远看，它通过让团队快速学习与适应，戏剧性地加速了开发。

AI 路线图的关键指标不是发布的功能数——而是运行的实验数。能跑更多实验、学得更快、迭代更迅速的团队才会赢。而快速实验的基石始终如一：健壮、可信、让所有人对其结果有信心的评测基础设施。

把你的路线图围绕实验而非功能重新组织，你就在自己的组织里创造了类似突破出现的条件。

结论

在这篇文章里，我分享了我观察数十个 AI 实现总结出的模式。最成功的团队不是工具最精密或模型最先进的团队——而是掌握了衡量、迭代与学习这些基本功的团队。

核心原则出奇地简单：

  • 看你的数据。没有任何东西能替代审视真实样例带来的洞察。错误分析始终揭示投资回报最高的改进点。
  • 构建消除摩擦的简单工具。让人轻松查看 AI 输出的定制数据查看器，比装着通用指标的复杂仪表盘产出更多洞察。
  • 赋能领域专家。最懂你业务领域的人，往往最能有效改进你的 AI，无论他们的技术背景如何。
  • 策略性地使用合成数据。你不需要真实用户就可以开始测试和改进你的 AI。用心生成的合成数据能为你的评测流程冷启动。
  • 维护评测的可信度。带详细批评的二元判断既创造清晰度又保留细微差别。定期的一致性检查确保自动评测保持可信。
  • 围绕实验而非功能组织路线图。承诺一个实验与学习的节奏，而不是特定日期交付特定结果。

这些原则不挑领域、团队规模或技术栈。从早期创业公司到科技巨头，从客服到代码生成，它们都行之有效。

延伸资源

如果你想深入这些话题，以下资源可能有帮助：

  • 我的 博客，有更多关于 AI 评测与改进的内容。我的其他文章更深入地探讨构建有效的 LLM 裁判、实现评测系统等 AI 开发主题。也推荐 Shreya Shankar 和 Eugene Yan 的博客，它们同样是这些主题的优质信息来源。
  • 我与 Shreya Shankar 在 AI Evals For Engineers & PMs 课程中教授这些方法。课程包含实操练习与答疑时间。

延伸阅读：想把这套方法放进交付工作流，可以阅读 FDEChina 的 AI Coding 专题与 实践指南，也可以看看 FDE 能力模型中对评测与迭代能力的定位。

本文由 FDEChina 团队翻译自原文，转载已注明出处；如需引用请以原文为准。