research-ops

name	research-ops
description	ECC 的证据优先当前状态研究工作流。当用户需要基于当前公开证据和任何提供的本地上下文构建新鲜事实、比较、丰富或推荐时使用。
origin	ECC

研究运维

当用户要求研究当前信息、比较选项、丰富人员或公司信息，或将重复查找转化为监控工作流时使用。

这是仓库研究栈的操作者包装器。它不是 deep-research、exa-search 或 market-research 的替代品；它告诉你何时以及如何一起使用它们。

技能栈

在相关时将这些 ECC 原生技能拉入工作流：

• exa-search 用于快速当前网络发现
• deep-research 用于带引用的多源综合
• market-research 当最终结果应该是推荐或排名决策时
• lead-intelligence 当任务是人员/公司定位而非通用研究时
• knowledge-ops 当结果之后应存储在持久上下文中时

何时使用

• 用户说"研究"、"查找"、"比较"、"我该找谁"或"最新的是什么"
• 答案取决于当前的公开信息
• 用户已经提供了证据并希望将其纳入新的推荐
• 任务可能足够经常性以至于应该变成监控而非一次性查找

防护措施

• 当新鲜搜索成本很低时不要用过时的记忆回答当前问题
• 分离：
  • 有来源的事实
  • 用户提供的证据
  • 推断
  • 推荐
• 如果本地代码或文档中已有答案，不要启动重量级的研究遍历

工作流

1. 从用户已提供的内容开始

将任何提供的材料规范化为：

• 已有证据的事实
• 需要验证
• 未解决的问题

如果用户已经构建了部分模型，不要从零重新开始分析。

2. 分类请求

在搜索前选择正确的通道：

• 快速事实答案
• 比较或决策备忘录
• 线索/丰富遍历
• 循环监控候选

3. 先走最轻量的有用证据路径

• 使用 exa-search 进行快速发现
• 当综合或多个来源重要时升级到 deep-research
• 当结果应该以推荐结束时使用 market-research
• 当真正的需求是目标排名或热路径发现时移交给 lead-intelligence

4. 以显式证据边界报告

对于重要声明，说明它们是：

• 有来源的事实
• 用户提供的上下文
• 推断
• 推荐

对新鲜度敏感的答案应包含具体日期。

5. 决定任务是否应该保持手动

如果用户可能重复问同一个研究问题，明确说出来并推荐监控或工作流层而不是永远重复相同的手动搜索。

输出格式

问题类型
- 事实 / 比较 / 丰富 / 监控

证据
- 有来源的事实
- 用户提供的上下文

推断
- 从证据中得出的结论

推荐
- 答案或下一步行动
- 此任务是否应变成监控

陷阱

• 不要在未标记的情况下将推断混入有来源的事实
• 不要忽略用户提供的证据
• 不要对本地仓库上下文就能回答的问题使用重量级研究通道
• 不要在没有日期的情况下给出新鲜度敏感的答案

验证

• 重要声明按证据类型标记
• 新鲜度敏感的输出包含日期
• 最终推荐与实际使用的研究模式匹配