Technical Deep Analysis
by @vincentlau2046-sudo
技术深度分析方法论。用于对新兴技术、技术趋势、技术产品进行系统化深度分析。 当需要分析新技术、写技术报告、做竞品分析、评估投资机会时使用此 skill。 触发词：深度分析、技术分析、竞品分析、技术报告、行业分析。
clawhub install technical-deep-analysis📖 About This 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 问题定义
## 分析目标定义WHAT - 分析什么？
分析对象：
分析范围：
排除内容： WHY - 为什么分析？
决策需求：
受众是谁： WHO - 谁是受众？
技术专家 / 产品经理 / 投资人 / 高管
受众背景知识水平： WHEN - 时间要求？
分析截止时间：
数据时效要求： HOW - 如何输出？
输出形式：报告 / PPT / 备忘录
深度要求：概览 / 中等 / 深度
页数/字数要求：
步骤 2: 信息收集
方法: 三源验证法
原则: 每个关键事实至少需要 2 个独立来源验证
信息源清单模板:
## 信息源清单| # | 来源类型 | 来源名称 | 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. 工作定义: 用于本次分析的操作性定义
输出模板:
## 概念定义术语溯源
首次提出：
原始定义：
验证者： 定义演进
| 时间 | 定义 | 来源 |
|------|------|------|
| ... | ... | ... |当前共识
主流定义：
存在争议： 工作定义
> [用于本次分析的定义]
步骤 4: 问题诊断
方法: 5 Why 根因分析法 + 问题-方案映射
问题收集来源:
5 Why 分析模板:
## 问题: [问题描述]
根因结论: ...
问题-方案映射矩阵:
| 问题 | 严重度 | 方案 A | 方案 B | 方案 C | 推荐 | |------|--------|--------|--------|--------|------| | P1 | 🔴 | ❌ | ⚠️ | ✅ | C | | P2 | 🟡 | ⚠️ | ✅ | ✅ | B |
步骤 5: 方案/组件分析
方法: 系统架构分析 + 决策框架
组件分析模板:
## 组件: [名称]职责: 一句话描述
输入: ...
输出: ...
依赖: ...
实现方式:
方式 A: ...
方式 B: ...
选型考量: ...
技术选型矩阵:
| 维度 | 方案 A | 方案 B | 方案 C | |------|--------|--------|--------| | 维度1 | 🟢/🟡/🔴 | ... | ... | | 维度2 | ... | ... | ... |
符号说明: 🟢 优秀 / 🟡 一般 / 🔴 劣势
步骤 6: 案例研究
方法: 案例研究法 (Yin, 2018)
案例选择标准:
案例分析框架:
| 维度 | 分析内容 | 数据来源 | |------|---------|---------| | 背景 | 公司/团队、目标、约束 | 官方介绍 | | 做法 | 具体实现、架构、流程 | 技术博客、代码 | | 结果 | 量化指标、定性效果 | 官方数据 | | 经验 | 关键决策、失败教训 | 技术分享 |
跨案例比较:
步骤 7: 市场/竞争分析
方法: 市场研究 + 波特五力分析
市场规模估算:
竞争格局四象限图:
[维度 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 补充内容整合到方案
审视矩阵模板:
## 视角: [角色]| 章节 | 覆盖度 | 缺失内容 | 建议补充 |
|------|--------|---------|---------|
| Part 1 | ✅/⚠️/❌ | ... | ... |
| Part 2 | ✅/⚠️/❌ | ... | ... |
关联 Skill: 详细审视方法见 multi-perspective-review skill
五、输出标准结构
每个分析章节必须包含以下结构：
## [章节标题]核心结论（一句话）
> ...（用一句话概括本章节最重要的结论）论据支撑
1. 来源：...
2. 数据：...
3. 分析：...
4. 结论：...不确定性说明
已知：...
未知：...
假设：... 来源引用
[1] 来源名称, URL, [可信度]
六、质量检查清单
分析前检查
分析中检查
分析后检查
七、常用信息源目录
官方来源 (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*