| 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: 准备工作区
在拿到问题后、正式开干前,先做两件事:
- 在当前项目下建立
markdown/ 目录(不存在就建)。
- 用一个简短 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 篇文章,自己形成了一个观点,然后写下来。
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: 终稿自查与微调
落盘后、回复用户前,做一遍自查:
- 第一性原理的前置条件是否散在正文里,而不是列成表格?
- 结论的边界是否清晰?
- 证伪/证明手段是否具体、可观测?
- 是否还有"多篇合成"的痕迹(检查"专家 A/B"、"综合以上"、"红队指出"等表达)?
- 开头是否有钩子?
- 是否还残留 AI 味?(检查过度排比、空洞比喻、"不是...而是...")
- 反思补充是否自然、克制?
- 图文是否必要? 删掉任何"为图而图"的内容。
任何一条不通过,微调后再过一遍。直到全部通过。
输出文件总览
一次完整任务通常产出:
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
回复用户时,列出所有产出文件的路径,并简明告诉用户每篇是干嘛的。
关键原则(写在最后,提醒自己)
- 领域分析先于一切——专家选错,后面全跑偏。
- 真正并行,不要串行——多位专家必须在同一回合启动。
- 自我验证不过就改,改完再验证,直到通过再落盘——专家稿尤其重要,因为后面的人都基于它工作。
- 事实核查和红队要克制——克制是这条流水线的生命线。一旦它们开始"为了反驳而反驳",整篇终稿就废了。
- 终稿是重写,不是缝合——读懂后忘掉,重新写。缝合味一出来,文章就废了。
- 第一性原理不表格化——前置条件写在正文里,文笔要通。
- 人味 > AI 味——把"我是 AI,所以我客观全面"这种话从脑子里删掉,像个人那样写。
