/multi-expert-analyzer_20260707

name: multi-expert-analyzer
description: 深度分析并解答任何领域的棘手问题。先判断问题涉及哪些领域，召集对应的领域专家分别搜证、按第一性原理作答（图文并茂、有权威数据和案例、讲清适用边界与证伪方式、自我验证），再经"事实核查"和"红队反驳"两道克制的校验，最后合成一篇面向小白、一气呵成、有人味的第一人称文章，全部产物存到当前项目 markdown/ 目录。触发条件：用户抛出一个想不通/难解/复杂/跨领域的问题并希望深入分析，例如"帮我分析一下……""这个问题到底怎么回事""从多个角度看……""深度思考一下……""这事儿靠谱吗""为什么会……未来会怎样"，或任何需要多领域专家协作、第一性原理推演、证据支撑与证伪路径的深度解答。即使用户没有明说"多专家"或"深度分析"，只要问题棘手、值得认真拆解，也应使用本 skill。

多专家深度分析

这个 skill 在做什么，为什么这么设计

很多棘手问题之所以棘手，是因为它横跨多个领域，单一视角必然有盲区。一个人再聪明，也很难同时是经济学家、工程师和心理学家。所以这里的思路是：**先把问题拆到它真正所属的几个领域，让每个领域的专家独立作答，再由一个中立的合成者把这些视角织成一篇普通人读得懂的文章。**

但多专家有个老毛病——每个专家都很自信，可他们之间可能互相矛盾，或者某个"权威数据"其实站不住脚。所以在合成之前，加了两道校验：一个**事实核查员**盯着专家们有没有自相矛盾或空口无凭，一个**红队**专挑最关键的结论去反驳。校验完才动笔。

有一点要特别克制：**这两道校验不是来找茬的。** 大多数问题并不需要写成严谨论文，过度的质疑只会让最终文章变得畏首畏尾、充满"但也可能……"。校验的价值不在于否定专家，而在于给最终文章埋下一些让读者会心一动、多想一层的点。所以校验结论**不直接改写文章的主干**，而是在文章成型后，把其中真正有价值的部分，以旁观者的口吻自然地嵌进去。

默认约定

• **输出语言**：默认中文，除非用户要求其他语言。
• **面向读者**：默认面向小白，通俗易懂。
• **产物位置**：全部存到当前项目的 `markdown/` 目录下。
• **严谨度**：默认"日常深度"——把问题讲透即可，不必学术化。只有当用户明确说了"要严谨""写成论文""学术级""每个结论都要能站住"这类话时，才切换到"论文级"，让两个校验器变得更较真。判断不准时，默认走日常深度。

工作流程

1. **复述与领域诊断。** 用一两句话复述问题，判断它涉及哪些领域。据此决定召集几位专家——**要右尺寸**：单一领域的问题 1 位专家足矣，跨领域问题一般 2–4 位。不要为了显得全面而硬凑专家；专家太多反而稀释重点。

2. **建运行目录。** 在当前项目下建 `markdown/multi-expert/<主题slug>-<YYYYMMDD>/`，内含子目录 `experts/`、`assets/`、`review/`。主题 slug 用简短的中文拼音或英文词。

3. **召集专家（并行）。** 对每个领域，先看当前环境有没有现成、贴切的专家 agent（比如"后端架构师""心理学家""投资研究员""土木工程师"等）：

• **有贴切的就直接调度它**，把该领域的解题任务交给它。
• **没有贴切的，就用 `general-purpose`（或类似通用）subagent 做角色扮演**，在 prompt 里明确"你现在是某某领域的资深专家"。

每位专家的任务书见 `references/expert-brief.md`——把它的要求完整传给每个专家 subagent，并告诉它自己的输出路径 `experts/NN-<角色>.md`。**在同一条消息里并行发起所有专家**，让他们同时开工。

4. **收齐草稿。** 等所有专家写完各自的 `experts/NN-*.md`（以及引用到的 `assets/*.svg`）。

5. **事实核查（克制）。** 起一个"事实核查员"subagent，读完所有专家草稿，标记**实质性**的矛盾和明显空口无凭的关键主张。做法与克制原则见 `references/verifiers.md`。存到 `review/fact-check.md`。

6. **红队反驳（克制）。** 再起一个"红队"subagent，只针对**最承重的那几个结论**尝试反驳。同样见 `references/verifiers.md`。存到 `review/red-team.md`。

> 第 5、6 步可以在同一条消息里并行发起——它们都只读专家草稿，互不依赖。

7. **先写文章，再织入校验。** 两个校验器都完成后，才动笔写最终文章。**先**把它写成一篇干净、连贯、面向小白的第一人称文章；**然后**回头看两份校验报告，挑出其中真正有启发、能让读者多想一层的点，以旁观者视角丝滑地嵌进去。写法与文风要求见 `references/synthesis.md`。存到 `final.md`。

8. **交付。** 告诉用户最终文章路径，以及中间产物（专家草稿、两份校验）的位置，方便他追溯。

关键原则速记

• **专家独立作答**：每位专家在自己的草稿里必须做到——复述并分析问题、第一性原理与前置条件、权威数据/案例支撑、适用边界、证明与证伪路径、交稿前自我验证一轮（不通过就改到通过）。图用 mermaid/ascii 直接内嵌；用 SVG 则单独存成 `.svg` 文件再在 md 里引用，**不要把 SVG 源码内联进 md**。
• **因果按时间顺序**：凡是"因为 Y 所以 X""在某时点做了某决定"这类说法，都要有明确的时间锚点，别用"早期""后来""成熟之前"这类含糊词。结果已经发生的事，其原因不可能发生在它之后。
• **校验器要克制**：不为找茬而找茬，不为反驳而反驳。默认日常深度时，只标注真正会误导读者的问题。
• **合成不留痕**：最终文章以第一人称一气呵成，专家视角用"站在……的角度"来带出，章节名和正文都不出现"专家一""综合""事实核查"这类合成痕迹。第一性原理的前置条件、变量融进行文，别列成表格。
• **要有人味**：像人写的，不是 AI 写的。措辞自然，少用"首先/其次/综上所述"这类八股和排比堆砌。

参考文件

• `references/expert-brief.md` — 每位专家的完整任务书（原样传给专家 subagent）。
• `references/verifiers.md` — 事实核查员与红队的 prompt 及克制原则。
• `references/synthesis.md` — 最终文章的文风与"织入校验"的写法。