analyze-research

# 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、设计如此、用户决策、文档/实现漂移、测试覆盖缺口和未复现项 ## 各类型输出格式 **技术选型**： ```text 推荐：[方案名] 理由：[2~3句话，聚焦关键差异] 注意事项：[风险/限制] ``` **可行性评估**： ```text 结论：[可行 / 有条件可行 / 不可行] 前置条件：[无则填"无"] 成本估算：[工程量/依赖变更/测试] 风险点：[主要风险] 备选方案：[若不可行] ``` **依赖/兼容性评估**： ```text 业务源码平滑性：[当前源码/调用方/配置/公开契约是否需适配] 依赖层落地条件：[版本 / Node 或 peer dependency / lockfile / CI runner / 发布与文档要求] 纯依赖层零附加动作：[是 / 否 / N/A；给出证据] 内部共享库评估：[是否应修共享库 ...