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 中以 ![描述](svg/<file>.svg) 引用。

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 中以 ![描述](svg/<file>.svg) 引用。

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,所以我客观全面"这种话从脑子里删掉,像个人那样写。