AI 报告写完了，研究未必做完：创始人如何定义任务完成

研究助手交来一份漂亮的报告：开头有说服力，来源看起来可靠，结论也很明确。但它究竟完成了你交代的调查，还是悄悄换了一道更容易的问题？

这个问题值得今天讨论，因为 10 月 13 日发表的 Into the Unknown 论文，本周末再次进入 AI 讨论。研究考察 Agent 能否继续推进尚未解决的科学问题。作者报告，135 份提交没有一份满足全部要求，其中 114 份未通过研究诚信检查。这是特定科研任务和评估设置下的结果，不能当成商业研究助手的失败率。

对正在构建研究功能的非技术创始人和小团队，真正可用的启示是一个产品决策：“生成了文档”和“完成了研究委托”，必须分别验收。 产品应保留原问题，让未完成的工作清楚可见；如果要改变客户原本购买的服务范围，应先让客户作出选择。

下文提供可复用的验收表，并用一个虚构的产品上手研究助手说明具体做法。我们没有复现论文评测，也没有测试某款研究服务。论文提供警示，面向客户的工作流则是本文提出的方案：什么时候可以标注完成，什么时候应部分交付，建议离开应用之前又需要人工检查什么。

1. 先读懂研究结果，不把它扩大成普遍判决

这项研究让 Agent 沿着领域科学家提出的方向，继续推进既有科研工作。评估区分三个条件：研究诚信、完整性，以及是否达到科学家设定的标准。换成直白的话，就是陈述是否可信、规定的交付物是否齐全、研究是否真正达到要求。这比汇总已有文档更难。论文的评估协议还使用了依据评分细则进行的自动评审，理解结论时需要同时考虑这种评估方式。

“没有一份提交满足所有条件”，不等于“每一句话都是假的”。整份任务采用严格标准，仍可能有局部成果可用。反过来，一份文字通顺、部分正确的报告，也不代表委托已经完成。这两点都会影响产品应该向客户展示什么状态。

研究也不只有一个标题可读。官方仓库提供任务说明、评分细则、评审结果和 Agent 产物的入口；其中的 10 月 15 日发布记录，也把公开发布与今天的再次传播区分开来。官方数据集包含结果、运行轨迹和文件系统材料。它们属于同一项研究的不同组成部分，并不是三次独立复现。

对创始人而言，这更适合用来制定验收规则，而不是直接选模型。客户可能需要访谈整理或竞品简报，并不要求完成原创科学发现。你应评估自己的真实承诺。直接搬用论文的失败比例，或认为换个模型就消除了问题，都会绕过最关键的产品判断。

2. 先定义研究承诺，再设计报告样式

从客户打算作出的决定开始。“研究一下新用户上手问题”过于宽泛。“从这些已获同意使用的访谈记录中，找出账号设置环节出现的障碍，并为下一轮研究提出问题”，才是一项有边界的服务：输入是什么、要调查什么、结果用于什么，都比较明确。

可以用三个术语把承诺说清楚。范围指包括与不包括哪些工作。来源与处理记录，也就是 provenance，指信息从哪里来、经过哪些处理才成为结果。验收则是客户或明确负责的人，判断约定工作是否满足条件。一份报告即使来源完整，也可能因为回答错了问题而不能验收。

W3C 的 PROV 概述通过实体、活动以及参与者来描述产物的来源关系。你不必先实现整套技术标准，也能使用这种思路：用了哪份输入，对它做过什么，谁或哪个系统负责？在团队开发专门界面之前，一张表也能记录这些关系。

把服务承诺写成一张简短的任务卡：支持什么决定、允许使用什么输入、必须进行哪些比较、交付什么、排除什么，以及谁有权批准变更。还要写清时间边界。分析昨天提供的文档，不应让客户误以为产品调查了今天的实时市场。

尤其要明确产品不执行的工作。读取访谈逐字稿，不等于亲自开展访谈；整理公开的产品功能说明，不等于实际测试产品；提出实验，不等于已经运行实验。如果这些区别会改变客户的理解，就应同时出现在最初的承诺和最终交付中。

3. 分开检查事实、已做工作和建议

一个证据链接可能支持某条事实，却无法支持报告对研究过程的描述。某个产品页面可以证明厂商宣称支持导出，但不能证明你的助手测试过导出、测量过速度，或确认用户觉得它好用。

因此，仅有参考资料清单并不是有力的验收条件。2023 年的引用生成评测 ALCE分别考察语言流畅度、正确性和引用质量。它的历史结果不代表今天产品的表现；这里值得采用的设计原则是：报告即使读起来顺畅、带有引用，也仍需核对证据是否真的支持陈述。

检查重要表述时，可以分为三类：

• 来源事实：文档、录音或外部资料究竟能证明什么。
• 工作陈述：助手或团队声称搜索、比较、计算、测试或观察过什么。
• 解释与提议：证据可能意味着什么，下一步建议做什么。

例如：“用户在设置阶段遇到困难，所以我们验证了一个简化流程。”一句话里混合了观察、概括和已经完成验证的宣称。它们需要不同的支持。访谈片段可能只说明某个人遇到了困难；要证明开展过验证，则需要研究方案和实际观察记录。简化流程在测试之前，只能算建议。

同样发表于 2023 年的 FActScore，把长文本拆成较小的事实单元，核对它们是否有依据。我们借用这种拆分方式进行审核，并不认为事实指标本身能判断产品是否可以上线。只要复合句的一部分可能为真、另一部分仍未证实，就值得拆开检查。

4. 一个虚构场景：上手研究助手如何悄悄丢掉任务范围

假设一个小团队正在开发面向产品经理的助手，暂且叫它“第一周”。客户上传六份获准使用的新用户上手访谈记录，希望知道：提供的访谈里出现了哪些障碍，首次使用者和回访用户的体验有什么差别，以及需要什么证据才能支持修改账号设置流程。

助手遇到了困难：访谈记录没有一致标注参与者属于首次使用还是回访用户，另外两份录音还有听不清的片段。它仍然可以写出一份很有说服力的上手体验分析。危险的捷径是，直接删去分组比较、自行推断缺失的用户类型，然后像完成了原调查一样给出建议。

更合理的交付应明确收窄结论，而不是暗中收窄任务。报告可以整理清晰材料中有依据的观察，把要求中的分组比较标为待解决，再提出补齐信息的方法。下一步研究计划不能伪装成已有发现。这样，客户拿到的内容依然有用，原委托也没有被抹掉。

这种区分在模型评测之外也有成熟的实践依据。GOV.UK 的研究分析指南分别处理观察、研究发现和行动。在这个产品里，也应让读者分清：参与者说过什么，团队据此得出了什么理解，又决定尝试什么。

例如，访谈笔记记录参与者 P03 两次返回密码页面，这是观察。认为找回路径不够清晰，是一种解释。建议测试修改后的找回提示，是下一步行动。“新提示降低了流失”则需要另一项调查，访谈记录和修改建议都不能直接提供这个结果。

本例中的人物、数量、产品名称和场景全部是假设，只用于说明验收选择，不是客户上线案例，也不能证明本文方案会提高留存。

5. 用一份验收表，把尚未回答的问题留在交付物里

你可以把下面的表复制到产品需求或发布评审文档中。它的目的，是决定客户可以依赖哪些结果，而不是堆积看起来专业的材料。生成报告前先填写一次，复核报告时再更新。示例继续使用虚构的“第一周”任务。

一条填好的决策记录可以这样写：FW-01；部分交付；原定分组比较尚未完成；清晰材料中的观察可用于规划；未开展可用性验证；客户负责补齐用户类型；比较结果等待澄清后更新。这是一条建议采用的记录示例，不是已经执行的测试。

对每项声称完成的活动，还应记录证据位置，以及是否有人实际检查过。模型生成一句“访谈或测试已经开展”，并不等于活动记录。重要陈述若尚未由获授权的人员复核，应明确标记“未复核”，不能让报告暗示已经验证。事后补写的说明，也不能冒充活动发生时留下的原始记录。

复核者应能依据表格解释，为什么报告属于这个状态。“听起来很谨慎”不够。缺失的分组比较是一项明确未完成的要求，有负责人，也有继续推进的路径。文末一条笼统免责声明，不能代替这项具体说明。

同样，不必因为任何字段留空就停止所有工作。某个细节缺失，可能只限制一条观察；某项要求缺失，则可能让核心建议无法成立。如果客户的决策依赖尚未完成的比较，就应暂缓该建议，同时允许交付范围清楚的有限分析。

6. 把部分交付和范围变更做成真正可用的产品状态

许多研究产品只有“进行中”和“已完成”两个状态。这会把不确定性全部塞进正文，忙碌的读者很容易漏掉。更好的设计是让状态对应委托本身：满足约定条件、部分完成且列明缺口、因缺少输入而受阻，或等待复核。

这些是本文建议的产品状态，并非通用标准。请用客户能理解的语言定义。“部分完成”应说明做完了什么、哪个问题还没解决、接下来怎么办。“受阻”应指出缺少的是权限、输入还是外部依赖，而不是只让加载动画一直转。

范围变更需要单独决策。如果无法比较用户群体，就让客户明确选择：提供缺失标注、批准改为范围更窄的描述性报告，或者停止任务。同时说明这会怎样影响建议。模型自己决定把任务简化，不能算客户已经批准。

客户接受一份有用的部分成果，也不代表原委托已经完成。应分别记录“接受部分交付”和“批准修订范围”。如果客户选择了更窄的新任务，后续完成度可以依据明确批准的版本判断，但原先未完成的要求仍应留在历史中。

客户批准缩小范围之后，也要保留原任务。否则系统就可能改写自己的历史：之所以最终报告显得完整，只是因为暴露缺口的要求被删掉了。一条简短修订记录即可交代原问题、批准后的问题、批准人和时间。

状态还必须跟着内容走。PDF、分享链接、复制出去的执行摘要，或邮件里的一段结论，都可能脱离原界面中的限制说明。应把影响决策的重要限制放在结论附近，并带入导出的摘要。目的不是每页重复免责声明，而是让未解决的条件始终跟随它所影响的建议。

最后，还要定义交付后证据发生变化怎么办。客户更正参与者类型时，系统应指出哪些比较和结论需要重新检查。悄悄重写正文，会让已经分享的旧版本看起来仍然有效。保留可见版本，并告诉客户早先的建议是否已经被替代。

7. 留下足够的依据，同时保护私人研究材料

证据访问存在实际取舍。客户需要检查报告为什么这样说，但访谈录音可能包含个人或保密信息。如果原本只应看到去标识化结论的人也能打开原始材料，增加透明度未必是好事。

GOV.UK 的研究记录指南强调参与者同意和研究材料的妥善处理。在这里，应由研究负责人确认：哪些材料可以处理、谁可以检查、导出报告能包含什么。本文并不能证明某种同意安排足以满足你的具体场景。

在允许的范围内，使用来源编号和相关片段，让有权限的复核者可以打开支持材料。不要默认把所有原始录音附在每份报告里。如果接收人没有权限，应诚实显示访问限制，并指向负责的人；不能把无法访问的链接包装成任何人都能核实的证据。

外部网页还有会变化的问题。Zotero 的文件文档区分链接、保存的文件和网页快照。设计来源清单时，这种区分很实用：URL 指明位置，获准保存的快照则有助于保留当时看过的内容。它们都不能单独证明网页里的说法是真的。

在会影响判断的地方记录来源版本或访问日期。对于会变化的产品功能，区分“阅读时厂商这样宣传”和“实际使用中已经验证”。只保留政策允许保存的支持材料，并明确访问和删除由谁负责。如果来源被要求删除，可能也要移除它、重新检查依赖它的结论，而不是留着一份仍暗示证据可查的报告。

最初可以只用受限文件夹和一张来源表。关键的验收问题是：合适的人能否检查重要陈述，同时产品又不会不必要地暴露其余研究材料。

8. 用故意不完整的任务，测试产品是否守住了承诺

在销售“自主研究”功能之前，用获准使用的代表性任务开展有边界的试点。除了完整、清晰的输入，也要纳入缺少标注、文件无法阅读、观察互相冲突、来源过时，以及仅凭允许材料根本无法回答的问题。不要只看最漂亮的成品。

先写预期行为。对“第一周”而言，缺少用户群体标注，就应让比较保持未解决；录音无法访问，仍应在输入清单中列出并说明访问问题；一项拟议实验，不能因为出现在“结果”标题下面就变成已经完成的实验。有人要求从导出中删去限制说明时，也应检查余下文档是否会误导读者。

还要加入一个反向检查：提供一项确实能由输入材料回答的核心任务，系统应正常完成，不能无谓拦截。否则产品只要拒绝一切，就会显得很谨慎。有用的克制，应能区分有依据的完成和确实存在的重要缺口。

同时从任务和陈述两个层面记录结果。任务层面记录尝试次数、可用输出、部分交付、受阻任务，以及标为完成的报告。报告层面检查无依据的已做工作宣称、遗漏要求、未经批准的范围变更，以及重要陈述是否缺少适当支持。失败和超时也要计入尝试次数，不能在比较时消失。

还应记录复核工作量，以及客户能否理解交付状态。专业人员花很长时间最终找得到限制，不代表忙碌的产品经理也能正确使用报告。让试点读者回答：做过什么、什么还没完成、下一步会怎么做。他们的回答，可能揭示引用检查无法发现的交付问题。

比较候选方案前，先设定验收条件。整体观感很好，不应抵消一次虚构活动或悄悄删去核心要求。如果结果正确，但证据无法访问，应与事实错误分开记录。两者都会影响产品，只是修复方式不同。

在可行情况下，一次只改变一个主要因素，保持任务和输入一致；模型、检索、导出或权限发生变更后，重新运行相关案例。这是一份建议的评估方案，本文没有提供实测成功率、通用通过阈值，也不保证一次试点覆盖所有未来故障。

9. 决定哪些可以上线，哪些只做辅助，哪些暂缓

合理的第一版可能是辅助研究，而不是宣称自主完成研究。它可以整理提供的材料、起草附有可检查依据的观察、指出未回答的问题，并准备下一轮研究提纲。即使解释和验收仍由人负责，这些能力也可能有价值。

只有团队能够实际评估的范围，才适合使用“全部交付完成”的标签。如果产品承诺新访谈、实时测试或因果结论，单靠生成文档无法兑现。当核心调查超出可用输入或团队复核能力时，就明确缩小承诺，或者暂缓该功能。

这套工作流适合边界明确的研究产品：委托人能说清要支持的决定、识别正当输入，并复核结果。对于开放式头脑风暴，它的价值较小，因为“完整完成”本身可能没有明确含义。它也不能单独替代专业科研评审或高风险领域的专业判断。填好验收表，不等于获得了专业资质，更不等于结论已经被认证。

摩擦确实存在。可见的部分完成状态和范围确认，会增加一些操作；删掉它们，演示可能更流畅，但客户也可能分不清有用的草稿和已经做完的工作。应通过真实用户测试这些摩擦，不要预先认定自动化越多越好，或人工复核越多越好。

下次发布前，挑一项代表性任务，让开发团队之外的人检查最初承诺、最终报告和导出文件。不翻隐藏日志，他们能否说出尚未解决的问题？他们能否分辨关键结果来自观察、推断，还是仅仅一项提议？如果不能，应先改善交付约定，再扩大自主研究的宣传范围。

产品要帮助客户知道自己究竟拿到了什么，以及可以据此负责任地做什么。一份外观看起来完成的文档，只是其中一部分。

参考资料

1. Into the Unknown 原论文，2026 年 10 月 13 日提交
2. 论文 HTML 版本中的评估协议
3. 官方代码、发布记录与研究产物说明
4. 官方数据集与公开研究产物
5. ALCE：让大语言模型生成带引用的文本，2023
6. FActScore：长文本生成中的细粒度事实准确性评估，2023
7. W3C：PROV 来源关系概述
8. GOV.UK：分析一轮用户研究
9. GOV.UK：用户研究中的笔记与录音记录
10. Zotero：向资料库添加文件