Domain Deep Dive（领域定义 + 五层深潜框架）
Overview
本技能提供一套结构化的"领域定义 + 五层"递进框架——先用一张可验证的领域定义卡把"我们要拆解的到底是什么"讲清楚（语义基座），再用五层递进框架（本质与边界→概念与语言→系统与关系→演化与争议→实践与验证）把认知从"泛泛而谈"升级为"可执行、可验证的系统理解"。同时按读者认知起点自适应三档信息强度（入门/专业/深度），避免"看不懂"或"嫌太浅"。验收标准嵌入在第五层，而不是停留在罗列工具和名词上。最终产出是一套结构化交付物，不是一篇长文章。
When to Use
当用户提出以下类型请求时使用本技能：
- "帮我系统讲解/拆解一下 [某领域]"
- "我想快速搞懂 [某行业] 是怎么运作的"
- "带我入门 [某专业方向]"
- 用户直接引用"第一层：本质与边界……第五层：实践与验证"这套框架，且给出或未给出具体领域
如果用户没有指明具体领域，先用 AskUserQuestion 或直接提问确认要拆解的领域（例如：跨境电商、私募股权、临床医学、半导体制造、AI Agent 商业化等），因为五层框架的内容完全依赖领域本身。
0. 领域定义 / 术语界定（必填，在五层框架之前）
这是整个报告的"语义基座"——在进入任何分析之前，先用一段独立的定义把"我们要拆解的到底是什么"讲清楚。本模块缺位会让后续所有讨论在读者脑中指向模糊（用户最常见的反馈是"读完还不知道这个领域是什么"）。
- 一句话核心定义：用一句不含行话的话，把领域是什么讲清楚，普通人读完能转述。用"X 是……"的下定义口吻。
- 详细定义（2-4 句）：覆盖核心对象 + 主要职能或范围 + 与相邻领域的边界。
- 权威来源验证：必须给出至少 1 个权威来源对该领域的标准定义（行业协会、专业教材、官方文件、学术综述；维基百科可作起点但需回溯一手），附（机构 / 出处 / 年份）。读者点开来源应能查到原文——不能凭印象撰写。
- 置信度标注：定义句尾部用
[已核实]/[单源]/[估算]标注（继承自 research_protocol）。 - 常见误解 / 易混淆：列举 2-3 个外行或跨领域人士常把这个领域和什么混淆（如把"HR"等同于"招聘"、把"私募股权"等同于"对冲基金"），这是"先定义"的核心价值。
- 多定义并存处理：如权威文献中存在多个并列定义（如"AI"在 OECD、中国信通院、欧盟 AI 法案里的不同定义），必须并列呈现并说明分歧由来，不能只挑一个。
本模块的产出是"领域定义卡"，对应 Deliverables 的第 0 项，HTML 报告中位于五层框架之前。其白话程度随信息强度档位调整（见 references/information_density.md）。
The Five Layers
对目标领域逐层展开，每层都要输出具体内容，不能只写框架标题：
第一层：本质与边界
- 这个领域解决什么核心问题？服务于谁（客户/对象）？
- 核心价值主张是什么？不做什么、边界在哪（哪些相邻领域容易被混淆）？
- 关键约束条件是什么（法规、资源、技术、周期）？
第二层：概念与语言
- 专业人士日常使用的核心术语、缩写、行话是什么？
- 关键指标/度量体系是什么（KPI、财务指标、技术指标等）？
- 输出为"核心概念表"（见 Deliverables）。
第三层：系统与关系
- 领域内有哪些角色（甲方/乙方/监管方/终端用户等），他们之间如何交互？
- 典型业务流程或价值链是什么？画出因果链/流程图。
- 数据如何流动？利益如何分配？
- 有哪些主要流派/学派/技术路线？组织分工（谁做什么、边界在哪）？
第四层：演化与争议
- 这个领域为什么演化成今天的样子？关键历史节点/转折点是什么？
- 当前哪些问题业内尚无共识（技术路线之争、商业模式之争、监管之争）？
- 哪些正在发生的变化（技术/政策/需求侧）可能真正重构这个领域？
第五层：实践与验证（验收层）
这一层不是罗列工具，而是设计一个"最小可行实践"，并明确验证标准：
- 用什么方法、工具、数据能完成一次最小实践（不追求完整，追求真实可执行）？
- 如何通过真实案例反推理解是否正确？
- 准备哪些问题去问真正的从业者/专家，用于校验认知盲区？
- 明确"完成"的判定标准是什么（例如：产出一份可被内行认可的初步方案/分析/原型）。
Deliverables Checklist
无论目标领域是什么，最终交付物必须包含以下八项（含先于五层的领域定义卡），缺一不可：
- 领域定义卡（语义基座，必填）：用一段独立的领域定义，把"这个领域是什么"讲清楚。必含：一句话核心定义（"X 是……"口吻）+ 详细定义 + 至少 1 个权威来源引用 + 常见误解列表 + 置信度标签。格式与撰写要点见
references/deliverable_templates.md第 0 节。此项缺位视为报告不合格。 - 领域全景图：一张视觉化图（用 Visualizer 的 diagram 模块生成 SVG），展示角色、流程、关键概念的关系全貌。不要用纯文字代替。
- 核心概念表：表格形式，列出术语/指标 + 定义 + 为什么重要 + 常见误用。其中「定义」列必须用「xxx 是……」的定义式开头（先一句教科书式准确定义，再补重要性），禁止用比喻替代定义；入门档需再加一列「一句话懂」大白话类比（详见
references/deliverable_templates.md第 2 节与references/information_density.md）。 - 业务流程或因果链：至少一条端到端的流程链或因果关系链（谁触发→经过什么环节→产生什么结果→反馈到哪里），建议同时用 Visualizer 生成流程图。
- 两个真实案例：必须是可查证的真实公司/项目/事件（不是虚构范例），每个案例说明背景、关键决策、结果、对框架的验证或修正。
- 方法与工具清单：分类列出该领域从业者实际使用的方法论、软件、数据源、评估工具。每一项必须先用"X 是……"的下定义口吻解释"它是什么、解决什么问题、核心机制是什么"（面向第一次听说该名词的读者，1-2 句），再标注适用场景、市场地位与获取方式；禁止只罗列特点和市场地位而跳过定义。具体格式与正反例见
references/deliverable_templates.md第 5 节。 - 专业问题清单：5-10 个准备向真正专家提出的问题，聚焦第四层未有共识的争议点和认知盲区，问题要具体、可被专业人士快速判断"这人是不是懂行"。
- 一个亲自完成的小任务：设计一个用户或WorkBuddy可以在当次会话中实际动手完成的最小实践任务（例如：搭一个简化模型、做一次真实数据拉取与分析、模拟一次关键决策），并给出结果和自我验证方式。
参见 references/deliverable_templates.md 获取每项交付物的具体格式模板和撰写要点。
Research & Verification（强制检索验证协议）
在撰写任何一层内容或任何交付物之前，必须先执行 references/research_protocol.md 中定义的检索与验证流程。核心要点（详见该文件）：
- 分级信源：一手权威（年报/监管文件/法院文书）> 权威二次报道（主流财经媒体）> 自媒体/论坛（仅作线索，需交叉验证）> 模型自身知识（不能直接作为定量数据来源）。
- 五轮专项检索：领域框定（含权威来源对领域名称的标准定义，用于领域定义卡）→ 指标专项（核心概念表每个指标单独查最新数值）→ 案例专项（基本事实+量化结果各一轮，必要时用 WebFetch 核对原文）→ 争议专项（第四层必须专门检索具名专家/机构的分歧观点，不能编造伪争议）→ 工具专项（方法与工具清单每个条目核实当前维护状态与市场格局，避免推荐已废弃工具）。
- 交叉验证：任何写入交付物的具体数字，尽量用两个独立来源核对；不一致时并列呈现两个数字及来源，不擅自取一个。
- 置信度标注：每个关键数据点标注
[已核实][单源][估算][存在分歧]之一，估算类必须同时给出推理逻辑和假设条件。绝不能用"看起来精确"的数字掩盖真实的不确定性。 - 来源记录：格式为
(来源：机构/媒体名称，标题或文件类型，发布/统计时间)，附在案例、图表、关键数据点之后。
如果检索后仍找不到完全匹配的真实案例，宁可如实告知"未找到完全匹配案例，以下是最接近的真实案例并说明其局限性"，绝不虚构案例数据。
Workflow
- 确认目标领域，并执行认知起点校准与初次调用引导分流：按
references/information_density.md的规则，AI 先判断档位（入门/专业/深度，默认专业档）并输出分流卡，用户可一句话确认或改档；跨出用户专业的领域必须出分流卡等确认；判定为深度档则初始化用户状态表。框架不变、密度可变。 - 按上述 Research & Verification 协议做五轮专项检索（WebSearch/WebFetch），建立带置信度标注和来源记录的素材库，再动笔写正文。其中"领域框定检索"必须包含权威来源对领域名称的标准定义，用于"领域定义卡"的撰写。
- 先撰写"领域定义卡"（第 0 项），确认读者凭这一段就能讲出"这是什么"——这是后续五层的语义锚点，缺位会让所有后续讨论在读者脑中指向模糊。
- 按五层逐层撰写内容，每层都要具体、有信息密度，避免空话；不确定的地方明确标注置信度标签。
- 生成 Deliverables 清单中的八项交付物，全景图和流程图使用 Visualizer（先调用 read_me 加载 diagram 模块）生成 SVG，避免用纯文字表格代替视觉图。
- 在对话中用简体中文清晰分节呈现八项交付物的核心内容，让用户在聊天窗口里就能看到关键结论，而不是复述框架本身。
- 默认额外产出一份 HTML 报告文件（除非用户明确说"只要口头讲一下""不需要文件"）：参照
assets/demo.html模板，将八项交付物（含领域定义卡）和五层叙述内容填入对应占位符，SVG 图表直接内嵌到{{PANORAMA_SVG}}/{{CHAIN_SVG}}占位符中，领域定义卡填入{{DOMAIN_DEFINITION}}；生成后落盘到当前工作目录的输出位置（如outputs/<领域名>-deep-dive-report.html），并用 present_files 呈现给用户（present_files 会自动在预览面板中打开 HTML）。 - 如果用户明确要求其他格式（Markdown/PPT等），在 HTML 报告基础上按需再转换或补充生成，而不是替代 HTML 报告。
Notes
- 本技能的核心价值是"结构化 + 可验证"，避免输出停留在概念罗列层面。第五层的问题清单和小任务是检验前四层理解是否扎实的关键环节，不能省略。
- "领域定义卡"是必备的语义基座，先于五层：跳过它直接讲"本质与边界"会让读者连领域是什么都不知道就进入分析，是本技能最常见的输出缺陷。
- 信息强度自适应：框架不变、密度可变。动笔前必须按
references/information_density.md做认知起点校准与引导分流（AI 判断档位 + 用户确认），选定入门/专业/深度档；跨出用户专业的领域尤其要先出分流卡确认，否则极易写出让对方看不懂的内容。 - 清单类交付物统一下定义口吻：领域定义卡、核心概念表、方法与工具清单三处都必须用"X 是……"先下定义，再展开；禁止用比喻或营销话术替代定义。
- 案例必须真实可查，如果无法确认真实性，要明确告知用户这是示例性描述而非真实案例。
- 遇到跨学科或高度专业（如医疗、法律、金融监管）领域时，第四层的"争议"部分要客观呈现各方观点，不代替用户下结论。
- HTML 报告是交付物的"综合载体"，不是替代对话讲解——两者都要有：对话里讲清楚核心结论和判断，HTML 报告承载完整的结构化内容供用户长期保存和分享。
assets/demo.html的样式是浅色扁平风格（白底卡片、细边框、无渐变阴影），如果用户要求暗色主题或其他视觉风格，可在填充内容时直接调整该模板的 CSS 变量（:root中的颜色变量），不必重新设计整套样式。
