菜单
深度研究与验证技能：当用户提出需要多源信息搜集、逻辑推理和事实验证的复杂问题时使用。 适用场景包括但不限于：投资研究、行业分析、技术对比、政策解读、商业决策支持等需要 "先想清楚怎么查，再去查，查完还要验证"的场景。 触发关键词/短语：为什么A而不是B、分析一下、帮我研究、设计一个SOP流程来回答、 深度分析、请验证、fact check、多角度分析、请先理解问题再回答、不要立即回答。 当用户明确要求"先设计研究流程再回答"或"验证你的结论"时，务必使用此技能。 当用户的问题涉及多个实体的比较（公司、技术、政策等）且答案不是简单事实时，也应触发。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the user asks to correct English prompts, broken English, typos, grammar, wording, tone, workplace English, business writing, presentation language, or asks for English practice, quizzes, or help expressing ideas clearly in English.
Use when 用户要求提取、提炼、总结某个日期或时间范围的群聊/聊天记录（EACC 投资群 / eacc-chat），生成群聊日报、核心话题分析或投资价值信息筛选。触发词：提取聊天记录、群聊提炼、群聊总结、某月某日群里聊了什么、chat digest、群聊日报、群聊干货。
评估或对比会议纪要/访谈整理/深度纪要的质量：对照原始转录核查保真度，盘点覆盖度，输出多维度打分与失真清单。适用时机：(1) 用户问"这两份纪要哪份质量更高/写得更好"，(2) AI 生成的纪要发布前验收（有没有幻觉、编造、立场写错），(3) 给纪要挑毛病/做质检/打分。触发语：评估纪要质量、对比纪要、纪要靠谱吗、纪要验收、纪要打分、哪份纪要好。
对会议纪要/活动回顾/访谈整理等将对外发布的文档做敏感信息检查与脱敏，覆盖查塔姆宫规则（Chatham House Rule）合规：人名机构名及变体、职级暗示、玩笑话与人事信号、点评同行、口语化敏感词、外链击穿匿名、身份指纹拼图、第三方未公开信息、编辑残留。适用时机：(1) 纪要将对外发布/进知识库/发群前，(2) 嘉宾或机构方要求脱敏审稿，(3) 用户提到查塔姆规则/讲事不讲人/匿名化/敏感信息检查。输出违规清单+修复建议，或直接执行脱敏。
Use when designing or reviewing lifecycle status fields, finite state machines, async task/order/payment/upload/approval workflows, or when states are overlapping, action-shaped, ownerless, unsafe under retries, concurrency, timeouts, or terminal-state updates.
对一段陈述/视频/文章/分析报告做真实性验收：拆解论点链 → 联网核查关键数据 → 找出反方证据 → 输出可点击的 8 维度红绿灯诊断与最终客观判断。当用户说"帮我看看这个说法靠不靠谱 / 验证真实性 / 反方观点是什么 / 这是不是泡沫 / 帮我做一个验收 / 这观点合理吗"时调用。
| name | deep-research-verifier |
| description | 深度研究与验证技能：当用户提出需要多源信息搜集、逻辑推理和事实验证的复杂问题时使用。 适用场景包括但不限于：投资研究、行业分析、技术对比、政策解读、商业决策支持等需要 "先想清楚怎么查，再去查，查完还要验证"的场景。 触发关键词/短语：为什么A而不是B、分析一下、帮我研究、设计一个SOP流程来回答、 深度分析、请验证、fact check、多角度分析、请先理解问题再回答、不要立即回答。 当用户明确要求"先设计研究流程再回答"或"验证你的结论"时，务必使用此技能。 当用户的问题涉及多个实体的比较（公司、技术、政策等）且答案不是简单事实时，也应触发。 |
一个结构化的"研究-回答-验证"框架，用于回答需要多源信息支撑的复杂问题。
大多数复杂问题的回答失败不是因为搜索不到信息，而是因为：
这个技能通过四个阶段来系统性地避免这些问题。
在做任何搜索之前，先停下来理解问题。
将用户的问题拆解为：
基于问题解构，列出需要搜集信息的维度。每个维度都应该回答一个子问题，子问题的组合能完整回答核心问题。
格式：
维度1: [子问题描述]
- 需要什么类型的信息（事实/数据/观点/对比）
- 可能的信息来源（公司公告/分析师报告/行业报告/新闻）
- 搜索关键词建议（2-3组）
维度2: ...
一般控制在 3-6 个维度。太少说明问题拆解不够，太多说明粒度过细需要合并。
将研究计划以清晰的步骤呈现给用户，说明：
如果用户说"不用展示SOP直接回答"，可以跳过展示，但内部仍应遵循这个思考过程。
按照Phase 1设计的维度，逐一执行搜索。注意：
搜集完成后，按问题结构组织信息，形成初步回答框架。此时的回答是"草稿"，还需经过Phase 3验证。
格式参考：
论点1: [陈述]
支撑证据:
- 证据A (来源: xxx, 类型: 一手/二手)
- 证据B (来源: xxx, 类型: 一手/二手)
证据强度: 强/中/弱
论点2: ...
这是与普通搜索回答最大的区别。对Phase 2的每个论点和关键证据进行系统性验证。
对每条关键事实性声明进行检查：
对于无法交叉验证的事实，明确标注"单一来源，未经交叉验证"。
对每个推理链条进行检查：
基于验证阶段发现的漏洞，进行针对性补充搜索：
为每个论点生成验证状态：
论点: [陈述]
验证状态: ✅ 已验证 / ⚠️ 部分验证 / ❌ 未通过验证 / ℹ️ 无法验证
验证详情:
- 事实层面: [验证结果]
- 逻辑层面: [验证结果]
- 如有修正: [原始 → 修正后]
基于验证后的信息，组织最终回答。结构建议：
这是透明度的关键。列出研究过程中：
采纳的证据：
| 论点 | 关键证据 | 来源 | 验证状态 | 采纳理由 |
|---|---|---|---|---|
| ... | ... | ... | ✅/⚠️ | ... |
放弃的证据/论点：
| 原始论点/证据 | 来源 | 放弃原因 |
|---|---|---|
| ... | ... | 与更可靠来源矛盾 / 逻辑不成立 / 时效过期 / ... |
未能验证的部分：
| 声明 | 原因 | 影响评估 |
|---|---|---|
| ... | 仅单一来源 / 缺乏数据 | 对结论影响大/小 |