调研清单生成

要解决什么问题

售前或交付前期，常见情况是合同、需求邮件、会议纪要已经堆在一起，但还没形成可追问、可归档的调研清单。若直接让模型写正式业务方案，容易把「文档里写过」和「客户已确认」混在一起，也会漏掉 CAP4 配置、接口集成、部署约束等需要单独归因的能力边界。

本技能的目标不是产出最终方案，而是：先梳理用户材料，再补齐调研问题，并把每条待确认项归到固定口径，生成可交给下游 $business-solution-writer 的交棒物。

技能如何工作

固定流程大致如下：

1. 初始化案例包：优先运行 scripts/init_research_workspace.py，在用户给定目录内增量更新；上传资料复制到 01-输入资料-inputs/，不移动原文件。
2. 按顺序读参考与用户材料：先读 references/05-handoff-spec.md，再按需读产品、CAP4、集成、运维四类知识源，最后从用户材料抽取合同范围、模块、表单、流程、角色、权限、集成与环境版本。
3. 补公开资料：需联网时调用 $smart-search，范围限于客户公开信息、行业/监管背景、相似案例；外部内容只能标为参考，不能写成客户既成事实。
4. 产出清单与底稿：维护 research-manifest.md、dialog-log.md，生成或更新 research-checklist.xlsx 与 solution-writer-handoff.md；处理表格时调用 $Excel。
5. 多轮确认：对不清楚项按 P0/P1/P2 追问，直到 P0 达到「已确认」或「待用户确认」。

清单列固定为：序号、调研对象、调研内容、优先级、信息来源、能力归因、对应方案输出项、确认状态、备注。能力归因仅限：官方产品能力、CAP4 配置能力、接口/集成能力、运维/部署约束、客户待确认。

适用边界与注意点

• 输出目录与下游草稿、正式稿默认在同一案例包根目录（05-方案草稿-draft/、06-正式输出-output/），避免文件散落。
• 写作上须区分四类内容：客户事实、官方能力参考、可能需开发/集成验证、外部案例与公开资料；无法确认一律归为「客户待确认」，不替用户拍板。
• 交棒物固定为 03-调研清单-checklist/research-checklist.xlsx 与 04-交接材料-handoff/solution-writer-handoff.md，语境是让下游在同一案例包内继续做模板判断与方案追问，而非从零重梳。