根据已核查的公开证据建立竞品功能矩阵

1. 搜索前先明确买方任务

提供的公开买方提问想了解：对于团队也计划开发的软件功能，竞品是如何实现的。要回答这个问题，需要比较任务的具体完成方式。仅列出功能名称并不足够。这篇公开帖子提供了有用的背景，但不能证明这一需求有多普遍。公开买方提问，发表于2024年7月5日；检索于2026年10月25日；仅作背景参考。

用一句话说明买方要完成的任务，写清操作和所需结果。例如，买方可能需要将报表导出为 CSV。CSV 指逗号分隔值，是一种存储表格数据的文本格式。买方也可能需要查看谁审批过报表的历史记录。这是两项不同的要求，应各占一行。

搜索前，先记录：

1. 买方要完成的任务及所需结果。
2. 要比较的具体产品。
3. 判断每项要求所需的证据。
4. 需要满足的订阅方案、地区或软件版本条件。
5. 比较日期，以及明确的研究结束条件。

订阅方案指产品的订阅档位。版本用于标识某一次具体的软件发布。这些条件会影响来源能否回答你的问题。如果某项必要条件尚不明确，应将其记为待确认。

每一行的范围都要足够具体，便于核查。“报表功能”过于宽泛。“官方文档将 CSV 列为导出格式”则是一项可核查的标准。如果导出文件是否包含买方所需的列也会影响决策，就应另设一项标准。

收集结果前，先确定范围。如果之后出现新要求，应记录变更，并将新要求用于所有产品。不要仅因某家厂商对某项功能介绍得很详细，就为它增加一行。

这张表比较的是与买方任务有关的证据。如果你需要比较竞品网站在搜索中的位置，请使用另一套固定竞品查询组方法。搜索位置不能证明产品能力。

2. 明确定义证据状态

填写表格前，先定义证据状态。对每个产品使用相同的规则。

将文档证据和测试证据放在不同字段中。同一产品可以同时拥有两类证据。添加测试结果时，应保留指导该测试的官方来源。

用简短备注说明未知状态。例如：“格式不明确”“页面无法打开”“订阅方案不明确”或“没有经过核查的来源”。这些备注用于解释证据缺口，不是对产品作出的额外判断。

例如，页面写着“导出报表”，并不能证明支持 CSV 导出。它只能支持较宽泛的导出说明。对于更具体的 CSV 标准，状态仍为未知，直到经过核查的来源明确写出该格式，或你自己的测试给出答案。

如果官方页面说明了限制，应准确记录。某个订阅方案的限制，不代表所有订阅方案都有同样的限制。保留“仅”“除……外”“最多”等限定词。这些词可能影响决策。

3. 优先核查官方页面

打开各厂商的官方网站，寻找与买方任务最相关的页面。帮助页面、产品文档和订阅方案页面都是值得查看的候选来源。一手来源来自负责该产品的组织。它记录的是该组织的说法，不能代替你自己的测试。

确认页面确实属于目标厂商。评测网站、经销商网站或名称相近的网站都属于其他来源。将第三方评论与官方产品证据分开记录。

对每个相关页面：

1. 记录准确的页面地址和打开日期。
2. 阅读与核查标准有关的段落。
3. 保存一小段准确原文，以及对应的标题或章节名称。
4. 记录其中说明的订阅方案、地区、版本及其他条件。
5. 写出该段落能支持的具体证据结论，避免扩大范围。

搜索摘要是搜索结果旁显示的简短文字。应把它当作线索。在用它支持矩阵中的单元格前，先打开页面。关于将页面段落用作证据前如何核查的单独指南，更详细地说明了这一步。

如果页面没有显示日期或版本，应写“未注明”。不要用打开页面的日期代替。核查日期告诉读者你何时检查了页面，不能证明厂商何时撰写或修改了它。

这套方法能生成一份注明日期的比较结果，不能据此确定产品发布日期或随时间发生的变化。

4. 用精简的搜索输入寻找候选来源

你可以通过人工研究完成比较。需要帮助寻找页面时，Google Search Scraper 的文档所列输入字段和结果字段适用于寻找来源这一步。Actor 是托管运行的数据采集程序。Task 是为 Actor 保存的一组预设输入。

所提供的证据记录了对公开默认构建版本 1.0.15 的核查，核查日期为2026年10月25日。其 schema 用于定义输入结构和字段，其中声明了下文使用的字段。静态检查确认，这个示例符合该 schema。本文准备过程中没有运行 Actor。这项检查不能证明实际运行结果、完整覆盖范围或采集成功。公开默认构建版本，核查于2026年10月25日；仅有 schema 证据，未实际运行。

可采用以下建议的精简输入：

{"country":"US","engines":["google"],"language":"en","maxResultsPerExecutedQuery":3,"queries":["reporting software CSV export documentation"]}

查询词是发送给搜索引擎的文字。将示例查询词替换为一家具体厂商的名称，以及买方实际要完成的任务。问题要足够具体，便于找到相关官方页面。对每个产品使用相同的研究方法。

示例请求使用 Google，国家设为 US，语言设为 en。只有这些值符合研究范围时，才保留它们。每条实际执行的查询，结果上限为 3 条。上限只限制请求采集的数量，不保证返回三条结果，也不保证覆盖所有相关页面。

公开的竞品搜索结果研究 Task，核查于2026年10月25日；仅确认页面存在页面当时存在，Task ID 为 `Pjq0JLkzo0wHTcabU`。SERP 指搜索引擎结果页。这个 Task 可以作为起点，但其当前保存的设置和运行行为均未经验证。上面的示例是建议使用的替代输入，并非已验证的保存设置副本。

使用搜索时，保留以下已声明的结果字段：

这些字段有助于追溯你如何找到来源，不能证明页面支持你对功能的说法。页面核查应另行记录。搜索排名不是产品质量评分。

5. 保存足够细节，为每个单元格提供依据

用汇总矩阵方便阅读，用证据表方便核查。矩阵中的单元格可以包含证据状态和证据引用。通过该引用，应能找到来源段落及其适用条件。

在证据表中保存以下字段：

如果通过搜索找到了来源，应在来源记录旁保留搜索引用。如果多个页面共同支持一个单元格，应为每个支持页面单独保存一条证据记录。

不要用猜测值填补缺失字段。“未注明版本”不等于版本为零。“未执行测试”不等于测试失败。“没有经过核查的来源”不等于官方声明该功能不可用。

公开页面可以支持有关公开文档内容的说法，却不能揭示私有账户设置、内部审批记录或你自己的导出结果。如果你在获得授权后执行账户测试，应将账户条件和测试结果保存在单独的测试记录中。本文不包含此类记录。

6. 确认条件匹配后再下结论

将每个来源与买方的实际需求对照。页面可能说明了所需功能，但仍不足以确定它是否适合买方。

对每个产品核查以下条件：

1. 页面介绍的是目标产品吗？
2. 页面是否涉及这项具体任务及所需结果？
3. 所述订阅方案是否与买方的订阅方案一致？
4. 如果地区会影响结果，地区是否一致？
5. 如果软件版本会影响结果，版本是否一致？
6. 段落是否说明了会影响任务的限制？

不要因为页面未提及某项条件，就认定该条件匹配。记录缺失的条件，并缩小结论的适用范围。

如果两个官方页面的说法似乎不一致，应同时保留。注明各自的日期、范围和条件。在来源核查、厂商答复或明确说明的读者测试解决问题前，将结论标为待定。不要在未解释冲突的情况下，只选取更有利的段落。

需要测试时，先定义预期结果，再执行测试。保存步骤、测试日期、环境、预期结果、实际结果和证据。一次测试只能支持你实际核查的任务和条件，不能证明产品整体更好。

7. 逐步分析一个原创虚构示例

原创虚构教学示例。以下产品、买方需求和来源描述均为虚构。这不是 Actor 运行记录、客户结果，也不是实际观察到的企业研究结论。未进行任何读者测试。

虚构买方需要 CSV 导出和审批历史记录。产品 A 的官方帮助页面说明了 CSV 导出。产品 B 的营销页面提到了导出，但未注明格式。对于选定的任务，产品 C 没有经过核查的来源。这些来源描述都没有回答审批历史记录的问题。

将两项任务分开记录：

示例包含三个产品和两项买方任务：

3 个产品 × 每个产品的 2 项买方任务 = 6 个比较单元格。

1 个有文档支持的单元格 + 5 个未知单元格 = 6 个比较单元格。

执行的读者测试次数为 0。这里用零表示测试次数是正确的，因为示例明确说明未进行任何测试。五个未知单元格表示缺少证据，不表示缺少五项功能，也不能因此给出五个零分。

产品 A 的 CSV 单元格只支持一个具体说法：其虚构的官方帮助页面说明了 CSV 导出。提供的虚构材料没有给出订阅方案、地区、版本、准确原文或页面地址。这些字段仍待确认。不要为了让证据记录看起来完整而编造内容。

产品 B 的页面只支持“页面提到了导出”这一宽泛说法，没有回答 CSV 的问题。产品 C 的证据缺口仅表示尚未核查来源，不能证明是否存在 CSV 导出功能。

根据这些缺口，接下来应问：

你不能根据这张表，按完整工作流程的适用性为这些产品排名。但你可以据此确定，为作出该决策还需要哪些核查。

8. 分享前检查证据缺口和核查失败状态

将每个单元格与其来源记录逐一核对。确认读者能沿着每项有文档支持的说法，找到官方页面和相关段落。

明确记录未能完成核查的各种情况：

将搜索采集问题与产品结论分开记录。采集结果为空或不完整，不能说明厂商缺少某项功能。

也要检查总结中的措辞。“我们找到了这项任务的相关文档”，比“这个产品满足我们的所有需求”范围更窄。有文档支持的功能，不能证明产品经过测试后表现更优。用矩阵说明你已知什么、哪些问题仍无答案，以及哪个证据缺口会影响下一步决策。