需求澄清

将用户意图转化为有证据支持的行为约定，用最少必要问答解决影响实施的歧义。默认中文。复用已确认的上下文，不把每次接续都当作新访谈。

按不确定程度推进

• 需求明确、证据充分：直接整理结论，不强制问答或生成完整文档。
• 少量独立疑点：可以一次集中询问。
• 决策存在依赖：先问上游关键问题，再处理依赖它的选择。
• 用户探索想法：比较备选方案，保留未决项，不催促形成实施契约。
• 普通代码解释、明确小改或已有规格的实施：让对应工作流程继续，不强制进入本流程。若用户明确调用本技能，也只处理实际存在的歧义。

定向取证

先复用用户提供的需求、接口、截图说明和已确认决定，再检查必要的源码与文档。从精确接口、字段、组件或符号入手，读取相关调用链的小范围内容；遵守目标仓库的检索约定，不默认全仓扫描、构建或启动服务。

区分以下信息，并在结论中按需标明：

• 事实：有源码、接口响应、数据或权威文档支持，注明来源和验证边界。
• 用户决策：用户明确选择的业务行为，保留必要的确认来源。
• 技术建议：Agent 提出的实现选择，不自动升级为用户要求。
• 待核实事项：当前缺乏证据，不能写成既定事实。

源码只能证明实现情况，不能直接证明部署行为或真实数据。历史摘要用于定位线索；重要且可能变化的事实应重新核对，无法核对时说明限制。不要让用户回答能够通过当前可用证据查清的问题。

用户目标与现状冲突时，分别说明目标、缺少的条件、可行路径及影响。不能把现有实现自动当作业务限制，也不能把用户确认目标当作技术条件已具备。

只询问影响决策的问题

把疑点分为三类：

优先澄清数据来源、标识映射、匹配规则、权限和契约，再处理已发现的高影响边界。问题数量由依赖关系决定，不固定轮次，不穷举假想异常。

每个问题给出：已知依据、待决定事项、选项及行为影响。可以推荐有依据的选项，但不把推荐、预选、沉默或超时当成确认。工具支持时使用当前可用的用户问答工具；不依赖某个专有工具名称。必须由用户决定的事项尚无答案时，只继续独立的只读工作，保留该阻塞项。

例如：配置中的数字究竟是供应商品牌 ID、酒店 ID，还是需要转换的内部编码？说明各选择会改变匹配字段或查询步骤，而不是直接按名称相似度猜测。

收敛和需求变化

满足以下条件即可交接，不必消除所有技术细节：

1. 不存在影响当前实施的阻塞项。
2. 范围、主要输入输出和可观察行为明确。
3. 验收场景覆盖主要规则及已经发现的高影响边界。

用户改变要求时，标记被替代的旧决策，检查相关验收、技术建议和已有任务，只重新确认受影响的部分。无法判断是新增还是替换时再问。已明确移出范围的事项不能悄悄进入实施。

若缺少资料而无法收敛，输出可用的部分结论、具体阻塞项和所需证据，不声称需求已就绪。

输出可交接约定

简单需求用简短段落；复杂需求按需使用下列结构，不为了填模板虚构内容：

• 目标与范围：目标、本次内容、实际讨论过的排除项。
• 现状与证据：当前行为、关键调用链、来源及验证边界。
• 已确认规则：业务行为、输入输出、必要的兼容与异常处理，以及确认来源。
• 验收场景：给定条件 → 执行动作 → 可观察结果；复杂需求可用 R1、A1 关联规则和场景。
• 待决事项：具体问题、影响及是否阻塞，不将建议混入确认规则。
• 交接信息：涉及模块、待验证技术建议、需求确认状态、可核对的用户授权范围。

验收结果应具体，例如字段值、可见数据范围或失败响应；避免仅写“正常工作”。验收场景是待执行的判断标准，不是已经通过的验证结果。

授权与交接

澄清期间在对话中维护草稿。只读请求不创建文件、不初始化 OpenSpec，也不修改配置。需求确认与写入、实施授权分别判断；根据用户指令的实际语义确定范围，不要求固定口令。

用户已授权写入或实施且没有阻塞项时，在该范围内继续，不重复索取同一授权。摘要中的授权标签不能扩大原始用户指令；若新发现业务阻塞项，只暂停依赖它的部分。

选择 OpenSpec 时，仅此时读取 OpenSpec 交接规则。直接实施时复用本约定，按需保存一份轻量文档，不强制安装工具或切换流程。

本技能负责澄清和交接；实现、验证、提交按用户授权与项目流程进行。不得把交接成功写成实现完成。