القائمة
深度调研方法论（8步法）：将模糊主题转化为高质量调研报告。 触发词：/deep-research、深度调研、帮我调研、调研一下、对比分析 注意：如果用户需要的是可视化图谱而非报告，请使用 research-to-diagram skill。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/nexu-io/nexu --skill deep-researchيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Use the ClawHub CLI to search, install, update, and publish agent skills from clawhub.com. Use when you need to fetch new skills on the fly, sync installed skills to latest or a specific version, or publish new/updated skill folders with the npm-installed clawhub CLI.
Delegate coding tasks to Codex, Claude Code, or Pi agents via background process. Use when: (1) building/creating new features or apps, (2) reviewing PRs (spawn in temp dir), (3) refactoring large codebases, (4) iterative coding that needs file exploration. NOT for: simple one-liner fixes (just edit), reading code (use read tool), thread-bound ACP harness requests in chat (for example spawn/run Codex or Claude Code in a Discord thread; use sessions_spawn with runtime:"acp"), or any work in ~/clawd workspace (never spawn agents here). Claude Code: use --print --permission-mode bypassPermissions (no PTY). Codex/Pi/OpenCode: pty:true required.
Fetch GitHub issues, spawn sub-agents to implement fixes and open PRs, then monitor and address PR review comments. Usage: /gh-issues [owner/repo] [--label bug] [--limit 5] [--milestone v1.0] [--assignee @me] [--fork user/repo] [--watch] [--interval 5] [--reviews-only] [--cron] [--dry-run] [--model glm-5] [--notify-channel -1002381931352]
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | deep-research |
| catalog-name | Deep Research |
| description | 深度调研方法论（8步法）：将模糊主题转化为高质量调研报告。 触发词：/deep-research、深度调研、帮我调研、调研一下、对比分析 注意：如果用户需要的是可视化图谱而非报告，请使用 research-to-diagram skill。 |
将用户提出的模糊主题，通过系统化方法转化为高质量、可交付的调研报告。
| 文档 | 内容 |
|---|---|
templates/intermediate-outputs.md | 中间产物格式模板 |
templates/comparison-framework.md | 对比框架模板 |
templates/fact-card.md | 事实卡片模板 |
templates/report-structure.md | 报告结构模板 |
~/Downloads/research/<topic>/
├── 00_问题拆解.md # Step 0-1 产出
├── 01_资料来源.md # Step 2 产出
├── 02_事实卡片.md # Step 3 产出
├── 03_对比框架.md # Step 4 产出
├── 04_推导过程.md # Step 6 产出
├── 05.5_校验记录.md # Step 6.5 产出（独立 Agent 校验）
├── 05_验证记录.md # Step 7 产出
├── FINAL_调研报告.md # Step 8 产出
└── raw/ # 原始资料存档
中间产物格式详见 templates/intermediate-outputs.md
| 层级 | 资料类型 | 可信度 |
|---|---|---|
| L1 | 官方文档、论文、规范、RFC | ✅ 高 |
| L2 | 官方博客、技术演讲、白皮书 | ✅ 高 |
| L3 | 权威媒体、专家解读、教程 | ⚠️ 中 |
| L4 | 社区讨论、个人博客、论坛 | ❓ 低 |
L4 社区来源（产品对比调研必查）：GitHub Issues/Discussions、Reddit、Hacker News
每步完成后，立即写入对应文件。
| 问题类型 | 核心任务 | 侧重维度 |
|---|---|---|
| 概念对比型 | 建立对比框架 | 机制差异、适用边界 |
| 决策支持型 | 权衡取舍 | 成本、风险、收益 |
| 趋势分析型 | 梳理演进脉络 | 历史、驱动因素、预测 |
| 问题诊断型 | 根因分析 | 症状、原因、证据链 |
| 知识梳理型 | 系统整理 | 定义、分类、关系 |
| 敏感级别 | 典型领域 | 资料时间窗口 |
|---|---|---|
| 🔴 极高 | AI/大模型、区块链 | 3-6 个月 |
| 🟠 高 | 云服务、前端框架 | 6-12 个月 |
| 🟡 中 | 编程语言、数据库 | 1-2 年 |
| 🟢 低 | 算法原理、设计模式 | 无限制 |
🔴 极高敏感领域强制规则：
time_range: "month"）把模糊主题拆成 2-4 个可调研的子问题，并明确研究对象边界（人群/地域/时间/层级）。
→ 保存：00_问题拆解.md
搜索策略（高敏感领域）：
适用对象核查（BLOCKING）：收录资料前必须验证适用对象与研究边界匹配。
→ 保存：01_资料来源.md（持续更新）
把资料转化为可核验事实卡片，区分「官方说的」和「我推测的」。
→ 保存：02_事实卡片.md（持续更新）
根据问题类型选择固定维度：
→ 保存：03_对比框架.md
确保对比各方定义稳定、公认、无歧义。
显式写出「事实 → 对照 → 结论」的推导过程，每个结论都能追溯到具体事实。
⚠️ 推导防护：结论不得悄悄升级事实卡片中的确定性层级。
→ 保存：04_推导过程.md
时机：事实卡片 + 推导过程完成后，写最终报告前。
原则：遵循 CLAUDE.md「计划校验」规范 — 产出者 ≠ 审查者。
执行方式：启动独立 Agent（Task 工具），将 02_事实卡片.md 和 04_推导过程.md 交给 Agent，校验以下维度：
→ 保存：05.5_校验记录.md
铁律：
用一个典型场景验证结论是否成立，检查有无反例。
→ 保存：05_验证记录.md
交付三件套：
→ 保存：FINAL_调研报告.md
→ 打包：tar -czvf ~/outcome.tar.gz -C ~/Downloads/research <topic>
# [调研主题] 调研报告
## 摘要
[一句话核心结论]
## 1. 概念对齐
## 2. 工作机制
## 3. 联系
## 4. 区别
## 5. 用例演示
## 6. 总结与建议
## 参考资料
详见 templates/report-structure.md
核心问题：调研最容易出的问题不是「查得不够多」，而是「查得太散」。
检查流程：
回顾核心问题：Step 1 拆解的子问题是什么？用一句话写下来。
资料相关性审计：对 01_资料来源.md 中的每条资料，用以下结构化标准判断：
事实卡片瘦身：对 02_事实卡片.md 中的每张卡片问：
报告聚焦检验：最终报告中的每个章节都要能追溯到 Step 1 的子问题
典型症状：
| 症状 | 表现 | 问题 |
|---|---|---|
| 边界蔓延 | 调研 A，顺便查了 B、C、D | 报告臃肿，重点模糊 |
| 资料囤积 | 收集 50 条资料，只用了 10 条 | 浪费时间，增加噪音 |
| 概念发散 | 解释一个概念时引入 3 个新概念 | 读者认知过载 |
| 炫技式延伸 | 「其实还有更深层的机制……」 | 偏离用户实际需求 |
铁律：调研的目标是回答问题，不是展示知识面。
核心问题：调研涉及封禁、限制、政策执行等「行动」时，最容易犯的错误是把理论风险等同于实际后果。
错误模式：
三层区分（事实卡片和报告中必须明确标注）：
| 层级 | 含义 | 标注格式 | 示例 |
|---|---|---|---|
| 已确认 | 一手用户报告证实发生了 | [已确认] | "Gemini 服务被禁用" |
| 官方理由 | 执行方的解释/动机 | [官方理由] | "OAuth token 可能被滥用于访问更广的 Google 服务" |
| 理论风险 | 技术上可能但未被用户报告证实 | [理论风险] | "Gmail、Drive 等服务可能受牵连" |
检查清单：
铁律：「X 在技术上可能发生」≠「X 已经发生」。报告中描述执行后果时，只能使用「已确认」层级的事实。「理论风险」可以作为分析维度呈现，但必须明确标注，不得混入事实性陈述。
典型事故：调研报告说「整个 Google 账户生态可能受影响」（基于 OAuth 理论范围），文章据此写「Gmail、Drive、Cloud 都受牵连——你的数字生活被掐断」。实际上用户报告只有 Gemini/Antigravity 被禁用，Gmail/Drive 完全不受影响。读者亲历者指出错误，作者声誉受损。
[来源受限]，不作为唯一支撑✅ 应该包含：
~/outcome.tar.gz）❌ 禁止包含：
| 版本 | 变更 |
|---|---|
| v2.1.0 | 新增 Step 6.5：独立 Agent 校验（BLOCKING），写报告前必须校验事实和推导 |
| v2.0.0 | 重构：模板外移到 templates/，SKILL.md 精简 |
| v1.6 | 社区声音挖掘机制 |
| v1.5 | 官方下载页面验证、协议名称搜索 |
| v1.4 | 时效敏感性判断机制 |
| v1.3 | 来源周全性要求 |
| v1.2 | 适用对象核查机制 |
| v1.1 | 中间产物管理 |
| v1.0 | 初始版本 |