CtrlK
BlogDocsLog inGet started
Tessl Logo

multi-expert-analyzer

深度分析并解答任何领域的棘手问题。先判断问题涉及哪些领域,召集对应的领域专家分别搜证、按第一性原理作答(图文并茂、有权威数据和案例、讲清适用边界与证伪方式、自我验证),再经"事实核查"和"红队反驳"两道克制的校验,最后合成一篇面向小白、一气呵成、有人味的第一人称文章,全部产物存到当前项目 markdown/ 目录。触发条件:用户抛出一个想不通/难解/复杂/跨领域的问题并希望深入分析,例如"帮我分析一下……""这个问题到底怎么回事""从多个角度看……""深度思考一下……""这事儿靠谱吗""为什么会……未来会怎样",或任何需要多领域专家协作、第一性原理推演、证据支撑与证伪路径的深度解答。即使用户没有明说"多专家"或"深度分析",只要问题棘手、值得认真拆解,也应使用本 skill。

73

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

多专家深度分析

这个 skill 在做什么,为什么这么设计

很多棘手问题之所以棘手,是因为它横跨多个领域,单一视角必然有盲区。一个人再聪明,也很难同时是经济学家、工程师和心理学家。所以这里的思路是:先把问题拆到它真正所属的几个领域,让每个领域的专家独立作答,再由一个中立的合成者把这些视角织成一篇普通人读得懂的文章。

但多专家有个老毛病——每个专家都很自信,可他们之间可能互相矛盾,或者某个"权威数据"其实站不住脚。所以在合成之前,加了两道校验:一个事实核查员盯着专家们有没有自相矛盾或空口无凭,一个红队专挑最关键的结论去反驳。校验完才动笔。

有一点要特别克制:这两道校验不是来找茬的。 大多数问题并不需要写成严谨论文,过度的质疑只会让最终文章变得畏首畏尾、充满"但也可能……"。校验的价值不在于否定专家,而在于给最终文章埋下一些让读者会心一动、多想一层的点。所以校验结论不直接改写文章的主干,而是在文章成型后,把其中真正有价值的部分,以旁观者的口吻自然地嵌进去。

默认约定

  • 输出语言:默认中文,除非用户要求其他语言。
  • 面向读者:默认面向小白,通俗易懂。
  • 产物位置:全部存到当前项目的 markdown/ 目录下。
  • 严谨度:默认"日常深度"——把问题讲透即可,不必学术化。只有当用户明确说了"要严谨""写成论文""学术级""每个结论都要能站住"这类话时,才切换到"论文级",让两个校验器变得更较真。判断不准时,默认走日常深度。

工作流程

  1. 复述与领域诊断。 用一两句话复述问题,判断它涉及哪些领域。据此决定召集几位专家——要右尺寸:单一领域的问题 1 位专家足矣,跨领域问题一般 2–4 位。不要为了显得全面而硬凑专家;专家太多反而稀释重点。

  2. 建运行目录。 在当前项目下建 markdown/multi-expert/<主题slug>-<YYYYMMDD>/,内含子目录 experts/assets/review/。主题 slug 用简短的中文拼音或英文词。

  3. 召集专家(并行)。 对每个领域,先看当前环境有没有现成、贴切的专家 agent(比如"后端架构师""心理学家""投资研究员""土木工程师"等):

    • 有贴切的就直接调度它,把该领域的解题任务交给它。
    • 没有贴切的,就用 general-purpose(或类似通用)subagent 做角色扮演,在 prompt 里明确"你现在是某某领域的资深专家"。

    每位专家的任务书见 references/expert-brief.md——把它的要求完整传给每个专家 subagent,并告诉它自己的输出路径 experts/NN-<角色>.md在同一条消息里并行发起所有专家,让他们同时开工。

  4. 收齐草稿。 等所有专家写完各自的 experts/NN-*.md(以及引用到的 assets/*.svg)。

  5. 事实核查(克制)。 起一个"事实核查员"subagent,读完所有专家草稿,标记实质性的矛盾和明显空口无凭的关键主张。做法与克制原则见 references/verifiers.md。存到 review/fact-check.md

  6. 红队反驳(克制)。 再起一个"红队"subagent,只针对最承重的那几个结论尝试反驳。同样见 references/verifiers.md。存到 review/red-team.md

    第 5、6 步可以在同一条消息里并行发起——它们都只读专家草稿,互不依赖。

  7. 先写文章,再织入校验。 两个校验器都完成后,才动笔写最终文章。把它写成一篇干净、连贯、面向小白的第一人称文章;然后回头看两份校验报告,挑出其中真正有启发、能让读者多想一层的点,以旁观者视角丝滑地嵌进去。写法与文风要求见 references/synthesis.md。存到 final.md

  8. 交付。 告诉用户最终文章路径,以及中间产物(专家草稿、两份校验)的位置,方便他追溯。

关键原则速记

  • 专家独立作答:每位专家在自己的草稿里必须做到——复述并分析问题、第一性原理与前置条件、权威数据/案例支撑、适用边界、证明与证伪路径、交稿前自我验证一轮(不通过就改到通过)。图用 mermaid/ascii 直接内嵌;用 SVG 则单独存成 .svg 文件再在 md 里引用,不要把 SVG 源码内联进 md
  • 因果按时间顺序:凡是"因为 Y 所以 X""在某时点做了某决定"这类说法,都要有明确的时间锚点,别用"早期""后来""成熟之前"这类含糊词。结果已经发生的事,其原因不可能发生在它之后。
  • 校验器要克制:不为找茬而找茬,不为反驳而反驳。默认日常深度时,只标注真正会误导读者的问题。
  • 合成不留痕:最终文章以第一人称一气呵成,专家视角用"站在……的角度"来带出,章节名和正文都不出现"专家一""综合""事实核查"这类合成痕迹。第一性原理的前置条件、变量融进行文,别列成表格。
  • 要有人味:像人写的,不是 AI 写的。措辞自然,少用"首先/其次/综上所述"这类八股和排比堆砌。

参考文件

  • references/expert-brief.md — 每位专家的完整任务书(原样传给专家 subagent)。
  • references/verifiers.md — 事实核查员与红队的 prompt 及克制原则。
  • references/synthesis.md — 最终文章的文风与"织入校验"的写法。
Repository
digoal/blog
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.