product-and-technical-research

概述

在制定技术实现方案与实施计划前，通过系统化的研究方法确保方案的可行性、一致性与最优性。本技能整合需求澄清、设计文档评估、代码分析、联网搜索等多个维度，为技术决策提供充分的信息支撑。

通用适用：本技能技术无关、项目独立，适用于任何软件开发场景。

输入参数

使用模式

默认使用完整模式。若用户明确要求"快速调研"或时间紧迫，可切换至快速模式。

⚠️ 重要约束

本技能只做分析研究，不允许修改、删除任何文件

• 只允许读取文件、代码用于分析，读取文档用于评估
• 只允许输出研究报告和分析结论
• 禁止输出完整的生产级代码实现
• 禁止输出详细的实施排期计划
• 禁止创建、修改、删除任何文件
• 禁止执行任何具有副作用的命令（如 git checkout、数据库修改等）

可输出的内容：
- ✅ 架构图（ASCII/示意图）
- ✅ 伪代码/算法示意
- ✅ API 设计草案
- ✅ 技术选型建议
- ✅ 风险评估报告
- ✅ POC 方案建议

如需实施代码或配置变更，应在获得用户明确同意后，由其他技能或用户自行执行。

使用场景

应使用本技能的场景：

• 复杂需求：涉及多个模块、多种技术或复杂业务逻辑的需求
• 架构影响评估：可能影响现有系统设计、数据模型或核心流程
• 技术选型决策：需要评估多种技术方案的优劣、兼容性或性能差异
• 最佳实践借鉴：希望参考业界成熟方案、开源实现或竞品功能
• 风险识别：需要提前识别技术挑战、兼容性问题或潜在设计冲突

不使用本技能的场景：

• 简单的配置修改或格式化任务
• 需求明确且有现成可直接复用的方案
• 紧急修复线上问题且无时间进行调研

调研终止条件（Exit Criteria）

当满足以下条件时，可以结束调研进入汇总阶段：

1. 用户需求已澄清，所有关键歧义已消除
2. 至少识别出 2 个以上可对比的技术方案
3. 主要技术风险已识别并附有初步缓解方案
4. 设计缺口已明确列出（不要求全部补全）
5. 关键决策点已提炼完成，有明确的推荐方向
6. 无重大阻塞性问题未解决

不满足条件时：需增加调研轮次或扩大搜索范围。

核心工作流程

digraph research_workflow {
    rankdir=TB;
    node [shape=box, style=filled, fontname="sans-serif"];
    edge [fontname="sans-serif"];

    "接收用户需求" [fillcolor="#e1f5fe"];
    "需求澄清与确认（主流程交互）" [fillcolor="#ffecb3", style="filled,bold"];
    "用户确认需求" [fillcolor="#c8e6c9"];
    "并行调研（子代理）" [fillcolor="#fff3e0"];
    "设计评估" [fillcolor="#e1bee7"];
    "代码分析" [fillcolor="#c8e6c9"];
    "联网搜索调研" [fillcolor="#ffe0b2"];
    "汇总研究报告" [fillcolor="#b2dfdb"];

    "接收用户需求" -> "需求澄清与确认（主流程交互）";
    "需求澄清与确认（主流程交互）" -> "用户确认需求" [label="待澄清问题逐条讨论"];
    "用户确认需求" -> "需求澄清与确认（主流程交互）" [label="用户反馈"];
    "用户确认需求" -> "并行调研（子代理）" [label="需求已明确，启动子代理"];
    "并行调研（子代理）" -> "设计评估";
    "并行调研（子代理）" -> "代码分析";
    "并行调研（子代理）" -> "联网搜索调研";
    "设计评估" -> "汇总研究报告";
    "代码分析" -> "汇总研究报告";
    "联网搜索调研" -> "汇总研究报告";
}

研究步骤

第一步：接收与理解需求

关键动作：

• 从 userRequirement 入参中获取用户原始需求
• 记录需求内容：功能描述、业务目标、技术约束
• 评估优先级和紧迫程度
• 初步标记可能存在的歧义点和信息缺口

产出物：需求摘要，包含关键要点和初步疑问清单

第二步：需求澄清与确认（主流程交互）

> 执行方式：直接在对话中与用户进行多轮讨论，不使用子代理。

2A. 第一轮：需求本质探索

讨论要点：

• 需求的根本动机是什么？要解决什么业务问题？
• 当前是否存在类似功能？为什么不能用现有方案解决？
• 预期的使用场景和用户角色是什么？
• 成功的标准是什么？如何衡量"做好了"？

识别隐含内容：

• 用户未明说的假设（如"应该支持高并发"但没有具体数值）
• 用户可能忽略的边缘场景
• 业务优先级和紧急程度的判断

产出：
- 核心问题定义（一句话描述本质上要解决什么问题）
- 隐含假设清单

2B. 第二轮：边界与范围界定

讨论要点：

产出：
- 功能边界清单（明确包含/不包含）
- 依赖关系图（系统间依赖）
- 影响范围初步评估

2C. 第三轮：关键决策问题确认

必须逐条确认的决策事项：

**性能目标**（需明确数值）：
- [ ] QPS/TPS 目标：_______
- [ ] 响应时间要求（P95/P99）：_______
- [ ] 数据量预估（存量/增量）：_______

**兼容性要求**：
- [ ] 需要支持的版本范围（JDK/数据库/浏览器等）：_______
- [ ] 是否需要向前兼容？兼容到哪个版本？

**技术约束**：
- [ ] 必须使用的技术栈：_______
- [ ] 禁止使用的技术/方案：_______
- [ ] 部署环境限制（内网/云/信创等）：_______

**成本与资源**：
- [ ] 是否有预算限制（云资源/第三方服务）？
- [ ] 团队当前对某技术的熟悉程度：_______

**时间约束**：
- [ ] 期望的上线时间：_______
- [ ] 是否有中间里程碑要求？_______

产出：完整的关键决策确认清单（用户已逐项回答）

2D. 需求确认汇总

执行动作：

• 将三轮讨论的产出汇总为最终确认的需求文档
• 向用户复述确认，确保理解无误
• 获得用户的明确确认（"确认无误，可以继续"）

产出：最终确认的需求文档（后续所有调研以此为准）

⚠️ 重要：未获得用户明确确认前，不得进入第三步。

第三步：并行调研（子代理）

启动条件：用户已确认需求理解无误，待澄清问题已全部回答。

执行方式：使用子代理并行执行以下三项调研。

3A. 设计评估（子代理）

评估范围：

• 现有架构设计文档（如有）
• 系统架构模式与约束条件
• 数据模型设计
• API 设计规范
• 安全与合规设计

评估检查清单：

- [ ] 现有架构能否支撑新需求？
- [ ] 数据模型需要哪些变更（新增表/修改字段/迁移数据）？
- [ ] API 是否需要新增或修改？是否存在版本兼容问题？
- [ ] 当前设计模式是否适配新场景？
- [ ] 有无违反现有架构约束？
- [ ] 是否需要引入新的中间件/服务？
- [ ] 对现有系统的性能影响评估
- [ ] 部署架构是否需要调整？

产出：
- 评估的文档清单（路径 + 版本）
- 架构约束检查结果
- 数据模型兼容性评估
- 设计缺口列表（明确需要新增设计的部分）

3B. 代码分析（子代理）

代码分析清单：

**结构分析**：
- [ ] 识别与需求相关的已有模块/包/类
- [ ] 分析涉及层的完整调用链（Controller → Service → Repository）
- [ ] 识别需要修改的现有类和方法

**复用性评估**：
- [ ] 是否有可复用的工具类、常量、枚举？
- [ ] 现有扩展点是否能满足需求？
- [ ] 是否有可借鉴的类似实现？

**影响分析**：
- [ ] 数据库 Schema 变更影响评估
- [ ] 现有配置是否需要新增或修改？
- [ ] 依赖图谱分析：引入新依赖的兼容性成本
- [ ] 识别可能受影响的其他模块（通过调用关系追踪）

**技术债务识别**：
- [ ] 涉及代码的复杂度/可维护性评分
- [ ] 是否存在需要先重构再开发的遗留代码？
- [ ] 测试覆盖情况评估

产出：
- 受影响代码清单（模块/类/方法级别）
- 复用机会清单
- 技术债务清单
- 代码层面的风险点

3C. 联网搜索调研（子代理）

输入：第二步产出的确认需求 + 第三步 3A/3B 的初步发现

搜索执行规范：

1. 关键词设计：

2. 搜索优先级：

3. 信息可信度评估：

• ✅ 检查发布日期（建议 1 年内）
• ✅ 检查讨论活跃度
• ✅ 验证是否有生产案例
• ✅ 检查 GitHub Issue 关闭率
• ✅ 查看项目 Star 数和贡献者数量

产出：
- 技术选型对比表（性能/成熟度/社区/成本）
- 开源方案评估（Star 数/最后更新时间/适配度/生产案例）
- 业界最佳实践总结
- 避坑指南（已知问题和解决方案）
- 推荐方案及适用场景说明

第四步：汇总研究报告

输入：第二步（需求确认）+ 第三步（设计评估、代码分析、联网搜索）的完整输出

汇总方法：

• 交叉验证各维度发现的一致性与冲突点
• 识别跨领域的关联风险和依赖关系
• 综合评估推荐方案的可行性和优先级
• 提炼需要决策的关键问题

研究报告结构

1. 需求概述与目标

• 需求背景与动机
• 核心目标描述
• 关键约束条件
• 功能边界（做什么 vs 不做什么）
• 确认过的关键决策点汇总

2. 需求澄清记录

• 三轮讨论的关键发现
• 用户确认的重要假设和决策
• 讨论过程中发现并确认的重要细节

3. 设计评估结论

• 现有架构对新需求的支撑度
• 数据模型兼容性评估结果
• API 扩展性分析
• 设计缺口清单
• 需要新增的设计任务

4. 代码分析结论

• 受影响模块/类/方法清单
• 可复用模块识别
• 技术债务识别
• 代码层面风险评估

5. 技术方案评分矩阵

6. 推荐技术方案

• 主推方案：方案名称 + 核心理由（2-3 条）
• 备选方案：方案名称 + 适用场景说明
• 弃用方案：方案名称 + 弃用原因
• 选型决策建议：在什么条件下选择哪个方案

附录：调研过程记录

• 调研起止时间
• 查阅的文档清单
• 分析的代码范围
• 搜索关键词及主要参考链接

技能集成

执行所需的技能：
- superpowers:brainstorming - 用于需求分析和方案探索（由主流程执行，非子代理）
- 联网搜索能力（MCP）- 用于收集业界信息（由子代理执行）

与其他技能的关系