“难以评估”是一种产品缺陷信号

中文精读

原文约 3,674 词 · 14 节

1. 开篇：难以评估是一种产品缺陷

   • 过去三年作者专注 AI 评估（evals），最常听见的反驳是“我们的产品很难评估”。
   • 作者把这种说法视为产品层面的“异味”（product smell）：你自己难以核验的产物，用户往往也难以核验；最糟情况下用户得从头重做一遍才能确认结果。
   • 他主张先让产品易于核验，再去搭建评估体系；文章将用三个亲历的咨询案例配前后草图来说明设计原则，最后给出把该模式迁移到自己产品的方法。

2. 例一：AI 数据助手

   • 几乎所有受访公司都在做内部 AI 数据助手：提问业务问题（如某产品上季度净收入），它找数据源、跑查询、给答案，目的是减少对数据分析师的依赖。
   • 常见错误是只输出答案——用户除了重做一遍没有任何可核对的东西。
   • 作者列出数据科学家验证指标的六种做法：与可信任来源（仪表盘、报告、同事已审过的分析）比对数量与中间计算；确认指标定义（净收入是否含退货、折扣）；用相关量做合理性检查（销量、独立客户数）；拆到聚合之下的维度看分布；读 SQL 并改跑以检验假设；把无法核验的步骤单独标出。
   • 改进方案做两层披露：聊天回复只呈现值得看的要点（来源与分析作者、指标定义是否匹配治理定义、中间计算、未匹配项），并可“打开为 notebook”查看完整分析。

3. 改进草图：Notebook 里的呈现结构

   • Sketch 中的 notebook（net_revenue_product_a.ipynb）注明改编自 Priya Nair 于 2026 年 6 月 28 日撰写的《Quarterly revenue review》，侧栏有目录和助手两个标签。
   • 聊天答案给出 $4.21M 并附细节：指标定义 gross − returns − discounts 与治理定义一致；退货 −$0.7M 标注“无可信来源”；12,480 个独立客户中有 183 个未匹配（CRM 与 Billing 之间）。

4. 第 4 节：Product A 的净收入（Q4 FY25）

   • 这一小节以“Product A 上季度净收入是多少？”这个问题开头，先给出短答案 $4.21M。
   • 随后说明这个 notebook 的用途：展示这个数字是如何被构建出来的，以及哪些环节对照了可信来源（trusted source）。
   • 该小节本身只交代短答案与 notebook 的展示目的，具体的定义读取、查询和核对步骤在后面的小节中展开。

5. Notebook 第 2 节：Product A 的净收入

   • 直接对订单行（order lines）聚合，算出该季度 Product A 的净收入为 4,210,442。
   • 这个数正是聊天回复中报告的 $4.21M，答案与查询结果形成可对照关系。

6. Notebook 第 3 节：分布合理性检查

   • 按区域拆分 Product A 的净收入并绘图，用来对照上季度结构、看是否有什么不对劲。
   • 结果：West 174 万、Central 116 万、East 89 万、Intl 42 万（美元）；West 与 Central 贡献大部分收入，国际业务只是小尾巴。

7. Notebook 第 4 节：列出无法核验的部分

   • 有两个输入没有可信来源可对照，作者不把它们当成已确定，而是各留成一个可运行、可编辑的 cell 供人深挖。
   • 第一个是代理给出的 −$0.7M 退货数是估算；运行查询查看 Q4 退货表行数，结果 n_rows 为 0、returns 为 NULL。

8. Notebook 结尾：Q4 退货与客户归属的未决项

   • Q4 退货数据尚未加载，因此 −$0.7M 目前无量可对；另一处未决项是客户表连接。
   • 12,480 个独立客户中有 183 个只存在于 Billing 而不在 CRM，导致部分收入无法归属；查询列出这些客户，如 BIL-44821 金额 18,400、BIL-39105 金额 12,950。
   • 这 183 行合计 $61,540 收入归属不确定，被显式呈现出来，由人在采信总额前解决。
   • notebook 自上而下依次是：代理所做的假设、跑过的查询及其返回的数字、以及明确列出的无法核验项；Notebook 里也有 AI 助手可追问，并可发布回知识库供未来分析检索，形成良性循环。

9. 改进要点与与评估的关系

   • 代理可选择性地从已审阅的分析中检索，界面显示用了哪一篇、由谁撰写。
   • 采用渐进披露：聊天回复呈现来源、假设、问题等高价值信息，用户可按需打开交互式 notebook 看完整上下文。
   • notebook 按“便于核验”组织：先给假设与来源，再给查询与结果，再拆分布做合理性检查，最后以可运行的未核验项收尾。
   • 作者把 Hex 举为该类产品中自己最喜欢的例子，认为它把 notebook 与 chat 结合得最好。
   • 与评估的关系：产品为核验而设计后，标注更便宜、评估能拿到更好的信号，用户也得到更好的产品。

10. 例二：体育课教案生成器

    • 一位创始人在做面向 K-12 教师的 AI 体育教案工具：教师输入年级、课时长度、室内外、可用器材，工具从零写出一份教案——只输出教案，因此难以核验。
    • 作者反问：教师到底在意什么？教师最快的信任方式是看到和自己相似的老师已经在用，并且愿意看到别人怎么做以学习新做法。
    • 改进设计：从学校中实际在用的、经审阅的教案出发，生成时显示沿用了哪份教案、谁在用，以及针对本次约束改了什么（diff）。
    • 草图显示教案改编自 Dana Ruiz 的方案，用于 14 所学校、今年运行 30 多次、符合 SHAPE 标准；只列出 2 处修改（热身由 2 圈/10 分钟改为 1 圈/8 分钟以适配 45 分钟课；主活动由 4 站 8 球圈改为 3 站 6 球锥筒以匹配器材），可接受或拒绝，且每条都给出改动理由。
    • 这样产品实现也更简单：不必往提示里塞几百个示例，而是抽取关键维度、检索最接近的方案再做适配；需要测试的面变小，可以自动验证“选对了锚点教案”和“每处修改都遵守约束”。

11. 例三：工伤赔偿医学报告

    • 工具读取病历（问诊表、影像报告、治疗记录、既往检查）生成篇幅常达 50 页以上的专家意见报告；只有这一份叙述作为输出，医生得重读整份病历核对每条陈述，耗时可能和从头写一样。
    • 此处问题与前两例相同但风险更高：医生对报告负责，必须自己回查事实与推论。
    • 作者建议不要去假装 50 页意见好核验，而是让产品像研究助手而非报告生成器：提取相关事实并链接回原文页码；标出两次检查相互矛盾或病历留白之处；由医生解决矛盾、补齐空缺；最后用已核验过的内容拼出报告。
    • 改进草图中显示 18 份记录已核 9 份、24 条发现中仍有 6 条待审，逐条列出矛盾（如直腿抬高试验治疗医生记右侧阳性 vs 既往 IME 记阴性）、关键事实（2019 年腰椎劳损影响因果关系判断；MRI 提示 L4-L5 已有退变）与开放问题（2025 年 3 月 18 日后无影像）。
    • 该设计同样更易构建和评估：有了可评分的细粒度单元，例如某处矛盾是否真实、某条引用是否支持某主张。

12. 推广这一模式

    • 关键前提是理解用户如何核验 AI 产物：有时需要拼装支撑性证据，有时需要重构整个流程把用户放进回路（如工伤报告案例）。
    • 作者给出四个引导设计的问题：用户实际需要检查什么？可以拿什么可信物来对照？专家用哪些信号或启发式来辅助核验？有哪些更小的单元可以让用户接受、编辑或拒绝？
    • 贯穿三例的共同主线是溯源（provenance）：显示每部分来自哪里、链接可查看详情，再用渐进披露避免来源把用户淹没。
    • 需要核验的内容随信任增长而改变：早期数据代理应突出指标定义来自哪里，用户信任后再默认折叠。
    • 这些原则对看似好评估的领域同样适用：写代码有测试、类型、diff，但 Cursor 与 Devin 仍会录一段 UI 改动短视频，让人不必自己复现即可确认。

13. 这些都不新鲜

    • 评估思路与好产品设计是一致的：收集支撑数据、把流程拆成更小单元，也让自动评分更容易。
    • 作者强调这些想法并非新创：观察专家怎么做、弄清他们在建之前检查什么，叫需求发现（needfinding）；医学这类研究密集型工作中有“意义建构”（sensemaking）这一设计目标，即对一批证据建立可据以推理的结构化理解。
    • 之所以仍要提醒：AI 之前，核验往往在创作产物过程中顺带完成；有了 AI，核验成了瓶颈，值得显式对待。

14. 视频讲解与脚注

    • 作者录了一段短视频走查这些例子，供偏好观看而非阅读的人使用，并感谢 Shreya Shankar 与 Isaac Flath 对本文的反馈。
    • 脚注中，作者提及其 AI 评估主题页与《AI Evals for Engineers and PMs》课程；引用 Lenny Rachitsky 的推文称某数据科学团队大部分工作变成审阅 PM 和工程师半成品 AI 分析，其中一半是错的。
    • 脚注还提到 Airbnb 内部工具 Knowledge Repo（数据科学家发布深挖 notebook 的地方，是快速获取项目背景的方式之一）；Hex 的 AI 由身为数据科学家的 Bryan Bischof 主导创建；Cursor 演示与 Devin 文档记录了 UI 改动的测试与录像；
    • needfinding 出自 Patnaik 与 Becker 的论文，sensemaking 出自 Russell 等人的论文。