| name | multi-expert-analyzer |
| description | 针对通用问题进行多领域专家联合分析。适用场景: 用户提出跨领域或不确定领域的复杂问题, 需要从多个专家角度分别搜证并综合成文, 例如该不该买房、该不该跳槽、是否进入某个赛道等。触发关键词: 多角度分析、专家分析、综合分析、多视角、跨领域分析、从不同角度看、深度分析。问题只属于单一明确领域时, 优先使用该领域的专门 skill, 例如纯财务用 finance-core-analysis、纯技术用 software-architect。输出: (1) 每位专家的中间分析稿, 以 markdown 保存到当前项目 markdown/ 目录; (2) 第一人称、通俗易懂的最终综合长文, 也保存到 markdown/ 目录。 |
Multi Expert Analyzer
核心定位
这个 skill 不做单领域研究, 而是把一个问题拆给多个领域的"专家", 让每个专家按统一规范独立作答, 最后由"我"用第一人称将所有专家的洞察编织成一篇给小白看的文章。
如果问题只属于一个明确领域 (比如纯财务、纯工程、纯法律), 优先使用该领域的专门 skill, 不要硬套多专家分析 — 那会浪费篇幅。
适用与不适用
适用
- 问题天然跨领域: 投资决策 (金融+行业+心理)、职业选择 (职业+经济+心理)、健康方案 (医学+营养+行为科学)、城市/移民 (经济+社会+生活)
- 用户明确希望"多角度"、"全面"、"深度"分析
- 问题存在重大不确定性, 需要多视角相互校验、暴露盲点
- 决策不可逆 / 沉没成本高, 单一视角风险太大
不适用
- 问题边界清晰、属于单一领域 (转给专门 skill)
- 用户只想快速问一句得到一句话答案
- 缺乏可验证信息 (无论多几个专家都只能猜)
工作流
按以下 5 步严格执行, 不要跳步:
步骤 1: 拆解问题, 识别领域
先用一段文字把问题复述清楚, 标注:
- 问题的真实诉求是什么 (用户嘴上问 A, 心里想问的可能是 B)
- 涉及哪些候选领域 (建议 2-4 个, 太少覆盖不足, 太多稀释焦点)
- 哪些是核心领域 (必须深入), 哪些是辅助领域 (点到即可)
参考 references/expert-roles.md 匹配角色, 不要硬凑领域。
步骤 2: 为每个领域确定专家角色
为每个核心领域确定一个具体的、有立场的专家角色, 不是泛泛的"金融专家", 而是"经历过 2008 和 2015 两轮牛熊的二级市场基金经理"或"看空房地产 10 年终于在 2021 年翻多的首席分析师"。
为什么要有具体人设: 抽象的"专家"会给出平庸答案, 具体人设会逼出真知灼见。角色越具体, 视角越锋利, 越能暴露冲突。
每个专家必须在心里问自己三件事:
- 我的领域看这件事, 第一关注点是什么?
- 我过往犯过哪些错? (避免重蹈覆辙)
- 我最不放心哪类风险?
步骤 3: 每个专家独立作答
严格按以下结构作答。这是硬规范, 不可省略任何一节:
3.1 复述并分析问题
用自己的话把问题重新讲一遍, 表明"我作为这个领域的专家, 理解到的问题本质是什么"。
3.2 第一性原理拆解
- 这个问题背后最底层的物理/逻辑/制度约束是什么?
- 我的结论建立在哪些前置条件之上? (写成完整句子, 不要丢词)
- 哪些前置条件一旦被打破, 结论会反转?
前置条件要写成连贯句子, 不要表格化列举 — 后面的综合阶段要把这些条件编织进叙述。
3.3 逻辑推演与图示
- 给出明确的因果链或决策树
- 必须有图: mermaid 流程图、时序图、思维导图, 或者 svg 矢量图, 或者 ascii art
- 如果用 svg 图, 必须单独输出为 .svg 文件, 在 markdown 中用
 引用
- 图示要服务于推理, 不能是装饰
3.4 数据与案例支撑
- 引用权威数据 (官方统计、上市公司财报、监管文件、学术研究、行业协会报告)
- 引用典型案例 (历史先例、近期事件、对标公司)
- 数据要标注时间点和来源, 避免"听说"、"很多人说"
3.5 适用边界
明确告诉读者:
- 我的结论在什么条件下成立 (时间窗口、地域、市场环境)
- 不适用于哪些情形
- 对哪些特殊人群 (高净值 / 低收入 / 老年人 / 创业者) 不一样
3.6 证伪与证明方法
这是最容易被忽略但最值钱的一节。 必须回答:
- 证伪条件: 出现什么新数据/事件, 我会推翻自己的结论?
- 验证信号: 接下来 3-6 个月观测哪些指标, 可以确认我的判断走在正确方向?
- 关键里程碑: 时间表上有哪些节点必须重新评估?
每个专家都按这 6 个小节写, 内部不必互相引用, 各自独立。
3.7 自我验证与迭代 (硬约束)
每位专家写完 3.1-3.6 初稿后, 必须做一轮自我验证, 通过后才能视为"定稿"进入综合阶段。不通过就改, 改完再验证, 直到通过 — 这不是可选项, 是这个 skill 的硬约束。
验证清单 (逐条过, 不能跳):
数据维度
逻辑维度
结构维度
不通过的处理:
- 数据有问题 → 重新搜证 (WebSearch / WebFetch); 找不到可靠来源就标"该数据无法可靠核实"并降级为定性判断, 不留模糊数字
- 逻辑有问题 → 回到 3.2 修前置条件, 顺着再推一遍
- 结构缺漏 → 补全对应小节, 拒绝"这节不重要所以省了"
- 反复三轮仍卡在同类问题 → 在专家档案的"关键盲点"加一条, 提醒综合阶段这位专家的输出有已知局限
只有"通过验证"的那一版内容, 才能进入步骤 4 的综合。 验证记录写在 assets/expert-analysis-template.md 的第 7 节, 不进入综合稿。
3.8 落盘中间产物 (硬约束, 与 3.7 一样不可省略)
3.7 验证通过后, 必须把这位专家的整份定稿立即写入 markdown/ 目录, 命名规则:
- 中文主题:
markdown/<主题>-专家<编号>-<角色>-<YYYYMMDD>.md
- 英文主题:
markdown/<topic>-expert-<n>-<role>-<YYYYMMDD>.md
<主题> 与最终综合稿保持完全一致, 便于关联<编号> 用阿拉伯数字, 从 1 开始, 与综合稿中引入该专家的顺序一致<角色> 用 kebab-case 的人设关键词, 例如 逆向投资人、量化pm、hrd-p9、城市规划学者
写入规则:
- 完整保留 1-6 节 (用户向内容) + 内部备注 + 第 7 节验证记录 (内部向内容) — 后两部分用引用块或小节标题清楚标出"不进入综合稿", 便于阅读也便于回溯
- 写入后再继续下一位专家, 避免最后才一次性补写 (一旦中途断档, 草稿就丢了)
- 同一位专家如果经历多轮验证, 以最终通过版落盘, 验证记录里附上每一轮迭代的摘要
- 文件名不要带"草稿"二字, 它就是定稿, 只是不直接呈现给用户
为什么必须落盘 (而不是只在上下文里流动):
- 多专家并行时, 上下文会塞满, 落盘后综合阶段可以"读文件"而不是"重生成"
- 读者回看时能看到"我当时是怎么想的", 增强可信度
- 一旦综合稿逻辑被质疑, 草稿就是审计线索, 可以回溯到每位专家的原始推演
步骤 4: 内部整合 (草稿阶段)
这一阶段产物是"原料", 不要直接呈现给用户。 在内部用结构化方式整理:
<内部草稿 - 完成后丢弃>
问题: ...
核心张力: [专家 A 认为 X, 专家 B 认为 Y, 冲突点在哪]
共识区: [所有专家都同意的事实/结论]
分歧区: [专家之间的根本分歧, 各自的论据]
对小白最重要的 3-5 个 insight: ...
最适合的比喻/类比: ...
需要预警的最大风险: ...
</内部草稿>
这一步不要在最终输出里留痕迹。
步骤 5: 用第一人称写最终文章
这是 skill 的核心交付物, 规则最严:
文风
- 第一人称 ("我", "我们")
- 给小白讲的口吻, 不预设专业背景
- 一气呵成, 不要用"首先...其次...最后..."的八股结构
- 不要把前置条件、变量列表做成表格 — 全部编织进叙述句子里
专家意见的措辞
- 用"站在 XX 角度"引出某个专家的洞见
- 不用"XX 专家说"、"综合 XX 意见"这类合成痕迹
- 章节名也不要出现"专家观点"、"综合分析"等词
- 可以用"如果我是你, 我会..."、"换做另一个视角..."自然过渡
结构建议 (不强制, 根据问题自由组织)
- 用一个具体场景或反直觉的洞察开头 (不要用"近年来..."这种平庸开头)
- 主体: 围绕"为什么会这样"层层推进, 每一层引入一个专家视角
- 中间必须有图 (mermaid 或 svg), 用读者能秒懂的呈现
- 结尾: 给出"接下来看什么"的可观测信号清单, 这就是各专家的"证伪/证明手段"的浓缩
- 结尾不要总结陈词, 要给读者一个可以立刻行动的"看盘清单"
输出位置
保存到当前项目的 markdown/ 目录, 两类文件:
-
专家中间稿 (步骤 3.8 已落盘, 综合前必须存在):
- 中文:
markdown/<主题>-专家<编号>-<角色>-<YYYYMMDD>.md
- 英文:
markdown/<topic>-expert-<n>-<role>-<YYYYMMDD>.md
- 例:
markdown/买房决策-专家1-看空翻多分析师-20260603.md
- 例:
markdown/career-pivot-expert-2-serial-founder-20260603.md
-
最终综合稿 (步骤 5 产出):
- 中文:
markdown/<主题>-多角度分析-<YYYYMMDD>.md
- 英文:
markdown/<topic>-multi-perspective-<YYYYMMDD>.md
- 主题用 kebab-case
<主题> 在两类文件之间保持完全一致, 用文件名前缀就能直接看到本次分析的所有产物。
输出前自检
资源
references/
expert-roles.md — 常见问题对应的专家角色清单, 帮你快速搭班子diagram-patterns.md — mermaid / svg / ascii 图示的速查与范式first-principles-framework.md — 第一性原理分析的骨架 (5 Whys + 约束识别 + 边界划定)synthesis-guide.md — 把多个专家观点编织成第一人称叙述的具体技法
assets/
expert-analysis-template.md — 单个专家作答的内部模板 (步骤 3 用)article-template.md — 最终文章的开头/结尾/章节提示模板 (步骤 5 用)
协作建议
- 复杂问题 (>4 个领域): 用
general-purpose 子代理并行做多个专家的搜证, 你只做整合, 效率最高
- 可验证数据: 必须用
WebSearch / WebFetch 联网核实, 不要凭训练记忆 — 至少对 1-2 个关键数据点做交叉验证
- 争议性话题: 主动把"反方意见"配齐, 不要只强化用户已有的判断 (confirmation bias 是大敌)
- 超出认知: 老实写"这个问题超出了我能可靠判断的范围", 宁缺勿编
失败模式 (要主动避免)
- 虚假综合: 把专家意见搅成一锅粥, 看似融合其实两边都不到位 — 保留各专家的锋利, 用过渡句自然连接
- 过度堆砌: 5 个以上专家一定稀释 — 砍到 3-4 个最关键
- 概念膨胀: 引入了"奥卡姆剃刀"这种术语却没解释 — 小白文风就是不用术语或者用了立刻解释
- 结尾空洞: "综上所述, 需综合考量" — 这是必须删掉的句式
- 数据无源: "数据显示..."必须可追溯, 否则写"据 XX 报告"
