这次做产品商业化调研时，我同时让几家 AI 评审同一个已有产品，又补了海外交叉验证和竞品对标。结果很容易让人兴奋：几份回答里反复出现相似的建议，安装、首次连接、同步范围、逐设备结果、稳定性和授权迁移，几乎都被放进了优先级最高的一层。
但我很快意识到，重复出现不等于已经证明。一个观点可能只是因为所有回答都读到了同一类公开资料，也可能是问题本身把模型引向了同一个模板。反过来，一次超时也不等于反对，一张竞品网页上的价格更不等于我们的定价答案。
真正要做的不是统计 AI 说了多少次，而是判断每条意见在证据链里站得有多稳。
先把热闹的意见表拆开
最初的任务看起来很明确：从定位、上手、交互、可靠性、授权、定价和分发等维度，评审一个已经能够工作的产品。表面上这是“收集建议”，实际上是在回答一个更难的问题：哪些问题会阻碍用户完成核心任务，哪些只是让产品看起来更完整？
如果不先拆开，最后很容易得到一张长长的建议表。每条建议都像有道理，优先级却只能按出现次数排序。这样做的后果是，最会被描述、最容易被模型复述的功能先进入路线图，真正影响信任的细节反而被推迟。
我后来把材料分成了4层：本地现状、用户问题、外部证据和推测。现状回答“现在到底有什么”；用户问题回答“哪里会卡住任务”；外部证据回答“别的产品或其他评审看到了什么”；推测则明确标出“这是我们暂时的解释”。这4层不能混成一列，因为事实、判断和待验证假设的责任不同。
比如“首次连接需要更多引导”属于对体验的判断，“首次连接失败会让用户怀疑产品不能用”是对后果的解释，而“增加6屏向导就能解决”已经是一个方案。它们可以连续出现，却不能用同一个证据标签覆盖。
共识先看独立性，再看数量
首轮评审里，有一组建议很快形成了共识：安装要顺利，首次连接要可理解，同步要明确范围，批量操作要能看到每台设备的结果，稳定性要经过长时间测试，授权还要支持迁移到新电脑。这些意见后来在海外交叉验证中仍然高度一致，所以我把它们视为较强的 P0 候选。
但我没有简单写成“3 家 AI 都同意，所以结论成立”。我给每条建议补了4个问题：来源是否独立，讨论的对象是否匹配，意见是否解释了核心用户任务，当前是否已有验证。只有跨来源重复、对象相同、能直接解释任务阻塞，而且不是纯粹的审美偏好，才有资格往 P0 靠近。
这里最容易误判的是来源数量。几家 AI 如果共享相似的产品知识和公开网页，它们的回答不能完全算作几次独立实验。数量能帮助我发现值得检查的模式，却不能替我完成证据判断。
共识的价值在于缩小验证范围，而不是替我们宣布事实已经成立。
我也把失败情况放进证据表里。有一个海外工具两次超时，没有返回有效判断。我没有把“没有回答”记录成反对意见，也没有为了凑齐来源继续重试。它只说明这条验证通道在当时没有产出证据。把缺失回答当成不同立场，会人为制造一场并不存在的争论。
P0 不是最受欢迎的功能
当我把意见重新放回用户任务里，优先级发生了变化。最吸引人的可能是脚本录制、语义级同步或更丰富的文档能力，它们确实可能形成差异化；但在用户还不能稳定安装、连上第1台设备、确认同步对象之前，这些能力很难兑现价值。
这次我选择先处理信任闭环，是因为产品的核心承诺不是“功能很多”，而是“我发起的批量动作确实发生在我选中的设备上，并且我知道每台设备发生了什么”。如果连接过程含糊，结果页只给一个总成功，授权迁移会让人担心换电脑后失效，那么再多高级功能也会被用户当成风险放大器。
因此，P0 的判断标准不是建议有多新，也不是某个回答写得多完整，而是它是否能减少核心任务中的不可见失败。逐设备结果看似是界面工作，实际是在补责任链；稳定性测试看似是工程工作，实际是在补产品承诺；授权迁移看似是商业化工作，实际是在补长期信任。
如果不处理这些基础缺口，后面会导致一种很难察觉的浪费：团队不断增加功能，用户却仍然在安装、连接和确认结果的地方流失。路线图会越来越长，产品却没有更接近“敢交给工作室使用”。
价格分歧不能被平均掉
竞品研究带来了另一种材料：有的产品免费，有的按设备收费，有的把语义级同步、脚本和文档作为差异点。几家 AI 对价格区间的判断差异更大，有的偏低，有的认为商业工作室可以接受更高的年度费用。
最容易走的错误捷径，是把这些数字平均一下，再把平均值写进 PRD。这样看起来既有多方参考，又很具体，实际上没有回答最关键的问题：谁愿意为哪种结果付费，免费替代品又在哪些场景足以满足他？
我没有直接定价，是因为这些答案需要设计伙伴访谈和真实使用实验。价格意见可以作为假设范围，不能伪装成市场事实。竞品网页也只能证明对方在某个时间点如何宣传，不能证明用户真的按那个价格购买，更不能证明我们的成本、支持承诺和目标人群相同。
有分歧的证据不该被平均掉，而应该被改写成下一步要验证的假设。
同样的处理也适用于功能分歧。某个来源建议把离线设备自动移到列表末尾，另一个判断这会破坏用户对设备位置的预期。我不会用投票决定，而是看哪种行为更容易造成误操作，再设计可观察的实验。结论没有形成前，分歧本身就是产品信息：它告诉我哪里还缺用户行为证据。
把证据写进 PRD，而不是只写结论
最终整理 PRD 时，我没有只保留“建议做什么”，而是把来源、当前差距、优先级和剩余缺口放在同一条判断链里。每一项都要能回答：现在是什么状态，用户为什么会受影响，外部资料支持了哪一部分，哪些只是推测，下一步准备怎样验证。
这也改变了“待办”的写法。比如“增加可靠性”太空泛，改成“做长时间稳定性测试，记录崩溃和断连原因，并让每个原因对应帮助内容”。前者容易被当成一句愿望，后者才有验收入口。又比如“优化授权”不够具体，改成“验证在线激活、离线使用、换电脑迁移和到期时的行为”，就能把商业化讨论落到用户会遇到的状态变化上。
我把每条结论标成几种状态：已由多来源支持、单一来源待核、来源缺失、需要访谈、需要实验。这样写会让 PRD 看起来没有那么“确定”，但它更诚实，也更容易推进。一个团队真正需要的不是一份充满肯定句的文档，而是一张知道哪里可以行动、哪里必须继续观察的地图。
这件事让我重新意识到，研究的产物不是答案的数量，而是判断的可追溯性。下次有人问“为什么是 P0”，我希望能回到用户任务、证据来源和验证状态，而不是回到“几家 AI 都这么说”。
下次我会怎么做
下次再做类似调研，我会先建立一张证据表，再发出第1个问题。每条建议至少留下来源、独立性、对象匹配度、支持的用户任务和验证状态；本地现状、外部事实、解释和方案分开写。这样可以在材料变多之前，先避免概念混层。
然后我会把意见分成3类处理。跨来源重复且能解释核心任务阻塞的，进入 P0 候选；只在单一来源出现、但有合理机制的，保留为待核假设；价格、包装和用户愿付金额这类强依赖场景的内容，直接安排访谈或实验，不用模型投票。
最后，我会单独记录失败和空白：谁超时了，谁没有覆盖某个问题，哪条竞品信息只是宣传，哪项结论还没有真实用户证据。一个流程成熟的标志，不是它能收集更多意见，而是它能让下一次的人快速分辨“已经知道”“暂时相信”和“还必须验证”。
我更愿意把多家 AI 当成证据发现器，而不是产品决策者；真正的决策仍然要回到用户任务、证据强弱和可验证的下一步。