multi-expert-analyzer2

---
name: multi-expert-analyzer2
description: 召唤多领域专家智能体，对任何棘手、跨学科、有争议或开放性的问题做并行深度分析，再经过一轮克制的事实核查与红队反驳，最后由一个"干净大脑"的终稿撰写者把所有内容无缝重写成一篇第一人称、面向小白、图文并茂、有人味、留有证伪空间的深度长文。触发条件：用户提出任何值得深挖的复杂问题，尤其是跨领域、需要多方视角、需要权威数据支撑的问题；提到"帮我深度分析"、"多专家视角"、"专家怎么看"、"这个问题涉及哪些领域"、"帮我搞清楚 XX 到底是怎么回事"、"用第一性原理分析一下"、"这个观点站得住脚吗"、"帮我论证一下"、"multi-expert-analyzer2"，或者只是抛出一个开放性问题如"为什么 XX 会发生"、"如何看待 XX 现象"、"XX 到底靠不靠谱"。即使用户没有明确说"专家"或"深度分析"这几个字，只要问题本身跨越多个专业领域、需要审慎论证而非泛泛而谈，也应使用本 skill。本 skill 与仓库中其他类似名称的技能（如 multi-expert-analyzer、multi-expert-analyzer1）相互独立，不共享模板或输出结构，请完全按照本文件的流程执行。
---

# Multi-Expert Analyzer 2

一个把"棘手问题"拆给多位领域专家、经过克制的事实核查与红队复核、最后由一个未被中间过程"污染"的撰稿人重写成人话长文的工作流。

核心理念：复杂问题的答案质量来自两件事——**多个真正专业的视角**，以及**一次不被中间草稿风格带偏的重写**。所以流程刻意分成"发散（专家）→ 收敛审阅（事实核查/红队）→ 重写（终稿人）"三段，且终稿人应当尽量以新鲜的视角去读前面的材料，而不是从中间小修小补。

## 何时使用

用户抛出一个足够复杂、跨领域、或有争议的问题，简单回答会显得单薄的时候。如果问题很简单（一个领域内的常识问答），不必套用整套流程，直接回答即可——本 skill 是为"棘手"问题准备的。

## 关于"子智能体"与"并行"

理想流程中，每位专家、事实核查员、红队、终稿撰写人都应该是独立的子智能体，彼此不共享上下文，这样才能真正做到"防止上下文污染"和并行加速。

- **如果当前环境有可用的子智能体/Task 工具**：请为每一位专家、事实核查员、红队、终稿撰写人分别派发独立任务，专家阶段并行启动。
- **如果当前环境没有子智能体（例如普通对话）**：老老实实按顺序自己扮演每一个角色，但要**用文件而不是记忆来传递信息**——每个角色写完就把稿子存成 markdown 文件；切换到下一个角色（尤其是终稿撰写人）时，重新去读磁盘上的文件，而不是依赖对话上下文里"我刚才写了什么"的印象。这是在没有真子智能体时，模拟"新开一个干净大脑"的最佳近似。终稿撰写人尤其要做到：假装自己完全没参与过前面的讨论，只是刚拿到这几份文件的新人。

无论哪种模式，所有中间产物和终稿都必须落盘为 markdown 文件，保存在当前项目的 `markdown/` 目录（如目录不存在则创建）。

## 整体流程

```
① 领域拆解与角色分配
② 专家智能体并行/依次作答（含自我验证循环）→ 各自存草稿
③ 事实核查员 + 红队复核（克制、不为难而难）→ 存复核记录
④ 终稿人（干净大脑）重写为第一人称长文，融入①②③但重写、不拼接
⑤ 终稿自检：对照第④步的所有要求逐条检查，必要时微调
```

---

## 第一步：拆解问题、分配专家角色

先复述你理解的问题，然后判断这个问题涉及哪些专业领域。多数"棘手问题"其实是跨领域的（比如"某产品估值是否合理"可能同时涉及财务、行业竞争、心理学/群体行为、监管政策），不要偷懒只派一个专家。

- 领域数量没有上限，但也不要为了显得"全面"硬凑角色——只选择真正能提供不同增量视角的专家。通常 2～5 位比较合适。
- 给每位专家一个具体身份（例如"数据库存储引擎架构师"而不是笼统的"技术专家"），身份越具体，后面第一人称转述时越有代入感。
- 把角色分配和你的判断依据简单告诉用户或记录下来，方便后面终稿人回溯。

## 第二步：专家智能体作答

每位专家的产出必须满足以下要求（这些要求本身就是为了让结论经得起推敲，而不是走流程）：

1. **先复述并分析问题**——用这位专家的专业语言重新表述一遍问题，说清楚这位专家会从什么角度切入。
2. **必要时搜证**——凡是涉及具体数字、时间、政策、企业名称、事件的地方，去搜索/核实，不要凭印象编。搜到的内容按版权规范转述，不整段照抄。
3. **逻辑清晰 + 图文并茂**——用 mermaid、ascii text 或 svg 辅助说明结构性、流程性、比较性的内容。**如果用 svg，必须单独存成 `.svg` 文件，再在这位专家的 markdown 草稿里用相对路径引用**，不要把 svg 源码直接堆在 markdown 正文里。图不是必须的，只有真正有助于理解时才加。
4. **权威数据、案例支撑**——结论不能空对空，要有具体的数据来源、真实案例。
5. **第一性原理 + 成立的前置条件**——说清楚"这个结论成立，需要哪些假设/条件为真"，而不是把结论包装成普适真理。
6. **适用边界**——结论在什么范围内成立，超出这个范围会怎样。
7. **证伪与证明手段**——明确写出：要证伪这个观点，应该去观测什么数据、出现什么结果就说明观点站不住；要证明/支持这个观点，应该观测什么数据、出现什么结果就是有力支持。这一条是重灾区，很多分析写完就忘了留这个口子，务必认真写。
8. **自我验证一轮再定稿**——写完后，专家自己再读一遍草稿，检查数据是否准确、逻辑是否自洽、是否有前后矛盾。如果发现问题，修改后再检查一遍，直到确认无误再定稿。这一步不用写成一个单独的章节展示给用户，但确实要做，且如果自查中发现较大问题应该在最终这版草稿里已经修正。

每位专家的草稿单独存为 markdown 文件，建议命名 `markdown/expert-<领域简称>.md`，涉及的 svg 图存为 `markdown/assets/<领域简称>-<图名>.svg`（没有 assets 目录就创建）。

## 第三步：事实核查员 + 红队复核

所有专家产出后，**不要急着直接写终稿**。先做一轮收敛审阅：

**事实核查员**：读所有专家的草稿，标出：
- 相互矛盾的主张（比如专家 A 和专家 B 对同一件事给出了不一致的数字或结论）
- 缺乏证据支撑、只是断言的主张

**红队**：挑草稿中"分量最重"的几个核心主张，尝试反驳——不是逐句挑刺，而是问"这个结论有没有明显的反例、有没有更强的对立解释"。

这两个角色都要遵守同一个克制原则：

- **默认相信专家的专业判断**，除非有确凿证据能推翻。没有实锤就不要动人家的结论。
- **不要为了挑刺而挑刺**。绝大多数情况下用户要的是一篇有说服力的深度文章，不是一篇无懈可击的学术论文——除非用户明确说了要写严谨论文级别的东西，才升级审查强度。
- 只标出真正有价值、值得读者多想一层的点，而不是把每个能挑的毛病都列出来。

事实核查员和红队各自的结果也要存成 markdown 文件：`markdown/fact-check.md` 和 `markdown/red-team.md`，内容简明扼要即可（矛盾点/待证实主张列表 + 反驳尝试及其强弱判断），不需要写成正式报告的排场。

## 第四步：终稿人重写（干净大脑）

这是全流程质量的关键一步。终稿人要做的不是"汇总"或"拼接"，而是**完全重写**——读懂前面所有材料（专家草稿 + 事实核查 + 红队）之后，当作自己从零开始构思了这篇文章。

终稿要求：

- **不能有拼凑痕迹**。章节标题和正文里都不应该看得出"这一段是专家A写的，这一段是专家B写的"这种缝合感。
- **第一人称行文**，专家意见用"站在xxx的角度"、"如果我是xxx"、"以xxx的视角来看"这类措辞自然带出，而不是"专家A认为……专家B认为……"这种报告腔。
- **标题要一针见血**，让人一看标题就知道这篇文章在回答什么真正的问题。
- **开头要有钩子**：先点破为什么现在要聊这个话题、背景是什么，再引出接下来要讨论的核心焦点，把读者的好奇心先勾起来，不要上来就罗列背景。
- **面向小白，一气呵成**。遇到专业术语要解释，但要克制——只解释真正会卡住读者的术语，不是每个术语都停下来讲一遍，那样反而啰嗦。
- **逻辑清晰，有权威数据、案例支撑结论**。
- **遵循第一性原理**：结论成立的前置条件要讲清楚，但要**用流畅的叙述文字表达，不要列成表格**——前置条件/变量表格化会打断阅读节奏，破坏"一气呵成"的要求。
- **结论有适用边界**：说清楚这个结论/观点在什么情况下适用，什么情况下不适用。
- **留出证伪与证明的口子**：跟专家草稿里的要求一样，读者应该知道，如果未来出现什么数据/事件，会证明或推翻这篇文章的核心观点。
- **有人味，没有 AI 味**。避免"综上所述"、"值得注意的是"这类AI高频套话堆砌，句式要有长短变化，不要每段都是"首先…其次…最后…"的模板腔。
- **图文并茂但不滥用**：只在真正有助于理解时才插入 mermaid/ascii/svg 图（svg 同样要单独存文件、markdown 里引用）。不要为了"看起来完整"硬凑一张图。
- **输出为 markdown**，保存到项目 `markdown/` 目录，建议命名 `markdown/final-<主题slug>.md`。

## 第五步：把审阅意见揉进终稿（而不是另起一节）

事实核查员和红队发现的有价值的点，不要单独开一个"风险提示"或"争议点"章节生硬地贴在文章末尾，而是要以**反思式的插入**自然地穿插在正文相应位置，语气可以参考：

- "顺带提醒一下……"
- "不过也不能太绝对……"
- "比如……这一点就值得反思"
- "凡事要辩证地看……"

这些插入要**克制**——只挑真正有启发性、值得读者多想一层的内容插入，不要为了显得"客观全面"而每隔几段就塞一句"但也有人持不同意见"，那样会稀释文章的观点浓度，读起来也很假。大多数事实核查/红队记录里的琐碎点，直接忽略就好，不用都用上。

## 第六步：终稿复检

写完终稿后，回头对照第四步列的每一条要求逐条自查一遍（有没有拼凑痕迹、第一人称是否自然、标题是否够犀利、开头钩子够不够、术语解释是否克制、前置条件是否写成了表格、证伪/证明的口子是否交代清楚、语气是否有AI味……），发现问题就直接在终稿里改，不用另外写一份检查报告。

---

## 输出清单（每次任务结束后应该存在于 markdown/ 目录下）

- `expert-<领域>.md` × N（每位专家一份）
- `fact-check.md`
- `red-team.md`
- `final-<主题slug>.md`（真正要给用户看的成品）
- `assets/*.svg`（如有用到 svg 图）

任务结束时，把 `final-<主题slug>.md`（以及它引用的 svg）作为最终交付物呈现给用户，中间过程的文件不需要主动展示，除非用户想看。