Kirrito-k423 技术洞察
目标
把“最近出现了什么新技术”转成一个有证据、可证伪、能行动的技术判断。最终回答：
- 新技术解决了旧方案的哪个具体瓶颈？
- 它改变、替代、保留或下沉了哪些技术对象？
- 优势依赖哪些模型、数据、硬件、软件、组织和商业前提？
- Demo、代码、基准和生产证据分别证明了什么，尚未证明什么？
- 采用后瓶颈、成本和风险会转移到哪里？
- 当前应 Adopt、Trial、Assess、Hold、Reject，还是与旧方案长期共存？
技术洞察不是资料数量竞赛。没有决策问题、比较基线、证据边界和行动建议的材料，只是资料汇总。
核心原则
- **先定义决策，再搜资料。**把“介绍某技术”改写成有对象、场景、期限和选择的决策问题。
- **先建立旧技术基线，再谈冲击。**没有 Baseline，就无法判断新技术消除了什么、又新增了什么。
- **事实、推论和建议分开。**每个重要判断标注来源、版本、证据等级、置信度和适用边界。
- **先理解机制，再比较结果。**功能表和排行榜不能解释差异来自架构、实现、硬件还是测试口径。
- **先做最小实验，再扩大投入。**只运行能改变决策的实验；Demo 跑通后再进入受控 Benchmark。
- **比较必须同口径。**模型、数据、硬件、精度、并行、版本、预热、统计窗口不同就标记“不可直接比较”。
- **结论包含代价。**任何收益都要对应迁移、算力、内存、通信、稳定性、人才、运维、锁定或机会成本。
- **新技术不天然淘汰旧技术。**同时检查替代、互补、封装、基础设施化、瓶颈迁移和长期共存。
选择工作深度
按用户的决策和证据需求选择深度，不机械执行全部步骤。
| 模式 | 适用情况 | 最小交付 |
|---|---|---|
| 扫描 | 了解版图、趋势和候选 | 技术地图、候选清单、证据账本、待验证问题 |
| 比较 | 在多个候选中选型 | 统一比较合同、机制卡、横向表、条件式建议 |
| 验证 | 关键事实不确定，需要动手 | Demo/PoC、可复现实验记录、结果表、失败样本 |
| 尽调 | 影响长期架构或重大投入 | 扫描 + 代码逆向 + 基准 + 成熟度 + TCO + 风险 + 决策备忘录 |
若用户没有指定，默认执行“比较”；只有未知会实质改变结论时才进入“验证”。
阶段一：冻结问题与边界
开始调查前，读取并填写 references/analysis-contract.md 的决策合同。
至少明确：
- 决策：要决定采用、试点、迁移、投资、集成、观望还是淘汰什么；
- 对象：新技术、现有 Baseline、候选和明确排除项；
- 场景：真实用户、工作负载、数据、SLA、合规和失败后果；
- 约束：硬件、预算、时间、人才、兼容性、供应链和部署环境；
- 时间窗：回答“现在”“一年内”还是“长期”；
- 验收：什么证据会改变决策，何时停止继续研究。
若用户只给出一个技术名称，先用最保守的默认问题推进：
在当前工作区所代表的用户、硬件和组织条件下，
该新技术相对现有主流方案解决了什么瓶颈，代价是什么，
是否值得进入一个有退出条件的最小试点？
阶段二：建立证据账本
优先使用以下证据，且固定来源版本：
- 本地代码、配置、测试和运行记录；
- 官方规范、标准、文档、仓库、版本说明和设计提案；
- 原始论文、官方项目页和补充材料；
- 可复现的独立实验与公开基准；
- 高质量二手分析；
- 厂商宣传、社区讨论和搜索摘要仅作为线索。
对代码结论记录仓库、提交、文件、符号和行范围；对性能数字记录模型、数据、硬件、精度、软件版本、并行配置和统计口径。当前信息或用户要求调研时必须联网核验；技术问题只依赖一手或官方来源形成核心结论。
维护证据账本：
| 判断 | 来源/版本 | 证据等级 | 事实/推论 | 置信度 | 适用边界 | 待验证 |
|---|
如果工作区有 .codegraph/，定位代码和调用关系前优先使用 CodeGraph。否则先用 rg 定位，再读取最小必要上下文。
阶段三：扫描技术全景
按决策问题裁剪扫描轴：
- 核心问题与技术路线；
- 代表性框架、项目、厂商和产品；
- 开源社区、治理、许可证与维护者集中度；
- 论文、专利、标准、接口和互操作性；
- 芯片、内存、网络、存储和编译/runtime 前提；
- 用户采用、生产案例、人才和服务供给；
- 版本节奏、兼容策略、事故与弃用历史。
输出至少包含：
- 技术地图：对象之间的层级、依赖和替代关系；
- 演进时间线：旧瓶颈、关键事件、路线转折和未解决问题；
- 生态矩阵：维护、采用、工具链、互操作、安全和供应商风险；
- 行动雷达：Assess、Trial、Adopt、Hold 或 Reject，并写明进入与退出条件。
Radar 状态是当前组织的行动建议，不是全行业真理。没有实际使用证据时，不把候选直接放入 Adopt。
阶段四：建立 Baseline 与冲击链
先为 Baseline 与新技术分别写机制卡：
| 字段 | 要回答的问题 |
|---|---|
| 目标瓶颈 | 原系统哪个对象、阶段或约束导致问题？ |
| 核心机制 | 新技术改变了什么数据、控制、资源、边界或所有权？ |
| 保留对象 | 哪些模块、接口、数据、能力和运维流程不变？ |
| 替代对象 | 哪些组件、路径、角色或商业环节被移除或弱化？ |
| 新增对象 | 新增哪些状态、服务、缓存、协议、依赖或专业能力？ |
| 新瓶颈 | 性能、可靠性、成本或组织约束转移到了哪里？ |
| 适用条件 | 模型、数据、规模、硬件、拓扑、精度、团队和合规前提是什么？ |
| 迁移路径 | 需要改哪些接口、数据、工具、人才和运行流程？ |
| 证据边界 | 当前由文档、代码、Demo、基准还是生产证明？ |
把冲击归入一个或多个类型：
- 直接替代：新技术承担同一职责，旧组件可退出关键路径；
- 互补增强：保留旧系统，仅增强某个局部能力；
- 重新封装：底层能力相近，但接口、交付或运维边界改变；
- 基础设施化：原本差异化的能力变成普遍可用的底座；
- 瓶颈迁移：解除旧约束后，其他资源或组织流程成为主约束；
- 生态重分配：价值、人才、利润或控制权转移到新的层级或厂商。
必须写一个反事实：**如果不采用该技术，Baseline 还能通过哪些优化达到目标？**这能防止把正常迭代误判成代际替代。
阶段五：代码与架构逆向
对开源或可访问实现执行以下顺序：
- 固定提交、构建方式、依赖锁文件和许可证；
- 找到真实入口、核心抽象和配置开关；
- 追踪数据流、控制流、资源流和错误流；
- 识别数据结构、生命周期、并发/调度、容错和扩展点；
- 标出性能关键路径、跨进程/设备边界和同步点；
- 对照文档，记录实现缺口、默认值和兼容分支；
- 用最小测试或运行日志验证关键调用链。
区分四类证据：
- 代码存在：只能证明某版本包含实现；
- 测试存在：只能证明特定断言被覆盖；
- Demo 跑通：只能证明指定环境的最小路径可执行；
- 生产/基准证据：只在披露的负载与环境范围内支持效果判断。
不要用 README 的功能声明替代真实调用路径，也不要因代码复杂就自动判定设计较差；说明复杂度来自兼容、性能、通用性还是历史负担。
阶段六：设计并运行 Demo、PoC 与 Benchmark
任何实验前必须读取 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，确认瓶颈是否迁移；不要继续优化已经不在关键路径上的部分。
阶段八：评估演进、成熟度与生态
演进分析回答：
- 过去方案解决了什么问题，为什么在当时成立？
- 当前主流路线靠什么硬件、数据、标准或生态前提形成？
- 新方案消除了哪个旧瓶颈，又引入什么新成本？
- 哪些能力会被替代、被封装、成为底座或长期共存？
- 哪个未来事件会推翻当前判断？
成熟度使用多轴矩阵，不使用单一总分替代解释：
- 理论与原理证据；
- 原型与相关环境证据；
- 工程完整性和性能稳定性；
- 文档、测试、工具链和可观测性；
- 社区健康、治理和维护者集中度；
- 用户采用、生产案例和服务供给；
- 安全、合规、供应链和许可证；
- 人才、迁移与长期维护能力。
TRL、CNCF 阶段、CHAOSS 指标和 OpenSSF Scorecard 只能作为对应轴的证据。明确它们未覆盖的维度。
阶段九：计算全生命周期成本与风险
读取 references/report-template.md 中的成本与风险表。
成本至少覆盖：
- 研发、集成、测试和迁移人力；
- 学习、招聘和关键人员依赖；
- 硬件、云、许可证和外部服务；
- 数据准备、兼容、观测、运维和故障处置；
- 升级、回滚、双栈共存和退出；
- 供应商锁定、机会成本和不可逆投入。
风险按“触发条件—失效模式—影响—现有控制—可探测性—处置—Owner—验证”记录。可按场景选择风险矩阵、FMEA、故障树、威胁建模或 Premortem。
使用 FMEA 时，不把 严重度 × 发生概率 × 可探测性 的 RPN 当作唯一排序真理；同时保留高严重度低概率项、共同原因、不可探测风险和矩阵/行动优先级。AI 技术另检查数据代表性、质量漂移、滥用、隐私、安全、透明度、人机责任和供应链风险。
阶段十：横向综合与结论
先逐个讲清候选机制，再拉横向表。禁止让一张功能表替代机制、前提和证据解释。
至少提供三张表：
- 冲击表：替代、保留、新增、新瓶颈、迁移条件；
- 实验表：统一环境、质量、性能、资源、稳定性和成本结果；
- 决策表：适用场景、成熟度、TCO、风险、证据等级和行动建议。
如果用户没有提供偏好权重，不擅自用加权总分制造精确排名。可以给硬约束、优势前沿、主导/被主导关系和条件式建议。确需加权时，说明权重来源并做权重敏感性分析。
最终结论采用以下之一：
- Adopt：在目标场景已有充分证据，可作为默认选项；
- Trial：关键假设已通过 PoC，进入有范围和退出条件的试点；
- Assess：方向相关，但证据或适配仍不足，继续研究指定未知；
- Hold：当前不新增采用，保留既有系统或等待触发条件；
- Reject：在明确硬约束下不适用；
- Coexist：新旧技术在不同场景或层级长期互补。
每个结论同时写：适用场景、反例、置信度、触发复审的事件、下一步 Owner 和截止条件。
交付与文件组织
用户只要聊天回答时，不强制创建文件。用户要求报告、实验或长期沉淀时，优先沿用仓库现有约定；没有约定时使用：
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、生产证据没有混用；
- 横向数字具备同模型、数据、硬件、精度、版本和统计口径；
- 不可比结果明确标记，不制造伪排名；
- 瓶颈分析覆盖端到端关键路径并检查优化后的瓶颈迁移；
- 成熟度、生态、成本和风险没有被单一分数代替；
- 结论包含适用边界、反例、置信度、退出条件和复审触发器；
- 新增代码或脚本已运行验证，失败样本和限制已保留；
- 文件、外部操作和费用均未超出用户授权范围。