Wiki Intent Scope

当用户提供客户需求、研究对象（词条/主题词）、业务意图、政府/企业研究需求、市场进入问题、可行性研究需求、排名/背书目标或政策/咨询报告需求时，用于 Wiki 研究项目的任务与决策场景界定。解析客户自由表述，内部调用 wiki-normalize，识别研究对象、管理问题、研究意图、研究口径、风险和待确认项，并输出聊天摘要、人类可读的 scope.md 与机器可读的 scope.json。

研究任务与场景界定

本技能用于将客户原始需求转化为结构化研究任务说明，是行业研究的项目启动节点。它接受客户自由表述，不要求客户先填写模板。 本技能只负责界定研究任务、决策场景、研究口径和输出假设；不负责正式研究、证据收集、报告框架搭建或研究报告正文撰写。

核心目标

本技能围绕四件事输出任务界定：

1. 将用户自由表述拆解为结构化字段，包括客户原话、发起方/使用场景、隐含目标、研究对象、管理问题、研究问题、证据问题、当前假设和待确认项。
2. 根据预设的常见研究意图分类，判断主意图、辅助意图和更细颗粒度意图，用于后续 wiki-framework-builder 按意图路由生成研究框架。
3. 明确研究口径，包括时间、区域、语言/信源、统计基础、币种、价格基础、纳入排除范围、输出用途和结论强度。
4. 在文字输出和交接记录中说明需求是否足够清晰、课题是否可基于当前假设推进，并列出需要用户补充或人工确认的问题。

工作边界

• 接受客户自由表述，不要求客户先填写模板。
• 可以在信息不完整时输出当前假设和待确认项。
• 不因为口径字段存在缺口而自动阻塞下一步。
• 如用户补充回答或确认问题，应基于新信息重新运行本技能并更新任务界定。
• 如用户暂不补充或确认，可基于当前假设进入后续流程，或将本次任务界定作为阶段性结果结束。
• 需求清晰度和课题可推进性需要人工最终确认，但该确认提示不强制阻塞下一步。

核心流程

按顺序完成以下工作：

1. 解析客户原始措辞、发起方、输出用途和隐含目标，形成 client_request。
2. 先提取唯一研究对象，再运行 skill wiki-normalize 对研究对象进行标准化，形成 normalize。
3. 基于标准化结果做边界预检查，区分术语颗粒度、研究对象、易混概念和研究边界，形成 boundary_precheck。
4. 将客户问题转换为管理问题、研究问题和证据问题，形成 problem_transform。
5. 读取 references/intent_taxonomy.md，判断主研究意图、可选辅助意图和细化意图，形成 research_intent。
6. 检查研究口径和缺口，形成 scope_caliber。
7. 识别预设结论、对外发布和排名背书风险，形成 conclusion_risk。
8. 推荐框架深度，形成 framework_depth。
9. 汇总当前假设、待确认项、建议追问、需求清晰度和课题可推进性说明，形成 handoff_record。
10. 按 references/output_contract.md 输出聊天摘要、scope.md 和 scope.json。

不可协商规则

• 始终在本技能内部运行 wiki-normalize skill，不要要求用户先运行。
• 输入中必须包含可提取的研究对象；如果缺失或无法判断，不要自行生成对象，先反馈要求用户补充或确认。
• 不要执行完整定义研究、证据工作、关系建模、框架搭建或正式报告撰写。
• 不要因为管理问题尚未确认而阻塞输出；把它作为当前假设，并保留确认状态。
• 仅将 L1-L5 视为术语颗粒度：L1 概念级、L2 产业级、L3 行业级、L4 产品/市场级、L5 应用产品级。L1-L5 不得直接决定报告章节层级或研究维度选择。
• L1-L5 使用规则保持内部化，不要在客户可见文本中解释。
• 静默忽略客户报价、项目预算、服务费用等商务信息；不要说明已忽略，也不要写入输出。不要因此删除研究口径中的价格基础、定价问题或市场价格相关模块。
• 不要将复合客户措辞拆成多个独立任务对象；应统一形成一份任务界定，记录主意图、辅助意图和确认问题。
• 如果请求带有预设期望结论，将其重构为可验证的研究问题。
• 如果输出可能用于对外、公开、政府面向或品牌传播，提高证据要求和措辞风险提示。

客户措辞解析

只提取与研究相关的信号：

• raw_text：客户原始措辞。
• recognized_client_or_sponsor：发起方、发布方、客户或决策侧线索。
• recognized_use_context：内部决策、政府报告、公开发布、路演/方案、投资、可行性、品牌传播、政策建议等。
• implicit_goal：未明说或已明说的目标，例如“证明影响力”“确认市场地位”“定位园区”“支持落地深圳”。
• external_use_likelihood：low / medium / high。

研究对象提取

研究对象是 wiki-normalize 的输入词条；“词条”或“主题词”在本技能中也按研究对象处理。 研究对象应是一个可被研究的产业、行业、产品、市场、应用或概念对象。 不要把完整句子作为研究对象，应提取底层行业主题作为 normalize.original_name。 如果客户需求中只提供研究动作、报告类型、输出用途或期望结论，没有可提取的研究对象，先要求用户补充或确认研究对象，再继续后续流程。

问题转换

客户提出的往往是症状、请求、目标或预设结论，不要自动等同为真实决策问题。

始终区分以下层次：

• client_problem：客户原始症状、请求或预设措辞。
• management_problem：客户可能真正需要分析和判断的管理问题。这是 AI 推断，除非用户已明确确认，否则必须标记为未确认。
• alternative_management_problems：同一客户措辞可能指向不同决策时的备选管理问题。
• research_problem：支撑管理决策所需回答的可研究问题。
• evidence_questions：回答研究问题所需的证据检查、数据问题或验证路径。

当管理问题只是从客户措辞中推断出来时，不要把单一推断当作最终事实。使用 confirmed 或 pending_confirmation 标记确认状态，并使用 low、medium、high 标记置信度。

方法论支持

在聊天摘要和 scope.md 中，如能增强客户信心，可加入简短的 方法论依据 说明。保持简短、便于客户理解；不要加入冗长学术阐述、引用或内部方法论代码。

可使用的表述基础：

• 问题定义：客户措辞往往是症状或请求；研究质量取决于在设计研究前定义真实问题。
• 管理决策问题到研究问题的转换：区分客户需要作出的决策与研究必须收集或验证的信息。
• 问题框定/重构：当同一措辞可能指向不同管理决策时，提出替代解释。
• 假设驱动的问题解决：将推断的管理问题和研究问题视为待验证假设，而非已确认事实。

不要声称这些概念是麦肯锡专有理论。

研究意图分类

判断研究意图时必须读取 references/intent_taxonomy.md。

使用宽口径、常见咨询类别。优先选择一个主类型和一个可选辅助类型；不要创建多个任务对象。更细的需求写入 explicit_granular_intents。

预设结论与发布风险

识别此类请求：

• “突出某公司影响力”
• “证明某品牌第一”
• “体现领先地位”
• “支持对外传播”

将预设结论重构为可验证问题。

不佳：

• “证明阿里云在高校 AI 中有影响力。”

较好：

• “建立高校 AI 应用能力与服务商影响力评价口径，并检验阿里云在高校群体中的影响力表现。”

设置护栏：

• 必须将预设结论改写为可验证的研究问题。
• 必须确认是否存在对外发布、公开传播或第三方背书场景。
• 在证据不足时，禁止生成强结论、排名背书或领先性主张。

研究口径

始终检查并记录：

• 时间范围：历史区间、预测周期、数据截止日期。
• 区域：全球、中国、省/市/区、海外市场。
• 纳入与排除范围。
• 语言范围：中文、英文、双语信源、输出语言。
• 统计基础：收入、终端销售额、产值、GMV、用户数、装机量、数量 x 价格等。
• 涉及定量时的币种和价格基础：人民币/美元、名义/实际、含税/不含税、出厂/零售。
• 决策主体和输出用途。
• 结论强度限制：描述、解释、趋势判断、机会判断、行动建议。
• 信源/数据约束：公开信源、数据库、访谈、内部数据、实地调研。

如未知，标记为 待确认，不要静默假设。

边界预检查

仅做任务界定所需的边界检查，不收集证据，不撰写正式定义。

最多输出 3-7 个候选术语或歧义点，覆盖：

• 上位概念。
• 下位概念。
• 同级或易混概念。
• 价值链环节概念。
• 相关替代或竞争边界。

深度推荐

推荐一个深度等级：

• 简易：快速扫描、内部讨论、无强建议。
• 常规：正式行业/市场报告、客户汇报、机会判断。
• 深度：投资、尽调、可行性、政府/园区战略、排名背书、公开发布或强行动建议。

输出要求

输出必须遵循 references/output_contract.md。