DoneHub
0%

发表于 分类于 阅读次数： Valine：

Skills 是 Claude Code 最强大的扩展机制之一。它不是简单的”命令别名”，而是完整的 AI 行为定义：可以限制工具池、覆盖模型、注入 Hook、选择执行上下文（inline 或 fork）。更令人惊叹的是，Skills 支持条件激活——只有当你操作特定文件时才被发现。

阅读全文 »

发表于 分类于 阅读次数： Valine：

Claude Code 的多 Agent 系统可能是其最被低估的设计之一。它不是简单的”子代理调用”，而是一个完整的协作框架：四种 Agent 类型（Subagent、Fork、Teammate、Remote）、Teams 邮箱通信、权限同步、Worktree 隔离。这个设计让 Claude Code 能够处理单 Agent 无法完成的复杂任务。

阅读全文 »

发表于 分类于 阅读次数： Valine：

AI Agent 执行命令、修改文件、访问网络——这些都是高风险操作。Claude Code 的权限系统设计了一个分层的决策模型：规则 → 模式 → 钩子 → 分类器 → 用户确认。每一层都可以独立中断工具调用，确保安全性。

阅读全文 »

发表于 分类于 阅读次数： Valine：

Claude Code 的系统提示词不是一个静态字符串，而是一个动态组装的管道。通过分层构建、缓存边界、Section 类型等设计，实现了跨会话的缓存复用，大幅降低了延迟和成本。这是 Prompt 工程的教科书级案例。

阅读全文 »

发表于 分类于 阅读次数： Valine：

Claude Code 的终端界面不是传统的 CLI——它是一个完整的 React 应用，运行在终端中。通过 Ink 框架（自定义 React Reconciler + Yoga 布局引擎），Claude Code 实现了组件化 UI、双缓冲渲染、交互式对话框等高级特性。这是 Terminal UI 开发的教科书级案例。

阅读全文 »

发表于 分类于 阅读次数： Valine：

Claude Code 有 48+ 个内置工具，每个工具都是一个完整的生命周期管理单元。从定义到执行，工具要经过七步管道：查找、解析、验证、钩子、权限、执行、后处理。这个设计使得每个工具都是自描述、自验证、自渲染的——框架不需要了解工具的内部逻辑，只需调用标准接口。

阅读全文 »

发表于 分类于 阅读次数： Valine：

导读：同样的模型，不同的体验

主流 Code Agent 竞品一览

当前市面上主流的 AI Code Agent 产品可分为三类：

产品 公司 形态 特点
Claude Code Anthropic CLI Agent 运行时框架，MCP 扩展
Codex CLI OpenAI CLI 同类型竞品，GPT 模型驱动
Cursor Anysphere AI 原生 IDE VS Code fork，深度上下文感知
Trae 字节跳动 AI 原生 IDE 国内版”扣子”，自适应学习
GitHub Copilot Microsoft IDE 扩展 行业先驱，生态成熟
Qoder 阿里云 IDE 扩展 通义灵码，阿里云生态集成

Claude Code 与 Codex CLI 是同类型产品——都是终端型 CLI 工具，直接操作文件系统。其他产品则是 IDE 形态，交互方式不同。

核心体验差异

用 GPT-4 模型 + OpenAI 自家的 Codex CLI，效果还行；
用 GPT-4 模型 + Anthropic 的 Claude Code，效果竟然更好。

这颠覆了常识——为什么自家模型搭配自家 Agent，效果反而不如搭配竞争对手的 Agent？

答案在于：Claude Code 不是”Claude 模型的专属工具”，而是一个通用的 Agent 运行时框架。它的架构设计让任何模型都能发挥更大潜力。

很多人猜测是”Prompt 更好”，但这只是表象。Claude Code 源码泄露后，真相浮出水面——它不是一个 Prompt 工具，而是一个完整的 Agent 运行时框架。

这个框架做了什么？它”懂”模型的能力边界，”懂”工具的执行风险，”懂”上下文的压缩策略，”懂”用户的意图流转。模型只是大脑，Claude Code 是躯体。

一、架构对比：状态机 vs ReAct

1.1 市面主流 Code Agent 架构

大多数 Code Agent 采用 ReAct（Reasoning + Acting） 模式：

1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────────────────────────────────────────────────────┐
│                    ReAct 循环                                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Thought → Action → Observation → Thought → Action → ...   │
│                                                             │
│  问题：容易陷入死循环                                        │
│  ├─ 模型反复"思考"但无法推进                                 │
│  ├─ 工具失败后没有恢复机制                                   │
│  └─ 上下文无限膨胀直到截断                                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

1.2 Claude Code 的状态机架构

Claude Code 选择了一条不同的路——Async Generator 状态机：

1
2
3
4
5
6
7
8
9
10
11
12
// 核心循环不是 Thought→Action→Observation
// 而是 state = next 的状态推进

while (true) {
  const next = await step(queryContext)
  state = next  // 状态推进，不是循环
  
  if (state.type === 'end') break
  if (state.type === 'error') {
    state = recover(state)  // 有恢复机制！
  }
}

优势对比：

特性 ReAct Claude Code 状态机
死循环风险 高 低（状态推进有边界）
错误恢复 无 有（6 种恢复策略）
流式交互 困难 原生支持（Generator）
上下文管理 简单截断 四级压缩
模型控制 被动 主动（state 驱动）

二、工具生态对比

2.1 工具数量对比

Code Agent 内置工具 扩展机制
Claude Code 48+ MCP 协议（无限扩展）
Codex CLI ~20 有限扩展
Cursor ~15 IDE 内嵌，无扩展
Trae ~15 IDE 内嵌，无扩展
GitHub Copilot ~10 IDE 生态，有限
Qoder ~10 阿里云生态，有限

MCP 协议是 Claude Code 的杀手级特性——任何开发者都可以用任何语言编写 MCP Server，扩展 Claude Code 的能力。相比之下，其他产品的扩展性都受限。

大多数 Code Agent 的工具执行是”裸奔”的：

1
调用工具 → 执行 → 返回结果

Claude Code 的工具执行有 七步管道：

1
查找 → 解析 → 验证 → 钩子 → 权限 → 执行 → 后处理

关键差异：

管道步骤 Claude Code 其他 Agent
验证 Schema 校验 + 业务规则 通常无
钩子 PreToolUse/PostToolUse 可拦截 无
权限 五层决策链 简单开关
后处理 结果渲染 + 错误恢复 直接输出

三、上下文管理对比

3.1 市面常见做法

大多数 Code Agent 的上下文管理是暴力截断：

1
2
3
if (tokens > limit) {
  截断最早的消息
}

问题：

  • 重要信息可能丢失
  • 模型”忘记”之前的上下文
  • 长任务无法完成

3.2 Claude Code 的四级压缩

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────┐
│                   四级上下文压缩                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Level 1: Snip                                              │
│    └─ 快速裁剪：删除空白、重复内容                           │
│                                                             │
│  Level 2: Micro                                             │
│    └─ 微压缩：保留 tool_use ID，删除详细参数                 │
│                                                             │
│  Level 3: Collapse                                          │
│    └─ 块压缩：合并相邻消息，生成摘要                         │
│                                                             │
│  Level 4: AutoCompact                                       │
│    └─ 深度压缩：调用子代理生成完整摘要                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

效果对比：

场景 暴力截断 四级压缩
长对话 信息丢失 关键信息保留
复杂任务 无法完成 可以完成
模型理解 “忘记”之前 “记住”要点
Token 消耗 高 低（智能压缩）

四、多代理协作对比

4.1 单 Agent 的局限

大多数 Code Agent 是单 Agent 设计：

1
一个模型 + 一套工具 = 完成所有任务

问题：

  • 复杂任务难以分解
  • 单一模型容易”思维固化”
  • 无法并行处理

4.2 Claude Code 的多代理架构

Claude Code 有 四种 Agent 类型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────┐
│                    四种 Agent 类型                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Subagent（子代理）                                          │
│    └─ 短生命周期，完成子任务后汇报                           │
│                                                             │
│  Fork（分叉代理）                                            │
│    └─ 独立上下文，不污染主对话                               │
│                                                             │
│  Teams（团队代理）                                           │
│    └─ 邮箱通信，任务分发，并行执行                           │
│                                                             │
│  Remote（远程代理）                                          │
│    └─ MCP 协议，扩展到外部服务                               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

协作场景示例：

任务 单 Agent Claude Code 多代理
重构大型模块 容易迷失 Fork + Subagent 分解
并行调研 无法并行 Teams 并行执行
跨项目操作 困难 Remote MCP 扩展
长时间任务 上下文爆炸 Teams 邮箱通信

五、安全机制对比

5.1 市面常见做法

大多数 Code Agent 的安全机制是简单开关：

1
allowDangerousCommands: true/false

问题：

  • 无法精细控制
  • 一旦开启，所有危险操作都允许
  • 用户无法审批具体操作

5.2 Claude Code 的分层权限模型

Claude Code 有 五层决策链：

1
规则检查 → 模式检查 → 钩子检查 → 分类器检查 → 用户确认

精细控制示例：

操作 其他 Agent Claude Code
git status 允许/拒绝 允许（Git 白名单）
rm -rf node_modules 允许/拒绝 确认（危险命令）
rm -rf / 允许/拒绝 拒绝（永远禁止）
写入 .git/config 允许/拒绝 拒绝（敏感路径）
运行测试 允许/拒绝 允许（安全操作）

六、Memory 系统：其他 Agent 没有

6.1 跨会话记忆

大多数 Code Agent 每次对话从零开始：

1
新对话 → 模型不知道你是谁 → 重新解释需求

Claude Code 的 Memory 系统：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────┐
│                    Memory 系统                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  User Memory（用户画像）                                     │
│    └─ 记住你的角色、技能水平、偏好                           │
│                                                             │
│  Feedback Memory（行为反馈）                                 │
│    └─ 记住你对 Claude 工作方式的纠正                         │
│                                                             │
│  Project Memory（项目动态）                                  │
│    └─ 记住项目的决策、截止日期、正在进行的工作               │
│                                                             │
│  Reference Memory（外部引用）                                │
│    └─ 记住外部系统指针：仪表板、工单系统                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

效果：

场景 无 Memory 有 Memory
新对话 重新解释 Claude 知道你是谁
编码风格 每次指定 Claude 记住偏好
项目决策 重复解释 Claude 记住背景
团队协作 不知道队友 Claude 知道分工

七、远程控制：Channel 系统

7.1 其他 Agent 的局限

大多数 Code Agent 只能在本地终端交互：

1
你必须坐在电脑前 → 才能让 Agent 工作

7.2 Claude Code 的 Channel 系统

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌─────────────────────────────────────────────────────────────┐
│                    Channel 系统                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  手机 Telegram → 发消息给 Claude Code                        │
│      ↓                                                      │
│  Claude Code 在你的电脑上工作                                │
│      ↓                                                      │
│  结果回复到你的 Telegram                                     │
│                                                             │
│  六层访问控制确保安全：                                       │
│  ├─ 能力声明                                                 │
│  ├─ 运行时开关                                               │
│  ├─ OAuth 认证                                               │
│  ├─ 组织策略                                                 │
│  ├─ 会话白名单                                               │
│  └─ Marketplace 验证                                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

体验差异：

场景 其他 Agent Claude Code
外出时 无法使用 Telegram 远程控制
紧急修复 必须回电脑 手机审批操作
监控进度 无法监控 IM 实时反馈

八、Terminal UI：React + Ink

8.1 其他 Agent 的界面

大多数 Code Agent 的界面是简单输出：

1
2
stdout.print("模型回复")
stdout.print("工具结果")

问题：

  • 信息密集时难以阅读
  • 无法交互式选择
  • 无法可视化复杂内容

8.2 Claude Code 的 Terminal UI

Claude Code 用 React + Ink 构建 Terminal UI：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────┐
│                    React + Ink TUI                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  组件化 UI                                                   │
│    ├─ Header（标题栏）                                       │
│    ├─ MessageList（消息列表）                                │
│    ├─ ToolBar（工具栏）                                      │
│    ├─ ContextPanel（上下文面板）                             │
│    ├─ InputBox（输入框）                                     │
│    └─ PermissionDialog（权限对话框）                         │
│                                                             │
│  Flexbox 布局（Yoga 引擎）                                   │
│  双缓冲渲染（避免闪烁）                                       │
│  交互式组件（键盘导航）                                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

体验对比：

特性 简单输出 React + Ink
信息密度 低 高（布局优化）
可读性 一般 好（结构化展示）
交互性 无 有（键盘导航）
权限审批 全部允许/拒绝 可选择 Allow/Deny

九、System Prompt 工程

9.1 其他 Agent 的做法

大多数 Code Agent 的 System Prompt 是静态字符串：

1
SYSTEM_PROMPT = "你是一个 AI 编程助手..."

问题：

  • 无法动态适应环境
  • 无法缓存，每次都发送
  • 无法合并多来源指令

9.2 Claude Code 的分层 System Prompt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
┌─────────────────────────────────────────────────────────────┐
│                 分层 System Prompt                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  静态可缓存区域                                              │
│    ├─ 角色定义                                               │
│    ├─ 系统规则                                               │
│    ├─ 工具说明                                               │
│    └─ 任务指导                                               │
│                                                             │
│  ─────────── 缓存边界 ───────────                            │
│                                                             │
│  动态可变区域                                                │
│    ├─ 当前日期                                               │
│    ├─ 项目结构                                               │
│    ├─ Git 状态                                               │
│    ├─ MCP 指令                                               │
│    └─ CLAUDE.md（用户指令）                                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

效果：

特性 静态 Prompt 分层 Prompt
Token 消耗 高（每次全量） 低（缓存复用）
响应延迟 高 低（缓存命中）
指令优先级 单一 多级合并
用户定制 困难 CLAUDE.md 支持

十、总结：Claude Code 的核心竞争力

Claude Code 比其他 Code Agent 更强，不是因为”Prompt 更好”，而是因为它是一个完整的 Agent 运行时框架：

10.1 七大核心优势

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
┌─────────────────────────────────────────────────────────────┐
│                Claude Code 七大核心优势                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. 状态机架构                                               │
│    └─ 替代 ReAct，避免死循环，支持流式交互                   │
│                                                             │
│  2. 工具生命周期                                             │
│    └─ 七步管道：验证、钩子、权限、后处理                     │
│                                                             │
│  3. 四级上下文压缩                                           │
│    └─ 智能压缩，保留关键信息，实现"伪无限对话"               │
│                                                             │
│  4. 多代理协作                                               │
│    └─ 四种 Agent 类型，Teams 邮箱通信，并行执行              │
│                                                             │
│  5. 分层权限控制                                             │
│    └─ 五层决策链，精细控制每个操作                           │
│                                                             │
│  6. Memory 系统                                              │
│    └─ 跨会话记忆，Claude"记住"你是谁                         │
│                                                             │
│  7. 分层 System Prompt                                       │
│    └─ 缓存优化，降低 Token 消耗和延迟                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

10.2 一句话总结

Claude Code 是一个”懂”模型的 Agent 平台：

  • 懂模型的能力边界 → 状态机架构
  • 懂工具的执行风险 → 七步管道 + 权限控制
  • 懂上下文的压缩策略 → 四级压缩
  • 懂任务的分解协作 → 多代理架构
  • 懂用户的长期意图 → Memory 系统

其他 Code Agent 只是模型的”简单包装”，Claude Code 是模型的”完整躯体”。这就是为什么同样的 Claude 模型，配合 Claude Code 使用效果更好的根本原因。

系列文章导航：

发表于 更新于 分类于 阅读次数： Valine：

写在前面

2026 年 4 月，中国。

你想订阅一个 Coding Plan？那得费老鼻子劲了。

这不是个例。2026 年，中国的 AI 算力供应紧张到了”抢号”的地步。

背后的原因很简单：高端 GPU 被禁售，国产替代跟不上。

这篇文章，聊聊中国显卡自研的进度、挑战，以及算力危机暴露出的深层问题。

一、现状：2026 年的国产 GPU

1.1 华为昇腾：国产 AI 算力的主力

华为昇腾是目前国产 AI 算力最有希望的产品线：

产品 制程 状态 性能对标
昇腾 910B 7nm (中芯N+2) 已量产 约 A100 水平（2020年）
昇腾 910C 7nm 小规模量产 约 A100/A800 水平
昇腾 910D 7nm+ 2025H2量产，2026部署 目标对标 H100

时间差距评估：

如果昇腾 910D 成功对标 H100（2022 年产品），那么：

1
2
3
4
5
6
7
8
性能对标：    昇腾 910D ≈ H100 (2022)
              ↙               ↘
时间差距：   2026年达到 → 2022年水平 = 落后 4 年

但同时 NVIDIA 已演进到：
              B200/B300 (2024-2025) + Rubin (2026)
              ↘
              仍领先 2-3 代

1.2 其他国产 GPU 厂商

厂商 产品 制程 状态 定位
海光 DCU 系列 7nm 已量产 CUDA 兼容，持续迭代
壁仞科技 BR100 改版 7nm 小规模 转型推理、边缘计算
摩尔线程 MTT S80/S4000 7nm 已量产 全功能 GPU，消费级+专业级
天数智芯 天垓 100 7nm 已量产 AI 推理

共同特点： 全部停留在 7nm 制程。

二、硬件瓶颈：制程封锁是核心困境

2.1 光刻机：无法获得的”关键设备”

高端 GPU 需要先进制程。而先进制程依赖光刻机。

制程 生产方 中国可获得性
3nm TSMC、三星 ❌ 完全封锁
4nm/4NP TSMC ❌ 禁止出口中国
5nm TSMC、三星 ❌ 禁止出口中国
7nm TSMC、三星、中芯 ⚠️ 中芯可做，但产能有限
14nm+ 中芯、华虹等 ✅ 成熟量产

2026 年实际差距：

1
2
3
4
5
6
7
8
9
NVIDIA 制程演进:
  2022: H100 @ 4nm
  2024: B200 @ 4NP (改进4nm)
  2026: Rubin @ 3nm
  
中国可获得的最佳制程:
  2026: 7nm (中芯 N+2，DUV 多重曝光)
  
制程差距: 3nm vs 7nm = 2-3 代差距

2.2 EUV vs DUV：光刻机的代际差距

EUV（极紫外光刻机） 是制造 7nm 以下芯片的关键设备，由荷兰 ASML 生产，被美国禁止出口中国。

中芯国际只能用 DUV（深紫外光刻机） 做 7nm，需要”多重曝光”：

指标 EUV 单次曝光 DUV 多重曝光
步骤数 1次曝光 3-4次曝光
良率 80-90% 30-50%
成本 基准 2-3 倍
产能 基准 限制较大

这意味着：

  • 同样生产一块 7nm GPU，中国成本更高、良率更低
  • 实际可用芯片数量有限，无法大规模量产
  • 7nm 是天花板，无法突破到 5nm/3nm

2.3 HBM 内存：另一个短板

高端 AI 训练需要 HBM（高带宽内存）：

GPU 内存规格 带宽
H100 80GB HBM3 3.35 TB/s
B200 192GB HBM3e 8 TB/s
昇腾 910D 估计 HBM2e 估计 1-2 TB/s

HBM 由韩国 SK 海力士、三星主导，技术门槛极高。国产 HBM 还在研发阶段，差距明显。

三、软件瓶颈：CUDA 的二十年差距

3.1 CANN vs CUDA：软件栈差距

华为昇腾使用 CANN（Compute Architecture for Neural Networks）作为软件栈：

1
2
3
4
5
6
7
8
9
10
CUDA 生态层级              CANN 生态层级
┌─────────────────┐        ┌─────────────────┐
│  PyTorch/TF     │        │  MindSpore      │ ← 华自研框架
├─────────────────┤        ├─────────────────┤
│  cuDNN/cuBLAS   │        │  ACL/OP API     │ ← 适配层
├─────────────────┤        ├─────────────────┤
│  CUDA Runtime   │        │  CANN Runtime   │
├─────────────────┤        ├─────────────────┤
│  NVIDIA GPU     │        │  昇腾 NPU       │
└─────────────────┘        └─────────────────┘

差距对比：

维度 CUDA (2026) CANN (2026)
开发周期 20 年 约 6-7 年
开发者数量 500 万+ 估计 15-20 万
算子库数量 3000+ 估计 500-600 个
文档完善度 极其详尽 相对不足
bug 修复速度 全球团队支持 依赖华为内部团队

3.2 深度学习框架的适配困境

主流框架对 CUDA 是”原生级”支持，对昇腾是”适配级”：

1
2
3
4
PyTorch 官方支持优先级：
├── CUDA: 原生支持，性能最优，bug 优先修复
├── ROCm (AMD): 次级支持，问题较多
└── CANN (昇腾): 通过 torch_npu 扩展适配，非官方原生

这意味着：

  • PyTorch 新特性永远先在 CUDA 上实现
  • 昇腾适配永远慢一步
  • 很多算子没有优化实现
  • 开源社区贡献几乎为零

3.3 算子移植的巨大工作量

一个深度学习模型可能有 数百个算子：

对比 数量
PyTorch CUDA 算子 超过 2000 个
昇腾已适配算子 估计 500-800 个
差距 超过 1200 个算子需要移植

每个算子都需要：

  • 针对昇腾架构重新实现
  • 性能优化调优
  • bug 测试修复

这是一项巨大且持续的工作。

四、人才瓶颈：GPU 专家在哪里？

4.1 GPU 架构设计人才稀缺

需要的人才类型 全球分布
GPU 微架构设计 主要在 NVIDIA、AMD，中国极少
并行计算编译器 CUDA 团队深耕 20 年，中国刚起步
高性能算子优化 需要硬件+算法双重知识，人才稀缺

现实： 全球 GPU 核心人才集中在 NVIDIA 和 AMD。中国需要”从零培养”或”海外引进”，但顶尖人才很难回国。

4.2 开发者转向成本

即使硬件做出来了，谁来用？

  • 中国 AI 开发者 90%+ 使用 CUDA
  • 学习 CANN 需要重新理解：编程模型、内存管理、性能优化策略
  • 企业没有动力让员工学习新平台（除非强制）

五、追赶悖论：永远差几步

5.1 时间差距的变化

1
2
3
4
5
6
7
8
9
10
11
12
时间差距变化：
  2024: 昇腾 910B vs H100 = 落后约 6-8 年
  2026: 昇腾 910D vs B300 = 落后约 3-4 年
  
如果保持追赶速度：
  2028: 可能落后 2-3 年
  2030: 可能落后 1-2 年
  
但前提是：
├── 制程不被进一步封锁
├── 软件生态持续投入
└── NVIDIA 不加速迭代

5.2 NVIDIA 也在前进

更残酷的是：你追上今天的 NVIDIA，但 NVIDIA 又进化了。

1
2
3
4
5
6
7
8
9
10
11
12
13
2026 年时间线：

NVIDIA:
├── H100 (2022) ─────→ 成熟稳定，大规模部署
├── B200/B300 (2024-2025) ─→ 大规模出货
└── Rubin R100 (2026H2) ─→ 下一代发布

华为昇腾:
├── 910B (已量产) ─────→ 对标 A100 (2020)
├── 910C (小规模) ─────→ 对标 A100/A800
└── 910D (2026部署) ───→ 目标对标 H100 (2022)

差距：4 年（但 NVIDIA 还有 B300、Rubin）

六、挑战排序：从难到易

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
                    ┌─────────────────────────────────┐
                    │   中国 GPU 自研挑战金字塔       │
                    └─────────────────────────────────┘

Level 5: 生态网络效应（差距扩大）
         ├── CUDA 20 年，开发者 500 万+
         ├── 学术界默认 CUDA，论文难复现
         └── 全球开源社区全部绑定 CUDA

Level 4: 软件栈深度（差距缩小但仍明显）
         ├── 算子库 3000+ vs 600
         ├── PyTorch 适配约 70% 主流算子
         └── 调试工具、profiler 差距大

Level 3: 人才知识积累（持续投入）
         ├── 20 年培养的 GPU 专家
         ├── 编译器团队规模差距
         └── 性能优化经验积累

Level 2: 制造工艺差距（核心瓶颈）
         ├── 3nm vs 7nm，差 2-3 代
         ├── EUV 光刻机完全封锁
         └── HBM 内存技术落后

Level 1: 硬件架构设计（已有突破）
         ├── 昇腾 910D 架构设计成熟
         ├── 部分指标接近 H100
         └── 资金投入可解决

排序结论：

  • 硬件设计（Level 1）：已有突破，可追赶
  • 制造工艺（Level 2）：核心瓶颈，短期难以突破
  • 人才积累（Level 3）：需要持续投入 5-10 年
  • 软件栈（Level 4）：差距明显，但正在缩小
  • 生态效应（Level 5）：差距扩大，最难跨越

七、算力危机：暴露了哪些问题？

7.1 表层问题：供应不足

2026 年，Coding Plan 抢不到，直接原因是：

问题 说明
NVIDIA GPU 禁售 H100、B200 等高端产品无法进口
国产 GPU 产能不足 7nm 良率低，产能有限
需求爆发式增长 大模型训练需求远超供给

7.2 深层问题：技术依赖

更深层的问题是技术依赖：

依赖类型 说明
硬件依赖 高端 GPU、光刻机、HBM 都依赖进口
软件依赖 CUDA 生态绑定，开发者只会 CUDA
人才依赖 GPU 核心人才在海外
生态依赖 学术论文、开源项目全部绑定 CUDA

一句话：AI 技术栈的每一层，都依赖海外技术。

7.3 更深层问题：战略误判

回顾过去十年，有哪些战略误判？

误判 后果
低估 AI 算力重要性 2022 年大模型爆发时，措手不及
低估制裁风险 没有”囤货”预案，禁售后严重短缺
高估国产替代速度 认为几年就能追上，实际差距仍大
忽视软件生态 只关注硬件，软件生态投入不足

八、未来展望：什么时候可以缓解？

8.1 短期（2026-2027）

方面 预期
昇腾 910D 部署 2026 年大规模部署，缓解部分需求
国家强制替代 政企、国企强制使用国产算力
算力共享平台 建立公共算力平台，提高利用率

缓解程度： 部分缓解，但高端需求仍紧张。

8.2 中期（2028-2030）

方面 预期
昇腾下一代 目标对标 B300，差距缩小到 2-3 年
软件生态成熟 CANN 算子适配 90%+，MindSpore 完善
7nm 产能提升 中芯产能提升，良率改善

缓解程度： 基本需求可满足，高端训练仍有限制。

8.3 长期（2030+）

方面 预期
制程突破？ 取决于光刻机技术突破，不确定性高
生态建立 国内开发者形成规模，可能突破 50 万
差异化路线 不追求通用 GPU，聚焦特定领域优化

缓解程度： 取决于技术突破和持续投入。

8.4 关键变量

什么时候可以缓解，取决于三个变量：

变量 影响
美国制裁力度 制程封锁是否会进一步加强
软件生态投入 CANN、MindSpore 能否持续迭代
国内需求增速 大模型需求是否会放缓

九、可能的破局路径

9.1 短期：强制替代

1
2
3
4
5
国家强制推动：
├── 政务系统 → 强制使用国产算力
├── 国企央企 → 强制使用国产算力
├── 高校科研 → 优先使用国产算力
└── 互联网公司 → 部分强制替代

优点： 快速提升国产 GPU 需求，加速迭代
缺点： 效率损失，短期内性能不如 CUDA

9.2 中期：场景突破

不追求”通用 GPU”，聚焦特定场景：

场景 策略
推理场景 不需要顶级算力，国产 GPU 可胜任
边缘计算 功耗要求高，国产 GPU 有优势
特定行业 政务、金融、医疗，可以定制优化

9.3 长期：生态建设

1
2
3
4
5
开源社区建设：
├── 投资开源项目 → 让开发者愿意贡献
├── 建立开发者社区 → 提供培训、文档、支持
├── 学术合作 → 让高校用国产 GPU 做研究
└── 企业扶持 → 帮助企业迁移到国产平台

这是最难但最根本的路径。

十、总结：路还要走多久？

回到开头的问题：Coding Plan 抢不到，什么时候可以缓解？

答案取决于视角：

视角 时间估计
基本需求缓解 2026-2027（昇腾 910D 部署）
高端需求缓解 2028-2030（取决于技术突破）
追上 NVIDIA 可能需要 10-15 年
建立完整生态 可能需要 20 年

更关键的问题：

算力危机暴露的不仅是”供应不足”，而是整个 AI 技术栈的依赖：

  • 硬件依赖：光刻机、GPU、HBM
  • 软件依赖：CUDA 生态
  • 人才依赖：GPU 专家稀缺
  • 生态依赖：学术界、开源社区

这不是”买买买”就能解决的问题，而是需要 10-20 年持续投入的系统性工程。

写在最后

中国显卡自研之路，注定是一条艰难的路。

硬件层面：制程封锁是核心瓶颈，短期难以突破。

软件层面：CUDA 的二十年差距，需要持续追赶。

生态层面：开发者、学术界、开源社区的绑定，是最难跨越的障碍。

但好消息是：

  • 昇腾 910D 如果成功量产，将大幅缩短差距
  • CANN/MindSpore 正在快速迭代
  • 国产替代需求 正在加速推动技术进步

中国 GPU 自研，不是”能不能”的问题，而是”要多久”的问题。

短期（2-3 年）：基本需求缓解。
中期（5-8 年）：高端需求部分满足。
长期（10-15 年）：可能追上 NVIDIA。

但前提是：制裁不加剧、投入不中断、生态持续建设。

参考资料

发表于 更新于 分类于 阅读次数： Valine：

一、前言：为什么需要这个工具？

你有没有遇到过这样的场景：

  • 想让 AI 帮你调试网页，但它只能”纸上谈兵”，给建议却不能动手
  • 需要自动化测试网页功能，写脚本太麻烦
  • 想分析网页性能瓶颈，但看不懂 DevTools 里的各种指标
  • 希望让 AI 帮你截取网页截图、提取页面内容

Chrome DevTools MCP 就是解决这些问题的神器。它让 AI 助手（如 Claude Code、Cursor、Copilot）能够直接操控浏览器，像一个真正的开发者一样干活。

二、核心概念：MCP 是什么？

2.1 MCP 协议简介

MCP（Model Context Protocol） 是 Anthropic 在 2024 年底提出的一个开放协议。简单理解，它是 AI 助手与外部工具之间的”通用插座”。

打个比方：

  • 没有 MCP 时，AI 像是”被困在盒子里的聪明人”——只能聊天，不能动手
    -有了 MCP，AI 像是”长了手脚的助手”——能连接数据库、操控浏览器、读写文件

2.2 MCP 的架构

1
2
3
4
5
6
7
8
9
10
┌─────────────┐     MCP 协议     ┌─────────────────┐
│   AI 助手   │◄──────────────►│   MCP Server    │
│ (Claude等)  │                 │ (工具提供者)     │
└─────────────┘                 └─────────────────┘
                                       │
                                       ▼
                              ┌─────────────────┐
                              │   外部资源       │
                              │ (浏览器/数据库等)│
                              └─────────────────┘

MCP Server 是关键组件，它：

  1. 暴露工具（Tools）给 AI 调用
  2. 提供资源（Resources）供 AI 读取
  3. 发送提示（Prompts）引导 AI 使用

2.3 Chrome DevTools MCP 的定位

chrome-devtools-mcp 是官方提供的 MCP 服务器，它把 Chrome 浏览器的 DevTools 能力 暴露给 AI 助手。

这意味着 AI 可以：

  • 打开网页、点击按钮、填写表单
  • 查看控制台日志、网络请求
  • 截图、分析性能
  • 提取 DOM 元素、调试 JavaScript

三、核心功能一览

3.1 主要能力分类

类别 功能 典型用途
浏览器控制 打开页面、导航、刷新、关闭 自动化浏览
页面交互 点击、输入文本、滚动、等待 自动化测试
调试分析 控制台日志、网络请求、错误追踪 问题排查
性能分析 录制性能追踪、分析加载时间 性能优化
视觉捕获 截图、获取元素坐标 文档记录
DOM 操作 获取元素、查询选择器 内容提取

3.2 Slim 模式 vs 完整模式

Chrome DevTools MCP 提供两种运行模式：

模式 工具数量 适用场景 启动参数
Slim 模式 约 10 个 基础浏览任务 --slim --headless
完整模式 约 30+ 个 调试、性能分析 默认

新手建议先用完整模式，熟悉后再根据需求切换。

四、安装配置：Claude Code 实战

4.1 环境要求

在开始之前，请确保你有：

要求 版本 检查方法
Node.js v20.19+ node -v
npm 最新版 npm -v
Chrome 最新稳定版 浏览器设置查看
Claude Code 最新版 claude --version

4.2 方法一：CLI 快速安装（推荐）

打开终端，执行一行命令：

1
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

这会自动添加到你的用户级配置中。

4.3 方法二：手动配置

如果你想手动配置，找到 Claude Code 的配置文件：

Windows:

1
C:\Users\<你的用户名>\.claude\settings.json

Mac/Linux:

1
~/.claude/settings.json

在 mcpServers 部分添加：

1
2
3
4
5
6
7
8
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

4.4 配置参数详解

你可以通过参数定制行为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--headless",           // 无头模式（不显示浏览器窗口）
        "--slim",               // 精简模式（减少工具数量）
        "--no-performance-crux" // 禁用 CrUX 数据收集
      ]
    }
  }
}

常用参数说明：

参数 作用 建议场景
--headless 无界面运行 CI/CD、自动化脚本
--slim 只加载基础工具 简单浏览任务
--no-usage-statistics 禁用使用统计 隐私敏感场景
--browser-url=... 连接已有浏览器 调试特定实例

4.5 验证安装

重启 Claude Code 后，输入以下命令验证：

1
2
3
4
5
# 查看已安装的 MCP 服务器
claude mcp list

# 查看 MCP 服务器详情
claude mcp get chrome-devtools

如果看到 chrome-devtools 在列表中，说明安装成功！

五、使用实战：从零开始

5.1 基础操作示例

安装成功后，你可以直接在 Claude Code 中用自然语言操控浏览器。

示例 1：打开网页并截图

1
请打开 https://example.com，然后截取整个页面的截图

AI 会自动调用 MCP 工具：

  1. browser_navigate - 打开网页
  2. browser_screenshot - 截取屏幕

示例 2：提取页面内容

1
打开 https://news.ycombinator.com，获取首页所有新闻标题

AI 会：

  1. 打开 Hacker News
  2. 用 DOM 选择器提取标题元素
  3. 返回标题列表

示例 3：自动化表单填写

1
打开 https://example.com/login，填写用户名 "test@example.com"，密码 "password123"，然后点击登录按钮

5.2 调试实战

示例 4：检查控制台错误

1
打开我的项目 http://localhost:3000，检查是否有控制台错误

AI 会查看 console 日志，找出红色错误信息并分析原因。

示例 5：分析网络请求

1
打开 https://myapi.example.com，查看所有 API 请求的响应时间

AI 会：

  1. 捕获网络请求
  2. 分析每个请求的耗时
  3. 找出慢请求并给出优化建议

5.3 性能分析实战

示例 6：页面性能诊断

1
分析 https://mysite.com 的加载性能，找出瓶颈

AI 会：

  1. 录制性能追踪（Performance Trace）
  2. 分析关键指标（FCP、LCP、CLS）
  3. 给出具体优化建议

关键性能指标解释：

指标 全称 含义 理想值
FCP First Contentful Paint 首次内容绘制 < 1.8s
LCP Largest Contentful Paint 最大内容绘制 < 2.5s
CLS Cumulative Layout Shift 累积布局偏移 < 0.1
TTI Time to Interactive 可交互时间 < 3.8s

六、进阶技巧

6.1 连接已有的浏览器实例

如果你已经在调试某个页面，可以让 MCP 连接到现有浏览器：

步骤 1：以调试模式启动 Chrome

Windows:

1
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222

Mac:

1
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

步骤 2：修改 MCP 配置

1
2
3
4
5
6
7
8
9
10
11
12
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--browser-url=http://127.0.0.1:9222"
      ]
    }
  }
}

这样 MCP 会连接到你已有的浏览器，而不是启动新实例。

6.2 禁用数据收集（隐私考量）

Chrome DevTools MCP 默认会收集使用统计数据。如果你在意隐私：

1
"args": ["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics"]

或设置环境变量：

1
export CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS=1

6.3 在 CI/CD 中使用

自动化测试场景建议配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--headless",
        "--no-usage-statistics"
      ],
      "env": {
        "CI": "true"
      }
    }
  }
}

七、常见问题排查

7.1 MCP 服务器启动失败

症状： Claude Code 提示 “Failed to start MCP server”

排查步骤：

  1. 检查 Node.js 版本：

    1
    node -v  # 需要 v20.19+

  2. 手动测试 MCP 服务器：

    1
    npx chrome-devtools-mcp@latest

  3. 检查网络连接（npx 需要下载包）

7.2 浏览器连接失败

症状： 提示 “Cannot connect to browser”

解决方案：

  1. 确保 Chrome 已安装且是最新版
  2. 如果使用 --browser-url，确保 Chrome 以调试模式启动
  3. 检查端口是否被占用：
    1
    2
    3
    4
    5
    # Windows
    netstat -ano | findstr 9222

    # Mac/Linux
    lsof -i :9222

7.3 工具调用超时

症状： 操作网页时长时间无响应

可能原因：

  • 页面加载缓慢
  • 网络问题
  • 复杂页面导致操作卡住

建议：

  • 使用 --headless 模式减少资源占用
  • 给 AI 明确的等待指令：”等待页面完全加载后再…”
  • 分步操作，不要一次性执行太多

7.4 Windows 特殊配置

Windows 用户可能遇到启动超时，建议添加环境变量：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "chrome-devtools-mcp@latest"
      ],
      "env": {
        "SystemRoot": "C:\\Windows",
        "PROGRAMFILES": "C:\\Program Files"
      },
      "startup_timeout_ms": 20000
    }
  }
}

八、最佳实践总结

8.1 使用建议

建议 说明
明确指令 告诉 AI 具体要做什么，不要模糊
分步执行 复杂任务拆成多个步骤
善用等待 让 AI 等待页面加载完成再操作
验证结果 让 AI 截图确认操作是否成功
保存日志 调试时让 AI 保存控制台日志供分析

8.2 安全注意事项

重要提醒： MCP 会将浏览器内容暴露给 AI 助手。

  • 不要在浏览器中打开敏感页面（银行、密码管理器等）
  • 不要填写真实密码或个人信息
  • CI/CD 环境建议禁用使用统计
  • 定期检查 MCP 配置，移除不需要的服务器

8.3 与其他工具对比

工具 类型 优点 适用场景
Chrome DevTools MCP AI+浏览器 AI自主操控、智能分析 调试、分析、自动化
Puppeteer Node.js库 精细控制、成熟稳定 自动化脚本
Selenium 自动化框架 跨浏览器、生态丰富 E2E测试
Playwright 自动化框架 现代、快速、多浏览器 现代Web测试

九、总结

Chrome DevTools MCP 打通了 AI 助手与浏览器之间的壁垒，让 AI 从”只能聊天”进化为”能动手干活”。

核心价值：

  1. 零代码自动化 - 用自然语言操控浏览器
  2. 智能调试 - AI 分析问题，给出解决方案
  3. 性能洞察 - 自动识别性能瓶颈
  4. 开发提效 - 减少手动重复操作

学习路径建议：

1
2
3
4
5
第1天：安装配置，尝试打开网页、截图
第2天：调试实战，检查控制台、网络请求
第3天：自动化测试，填写表单、点击按钮
第4天：性能分析，了解 Web Vitals 指标
第5天：进阶使用，连接已有浏览器、CI集成

参考资料

发表于 更新于 分类于 阅读次数： Valine：

从抢购算力开始

2026 年，想买个 Coding Plan 太难了。。。

中国的算力紧张，根源在哪？答案很简单：算力要靠显卡，显卡要买英伟达。

显卡是怎么制约算力发展的？为了搞清楚这个问题，我研究了很多方面，但始终绕不开英伟达这家企业。

很多人知道英伟达卖显卡，但不知道 CUDA 是什么。更不知道，CUDA 是英伟达最重要的一段护城河，以及这道护城河是怎么花了二十年一步步挖出来的。

这篇文章，就来聊聊 CUDA 的故事。

一、先搞清楚：CUDA 到底是什么？

CUDA = Compute Unified Device Architecture，翻译过来是”统一计算设备架构”。

听起来很抽象？用一个类比：

类比 说明
GPU 是”肌肉” 专门做大规模并行计算，力量惊人
CUDA 是”大脑” 指挥 GPU 怎么干活，把计算任务调度到各个核心

没有 CUDA，GPU 就只是个画图的机器——只能渲染游戏画面，不能做 AI 训练、科学计算这些”正经事”。

有了 CUDA，GPU 才变成了一台通用计算设备——可以跑任何需要大规模并行计算的程序。

这就是 CUDA 的核心价值：让 GPU 从”画图专用”变成了”万能计算器”。

二、起源：黄仁勋的一场豪赌

2.1 2006 年之前的 GPU 世界

在 2006 年之前，GPU 只有一个用途：打游戏。

想用 GPU 做科学计算？你得把计算任务”伪装”成画图任务：

1
2
3
4
5
6
7
你想计算：矩阵乘法
你得告诉 GPU：我要画一堆三角形，颜色就是计算结果

这就像：
你想请厨师做饭
但你只能用"点菜"的方式告诉他
"我要一盘红色的、方形的、味道像矩阵乘法的菜"

这种”骗 GPU 干活”的方式叫 GPGPU（General Purpose GPU）。极其痛苦，效率极低。

2.2 黄仁勋的”押注公司”时刻

2006 年，英伟达 CEO 黄仁勋做了一个决定：

投入 100 亿美元，开发 CUDA 平台

这是什么概念？当时英伟达的市值也就几百亿美元。华尔街疯了：

“你一个卖游戏显卡的公司，为什么要烧钱搞什么通用计算平台？”
“这钱烧下去，什么时候能赚回来？”

黄仁勋的回答很简单：“GPU 不应该只用来打游戏。”

G80 架构（GeForce 8800 GTX）是第一款支持 CUDA 的显卡。它实现了”统一着色器架构”——让 GPU 的所有核心可以执行任意计算任务，而不是只能画三角形。

2.3 漫长的黑暗期

CUDA 发布后，遭遇了长达 6-7 年的冷遇：

时间 状态
2006-2008 几乎无人问津，只有少数科研人员用
2008-2010 学术界开始关注，产业界无动于衷
2010-2012 股价低迷，投资者持续质疑

这期间，英伟达默默做了三件事：

  1. 免费开放 CUDA 工具包——任何开发者都可以下载使用
  2. 资助大学教育——让 CUDA 进入计算机课程
  3. 持续迭代硬件——Fermi、Kepler、Maxwell，每一代都优化 CUDA 性能

这就像种树：前六年只浇水不结果，但根系在悄悄扎深。

三、转折：2012 年 AlexNet

2012 年，ImageNet 图像识别竞赛，一个叫 Alex Krizhevsky 的研究生用两块 GTX 580 训练了一个深度神经网络。

结果：碾压全场。

对比 AlexNet 传统方法
错误率 15.3% 26%+
训练时间 几周 数月甚至数年
硬件成本 几千美元 数百万美元

关键点：AlexNet 的实现深度依赖 CUDA。

这让全世界 AI 研究者意识到一个公式：

GPU + CUDA + 深度神经网络 = AI 的未来

从这一天开始，CUDA 从”没人用的玩具”变成了”AI 研究的标配”。

四、发展：二十年迭代，从 1.0 到 14.x

CUDA 的发展不是一蹴而就，而是持续二十年的迭代：

1
2
3
4
5
6
7
8
9
CUDA 时间线（2006-2026）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2006      2012       2016       2022       2024       2026
  │         │          │          │          │          │
CUDA 1.0  AlexNet    Volta      H100       B200       Rubin
  │         │          │          │          │          │
  │         │          │          │          │          │
冷启动期  AI起飞     生态成熟   大模型爆发  主流出货   下一代
CUDA 版本 年份 关键特性
1.0 2006 基础编程模型
2.0 2008 双精度浮点支持
4.0 2011 动态并行
6.0 2014 统一内存
8.0 2016 Volta 架构优化
10.0 2018 Turing 架构、Tensor Core
11.0 2020 Ampere 架构、多实例 GPU
12.0 2022 Hopper 架构、H100
14.x 2026 Rubin 架构适配

二十年积累，意味着：

维度 2026 年数据
开发者数量 500 万+
CUDA 版本 14.x
算子库数量 3000+
GitHub 项目依赖 数千万
学术论文依赖 95%+

五、护城河：CUDA 是怎么”锁死”竞品的？

5.1 护城河的本质

护城河不只是”技术先进”，而是让竞争对手根本无法入场。

CUDA 的护城河是一个多层嵌套的陷阱：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
                    ┌─────────────────────────────────────┐
                    │       CUDA 护城河层级               │
                    └─────────────────────────────────────┘

Level 5: 生态网络效应（最难跨越）
         ├── 全球 500 万开发者，都只会 CUDA
         ├── 学术论文默认 CUDA，想发 paper 必用 CUDA
         └── 开源项目全部绑定 CUDA

Level 4: 软件栈深度（很难）
         ├── 3000+ 高度优化的算子库
         ├── cuDNN、cuBLAS、NCCL 等核心库
         └── TensorRT、RAPIDS 等工具链

Level 3: 人才知识积累（难）
         ├── 20 年培养的 GPU 专家
         ├── 编译器、架构设计团队
         └── 性能优化经验

Level 2: 硬件制造差距（困难）
         ├── 3nm 制程领先 2-3 代
         ├── HBM3e 内存技术领先
         └── NVLink 高速互联

Level 1: 架构设计（相对可追赶）
         ├── 有公开论文可参考
         ├── 有人才储备
         └── 资金可投入

5.2 软件栈锁定

英伟达的软件栈是一个层层嵌套的体系：

1
2
3
4
5
6
7
8
9
10
11
┌─────────────────────────────────────────────┐
│   PyTorch / TensorFlow / JAX 等框架         │  ← 开发者直接接触
├─────────────────────────────────────────────┤
│   TensorRT / RAPIDS / Numba                  │  ← 性能优化工具
├─────────────────────────────────────────────┤
│   cuDNN / cuBLAS / NCCL / cuSPARSE           │  ← 核心计算库
├─────────────────────────────────────────────┤
│   CUDA Runtime / CUDA Driver API             │  ← 编程接口
├─────────────────────────────────────────────┤
│   NVIDIA GPU 硆件                            │  ← 物理基础
└─────────────────────────────────────────────┘

每一层都只对 NVIDIA 硬件优化：

层级 英伟达专有 竞品状态
深度学习框架 PyTorch 对 CUDA 优化最完善 AMD ROCm 支持残缺
计算库 cuDNN 性能碾压其他实现 AMD 没有对标库
通信库 NCCL 多卡通信成熟稳定 AMD 的 RCCL bug 满天飞
开发者 500 万 CUDA 程序员 ROCm 开发者寥寥无几

5.3 开发者锁定

假设你是一家 AI 公司的技术负责人，想迁移到 AMD：

挑战 具体内容
代码资产 你有 50 万行 CUDA 代码，全要重写
人才储备 你的团队精通 CUDA，需要重新培训
基础设施 CI/CD 全基于 NVIDIA GPU，要重建
第三方依赖 开源库都绑定 CUDA，迁移兼容性差
迁移风险 迁移期间 bug 多、性能下降

结论：迁移成本太高，几乎不可能。

这就是开发者锁定的本质：不是 CUDA 技术有多好，而是换一套生态的代价太大。

5.4 学术界锁定

更可怕的是学术界锁定：

1
2
3
4
5
6
AI 研究流程：
论文作者 → 写了 CUDA 代码 → 论文发表 → 代码开源

后续研究者 → 想复现论文 → 必须用 CUDA → 又写了更多 CUDA 代码

循环强化 → 所有论文都默认 CUDA → 学术界被绑定

95% 的 AI 论文默认使用 CUDA。想发 paper、想复现别人的结果、想用开源模型？你必须有 NVIDIA GPU。

六、竞品困境：AMD 和英特尔为什么追不上？

6.1 AMD 的 ROCm

AMD 推出了 ROCm（Radeon Open Compute）试图对标 CUDA：

对比维度 CUDA ROCm
发布时间 2006 2016（晚10年）
开发者数量 500万 估计不足5万
算子库 3000+ 约200个
稳定性 极高 经常出 bug
框架支持 原生级 适配级（残缺）

ROCm 的问题：

  1. 起步太晚——CUDA 已经 10 年积累，ROCm 才开始
  2. 兼容性差——很多 CUDA 代码无法直接迁移
  3. 文档缺失——开发者找不到资料
  4. 社区冷淡——没人愿意贡献代码

6.2 英特尔的 oneAPI

英特尔 2020 年才推出 oneAPI：

问题 说明
起步更晚 比 CUDA 晚 14 年
硬件不给力 英特尔 GPU 性能跟不上
开发者不学 没人愿意学一套新 API
市场份额低 几乎没有实际部署

6.3 追赶悖论

更残酷的是：你追上今天的 CUDA，但 CUDA 又进化了。

1
2
3
4
5
6
7
8
9
如果 AMD 今天追上 CUDA 2022 年的水平：
├── CUDA 已经是 2026 年的 14.x 版本
├── NVIDIA 已经发布 Rubin 架构
└── AMD 仍然落后 4 年

追赶速度：
├── NVIDIA 每年迭代一次
├── AMD 每年追赶一点
└── 差距永远存在

七、硬件护城河：不只是软件

很多人以为 CUDA 只是软件，其实硬件也是护城河的一部分：

7.1 制程领先

NVIDIA GPU 制程 发布年份
H100 4nm (TSMC) 2022
B200 4NP (TSMC) 2024
B300 4NP (TSMC) 2025
Rubin R100 3nm (TSMC) 2026H2

台积电最先进的制程，优先给 NVIDIA。

7.2 HBM 内存领先

高端 AI 训练需要高带宽内存（HBM）：

GPU 内存规格 带宽
H100 80GB HBM3 3.35 TB/s
B200 192GB HBM3e 8 TB/s
B300 192GB+ HBM3e 8 TB/s+

HBM 由 SK 海力士、三星生产，技术门槛极高。NVIDIA 有优先供应权。

多卡训练需要高速互联：

互联技术 带宽 状态
NVLink 4.0 900 GB/s NVIDIA 专有，成熟稳定
NVLink 5.0 1.8 TB/s 2026 年推出
AMD Infinity Fabric ~400 GB/s 性能落后，稳定性差

八、总结：护城河是怎么挖出来的？

回到开头的问题：CUDA 的护城河是怎么一步步挖出来的？

答案：二十年持续投入 + 多层嵌套锁定。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
第一步：2006 年，投入 100 亿，发布 CUDA
        ↓ 让 GPU 可以做通用计算

第二步：2006-2012，免费开放 + 大学教育
        ↓ 培养第一批开发者

第三步：2012 年，AlexNet 证明 GPU+CUDA=AI 未来
        ↓ 学术界开始绑定 CUDA

第四步：2012-2022，持续迭代 + 构建软件栈
        ↓ cuDNN、TensorRT、NCCL 等核心库

第五步：2022-2026，大模型爆发
        ↓ CUDA 成为"空气"，无处不在

结果：五层护城河，竞品无法入场

核心逻辑：

护城河类型 形成方式
技术护城河 20 年迭代，3000+ 算子库
生态护城河 500 万开发者，学术界绑定
经济护城河 迁移成本太高，换不起
硬件护城河 制程、HBM、NVLink 领先

一句话总结：

CUDA 的护城河，不是某个天才的设计，而是二十年持续投入的结果。

它像一条河，起初只是一条小溪，没人注意。但英伟达持续挖了二十年，终于变成一条竞品无法跨越的大河。

参考资料