multi-expert-analyzer

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 — 最终文章的文风与"织入校验"的写法。