Skill: vincentlau2046-sudo/technical-deep-analysis (version 1.0.0)

--- 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*


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)