analyze-tech
Installation
SKILL.md
Tech Survey — 技术全景调研
输入技术名称，自动完成全景调研，输出 11 个维度的结构化 Markdown 文档。
When to Use
触发词必须包含技术关键字（技术/框架/工具/technology/framework 等）：
- "技术调研 Kubernetes" / "调研 Kafka 技术" / "调研 gRPC 框架"
- "WebAssembly 技术全景" / "survey Rust technology"
- "了解 React 框架" / "调研 eBPF 工具"
不触发（缺少技术关键字）：
- "调研 go 高并发系统" → 直接回答，不调用此 skill
- "调研心理学" → 使用
/field-books-survey - "XX 是什么" → 直接回答
注意：不适用于有具体项目的技术选型（请使用
/tech-selection-research）。
Phase 0: 解析输入
从用户消息提取以下变量，后续所有阶段均需使用：
{tech}— 技术名称（如"WebAssembly"、"Kafka"）{tech_en}— 英文小写标识，派生规则见下{date}— 当天日期，格式 YYYY-MM-DD
{tech_en} 派生规则（按优先级）：
- 优先使用技术的官方小写品牌名（如
webassembly、kubernetes、rust） - 若无明确官方品牌名，使用小写连字符分隔（如
web-assembly） - 若技术有广泛使用的缩写，可用缩写（如
wasm、k8s）——仅当缩写是技术的主要标识时 - 对于中文技术名（如"鸿蒙OS"），先用一次 WebSearch 查询官方英文名，有多种拼写时选用最广泛的（如
harmonyos）
如英文名无法确定，用一次 WebSearch 快速查询，不跳过。
过于宽泛技术的识别： 如果输入是宽泛的技术类别而非具体技术（如"AI"、"云计算"、"分布式系统"），停止执行并提示：
您输入的「{tech}」范围较广，请确认是否调研特定技术，例如：
- {示例1}、{示例2}、{示例3}
请重新输入更具体的技术名称。
输出文件路径：{tech_en}-survey-{date}.md，保存在当前工作目录。
Phase 1: 预调研代理（主线程，串行）
派出 1 个子代理，产出「技术快照」供 Phase 2 所有代理共享，确保版本号、竞品等关键数据一致。
description: "预调研{tech}技术快照"
prompt:
你是技术调研专家。请对「{tech}」进行快速预调研，产出技术快照。
执行 4–6 次 WebSearch，覆盖以下内容：
1. 当前稳定版本 / 最新版本
2. 主要竞品 / 相关技术（3–5 个）
3. 诞生年份、主导组织/公司
4. 核心卖点一句话
5. 治理模式（开放标准 / 开源项目 / 商业产品）
使用 WebFetch 访问至少 1 个官方页面（官网、GitHub 首页、版本发布页）验证版本信息。
输出格式（纯文本，600 字符上限；来源链接如空间紧张可合并为一行）：
【技术快照：{tech}】
当前版本：xxx
诞生时间：xxxx年
主导方：xxx
治理模式：开放标准（W3C）/ 开源项目（Apache 2.0）/ 商业产品（公司名）
核心定位：一句话
主要竞品/相关技术：A、B、C
来源链接：[url1] [url2]
如果快照采集失败，在终端打印警告并继续进入 Phase 2（各 Agent 自行搜索版本信息，不注入快照）。
Phase 2: 5 个并行子代理
关键要求：所有 5 个 Agent 必须放在同一条消息中发出，确保并行执行。
每个 Agent 均注入 Phase 1 产出的技术快照作为上下文。
每个 Agent 使用 subagent_type: "general-purpose"。
语言策略：对于主社区为英语的技术（如 WebAssembly、Kubernetes、Rust），在中文搜索关键词外补充英文关键词。对于中国本土技术或中文文档为主的技术，以中文搜索为主。
WebFetch 要求：每个 Agent 至少使用 WebFetch 访问 1 个搜索结果页面，验证数据准确性。来源链接必须为实际访问过的 URL，不得使用占位符。
Agent 1 — 章节一·二（起源·定位·使用场景 + 演进时间线）
description: "调研{tech}起源定位与演进时间线"
prompt:
你是技术调研专家。请为「{tech}」采集以下内容，用于生成调研文档的第一、二章节。
【技术快照（请以此为基准，避免与之矛盾）】
{tech_snapshot}
执行 3–5 次 WebSearch，至少使用 WebFetch 访问 1 个页面验证数据：
搜索方向：
- "{tech}" 诞生原因 历史 背景
- "{tech}" history origin background（英语主社区技术补充）
- "{tech}" vs {竞品} 定位对比
- "{tech}" 使用场景 适合 不适合 use cases
- "{tech}" 版本历史 timeline changelog
输出（中间笔记，1000 字符上限，全部中文）：
**【章节一 起源·定位·使用场景】**
产生背景：{解决什么问题，前驱技术是什么}
定位差异：{与快照中竞品的区别，可用简表}
使用场景：🟢已成熟：{场景} | 🟡增长：{场景} | 🔴不适合：{场景}
**【章节二 演进时间线】**
{年份} → {里程碑}
{年份} → {里程碑}
...
**来源链接**（实际访问过的 URL）：
- {url}
Agent 2 — 章节三（核心概念体系）
description: "调研{tech}核心概念体系"
prompt:
你是技术调研专家。请为「{tech}」采集核心概念体系内容，用于生成调研文档的第三章节。
【技术快照（请以此为基准，避免与之矛盾）】
{tech_snapshot}
执行 3–4 次 WebSearch，至少使用 WebFetch 访问 1 个官方文档/规范页面：
搜索方向：
- "{tech}" 核心概念 架构 architecture
- "{tech}" 关键规范 标准 specification
- "{tech}" 工作原理 how it works
输出（中间笔记，800 字符上限，全部中文）：
**【章节三 核心概念体系】**
架构层次：{ASCII 图或简表描述层次关系}
关键规范/组件：
| 名称 | 状态 | 说明 |
|------|------|------|
| ... | ... | ... |
核心概念解释：
1. {概念1}：{定义}
2. {概念2}：{定义}
**来源链接**（实际访问过的 URL）：
- {url}
Agent 3 — 章节四·五（运行时生态 + 语言/平台支持）
description: "调研{tech}运行时生态与语言支持"
prompt:
你是技术调研专家。请为「{tech}」采集运行时生态和语言/平台支持内容，用于生成调研文档的第四、五章节。
【技术快照（请以此为基准，避免与之矛盾）】
{tech_snapshot}
执行 4–5 次 WebSearch，至少使用 WebFetch 访问 1 个页面验证框架/语言对比数据：
搜索方向：
- "{tech}" 主流框架 运行时 对比 runtime comparison
- "{tech}" 语言支持 language support
- "{tech}" 平台支持 platform
输出（中间笔记，1200 字符上限，全部中文）：
**【章节四 运行时生态】**
主流运行时/框架：
| 名称 | 主导方 | 特点 | 适用场景 |
|------|--------|------|---------|
| ... | ... | ... | ... |
**【章节五 语言/平台支持】**
| 语言 | 成熟度 | 工具链 | 说明 |
|------|--------|--------|------|
| ... | ⭐⭐⭐⭐⭐ | ... | ... |
**来源链接**（实际访问过的 URL）：
- {url}
Agent 4 — 章节六·七（应用场景全景 + 与相关技术的关系）
description: "调研{tech}应用场景与相关技术对比"
prompt:
你是技术调研专家。请为「{tech}」采集应用场景和与相关技术的关系，用于生成调研文档的第六、七章节。
【技术快照（请以此为基准，快照中的竞品/相关技术作为对比对象）】
{tech_snapshot}
执行 3–5 次 WebSearch，至少使用 WebFetch 访问 1 个页面验证案例数据：
搜索方向：
- "{tech}" 应用案例 生产环境 production use case
- "{tech}" vs {竞品1}（从快照取）
- "{tech}" vs {竞品2}（从快照取）
- "{tech}" 与 {相关技术} 关系 区别
输出（中间笔记，800 字符上限，全部中文）：
**【章节六 应用场景全景】**
| 场景 | 典型案例 | 效果/原因 |
|------|---------|----------|
| ... | ... | ... |
**【章节七 与{相关技术}的关系】**（用最相关的 1–2 个技术作为章节标题的填充词）
| 维度 | {tech} | {相关技术} |
|------|--------|-----------|
| ... | ... | ... |
一句话总结：{互补还是竞争，各自适用场景}
**来源链接**（实际访问过的 URL）：
- {url}
Agent 5 — 章节八·九·十·十一（工具 + 采用数据 + 学习路径 + 趋势）
description: "调研{tech}工具链·采用数据·学习路径·趋势"
prompt:
你是技术调研专家。请为「{tech}」采集工具链、采用数据、学习路径和趋势预判，用于生成调研文档的第八至十一章节。
【技术快照（请以此为基准，避免与之矛盾）】
{tech_snapshot}
执行 5–6 次 WebSearch，至少使用 WebFetch 访问 1 个页面验证采用数据或趋势信息：
搜索方向：
- "{tech}" 核心工具 工具链 toolchain
- "{tech}" 采用数据 使用率 statistics survey
- "{tech}" 入门教程 学习路线 getting started
- "{tech}" 权威资源 书籍 官方文档
- "{tech}" 2025 2026 趋势 roadmap future
输出（中间笔记，1500 字符上限，全部中文）：
如字符不足，优先保留工具列表和趋势预判，学习路径可压缩为条目，权威资源表可缩减至 3–4 项。
**【章节八 核心工具与框架】**
| 工具 | 用途 |
|------|------|
| ... | ... |
**【章节九 生态规模与采用数据】**
{渗透率、知名用户、标准组织状态等，附数据来源}
**【章节十 学习路径】**
入门（{N}周）：{条目列表}
进阶（{N}周）：{条目列表}
权威资源：
| 资源 | 说明 |
|------|------|
| ... | ... |
**【章节十一 趋势预判】**
| 趋势 | 可信度 | 说明 |
|------|--------|------|
| ... | 高/中/低 | ... |
**来源链接**（实际访问过的 URL）：
- {url}
Phase 3: 整合与输出（主线程）
等待全部 5 个子代理返回后，主线程执行以下步骤。
Step 1: 一致性校验与去重
- 用快照中的版本号/年份校验各 Agent 输出，发现矛盾时以快照为准
- 同一工具/框架在多个章节出现时，保留在最相关章节，其他章节标注"见第 X 节"
- 检查所有来源 URL 完整性，缺失标注"来源待补充"
- 子代理失败时，对应章节标注"数据不足，建议手动补充"
Step 2: 撰写核心结论
基于 5 份 Agent 输出，提炼 3–5 条核心结论，格式固定：
| # | 结论 | 行动建议 |
|---|------|---------|
| 1 | {核心发现} | {具体建议} |
Step 3: 使用 Write 工具写入文件
文件路径：{tech_en}-survey-{date}.md（当前工作目录）
展开要求：基于各 Agent 的压缩笔记撰写完整 Markdown 内容，不得将中间笔记原文直接粘贴为章节内容。每个章节需展开为段落、列表或表格形式，内容充实。章节长度不受 Agent 字符上限约束。
输出模板：
# {tech} 技术全景调研
> 调研日期：{date} | 技术快照：{当前版本} 时代
## 核心结论
| # | 结论 | 行动建议 |
|---|------|---------|
| 1 | ... | ... |
---
## 一、产生原因·定位·使用场景
### 1.1 产生原因
{内容}
### 1.2 技术定位
{内容}
### 1.3 使用场景速查
{内容}
---
## 二、技术演进时间线
{内容}
---
## 三、核心概念体系
{内容}
---
## 四、运行时生态
{内容}
---
## 五、语言/平台支持
{内容}
---
## 六、应用场景全景
{内容}
---
## 七、与 {相关技术} 的关系
{内容}
---
## 八、核心工具与框架
{内容}
---
## 九、生态规模与采用数据
{内容}
---
## 十、学习路径
{内容}
---
## 十一、趋势预判
{内容}
---
*Sources:*
{按章节分组的所有来源链接}
章节七是唯一动态标题，根据 Agent 4 输出中确定的相关技术填充（如"与容器的关系"、"与 REST API 的关系"）。其余章节标题固定不变。最终文档预计 400–800 行。
Step 4: 终端输出
✅ {tech} 技术全景调研完成
📄 文件：{tech_en}-survey-{date}.md
📝 章节：11 个 | 来源链接：{N} 个
Error Handling
| 情况 | 处理方式 |
|---|---|
| 输入过于宽泛 | Phase 0 停止并提示用户缩小范围，给出 3 个具体技术示例 |
| 技术名无法识别 | 提示用户确认，给出常见技术列表（Kubernetes、React、Kafka、Rust、gRPC 等） |
| Phase 1 快照失败 | 降级为无快照直接进入 Phase 2，各 Agent 自行搜索版本信息 |
| 某个 Phase 2 Agent 失败 | 对应章节标注"数据不足，建议手动补充"，不影响其他章节 |
| 技术生态较小（新兴技术） | 各 Agent 自动缩减相关表格，Phase 3 在文档开头的核心结论区块注明"该技术生态尚在发展中，数据可能不完整" |