메뉴
对任何领域的棘手问题进行深度思考分析,先识别问题所属领域并按需调度多位领域专家并行作答, 之后由事实核查员和红队做克制的事实审计与对抗性反驳,最后整合为面向小白的第一人称终稿。 适用:用户抛出一个跨领域/有深度的真实问题,希望听到多位专家的视角、看到观点的边界与证伪条件, 并得到一气呵成、通俗有据的最终文章。不适用:简单事实查询、纯情绪吐槽、不要求证据的随口一问。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
深度思考分析解答任何领域的棘手问题。当用户提出的问题具备以下任一特征时必须触发此 skill：(1) 涉及多个领域（如"AI 对就业的影响"涉及技术、经济、社会学、哲学）；(2) 涉及争议性观点或对立立场（如"比特币是不是泡沫"）；(3) 需要严谨论证、权威数据支撑、第一性原理推理（如"为什么中国新能源车销量这么猛"）；(4) 用户明确要求深度分析、多视角交叉验证、给出适用边界和证伪/证明手段。即便用户没有点名"深度分析"，只要问题本身具备跨学科、权衡性、需多专家视角的特征，都应触发本 skill，而不是给出浅尝辄止的单线回答。本 skill 不适用于闲聊、事实查询、明确要求简短回复的场景。
召唤多领域专家智能体，对任何棘手、跨学科、有争议或开放性的问题做并行深度分析，再经过一轮克制的事实核查与红队反驳，最后由一个"干净大脑"的终稿撰写者把所有内容无缝重写成一篇第一人称、面向小白、图文并茂、有人味、留有证伪空间的深度长文。触发条件：用户提出任何值得深挖的复杂问题，尤其是跨领域、需要多方视角、需要权威数据支撑的问题；提到"帮我深度分析"、"多专家视角"、"专家怎么看"、"这个问题涉及哪些领域"、"帮我搞清楚 XX 到底是怎么回事"、"用第一性原理分析一下"、"这个观点站得住脚吗"、"帮我论证一下"、"multi-expert-analyzer2"，或者只是抛出一个开放性问题如"为什么 XX 会发生"、"如何看待 XX 现象"、"XX 到底靠不靠谱"。即使用户没有明确说"专家"或"深度分析"这几个字，只要问题本身跨越多个专业领域、需要审慎论证而非泛泛而谈，也应使用本 skill。本 skill 与仓库中其他类似名称的技能（如 multi-expert-analyzer、multi-expert-analyzer1）相互独立，不共享模板或输出结构，请完全按照本文件的流程执行。
多领域专家联合分析 skill，深度思考分析解答任何领域的棘手问题。流程：主控 agent 识别问题所属领域，动态调度 1~N 个领域专家并行搜证、分析、产稿，再交由事实核查员与红队进行克制温和的二次审查，最终综合成第一人称、面向小白、文笔一气呵成的 markdown 文章。当用户提出跨界、复杂、有争议的硬问题，希望从多视角深度拆解；或明确要求"深度分析 / 多角度分析 / 专家会诊 / 多领域联合分析"时触发。
召唤多领域专家智能体，对任何棘手、跨学科、有争议或开放性的问题进行并行深度分析，再经过事实核查员与红队子智能体的克制审阅，最终重写为一篇面向小白、第一人称、图文并茂、有人味的深度长文。触发条件：用户提出任何值得深挖的复杂问题，尤其是跨领域、需要多方视角、需要权威数据支撑的问题；提到"帮我深度分析"、"多专家视角"、"专家怎么看"、"这个问题涉及哪些领域"、"帮我搞清楚 XX 到底是怎么回事"、"用第一性原理分析一下"、"这个观点站得住脚吗"、"帮我论证一下"，或者只是抛出一个开放性问题如"为什么 XX 会发生"、"如何看待 XX 现象"、"XX 到底靠不靠谱"。即使用户没有明确要求"专家"或"深度分析"这几个字，只要问题本身跨越多个专业领域、需要审慎论证而非泛泛而谈，也应使用本 skill。本 skill 与仓库中其他类似名称的技能相互独立，请完全按照本文件的流程执行，不要套用其他技能的模板或输出结构。
针对通用问题进行多领域专家联合分析, 综合稿产生前必经 fact-checker 与 red-team 两道独立校验。适用场景: 用户提出跨领域或不确定领域的复杂问题, 需要从多个专家角度分别搜证并相互校验后综合成文, 例如该不该买房、该不该跳槽、是否进入某个赛道等。触发关键词: 多角度分析、专家分析、综合分析、多视角、跨领域分析、从不同角度看、深度分析。问题只属于单一明确领域时, 优先使用该领域的专门 skill, 例如纯财务用 finance-core-analysis、纯技术用 software-architect。输出 (全部 markdown 保存到当前项目 markdown/ 目录): (1) 每位专家的中间分析稿; (2) 事实核查报告 (跨专家矛盾 / 未经证实的主张 / 重叠区); (3) 红队反驳报告 (逐条反驳承重墙级主张, 给出 SURVIVES / WEAKENS / REFUTED 裁定); (4) 第一人称、通俗易懂的最终综合长文, 同时报告哪些主张通过验证、多少被弱化、多少被剔除。
深度分析并解答任何领域的棘手问题。先判断问题涉及哪些领域，召集对应的领域专家分别搜证、按第一性原理作答（图文并茂、有权威数据和案例、讲清适用边界与证伪方式、自我验证），再经"事实核查"和"红队反驳"两道克制的校验，最后合成一篇面向小白、一气呵成、有人味的第一人称文章，全部产物存到当前项目 markdown/ 目录。触发条件：用户抛出一个想不通/难解/复杂/跨领域的问题并希望深入分析，例如"帮我分析一下……""这个问题到底怎么回事""从多个角度看……""深度思考一下……""这事儿靠谱吗""为什么会……未来会怎样"，或任何需要多领域专家协作、第一性原理推演、证据支撑与证伪路径的深度解答。即使用户没有明说"多专家"或"深度分析"，只要问题棘手、值得认真拆解，也应使用本 skill。
| name | multi-expert-analyzer |
| description | 对任何领域的棘手问题进行深度思考分析,先识别问题所属领域并按需调度多位领域专家并行作答, 之后由事实核查员和红队做克制的事实审计与对抗性反驳,最后整合为面向小白的第一人称终稿。 适用:用户抛出一个跨领域/有深度的真实问题,希望听到多位专家的视角、看到观点的边界与证伪条件, 并得到一气呵成、通俗有据的最终文章。不适用:简单事实查询、纯情绪吐槽、不要求证据的随口一问。 |
这个 skill 不是搜索引擎,不是答库,也不是简单的"让多个人聊聊"。它是一套深度分析流水线:
多专家并行作答 → 事实核查 + 红队对抗 → 第一人称整合终稿
解决一类具体问题:任何领域的棘手问题——单凭一个视角答不全、答不透、答不准的题。
适用:
不适用:
用户问题
↓
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 模板在拿到问题后、正式开干前,先做两件事:
markdown/ 目录(不存在就建)。ai-programmer-unemploymentpg-htap-feasibilityxiaohongshu-cold-startslug 是后续所有产物的文件名前缀,定下来不要中途换。
这一步是整个 skill 最关键的判断,做错了后面全跑偏。
先把问题放回它真正的领域范畴里:
在脑里过一遍,确认:
这一步不要落盘成文件——它只是给 Step 2 服务的内部规划。别让用户看到"我先做了个专家分配表"这种 AI 味输出。
多位专家必须真正并行——在同一个工具调用回合里同时启动。不要一个接一个跑。
每启动一位专家,先 Read 一次 agents/expert.md 拿到模板,按占位符替换后喂给 Agent 工具。
不要为了"看起来热闹"硬凑专家。判断标准:
每篇专家稿统一文件名格式:
markdown/<slug>-expert-<n>.md
例如 ai-programmer-unemployment-expert-1.md、ai-programmer-unemployment-expert-2.md。
如果专家用了 svg 图,svg 存到 markdown/svg/,在 markdown 中以  引用。
专家稿全部落盘后,再启动这两个子智能体。不要边写专家稿边跑核查——核查员需要看到全部专家稿才能比对矛盾。
Read agents/fact-checker.md 拿到 prompt 模板,把全部专家稿的全文(或文件路径列表)塞进去,启动子智能体。
产物:markdown/<slug>-fact-check.md
Read agents/red-team.md 拿到 prompt 模板,把全部专家稿的全文(或文件路径列表)塞进去,启动子智能体。
产物:markdown/<slug>-red-team.md
把这条刻在脑子里:
除非用户明确说要写严谨论文,否则大多数问题都不需要论文级严谨。 没找到硬伤就标"未发现硬伤",不要硬挑。
事实核查和红队一旦开始"为了找茬而找茬",整篇终稿就废了——它会被怀疑论淹没,失去"有立场、有判断"的人味。
在动笔前,先读懂所有产物:
读懂的标准:
然后把这些材料放到一边,重新写——不是把它们缝起来,也不是在它们的骨架上补肉。当成你读了 N 篇文章,自己形成了一个观点,然后写下来。
风格:
开头:
结构:
论证:
反思补充(来自事实核查员和红队):
终稿文件名:
markdown/<slug>-final.md
如果有 svg 图,存到 markdown/svg/,在 markdown 中以  引用。
落盘后、回复用户前,做一遍自查:
任何一条不通过,微调后再过一遍。直到全部通过。
一次完整任务通常产出:
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
回复用户时,列出所有产出文件的路径,并简明告诉用户每篇是干嘛的。