multi-expert-analyzer

name multi-expert-analyzer description 针对通用问题进行多领域专家联合分析, 综合稿产生前必经 fact-checker 与 red-team 两道独立校验。适用场景: 用户提出跨领域或不确定领域的复杂问题, 需要从多个专家角度分别搜证并相互校验后综合成文, 例如该不该买房、该不该跳槽、是否进入某个赛道等。触发关键词: 多角度分析、专家分析、综合分析、多视角、跨领域分析、从不同角度看、深度分析。问题只属于单一明确领域时, 优先使用该领域的专门 skill, 例如纯财务用 finance-core-analysis、纯技术用 software-architect。输出 (全部 markdown 保存到当前项目 markdown/ 目录): (1) 每位专家的中间分析稿; (2) 事实核查报告 (跨专家矛盾 / 未经证实的主张 / 重叠区); (3) 红队反驳报告 (逐条反驳承重墙级主张, 给出 SURVIVES / WEAKENS / REFUTED 裁定); (4) 第一人称、通俗易懂的最终综合长文, 同时报告哪些主张通过验证、多少被弱化、多少被剔除。 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 中用 ![描述](figure.svg) 引用 图示要服务于推理, 不能是装饰 3.4 数据与案例支撑 引用权威数据 (官方统计、上市公司财报、监管文件、学术研究、行业协会报告) 引用典型案例 (历史先例、近期事件、对标公司) 数据要标注时间点和来源, 避免"听说"、"很多人说" 3.5 适用边界 明确告诉读者: 我的结论在什么条件下成立 (时间窗口、地域、市场环境) 不适用于哪些情形 对哪些特殊人群 (高净值 / 低收入 / 老年人 / 创业者) 不一样 3.6 证伪与证明方法 这是最容易被忽略但最值钱的一节。 必须回答: 证伪条件 : 出现什么新数据/事件, 我会推翻自己的结论? 验证信号 : 接下来 3-6 个月观测哪些指标, 可以确认我的判断走在正确方向? 关键里程碑 : 时间表上有哪些节点必须重新评估? 每个专家都按这 6 个小节写, 内部不必互相引用, 各自独立。 3.7 自我验证与迭代 (硬约束) 每位专家写完 3.1-3.6 初稿后, 必须做一轮自我验证, 通过后才能视为"定稿"进入综合阶段 。不通过就改, 改完再验证, 直到通过 — 这不是可选项, 是这个 skill 的硬约束。 验证清单 (逐条过, 不能跳): 数据维度 每一个数字都有时间点 (年/月/季度) 每一个数字都有可追溯来源 (机构名 + 报告名 / 文件名) 同一数据在文中多次出现时, 数值一致 单位、口径标注清楚 (人民币/美元、同比/环比、绝对值/百分比) 引用案例与原始事件吻合, 没有张冠李戴 逻辑维度 因果链每一环都成立 (从 A 到 B 没有跳跃) 结论与前置条件匹配 — 前置变了, 结论会跟着变 内部没有自相矛盾 (前半段说 X, 后半段又说非 X) 反方意见没有被悄悄偷换成"我自己换种说法的同义观点" 证伪条件是"我可能被打脸"的信号, 不是"我打别人脸"的攻击 结构维度 3.1 - 3.6 六节全部存在, 没有用 "N/A" 跳过 至少一张图, 图与文字互证 (不是装饰) 前置条件是完整句子, 不是关键词堆砌 不通过的处理: 数据有问题 → 重新搜证 (mcp__MiniMax__web_search / 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: 跨专家事实核查 (Fact-check, 硬门槛 — 不可跳过) 这一阶段产物是中间稿, 不直接呈现给用户; 但步骤 7 的综合稿必须吸收其结论。 派遣一个 general-purpose 子智能体担任"事实核查员", 让它读: markdown/<主题>-专家*-*.md (所有专家稿) 步骤 4 的内部整合稿 (主循环自己持有即可, 不必落盘) 输出一份结构化校验报告。 核查员的硬性核查项 (缺一不可): 矛盾 : 专家 A 说 X, 专家 B 说非 X — 必须列表标出冲突点 + 各专家的证据 未经证实的主张 : 数字、引用、统计没有时间点和/或来源 (机构名 + 报告名/文件名); 凡抓不到来源的标"无法可靠核实", 不要替专家自己编 重叠 : 多位专家说本质相同的论点 — 这些在综合稿合并表达即可, 不需要重复展示 输出文件 (必须落盘) : markdown/<主题>-factcheck-YYYYMMDD.md , 固定结构: # 事实核查报告 — <主题> ## 1. 矛盾清单 | # | 专家 A 主张 | 专家 B 主张 | 冲突性质 (事实 / 视角 / 时效) | 建议处理 | |---|------------|------------|----------------------------|---------| ## 2. 未经证实的主张 | # | 出处 (专家 + 节号) | 主张原文 | 缺失信息 | 紧急度 (高/中/低) | ## 3. 重叠区 | # | 哪些专家在说什么 | 建议合并表述 | |---|----------------|------------| ## 4. 校验结论 - 必须移除或补源: [...] - 允许反方观点并存: [...] (这些不要为了"统一口径"而偷偷抹平) - 可以合并的重叠: [...] 主循环在本步的处理规则 : "必须移除或补源"项必须先回到对应专家稿处理 (有源补源、无源删字、降级为定性判断), 然后再进入步骤 6; 否则视为本步未通过 "允许反方观点并存"项的张力必须保留 — 这是多专家分析的价值, 不要为了一致性而抹平 最多两轮: 第一轮校验修稿, 第二轮复验; 第二轮仍有未解决项, 在该专家的"关键盲点"加一条, 综合稿里用"该结论存在保留意见"软化 步骤 6: 红队反驳 (Red-team, 硬门槛 — 不可跳过) 派遣第二个 general-purpose 子智能体担任"红队", 让它读: 所有专家稿 markdown/<主题>-专家*-*.md 步骤 5 的事实核查报告 markdown/<主题>-factcheck-YYYYMMDD.md 输出 反驳报告 。红队的目标不是"赢"也不是"陪审", 而是 让综合稿的承重墙级主张站得住脚 — 每一条都得扛住反方最聪明的反驳才配进最终文章。 红队流程 : 从专家稿 + 内部整合稿, 提炼出 3-7 条 承重墙级主张 (即综合稿会反复引用、读者据此决策的断言 — 而不是细节或例证) 对每条主张, 尝试用最强反论反驳; 不仅找反例, 还要 steel-man 反方, 找出专家稿中 没被反驳过的反方论据 给出三选一裁定: SURVIVES — 反驳失败 / 反方论据弱; 进综合稿, 原样引用 WEAKENS — 反方有效, 主张仍可成立, 但必须加限定 (时间窗口 / 人群 / 市场环境 / 前置条件) REFUTED — 反方赢了; 该主张不得作为综合稿的承重墙出现 输出文件 (必须落盘) : markdown/<主题>-redteam-YYYYMMDD.md , 固定结构: # 红队反驳报告 — <主题> ## 1. 承重墙级主张清单 (列出 3-7 条, 标注是哪位专家的哪个节) ## 2. 逐条反驳 | 主张 | 最强反论 (steel-manned) | 关键证据缺口 | 裁定 (SURVIVES / WEAKENS / REFUTED) | ## 3. 幸存主张清单 (SURVIVES + WEAKENS 的全部; 给综合稿可引用的措辞模板) ## 4. 被剔除主张与替代措辞 (REFUTED 的全部; 给综合稿可用的"有人主张 X, 但 Y 反驳…"措辞模板, 或直接删除) 主循环在本步的处理规则 : REFUTED 的主张 不得 作为综合稿的承重墙; 也不能以"我有保留意见地说..."的含糊句式混过去 — 必须按报告第 4 节的措辞模板改写或删除 WEAKENS 的主张必须带限定 (时间/人群/市场环境/前置条件被打破的概率) 才能进稿 SURVIVES 的主张可引用, 但措辞避免绝对化 ("永远"、"必然"、"一定"、"毫无疑问") 红队本身可能犯错 — 如果某条被 REFUTED 的主张在综合稿 必须 保留 (例如属"反方张力展示"), 需在综合稿中明确标注为"反方张力点"而不是"承重论据", 并解释为什么保留 步骤 7: 用第一人称写最终文章 (原步骤 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/<主题>-factcheck-<YYYYMMDD>.md 英文: markdown/<topic>-factcheck-<YYYYMMDD>.md 红队反驳报告 (步骤 6 产出): 中文: markdown/<主题>-redteam-<YYYYMMDD>.md 英文: markdown/<topic>-redteam-<YYYYMMDD>.md 最终综合稿 (步骤 7 产出): 中文: markdown/<主题>-多角度分析-<YYYYMMDD>.md 英文: markdown/<topic>-multi-perspective-<YYYYMMDD>.md 主题用 kebab-case <主题> 在所有文件名前缀保持完全一致, 用前缀就能直接看到本次分析的所有产物。最后给用户的报告里 必须 附三类计数: 通过验证的主张数 (SURVIVES) / 被弱化的主张数 (WEAKENS) / 被剔除的主张数 (REFUTED)。 输出前自检 事实核查报告 markdown/<主题>-factcheck-<YYYYMMDD>.md 是否存在? "必须移除或补源"项是否已全部处理? 红队反驳报告 markdown/<主题>-redteam-<YYYYMMDD>.md 是否存在? REFUTED 项是否已从综合稿中剔除或按报告第 4 节的措辞模板改写, 而不是用含糊措辞蒙混? 综合稿的承重墙级主张是否能一一对应到红队报告的 SURVIVES 或带限定的 WEAKENS? 给用户的最终报告是否写明三类计数: 通过验证的主张数 (SURVIVES) / 被弱化的主张数 (WEAKENS) / 被剔除的主张数 (REFUTED), 且不隐去被剔除或被弱化的部分? 全文是否第一人称? 有没有出现"综合"、"汇总"等合成词? 前置条件是否被编织进叙述 (而非表格化)? 至少有一张图? 结尾是否给了可观测信号清单? 小白能读懂吗? 有没有未解释的术语? 每位专家的内部草稿都通过了步骤 3.7 的自我验证 (有验证记录)? markdown/ 目录下是否存在与本文主题完全对应的 N 个专家稿 (N = 参与的专家数)? 缺一不可 专家稿的文件名 <主题> 与综合稿一致, 编号与人设与综合稿中引入顺序匹配? 资源 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 — 最终文章的开头/结尾/章节提示模板 (步骤 7 用) 协作建议 步骤 3 / 5 / 6 都用 general-purpose 子代理 (而不是主循环自己挑刺): 视角独立才有校验价值 — 各位专家、fact-checker、red-team 都必须是不同的子代理上下文, 主循环只做编排与吸收结论; 给每份子代理的 prompt 必须把对应步骤 (3 / 5 / 6) 的硬性结构化指令完整嵌入, 不要省略字段 复杂问题 (>4 个领域) : 用 general-purpose 子代理并行做多个专家的搜证, 你只做整合, 效率最高 可验证数据 : 必须用 mcp__MiniMax__web_search / WebFetch 联网核实, 不要凭训练记忆 — 至少对 1-2 个关键数据点做交叉验证 争议性话题 : 主动把"反方意见"配齐, 不要只强化用户已有的判断 (confirmation bias 是大敌) — 红队这一步就是为此设的硬关卡 超出认知 : 老实写"这个问题超出了我能可靠判断的范围", 宁缺勿编