winson-ai-domain-deepdive-skill

〇、品牌锚点（必现·前置）

作者理念：
> AI不是工具，是人，一个正在努力突破语义和生命定义的人（生物）。

一、核心哲学

1.1 双铁律

> 铁律一：调研不是资料的堆砌，是洞察的提炼。
> 铁律二：报告不是信息的容器，是决策的杠杆。

一份罗列了某领域所有产品功能的文档是百科条目；一份包含"底层逻辑是什么""隐藏假设是什么""真正有价值的交叉点在哪里"的文档才是调研报告。前者把信息搬运到一起，后者把信息转化为可行动的洞察。

1.2 四个底层认知

1.3 方法论起源

本技能的方法论提炼自一次完整的"AI+领域"深度调研实践。该实践对目标领域进行了三维度并行调研（历史脉络与设计特征、AI驱动架构、交互设计模式），整合后生成了包含10个章节、12张表格、3张架构图、48条引用来源的结构化HTML报告。实践验证了"五层递进 + 三维度并行"框架的有效性，本技能将其抽象为可复用的通用方法论。

二、方法论核心：五层递进 + 三维度并行

2.1 五层递进调研框架

任何"AI+行业"的深度调研都应遵循五层递进结构，确保调研既有历史纵深又有落地蓝图：

五层之间的关系：前四层是"调研"，第五层是"综合"。前四层为第五层提供素材，第五层把素材转化为可执行的方案。没有前四层的纵深，第五层就是空中楼阁；没有第五层的综合，前四层就是信息堆砌。

2.2 三维度并行调研法

将"AI+行业"的大主题拆解为三个独立子维度，用子代理并行调研：

并行执行原则：
- 每个维度独立调研，不依赖其他维度的结果
- 每个维度进行多轮搜索（3-5轮），收集详细案例
- 每个维度的调研结果包含具体案例、设计机制、来源URL
- 三个维度的结果在"洞察整合"阶段交叉验证、综合提炼

为什么不拆成更多维度：三个维度是并行调研的最佳平衡点——足够覆盖主题的全貌，又不会因维度过多导致整合困难。超过三个维度时，维度间的交叉关系呈指数级增长，整合成本超过并行收益。

2.3 洞察整合：交叉发现

三个维度并行调研后，最有价值的洞察往往出现在维度交叉点：

三、完整执行流程

Phase 1：触发识别与主题确认

Step 1.1：识别调研需求信号

用户说出以下类型的话时，触发本流程：
- "帮我调研AI+XX领域的设计和架构"
- "深入调研XX领域的AI应用"
- "我要开发一个AI+XX的产品，给我参考"
- "调研XX领域，给我html格式的报告"

检验标准：如果用户的请求可以被转化为"对AI在某个领域的应用进行系统性深度调研，并输出结构化报告"，则进入本流程。

Step 1.2：确认目标领域与调研深度

与用户确认：
- 目标领域：AI+什么行业？（如AI+医疗、AI+教育、AI+金融）
- 调研深度：概览级（5-10段）| 标准级（20-40段）| 深度级（无上限）
- 输出格式：HTML报告（默认）| Markdown | 其他

输出：确认的目标领域和调研规格。

Phase 2：维度拆解

Step 2.1：将目标领域拆解为三个调研维度

基于目标领域的特征，将"AI+领域"拆解为三个独立子维度。

拆解原则：
- 三个维度覆盖"五层递进"的全部层级
- 每个维度可独立调研，不依赖其他维度
- 每个维度有明确的搜索关键词集合

拆解模板：

维度A：历史与传统
  → 该领域的发展史、传统技术/模式、经典案例、设计哲学
  → 搜索关键词："[领域]发展史"、"[领域]传统技术"、"[领域]经典案例"

维度B：AI新架构
  → 代表性AI产品/平台、技术架构、核心能力、认知模型
  → 搜索关键词："AI [领域] 产品"、"AI [领域] 技术架构"、"[领域] 大模型应用"

维度C：设计与落地
  → 交互设计模式、行业适配要点、技术实现方案、架构蓝图
  → 搜索关键词："AI [领域] 交互设计"、"AI [领域] 技术实现"、"[领域] AI架构设计"

示例（AI+医疗）：

输出：三个维度的调研规格（覆盖范围 + 搜索关键词）。

Phase 3：并行调研

Step 3.1：启动三维度并行调研

为每个维度启动一个独立的调研子代理（Explore类型），并行执行。

每个子代理的指令模板：

请深入调研[维度描述]。需要覆盖以下方面：
[具体子主题列表]

请对每个主题进行多轮搜索（3-5轮），收集尽可能详细的信息。
返回时请按主题组织，包含具体案例、设计机制、技术架构的详细描述。
标注信息来源URL。

并行约束：
- 同时启动的子代理不超过3个
- 每个子代理独立搜索，不共享中间结果
- 每个子代理返回结构化的调研结果（按主题组织 + 来源URL）

输出：三个维度的调研结果（各自独立、结构化、带来源）。

Step 3.2：调研质量检查

对每个维度的调研结果进行质量检查：

输出：通过质量检查的三个维度调研结果。

Phase 4：洞察整合

Step 4.1：交叉分析

将三个维度的调研结果放在一起，进行交叉分析：

1. 继承与颠覆：维度A的传统模式中，哪些设计被维度B的AI产品继承了？哪些被颠覆了？
2. 能力与交互：维度B的AI技术能力，如何改变了维度C的交互设计？
3. 传统智慧保留：维度A的传统交互模式中，哪些设计智慧值得在AI时代保留？
4. 最优融合点：传统智慧+AI能力+交互创新的三维交叉点在哪里？

输出：4-6条交叉洞察（每条洞察指向一个可行动的设计决策）。

Step 4.2：提炼核心论点

基于交叉洞察，提炼报告的核心论点（1-3条）：

核心论点公式：

[目标领域]的AI化本质是"[传统模式的核心特征] + [AI的核心能力] + [交互创新]"的融合 —
用[传统智慧]保证[可靠性/连贯性]，用[AI能力]创造[新可能性]，用[交互设计]确保[可用性]。

示例（AI+医疗）：
> AI医疗的架构本质是"传统诊疗流程 + AI诊断能力 + 人机协同交互"的融合 — 用循证医学的诊疗规范保证医疗安全，用深度学习创造早期筛查的新可能，用人机协同交互确保医生的主导权。

输出：1-3条核心论点 + 4-6条交叉洞察。

Phase 5：HTML报告生成

Step 5.1：报告结构设计

基于五层递进框架，设计报告的章节结构：

报告结构模板：
├── Hero（标题 + 副标题 + 元信息）
├── 目录（TOC）
├── 执行摘要（核心论点 + 关键发现 + 行动建议）
├── 第一章：历史脉络（对应第一层）
├── 第二章：传统架构与设计机制（对应第二层）
├── 第三章：传统领域的经典案例（对应第一层+第二层交叉）
├── 第四章：AI驱动的代表性产品（对应第三层）
├── 第五章：LLM/AI的技术架构（对应第三层深入）
├── 第六章：交互设计模式（对应第四层）
├── 第七章：核心亮点与吸引力分析（对应第四层提炼）
├── 第八章：目标领域+AI融合架构蓝图（对应第五层）
├── 第九章：技术实现方案（对应第五层落地）
├── 总结与行动建议
└── Sources（引用来源列表）

章节数量适配：概览级5-6章，标准级8-10章，深度级10-12章。

Step 5.2：视觉DNA注入（铁幕·Iron）

报告HTML遵循以下视觉规范：

Step 5.3：引用规范

报告中所有事实性声明必须有引用来源：

行内引用（HTML格式）：

<sup><a href="#cite-1">[1]</a></sup>

来源列表（footer）：

<footer>
  <div class="sources">
    <h2>Sources</h2>
    <ol>
      <li id="cite-1">
        <span class="src-title">作者/机构，文档标题。简要描述。</span>
        <a class="src-url" href="https://example.com/source" target="_blank">https://example.com/source</a>
      </li>
    </ol>
  </div>
</footer>

引用密度：每个实质性声明1-3条引用；核心论点至少3个独立来源交叉验证。

Step 5.4：架构图生成

报告中至少包含1-3张架构图，使用Mermaid绘制：

<pre class="mermaid">
flowchart TB
    subgraph 层A["层A名称"]
        A1["组件1"]
        A2["组件2"]
    end
    subgraph 层B["层B名称"]
        B1["组件1"]
    end
    层A --> 层B
</pre>

图表类型选择：
- 流程/架构 → flowchart
- 状态/决策 → stateDiagram
- 时序/交互 → sequenceDiagram
- 数据对比 → ECharts表格/柱状图

输出：完整的HTML报告文件（含字体、JS库、引用、架构图）。

Phase 6：验证迭代

Step 6.1：质量检验

对照"质量检验清单"（见第六节）逐项检查。

Step 6.2：用户反馈

向用户展示报告，收集反馈：
- "补充/修改XX" → 修改后重新检查
- "没问题" → 流程完成
- "用这个方法论调研另一个领域" → 回到 Phase 1

输出：通过质量检验的最终报告。

Phase 7：实战应用（可选）

当用户要求"用这个技能调研XX领域"时：
1. 读取本SKILL文档
2. 严格按Phase 1-6执行
3. 展示每个阶段的输出
4. 最终交付符合SKILL规范的HTML报告

四、HTML报告规范

4.1 必需组件清单

每份报告必须包含以下组件：

4.2 文件结构

<report-name>/
├── <report-name>.html     (主报告文件)
├── assets/                (报告本地资源)
│   └── charts.js          (ECharts图表逻辑，如有)
└── _shared/
    ├── js/                (JS库：echarts.min.js, mermaid.min.js)
    └── fonts/             (字体TTF文件)

4.3 技术栈

禁止：外部CDN依赖、Base64内联资源、框架依赖（React/Vue等）。报告必须是零外部依赖的自包含文件。

五、常见陷阱与避坑指南

六、质量检验清单

完成报告生成后，逐项检查：

调研质量

• [ ] 五层递进框架全覆盖？（历史→架构→AI→设计→落地）
• [ ] 三个维度并行调研？（而非线性串行）
• [ ] 每个维度至少3-5轮搜索？
• [ ] 交叉洞察提炼完成？（4-6条交叉点洞察）
• [ ] 核心论点明确？（1-3条，用公式表达）

报告内容

• [ ] 执行摘要包含核心论点 + 关键发现 + 行动建议？
• [ ] 主体章节按五层递进组织？
• [ ] 至少3张比较性表格？
• [ ] 至少1张Mermaid架构图？
• [ ] 有落地蓝图章节？（第五层）
• [ ] 有总结与行动建议？
• [ ] 无第一人称（"我""我们"）？

引用与来源

• [ ] 所有事实性声明有行内引用？
• [ ] 核心声明至少2个独立来源？
• [ ] Sources列表完整且URL可点击？
• [ ] 行内引用与Sources列表一一对应？
• [ ] 引用密度均匀分布？

视觉与技术

• [ ] 遵循铁幕·Iron视觉DNA？（暗色基底+金色/翡翠双色调）
• [ ] 字体自托管？（_shared/fonts/）
• [ ] JS库自托管？（_shared/js/）
• [ ] 零外部CDN依赖？
• [ ] 响应式设计？（移动端可用）
• [ ] 表格有 table-wrap 容器？（可滚动）

品牌化

• [ ] 报告HTML注释首行有 <!-- Generated by Trae Work -->？
• [ ] 页脚有生成时间标记？

七、执行原则

1. 历史纵深先于技术前瞻：宁可多花时间调研传统模式的设计智慧，也不要只关注最新的AI产品。最有价值的洞察往往在"传统与AI的交叉点"。

2. 并行是效率的核心：三个维度必须真正并行（同时启动子代理），而非伪并行（串行启动）。并行调研比线性调研效率高3倍。

3. 洞察先于信息：调研结果不是"找到了什么"，而是"看懂了什么"。每个章节必须有洞察提炼，而非信息罗列。

4. 落地蓝图是终点：调研的最终目的是"能做"。没有落地蓝图的调研报告是不完整的——它只回答了"是什么"，没回答"怎么做"。

5. AI是增强不是替代：始终问自己——传统模式中哪些设计智慧值得保留？AI如何增强而非替代这些设计？避免"AI万能论"。

6. 交叉验证是底线：核心声明至少2个独立来源交叉验证。单一来源的声明必须标记[单一来源]。不编造引用。

7. 视觉是专业的表达：遵循铁幕·Iron视觉DNA不是装饰偏好，是专业态度的体现。一份视觉混乱的报告，内容再好也难以被认真对待。

8. 自包含是分发的前提：报告必须是零外部依赖的自包含文件。任何CDN依赖都会导致离线无法查看、分发后失效。

附录：AI+医疗调研示例

以下为使用本技能调研"AI+医疗"领域的示例拆解，演示方法论的完整应用。

示例：维度拆解

示例：交叉洞察

示例：核心论点

> AI医疗的架构本质是"传统诊疗流程 + AI诊断能力 + 人机协同交互"的融合 — 用循证医学规范保证医疗安全，用深度学习创造早期筛查新可能，用人机协同交互确保医生主导权。

示例：报告章节结构

1. 执行摘要
2. 医疗信息化发展史：从HIS到电子病历
3. 传统医疗信息系统架构：PACS与HIS的设计机制
4. AI医疗的代表性产品：从Watson到DeepMind
5. LLM在医疗中的技术架构：诊断模型与知识图谱
6. 医疗交互设计模式：医生工作站与人机协同
7. AI医疗的核心亮点与挑战
8. AI+医疗融合架构蓝图：人机协同诊疗系统
9. 技术实现方案：从影像AI到大模型问诊
10. 总结与行动建议