stage-research
Skill2 starsChanged 5 months agoMITView on GitHub
调研与竞争分析——调查、竞品分析、可行性评估。阶段子工作流，可独立使用。
In this repository26 other files it gives its agents.
- AGENTS.mdAGENTS.md
- code-reviewSkill
- design-reviewSkill
- main-workflowSkill
- okrSkill
- pr-faqSkill
- release-checklistSkill
- release-reviewSkill
- requirement-clarificationSkill
- requirement-reviewSkill
- retro-meetingSkill
- retro-reviewSkill
- six-pagerSkill
- software-project-governanceSkill
- stage-architectureSkill
- stage-cicdSkill
- stage-developmentSkill
- stage-infraSkill
- stage-initiationSkill
- stage-maintenanceSkill
- stage-operationsSkill
- stage-releaseSkill
- stage-selectionSkill
- stage-testingSkill
- tech-reviewSkill
- test-reviewSkill
The file
Files
调研与竞争分析 — 子工作流
本文件定义"调研与竞争分析"阶段的独立子工作流。用户可单独加载本文件执行调研阶段。
阶段目标
通过调研和竞争分析建立决策事实基础。调研阶段的核心产出是"调研报告"——用事实和数据回答"外面有什么、别人怎么做的、我们该注意什么"。
AI 编程场景特有风险
在 AI 辅助编程项目中，调研阶段存在以下特有风险：
| 风险 | 说明 | 缓解方向 |
| 搜索结果幻觉 | AI 可能生成看似合理但不存在的研究发现、编造引用来源或虚构数据 | 每条关键发现必须标注可验证的数据来源（URL/文档名/行号）；不可标注"据调研"等模糊来源 |
| 调研广度不足 | AI 倾向于收敛到前几个搜索结果，遗漏小众但关键的信息源和长尾方案 | 强制多轮搜索：至少 3 个不同关键词/角度；至少 1 个非英语信息源 |
| 确认偏差 | AI 可能偏好引用支持项目假设的信息而忽略反面证据，形成"调研验证了我们已经相信的"假象 | 强制列出"与项目假设矛盾的发现"（≥1 条）；如果没有，说明为什么不矛盾 |
| 一手信息缺失 | AI 依赖二次整理（博客、聚合文章）而非原始文档（官方文档、RFC、白皮书） | 每条技术发现优先引用原始文档；二次来源需标注"非一手" |
| 竞争分析表面化 | AI 生成的竞品对比停留在官网宣传层面，缺少实际使用体验和社区生态深度 | 竞品分析必须包含社区活跃度（Star/Issue/PR 频率）和实际使用反馈（Hacker News/Reddit/GitHub Issues） |
独立使用时的目标锚定
当本子工作流被独立加载（非通过
main-workflow.md总入口加载）时，MUST 在执行阶段活动前完成：
- 目标确认：读取
.governance/plan-tracker.md，确认项目立项时定义的量化成功标准 - 偏离检查：对照成功标准，确认调研方向与项目总目标一致。如发现偏离，MUST 先记录到
.governance/decision-log.md再继续 - 质量底线：调研结论必须包含数据支撑，不接受纯定性结论（参考 profile 质量要求）
进入条件
- 立项阶段已完成（G1 通过）
- 已明确需要调研的问题域
活动清单
1. 调研问题定义
| 活动 | 描述 | 交互边界 | 企业实践 |
| 列出需要回答的问题 | 基于立项阶段的目标，明确调研要回答哪些问题 | 需用户输入：需要调研什么 | [Amazon Working Backwards] 从用户价值出发定义调研问题——"用户需要知道什么"而非"我们想研究什么" |
| 确定调研范围 | 技术维度、市场维度、用户维度 | 需用户确认 | [Google Design Doc] 调研范围显式声明——覆盖什么、不覆盖什么 |
| 优先级排序 | 哪些问题必须先回答才能进入下一阶段 | 需用户确认 | [Amazon Bias for Action] 可逆决策的调研快速推进，不可逆决策深度调研 |
2. 技术/市场/用户三维调研
| 活动 | 描述 | 交互边界 | 企业实践 |
| 技术调研 | 当前技术方案的成熟度、趋势和风险；优先引用原始文档 | 自动执行（多轮搜索，≥3 个角度）→ 需用户验证：关键结论的准确性 | [Google] 技术调研必须引用原始文档和可复现数据 |
| 市场/竞品调研 | 竞争格局、替代方案、差异化空间；包含社区活跃度指标 | 自动执行（搜索结果需人工验证） | [Amazon] 竞品分析包含：产品能力 + 社区生态 + 真实用户反馈 |
| 用户/需求调研 | 目标用户的痛点、期望和使用场景 | 需用户输入：用户画像和场景 | [Amazon Customer Obsession] 从用户痛点出发而非从技术可能性出发 |
| 反面证据收集 | 主动搜索与项目假设矛盾的发现和失败案例 | 自动执行 | [华为蓝军] 对立面思考——主动找"不支持我们假设"的证据 |
3. 竞争分析矩阵
| 活动 | 描述 | 交互边界 | 企业实践 |
| 列举竞品/替代方案 | 至少列举 3 个竞品或替代方案，含开源和商业 | 自动执行 → 需用户补充：已知但未被搜索到的竞品 | [Amazon] 不只列直接竞品，也要列替代方案（解决问题的不同方式） |
| 建立对比维度 | 功能、性能、成本、体验、生态、社区活跃度、维护响应速度 | 需用户确认对比维度 | [Google] 比较维度必须与项目成功标准对齐 |
| 填充对比矩阵 | 逐个竞品按维度评估，标注评估置信度（实测/文档/推测） | 自动执行：基于搜索结果填充 | [ByteDance 数据驱动] 对比必须有数据进行量化，不接受"A 比 B 好" |
| 差异化分析 | 我们的机会在哪里——竞品没做好的、没覆盖的、做得太复杂的 | 自动执行 → 需用户确认 | [Amazon] 找到"竞品不做但用户需要"的空间 |
4. 关键发现总结
| 活动 | 描述 | 交互边界 | 企业实践 |
| 提炼关键发现 | 从调研数据中提炼 3~7 条关键发现 | 自动执行 | [Amazon 6-Pager] 不只是罗列数据，要有叙事——这些发现告诉我们什么 |
| 标注数据支撑 | 每条发现标注数据来源（URL/文档名+行号/数据集名） | 自动执行 | [ByteDance] 不接受无来源的结论 |
| 识别可行约束 | 列出技术可行性、市场窗口、资源约束 | 自动执行 → 需用户确认 | [华为 IPD] 约束条件必须显式列出并评估影响 |
5. 可行性评估
| 活动 | 描述 | 交互边界 | 企业实践 |
| 评估技术可行性 | 当前技术栈能否支撑目标；关键不确定性列出 | 自动执行（结论需人工验证） | [Google] 技术可行性必须有 PoC 或数据支撑 |
| 评估市场可行性 | 市场窗口是否合适；是否有明确的需求信号 | 需用户判断 | [Amazon] 市场可行性基于用户需求信号而非主观判断 |
| 评估资源可行性 | 团队能力和资源是否匹配；差距在哪里 | 需用户判断 | [华为] 资源评估必须包含"我们还缺什么" |
产出物标准
| 产出物 | 格式要求 | 质量标准 | 企业实践来源 |
| 调研报告 | 覆盖技术、市场、用户三个维度 | 每个维度 ≥3 条有数据支撑的发现；≥1 条反面证据 | [Amazon 6-Pager] + [华为蓝军] |
| 竞争分析矩阵 | 至少 3 个竞品 × 至少 4 个对比维度 | 矩阵完整无空白；有评估置信度标注 | [Google] |
| 可行性评估 | 技术/市场/资源各有明确结论 | 结论有数据支撑，不是猜测；关键不确定性已标注 | [华为 IPD] |
| 关键发现总结 | 3~7 条发现，每条有可验证数据来源 | 发现之间不重复、不矛盾；有叙事逻辑 | [Amazon] + [ByteDance] |
退出条件
- 调研覆盖了技术、市场和用户三个维度
- 竞争格局已清晰（至少 3 个竞品的对比矩阵，含评估置信度）
- 关键发现有可验证数据支撑（每条发现标注来源，不接受"据调研"）
- 反面证据已收集（≥1 条与假设矛盾的发现，或明确声明"未发现矛盾"）
- 可行性有初步判断（技术/市场/资源各有结论，关键不确定性已标注）
Gate 映射
本阶段对应 G2 — 调研完成。
| Gate 检查项 | 对应活动 | 判定标准 | 自动化判定 |
| 调研是否覆盖了技术、市场和用户三个维度？ | 三维调研 | 三个维度各有至少 3 条发现 | 可自动：检查各维度发现计数 |
| 竞争格局是否清晰？ | 竞争分析矩阵 | 矩阵至少 3×4，无空白项，有评估置信度 | 可自动：检查矩阵维度+空白检测+置信度字段 |
| 关键发现是否有数据支撑？ | 关键发现总结 | 每条发现标注了可验证的数据来源 | 可自动：正则检查来源字段非空+格式（URL/文档路径） |
| 是否涵盖了反面证据？ | 三维调研 | ≥1 条矛盾发现或明确声明 | 可自动：关键词匹配"矛盾/反面/不支持/失败" |
| 是否识别了技术可行性的关键约束？ | 可行性评估 | ≥1 条技术约束，有明确影响描述 | 可自动：检查约束列表非空+影响字段完整性 |
企业实践溯源
本子工作流的设计参考了以下企业实践，每条实践已映射到具体活动步骤：
| 企业 | 核心实践 | 映射到本工作流 |
| Amazon | Working Backwards (从用户价值出发) | 调研问题定义→从"用户需要知道什么"出发 |
| Amazon | 6-Pager 结构化叙述 | 关键发现总结→不只是罗列数据，要有叙事逻辑 |
| Amazon | Customer Obsession | 用户/需求调研→从用户痛点出发 |
| Design Doc（调研范围显式声明） | 调研问题定义→覆盖什么、不覆盖什么 | |
| 一手文档优先 | 技术调研→优先引用原始文档 | |
| 华为 | 蓝军机制（对立面思考） | 三维调研→反面证据收集 |
| 华为 | IPD 门控（约束显式化） | 可行性评估→约束条件必须显式列出 |
| 字节跳动 | 数据驱动——无数字不接受 | 竞争分析→对比必须有量化数据；关键发现→每条标注来源 |
| — | AI 编程专项 | 调研→多轮搜索；发现→来源可验证；反确认偏差→反面证据强制 |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.