back
loading skill details...
技术深度分析方法论。用于对新兴技术、技术趋势、技术产品进行系统化深度分析。 当需要分析新技术、写技术报告、做竞品分析、评估投资机会时使用此 skill。 触发词：深度分析、技术分析、竞品分析、技术报告、行业分析。
---
name: technical-deep-analysis
description: >
技术深度分析方法论。用于对新兴技术、技术趋势、技术产品进行系统化深度分析。
当需要分析新技术、写技术报告、做竞品分析、评估投资机会时使用此 skill。
触发词：深度分析、技术分析、竞品分析、技术报告、行业分析。
---
# Technical Deep Analysis - 技术深度分析方法论
> 严谨、可复现、高质量的技术分析框架。
## 一、分析类型与场景
| 分析类型 | 适用场景 | 输出形式 |
|---------|---------|---------|
| **技术趋势分析** | 新兴技术、范式转变 | 趋势报告 |
| **竞品对比分析** | 产品选型、投资决策 | 对比矩阵 |
| **技术深度剖析** | 核心技术原理、架构设计 | 技术白皮书 |
| **市场与投资分析** | 投资决策、战略规划 | 投资备忘录 |
---
## 二、信息可信度分级体系
### 分级标准
| 级别 | 来源类型 | 示例 | 使用规则 |
|------|---------|------|---------|
| **L1 最可信** | 官方文档、论文、代码仓库、技术报告 | OpenAI Blog、Anthropic Engineering、GitHub Repo | 直接引用，必须标注来源链接 |
| **L2 可信** | 知名媒体、行业报告、专家文章、投资人观点 | a16z 报告、TechCrunch、Karpathy 博客 | 交叉验证后引用，标注来源 |
| **L3 参考性** | 社区讨论、博客、评论、社交媒体 | Reddit、Medium、Twitter/X | 仅作趋势参考，不作为事实依据 |
| **L4 待验证** | 未公开信息、推测、假设、未来预测 | 内部消息、匿名爆料 | 明确标注"推测"或"待验证"，需说明依据 |
### 使用原则
1. **核心结论必须由 L1/L2 来源支撑**
2. **L3 来源仅用于补充视角，不单独支撑结论**
3. **L4 来源必须明确标注不确定性**
4. **所有引用必须保留原始链接**
---
## 三、分析流程（九步法）
```
步骤 1: 明确分析目标
└─ 输出: 分析问题定义
步骤 2: 信息收集
└─ 输出: 信息源清单（含可信度分级）
步骤 3: 概念定义
└─ 输出: 核心概念、术语溯源、工作定义
步骤 4: 问题诊断
└─ 输出: 问题清单、根因分析、优先级排序
步骤 5: 方案/组件分析
└─ 输出: 架构图、组件矩阵、技术选型建议
步骤 6: 案例研究
└─ 输出: 案例卡片、跨案例比较、最佳实践
步骤 7: 市场/竞争分析
└─ 输出: 市场规模、竞争格局、波特五力分析
步骤 8: 结论与建议
└─ 输出: 核心结论、趋势预测、行动建议
步骤 9: 多视角审视 ⭐ 质量保证
└─ 输出: 审视报告、补充建议、完善方案
```
---
## 四、各步骤方法论详解
### 步骤 1: 明确分析目标
**方法**: 5W1H 问题定义
```markdown
## 分析目标定义
### WHAT - 分析什么？
- 分析对象：
- 分析范围：
- 排除内容：
### WHY - 为什么分析？
- 决策需求：
- 受众是谁：
### WHO - 谁是受众？
- 技术专家 / 产品经理 / 投资人 / 高管
- 受众背景知识水平：
### WHEN - 时间要求？
- 分析截止时间：
- 数据时效要求：
### HOW - 如何输出？
- 输出形式：报告 / PPT / 备忘录
- 深度要求：概览 / 中等 / 深度
- 页数/字数要求：
```
---
### 步骤 2: 信息收集
**方法**: 三源验证法
**原则**: 每个关键事实至少需要 2 个独立来源验证
**信息源清单模板**:
```markdown
## 信息源清单
| # | 来源类型 | 来源名称 | URL/位置 | 可信度 | 覆盖内容 |
|---|---------|---------|----------|--------|---------|
| 1 | 官方文档 | OpenAI Blog | openai.com/blog | L1 | Harness 定义 |
| 2 | 技术博客 | Phil Schmid | philschmid.de | L2 | 架构分析 |
| 3 | 社区讨论 | Reddit | reddit.com/r/... | L3 | 用户反馈 |
```
---
### 步骤 3: 概念定义
**方法**: 文献综述 + 概念溯源法
**流程**:
1. **术语溯源**: 谁首先提出？最早出现在什么语境？
2. **概念演化**: 如何随时间演变？关键转折点？
3. **定义收敛**: 当前主流定义是什么？是否存在分歧？
4. **工作定义**: 用于本次分析的操作性定义
**输出模板**:
```markdown
## 概念定义
### 术语溯源
- 首次提出：
- 原始定义：
- 验证者：
### 定义演进
| 时间 | 定义 | 来源 |
|------|------|------|
| ... | ... | ... |
### 当前共识
- 主流定义：
- 存在争议：
### 工作定义
> [用于本次分析的定义]
```
---
### 步骤 4: 问题诊断
**方法**: 5 Why 根因分析法 + 问题-方案映射
**问题收集来源**:
- 官方技术报告中的失败案例
- 用户反馈和痛点
- 竞品对比中的差距
**5 Why 分析模板**:
```markdown
## 问题: [问题描述]
```
问题: ...
↓ Why 1: ...
↓ Why 2: ...
↓ Why 3: ...
↓ Why 4: ...
↓ Why 5 (根因): ...
```
**根因结论**: ...
```
**问题-方案映射矩阵**:
| 问题 | 严重度 | 方案 A | 方案 B | 方案 C | 推荐 |
|------|--------|--------|--------|--------|------|
| P1 | 🔴 | ❌ | ⚠️ | ✅ | C |
| P2 | 🟡 | ⚠️ | ✅ | ✅ | B |
---
### 步骤 5: 方案/组件分析
**方法**: 系统架构分析 + 决策框架
**组件分析模板**:
```markdown
## 组件: [名称]
**职责**: 一句话描述
**输入**: ...
**输出**: ...
**依赖**: ...
**实现方式**:
- 方式 A: ...
- 方式 B: ...
**选型考量**: ...
```
**技术选型矩阵**:
| 维度 | 方案 A | 方案 B | 方案 C |
|------|--------|--------|--------|
| 维度1 | 🟢/🟡/🔴 | ... | ... |
| 维度2 | ... | ... | ... |
**符号说明**: 🟢 优秀 / 🟡 一般 / 🔴 劣势
---
### 步骤 6: 案例研究
**方法**: 案例研究法 (Yin, 2018)
**案例选择标准**:
- 代表性：是否代表一类实践？
- 数据可获得性：是否有足够公开信息？
- 启发性：是否能提供独特洞察？
**案例分析框架**:
| 维度 | 分析内容 | 数据来源 |
|------|---------|---------|
| **背景** | 公司/团队、目标、约束 | 官方介绍 |
| **做法** | 具体实现、架构、流程 | 技术博客、代码 |
| **结果** | 量化指标、定性效果 | 官方数据 |
| **经验** | 关键决策、失败教训 | 技术分享 |
**跨案例比较**:
- 共性：共同的最佳实践
- 差异：不同场景的不同选择
- 模式：可复用的设计模式
---
### 步骤 7: 市场/竞争分析
**方法**: 市场研究 + 波特五力分析
**市场规模估算**:
- TAM (Total Addressable Market): 总潜在市场
- SAM (Serviceable Addressable Market): 可服务市场
- SOM (Serviceable Obtainable Market): 可获得市场
**竞争格局四象限图**:
```
[维度 A: 高]
│
│
[维度 B: 低]──┼──[维度 B: 高]
│
│
[维度 A: 低]
```
**波特五力分析**:
| 力量 | 强度 | 分析 |
|------|------|------|
| 供应商议价力 | 高/中/低 | ... |
| 买家议价力 | 高/中/低 | ... |
| 替代品威胁 | 高/中/低 | ... |
| 新进入者威胁 | 高/中/低 | ... |
| 同业竞争 | 高/中/低 | ... |
---
### 步骤 8: 结论与建议
**方法**: 趋势外推 + 情景分析
**趋势预测模板**:
| 趋势 | 当前状态 | 驱动因素 | 时间线 | 置信度 |
|------|---------|---------|--------|--------|
| ... | ... | ... | ... | 高/中/低 |
**情景分析**:
| 情景 | 概率 | 假设 | 结果 |
|------|------|------|------|
| 乐观 | X% | ... | ... |
| 基准 | Y% | ... | ... |
| 悲观 | Z% | ... | ... |
**行动建议**:
| 角色 | 优先级 | 建议 | 时间线 |
|------|--------|------|--------|
| 开发者 | P0 | ... | 立即 |
| 产品 | P1 | ... | 1周内 |
| CTO | P2 | ... | 1月内 |
---
### 步骤 9: 多视角审视 ⭐ 质量保证
**方法**: 多视角审视法
**目的**: 从不同利益相关者角度审视方案，发现遗漏、补充视角、完善内容
**核心视角**:
| 视角 | 关注点 | 核心问题 |
|------|--------|---------|
| **CTO/技术负责人** | 技术架构、工程实践、技术选型 | "技术可行吗？技术债务风险？" |
| **产品VP/产品负责人** | 用户需求、产品化、商业化 | "用户需要吗？能产品化吗？" |
| **CEO/投资人** | 市场机会、竞争格局、投资价值 | "市场够大吗？值得投资吗？" |
**扩展视角**:
| 视角 | 关注点 | 适用场景 |
|------|--------|---------|
| **安全专家** | 安全风险、合规要求 | 涉及数据/隐私场景 |
| **用户/客户** | 使用体验、实际痛点 | 面向用户的产品 |
| **竞争对手** | 竞争威胁、差异化 | 竞争激烈的市场 |
| **监管者** | 合规风险、政策影响 | 金融/医疗/政务 |
| **运维团队** | 可维护性、监控告警 | 生产级系统 |
**审视流程**:
```
1. 选择审视视角（3-5 个）
└─ 核心：CTO, 产品VP, CEO
└─ 按需扩展：安全/用户/竞争对手/监管/运维
2. 填写审视矩阵
└─ 每个视角评估各章节覆盖度
└─ 识别缺失内容和补充建议
3. 汇总发现
└─ 按优先级排序：P0（必须）/ P1（建议）/ P2（可选）
4. 完善方案
└─ 将 P0 补充内容整合到方案
```
**审视矩阵模板**:
```markdown
## 视角: [角色]
| 章节 | 覆盖度 | 缺失内容 | 建议补充 |
|------|--------|---------|---------|
| Part 1 | ✅/⚠️/❌ | ... | ... |
| Part 2 | ✅/⚠️/❌ | ... | ... |
```
**关联 Skill**: 详细审视方法见 `multi-perspective-review` skill
---
## 五、输出标准结构
每个分析章节必须包含以下结构：
```markdown
## [章节标题]
### 核心结论（一句话）
> ...（用一句话概括本章节最重要的结论）
### 论据支撑
1. **来源**：...
2. **数据**：...
3. **分析**：...
4. **结论**：...
### 不确定性说明
- **已知**：...
- **未知**：...
- **假设**：...
### 来源引用
- [1] 来源名称, URL, [可信度]
```
---
## 六、质量检查清单
### 分析前检查
- [ ] 明确了分析目标和受众
- [ ] 定义了分析范围和排除内容
- [ ] 收集了足够的 L1/L2 来源
- [ ] 制定了输出格式要求
### 分析中检查
- [ ] 每个核心结论有 ≥2 个独立来源支持
- [ ] 区分了事实和观点
- [ ] 标注了所有来源的可信度级别
- [ ] 记录了不确定性和假设
### 分析后检查
- [ ] 交叉验证了关键数据
- [ ] 检查了逻辑一致性
- [ ] 完成了可读性审查
- [ ] 补充了所有来源引用
---
## 七、常用信息源目录
### 官方来源 (L1)
| 类型 | 来源 | URL |
|------|------|-----|
| AI 厂商官方博客 | OpenAI Blog | openai.com/blog |
| AI 厂商官方博客 | Anthropic Engineering | anthropic.com/engineering |
| AI 厂商官方博客 | Google AI Blog | ai.googleblog.com |
| AI 厂商官方博客 | Meta AI Blog | ai.meta.com/blog |
| 技术专家博客 | Mitchell Hashimoto | mitchellh.com |
| 技术专家博客 | Phil Schmid | philschmid.de |
| 代码仓库 | GitHub | github.com |
| 论文预印本 | arXiv | arxiv.org |
### 行业报告 (L2)
| 类型 | 来源 | URL |
|------|------|-----|
| 投资机构报告 | a16z | a16z.com |
| 投资机构报告 | Sequoia | sequoiacap.com |
| 行业分析 | Gartner | gartner.com |
| 行业分析 | LangChain | langchain.com |
| 技术媒体 | TechCrunch | techcrunch.com |
| 技术媒体 | The Verge | theverge.com |
### 社区讨论 (L3)
| 类型 | 来源 | URL |
|------|------|-----|
| 技术社区 | Reddit r/MachineLearning | reddit.com/r/MachineLearning |
| 技术社区 | Reddit r/LocalLLaMA | reddit.com/r/LocalLLaMA |
| 技术社区 | Hacker News | news.ycombinator.com |
| 社交媒体 | Twitter/X AI 圈 | - |
| 博客平台 | Medium | medium.com |
---
## 八、分析视角切换
不同角色关注点不同，分析时应考虑多视角：
| 视角 | 关注点 | 分析重点 |
|------|--------|---------|
| **CTO/技术负责人** | 技术架构、工程实践、技术选型 | 架构模式、技术债务、性能基准 |
| **产品VP/产品负责人** | 用户需求、产品化、商业化 | 用户痛点、ROI量化、产品路线图 |
| **CEO/投资人** | 市场机会、竞争格局、投资价值 | 市场规模、竞争态势、风险评估 |
**建议**: 复杂分析应至少覆盖 2-3 个视角。
---
## 九、模板文件位置
| 模板 | 路径 | 用途 |
|------|------|------|
| 分析目标定义模板 | templates/analysis-goal.md | 步骤1 |
| 信息源清单模板 | templates/source-list.md | 步骤2 |
| 概念定义模板 | templates/concept-definition.md | 步骤3 |
| 问题诊断模板 | templates/problem-diagnosis.md | 步骤4 |
| 案例分析模板 | templates/case-study.md | 步骤6 |
| 完整报告模板 | templates/full-report.md | 综合 |
---
## 十、持续改进
### 改进来源
1. **用户反馈**: 分析报告的使用反馈
2. **同行评审**: 其他专家的评审意见
3. **复盘总结**: 每次分析后的经验总结
### 改进流程
1. 发现问题/改进机会
2. 记录到 `self-improving/technical-analysis.md`
3. 更新本 SKILL.md 或相关模板
4. 通知相关使用方
---
## 使用示例
### 调用方式
```
用户: 帮我深度分析 [技术名称]
AI 行为:
1. 读取本 SKILL.md
2. 按照"八步法"执行分析
3. 使用信息可信度分级
4. 输出标准结构的报告
5. 完成质量检查清单
```
### 输出目录结构
```
WORK/TOPIC分析/[主题名称]/
├── 分析目标定义.md
├── 信息源清单.md
├── 深度分析报告.md
├── 附录/
│ └── 数据来源/
└── 检查清单.md
```
---
*版本: 1.0 | 创建: 2026-04-14 | 维护: self-improving/technical-analysis.md*
don't have the plugin yet? install it then click "run inline in claude" again.