# Technology Insight

> 对一个新技术、模型、框架、系统、协议、算子、硬件或开源项目进行证据驱动的技术洞察。用于技术全景扫描、技术雷达、竞品与标杆分析、代码和架构逆向、新旧技术冲击分析、Demo/PoC/基准实验、瓶颈与演进分析、成熟度/生态/成本/风险评估、技术选型、技术尽调、横向比较表和 Go/No-Go/Trial 建议。用户要求“深入比较”“新技术会替代什么”“做个 Demo 验证”“拉表格选型”“不要只汇总资料”时使用。

- Skill: `kirrito-k423/technology-insight` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add kirrito-k423/technology-insight`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kirrito-k423/technology-insight/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Kirrito-k423 (https://skillmd.com/u/kirrito-k423)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/kirrito-k423/technology-insight

---


# 技术洞察

## 目标

把“最近出现了什么新技术”转成一个**有证据、可证伪、能行动的技术判断**。最终回答：

1. 新技术解决了旧方案的哪个具体瓶颈？
2. 它改变、替代、保留或下沉了哪些技术对象？
3. 优势依赖哪些模型、数据、硬件、软件、组织和商业前提？
4. Demo、代码、基准和生产证据分别证明了什么，尚未证明什么？
5. 采用后瓶颈、成本和风险会转移到哪里？
6. 当前应 Adopt、Trial、Assess、Hold、Reject，还是与旧方案长期共存？

技术洞察不是资料数量竞赛。**没有决策问题、比较基线、证据边界和行动建议的材料，只是资料汇总。**

## 核心原则

1. **先定义决策，再搜资料。**把“介绍某技术”改写成有对象、场景、期限和选择的决策问题。
2. **先建立旧技术基线，再谈冲击。**没有 Baseline，就无法判断新技术消除了什么、又新增了什么。
3. **事实、推论和建议分开。**每个重要判断标注来源、版本、证据等级、置信度和适用边界。
4. **先理解机制，再比较结果。**功能表和排行榜不能解释差异来自架构、实现、硬件还是测试口径。
5. **先做最小实验，再扩大投入。**只运行能改变决策的实验；Demo 跑通后再进入受控 Benchmark。
6. **比较必须同口径。**模型、数据、硬件、精度、并行、版本、预热、统计窗口不同就标记“不可直接比较”。
7. **结论包含代价。**任何收益都要对应迁移、算力、内存、通信、稳定性、人才、运维、锁定或机会成本。
8. **新技术不天然淘汰旧技术。**同时检查替代、互补、封装、基础设施化、瓶颈迁移和长期共存。

## 选择工作深度

按用户的决策和证据需求选择深度，不机械执行全部步骤。

| 模式 | 适用情况 | 最小交付 |
|---|---|---|
| **扫描** | 了解版图、趋势和候选 | 技术地图、候选清单、证据账本、待验证问题 |
| **比较** | 在多个候选中选型 | 统一比较合同、机制卡、横向表、条件式建议 |
| **验证** | 关键事实不确定，需要动手 | Demo/PoC、可复现实验记录、结果表、失败样本 |
| **尽调** | 影响长期架构或重大投入 | 扫描 + 代码逆向 + 基准 + 成熟度 + TCO + 风险 + 决策备忘录 |

若用户没有指定，默认执行“比较”；只有未知会实质改变结论时才进入“验证”。

## 阶段一：冻结问题与边界

开始调查前，读取并填写 [`references/analysis-contract.md`](references/analysis-contract.md) 的决策合同。

至少明确：

- **决策**：要决定采用、试点、迁移、投资、集成、观望还是淘汰什么；
- **对象**：新技术、现有 Baseline、候选和明确排除项；
- **场景**：真实用户、工作负载、数据、SLA、合规和失败后果；
- **约束**：硬件、预算、时间、人才、兼容性、供应链和部署环境；
- **时间窗**：回答“现在”“一年内”还是“长期”；
- **验收**：什么证据会改变决策，何时停止继续研究。

若用户只给出一个技术名称，先用最保守的默认问题推进：

```text
在当前工作区所代表的用户、硬件和组织条件下，
该新技术相对现有主流方案解决了什么瓶颈，代价是什么，
是否值得进入一个有退出条件的最小试点？
```

## 阶段二：建立证据账本

优先使用以下证据，且固定来源版本：

1. 本地代码、配置、测试和运行记录；
2. 官方规范、标准、文档、仓库、版本说明和设计提案；
3. 原始论文、官方项目页和补充材料；
4. 可复现的独立实验与公开基准；
5. 高质量二手分析；
6. 厂商宣传、社区讨论和搜索摘要仅作为线索。

对代码结论记录仓库、提交、文件、符号和行范围；对性能数字记录模型、数据、硬件、精度、软件版本、并行配置和统计口径。当前信息或用户要求调研时必须联网核验；技术问题只依赖一手或官方来源形成核心结论。

维护证据账本：

| 判断 | 来源/版本 | 证据等级 | 事实/推论 | 置信度 | 适用边界 | 待验证 |
|---|---|---|---|---|---|---|

如果工作区有 `.codegraph/`，定位代码和调用关系前优先使用 CodeGraph。否则先用 `rg` 定位，再读取最小必要上下文。

## 阶段三：扫描技术全景

按决策问题裁剪扫描轴：

- 核心问题与技术路线；
- 代表性框架、项目、厂商和产品；
- 开源社区、治理、许可证与维护者集中度；
- 论文、专利、标准、接口和互操作性；
- 芯片、内存、网络、存储和编译/runtime 前提；
- 用户采用、生产案例、人才和服务供给；
- 版本节奏、兼容策略、事故与弃用历史。

输出至少包含：

1. **技术地图**：对象之间的层级、依赖和替代关系；
2. **演进时间线**：旧瓶颈、关键事件、路线转折和未解决问题；
3. **生态矩阵**：维护、采用、工具链、互操作、安全和供应商风险；
4. **行动雷达**：Assess、Trial、Adopt、Hold 或 Reject，并写明进入与退出条件。

Radar 状态是当前组织的行动建议，不是全行业真理。没有实际使用证据时，不把候选直接放入 Adopt。

## 阶段四：建立 Baseline 与冲击链

先为 Baseline 与新技术分别写机制卡：

| 字段 | 要回答的问题 |
|---|---|
| 目标瓶颈 | 原系统哪个对象、阶段或约束导致问题？ |
| 核心机制 | 新技术改变了什么数据、控制、资源、边界或所有权？ |
| 保留对象 | 哪些模块、接口、数据、能力和运维流程不变？ |
| 替代对象 | 哪些组件、路径、角色或商业环节被移除或弱化？ |
| 新增对象 | 新增哪些状态、服务、缓存、协议、依赖或专业能力？ |
| 新瓶颈 | 性能、可靠性、成本或组织约束转移到了哪里？ |
| 适用条件 | 模型、数据、规模、硬件、拓扑、精度、团队和合规前提是什么？ |
| 迁移路径 | 需要改哪些接口、数据、工具、人才和运行流程？ |
| 证据边界 | 当前由文档、代码、Demo、基准还是生产证明？ |

把冲击归入一个或多个类型：

- **直接替代**：新技术承担同一职责，旧组件可退出关键路径；
- **互补增强**：保留旧系统，仅增强某个局部能力；
- **重新封装**：底层能力相近，但接口、交付或运维边界改变；
- **基础设施化**：原本差异化的能力变成普遍可用的底座；
- **瓶颈迁移**：解除旧约束后，其他资源或组织流程成为主约束；
- **生态重分配**：价值、人才、利润或控制权转移到新的层级或厂商。

必须写一个反事实：**如果不采用该技术，Baseline 还能通过哪些优化达到目标？**这能防止把正常迭代误判成代际替代。

## 阶段五：代码与架构逆向

对开源或可访问实现执行以下顺序：

1. 固定提交、构建方式、依赖锁文件和许可证；
2. 找到真实入口、核心抽象和配置开关；
3. 追踪数据流、控制流、资源流和错误流；
4. 识别数据结构、生命周期、并发/调度、容错和扩展点；
5. 标出性能关键路径、跨进程/设备边界和同步点；
6. 对照文档，记录实现缺口、默认值和兼容分支；
7. 用最小测试或运行日志验证关键调用链。

区分四类证据：

- 代码存在：只能证明某版本包含实现；
- 测试存在：只能证明特定断言被覆盖；
- Demo 跑通：只能证明指定环境的最小路径可执行；
- 生产/基准证据：只在披露的负载与环境范围内支持效果判断。

不要用 README 的功能声明替代真实调用路径，也不要因代码复杂就自动判定设计较差；说明复杂度来自兼容、性能、通用性还是历史负担。

## 阶段六：设计并运行 Demo、PoC 与 Benchmark

任何实验前必须读取 [`references/experiment-and-benchmark.md`](references/experiment-and-benchmark.md)。

先区分目的：

- **Demo**：证明最小端到端路径能运行；
- **PoC**：验证一个会改变选型的关键假设；
- **Benchmark**：在统一合同下比较性能、质量、资源和稳定性；
- **Stress/Failure Test**：寻找容量、可靠性和恢复边界。

按“信息价值/成本”选择实验。每次实验只回答一个主问题，并固定：

- 模型、数据集、样本分布和随机种子；
- 硬件、拓扑、功耗模式和后台负载；
- OS、驱动、编译器、Runtime、框架和候选版本；
- 并行策略、Batch Size、精度、缓存和预热；
- 重复次数、测量窗口、超时、异常样本和失败判定；
- 质量门槛、SLA、统计量与日志/Profiler 证据。

指标不要只留吞吐。按场景选择：

- p50/p95/p99 时延、首结果时间和稳态吞吐；
- 峰值/稳态内存、通信量、I/O、CPU/GPU/NPU 利用率和能耗；
- 精度、任务质量、数值误差和失败率；
- 冷启动、抖动、扩展效率、恢复时间和长稳时间；
- 集成工时、代码改动、学习成本、运维复杂度和单位业务成本。

保留原始结果、命令、配置、日志、Profiler 文件、失败样本和结果解析逻辑。结果不支持原假设时修改判断，不修改数据。

若预计运行超过 20 分钟，遵循当前仓库的费用监控规则；在本仓库默认使用 `rmb-cost-report` 并更新 `RMB-Cost.md`。涉及付费 API、生产环境变更、敏感数据上传或超出用户已授权范围的远程资源时，先取得明确授权。

## 阶段七：定位瓶颈

先量化端到端时间和资源占比，再选择工具：

| 问题 | 首选方法 | 不能单独证明 |
|---|---|---|
| 时间耗在哪里 | Trace、Profiler、火焰图、关键路径 | 硬件理论上限与业务价值 |
| 内核受何约束 | Roofline、硬件计数器 | 端到端服务收益 |
| 局部优化能带来多少整体收益 | Amdahl 风格分解 | 负载变化后的新瓶颈 |
| 并发等待为何增长 | 排队模型、到达/服务/队列指标 | 单个请求内部关键路径 |
| 通信是否隐藏 | 通信—计算时间线、依赖与同步事件 | 无依赖条件下的可实现重叠 |
| 内存为何峰值 | 对象大小、分配/最后使用/释放的生命周期 | 分配器保留与碎片的全部行为 |

训练或推理系统可按数据加载、Host 处理、传输、前向、通信、反向、优化器、保存/加载、调度和排队拆分。优化后重新 Profiling，确认瓶颈是否迁移；不要继续优化已经不在关键路径上的部分。

## 阶段八：评估演进、成熟度与生态

演进分析回答：

1. 过去方案解决了什么问题，为什么在当时成立？
2. 当前主流路线靠什么硬件、数据、标准或生态前提形成？
3. 新方案消除了哪个旧瓶颈，又引入什么新成本？
4. 哪些能力会被替代、被封装、成为底座或长期共存？
5. 哪个未来事件会推翻当前判断？

成熟度使用多轴矩阵，不使用单一总分替代解释：

- 理论与原理证据；
- 原型与相关环境证据；
- 工程完整性和性能稳定性；
- 文档、测试、工具链和可观测性；
- 社区健康、治理和维护者集中度；
- 用户采用、生产案例和服务供给；
- 安全、合规、供应链和许可证；
- 人才、迁移与长期维护能力。

TRL、CNCF 阶段、CHAOSS 指标和 OpenSSF Scorecard 只能作为对应轴的证据。明确它们未覆盖的维度。

## 阶段九：计算全生命周期成本与风险

读取 [`references/report-template.md`](references/report-template.md) 中的成本与风险表。

成本至少覆盖：

- 研发、集成、测试和迁移人力；
- 学习、招聘和关键人员依赖；
- 硬件、云、许可证和外部服务；
- 数据准备、兼容、观测、运维和故障处置；
- 升级、回滚、双栈共存和退出；
- 供应商锁定、机会成本和不可逆投入。

风险按“触发条件—失效模式—影响—现有控制—可探测性—处置—Owner—验证”记录。可按场景选择风险矩阵、FMEA、故障树、威胁建模或 Premortem。

使用 FMEA 时，不把 `严重度 × 发生概率 × 可探测性` 的 RPN 当作唯一排序真理；同时保留高严重度低概率项、共同原因、不可探测风险和矩阵/行动优先级。AI 技术另检查数据代表性、质量漂移、滥用、隐私、安全、透明度、人机责任和供应链风险。

## 阶段十：横向综合与结论

先逐个讲清候选机制，再拉横向表。禁止让一张功能表替代机制、前提和证据解释。

至少提供三张表：

1. **冲击表**：替代、保留、新增、新瓶颈、迁移条件；
2. **实验表**：统一环境、质量、性能、资源、稳定性和成本结果；
3. **决策表**：适用场景、成熟度、TCO、风险、证据等级和行动建议。

如果用户没有提供偏好权重，不擅自用加权总分制造精确排名。可以给硬约束、优势前沿、主导/被主导关系和条件式建议。确需加权时，说明权重来源并做权重敏感性分析。

最终结论采用以下之一：

- **Adopt**：在目标场景已有充分证据，可作为默认选项；
- **Trial**：关键假设已通过 PoC，进入有范围和退出条件的试点；
- **Assess**：方向相关，但证据或适配仍不足，继续研究指定未知；
- **Hold**：当前不新增采用，保留既有系统或等待触发条件；
- **Reject**：在明确硬约束下不适用；
- **Coexist**：新旧技术在不同场景或层级长期互补。

每个结论同时写：适用场景、反例、置信度、触发复审的事件、下一步 Owner 和截止条件。

## 交付与文件组织

用户只要聊天回答时，不强制创建文件。用户要求报告、实验或长期沉淀时，优先沿用仓库现有约定；没有约定时使用：

```text
technology-insight/<topic-slug>/
  TECHNOLOGY-INSIGHT.md
  evidence-ledger.md
  source-pins.md
  comparison-matrix.md
  experiment-plan.md
  demo/
  results/
  risk-register.md
```

不要提交大型临时环境、依赖缓存、凭据、私有数据或不可解释的二进制结果。提交、推送、开 PR、部署或发布必须由用户明确授权或由已启用的上层工作流明确授权。

## 完成门禁

交付前逐项检查：

- [ ] 决策问题、Baseline、候选、场景、约束和时间窗明确；
- [ ] 核心结论可追到一手来源、固定代码或可复现实验；
- [ ] 事实、推论、建议和未知分开；
- [ ] 每个候选说明机制、成立前提、保留/替代/新增对象和新瓶颈；
- [ ] Demo、PoC、Benchmark、生产证据没有混用；
- [ ] 横向数字具备同模型、数据、硬件、精度、版本和统计口径；
- [ ] 不可比结果明确标记，不制造伪排名；
- [ ] 瓶颈分析覆盖端到端关键路径并检查优化后的瓶颈迁移；
- [ ] 成熟度、生态、成本和风险没有被单一分数代替；
- [ ] 结论包含适用边界、反例、置信度、退出条件和复审触发器；
- [ ] 新增代码或脚本已运行验证，失败样本和限制已保留；
- [ ] 文件、外部操作和费用均未超出用户授权范围。