凯哥讲 AI | Claude 打穿 CUDA 的深度解读:从 All In AI 到 All By AI

凯哥讲 AI

从 All In AI到 All By AI

Claude 一个周末跑通 AMD 新 GPU 之后，真正崩塌的不是 CUDA，而是工业时代关于行业、组织、知识、时间、技术与工程边界的旧假设。

作者｜史凯（凯哥）

CUDA 没有在一个周末崩塌。

真正崩塌的是“复杂生态差距只能靠专家人年慢慢追赶”的旧假设

最近，一则消息在 AI 圈迅速传播。

AMD 给 Anthropic 提供了一套搭载 MI355X GPU 的新机架。按照传统经验，把一个前沿大模型迁移到新的 GPU 平台，从安装软件栈、适配框架、解决算子兼容，到定位性能瓶颈、调优内核、验证分布式通信，通常需要一支跨越模型、编译器、系统与硬件的工程团队，花费数周甚至数月。

但 Anthropic 联合创始人兼首席计算官 Tom Brown 在 AMD Advancing AI 2026 大会上讲述的版本是：团队先让一名工程师把 Claude 接到机器上，让它尝试把系统跑起来。等到周末结束，工作负载不仅已经运行，性能曲线还在持续改善。AMD CEO 苏姿丰听说 Anthropic 只有一名工程师在处理 MI355X 时，本来让团队赶紧提供支援，得到的答复却是：不需要，已经搞定。

故事随后迅速从一次实验变成了产业级合作。AMD 官方宣布，Anthropic 将在 Helios 机架级系统上部署最高 2GW 的 Instinct MI450 系列 GPU，首批 1GW 计划于 2027 年上半年启动；双方还将使用 Claude 优化 AMD GPU 工作负载、加速 ROCm 软件开发，AMD 也将在自身工程与产品研发体系中广泛采用 Claude。需要注意的是，已经用于上述探索的是 MI355X，而未来 Helios 大规模部署采用的是 MI450 系列中的 MI455X，二者不能混为一谈。

于是，一个足够抓眼球的标题出现了：

英伟达用二十年构筑的 CUDA 护城河，被 Claude 用一个周末跨了过去。

这个标题很有传播力，但如果我们只停在“Claude 会写 GPU 代码了”“AMD 终于能挑战英伟达了”，就低估了这件事真正的意义。

CUDA 并没有在一个周末崩塌。CUDA 从 2006 年推出至今，早已不是一个简单的编程接口，而是由编程模型、编译器、数学库、通信库、调试工具、性能分析工具、框架适配、开发者社区、人才供给和生产经验共同形成的复杂生态。NVIDIA 自己对 CUDA 的定义也从来不只是一门语言或一个 API，而是一整套加速计算平台。、

真正被动摇的，是 CUDA 护城河背后的一个更底层假设：

复杂技术生态的差距，只能靠大量工程师、漫长时间和一代代隐性经验慢慢追赶。

Claude 跑通 MI355X 的故事第一次让行业大规模看到，当文档、接口、工具、遥测、测试环境与执行权限都对 Agent 开放之后，过去按“专家人年”积累的生态差距，正在被改写成按“机器任务、并行 Agent 和验证循环”计算的新问题。

真正崩塌的不是某一条护城河，而是我们用来理解产业竞争、组织分工、知识积累和工程交付的旧坐标系。

这就是本文要讨论的主题：

AI 的下一阶段，不再是 All In AI，而是 All By AI。

一、先别急着宣布 CUDA 终结

一个周末背后，其实站着二十年的工程积累

我们必须先把这件事说准确。

所谓“Claude 独自跑通 AMD 新 GPU”，不意味着 Claude 在一个完全空白的世界里，凭空发明了驱动、编译器、算子和性能调优方法。它之所以能够工作，是因为它脚下已经有 PyTorch、ROCm、HIP、vLLM、容器、编译器、分析器、日志系统和大量开放代码；因为 AMD 愿意公开指令集信息，愿意把文档变成机器可理解的知识，把安装、诊断、部署和性能分析变成 Agent 可调用的工具。

换句话说，表面上是“一名工程师加一个 Claude”，背后却是：

数十年 GPU 与高性能计算知识；

AMD 多年建设的 ROCm 软件栈；

开源社区积累的框架、算子和部署经验；

前沿模型吸收的大量软件工程模式；

一套可以执行、观测、评测和回滚的工程环境。

所以，这个故事真正值得关注的地方，并不是“人类工程师没有写代码”，而是人类过去写过的代码、踩过的坑、形成的规范和积累的判断，开始被重新封装成 Agent 可以直接消费的生产资料。

AMD 在 Advancing AI 2026 上发布的 ROCm.AI，正是在主动完成这种封装。它并不是再增加一个聊天窗口，而是把四个关键部分组合起来：

第一，AMD Skills 将经过验证的 ROCm 知识、脚本和工程惯例提供给 Claude、Codex、Cursor、Gemini 等 Agent，让它们知道面对特定 AMD 硬件、ROCm 版本和软件组合时，应该走哪一条经过验证的路径。AMD 对 Skills 的解释非常值得企业管理者注意：普通文档描述全部选项，而 Skill 编码的是资深工程师在特定场景中会自然选择的“有观点的路径”。

第二，ROCm CLI 把安装、诊断、模型服务、升级等动作变成确定性、可脚本化、可授权的执行接口。Agent 不再只会给建议，它可以在许可范围内真正调用机器。

第三，ROCm Console 和遥测工具把日志、状态、性能与故障上下文暴露出来。Agent 不是执行完就结束，而是能够观察结果，知道系统是否真的运行、哪里变慢、哪一步失败。

第四，Hyperloom 把“理解工作负载—建立性能基线—发现瓶颈—生成优化—重新测试—验证正确性”组织成持续循环。其开源说明将这个过程概括为 Think、Decide、Implement、Benchmark，并同时针对主机代码和 GPU 内核进行优化。、

这四部分合在一起，才是故事的主角。

Claude 不是单独击穿 CUDA 的超级程序员。真正发生的是：模型能力、平台知识、执行工具、实时观测与验证闭环被组装成了一名可以在真实环境中工作的数字工程师。

这也是为什么“一个周末”比“一个模型跑在另一块 GPU 上”重要得多。

它证明了一件事：AI 的价值正在从内容生成进入环境执行，从回答问题进入改变世界状态，从“告诉人怎么做”进入“在可控边界内把事情做完”。

二、从 All In AI 到 All By AI

AI 从战略对象变成生产方式

过去三年，几乎所有企业都在讲 All In AI。

All In AI 的核心是资源配置。企业成立 AI 委员会，采购大模型，建设算力平台，启动知识库，做一批智能助手和 POC，希望证明自己没有错过新一轮技术革命。这个阶段当然必要，它解决的是“有没有 AI”的问题。

但 All In AI 有一个隐含前提：AI 仍然是被人建设、被人部署、被人使用的一类新技术。组织原有的结构基本不变，只是在研发、客服、营销、财务或供应链流程中增加一个 AI 工具。

而 All By AI 的含义完全不同。

它不再问企业“有没有使用 AI”，而是追问：

新产品是不是由人和 Agent 共同设计出来的？

软件、模型、数据产品和基础设施是不是由 Agent 参与建设和持续优化的？

业务流程是不是默认允许 Agent 在授权范围内行动？

组织知识是不是能够被机器理解、调用、验证和更新？

每一次生产活动是不是都能形成新的 Trajectory，反过来训练下一次执行？

企业是不是已经把“为人设计的系统”，改造成“人和 Agent 可以共同工作的环境”？

因此，All By AI 并不是“所有事情都让 AI 自己做”，更不等于“不要人了”。它是一种新的企业生产公式：

All By AI = Human Defines + Agent Executes + System Verifies + Organization Adopts + Governance Bounds

人负责定义价值、场景、责任和不可逾越的边界；Agent 负责搜索、分析、生成、操作、并行试验和高频迭代；系统负责用数据、测试、规则、仿真和真实反馈验证结果；组织负责把有效方案嵌入流程、岗位与经营机制；治理体系负责权限、审计、安全、合规和最终问责。

这五部分缺一不可。

如果只有模型，没有执行环境，AI 仍然只是顾问。

如果只有执行，没有验证，AI 就是一个速度极快但不可信的实习生。

如果只有验证，没有组织采纳，AI 最终只是一个漂亮的 POC。

如果只有效率，没有价值判断，AI 会以更高速度制造更多无效代码、无效流程和无效产品。

如果没有治理边界，所谓自主智能就可能变成责任失控。

所以，All In AI 是“把 AI 放进企业”；All By AI 是“重新设计企业，让 AI 成为生产过程中的参与者”。

从前者到后者，不是技术升级，而是生产关系重构。

边界并没有简单消失，而是在被重新定价。AI 把原来依靠岗位、部门与专家人年完成的连接，压缩成可以并行执行、持续验证的价值循环；与此同时，价值、责任、安全与伦理边界必须被画得更加清楚。

三、CUDA 故事揭示的第一重变化

技术边界正在从“封闭栈”变成“可学习界面”

过去，硬件与软件之间的边界由专业分工维持。

芯片公司设计硬件和指令集；系统软件团队建设驱动、编译器与库；框架团队完成适配；模型团队使用上层接口；应用团队几乎不需要理解底层。这种分层极大提升了工业效率，却也形成了漫长的依赖链。任何新硬件想进入生态，都必须从底层一层层向上适配。

Agent 的出现并没有让分层架构消失，却改变了跨层协作的成本。

当 Agent 可以同时阅读模型结构、框架代码、编译日志、GPU Trace、ISA 信息和性能数据时，它不再像传统组织中的某个岗位，只看到自己负责的一小段。它可以跨越抽象层，在“模型为什么慢”“框架调用了什么”“通信在哪里阻塞”“内核如何映射到硬件”之间连续推理。

这使技术竞争从“谁拥有更封闭、更庞大的栈”，逐步增加了一个新的维度：

谁的技术栈对 Agent 更可读、更可调用、更可观察、更可验证。

未来，芯片参数表上不只会比较峰值算力、显存容量、带宽、互联和能效，还会比较另一组过去不存在的指标：

• Agent 能否理解这块硬件？
• 能否自动完成环境配置？
• 能否定位跨层瓶颈？
• 能否生成并验证定制优化？
• 能否把一次优化沉淀为下一次可复用的 Skill？
• 能否在企业安全边界内自主行动？

这意味着技术产品将面对一种新的“客户”——不是人类开发者，而是开发者背后的 Agent。

过去的开发者体验叫 DX，下一阶段还会出现 AX，也就是 Agent Experience。

文档只适合人读，已经不够；文档需要结构化、可检索并与版本对应。命令可以执行，也不够；命令需要确定性返回、清晰错误和权限控制。系统有日志，也不够；日志需要能够支撑 Agent 判断状态、定位因果并发起下一步操作。API 可以调用，也不够；API 需要语义清晰、边界明确、可审计并且有测试环境。

技术护城河因此不会消失，但构筑方式会改变。

过去，复杂和不透明本身可以形成锁定；未来，越容易被 Agent 理解和使用的平台，越可能获得更快的生态扩张。过去开源意味着把代码给人，未来开放意味着把能力暴露给 Agent。

四、第二重变化

工程边界被打破，代码不再是交付中心，环境才是

OpenAI 在 2026 年公布过一次极具代表性的内部实验：一个团队用 Codex 建设并运行了一套内部产品，应用逻辑、测试、CI 配置、文档、观测工具等代码全部由 Agent 生成，开发时间估算约为传统手写方式的十分之一。OpenAI 对这次实验的总结不是“模型写代码真快”，而是工程师的主要工作从写代码转向设计环境、表达意图和构建反馈回路。

这与 Claude 跑通 MI355X 是同一件事的两个截面。

当代码生成成本快速下降，代码本身不再是软件工程中最稀缺的部分。真正稀缺的是：

• 问题是否定义正确；
• 环境是否对 Agent 清晰可见；
• 架构约束能否自动执行；
• 测试是否真正代表业务验收；
• 失败是否能被迅速发现；
• 权限是否与风险匹配；
• 变化能否安全上线和回滚；
• 结果是否真的被业务采纳。

传统软件工程把代码当成中心，需求、测试、部署和运维围绕代码展开。Agent 时代的工程中心将变成“可验证的状态变化”：系统从状态 A 到状态 B，是否实现了预期业务结果，是否符合质量、安全与合规边界。

因此，需求与代码的边界开始模糊。高质量需求不再只是写给程序员看的自然语言，而会逐步成为 Agent 可执行、测试系统可验证的任务契约。

开发与测试的边界开始模糊。Agent 每生成一个方案，都可以同时生成测试、运行验证、分析差异并继续修改。

开发与运维的边界开始模糊。Agent 不只写代码，还读取生产遥测、诊断异常、调整配置、生成补丁并准备回滚方案。

应用与基础设施的边界开始模糊。模型服务、GPU 调度、内存配置、并行策略和业务性能不再是互相隔离的问题，而成为同一条价值链中的联合优化对象。

软件与知识的边界也开始模糊。Skill 既可以是说明书，也可以包含脚本、模板、参考资料和验证标准；知识不再只供人阅读，而可以直接参与执行。

这就是为什么我一直强调：

AI Coding 不是代码生产率工具，而是软件工程生产关系的重构。

未来最优秀的工程师，不一定是亲手写代码最多的人，而是最擅长把目标、上下文、工具、约束和反馈组织成高质量执行环境的人。

五、第三重变化

知识边界被打破，隐性经验开始从“人的手感”变成“组织的可执行资产”

CUDA 最难复制的部分，从来不只是公开文档。

真正的差距存在于成千上万名工程师的隐性知识中：某个算子在什么形状下会变慢，某个通信策略在什么拓扑中容易拥塞，哪一种显存分配会引发碎片，哪个驱动版本与某个框架组合会出现异常，性能下降究竟来自 GPU 内核还是 CPU 喂数。

这些经验过去有三个特点：难以完整表达、难以快速传承、难以跨团队复制。

Agent 正在改变知识的载体。

一次成功的调优，不再只产生一段代码，而可以同时留下完整 Trajectory：当时的硬件、软件版本、输入、基线、观察、假设、动作、测试、结果和回滚条件。一次失败也不再只是“踩了一个坑”，而可以被沉淀为下一次搜索空间中的排除项。

于是，知识从静态文档变成了四种可执行资产：

第一种是Skill，告诉 Agent 在什么场景下应该采用什么经过验证的路径。

第二种是Tool，让 Agent 能够真正读取数据、调用系统和改变环境。

第三种是Eval，定义怎样才算正确、有效和安全。

第四种是Trajectory，记录问题、判断、行动与结果之间的完整因果链。

这四种资产结合起来，才形成企业真正的 AI 时代知识库。

传统知识管理经常失败，是因为企业把大量文档存进知识库，却没有解决“谁在什么情境下，依据什么信息，采取什么动作，如何知道结果好坏”。Agent 时代如果只是把旧文档向量化，再加一个聊天入口，仍然没有触及知识的生产性。

真正的知识工程不是让 AI 能够回答“公司以前怎么做”，而是让 AI 能够在当前上下文中，复用过去经过验证的经验，把任务继续向前推进。

因此，AI 打破了专家与新手之间的知识边界，但不会让专家失去价值。相反，专家的价值将从“亲自解决每一个问题”，转向“把自己的判断标准、关键变量、失败模式和验收方法转化为可复制的组织能力”。

过去，专家是解决问题的人；未来，真正稀缺的专家是能够教会一群 Agent 和整个组织如何持续解决问题的人。

六、第四重变化

组织边界被打破，一名工程师正在变成一支数字团队的指挥官

在传统组织中，一项新 GPU 适配任务可能需要平台工程师、框架工程师、性能工程师、模型工程师、DevOps 和项目经理共同协作。每个人拥有一部分知识和权限，信息在会议、工单、文档和排期中流动。

Claude 跑通 MI355X 的故事最具冲击力的部分，不是“一名工程师抵得上一支团队”，而是这名工程师的角色发生了变化。

他不再亲自完成每一个技术动作，而是负责给出目标、开放环境、设定边界、观察进展、处理例外并判断结果。一名工程师由执行者变成了 Agent Team 的任务设计者、环境管理员与最终责任人。

这会打破企业里长期存在的三种组织边界。

第一是职能边界。业务分析、产品、开发、测试、运维和数据工程之间的部分工作，可以在同一条 Agent Loop 中连续完成。人仍然拥有不同专业，但不再需要让每一次信息流动都穿过部门墙。

第二是层级边界。过去，复杂任务需要通过层层分解、汇报与协调来获得组织规模；未来，一名具备足够判断力的前线人员可以编排多个 Agent，同步完成研究、设计、实现、测试和分析。组织杠杆从“管理更多人”逐步转向“编排更多智能并对结果负责”。

第三是内外边界。供应商、客户、平台方与生态伙伴之间的协作，过去靠接口文档、项目会议和人工服务连接；未来，越来越多能力会以 Agent 可发现、可协商、可调用、可结算的方式进入同一个任务网络。

但这里也最容易产生一个危险误判：既然 Agent 可以跨界，是不是组织就不需要专业岗位、不需要管理、不需要流程？

恰恰相反。

执行成本下降以后，错误方向的规模也会同步放大。一个人可以调动几十个 Agent，意味着一个模糊目标、一项错误权限或一个失真的指标，也可能以过去无法想象的速度扩散。

所以，组织边界被打破之后，责任边界必须更加清晰。

谁定义任务？谁批准权限？谁拥有数据？谁判断验收？谁承担生产结果？什么情况必须停止？什么变化可以自动发布？什么变化必须由人签字？

All By AI 不是无组织化，而是从“以岗位和汇报线为中心的组织”，走向“以价值流、权限、状态和责任为中心的组织”。

七、第五重变化

行业边界被打破，所有企业都开始成为“模型公司、软件公司和数据公司”

AMD 是一家芯片公司，但 ROCm.AI 展示的已不只是芯片能力。它必须建设 Agent Skills、命令行执行层、遥测系统、自动优化 Agent、知识资产和开发者生态。

Anthropic 是一家模型公司，但它正在参与 GPU 工作负载优化、软件栈开发和基础设施协同设计。

前沿模型既是芯片的客户，又成为芯片软件生态的建设者；芯片既是模型运行的基础设施，又开始为 Agent 提供可学习、可执行的工程环境。

硬件公司、软件公司和模型公司的传统边界由此开始重叠。

这种变化不会停留在 GPU 行业。

在制造业，设备企业不再只销售机器，而要把设备说明、控制接口、故障模式、维修经验和性能数据变成 Agent 可以调用的能力。未来客户购买的不只是机床，而是“能够被 AI 持续优化的生产单元”。

在汽车行业，车企、供应商、软件平台、地图、能源与保险之间的边界会进一步模糊。智能汽车不只是一个产品，而是持续产生状态、动作和反馈的具身智能节点；企业竞争将围绕数据回流权、模型更新权、场景进入权和安全控制权展开。

在金融行业，银行和券商不再只是金融产品提供者，也必须成为实时数据公司、风险模型公司和智能流程运营商。研究、投顾、合规、客服、运营与软件交付会被同一个 Agentic Workflow 串联起来。

在医药行业，模型可以阅读论文、设计实验、分析数据、生成候选方案并辅助申报，但临床责任、伦理边界和监管证据不会因此消失。相反，企业必须把证据链设计成 Agent 工作的一部分。

在政府与城市治理领域，AI 不只是一个问答助手。规划、审批、监管、调度、执法和公共服务将逐步形成“意图—数据—分析—行动—反馈”的闭环。城市数字底座也将从给人展示态势，走向支持 Agent 在受控范围内参与决策与执行。

这说明，所谓“AI 行业”最终可能并不存在。

就像互联网不再是一个独立行业，而成为所有行业的基础连接方式；AI 也将从一个产业赛道，变成所有行业组织知识、调用能力和完成工作的通用生产方式。

All In AI 时代，企业问自己属于哪个行业；All By AI 时代，企业更需要问：我的哪些核心能力能够被 Agent 理解、调用、验证和持续进化？

八、第六重变化

时间边界被打破，二十年差距第一次可以被压缩成高密度的验证循环

工业时代，时间几乎是最公平也最残酷的壁垒。

一名优秀 GPU 工程师需要多年训练；一个成熟软件生态需要十年以上积累；一套组织能力需要反复经历项目、失败和复盘。资本可以买设备、买公司、买人才，却很难直接购买时间。

Agent 改写的不是物理时间，而是单位自然时间里可以完成多少次高质量认知与验证循环。

人类工程师一天可能提出几个假设、测试几种配置；多个 Agent 可以昼夜并行探索更多组合。人会疲劳，会遗忘，会因为组织边界重复踩坑；Agent 可以继承历史 Trajectory，把一次成功或失败立即转化为下一批任务的上下文。

于是，竞争的时间单位正在发生变化：

从项目周期变成反馈周期；

从年度版本变成持续实验；

从专家培养年限变成知识资产的复制速度；

从组织扩张速度变成 Agent 编排和验证吞吐；

从“多久能做出来”变成“多久能证明有效并安全进入生产”。

但必须看到，Agent 只能压缩“可数字化、可执行、可验证”的时间。

一块芯片的制造周期不会因为模型更聪明而凭空消失；真实道路测试、临床试验、材料老化、供应链交付和监管审批也有不可压缩的物理与制度时间。

因此，AI 对时间边界的真正突破，不是让一切瞬间完成，而是把等待、搜索、重复劳动、跨部门传递和低效试错从关键路径中大量移除，把宝贵的真实时间留给那些必须由现实世界给出答案的环节。

AI 不会消灭时间，但会重新定价时间。未来最昂贵的不是计算时间，而是没有反馈的等待时间；最稀缺的不是生成速度，而是获得真实结果的速度。

这也是 CUDA 故事最深的产业含义：二十年的积累仍然存在，但后来者第一次拥有了一种高密度吸收、执行和验证既有知识的新方法。

九、为什么边界被打破之后，Lean-FDE 反而变得更重要

看到这里，很多人会问：既然 Claude 已经可以自己调 GPU，未来是不是只需要更强的模型和更多 Agent？

我的答案恰恰相反。

模型越强，Agent 越多，Lean-FDE 越重要。

因为企业 AI 落地最难的问题，从来不是“能不能生成一个方案”，而是“面对一个混乱、模糊、充满利益关系和约束的真实现场，究竟应该解决什么问题，如何以最小成本验证价值，怎样安全进入生产，又如何把一次成功变成可复制能力”。

AI 擅长在给定目标下高速探索，但真实企业现场很少给出清晰目标。

客户说想做一个知识库，真实问题可能是售后响应链条过长；客户说想训练行业大模型，真实问题可能是数据责任和流程标准都没有统一；管理层说要降本增效，现场却无法回答成本发生在哪一步、谁会因为流程改变而受影响；技术团队做出一个准确率很高的模型，业务部门却不愿承担使用结果的责任。

这些都不是单纯的模型问题，而是价值、认知、工程和组织问题。

Lean-FDE 的核心定义是：

以客户和业务价值流为起点，以受控实验为方法，以智能体工程为手段，以生产采纳为闭环，以资产沉淀和持续复制为目标的企业 AI 前线交付操作系统。

它不是传统售前，不是驻场开发，也不是把咨询顾问、产品经理和工程师简单拼在一起。Lean-FDE 的使命，是站在真实业务现场，把混乱问题抽象成可验证任务，把 Agent 的可能性变成生产结果，再把一次项目经验沉淀成组织可复制的能力。

为什么前面一定要加 Lean？

因为 Agent 会把生产能力放大，也会把浪费放大。

如果问题定义错误，Agent 会更快地产出错误答案；如果流程本身没有价值，Agent 会更高效地自动化浪费；如果验收指标失真，Agent 会更努力地优化错误指标；如果组织没有采纳机制，Agent 会制造更多无人使用的 POC。

Lean 的本质不是节省几个人、缩短几天工期，而是持续识别真正的价值，压缩从问题到反馈的路径，用最小代价验证最关键的不确定性，并让学习发生在大规模投入之前。

为什么必须是 FDE？

因为 All By AI 不能只在总部实验室、技术中台或模型团队里发生。它必须进入业务现场，接触真实数据、真实系统、真实人员、真实流程和真实责任。只有站在前线，才能知道什么叫有效，什么可以自动，什么不能越界，什么结果会被组织真正采用。

所以，我把 Lean-FDE 在 All By AI 时代的作用概括为一句话：

AI 负责扩大可能性的边界，FDE 负责把可能性带入现场；Lean 负责确保我们没有用更快的速度奔向错误方向。

十、Lean-FDE 的 C6 能力

正是穿越六类边界所需要的新型生产能力

边界打破以后，组织需要的不是一个“全能 AI 工程师”神话，而是一套可以培养、协作和评测的复合能力模型。Lean-FDE 的 C6，分别是价值感觉、问题重构、抽象建模、受控实验、智能体工程和组织推动。

它们与前面六类边界的重构并非巧合，而是一一对应。

价值感觉，是在大量“可以做”的机会中判断什么值得做。All By AI 会让可行方案爆炸式增加，真正稀缺的反而是对价值、成本、风险和采纳阻力的敏感度。

问题重构，是不接受客户最初给出的技术表述，而是回到业务结果、行为变化和约束条件。客户提出的往往是解决方案，不是真问题；FDE 要把“做一个 Agent”重构为“在哪一个决策点上，让什么角色基于什么证据作出更好的行动”。

抽象建模，是从混乱现场中识别关键对象、状态、规则、动作、反馈和责任。没有抽象，Agent 只能处理碎片；有了抽象，企业才能把真实世界变成模型可理解、系统可执行的任务空间。

受控实验，是把宏大转型拆成最小价值闭环。不是做一个缩小版大项目，而是找到最关键的不确定性，用最小成本获得真实证据。POC 的目标不是证明模型能跑，而是证明价值链愿意改变。

智能体工程，是把模型、上下文、工具、记忆、权限、工作流、评测、观测与人类监督组织成可靠系统。它关注的从来不是“用了几个 Agent”，而是 Agent 能不能在真实环境中完成可验证工作。

组织推动，是把有效结果转化为岗位行为、流程机制、管理指标与利益关系的变化。AI 项目上线不是终点；只有业务愿意使用、管理者愿意承担责任、流程真的发生变化，价值才开始发生。

这六项能力决定了 FDE 不是某一种岗位名称，而是一种新的企业价值生产能力。

十一、All By AI 企业需要的，不是更多 POC，而是一套“AI 可执行企业”架构

AMD 的启示不应该被企业理解成“我们也去采购一个更强的 Coding Agent”。真正应该学习的是：AMD 正在把自己的技术栈改造成 Agent 能够理解和行动的环境。

同样，企业也需要逐步把自身变成“AI 可执行企业”。

一个 AI 可执行企业至少包含五层。

最底层是真实价值流。所有 Agent 任务最终必须连接到客户、收入、成本、风险、质量、效率或公共价值。没有价值流，AI 只是技术表演。

第二层是机器可读的业务上下文。包括组织、产品、客户、资产、合同、流程、规则、指标、权限和历史决策。它们不能散落在人的记忆与不同文档中，而要形成版本化、可追溯的业务语义。

第三层是机器可调用的工具与数据。Agent 需要受控访问 API、数据库、软件系统、仿真环境和现实设备。每一次调用都应具有身份、权限、用途限制、日志和审计。

第四层是机器可验证的反馈系统。包括自动化测试、业务指标、规则校验、模型评测、数字孪生、灰度发布、人工复核与生产遥测。Agent 只有获得可靠反馈，才可能真正学习。

第五层是人类可治理的责任系统。企业必须定义哪些任务可以自主执行，哪些需要审批，哪些属于禁止区域；必须提供暂停、回滚、追责和争议处理机制。

这五层共同构成企业的 Agent Harness。模型只是其中的大脑，企业环境则是它的眼睛、手脚、记忆、边界和反馈神经。

因此，未来企业之间的 AI 差距不会主要来自是否买到了同一个模型。领先企业真正拥有的，是更完整的环境：

• 更真实的场景进入权；
• 更高质量的数据与反馈获取权；
• 更清晰的业务语义；
• 更成熟的工具与权限接口；
• 更多经过验证的 Trajectory；
• 更短的实验到生产路径；
• 更强的组织采纳和治理能力。

这些能力无法通过一次模型采购获得，也不会随着基础模型价格下降而自动普及。

模型决定智能的起点，企业环境决定智能能走多远；模型能力趋同以后，环境可执行性就是新的护城河。

十二、未来真正的护城河，不再只是生态规模，而是“可验证经验的复利”

如果 Agent 能够快速学习一个平台，是否意味着所有技术护城河都会消失？

不会。

护城河会从静态占有转向动态学习。

过去的护城河可能是专有接口、封闭文档、稀缺专家和庞大存量代码。未来更强的护城河将来自五种能够持续复利的资产。

第一是场景权。企业是否能够进入真实业务现场，获得高价值问题、真实约束与生产反馈。没有场景，模型只能在假设世界中优化。

第二是行动权。Agent 是否可以在合法、安全、受控范围内调用工具、修改系统和影响现实状态。没有行动权，AI 永远停留在建议层。

第三是反馈权。企业是否能够知道一次行动最后产生了什么结果。没有结果反馈，就没有真正的学习闭环。

第四是 Trajectory 资产。企业是否能够把每一次“状态—判断—动作—结果”沉淀为可复用、可评测、可训练的经验。原始数据规模很重要，但能够解释为什么采取行动以及行动是否有效的数据更稀缺。

第五是组织复制能力。一个优秀工程师用 Agent 完成一次任务不难，难的是让不同团队在不同场景中持续复制成功，同时保持质量、安全与经济性。

这五种资产构成新的动态护城河。

AMD 如果只是让 Claude 偶然跑通一台机器，这件事的价值有限；真正有价值的是把知识封装进 Skills，把动作封装进 CLI，把反馈封装进 Console，把优化封装进 Hyperloom，再把每一次执行经验反馈到后续平台与模型中。

从一次奇迹到一套机制，从个人能力到群体能力，从项目结果到资产复利，这正是 Lean-FDE 要完成的最后一公里。

个人英雄解决一次问题，成熟组织复制解决问题的能力；AI 原生组织则让每一次解决问题，都自动提高下一次解决问题的能力。

十三、企业现在应该怎么做：不要从“部署更多 Agent”开始

面对 All By AI，企业最容易犯的错误，是立即启动一个大而全的 Agent 平台项目，然后要求所有部门上报场景。

这很可能重演过去的数据中台、数字化转型和大模型 POC：平台先建起来，业务价值以后再找；场景上报很多，生产采纳很少；演示越来越炫，真实经营变化越来越弱。

更可行的路径，是从一条高价值、强反馈、可授权的真实价值流开始，用 Lean-FDE 完成一个最小闭环。

第一个 30 天：不是选模型，而是找到值得改变的决策点

选择一个频率足够高、结果可观察、数据可获得、责任人明确的业务问题。不要写“建设智能客服”“建设供应链 Agent”，而要明确：哪个角色在什么时刻作出什么决策，目前为什么慢、为什么错、为什么成本高，改善后用什么业务结果验收。

由业务负责人、FDE、领域专家、数据与工程人员组成最小 Squad。团队第一阶段最重要的产出不是 PRD，而是一张清晰的问题模型：目标、对象、状态、规则、动作、反馈、风险和责任。

第二个 30 天：把现场变成 Agent 可以理解和验证的环境

整理最小必要上下文，不追求一次性治理全部数据；开放最小必要工具，不追求打通全部系统；构建一组可以代表真实结果的 Eval，不用“回答看起来不错”作为验收。

把专家的关键判断、常见失败模式和操作路径转化为 Skill，把系统动作转化为有权限边界的 Tool，把真实业务结果转化为 Eval，把每一次试验过程记录为 Trajectory。

第三个 30 天：让 Agent 进入受控生产，而不是停在演示

采用分级上线：建议模式、影子模式、人机协同模式、有限自主模式、条件自主模式逐步推进。每一级都要有明确的进入条件、退出条件、异常处理和回滚机制。

同时评估四类指标：业务价值是否发生、交付周期是否缩短、系统质量是否可靠、组织是否真正采纳。只有这四类指标同时成立，才能继续扩大范围。

90 天之后，企业得到的不应只是一个 Agent，而应该得到第一块可复制资产：一套问题模型、一组 Skills、一套工具接口、一组 Evals、一批经过验证的 Trajectories，以及一套从实验进入生产的治理机制。

这才是 All By AI 的正确起点。

十四、管理者必须改变的五个判断

第一，不要再用“AI 项目数量”衡量 AI 战略。项目多不等于价值多，Agent 多也不等于生产力高。更应该看多少关键价值流已经形成“意图—执行—验证—反馈—改进”的闭环。

第二，不要再把 AI 归口为单一技术部门。技术部门可以建设平台，但无法独自定义业务价值、改变岗位行为或承担经营结果。AI 必须在前线以跨职能 Squad 的方式发生。

第三，不要把文档数字化误认为知识资产化。真正的知识资产必须能够被 Agent 在正确情境中调用，能够引导行动，并且能够被结果验证。

第四，不要只追求模型自主性，要优先建设环境可控性。企业不是因为 Agent“更自由”而获得价值，而是因为任务更清楚、工具更可靠、反馈更及时、权限更匹配而获得价值。

第五，不要把人机协同理解为“AI 给建议、人来审批”这么简单。真正的人机协同，是重新分配认知、执行和责任：人把精力集中在价值判断、复杂抽象、例外处理、伦理与最终责任上；Agent 承担大规模搜索、生成、操作和验证；系统确保两者的协作过程可以被观察、评估和改进。

十五、为什么这一次，我想邀请你“拼”一个 Lean-FDE 班

写到这里，我不想把 Lean-FDE 停留在一套看起来完整的方法论里。

如果 All By AI 真的是一种新的生产方式，那么学习 Lean-FDE 的方式，也不能还是一个老师讲、几十个人听，课程结束以后各自收藏一份 PPT。那种学习可以增加概念，却很难改变现场。Lean-FDE 必须在真实问题、真实约束、真实协作和真实反馈中长出来。

所以，我想发起的不是一门普通公开课，而是一个Lean-FDE 拼班计划。

5 个人组成一个最小作战组，10 个人组成一个实战班。不是为了凑人数，而是为了凑齐一条 AI 价值闭环真正需要的能力。

拼班不是团购，而是在组建一支最小 AI 交付队

一个真实的企业 AI 项目，很少失败在“没有人会调用模型”。它更常失败在五件事没有同时发生：业务目标没人真正负责，现场知识没有进入方案，产品与流程没有被重新设计，技术能力无法进入生产，组织也没有为结果采纳做好准备。

这正是为什么一个 Lean-FDE 小组建议由 5 个不同视角构成。

这 5 个角色可以来自同一家企业，也可以由不同企业、不同专业背景的人共同组成。重点不是职务名称完全对应，而是一个小组必须具备这五种思考能力。一个人可以兼任两种视角，但不能让任何一种关键视角缺席。

为什么一个班是 10 个人，而不是 50 人、100 人？

因为两个 5 人小组刚好形成最小的对照学习机制。一个小组在自己的场景里做问题重构、最小闭环和受控实验，另一个小组用不同的行业经验挑战它的假设、验收标准和组织路径。十个人既能形成足够丰富的案例密度，又能保证每个人被看见、每个问题被讨论、每个方案得到反馈。

一个小组解决一个真实问题，两个小组互相校验解决问题的方法。10 个人得到的不是 10 份听课笔记，而是 10 个视角、2 条价值闭环和一套可以带回企业继续复制的共同语言。

你不是带着“想学 AI”来，而是带着一个真问题来

这个班不会从工具清单开始，也不会用几十个 Agent 案例制造热闹。每位成员都要带着一个真实问题进入课堂：它可以来自企业 AI 转型、数据产品、智能体应用、软件工程、供应链、客服、营销、金融、制造、交通、城市治理，也可以来自一家创业公司的新产品。

问题不要求一开始就定义得很漂亮。恰恰相反，Lean-FDE 的第一项工作，就是把“我要做一个知识库”“我要训练行业大模型”“我要建设 Agent 平台”这类解决方案式表达，重新拆回业务结果、关键决策、现场行为、约束条件和责任边界。

围绕这个真实问题，每个小组要完成一条从认知到生产的最小闭环：

• 找到一条值得改变的价值流，而不是罗列一批可以使用 AI 的功能；
• 把模糊诉求重构为对象、状态、规则、动作、反馈与责任；
• 设计最小可行的 Agent Harness，包括上下文、工具、权限、评测和人工控制；
• 用受控实验验证最大的不确定性，不把 POC 成功误认为业务成功；
• 形成进入真实生产的采纳路径、风险边界和下一轮迭代计划；
• 把过程沉淀为问题模型、Skills、Tools、Evals 与 Trajectories，让一次项目变成可复制资产。

最终带走的，不只是一张证书或一套课件，而应该是一份与你的真实业务直接相关的 Lean-FDE 作战包：价值假设、问题地图、最小闭环设计、Agent Harness 蓝图、评测集、90 天行动路线和组织采纳方案。

这不是一门适合所有人的课

如果你只是想快速收集一套最新 AI 工具，想听完以后再决定做什么，或者希望把真实问题完全交给老师替你解决，这个班可能并不适合你。

但如果你是企业业务负责人、数字化与 AI 负责人、产品和技术负责人、行业专家、咨询顾问、创业者，或者正在从传统交付走向 FDE 的一线实践者，并且你已经意识到“会用模型”与“能把 AI 变成业务结果”之间隔着一整套现场能力，那么你会在这个班里遇到真正的同路人。

这里不按职位高低分组，只按问题是否真实、参与是否投入、结果是否可验证来协作。我们不承诺用几堂课解决一家企业的全部转型问题，但会共同完成最关键的一步：让一个模糊的 AI 想法，第一次变成可行动、可验证、可进入生产的价值闭环。

拼班规则：先组队，再开班

• 已经有 5 位伙伴：可以按完整小组申请，带同一个企业场景，也可以带 5 个相互关联的问题。
• 目前只有 1—4 人：可以进入候组池，根据行业、角色与问题互补性匹配队友。
• 满 10 人组成两个小组后开班；每班严格控制 10 人，确保每个真实问题都有足够时间被讨论与验证。
• 报名不是简单占位，需要说明自己的角色、行业、真实问题，以及能否投入到小组共创与作业验证。

我越来越相信，未来真正稀缺的不是“学过 AI 的人”，而是能够站在复杂现场里，把业务、数据、模型、工程、组织和责任连接成闭环的人。

你不是来听我讲 Lean-FDE。

你要带着一个真实问题进来，让自己成为 Lean-FDE。

十六、一个周末之后，世界不会立即抛弃 CUDA，但企业必须抛弃旧的 AI 观

CUDA 的生态不会在明天消失。NVIDIA 的软硬件协同、库、工具、社区、生产验证和客户基础仍然强大。把一次引人注目的工程进展直接宣布为“二十年护城河归零”，既不严谨，也不利于我们真正理解产业变化。

但是，另一个更重要的事实已经无法忽视：

过去只有靠时间才能积累的能力，正在被重新编码成 Agent 可以学习、调用、验证和复制的系统。

当说明书开始面向机器编写，当专家经验开始被封装为 Skill，当软件工具开始为 Agent 暴露执行接口，当遥测系统成为 Agent 的观察能力，当测试和业务指标成为它的反馈回路，AI 就不再只是产品里的一个功能。

它开始参与建设产品、优化基础设施、组织知识、运行流程，并进一步生产下一代 AI。

这就是从 All In AI 到 All By AI 的分水岭。

All In AI 讨论的是企业愿意为 AI 投入多少资源。

All By AI 讨论的是企业有多少工作方式、知识资产、软件系统和组织机制，已经允许 AI 参与价值创造。

All In AI 的竞争焦点是模型、算力、数据和预算。

All By AI 的竞争焦点是场景、上下文、工具、权限、反馈、Trajectory、治理与生产采纳。

All In AI 容易制造一批 AI 项目。

All By AI 要重构的是企业本身。

在这个过程中，行业边界会被重新组合，组织边界会被重新划分，知识边界会被持续穿透，技术与工程边界会变得流动，时间会被重新定价。

但越是在边界被打破的时代，价值边界、责任边界、安全边界和伦理边界越需要被清晰定义。

因此，未来最重要的角色，不是最会调用模型的人，也不是最会制造 Agent 的人，而是能够站在真实业务现场，把价值、问题、上下文、工具、实验、工程、组织和治理连接成闭环的人。

这就是 Lean-FDE。

它不负责制造更多 AI 幻觉，而负责把 AI 变成真实生产力；不以完成一个原型为终点，而以业务采纳和持续结果为闭环；不满足于一次项目成功，而要把成功沉淀为组织可复制、可经营、可进化的能力。

最后，用几句话总结这场变化：

CUDA 没有在一个周末崩塌，真正崩塌的是“生态差距只能靠人年追赶”的旧假设。

All In AI 是把 AI 当作战略对象，All By AI 是把 AI 变成新的生产方式。

模型不是新的组织，只有当目标、工具、权限、反馈和责任被重新设计，Agent 才会成为生产力。

代码生成成本越低，问题定义、验收设计和生产采纳就越昂贵。

AI 打破专业边界，不代表专业消失；它让专业从个人手感变成组织可以复制的执行资产。

未来企业最深的护城河，不是拥有多少数据，而是拥有多少“真实场景—有效行动—结果反馈”的闭环。

AI 不会消灭时间，但会重新定价时间；没有反馈的等待，将成为最昂贵的浪费。

AI 负责扩大可能性的边界，FDE 负责把可能性带入现场；Lean 负责确保我们没有用更快的速度奔向错误方向。

个人英雄解决一次问题，成熟组织复制解决问题的能力；AI 原生组织让每一次解决问题，都提高下一次解决问题的能力。

未来的竞争，不是谁 All In AI 得更早，而是谁更早完成从 All In AI 到 All By AI 的组织跃迁。

凯哥讲 AI｜智胜系列

策略决定边界，洞察穿透表象，行动创造价值。