| name | cross-analysis |
| description | 面向“围绕一个明确目的,对照多个参考源的实现、做法或边界来形成判断”的调研分析型任务。适用于交叉分析、对标调研、竞品分析、参考已有软件怎么做、围绕某个主题找多个参考源对照等请求;当需要先找到合适参考源,再展开分析、比较、综合时,应触发此 skill。默认用于运行态交叉分析,只有在用户明确要求新增、补充或整理本地参考源时,才进入维护态。触发关键词:交叉分析、对标调研、竞品对比、参考源对照、多个参考源、调研分析、为什么参考X而不是Y、应该参考哪些。 |
交叉分析
这个 skill 的目标是:
围绕用户给定的“目的”,优先调用已经沉淀的参考源,对照这些参考源在相关主题上的实现、做法与边界,产出可供用户继续使用的交叉分析结论。
这个 skill 的重点不在“最后把结果写到哪里”,而在:
- 先识别用户真正的目的
- 再找最合适的参考源
- 再围绕该目的做对照分析
结果与形式由用户决定,不由本 skill 预先限定。
使用状态
这个 skill 有两种状态,但默认按“运行态”使用。
除非用户明确要求:
- 新增一个本地参考源
- 补充一个已有本地参考源
- 整理参考源索引或维护章程
否则都应优先按“运行态”理解,而不是先进入维护态。
1. 运行态(默认)
用于围绕一个明确目的,调用现有参考源做交叉分析。
此时重点是:
2. 维护态(少用)
用于新增、补充或整理本地参考源。
维护态的具体做法见:
核心概念
目的
“目的”是用户真正想推进的问题,不是一个孤立关键词。
例如:”本地化笔记该优先参考哪些成熟做法”、”DAG动画增强该参考哪些现有实现”。
交叉分析必须围绕”目的”展开,而不是围绕某个产品名称机械摘要。
参考源
“参考源”是可持续积累、可重复调用的对照对象,可以是本地档案、GitHub项目、官方文档或产品级参考对象。
本地 source-*.md 档案是”外部参考的本地化搜索指南”,帮助 Agent 定位参考源,不替代对 ExoMind 自身现状的内部核查。
内部参考与外部参考
当问题围绕 ExoMind 自身功能、代码、issue/PR 展开时,先区分:
内部参考:当前仓库与项目自身已有的代码、文档、网站页面、issue/PR
外部参考:仓库之外的开源项目、官网、帮助中心、产品网站等
默认原则:与 ExoMind 自身实现直接相关的问题,先查内部参考;需要对照外部成熟做法时,再进入外部参考。
外部参考默认按”只读”处理——用来对照、借鉴、提炼模式与边界,不把外部仓库当作当前任务的可修改对象。
本 skill 的职责边界
本 skill 负责:明确目的、选择参考源、对照分析、输出结构化结论。
本 skill 不负责强制规定最终写回位置、写成何种计划文档或生成何种固定模板报告。
参考源优先级
如果问题直接围绕 ExoMind 自身当前实现,默认按以下顺序取材,只有上一层不足时才进入下一层:
- 内部参考
- 本地参考源档案
- 外部 GitHub / 官方文档 / 产品网站
- 搜索型 skill
- Agent 自行网页搜索
如果问题本身不是围绕 ExoMind 当前实现,而是纯外部对标或通用调研,可从:
- 本地参考源档案
- 外部 GitHub / 官方文档 / 产品网站
- 搜索型 skill
- Agent 自行网页搜索
Before 做交叉分析
在做交叉分析之前,先问自己:
- 目的:用户真正想解决什么问题?不是关键词是什么
- 范围:需要内部参考吗?还是纯外部对标?
- 深度:选 2-5 个参考源,为什么这 2-5 个能形成互补?
- 判断:共性是什么?分歧在哪里?推荐路径是什么?
标准流程
以下流程默认面向“运行态”。
1. 先明确用户目的
先把用户真正想分析的”目的”收敛出来。
至少要明确:
- 主题是什么
- 用户想借这次分析解决什么问题
- 用户更关心实现、产品做法、交互方式,还是边界约束
若用户目的模糊或分散:
- 先内部归纳成一句话:”这次要围绕什么目的做参考源对照”
- 用这句话向用户确认
- 得到确认后再继续,不要在目的模糊时就开始分析
2. 若与 ExoMind 自身相关,先查内部参考
如果用户的目的本身是在分析:
- ExoMind 当前功能
- 外心官网 / 用户教程 / 应用内文档
- 当前代码实现
- 当前 issue / PR / GitHub 内容
那么先检查内部参考。
优先看:
- 当前仓库里的代码、文档、网站页面
- 当前 issue、PR、计划文档
- 当前 GitHub 上已存在的公开内容
这里的第一步目标是:
- 先确认 ExoMind 现在已经有什么
- 先确认当前问题到底缺什么
- 避免在没有看现状的情况下,直接去外部找答案
3. 再查本地参考源
先查看本地是否已有相关参考源档案。
优先读取:
skills/cross-analysis/references/ 下的索引和相关档案
这里的第一步目标是:
- 找到相关参考源
- 确定优先检索路线
- 明确下一步该去哪个本地档案、GitHub 项目或官方资料
如果本地已有与当前目的高度相关的参考源,就优先沿这些线索展开。
不要跳过本地参考源,直接外搜。
4. 再补外部参考源
当本地参考源不够时,再去补 GitHub 或其他来源。优先顺序:GitHub 开源项目 > 搜索型 skill > 网页搜索。
为什么选 2-5 个参考源?
- 少于 2 个:无法形成对照,单一参考等于没有分析
- 超过 5 个:边际收益递减,且增加综合难度
- 2-3 个:适合相似类型对象对照(如两个竞品)
- 3-5 个:适合跨越类型对照(如 1 个竞品 + 1 个开源 + 1 个文档)
筛选标准:与用户目的的相关度、技术栈或产品形态相似度、能否形成互补对照。
外部参考默认只读。这里的重点是:看外部对象怎么做、抽象可借鉴模式与边界、再回到 ExoMind 当前现状做对照。不要把外部仓库或网页当作当前任务的可修改对象。
5. 可并行时再拆给 subAgent
只有在多个参考源调查彼此独立时,才拆给多个 subAgent。
推荐方式:
- 每个参考源一个 subAgent
- subAgent 只做该参考源的只读调查
- 主代理负责综合与抽象
不要让 subAgent 混合调查多个参考源。
6. 统一每个参考源的分析维度
每个参考源至少回答:
- 这个参考源为什么与当前目的相关
- 它在这个主题上是怎么做的
- 这些做法落在哪些实现位置、模块位置或功能位置
- 它的边界、约束与默认策略是什么
- 哪些点值得借鉴,哪些点不该直接照搬
如果能拿到精确源码位置,就明确列出;如果拿不到源码,只能作为产品参考时,也要明确标注。
推荐覆盖的分析维度:
- 实现位置、产品做法、交互效果、状态边界、数据边界、可扩展性、耦合风险
- 主题偏实现时优先看:源码入口、组件或模块分层、状态与持久化边界
- 主题偏产品时优先看:交互模式、信息组织方式、用户感知到的行为、功能边界与默认策略
7. 最后做交叉综合
最终综合时,不要写成参考源流水账。
应该回答:
- 多个参考源之间有哪些共性
- 它们在哪些地方分歧明显
- 对于当前“目的”,哪些路径更值得优先考虑
- 哪些参考源适合作为长期参考对象
不要把结果写成“逐个参考源复述”的堆叠摘要。
运行态输出建议
运行态产出默认应显式包含一段:
这一段至少说明:
- 这次是否先查了 ExoMind 的内部参考,查了哪些
- 这次分析先命中了哪些本地参考源档案
- 这些本地参考源把后续检索导向了哪些官方资料、GitHub 项目或其他来源
- 哪些来源是补充性的,为什么需要补
- 最终保留了哪些参考源进入交叉分析,为什么它们与当前目的相关
如果同时用了内部参考与外部参考,也应明确写出:
- 哪些判断来自 ExoMind 当前现状
- 哪些判断来自外部对照对象
- 最后是如何把两者对照起来的
如果这次没有命中本地参考源,也要明确写出:
- 为什么本地索引不足
- 因此是如何进入 GitHub、搜索型 skill 或网页搜索的
这样做的目的不是固定报告模板,而是让运行态结果具备可审阅性,能看出 Agent 是否真的遵循了“先本地参考源、再外部补充”的路线。
反模式
不要这样做:
- 一上来就网页搜索
- 列一堆参考源但没有围绕用户目的筛选
- 只讲“这个产品很像”,却不说明为什么相关
- 把本地已沉淀的参考源档案完全跳过
- 强行规定结果必须写到某种固定载体
- 在没有对照维度的情况下输出一大段松散摘要
最小检查清单
- 已明确用户目的
- 已先检查本地参考源档案
- 已按优先级决定是否需要外部补充
- 已控制参考源数量,不无上限扩展
- 已统一每个参考源的分析维度
- 已完成交叉综合,而不只是逐个摘要