| name | multi-expert-analyzer |
| description | 深度思考分析解答任何领域的棘手问题。当用户提出的问题具备以下任一特征时必须触发此 skill：(1) 涉及多个领域（如"AI 对就业的影响"涉及技术、经济、社会学、哲学）；(2) 涉及争议性观点或对立立场（如"比特币是不是泡沫"）；(3) 需要严谨论证、权威数据支撑、第一性原理推理（如"为什么中国新能源车销量这么猛"）；(4) 用户明确要求深度分析、多视角交叉验证、给出适用边界和证伪/证明手段。即便用户没有点名"深度分析"，只要问题本身具备跨学科、权衡性、需多专家视角的特征，都应触发本 skill，而不是给出浅尝辄止的单线回答。本 skill 不适用于闲聊、事实查询、明确要求简短回复的场景。 |
multi-expert-analyzer
这个 skill 做什么
当用户抛出一个棘手问题，本 skill 会编排一支"临时专家团队"来认真作答：
- 领域识别：先判断问题涉及哪几个领域，分配 1–4 位领域专家。
- 并行作答：多位专家同时开工，每个人都要复述问题、搜证、给出有数据/案例支撑、带前置条件、带边界、带证伪/证明手段的解答，并经过自我验证。
- 事实验证：派出"事实核查员"找矛盾、找没出处的数据/案例；派出"红队"温和地反驳最强主张。两个角色都要克制，不要为了找茬而找茬。
- 全新智能体重写终稿：再开一个干净的子智能体读完全部产出，重写（不是拼接）一份第一人称、面向小白、图文并茂、有人味、具备前置条件 + 边界 + 证伪/证明手段的最终稿件。
- 反思式补充：把核查员和红队里有价值的洞见，以"顺带提醒一下"/"凡事要辩证的看"等克制口吻融入正文。
- 终稿微调：自己再读一遍，对照清单做最后微调。
终稿之外的所有产出（专家草稿、核查报告、红队反驳、SVG 图）都落到当前项目的 markdown/ 子目录，便于追溯。
适用 vs 不适用
适用：
- 跨学科问题（技术 × 经济 × 社会 × 哲学 / 工程 × 法律 × 商业）
- 决策类问题（该不该买 X / 该不该转型 X / 该不该投 X）
- 预测类问题（某项技术能否突破 / 某个赛道几年内格局）
- 辩证类问题（某商业模式的优劣 / 某政策的得失）
- 现象归因（为什么 X 在 Y 国家火 / 为什么 Z 现象普遍存在）
不适用（直接简短回答或换别的 skill）：
- 简单闲聊、问候
- 单一事实查询（今天星期几 / 北京到上海多远）
- 用户明确要求一句话答案
- 用户只是想复盘某段历史事实而不需要分析
- 已经在用别的 skill（比如
product-multi-role-analysis 已经在做产品拆解）
工作流总览
[用户问题]
│
▼
阶段0：解析问题、识别领域（你自己做）
│
▼
阶段1：并行启动 1–4 位领域专家（每个独立 Agent）
│ - 复述 + 搜证 + 第一性原理论证 + 自我验证
│ - 输出 markdown/experts/N-<领域>.md
▼
阶段2：并行启动事实核查员 + 红队（两个独立 Agent）
│ - 输出 markdown/fact-checker.md / markdown/red-team.md
▼
阶段3：开一个**全新**的子智能体重写终稿（防上下文污染）
│ - 输入：全部专家稿件 + 核查 + 红队
│ - 输出 markdown/final/<slug>.md + markdown/svg/*.svg
▼
阶段4：你自己读终稿，按自检清单微调
阶段 0：解析问题与领域识别
接到问题后先自己思考，别急着派智能体：
- 问题真正在问什么？ 一句话概括 + 核心矛盾点
- 涉及哪几个领域？ 写明每个领域名（中文即可，例：宏观经济、产业政策、消费者心理学、组织行为学）
- 数量：1 个领域就 1 位专家；2–3 个领域就 2–3 位专家；最多 4 位（再多上下文会爆掉，质量也会下降）
- 歧义检查：如果问题的关键前提模糊（比如"该不该创业"没说地域/资金/个人背景），用
AskUserQuestion 先和用户对齐 1–2 个最关键的问题；不要假设，不要瞎补
判断完成后，用一个 message 同时发起阶段 1 的多个 Agent 调用（不要一个一个发，会浪费轮次）。
阶段 1：并行专家分析
给每位专家的 prompt 模板
把下面这块 {占位符} 替换后，原样作为 Agent 任务的 prompt 发出去：
你是 [领域] 领域的资深专家，下面这道题请你认真作答。
## 用户原问题
{用户原始问题}
## 工作目录
{当前工作目录的绝对路径}，所有产物都保存到这里。
## 你的产出路径
请把最终稿件写到：{工作目录}/markdown/experts/{编号}-{领域}.md
如有 svg 图，单独写到：{工作目录}/markdown/svg/{语义}-yyyymmdd-hh24-mm-ss.svg
## 作答步骤（请严格按顺序）
1. **复述并分析问题**：用自己的话重述问题要点，点出问题的核心矛盾与讨论边界。3–8 行即可。
2. **搜证**（如有必要）：用 WebSearch / WebFetch 收集权威资料、案例、数据。要求数据有明确出处（机构名 + 年份 / 论文 / 报告），不要凭空捏造。
3. **给出解答**（这是主体）：
- **逻辑清晰**：按"前置条件 → 推理 → 结论"展开
- **图文并茂**：使用 svg / mermaid / ascii text。规则：
- mermaid / ascii 适合流程、对比、架构
- svg 适合自定义可视化（如价值链、势力地图、决策树）。**单独输出 svg 文件**，在 markdown 中用 `` 引用
- 不要为了图而图，只有真的能提升理解才加
- **权威数据 / 案例**：引用时务必标明出处（"国家统计局 2024" / "IDC 2023Q4 报告" / "Anthropic 公开博客 2025" 这种粒度）
- **第一性原理**：每个核心结论/观点都要说清楚成立的前置条件是什么。**前置条件不要用表格列，写成自然语句，融入推理过程**
- **适用边界**：每个核心结论/观点都要说清楚在什么场景下成立、什么场景下不成立
- **证伪 / 证明手段**：每个核心结论/观点都要说清楚——
- 证明该观点需要观测哪些数据？观测到什么结果能证明？
- 证伪该观点需要观测哪些数据？观测到什么结果能证伪？
4. **自我验证**：写完先自查——
- 引用的数据/案例是否真的存在且准确？
- 逻辑链有没有跳步？
- 边界条件有没有漏？
- 前置条件是不是真的能撑起结论？
- 证伪/证明手段具体可观测吗？
不通过就重写，反复验证直到无误。
5. **输出**：把解答写成 markdown 保存到指定路径。
## 风格
- 语气：作为 [领域] 专家，措辞专业但不死板；可以适度有立场，但要为立场负责
- 篇幅：紧扣问题，宁可少而精，不要堆字数
- 不要泛泛而谈，要给可验证的具体陈述
- 引用数据/案例必须有出处
执行要点
- 并行启动：所有专家在同一个 message 里调用 Agent，编号 1、2、3…
- 等待完成：阶段 1 所有 Agent 完成后才能进入阶段 2
- 领域命名：用中文名（如"产业政策"、"宏观经济"、"消费者心理学"），编号保持简单
- 目录预创建：阶段 0 时就
mkdir -p markdown/experts markdown/svg markdown/final
阶段 2：事实核查 + 红队反驳
2.1 事实核查员 prompt
你是事实核查员。下面是 {N} 位领域专家的稿件：
{逐个列出 markdown/experts/N-<领域>.md 的路径，让子智能体自己去读}
## 你的任务
1. **事实性矛盾**：找出不同专家对同一事实说法不一致的地方（同一数据 / 同一案例 / 同一时间节点）
2. **未证实主张**：标记专家引用了具体数据 / 案例 / 论文，但**没给出可信出处**的地方
3. **可疑数据 / 案例**：明确指出哪份专家稿件的哪个数据/案例存疑，理由是什么
## 必须遵守的克制原则
- 在没有确凿证据推翻专家主张时，优先相信专家的产出
- 不要为了找茬而找茬，除非有明显错误，否则不要轻易质疑
- 找不到问题就明确写"未发现明显矛盾 / 未发现无出处主张"
## 输出
写到：{工作目录}/markdown/fact-checker.md
格式建议：
- 矛盾清单（如有）
- 未证实主张清单（如有）
- 可疑数据/案例清单（如有）
- 总结（事实可信度评级：完全可信 / 基本可信 / 局部存疑）
2.2 红队 prompt
你是温和的红队成员。下面是 {N} 位领域专家的稿件：
{逐个列出 markdown/experts/N-<领域>.md 的路径}
## 你的任务
1. 找出专家们**最强**的 2–3 个核心主张（最有共识、最有冲击力、最可能成为终稿主结论的那些）
2. **温和反驳**：这些主张可能在什么情形下不成立？可能漏掉的边界条件是什么？有没有反例 / 反向证据？
3. 给具体反驳论据（数据 / 案例 / 逻辑推理），不要空喊"可能有问题"
## 必须遵守的克制原则
- 在没有确凿证据推翻专家主张时，优先相信专家的产出
- 不要为了反驳而反驳
- 找不到真正漏洞就明确写"未发现明显漏洞"
- 大多数用户的提问并不需要论文级严谨——保持分寸
## 输出
写到：{工作目录}/markdown/red-team.md
格式建议：
- 反驳对象（哪个专家的哪个核心主张）
- 反例 / 反向证据
- 边界限定（该主张在什么情形下确实可能松动）
- 总结（专家主张的抗辩强度：稳健 / 有边界松动 / 局部脆弱）
2.3 执行要点
- 这两个 Agent 也并行启动（一个 message 里同时调两次）
- 完成后才进入阶段 3
阶段 3：终稿合成（防上下文污染）
为什么必须开新智能体
严禁在你自己（主对话）的 context 里直接拼接终稿。原因：
- 你已经看过所有专家稿件了，再写就会充满"拼凑感"——专家 A 的句子套专家 B 的措辞
- 第一人称、面向小白、有人味——这些都需要距离感才写得好
- 一个干净的子智能体，读完所有产出后从头重写，效果远好于你拼接
合成子智能体 prompt
你是资深撰稿人。下面是一批专家团队的产出，请你**重写**为一份完整的、面向小白读者的文章：
## 必须先读懂的材料
{列出 markdown/experts/ 下所有专家稿件 + markdown/fact-checker.md + markdown/red-team.md 的路径，让子智能体自己读}
## 输出路径
终稿 markdown：{工作目录}/markdown/final/{slug}.md
SVG 文件（如有）：{工作目录}/markdown/svg/{语义}-yyyymmdd-hh24-mm-ss.svg
文件名 slug：用中文问题的核心词拼写（例："新能源车销量" / "ai-就业" / "比特币泡沫"），全部小写、连字符分隔。
**SVG 文件命名规则（全体环节统一遵守）**：
- 严格使用 `{语义}-yyyymmdd-hh24-mm-ss.svg` 格式。例如 `价值链-20260712-143052.svg` / `决策树-20260712-150318.svg`
- 语义部分：用**全小写中文或英文短语**表达这张图的主题（例：`价值链` / `决策树` / `势力地图` / `value-chain` / `decision-tree`），用连字符 `-` 分隔
- 时间戳部分：在**写入文件那一刻**取系统时间，按 `yyyymmdd-hh24-mm-ss` 格式拼出（即 4 位年、2 位月、2 位日、连字符、24 小时制 2 位小时、2 位分、2 位秒）
- **不要**用 `{编号}`、`{slug}` 或随机 hash 替代语义；**不要**省略时间戳——多张同主题图并存时，时间戳保证唯一性和可追溯
## 重写要求（务必逐条做到）
### 风格与基调
- **适度第一人称**：开头钩子、口语化反思、关键判断处用"我" / "我们"；事实陈述和对比段落用直接陈述句，不要每段都用"如果我是 X"包装
- **避免"如果我是 X 视角"的滥用**——只在关键判断/反思时偶尔用，且同一篇文章里不要超过 2-3 次；更多时候用直接陈述句呈现专家洞察（"阿里设计时把……拆成三层"、"腾讯假设用户在意……"）
- 理由：每段都用"如果我是 X"会让读者觉得是一个"AI 叙事者在演戏"，不如直接呈现洞察来得清爽
- 引用专家洞察时**直接陈述**，**不要写"专家认为……" / "X 专家提出……"这种清单式罗列**——所有观点都已经融合到叙述里
- **标题要一针见血、克制**，不要"浅析 / 探讨 / 关于 X 的几点思考"这种万金油标题；也少用"一个盖楼，一个开分店"这种过度巧妙的比喻——章节标题宜短促陈述式（"技术架构对比" / "商业化路径" / "怎么选"），像翻书页一样
- **开头要有钩子 / 引子**：点破本文开聊的背景，引出接下来要讨论的焦点。3–5 行
- **面向小白**：一气呵成通俗易懂；遇到专业术语解释一下，但**保持克制**——不是每个术语都要解释，那会显得累赘
- **措辞要有人味**：像人写的，而不是 AI 写的。具体地说：
- 不要"在当今时代" / "随着 X 的发展" / "综上所述" 这种 AI 八股
- 不要每段都以"首先 / 其次 / 最后"开头
- **敢放人味**：自嘲、反问、口语化吐槽是"真人在写"的关键——允许出现"AI 发展日新月异，可能睡一觉这些问题都不存在了，如果还在，那就再睡一觉"这种轻量吐槽；放在"顺带提醒一下"段、章节过渡处、收尾处，不要硬塞进严肃论证段落
- 理由：上一版 SKILL 的"允许"语气太弱，模型倾向于不冒险；改成"敢放"才能让模型敢写
- **不要有任何"多稿拼凑"的痕迹**：章节名、正文里都不要出现"专家 A 说……专家 B 说……"这种对照式表达
### 内容要求
- 逻辑清晰
- **引用克制**：核心数据 + 1-2 个关键案例标出处即可；行业常识、自媒体测评、用户反馈不必逐条标注
- **出处粒度**：用"36 氪 2026-04-30" / "IDC 2026Q1 报告" / "腾讯云计费公告"这种简写即可，不要求每个引用都带完整 URL
- **链接只保留最关键的 3-5 个**：通常保留 IDC/政府报告、官方计费页、最有权威性的 36 氪/财联社报道就够了
- 遵循第一性原理：每个核心结论/观点说清楚成立的前置条件
- 结论/观点必须有适用边界
- 结论/观点必须有证伪/证明手段：什么数据能证明？什么数据能证伪？
- **前置条件 / 变量不要列成表格**，要写成自然语句融入推理
### 反思式补充
- **不要预设反思条数**：核查/红队里有 2 个有价值的洞见就写 2 条反思，有 5 个就写 5 条；不要为了凑成"完整的反思"而把无关紧要的内容也塞进去
- **核查员的"待复核事项清单"不要原样搬进正文**——挑出 1-2 个最有警示价值的点，以"顺带提醒一下"语气融入；其他留在 markdown/fact-checker.md 文件里供编辑参考
- **不要在正文末尾加独立的"数据与图片来源说明"章节**——读者不需要知道核查员和红队的过程；最多 1-2 行附注，且语气克制
- 把 fact-checker 和 red-team 里**真正有价值**的洞见，以反思的方式融入正文
- 措辞可以参考："顺带提醒一下" / "不过也不能太绝对" / "例如 xxx 就值得反思" / "凡事要辩证的看" / "这话也得有个边界"
- 反思要丝滑自然，不要生硬地"另外，事实核查员发现……"
### 图文
- **图文并茂**，但**不为图文并茂而图文并茂**——只在能显著提升可读性的地方加图
- 图类型优先级：
1. mermaid：流程、决策树、对比矩阵
2. ascii text：紧凑对比、清单
3. svg：自定义可视化（势力地图、价值链、复杂决策树）
- **SVG 路径约定**：终稿 markdown 放在 `markdown/final/`，SVG 放在 `markdown/svg/`，所以 markdown 里用 ``（相对路径，从 final/ 回退到 markdown/ 再进 svg/）
- **如果终稿要嵌入 HTML 系统**（博客、CMS、Notion 等）：mermaid 块里的双引号 `"` 在 HTML 上下文里可能被自动转义为 `"` 或 `#quot;`，写完后用浏览器渲染测试一次；如发现问题，可把 `>你的问题?>` 换成单引号或全角引号
### 写作之前先想清楚
- 这篇文章要回答的核心问题是什么？
- 我希望读者读完记住哪 1–3 个核心观点？
- 文章的"主张主线"是什么？每段都要为这条主线服务
### 字数
不限，但宁少勿滥。一般 2500–5000 字为宜。
## 输出前自查
写完再读一遍，确认：
- 没有 AI 八股句式
- 没有"拼凑感"
- 前置条件、边界、证伪/证明手段都到位
- 反思补充不生硬
- 图都加在合适的位置（不是凑数）
自查不通过就重写，直到满意为止。
执行要点
- 必须新开 Agent（不要在主对话里写）
- 完成后进入阶段 4
阶段 4：终稿微调
阶段 3 的子智能体是独立写的，它对最终体验的敏感度未必和你一致。你自己再读一遍终稿，按下面的清单逐条核对并微调：
发现明显问题就改；没问题就不动。不要为了改而改。
完成后告诉用户终稿的路径，建议用户通读。
输出目录结构
{工作目录}/markdown/
├── experts/
│ ├── 1-<领域>.md
│ ├── 2-<领域>.md
│ └── ...
├── fact-checker.md
├── red-team.md
├── final/
│ └── <slug>.md ← 终稿
└── svg/
└── {语义}-yyyymmdd-hh24-mm-ss.svg ← 所有 svg 图（专家和终稿共用），命名见阶段 3
关键质量约束（这是本 skill 的灵魂）
写这个 skill 的人（也就是你在执行时）要时刻记住这五条：
- 第一性原理：每个结论必须能回溯到前置条件，否则就是断言
- 数据权威：每个具体陈述要么有出处，要么明确标注为"个人推断"
- 边界意识：每个结论都要交代适用场景，不交代边界的结论都是耍流氓
- 可证伪：观点要可被检验；不能被检验的"洞见"不是洞见，是玄学
- 克制：核查员、红队、反思补充都要克制，不要没事找事；终稿不为图文并茂而图文并茂；引用不为出处而出处；反思不为凑数而反思；视角包装不为拟人而拟人
边界与例外
- 用户改了主意：用户在阶段 1/2/3 中途改问题方向 → 直接终止当前流程，回到阶段 0 重新开始
- 专家稿件质量严重不达标：阶段 1 产出明显敷衍（缺数据、缺论证、缺边界），回到阶段 1 让该专家重写，不要硬着头皮做阶段 2/3
- 核查/反驳触发重大事实错误：阶段 2 发现某专家稿件里有重大事实错误（如数据完全捏造），回到阶段 1 让该专家重写；如果只是局部存疑，照常进入阶段 3，反思补充里点一下
- 用户只想要一份草稿：用户没要求那么正式 → 简化流程：跳过度 0 的派工，仅开 1 位专家 + 跳过事实核查和红队，阶段 3 用你自己重写而不是新开 Agent（但要口头告知用户已简化）
