research

name	research
description	深度研究、核心判断提炼、实测能力验证

Stage 02: 研究

固定上下文（启动前必读）

• {profile_dir}/style-library.md — 参考句式和节奏
• {profile_dir}/experience-log.md — 历史踩坑 + 成功规律
• {project_dir}/00-brief.md — 选题

---

研究员 agent → {project_dir}/01-research/

启动 Researcher agent（启动子 agent）：

你是研究员。读取 {project_dir}/00-brief.md 了解选题。执行深度研究：

Step 0（必做）：读一手原始资料
- GitHub README、源码关键文件、官方文档全文
- 写入 {project_dir}/01-research/00-primary-sources.md

Step 0 验收门禁（不过不得进入 Step 1）：
- 00-primary-sources.md 必须包含至少 1 个实际抓取的 URL（用工具真实抓取，不得只列链接）
- 涉及某公司产品 → 该公司官方博客/文档 URL 必须在列表中
- 对话中用户提供的截图/体验描述只能写入 {project_dir}/01-research/04-personal-experience.md，严禁充当一手资料
- **README 功能覆盖检查**：对于工具类文章，README 中提到的所有主要功能（CLI 命令、Web UI、支持语言/平台、配置方式）必须在 00-primary-sources.md 中列出。漏掉的功能 = 写作时漏掉内容。

Step 0.5：读取 `{project_dir}/01-research/04-personal-experience.md`（已由主流程写入），了解用户体验情况，纳入研究素材。

Step 1-3（3轮搜索）：
- 基础轮：搜索工具名/功能名，确认基本事实
- 验证轮：搜索官方文档，核对数字/版本
- 深挖轮：搜索批评声音、社区讨论、边缘案例

Step 4：社区调研（工具类必做）
去真实社区看用户怎么说，找出官方文档没有的东西：
1. 搜 X/Twitter：搜 `site:x.com [工具名]`，看真实用户的讨论/吐槽
2. 搜 V2EX/即刻：`site:v2ex.com [工具名]`，中文用户的踩坑和用法
3. 搜 GitHub Issues/Discussions：真实 bug 报告和使用边界问题

每个平台提取 ≥3 条有价值内容，写入 `{project_dir}/01-research/05-community-insights.md`：
- 用户真实痛点（不是官方 feature 说明）
- 意外的使用方式（官方没有宣传的用法）
- 社区推荐的替代方案
- 真实用户描述这个工具的语言（避免文章只会说官方词汇）

必做：同题材爆款分析
- 找 Ceiling（最高阅读内容的标题和角度）
- 找 Floor（数据断崖在哪）
- 写入 {project_dir}/01-research/03-facts.md 的「爆款角度分析」章节

产出：{project_dir}/01-research/（00-primary-sources.md / 01-web-search.md / 02-deep-reads.md / 03-facts.md / 04-personal-experience.md / 05-community-insights.md）
完成后输出：「研究完成」

---

研究验收门禁

研究完成后，先验收再进入核心判断：

1. 打开 {project_dir}/01-research/00-primary-sources.md，确认有实际抓取的一手 URL
2. 涉及某公司产品 → 该公司官方博客/文档 URL 必须在列表中
3. 缺失一手源 → 退回研究员补充，不进入核心判断

技术类文章额外验收（两关都要过）：

关 A：权威背书 — 必须有产品作者/核心工程师的直接表态，或社区验证的真实使用案例。只有官方文档不够，人人能查，读者不需要你复述。找法：搜产品团队 X/Twitter、搜 GitHub Issues/Discussions、搜 Reddit 真实讨论。没找到 → 退回研究员继续挖。

关 B：深度 — 必须有至少 1 条超出官方文档的信息：底层机制、设计边界、真实踩坑（社区验证的，不是自己推断的）。只是翻译文档 = 没有深度 → 退回研究员。

验收通过后，读取 {project_dir}/01-research/03-facts.md 汇总关键素材。

---

核心判断（★用户确认节点）

基于研究素材提炼 3-5 个判断角度，每个角度一句话：

• ❌ 功能描述："工具 X 显示 context 用量"
• ✅ 有立场的判断："工具 X 解决的不是看不到数据的问题，是不敢让它跑完的问题"

攻核：对每个判断问"如果这是真的，那为什么……？"

• 扛住了 → 保留
• 碎了 → 剔除

等用户选定核心判断，写入 {project_dir}/00-brief.md。

---

实测能力验证（大纲含"实测"章节时必做）

如果计划的大纲包含"实测"、"亲测"、"实操演示"相关章节：

1. 问用户：「你有该功能的实际使用权限吗？能现在打开演示吗？」
2. 用户确认有 → 在 {project_dir}/00-brief.md 追加 实测状态: 已验证
3. 用户确认没有 → 两选一：
   • 大纲中"实测"章节改为"文档解读"或"官方演示拆解"
   • 等用户获取权限后再继续

硬规则：{project_dir}/00-brief.md 中无 实测状态: 已验证 标注 → 文章中禁止使用"实测/亲测/我试了/实测发现"。