LitPivot 给 AI 创始人的启发：让证据真正改变产品方案

Ai2 在 10 月 23 日介绍的 LitPivot，给 AI 应用开发者提出了一个值得认真对待的问题：新证据能否真正改变你的想法，还是 AI 只会把原来的产品故事讲得更有说服力？这个研究系统把方案编辑、相关文献和有原文依据的批评放进同一流程。对创始人有用的，是它们之间的联系，而不只是多了一种生成点子的方法。

对非技术创始人和小型产品团队来说，一份写得很完整的方案，可能同时掩盖三种不确定性：用户的问题是否重要、拟议方案是否带来改善、计划中的测试能否暴露失败。把它们拆成不同的主张；证据变了，方案也应随之改变。 否则，AI 写作越快，团队可能越快投入一个缺少依据的方向。

本文先解释 LitPivot 公告与研究能支持哪些结论，再给出面向产品探索的改编方法。你会得到一个完整场景、一份可复用决策表，以及一套帮助团队判断“下个开发周期之前该先查清什么”的简短评审流程。这是我们提出的产品工作方法，尚未经 LitPivot 研究验证；我们没有使用该原型，也没有开展客户实验。

1. 这次发生了什么，研究究竟证明了什么

今天值得关注的是 Ai2 于 10 月 23 日发布的 LitPivot 介绍。项目由 Ai2 与宾夕法尼亚大学研究者合作完成。研究者可以选中方案的一部分、选择相关论文、查看附有原文片段的批评，再接受、编辑或拒绝修改建议。系统区分问题、拟议贡献与评估计划；某处改动后，下一步值得阅读的文献也可能改变。

论文当前版本早于这篇公告：arXiv 记录始于 4 月，9 月已有修订。因此，热点是已有研究项目获得新的介绍与关注，不能写成昨天刚上线的全新商业产品。公告没有确立普遍开放使用、定价，或导入私有客户访谈的能力。不要基于这些尚未确认的条件安排采购或接入。

论文报告的对照研究有 17 名研究者参与，基线是文本编辑器配合 AI，两种条件使用同一批论文。专家评价关注的是方案使用相关文献作为依据的程度；新颖性与实用性的改善感受来自参与者自评。另有 5 人围绕自身项目进行的探索性研究。这些结果在各自场景内值得关注，但并未测量创业需求、营收或产品与市场的匹配程度。

这些边界决定了创始人该怎样使用这条消息：借鉴一个值得尝试的流程，再在自己的场景中检验它。不能宣称“AI 根据文献修改过方案，生意就得到验证”。一份方案即使与已有研究衔接得很好，也可能无人愿意购买、交付难度过高，或早已存在更便宜的解决办法。

2. 把产品方案拆成可以被质疑的主张

这里的“主张”，指能够被证据支持、缩小范围或反驳的陈述。“假设”是团队目前需要它成立、却尚未确认的主张。“决策”则是在仍有不确定性时投入时间或资源。区分这三个概念，能防止流畅的段落把假设悄悄写成事实。

产品工作可以拆成三个可独立修改的部分：用户的问题、计划带来的改善，以及验证方式。这是受 LitPivot 研究结构启发的改编，并非声称原型自带某种“创始人模式”。每一部分都应使用普通语言，让同事能明确表示不同意，而不是面对一串只能点头的术语。

例如，问题可以是“小型代理公司难以追踪分散在消息中的客户请求”；改善可以是“生成一份附有来源链接的未解决请求清单”；测试则可以是“请负责人回看一个近期项目，把草稿与当时实际需要完成的工作对照”。三个句子回答不同的问题，其中一个得到正面反馈，并不能替另外两个作答。

Google 的 People + AI Guidebook 用户需求章节建议从真实工作流程出发，判断 AI 是否提供独特价值。这是产品探索的背景指导，不是证明本文决策表有效的实验。落实到当前例子，就是认真考虑共享收件箱、表单或更清晰的责任分工，能否更简单地解决问题。

在 AI 方案旁边写出一个明确的替代办法。如果团队说不清 AI 版本相较之下改善了什么，就把这一点保留为待确认事项。仍然可以制作原型，但目的应是查清差异，而不是演示一个团队早就决定相信的结论。

3. 按证据能回答的问题选择材料

论文可以支持技术上的可能性；当前产品文档可以确认有记录的功能或限制；访谈可以揭示一个人对自身经历的描述；观察任务则能呈现他在特定场景下实际做了什么。没有哪类材料能包办所有证明。你需要写明，它与眼前这条产品主张究竟有什么联系。

NN/G 的用户访谈指南区分了受访者描述的经历与研究者直接观察到的设计使用行为。当创始人听到客户对拟议助手很感兴趣时，这个区别尤其重要。对话有助于理解困扰、用户自己的说法和现有变通办法，却不能单独证明用户会在真实工作中成功使用该功能。

假设在一次虚构的探索访谈中，有人说自己很想要自动跟进客户的功能。应把它记录为“表达兴趣”，同时保留语境和当时的提问。不能悄悄改写成“愿意授权发送消息”“愿意付费”，或“目前确实经常漏掉跟进”。更强的判断，各自都需要新的观察。

每个重要来源都应记录出处、日期、情境，以及它能支持的具体陈述，也要注明它回答不了什么。竞品文档也许能证明市场上存在请求追踪功能，却不能证明目标客户知道它、或认为它已经足够好。技术论文可能让信息提取显得可行，却不能证明它能处理客户杂乱的真实消息。

还要区分独立证据与重复传播。同一篇公告被五篇文章转述，底层仍是一条来源；同一位热情设计合作伙伴的多次评论，仍主要代表一个人的视角。链接和摘录的数量很容易统计，也很容易让团队误以为自己已经考察了多种独立情境。

4. 完整场景：先缩小代理公司助手的承诺

设想一个虚构的两人团队，正在为小型设计公司开发 AI 助手。初版方案承诺读取客户沟通、找出所有未完成请求，并自动发送跟进消息。这里没有真实客户发现；下面的不同分支，用来说明不同证据应该怎样改变决策。

团队先请一位公司负责人回顾最近完成的项目。取得许可后，查看他实际如何追踪请求。假如负责人并不难找到请求，真正头疼的是判断新要求是否超出原先约定的服务范围，这就会削弱最初的“检索困难”假设。再做一个搜索界面，并不能直接解决他描述的判断难题。

此时，问题应改成“找出可能涉及范围变化的事项，交给负责人审阅”。改善主张也要同步改变：产品可以整理疑似相关请求及协议原文，由负责人判断哪些可能超出范围。测试自然也要变。只统计助手列出多少请求已不够，团队需要了解这种对照能否帮助负责人作出有依据的决定。

再看另一种可能。假如负责人确实会漏掉请求，但已有一套有效追踪工具，只是配置过程太繁琐，那么有价值的方向可能是简化录入，或把消息导入现有系统。证据支持的是继续调查既有流程中的摩擦，而不是预先认定需要一个新的自主 Agent。

第三种分支没有那么振奋，却同样有价值：这个项目不典型，负责人拿不出相关例子，或能提供的消息没有覆盖请求真正进入的渠道。此时证据不足。下一步应该是寻找另一位合适参与者，或取得范围恰当的材料，而不是挑一个最能讲出好故事的产品方向。

这些分支的价值，在于下一次投入会发生可见变化。问题不同，原型、招募对象与成功标准都应调整。如果无论出现什么发现，最后都决定开发同一个自动跟进 Agent，那么所谓探索更像是在推销已经选定的答案。

5. 一份可复用的“主张—证据—决策”表

每次用这张表处理一个重要的不确定性即可。它是建议使用的团队工具，不是经过验证的评分量表。不要把所有项目合并成一个置信度分数：技术可行性的强证据，不能抵消用户问题尚未成立这一缺口。

修改主张时保留原来的措辞，新增带日期的版本，并写明是哪条证据促成调整。这样，其他同事才能分清真正的学习与事后的故事重构。简短记录即可：原来相信什么、什么材料提出挑战、现在准备怎样做，以及还有什么不知道。

如果某个来源无法查看，就标记为不可核验，不要把助手的摘要当成已确认材料。如果保密要求让同事无法接触原始记录，应安排有权限的人审阅，或保留这一限制。决策表的作用是让不确定性更容易讨论，不是鼓励把私有材料分享给更多人。

每次评审都要落到实际决定。继续研究可以是合理选择，前提是某个明确缺失的观察可能改变下一次投入。但不能因为表格永远填不满，就无限延长探索。为下一步划定范围、指定负责人，并解释这一步为什么值得花费时间。

6. 先找反例，再让 AI 改写

如果助手只检索支持材料，一条缺少依据的产品思路也会显得越来越“研究充分”。请求改写方案前，先问什么发现会让当前方向不那么值得做：已有足够好的变通办法、用户不愿接受拟议自动化、问题出现频率很低，或真正的困难在别处，都值得主动寻找。

探索问题的措辞会影响答案。NN/G 关于诱导式提问的指南解释了访谈者怎样在无意中把预期答案塞进问题。回到代理公司场景，直接问“AI 范围评估助手能帮你省多少时间”，已经假定困难存在、方案合适。请对方描述上一次范围争议，会给意外信息留下更多空间。

可以让 AI 对同一段材料提出不同解释，但每种解释都要标成暂定。比如，有人说某条客户请求“很烦”，可能涉及时间、语气、付款，也可能涉及范围。没有进一步语境时，助手不应自动选择最符合产品故事的解释。一句追问，可能比更精美的总结更有价值。

一种可用的指令是：指出材料支持哪条主张、最有力的替代解释是什么，以及下一次观察如何区分这两种解释。事实陈述要附链接或内部记录编号，同时允许明确回答“目前证据不足”。这是帮助审阅的方法，并不能保证模型的推理一定有据可查。

把相反材料留在工作方案中，不要塞进生成投资人摘要时会消失的附录。与此同时，一条反例也不必自动否定整个产品。它可能意味着更窄的用户群体、某个适用条件，或原主张写得不准确。创始人需要决定，哪种解释值得继续测试。

7. 产品承诺改变，测试也必须改变

产品转向经常在评估环节悄悄失效：承诺已经从“找到请求”改成“辅助判断范围”，团队却继续只测提取准确率。于是，一个技术上漂亮的结果，可能批准了一个价值主张根本没被检验过的功能。

对修改后的代理公司助手，要分别检查：它是否找到相关材料、是否忠实呈现材料，以及负责人能否据此完成预期判断。附有来源的对照也可能失败：遗漏关键协议条款，把含糊请求写成确定事实，或者让审阅输出比原来的人工方法更费力。

测试前先写清，什么结果会使团队继续、缩小范围或停止。根据决策后果与成本设定标准，不要直接借用一个通用通过率。探索性测试可以发现明显的可用性问题，却不能估计整个市场的可靠成功率。日后若要发表量化结论，抽样与测量设计也必须足以支持它。

把现有替代办法放进评审。请参与者用当前方法完成一个适合比较的任务，记录材料、熟悉程度和任务难度方面的差异。这属于形成性比较，并不是随机实验得到的因果估计；但它仍能揭示原型是否增加步骤，或让原本清楚的决策变得更困难。

展示原型之前，先请负责人说明一个合适历史案例的实际结果，以及当时依据的材料。把这份说明与 AI 输出分开保存，避免让 AI 建议变成自己的标准答案。如果负责人和另一位获授权的审阅者对范围有分歧，就记录分歧，不要通过多数投票宣称助手正确。产品也许需要同时呈现几种解释。这个练习用于审视工作流程，不能确定协议的法律含义。

失败也要进入结果记录。助手无法访问来源、没有生成有用对照，或必须由创始人先修好输出，都属于流程的一部分。排除这些情况，会让一次顺畅演示代替真实体验。随后再决定，应该修改产品、缩小支持场景，还是继续调查。

8. 让人能审阅、纠正并保留最终决定权

如果你正在开发批评方案或综合客户证据的 AI 功能，界面本身就是可靠性的一部分。作决定的人应能方便地查看原始材料、AI 的解释和建议修改。引用链接的价值，是帮助检查主张依据，而不是给自信的句子添加装饰。

微软的人机 AI 交互指南提供了有关能力说明和纠错支持的既有设计指导，并不验证任何特定的当前模型。落实到这个产品，可以让用户拒绝某种解释而不删除原始证据，也可以编辑建议，同时清楚保留最终决定出自人类这一事实。 Google 关于可解释性与信任的指南强调恰当依赖系统，并向用户提供可理解的信息。内部研究助手可以用“受访者描述”“观察到的行为”“外部研究”“团队推断”等标签落实这个原则。相比在“建议转向”旁边放一个说不清含义的置信度百分比，这些标签更利于判断。

证据访问也应单独成为产品要求。GOV.UK 服务手册的深度访谈指南涉及知情同意、录音及个人材料的安全处理。收集或处理客户例子前，应取得适当许可，明确哪些工具可以接收、谁能查看，以及何时删除。本文没有为这些选择确立放之四海而皆准的法律依据。

早期原型可能只需要人工挑选的一组已获授权摘录。尚未证明决策辅助有用，就接入所有客户系统，会先增加大量需要管理的材料。只有能够说清新增访问将回答什么问题时，才逐步扩大证据范围。

9. 判断这套流程什么时候值得使用

当下一次开发投入取决于尚未确认的问题、有争议的解释，或能够低成本测试的改善主张时，这套方法值得尝试。尤其当一份 AI 生成规格看起来十分完整，却没人能指出最重要功能究竟依据哪次观察时，它能让讨论重新落地。

需求已经清楚的常规改动，不必套用整套流程。修复坏链接不需要研究档案；紧急线上事故应按事故流程先控制影响再调查。医疗、法律或安全等高风险决策，还需要领域专业能力和相应验证，不能用这张表替代。读过文献的方案，也无法免除这些要求。

从一个决策、手头已有的来源和一次能结束于具体行动的短会开始。一人介绍主张及最强支持，另一人寻找相反解释与缺失语境，再由决策负责人记录哪些内容发生变化。不必等某个研究产品开放使用，在共享文档中就能开始。

下一轮评审时，检查新观察有没有改变产品方案、测试方法或决策。如果三者都没变，就该回头看看，测试是否真的可能让团队感到意外。如果证据仍然含糊，应如实记录，并判断是否值得再做一次有明确范围的调查。访谈数量和链接数量，本身不应成为成绩。

LitPivot 带来的即时启发，是让“改变想法”成为与 AI 协作时清晰可见的一步。对创始人来说，有用的结果是更有依据的下一次投入：可能是更小的功能、不同的问题，也可能是停止。这张表只有在帮助团队看清证据、减少隐藏假设并作出决定时，才值得留在工作流程里。

参考资料

1. Ai2：LitPivot 介绍，2026 年 10 月 23 日。
2. LitPivot 论文，第 3 版。
3. Google PAIR：用户需求与成功标准。
4. NN/G：用户访谈基础。
5. NN/G：避免诱导式提问。
6. Microsoft Research：人机 AI 交互指南。
7. Google PAIR：可解释性与信任。
8. GOV.UK：开展深度访谈。