/multi-expert-analyzer_20260708

name: multi-expert-analyzer
description: |
  对任何领域的棘手问题进行深度思考分析,先识别问题所属领域并按需调度多位领域专家并行作答,
  之后由事实核查员和红队做克制的事实审计与对抗性反驳,最后整合为面向小白的第一人称终稿。
  适用:用户抛出一个跨领域/有深度的真实问题,希望听到多位专家的视角、看到观点的边界与证伪条件,
  并得到一气呵成、通俗有据的最终文章。不适用:简单事实查询、纯情绪吐槽、不要求证据的随口一问。

Multi-Expert Analyzer · 多专家深度分析

核心定位

这个 skill 不是搜索引擎,不是答库,也不是简单的"让多个人聊聊"。它是一套**深度分析流水线**:

**多专家并行作答 → 事实核查 + 红队对抗 → 第一人称整合终稿**

解决一类具体问题:**任何领域的棘手问题**——单凭一个视角答不全、答不透、答不准的题。

适用与不适用

**适用**:

• 跨领域真实问题(技术 × 商业 × 心理学 × 经济学 ...)
• 需要权威数据、案例、边界、证伪手段支撑的判断
• 用户希望看到"不同角度的拉扯",而不是"一个自信满满的答案"
• 问题本身有"前置条件"和"适用边界"——不是非黑即白

**不适用**:

• 简单事实查询("爱因斯坦哪年生的")
• 纯情绪吐槽("今天好烦")
• 随口一问的闲聊("你说 A 和 B 哪个好")
• 明确要求快速短答的场景

工作流概览

用户问题
   ↓
Step 0: 准备工作区(slug + markdown/ 目录)
   ↓
Step 1: 领域分析 + 专家分配(动态 1-5 位)
   ↓
Step 2: 多专家真正并行作答
   ↓
Step 3: 事实核查员 + 红队(克制版)
   ↓
Step 4: 第一人称终稿(重写而非拼凑)
   ↓
Step 5: 终稿自查与微调

子智能体的 prompt 模板放在 `agents/` 下,启动时按需读取:

• `agents/expert.md` — 领域专家的 prompt 模板
• `agents/fact-checker.md` — 事实核查员的 prompt 模板
• `agents/red-team.md` — 红队的 prompt 模板

---

Step 0: 准备工作区

在拿到问题后、正式开干前,先做两件事:

1. **在当前项目下建立 `markdown/` 目录**(不存在就建)。 2. **用一个简短 slug 标识本次任务**。slug 来自问题关键词,2-4 个英文词,kebab-case,例如:

• "AI 会不会让程序员失业" → `ai-programmer-unemployment`
• "PG 适合做 HTAP 吗" → `pg-htap-feasibility`
• "小红书冷启动怎么做" → `xiaohongshu-cold-start`

slug 是后续所有产物的文件名前缀,定下来不要中途换。

---

Step 1: 领域分析与专家分配

这一步是**整个 skill 最关键的判断**,做错了后面全跑偏。

1.1 识别问题领域

先把问题放回它真正的领域范畴里:

• **纯单一领域** → 1-2 位专家(同一领域不同视角,例如"前端架构师"+"后端架构师"看一个全栈问题)
• **跨 2 个领域** → 2-3 位专家(每个核心领域 1 位,如果交集复杂可加 1 位跨界专家)
• **跨 3 个及以上领域** → 3-5 位专家(避免再往上加,再多就是会议了)
• **强争议/强情绪类** → 在主领域专家之外,加 1 位"反方"或"现实主义"专家(例如"乐观主义者"+"悲观主义者"+"行业老兵")

1.2 选专家的几个原则

• **不要"挂名专家"**——别给"科技评论员""财经观察家"这种万金油头衔。要选**真在这个细分领域里工作/研究过的人**。
• **专家之间要互补,不是重复**。选了"产品经理"就别再选"产品总监",选了"宏观经济学家"就别再选"金融分析师"。
• **领域交集处必须有专家能 cover**。比如"AI + 教育"问题,要么有"AI 教育产品经理"这种跨界专家,要么前后两位专家能接力说清楚。
• **专家的认知深度必须能撑住问题的深度**。问"分布式系统一致性"就别派"前端工程师"。

1.3 把"专家分配方案"写在脑里

在脑里过一遍,确认:

• 问题真正涉及哪几个领域?
• 每个领域配谁?为什么是 TA?
• 专家之间是否互补?有无空缺?

**这一步不要落盘成文件**——它只是给 Step 2 服务的内部规划。**别让用户看到"我先做了个专家分配表"这种 AI 味输出。**

---

Step 2: 多专家并行作答

2.1 真正并行

多位专家必须**真正并行**——在同一个工具调用回合里同时启动。**不要一个接一个跑**。

每启动一位专家,先 `Read` 一次 `agents/expert.md` 拿到模板,按占位符替换后喂给 `Agent` 工具。

2.2 关于 n(专家数量)

不要为了"看起来热闹"硬凑专家。判断标准:

• **1 位**:问题单一,不需要多视角(这种情况 skill 退化为"直接答",但也按规格走完流程)
• **2 位**:互补视角足够(常见于"理论派+实战派"、"技术派+商业派")
• **3 位**:跨 2-3 个领域
• **4-5 位**:跨 3 个以上领域,或问题高度复杂
• **超过 5 位**:停下来问自己是不是过度设计。如果确实需要,把任务拆成多轮,而不是把专家数量推到 6+。

2.3 落盘规范

每篇专家稿统一文件名格式:

markdown/<slug>-expert-<n>.md

例如 `ai-programmer-unemployment-expert-1.md`、`ai-programmer-unemployment-expert-2.md`。

如果专家用了 svg 图,svg 存到 `markdown/svg/`,在 markdown 中以 `` 引用。

---

Step 3: 事实核查员 + 红队

**专家稿全部落盘后**,再启动这两个子智能体。**不要边写专家稿边跑核查**——核查员需要看到全部专家稿才能比对矛盾。

3.1 事实核查员

`Read` `agents/fact-checker.md` 拿到 prompt 模板,把全部专家稿的全文(或文件路径列表)塞进去,启动子智能体。

产物:`markdown/<slug>-fact-check.md`

3.2 红队

`Read` `agents/red-team.md` 拿到 prompt 模板,把全部专家稿的全文(或文件路径列表)塞进去,启动子智能体。

产物:`markdown/<slug>-red-team.md`

3.3 关于"克制"——这是流水线的生命线

把这条刻在脑子里:

> **除非用户明确说要写严谨论文,否则大多数问题都不需要论文级严谨。** 没找到硬伤就标"未发现硬伤",不要硬挑。

事实核查和红队一旦开始"为了找茬而找茬",整篇终稿就废了——它会被怀疑论淹没,失去"有立场、有判断"的人味。

---

Step 4: 第一人称终稿

4.1 读懂,而非拼凑

在动笔前,**先读懂所有产物**:

• 全部专家稿(N 篇)
• 事实核查稿
• 红队稿

读懂的标准:

• 每位专家的核心论点和关键数据是什么
• 专家之间在哪些点上一致、在哪些点上分歧
• 事实核查和红队指出了哪些值得反思的点
• 我自己(作为终稿作者)对这个问题最自然的切入角度是什么

**然后把这些材料放到一边,重新写**——不是把它们缝起来,也不是在它们的骨架上补肉。**当成你读了 N 篇文章,自己形成了一个观点,然后写下来。**

4.2 写作要求(硬规矩)

**风格**:

• **第一人称**("我"作为叙述者)
• 提及专家视角时,用"站在 xxx 角度"、"如果我是 xxx"、"以 xxx 的视角"这样的措辞
• 读者面向**小白**:专业术语第一次出现时解释一下,但克制,不是什么术语都要解释
• 句式短,一气呵成,避免"综上所述""由此可见"这种八股
• **不要 AI 味**:不堆排比,不滥用"不是...而是...",不滥用空洞比喻
• **要有活人感**:像人写的,像有作者在跟你聊天

**开头**:

• 必须有**钩子、引子**,点破本文开聊的背景,承托出本文要讨论的焦点在什么样的大背景下.
• 让读者在第一段就知道:这篇文章要讨论什么焦点?为什么值得读?

**结构**:

• 章节名和正文中**都不要出现"多篇内容合成"的痕迹**
• 不能出现:"专家 A 认为""专家 B 认为""综合以上""红队指出""事实核查显示"这种结构性缝合语句
• 章节命名直接用内容本身,例如不叫"专家观点综述",叫"AI 替代程序员的真实路径"

**论证**:

• 必须逻辑清晰
• 必须有权威数据、案例支撑结论
• 必须遵循第一性原理:**前置条件写在正文里,不要列成表格**
• 结论/观点必须有适用边界
• 结论/观点必须留有证伪及证明手段:**什么数据能证伪,什么数据能证明**
• 必要时图文并茂:**Mermaid / ASCII / SVG 都可以,但只在能提高可读性时用**——别为了图文并茂而图文并茂

**反思补充**(来自事实核查员和红队):

• 这些内容**必须以反思的方式**自然融入正文
• 措辞参考:"顺带提醒一下"、"不过也不能太绝对"、"例如 xxx 就值得反思"、"凡事要辩证的看"
• **必须克制**——只挑最有价值的 1-3 个点融进去,别硬塞
• 融入要丝滑,不要生硬"插一段反思"

4.3 落盘

终稿文件名:

markdown/<slug>-final.md

如果有 svg 图,存到 `markdown/svg/`,在 markdown 中以 `` 引用。

---

Step 5: 终稿自查与微调

落盘后、回复用户前,做一遍自查:

1. **第一性原理的前置条件是否散在正文里,而不是列成表格?** 2. **结论的边界是否清晰?** 3. **证伪/证明手段是否具体、可观测?** 4. **是否还有"多篇合成"的痕迹**(检查"专家 A/B"、"综合以上"、"红队指出"等表达)? 5. **开头是否有钩子?** 6. **是否还残留 AI 味?**(检查过度排比、空洞比喻、"不是...而是...") 7. **反思补充是否自然、克制?** 8. **图文是否必要?** 删掉任何"为图而图"的内容。

任何一条不通过,微调后再过一遍。直到全部通过。

---

输出文件总览

一次完整任务通常产出:

markdown/
├── <slug>-expert-1.md
├── <slug>-expert-2.md
├── <slug>-expert-3.md         (可能存在,视专家数)
├── <slug>-fact-check.md
├── <slug>-red-team.md
├── <slug>-final.md
└── svg/                       (如有用 svg)
    └── <...>.svg

回复用户时,**列出所有产出文件的路径**,并简明告诉用户每篇是干嘛的。

---

关键原则(写在最后,提醒自己)

1. **领域分析先于一切**——专家选错,后面全跑偏。 2. **真正并行,不要串行**——多位专家必须在同一回合启动。 3. **自我验证不过就改,改完再验证,直到通过再落盘**——专家稿尤其重要,因为后面的人都基于它工作。 4. **事实核查和红队要克制**——克制是这条流水线的生命线。一旦它们开始"为了反驳而反驳",整篇终稿就废了。 5. **终稿是重写,不是缝合**——读懂后忘掉,重新写。缝合味一出来,文章就废了。 6. **第一性原理不表格化**——前置条件写在正文里,文笔要通。 7. **人味 > AI 味**——把"我是 AI,所以我客观全面"这种话从脑子里删掉,像个人那样写。