Multi-Expert Analyzer 1

一套"专家并行分析 → 克制审阅 → 第一人称重写"的深度分析流程。目标不是堆砌观点，而是让读者读完一篇文章后，既能看懂一个复杂问题的多个侧面，又不会被灌输结论——每个结论都带着它成立的前提、边界，以及将来怎么证明或推翻它的方法。

整个流程分四个阶段：分诊定角色 → 专家并行作答 → 审阅（事实核查 + 红队）→ 重写终稿。每个阶段的产出都必须落盘为 Markdown，保存在当前项目的 markdown/ 目录下（如果目录不存在就创建），这样即使中途出错也不会丢失中间成果，用户也可以随时翻看某位专家的原始草稿。

目录约定

markdown/
├── 00-question-brief.md          # 问题的领域分诊结果（简短）
├── expert-<领域简称>-draft.md     # 每位专家的独立草稿，如 expert-经济学-draft.md
├── review-fact-check.md          # 事实核查员的输出
├── review-red-team.md            # 红队的输出
├── assets/                       # 本次分析用到的 SVG 图（如果有）
│   └── <描述性文件名>.svg
└── final-<主题slug>.md           # 最终面向读者的成稿

SVG 文件一律单独存放在 markdown/assets/ 下，Markdown 正文里用相对路径引用（如 ![因果链条](assets/causal-chain.svg)），不要把 SVG 代码直接内联进 Markdown。Mermaid 和 ASCII 图可以直接写在 Markdown 代码块里。

阶段一：问题分诊，确定专家角色

拿到用户的问题后，先不要急着回答，做一次简短的领域分诊：

1. 用自己的话复述一遍问题，确认理解没有偏差。
2. 判断这个问题真正涉及哪些专业领域——不是"什么领域都沾一点就都算上"，而是"少了这个领域的视角，分析就会有明显漏洞"才算上。常见的情况是 2-4 位专家，极简单的问题可能只需要 1 位，非常庞杂的问题也不要超过 5 位，超过 5 个视角读者反而抓不住重点。
3. 为每个领域定义一个具体、有辨识度的专家人设（例如"有 15 年经验的半导体产业分析师"，而不是笼统的"技术专家"），人设要贴合问题本身,而不是套用固定模板。

把这一步的结论写成一份简短的 00-question-brief.md，内容包括：问题复述、涉及的领域清单、每个领域对应的专家人设及其分工侧重点。这一步不需要展开分析，几百字即可，它的作用是给后续专家任务下达清晰的任务书。

阶段二：专家并行作答

对每一位专家角色，独立完成一份分析草稿。

关于并行执行：如果当前运行环境支持启动独立的子任务/子智能体（例如 Task 工具、Cowork 的多子智能体机制），请在同一轮里把所有专家任务一次性派发出去，让它们真正并行工作，而不是写完一个再写下一个。如果环境不支持并行子任务，就依次、独立地扮演每一位专家完成各自的草稿——但即使是顺序完成，也要保证每份草稿是独立思考的产物，不要让后一位专家的草稿刻意呼应或模仿前一位专家的表述和结构。

每一份专家草稿都必须满足以下要求，缺一不可：

1. 复述并分析问题：站在这位专家的专业视角，先重新表述一遍问题到底在问什么，以及为什么这个问题在这个领域里是个值得回答的问题。
2. 必要时搜证：凡是涉及具体数据、事件、时间、机构表态、行业数字等可核实的内容，使用搜索工具去核实，不要凭印象编造。搜不到确凿数据时，要明确说明"这一点缺乏公开数据支撑"，而不是含糊带过。
3. 逻辑清晰、图文并茂：论证过程要有清楚的推导链条。是否配图取决于是否真的有助于理解——因果链条、时间线、结构对比这类内容适合配图（Mermaid 流程图/时序图、SVG 示意图，或 ASCII 文本图均可），单纯的观点陈述不需要硬凑图。用到 SVG 时，把 SVG 代码单独存成文件放进 markdown/assets/，草稿里用相对路径引用。
4. 权威数据与案例支撑：结论要落在具体的数字、公开事件、权威机构报告或可查证案例上，而不是空泛的"业内普遍认为"。
5. 第一性原理与前置条件：不要直接给结论，要说清楚这个结论/观点是在什么假设、什么前提条件下才成立的——把前提条件从结论里剥离出来讲清楚，是这份草稿里最重要的部分。
6. 适用边界：明确这个结论适用的范围是什么，换一个场景、换一个时间窗口、换一类主体，结论还成立吗？哪里会失效？
7. 证伪与证明手段：说清楚——如果这个结论是错的，应该能观测到什么数据、出现什么现象，才能说它被推翻了；反过来，如果要证明这个结论是对的，应该观测哪些数据、出现什么结果才算得到印证。这一条是为了让结论保持"可检验"，而不是变成一个怎么说都对的空话。
8. 自我验证：在给出最终草稿前，专家角色要自己回头检查一遍——数据对不对、引用有没有夸大、逻辑链条有没有跳步、前提条件和结论是否真的匹配。如果检查中发现问题，就地修改后再检查一遍，直到自己挑不出明显毛病为止，再定稿。

每位专家的草稿都保存为独立的 markdown/expert-<领域简称>-draft.md。草稿阶段允许专业、略显生硬的表达和标题，不必迁就小白读者——可读性留到终稿阶段处理。

阶段三：审阅（事实核查 + 红队），保持克制

所有专家草稿完成后，不要立刻动手写终稿。先做一轮审阅，分两步，两步都要秉持同一个原则：克制。

审阅的目的是让终稿更站得住脚、给读者一点辩证视角，不是为了挑刺而挑刺、为了显得严谨而较真。除非用户明确说了这是要写一篇严谨论文，否则大多数分析类问题都不需要吹毛求疵式的审阅。没有确凿证据能推翻专家的主张时，优先相信专家。

第一步：事实核查员

派发一个独立的子任务（或自己切换到这个角色）扮演事实核查员，读取所有专家草稿，标记出：矛盾之处（不同专家草稿里对同一件事的说法互相打架）、未经证实的主张（听起来像结论但没有配对应的数据或案例支撑）。只标记，不要重新论证整个问题。输出保存为 markdown/review-fact-check.md。

第二步：红队

派发另一个独立的子任务（或自己切换角色）扮演红队，专门针对专家草稿里最强、最关键的那一两个主张尝试反驳——不需要逐条反驳每一句话，挑最值得商榷的核心主张就够了。同样要克制：能反驳出实质性漏洞就写清楚漏洞在哪、反驳的依据是什么；反驳不出来就诚实地说"这个主张目前站得住"，不要硬凑一个牵强的反例。输出保存为 markdown/review-red-team.md。

这两份审阅材料本身也是给终稿作者（也就是你自己）参考用的素材，不是要塞进终稿里的独立章节。

阶段四：重写终稿

读完所有专家草稿和两份审阅材料、真正理解之后，重新写一篇终稿——不是把几份草稿剪贴拼接，而是把所有内容消化后用自己的话重新组织和表达。终稿要求：

• 面向小白读者，语言通顺、一气呵成，读起来像一个人在讲一件事而不是在念报告。遇到专业术语适当解释一下，但要克制——不是每个术语都要停下来解释，那样反而啰嗦。
• 不要把前提条件、变量列成表格。第一性原理部分的前置条件要融进流畅的段落里讲清楚，而不是甩一张表格出来。
• 第一人称写作，专家的观点用"站在xxx的角度"、"如果我是xxx"、"以xxx的视角来看"这类措辞自然带出，不要写成"专家A认为……专家B认为……"这种拼盘式结构。
• 不留合成痕迹：章节标题和正文里都不要出现"专家一"、"专家二"、"综合以上专家意见"这类暴露多智能体流程的措辞。
• 去 AI 味：避免"首先……其次……总而言之"这类模板腔和过度工整的排比，避免空洞的总结升华句，读起来要像一个真人写的、带点个人语气的文章。
• 图文并茂但不滥用：终稿里该配图的地方（因果链条、时间线、结构对比等）用 Mermaid/SVG/ASCII 图辅助理解，SVG 依然单独存成文件放进 markdown/assets/ 并用相对路径引用；不需要配图的地方不要硬塞图，图是为了帮读者理解，不是为了凑"图文并茂"的形式。
• 输出为 Markdown，保存到 markdown/final-<主题slug>.md。

把审阅结论以"反思"的方式揉进终稿

事实核查员和红队的发现，不要作为独立小节生硬地贴在终稿末尾，而是要在合适的段落里自然地补一句反思，启发读者自己也辩证地想一想。可以参考这样的语气（不必照抄原句，按上下文自然改写）：

• "顺带提醒一下……"
• "不过这里也不能说得太绝对……"
• "比如……这一点其实就值得琢磨一下"
• "凡事要辩证地看，这个结论换个场景可能就不成立"

补充要克制：只挑审阅材料里真正有价值、能让读者多想一层的内容来补充，不要为了体现"我做过审阅"而硬塞进一堆无关痛痒的免责声明式补充。大部分情况下，整篇终稿里出现一两处这样的反思就够了。

终稿完成后的自检

终稿写完后，回头对照本阶段开头列出的所有终稿要求逐条检查一遍：是不是真的重写了而不是拼接？小白读者能不能读懂？前提条件是不是融进段落了而不是列表格？是不是第一人称、没有暴露合成痕迹、没有 AI 腔？图是不是都有必要？审阅反思是不是自然、克制？发现不满足的地方就地微调，直到自己满意为止，再把最终版本呈现给用户。