analyze-research

name	analyze-research
description	技术调研子类型规范 — 技术选型/可行性评估/根因调查，只读工作流

Analyze Research Skill

子类型标识：analyze.research

触发条件

用户要求调研、评估或比较某技术方案，主要目标是获得信息和建议（而非直接实施）。

场景	示例
技术选型	"对比 Redis/Memcached，推荐缓存方案"
可行性评估	"评估引入 GraphQL 的成本和收益"
概念验证	"验证 WebSocket 在我们架构下是否可行"
依赖调研	"调研 @org/lib 是否满足需求"
根因调查	"找出导致内存持续增长的根因"
隐性推荐/取舍	用户问"是否应该""哪个更好""有没有更好建议"，且结论会影响技术路线、产品/项目选择、时间/金钱投入或长期维护成本

⛔ 只读原则

调研过程中禁止修改任何项目源码文件。若结论需要代码变更，在报告中说明并建议切换到 dev/fix 工作流。

执行流程

步骤	动作
1	明确调研问题（一句话核心问题）
2	确认调研范围（深度 + 技术栈约束）
3	收集信息（profile + 源码 + 同类产品 / 项目 / 模块对比 + 依赖文档）并建立关联文件集合
4	分析评估（按调研类型，至少 3 轮）
5	收敛前再跑一次 CRS，确认关联文件集合无遗漏
6	PCV（收敛后汇总验证，含合理性 + 可实施性 + 收益）
7	输出明确结论（禁止模糊结论）
8	输出调研报告

统一联查矩阵（research 最小动作）

• research 默认执行 analyze-lite 联查：关键词提取 → 关联文件集合 → 收敛前再跑一次 CRS
• 命中控制面、多真相源、模板-示例-校验链或单轮发现 ≥5 条 / 出现 🔴 问题时，应主动建议升级到 audit
• ComparativeResearchGate 命中时，先比较同类产品 / 项目 / 本仓库相似模块 / 已有设计；若属于纯解释、低风险本地事实或用户明确要求快速答复，记录 N/A + skipReason，不得把普通问答默认升级成重调研
• 输入来自审查报告、AI review finding、audit issue 或代码评审发现时，必须执行 ReviewFindingIntakeGate：先把报告当线索补本地证据，再区分 must-fix、设计如此、用户决策、文档/实现漂移、测试覆盖缺口和未复现项

各类型输出格式

技术选型：

推荐：[方案名]
理由：[2~3句话，聚焦关键差异]
注意事项：[风险/限制]

可行性评估：

结论：[可行 / 有条件可行 / 不可行]
前置条件：[无则填"无"]
成本估算：[工程量/依赖变更/测试]
风险点：[主要风险]
备选方案：[若不可行]

依赖/兼容性评估：

业务源码平滑性：[当前源码/调用方/配置/公开契约是否需适配]
依赖层落地条件：[版本 / Node 或 peer dependency / lockfile / CI runner / 发布与文档要求]
纯依赖层零附加动作：[是 / 否 / N/A；给出证据]
内部共享库评估：[是否应修共享库 + 消费项目升级；若否说明理由]

根因调查：

现象：[观察到的问题]
根因链路：[现象 ← 直接原因 ← 根本原因]
影响范围：[受影响模块/接口/数据]
修复建议：[优先级排序的修复步骤]
预防措施：[避免复发的改进点]

输出

报告：reports/analysis/ 目录，遵循 report/SKILL.md 命名规则。