Wiki Intent Scope

SKILL.md

---
name: wiki-intent-scope
description: 当用户提供客户需求、研究对象（词条/主题词）、业务意图、政府/企业研究需求、市场进入问题、可行性研究需求、排名/背书目标或政策/咨询报告需求时，用于 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`。