深度分析并解答任何领域的棘手问题。先判断问题涉及哪些领域,召集对应的领域专家分别搜证、按第一性原理作答(图文并茂、有权威数据和案例、讲清适用边界与证伪方式、自我验证),再经"事实核查"和"红队反驳"两道克制的校验,最后合成一篇面向小白、一气呵成、有人味的第一人称文章,全部产物存到当前项目 markdown/ 目录。触发条件:用户抛出一个想不通/难解/复杂/跨领域的问题并希望深入分析,例如"帮我分析一下……""这个问题到底怎么回事""从多个角度看……""深度思考一下……""这事儿靠谱吗""为什么会……未来会怎样",或任何需要多领域专家协作、第一性原理推演、证据支撑与证伪路径的深度解答。即使用户没有明说"多专家"或"深度分析",只要问题棘手、值得认真拆解,也应使用本 skill。
72
91%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
很多棘手问题之所以棘手,是因为它横跨多个领域,单一视角必然有盲区。一个人再聪明,也很难同时是经济学家、工程师和心理学家。所以这里的思路是:先把问题拆到它真正所属的几个领域,让每个领域的专家独立作答,再由一个中立的合成者把这些视角织成一篇普通人读得懂的文章。
但多专家有个老毛病——每个专家都很自信,可他们之间可能互相矛盾,或者某个"权威数据"其实站不住脚。所以在合成之前,加了两道校验:一个事实核查员盯着专家们有没有自相矛盾或空口无凭,一个红队专挑最关键的结论去反驳。校验完才动笔。
有一点要特别克制:这两道校验不是来找茬的。 大多数问题并不需要写成严谨论文,过度的质疑只会让最终文章变得畏首畏尾、充满"但也可能……"。校验的价值不在于否定专家,而在于给最终文章埋下一些让读者会心一动、多想一层的点。所以校验结论不直接改写文章的主干,而是在文章成型后,把其中真正有价值的部分,以旁观者的口吻自然地嵌进去。
markdown/ 目录下。复述与领域诊断。 用一两句话复述问题,判断它涉及哪些领域。据此决定召集几位专家——要右尺寸:单一领域的问题 1 位专家足矣,跨领域问题一般 2–4 位。不要为了显得全面而硬凑专家;专家太多反而稀释重点。
建运行目录。 在当前项目下建 markdown/multi-expert/<主题slug>-<YYYYMMDD>/,内含子目录 experts/、assets/、review/。主题 slug 用简短的中文拼音或英文词。
召集专家(并行)。 对每个领域,先看当前环境有没有现成、贴切的专家 agent(比如"后端架构师""心理学家""投资研究员""土木工程师"等):
general-purpose(或类似通用)subagent 做角色扮演,在 prompt 里明确"你现在是某某领域的资深专家"。每位专家的任务书见 references/expert-brief.md——把它的要求完整传给每个专家 subagent,并告诉它自己的输出路径 experts/NN-<角色>.md。在同一条消息里并行发起所有专家,让他们同时开工。
收齐草稿。 等所有专家写完各自的 experts/NN-*.md(以及引用到的 assets/*.svg)。
事实核查(克制)。 起一个"事实核查员"subagent,读完所有专家草稿,标记实质性的矛盾和明显空口无凭的关键主张。做法与克制原则见 references/verifiers.md。存到 review/fact-check.md。
红队反驳(克制)。 再起一个"红队"subagent,只针对最承重的那几个结论尝试反驳。同样见 references/verifiers.md。存到 review/red-team.md。
第 5、6 步可以在同一条消息里并行发起——它们都只读专家草稿,互不依赖。
先写文章,再织入校验。 两个校验器都完成后,才动笔写最终文章。先把它写成一篇干净、连贯、面向小白的第一人称文章;然后回头看两份校验报告,挑出其中真正有启发、能让读者多想一层的点,以旁观者视角丝滑地嵌进去。写法与文风要求见 references/synthesis.md。存到 final.md。
交付。 告诉用户最终文章路径,以及中间产物(专家草稿、两份校验)的位置,方便他追溯。
.svg 文件再在 md 里引用,不要把 SVG 源码内联进 md。references/expert-brief.md — 每位专家的完整任务书(原样传给专家 subagent)。references/verifiers.md — 事实核查员与红队的 prompt 及克制原则。references/synthesis.md — 最终文章的文风与"织入校验"的写法。digoal/blog
7abecbf
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.