技术路线对比（Tech Route Comparison）

由 Patsnap Eureka 提供。

当决策对象是路线集合（而非某家公司、某个市场领域或具体提案包）时，使用本技能。目标是基于证据对路线进行对比，规范对比基准，并最终给出用户可据以行动的建议。

适用场景

• 用户询问哪条技术路线更好、更成熟或风险更低

• 两条或多条技术路线的横向对比

• 成熟度、就绪度、可行性或 TRL 评估

• 特定场景下的路线推荐（如"哪条路线适合电动汽车？"）

• 各路线的机会图谱或空白点扫描

• 面向管理层的技术预研报告

不适用场景

• 真实问题是某一公司在某一主题下的情况 → 转至 company-tech-profile

• 真实问题是多方竞争格局或参与者图谱 → 转至 competitive-landscape

• 真实问题是具体提案或立项包 → 转至 rd-initiation-review

• 任务是纯市场规模测算或无技术核心的商业对比

• 法律专利意见、FTO 或侵权分析

模式

默认模式：已命名路线时为 compare，仅给出主题时为 overview。

核心原则

检索前先冻结范围

在大范围检索前，先冻结以下参数，防止证据漂移：

• topic：技术领域

• decision_question：用户需要决策的问题

• decision_use：方向性路线扫描 / 通过/否决 / 尽职调查级别

• application_scenario：具体使用场景或背景（如电动汽车电池、数据中心冷却、边缘推理）

• comparison_level：材料级 / 组件级 / 系统级

• known_routes：用户提供或已发现的路线集合

• time_window：默认近 3-5 年

对比基准必须明确

在对路线排名之前，写明：

• 被对比的路线（冻结定义）

• 对比所用的维度（性能、成本、成熟度、风险、可扩展性等）

• 适用的归一化规则（相同应用场景、相同对比层级、相同时间窗口）

不得对比边界模糊的路线桶。不得将材料级证据与系统级证据混同为同一层级进行比较。

TRL 与成熟度需要明确的评分标准

不得在没有明确评分标准（定义每个级别在当前语境下含义）的情况下写出 TRL 标签、就绪度级别或成熟度声明。信号数量多的路线不等于置信度高——不要将数量与置信度混淆。

必须提供反向证据

对于每条路线的建议，主动检索并记录：

• 与建议相矛盾的证据

• 建议会发生改变的条件

• 应触发重新评估的更新触发器

工具路由与降级策略

本技能可在多种工具环境下运行。检索前，检测可用能力并选择可达的最高层级。

第一层（推荐）：结构化专利/论文检索

• 使用宿主环境中最优的结构化专利和论文检索栈。

• 通常包括字段化专利/论文搜索，以及记录级深度获取。

• 证据等级：S/A

• 所需能力：按路线检索、关键词或语义路线发现，以及对入围记录的深度阅读。

第二层（降级）：网络调研 + 学术辅助通道

• 使用宿主环境中最优的宽泛网络调研工具，以及可用的学术辅助通道。

• Exa、Tavily、Brave 及领域专属学术数据库均为示例，非硬性要求。

• 证据等级：A/B

• 与第一层相比的覆盖损失：路线广度和专利结构性声明精度较低。

第三层（降级）：通用网络搜索与页面阅读

• 使用宿主环境中可用的通用网络搜索和页面/PDF 阅读工具。

• 证据等级：B/C

第四层（最低）：用户材料 + 推理综合

• 无需外部工具

• 证据等级：C/U

路由规则

• 在工作流开始时检测可用能力。

• 选择可用的最高层级作为主要检索通道。

• 当某层级不可用时，明确说明降级情况。

• 若工具栈降级，则降低路线广度和前沿声明的置信度。

最小工作文件集

在可写的运行目录中创建或更新以下文件：

• request.md

• workplan.md

• method_decisions.md

• comparison_basis.md

• query_log.csv

• source_index.csv

• claim_ledger.csv

• report.md

推荐子目录结构详见 references/workflow.md 。

默认工作流

第 0 步：冻结范围

在任何检索前，确认或推断以下内容：

• topic、 decision_question、 decision_use

• mode（overview / compare / maturity / opportunity）

• application_scenario、 comparison_level

• known_routes（用户提供或待发现）

• time_window、 audience、 deliverable

若用户未指定路线，在第 1 步进行路线发现。 若用户已命名路线，冻结后直接进入第 2 步。

若主题宽泛且路线尚未冻结，在检索开始前将初步路线分类写入 comparison_basis.md。

第 1 步：构建路线分类（路线未给定时）

1. 运行 2-3 次宽泛主题搜索以发现候选路线。

   • 第一层：围绕主题进行结构化专利/论文搜索

   • 第二层：有针对性的网络调研加学术辅助搜索

   • 第三/四层：通用网络搜索或用户提供的材料

2. 从专利 IPC 聚类、论文主题和综述文章中提取候选路线。

3. 在继续之前，将路线集合冻结至 comparison_basis.md。

4. 若路线集合仍过于模糊，停下来与用户共同收窄，而非写出一个浅层排名。

第 2 步：冻结对比基准

写入 comparison_basis.md：

• 路线定义（每条路线的技术含义）

• 对比维度（性能、成本、成熟度、风险、可扩展性、部署就绪度等）

• 归一化规则：

  • 所有路线使用相同应用场景

  • 相同对比层级（不混用材料级与系统级）

  • 相同时间窗口

• 评分方法（成熟度或 TRL 模式时）：

  • 含级别定义的明确评分标准

  • 每个级别所需的证据要求

第 3 步：按路线独立检索证据

对每条路线独立进行：

1. 运行 2-3 次聚焦于该路线技术细节的搜索。

   • 第一层：针对该路线的结构化专利/论文搜索

   • 第二层：有针对性的网络调研加学术辅助搜索

   • 第三/四层：通用网络搜索或用户提供的材料

2. 跨维度收集证据：

   • 专利活动及关键技术方案

   • 论文前沿及近期突破

   • 标准、规范及监管状态

   • 产品部署、基准测试及商业化信号

3. 对每条路线深度阅读 2-3 篇代表性专利/论文以获取技术细节。

4. 将所有搜索记录至 query_log.csv，并按路线打标签。

收集阶段不得跨路线混用证据。在归一化步骤之前，保持各路线证据桶独立。

第 4 步：归一化与对比

1. 构建对比矩阵：路线（行）× 维度（列）。 每个单元格填入有证据支撑的评估结论。

示例格式：

1. 应用评分标准（成熟度或 TRL 模式时）：

   • 使用明确标准对每条路线按维度评分

   • 在分数旁展示评分标准

   • 不得在无证据支撑的情况下赋予 TRL 或成熟度标签

2. 执行反向证据检验：

   • 对每条路线建议，搜索反驳证据

   • 记录削弱条件和更新触发器

   • 若反向证据充分，调整建议

3. 将每项声明分类为：

   • 已核实事实 ：直接由专利、论文或官方来源支撑

   • 有证据支撑的推断 ：基于多个信号的合理结论

   • 开放缺口 ：证据不足，说明缺失内容

第 5 步：综合与起草

按照对应模式的输出骨架撰写报告。

输出骨架

概览模式

1. 执行摘要：主题全景与主要路线族群

2. 路线分类与定义

3. 各路线简介卡（每条 2-3 段）

4. 前沿信号与新兴方向

5. 关键证据参考

对比模式

1. 执行摘要：推荐哪条路线及原因

2. 范围与对比基准（明确）

3. 各路线简介卡

4. 对比矩阵（路线 × 维度）

5. 建议及条件、权衡与更新触发器

6. 反向证据与削弱条件

7. 关键证据参考

成熟度模式

1. 执行摘要：成熟度全景与就绪度差距

2. 范围与成熟度评分标准（明确）

3. 各路线成熟度评估（含证据）

4. 成熟度对比矩阵

5. 阶段门或就绪度路线图

6. 风险与部署阻碍因素

7. 关键证据参考

机会模式

1. 执行摘要：机会所在

2. 路线全景与当前覆盖情况

3. 差距分析（稀疏覆盖 + 技术价值 + 切入路径）

4. 新兴路线与早期信号

5. 推荐调研优先级

6. 关键证据参考

每项声明必须引用其来源类型和标识符，例如 [专利: CN1234567B]、 [论文: DOI 或标题]、 [网络: 来源名称]。

完成门控

交付最终答案前，以下各项必须全部通过：

• 路线集合在大范围检索前已冻结

• 对比基准已明确并写入 comparison_basis.md

• 对比层级一致（未混用材料/组件/系统级）

• 每条路线至少执行 2 次搜索并分析结果

• 各路线证据在跨路线对比前已独立收集

• 对比矩阵存在且每个单元格有证据支撑

• 若使用 TRL 或成熟度标签，明确评分标准已存在

• 主要建议的反向证据检验已完成

• 每项主要声明均有可溯源的引用

• 已核实事实 / 有证据支撑的推断 / 开放缺口已明确区分

• 工具层级和覆盖局限已明确说明

• 若证据不足以支撑有把握的排名，已明确说明并给出下一步证据收集方向

护栏

• 不得将数量与置信度混淆。信号数量多的路线仍可能是弱路线。

• 不得让供应商或公司营销材料的权重高于专利、论文、标准或可直接查验的技术证据。

• 不得在未去重和未加范围说明的情况下，将原始专利或论文数量转化为成熟度声明。

• 不得在没有明确评分标准的情况下写出 TRL、就绪度或成熟度标签。

• 不得将材料级、组件级和系统级证据混同为同一层级进行比较。

• 当用户仅给出宽泛主题且证据基础薄弱时，不得强行得出强结论。

• 不得跳过反向证据检验——每条建议至少需要一个有记录的削弱条件。

• 若某路线的论文或专利覆盖不足，在作出强度声明前明确说明。

• 当对比基准不完整或评分标准缺失时，不得将路线排名呈现为确定性结论。

• 建议必须与所述场景挂钩——对某一应用最优的路线，对另一应用未必最优。

按需加载的文件

• references/method-benchmark.md

• references/domain-playbooks.md

• references/workflow.md

• references/source-routing.md

• references/deliverables.md

• references/evidence-schema.md

• references/quality-gates.md

• templates/request-template.md

• templates/workplan-template.md

• templates/comparison-basis-template.md

• templates/report-outline.md