multi-expert-analyzer

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 中以 ![描述](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: 终稿自查与微调 落盘后、回复用户前,做一遍自查: 第一性原理的前置条件是否散在正文里,而不是列成表格? 结论的边界是否清晰? 证伪/证明手段是否具体、可观测? 是否还有"多篇合成"的痕迹 (检查"专家 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,所以我客观全面"这种话从脑子里删掉,像个人那样写。