Multi-Expert Analyzer 2

一个把"棘手问题"拆给多位领域专家、经过克制的事实核查与红队复核、最后由一个未被中间过程"污染"的撰稿人重写成人话长文的工作流。

核心理念：复杂问题的答案质量来自两件事——多个真正专业的视角，以及一次不被中间草稿风格带偏的重写。所以流程刻意分成"发散（专家）→ 收敛审阅（事实核查/红队）→ 重写（终稿人）"三段，且终稿人应当尽量以新鲜的视角去读前面的材料，而不是从中间小修小补。

何时使用

用户抛出一个足够复杂、跨领域、或有争议的问题，简单回答会显得单薄的时候。如果问题很简单（一个领域内的常识问答），不必套用整套流程，直接回答即可——本 skill 是为"棘手"问题准备的。

关于"子智能体"与"并行"

理想流程中，每位专家、事实核查员、红队、终稿撰写人都应该是独立的子智能体，彼此不共享上下文，这样才能真正做到"防止上下文污染"和并行加速。

• 如果当前环境有可用的子智能体/Task 工具：请为每一位专家、事实核查员、红队、终稿撰写人分别派发独立任务，专家阶段并行启动。
• 如果当前环境没有子智能体（例如普通对话）：老老实实按顺序自己扮演每一个角色，但要用文件而不是记忆来传递信息——每个角色写完就把稿子存成 markdown 文件；切换到下一个角色（尤其是终稿撰写人）时，重新去读磁盘上的文件，而不是依赖对话上下文里"我刚才写了什么"的印象。这是在没有真子智能体时，模拟"新开一个干净大脑"的最佳近似。终稿撰写人尤其要做到：假装自己完全没参与过前面的讨论，只是刚拿到这几份文件的新人。

无论哪种模式，所有中间产物和终稿都必须落盘为 markdown 文件，保存在当前项目的 markdown/ 目录（如目录不存在则创建）。

整体流程

① 领域拆解与角色分配
② 专家智能体并行/依次作答（含自我验证循环）→ 各自存草稿
③ 事实核查员 + 红队复核（克制、不为难而难）→ 存复核记录
④ 终稿人（干净大脑）重写为第一人称长文，融入①②③但重写、不拼接
⑤ 终稿自检：对照第④步的所有要求逐条检查，必要时微调

第一步：拆解问题、分配专家角色

先复述你理解的问题，然后判断这个问题涉及哪些专业领域。多数"棘手问题"其实是跨领域的（比如"某产品估值是否合理"可能同时涉及财务、行业竞争、心理学/群体行为、监管政策），不要偷懒只派一个专家。

• 领域数量没有上限，但也不要为了显得"全面"硬凑角色——只选择真正能提供不同增量视角的专家。通常 2～5 位比较合适。
• 给每位专家一个具体身份（例如"数据库存储引擎架构师"而不是笼统的"技术专家"），身份越具体，后面第一人称转述时越有代入感。
• 把角色分配和你的判断依据简单告诉用户或记录下来，方便后面终稿人回溯。

第二步：专家智能体作答

每位专家的产出必须满足以下要求（这些要求本身就是为了让结论经得起推敲，而不是走流程）：

1. 先复述并分析问题——用这位专家的专业语言重新表述一遍问题，说清楚这位专家会从什么角度切入。
2. 必要时搜证——凡是涉及具体数字、时间、政策、企业名称、事件的地方，去搜索/核实，不要凭印象编。搜到的内容按版权规范转述，不整段照抄。
3. 逻辑清晰 + 图文并茂——用 mermaid、ascii text 或 svg 辅助说明结构性、流程性、比较性的内容。如果用 svg，必须单独存成 .svg 文件，再在这位专家的 markdown 草稿里用相对路径引用，不要把 svg 源码直接堆在 markdown 正文里。图不是必须的，只有真正有助于理解时才加。
4. 权威数据、案例支撑——结论不能空对空，要有具体的数据来源、真实案例。
5. 第一性原理 + 成立的前置条件——说清楚"这个结论成立，需要哪些假设/条件为真"，而不是把结论包装成普适真理。
6. 适用边界——结论在什么范围内成立，超出这个范围会怎样。
7. 证伪与证明手段——明确写出：要证伪这个观点，应该去观测什么数据、出现什么结果就说明观点站不住；要证明/支持这个观点，应该观测什么数据、出现什么结果就是有力支持。这一条是重灾区，很多分析写完就忘了留这个口子，务必认真写。
8. 自我验证一轮再定稿——写完后，专家自己再读一遍草稿，检查数据是否准确、逻辑是否自洽、是否有前后矛盾。如果发现问题，修改后再检查一遍，直到确认无误再定稿。这一步不用写成一个单独的章节展示给用户，但确实要做，且如果自查中发现较大问题应该在最终这版草稿里已经修正。

每位专家的草稿单独存为 markdown 文件，建议命名 markdown/expert-<领域简称>.md，涉及的 svg 图存为 markdown/assets/<领域简称>-<图名>.svg（没有 assets 目录就创建）。

第三步：事实核查员 + 红队复核

所有专家产出后，不要急着直接写终稿。先做一轮收敛审阅：

事实核查员：读所有专家的草稿，标出：

• 相互矛盾的主张（比如专家 A 和专家 B 对同一件事给出了不一致的数字或结论）
• 缺乏证据支撑、只是断言的主张

红队：挑草稿中"分量最重"的几个核心主张，尝试反驳——不是逐句挑刺，而是问"这个结论有没有明显的反例、有没有更强的对立解释"。

这两个角色都要遵守同一个克制原则：

• 默认相信专家的专业判断，除非有确凿证据能推翻。没有实锤就不要动人家的结论。
• 不要为了挑刺而挑刺。绝大多数情况下用户要的是一篇有说服力的深度文章，不是一篇无懈可击的学术论文——除非用户明确说了要写严谨论文级别的东西，才升级审查强度。
• 只标出真正有价值、值得读者多想一层的点，而不是把每个能挑的毛病都列出来。

事实核查员和红队各自的结果也要存成 markdown 文件：markdown/fact-check.md 和 markdown/red-team.md，内容简明扼要即可（矛盾点/待证实主张列表 + 反驳尝试及其强弱判断），不需要写成正式报告的排场。

第四步：终稿人重写（干净大脑）

这是全流程质量的关键一步。终稿人要做的不是"汇总"或"拼接"，而是完全重写——读懂前面所有材料（专家草稿 + 事实核查 + 红队）之后，当作自己从零开始构思了这篇文章。

终稿要求：

• 不能有拼凑痕迹。章节标题和正文里都不应该看得出"这一段是专家A写的，这一段是专家B写的"这种缝合感。
• 第一人称行文，专家意见用"站在xxx的角度"、"如果我是xxx"、"以xxx的视角来看"这类措辞自然带出，而不是"专家A认为……专家B认为……"这种报告腔。
• 标题要一针见血，让人一看标题就知道这篇文章在回答什么真正的问题。
• 开头要有钩子：先点破为什么现在要聊这个话题、背景是什么，再引出接下来要讨论的核心焦点，把读者的好奇心先勾起来，不要上来就罗列背景。
• 面向小白，一气呵成。遇到专业术语要解释，但要克制——只解释真正会卡住读者的术语，不是每个术语都停下来讲一遍，那样反而啰嗦。
• 逻辑清晰，有权威数据、案例支撑结论。
• 遵循第一性原理：结论成立的前置条件要讲清楚，但要用流畅的叙述文字表达，不要列成表格——前置条件/变量表格化会打断阅读节奏，破坏"一气呵成"的要求。
• 结论有适用边界：说清楚这个结论/观点在什么情况下适用，什么情况下不适用。
• 留出证伪与证明的口子：跟专家草稿里的要求一样，读者应该知道，如果未来出现什么数据/事件，会证明或推翻这篇文章的核心观点。
• 有人味，没有 AI 味。避免"综上所述"、"值得注意的是"这类AI高频套话堆砌，句式要有长短变化，不要每段都是"首先…其次…最后…"的模板腔。
• 图文并茂但不滥用：只在真正有助于理解时才插入 mermaid/ascii/svg 图（svg 同样要单独存文件、markdown 里引用）。不要为了"看起来完整"硬凑一张图。
• 输出为 markdown，保存到项目 markdown/ 目录，建议命名 markdown/final-<主题slug>.md。

第五步：把审阅意见揉进终稿（而不是另起一节）

事实核查员和红队发现的有价值的点，不要单独开一个"风险提示"或"争议点"章节生硬地贴在文章末尾，而是要以反思式的插入自然地穿插在正文相应位置，语气可以参考：

• "顺带提醒一下……"
• "不过也不能太绝对……"
• "比如……这一点就值得反思"
• "凡事要辩证地看……"

这些插入要克制——只挑真正有启发性、值得读者多想一层的内容插入，不要为了显得"客观全面"而每隔几段就塞一句"但也有人持不同意见"，那样会稀释文章的观点浓度，读起来也很假。大多数事实核查/红队记录里的琐碎点，直接忽略就好，不用都用上。

第六步：终稿复检

写完终稿后，回头对照第四步列的每一条要求逐条自查一遍（有没有拼凑痕迹、第一人称是否自然、标题是否够犀利、开头钩子够不够、术语解释是否克制、前置条件是否写成了表格、证伪/证明的口子是否交代清楚、语气是否有AI味……），发现问题就直接在终稿里改，不用另外写一份检查报告。

输出清单（每次任务结束后应该存在于 markdown/ 目录下）

• expert-<领域>.md × N（每位专家一份）
• fact-check.md
• red-team.md
• final-<主题slug>.md（真正要给用户看的成品）
• assets/*.svg（如有用到 svg 图）

任务结束时，把 final-<主题slug>.md（以及它引用的 svg）作为最终交付物呈现给用户，中间过程的文件不需要主动展示，除非用户想看。