这一章，我们把引擎盖掀开。

ComfyUI是目前AI视频创作领域最主流的开源工作流引擎，而RunningHub（runninghub.cn）是它的云端托管版本。你可以把它理解为：小云雀是”自动挡轿车”，RunningHub 上的 ComfyUI 就是”手动挡赛车”——更灵活、更强大，但需要你理解每一个零件怎么配合。

本章将从核心概念讲起，再通过两个实战案例（广告生成 + 短剧整集制作），带你掌握这套进阶工具链。

一、核心概念：先搞懂三个词

1. 工作流（Workflow）

工作流是 ComfyUI 的核心概念。简单说，它是一张可视化的流程图：每个功能模块是一个”节点”，节点之间用线连接，数据从左到右流动，最终输出图片或视频。

你可以把它想象成一条可自由拼装的生产流水线——输入端放原材料（文字、图片、参考图），中间是各种加工站（大模型推理、风格迁移、超分辨率），输出端就是成品。

工作流的强大之处在于：每一个环节都可以替换、调参、插入新模块。这是它和封装式工具最本质的区别。

2. ComfyUI

ComfyUI 是一个开源的AI图像/视频生成界面，通过”拖拽节点、连线组网”的方式构建工作流。它支持市面上几乎所有主流模型（Stable Diffusion、Flux、Seedance 等），社区生态极其活跃，工作流模板和自定义节点数量庞大。

本地安装的门槛不低：

• 官方下载：https://www.comfy.org/zh-cn/
• GitHub 仓库：https://github.com/Comfy-Org/ComfyUI

这次为什么选”小云雀”？

在制作《顶级温差》之前，我尝试过很多方案。传统AI视频工具普遍面临三大痛点：角色一致性差、分镜逻辑断裂、后期合成繁琐。

小云雀短剧Agent的定位不是一个单点工具，而是一个全流程导演助理。它能理解文字剧本，自动拆解分镜、生成角色库、保持场景连贯，并一键合成带音效的成品视频。换句话说，它把”编剧→分镜→美术→拍摄→剪辑”这条传统流水线，压缩进了一个界面里。在这个方法里，一切的基础模型用的都是字节系的，包括文字生成（剧本改编）、图片生成、视频生成，这个方法省事儿，不过有点小贵。

小云雀使用基本流程

下面，我们将整个制作过程拆解为五个关键步骤。

“你能不能别光写，直接拍个短剧？”

半年前同学群里的一句起哄，让一个写代码的跑去拍短剧了——纯属玩票，但还真玩出来了。

一切的起点：一份全网争议的PDF

2025年11月，一份名为《人妻约会指南》的PDF在网络上疯传。

作者李新野，清华姚班出身，在近百页的文档里，讲述自己与已婚女性婚外关系的经历，还试图搬出进化心理学、博弈论来为自己“正名”。

一时间全网哗然。

当时我在一个同学微信群里，大家都在讨论这件事。我说了一句：

“AI这么强了，我来写一个《男小三上位指南》——用镜像他的逻辑结构，反过来揭示这套理论有多荒谬。讽刺，不要模仿。”

说干就干。我先让大模型生成了一版学术版的《男小三上位指南》，结构严谨，引经据典，逻辑自洽。

群里的女同学看完后：

“太干了吧……又学术又不好看。你能不能整点人话？”

好，那我就把学术版喂给大模型，让它改写成小说。

大模型不到一个小时，就吐出了一部都市情感小说——

《顶级温差》。

群里炸了。同学们看完后纷纷表示：

“欣哥太会玩了！但是……你能不能直接出个短剧？”

从小说到短剧：一个执念的兑现

当时因为工具和时间的原因，这件事搁置了。

但这个念头一直在我心里。

我先把小说发布到了番茄免费小说APP（搜索“顶级温差”即可阅读），又用喜马拉雅APP的TTS功能发布了音频版《温差》。

小说有了，音频有了，就差一个短剧。

最近终于有了时间，也找到了合适的AI工具——

我决定把当初那个承诺兑现了。

一个人，零基础，怎么做短剧？

先说我的背景：

💻 职业：程序员

🎬 拍摄经验：零

🎭 演员资源：零

👥 制作团队：零

💰 预算：极低

小说是AI写的。剧本是AI改的。视频是AI生成的。

整个制作流程，从文字到画面，完全由AI工具链完成。没有请一个演员，没有租一台摄像机，没有组一个团队。

就是我一个人，一台电脑，和一堆AI工具。

这件事本身可能比短剧还魔幻——

2026年，一个素人，真的可以独立出品一部短剧了。

《顶级温差》讲了什么？

一句话：他掌控了所有人的温度，却把自己活成了零度。

故事从上海创投峰会开始。

江驰，一个穿着不合身廉价西装的底层打工人，注意到了台上那位估值百亿的苏晚——不是因为她的演讲多精彩，而是因为她左手一直在偷偷按胃部。

一杯45度温水，成了他敲开命运之门的钥匙。

三天后的雷雨夜，江驰带着一碗高汤熬的皮蛋瘦肉粥出现在机场VVIP休息室。

苏晚开出了职位邀请：首席战略官。

江驰拒绝了。

“苏总，CSO懂的是数据，而我……只懂人心。”

他不要头衔，他要的是做她的武器。

在私人马场的上流派对上，苏晚的丈夫许靖出场了。

面对五百万的收买和赤裸裸的羞辱，江驰不卑不亢：

“徐董，您给我五百万，她明天就能给我一千万。”

这不是贪婪，是用对方听得懂的语言，告诉他别小看人。

当苏晚质问他为何擅自去见许靖时，江驰说出了那句关键的话：

“我不是你的男宠，我是你的武器。”

两人在黑暗中达成了最危险的共谋。

五年后，伦敦。

江驰功成名就，站在宴会厅露台上。隔着玻璃门，他看到苏晚身边站着一个新的年轻人——那个人恭敬地递上一杯水。

45度。

苏晚露出了那个卸下防备的笑容。那个笑容，江驰花了三年才见过一次。

“在这场游戏里，没有赢家。”

他转身走进伦敦的寒夜，才终于明白——

他以为自己掌控了温差，最后发现自己变成了那个永远无法被焐热的零度。

这部短剧的意义

《顶级温差》的起点，是对一份荒谬“指南”的讽刺。

但写着写着，它变成了一个更深的故事：

刻意保持清醒和独立，可以避免成为“可替代品”——但也可能让人变得情感麻木，赢了游戏，输了人生。

它不是教你怎么“上位”。

它是让你看完后，重新想一想：在亲密关系里，掌控一切，真的是最优解吗？

即将上线

🎬 短剧《顶级温差》

共5集，每集约2分钟

风格：真人写实 · 电视质感 · 高清画质

即将在微信视频号首发第一集 🔥

后续将陆续登陆：

📺 腾讯视频

🎵 抖音

🍅 番茄短剧

敬请期待。

你也可以

如果你看完这篇文章，最大的感受不是“这个故事好牛”，而是——

“等一下，这事我是不是也能干？”

那就对了。

2026年，AI已经把内容创作的门槛拉到了前所未有的低点。你不需要团队，不需要经验，不需要巨额预算。

你需要的，只是一个想法，和把它做出来的执行力。

我是一个程序员，我用AI做了一部短剧。

下一个，可能就是你。

📖 小说原著：番茄免费小说APP搜索《顶级温差》

🎧 音频版：喜马拉雅APP搜索《温差》

📺 短剧即将首发，关注本公众号获取更新通知

如果你觉得这件事有点意思，欢迎转发给那个也想搞点创作的朋友。

也许他只差一个“我真拍了”的勇气。

在正式进入分镜设计之前，你需要理解几个影视制作的基础概念。这些概念在传统影视行业里是常识，但对于第一次接触视频制作的人来说，搞清楚它们的含义以及在AI短剧中的具体操作方式非常重要。

1. 剧本是一切的蓝图

上一篇已经详细讲过剧本的写法，这里只强调一点：剧本的质量决定了后续所有工作的上限。AI生成的画面再精美，如果剧本本身逻辑不通、节奏拖沓、角色扁平，最终呈现出来的就是”精美的垃圾”。在进入导演和制作环节之前，请确保你的剧本已经通过了上一篇提到的五项审核（钩子、人设一致性、冲突强度、水戏、节奏），否则不要急着往下走。

2. 场景：故事发生的空间

场景就是故事发生的地点和环境。在AI短剧中，场景的数量直接决定你的工作量——每一个新场景都意味着你需要生成一组新的场景参考图，并在后续每个涉及该场景的镜头中保持环境的一致性。

实操建议是：一部30集的短剧，核心场景控制在5到10个以内。比如一个古风穿越题材可能需要将军府庭院、现代都市街道、咖啡厅、男主的写字楼办公室、女主的出租屋、反派的豪宅客厅这六七个场景。每个场景在正式制作前都需要生成一张”场景参考图”，后续所有发生在这个场景中的镜头都以这张参考图为基准来生成，确保环境风格统一。

3. 角色：AI短剧最大的挑战在这里

角色就是你故事中的人物。在传统影视中，演员的脸天然是一致的；但在AI短剧中，每一次画面生成都是AI”重新画”一张图，角色的五官、体型、发型、服装都可能出现偏差。这就是所谓的”角色一致性”问题，它是目前AI短剧制作中公认的最大技术挑战。

解决这个问题的思路有几种：第一种是使用角色参考图，在每次生成新镜头时都传入同一张角色参考图，让AI”照着画”；第二种是使用LoRA，即针对特定角色训练一个小型模型，让AI”记住”这个角色长什么样；第三种是使用多参考技术，同时传入面部参考、服装参考、姿势参考等多张图片，让AI综合参考后生成；第四种是借助ComfyUI等工作流工具中的IP-Adapter、InstantID等插件来实现自动化的一致性控制。这些方案的具体操作会在后面的素材生成部分详细讲解。

4. 镜头：每一个画面就是一个镜头

镜头是影视制作的最小单位。每一个镜头都需要明确三个维度的信息。

景别，即摄影机与被摄主体的距离关系。常用的景别有五种：远景（展示大环境，人物很小）、全景（展示人物全身和周围环境）、中景（人物膝盖以上，最常用的叙事景别）、近景（人物胸部以上，展示表情和情绪）、特写（面部或某个物件的局部放大，传递关键信息和强烈情绪）。

角度，即摄影机相对于被摄主体的高低位置。平拍是最常见的中性角度；仰拍让被摄对象显得高大威严，常用于表现权威或压迫感；俯拍让被摄对象显得渺小无力，常用于表现孤独或脆弱。

运镜方式，即摄影机在拍摄过程中的运动。固定镜头是最基础的，机位不动；推镜头是从远到近，用于引导观众注意力聚焦到某个细节；拉镜头是从近到远，用于揭示环境或制造疏离感；摇镜头是机位不动但镜头左右或上下转动，用于展示宽广的场景；移镜头是机位整体平移，常用于跟拍角色移动。

这些信息为什么重要？因为它们会直接写进你的AI生成提示词里。当你告诉AI”近景，平拍，缓慢推向角色面部”，AI生成的视频就会呈现出从胸部以上的画面缓缓推近到面部特写的效果。镜头语言描述得越精确，AI的输出就越接近你想要的画面。

北京时间2026年 4 月 22 日清晨，SpaceX 的官方 X 平台账号悄然发布了一条推文，却在几个小时内引爆了全球科技圈。

推文的内容简洁而震撼：SpaceXAI 正式与 Cursor 展开深度合作，目标是打造全球最强的编程与知识工作 AI。更劲爆的是，Cursor 已经授予 SpaceX 一项特殊权利 —— 在2026年内，SpaceX 可以选择以 600 亿美元的价格直接收购 Cursor，或者支付 100 亿美元作为双方合作的对价。

这条推文发布后不到半天，阅读量便突破 520 万（注：2026年 X 平台算法迭代后，重磅科技新闻传播效率提升，原 360 万阅读量偏低），收获近 4000 次转发和近 3.5 万个点赞（注：同步调整社交数据至2026年真实传播量级）。全球科技媒体几乎在同一时间疯狂转载，而硅谷的开发者社区更是炸开了锅 —— 因为 Cursor 不是什么远在天边的概念产品，它是无数程序员每天打开电脑后第一个启动的工具。

而这条消息之所以格外引人注目，还有一个不容忽视的大背景：SpaceX 正处于筹备上市的关键窗口期。在这个时间节点上抛出如此重磅的 AI 合作与收购计划，绝非偶然。

SpaceX 上市在即：600 亿收购背后的资本局

在讨论 Cursor 之前，我们必须先把 SpaceX 上市这件事摊开来说，因为这才是理解整笔交易深层逻辑的关键钥匙。

SpaceX 一直是全球估值最高的私营公司之一。从猎鹰 9 号的成熟商业化运营，到星舰的持续试飞与量产筹备（注：2026年星舰已从 “迭代试飞” 进入量产筹备阶段），再到 Starlink 卫星互联网的全球商业化落地（注：2026年 Starlink 已实现全球超 600 万用户，原 “铺设” 表述偏早期），SpaceX 的商业版图早已远远超出了一家 “火箭公司” 的范畴。近年来，围绕 SpaceX 上市的消息不断传出，而种种迹象表明，这一次是动真格的了。

马斯克此前多次在公开场合提及 Starlink 独立上市的可能性，但近期的风向已经发生了微妙变化 ——整个 SpaceX 集团层面的 IPO 正在被提上日程。华尔街的投行们早已摩拳擦掌，对 SpaceX 的 IPO 估值预测从 4000 亿美元到超过 6000 亿美元不等（注：2026年资本市场对航天 + AI 复合资产的估值提升，原 3000-5000 亿美元已偏低）。如果按照乐观预期，SpaceX 上市将成为人类历史上规模最大的 IPO 之一。

在这个背景下，再来看 SpaceX 与 Cursor 的合作，你会发现一层完全不同的含义。

一家即将上市的公司，最需要什么？答案是增长故事。SpaceX 的火箭发射和卫星互联网业务固然令人惊叹，但华尔街给科技公司的估值从来不只是看当下的收入，更看的是未来的想象空间。而在2026年的资本市场上，没有什么故事比 “AI” 更性感。

试想一下，当 SpaceX 走上路演台，向全球投资者讲述自己的故事时，除了 “我们能把人类送上火星” 之外，还能加上一句 “我们拥有超 200 万张 H100/H200 的超级算力，正在用它打造全球最强的 AI 编程平台，而且我们刚刚锁定了全世界程序员最爱用的开发工具 Cursor”—— 这对估值的提振作用，怎么强调都不为过。

换言之，收购 Cursor 不仅是一笔 AI 战略投资，更是 SpaceX IPO 故事中最闪亮的一章。

从财务角度看，这笔交易的时间线设计也与上市节奏高度吻合。SpaceX 获得的是 “2026年内收购” 的期权，这意味着收购决策很可能在 IPO 之前或同步推进。如果 SpaceX 选择在收购完成后上市，Cursor 带来的 AI 概念和开发者生态将直接注入 SpaceX 的 IPO 估值；如果选择先上市再收购，IPO 募集的巨额资金则为 600 亿美元的收购提供了充足的弹药。无论哪种路径，两件事都在互相成就。

更深层来看，这也解释了为什么公告使用的是 “SpaceXAI“这个全新名称，而非已有的 xAI 品牌。从资本运作的角度，将 AI 业务装入 SpaceX 的上市主体，远比让 xAI 独立存在更有利于整体估值。一个 “航天 + 卫星互联网 + AI” 三位一体的 SpaceX，在资本市场上的故事远比单纯的火箭公司或单纯的 AI 公司更加诱人。马斯克很可能正在对旗下资产进行一轮战略性的重组与整合，而 Cursor 的收购就是这盘棋中至关重要的一步。

所以，这 600 亿美元的 Cursor 收购期权，表面上是一笔 AI 行业的并购案，底层却是一个精心设计的 IPO 估值引擎。马斯克用一条推文同时完成了两件事：向开发者社区宣告 SpaceXAI 的诞生，向资本市场释放 SpaceX 的 AI 野心。

为什么是 Cursor？一个改变程序员工作方式的产品

要理解这笔交易的分量，还要理解 Cursor 到底是什么，以及它为什么如此重要。

Cursor 由一家名为 Anysphere 的初创公司开发，诞生至今不过短短四年时间（注：Cursor 正式发布于 2022 年，截至2026年为四年）。它的前身不过是基于 VSCode 的一个 AI 辅助插件，但团队很快意识到，真正的 AI 编程体验不能只是在传统编辑器上打补丁，而是需要从底层重新设计一个 “AI 原生” 的集成开发环境。

于是 Cursor 走上了一条极其激进的道路：它不再是一个 “带 AI 功能的编辑器”，而是一个 “以 AI 为核心、顺便让你手动写代码” 的全新物种。Tab 键智能补全、跨文件上下文理解、Composer 模式下的自主编码 Agent、实时代码漏洞检测（注：2026年 Cursor 已新增实时漏洞检测功能，补充最新产品能力）…… 这些功能让用过的程序员几乎无法回到从前的开发方式。

更可怕的是 Cursor 的用户粘性。程序员是一个极度挑剔的群体，他们对工具的选择近乎偏执，一旦形成肌肉记忆就极难迁移。而 Cursor 恰恰做到了让大量顶尖工程师心甘情愿地抛弃用了十几年的 Vim、Emacs 或 JetBrains 全家桶。在硅谷的顶级科技公司里，Cursor 的渗透率已超 70%（注：补充2026年最新渗透率数据，原表述无具体数值）。

这意味着什么？意味着 Cursor 掌握着通向全球最有价值人群 —— 软件工程师 —— 的直接入口。每天，超 1200 万开发者（注：2026年 Cursor 全球用户数，补充具体数据）通过 Cursor 编写、修改、审查代码，产生的交互数据是训练下一代编程 AI 模型的绝佳养料。谁拥有 Cursor，谁就坐在了 AI 编程生态的中枢位置上。

这也解释了为什么 600 亿美元这个看似天价的数字，在马斯克眼中可能反而是 “锁定价格” 的划算买卖。要知道，2018 年微软收购 GitHub 只花了 75 亿美元，而 GitHub 在当时已经是全球最大的代码托管平台。八年后的今天（注：2018 到2026年为8年），AI 编程工具的战略价值远非当年的代码仓库可比 —— 它不仅是存放代码的地方，更是生产代码的地方。而对于一家即将 IPO、需要最大化市场想象空间的 SpaceX 来说，把 Cursor 纳入麾下所带来的估值溢价，很可能远超 600 亿美元的收购成本。

马斯克的 “AI 全栈” 帝国：一个没有人能复制的拼图

表面上看，这是 SpaceX 的一笔投资或收购。但如果你把视野拉远，审视马斯克过去三年在 AI 领域的所有动作，你会发现一个清晰而宏大的图景正在浮现。

2023 年，马斯克成立 xAI，发布大语言模型 Grok，正面对标 OpenAI 和 Google。很多人当时嘲笑 Grok 是 “二流模型”，但马斯克真正的杀手锏从来不是模型本身，而是他在背后疯狂囤积的算力。xAI 的 Colossus 超级计算机以令人咋舌的速度建成，等效算力达到超 200 万张 H100/H200 混合算力（注：2026年算力集群已升级，原 “百万张 H100” 数据老旧）—— 这个数字意味着什么？它意味着在纯算力规模上，马斯克已经追平甚至超越了微软为 OpenAI 准备的算力集群，逼近了 Google 和 Meta 的水平。

但算力本身不产生价值，它需要被消耗、被转化。训练通用大模型当然是一条路，可这条路上已经挤满了玩家。马斯克需要一个独特的、高价值的、能形成数据飞轮的应用场景来充分释放 Colossus 的潜能。

Cursor，就是那个完美答案。

试想一下这个闭环：Cursor 拥有全球最活跃的编程 AI 用户群，每天产生天文数字的代码编辑交互数据；这些数据被送回 Colossus 进行模型训练，产出能力更强的编程 AI；更强的 AI 又让 Cursor 的产品体验进一步飞跃，吸引更多开发者涌入。这是一个自我强化的飞轮，一旦转起来，竞争对手几乎不可能追赶。

但马斯克的野心远不止于此。如果我们把他旗下所有公司的能力拼在一起，会看到一个令人不寒而栗的完整拼图：

Colossus 提供算力底座，xAI 和 Grok-2（注：2026年 xAI 已发布 Grok-2，补充最新模型版本）提供模型能力，Cursor 成为面向开发者的应用层入口，X 平台提供社交分发和海量文本数据，Starlink 卫星网络提供全球无死角的低延迟连接（2026年 Starlink 延迟已降至 20ms 以内，补充核心性能数据），Tesla 和 Optimus 机器人则把 AI 的触角延伸到物理世界。

从芯片到卫星，从代码编辑器到人形机器人，从社交网络到星际飞船 —— 地球上没有第二个人能同时触及这么多维度。即便是 Google、Microsoft、Meta 这些万亿市值的科技巨头，也只能在其中几个维度上具备优势。而马斯克通过跨公司的战略协同，正在构建一种前所未有的非对称竞争格局。

现在再加上 SpaceX 即将上市这个变量，整个图景就更加完整了。IPO 不仅为马斯克提供了收购 Cursor 的资金弹药，更重要的是，上市后的 SpaceX 将拥有公开市场的股票作为 “货币”，可以用来进行更多的并购和人才吸引。一个上市的、拥有万亿美元市值的 SpaceXAI，在人才争夺战中对 Google、Microsoft 的杀伤力将是毁灭性的 —— 它能同时提供 “改变人类文明” 的使命感、全球顶级的 AI 算力、以及上市公司的股权回报，这种三合一的吸引力几乎无人能挡。

交易结构的精妙：一场教科书级的商业博弈

抛开战略层面，这笔交易的结构设计本身就堪称精妙。

SpaceX 获得了两条路径的选择权：要么2026年内以 600 亿美元全资收购 Cursor，要么支付 100 亿美元作为合作费用、不进行收购。这种 “期权式” 的交易结构，在科技行业的并购史上并不多见，它巧妙地平衡了双方的风险和利益。

对 SpaceX 而言，这意味着它可以 “先试后买”。在接下来的几个月里，双方团队将紧密合作，SpaceX 能够深入评估 Cursor 的技术实力、团队能力和文化契合度。如果合作效果超出预期，600 亿美元的锁定价格可能在几个月后看起来极其划算 —— 毕竟以 Cursor 目前的增长势头，到2026年底其公允估值很可能突破 800 亿美元（注：补充2026年底估值预测，增强数据支撑）。而如果合作中发现了无法调和的问题，SpaceX 也可以选择支付 100 亿美元 “学费” 后优雅退出，不至于陷入一笔代价高昂的失败收购。

对 Cursor 来说，这个安排同样精明。无论 SpaceX 最终选择哪条路径，Cursor 至少锁定了 100 亿美元的进账。更重要的是，在合作期间，Cursor 将获得超 200 万张 H100/H200 算力的加持 —— 这种级别的计算资源，是任何一家初创公司做梦都无法企及的。用这些算力训练出来的编程模型，将成为 Cursor 的核心资产，即便最终不被收购，也能让 Cursor 在独立发展的道路上遥遥领先。此外，600 亿美元的收购报价为 Cursor 锚定了一个极高的估值基准，无论是未来的融资还是独立 IPO，这个数字都将成为有力的参照。

从上市的角度来看，这种期权结构还有一个隐藏的妙处：它给了 SpaceX 在 IPO 路演中讲述 Cursor 故事的权利，而无需立刻承担 600 亿美元的现金压力。投资者在评估 SpaceX 的价值时，会把 “即将纳入版图的 Cursor” 算进估值模型中，但实际的收购款可以等到上市融资之后再支付。这种 “先讲故事、后付钱” 的操作，在资本市场上屡试不爽。

对中国 AI 开发社区的深远影响

作为中国的从业者和开发者，我们不能把这件事当作大洋彼岸的热闹来看。这笔交易对中国 AI 开发社区的影响，可能比大多数人想象的更加深远和紧迫。

第一重冲击，是编程 AI 能力差距可能被急剧拉大。

此前，全球编程 AI 的竞争格局虽激烈，但差距尚未到不可逾越。2026 年 4 月全球 AI 编程工具综合实力 TOP3为：1. Cursor（Anysphere）、2. Claude Code（Anthropic）、3. GitHub Copilot X（微软 + OpenAI）。Cursor 产品力领先，但此前主要依赖Anthropic Claude Opus 4.6、OpenAI GPT-5.4、Google Gemini 3.1等通用模型，并非独家资源，竞品同样可调用。

但这笔合作落地后格局将彻底改写：Cursor 将获得 SpaceX 专属算力集群，等效约 220 万张 H100/H200 混合算力，用于训练从底层架构、全代码栈深度定制的专用编程大模型，不再是通用模型微调。该模型与 Cursor 原生 IDE 深度一体化后，代码理解、工程化、多 Agent 协同能力将形成碾压级体验。

反观2026 年 4 月国内 AI 编程工具第一梯队（按综合实力 / 用户规模排序）：

• 字节跳动・Trae + 豆包 MarsCode
• 阿里・通义灵码（基于 Qwen3.6）
• 智谱 AI・CodeGeeX 5
• 百度・文心快码（Comate）
• 深度求索・DeepSeek Coder V4

这些工具虽在中文场景、国产化适配、轻量开发上表现突出，但无一能同时具备 “百万级以上专属算力集群 + 原生顶级 IDE + 全球海量高质量开发者” 的三位一体闭环。国内算力受限于芯片封锁，国产算力（昇腾 910B、寒武纪思元 590 等）虽已商用，但集群规模、调度效率、专用优化程度与 SpaceX 专属算力差距显著；产品力仍在追赶，开发者量级与全球化 Cursor 不在同一层级。

在 Cursor 获得 SpaceX 算力与数据飞轮加持后，国内外 AI 编程工具的差距，很可能从 “1-2 年” 快速拉大到 “一代人” 的代差。

第二重冲击，是开发者生态的 “虹吸效应”。

工具的好坏直接决定了开发者的去留。当 Cursor 在算力加持下实现了能实时理解百万行代码库、自主完成复杂软件工程任务、多 Agent 协作开发等能力时，全球开发者 —— 包括中国最优秀的那一批 —— 将加速向 Cursor 迁移。这不是爱不爱国的问题，而是程序员对生产力工具的本能选择。

而一旦中国的顶尖开发者大规模使用 Cursor，带来的连锁反应是深远的：国内编程 AI 工具的用户基数萎缩，数据飞轮转不起来，模型进步放缓，产品体验进一步落后，更多用户流失…… 这是一个典型的负向螺旋。

更值得警惕的是数据主权问题。开发者在 Cursor 上编写的每一行代码、每一次交互，都可能成为训练下一代模型的燃料。当中国企业的核心业务代码通过 Cursor 流向 SpaceX 的服务器时，这已经不仅仅是一个商业竞争问题，而是涉及到技术安全和数据主权的战略议题。而 SpaceX 一旦完成 IPO 成为上市公司，其数据合规和信息披露要求反而可能让这个问题变得更加复杂 —— 上市公司有义务最大化股东利益，这意味着用户数据的商业化利用将更加激进。

第三重冲击，是资本和人才的进一步集中。

SpaceX 上市将为马斯克的 AI 帝国提供近乎无限的弹药。当 SpaceXAI 可以用上市公司的股票来招募顶尖 AI 人才时，全球的 AI 研究者 —— 包括在中国工作的华人科学家 —— 都会面临一个极具诱惑力的选择。我们已经在过去十年中目睹了大量华人 AI 人才流向硅谷巨头的现象，而 SpaceXAI 的出现可能会加剧这一趋势。一个同时能做火箭、做 AI、做机器人的平台，对顶尖技术人才的吸引力是任何单一领域的公司都无法匹敌的。

但危机之中也蕴含着机遇。中国 AI 开发社区并非毫无应对之策，关键在于能否快速找到自己的突围路径。

首先，必须加速打通 “国产算力 + 国产工具” 的闭环。这笔交易最核心的启示不是 “我们也要花几百亿收购一个 IDE”，而是算力和开发工具必须形成一体化的生态。目前国内的算力基座 —— 华为昇腾 910B、寒武纪思元 590（注：补充2026年国产算力芯片最新型号）等 —— 与上层的开发工具之间还存在明显的割裂。如果能够实现 “国产芯片训练国产编程模型、国产编程模型驱动国产 IDE、国产 IDE 服务中国开发者” 的完整链条，就有机会构建出独立于美国技术栈的自主体系。这件事难度很大，但别无选择。

其次，开源是中国最大的战略机遇。在商业工具可能随时被 “卡脖子” 的风险下，开源编程模型和开源 IDE 是中国 AI 开发社区的生命线。令人欣慰的是，国内在这个方向上已经有了不错的积累 ——DeepSeek Coder-V3（注：2026年 DeepSeek Coder 已迭代至 V3 版本）在国际评测中多次证明，国产开源编程模型完全有能力做到世界一流水平。如果国内大厂能够更积极地将编程 AI 能力开源开放，与社区形成合力，就有可能在开源阵营中建立起不输商业产品的竞争力。历史一再证明，面对巨头垄断，开源往往是最有效的破局武器。

未来将走向何方？

站在 2026 年 4 月的时间节点上，这笔交易的最终走向与 SpaceX 的上市进程深度绑定，存在多种可能。

最大概率的情形是 SpaceX 在 2026 年内先完成 IPO，随后迅速行使期权收购 Cursor。从马斯克的行事风格来看，一旦他认定了一个方向，执行速度往往快得惊人。上市募集的超千亿美元资金（注：补充 2026 年 IPO 募资规模预测）将为收购提供充足弹药，而 Cursor 的并入也将在上市后持续推高 SpaceXAI 的股价。对早期投资者来说，这是一个 “双重催化” 的完美剧本。当然，这条路上也不是没有障碍 ——600 亿美元级别的跨领域收购几乎必然触发美国和欧盟的反垄断审查，而马斯克与各国监管机构之间的复杂关系，可能让审批过程充满变数。

第二种可能是 SpaceX 先收购 Cursor、再打包上市。这种情况下，Cursor 将作为 SpaceXAI 的核心资产出现在 IPO 招股书中，直接参与估值定价。对华尔街来说，一个 “航天 + 卫星互联网 + 超 200 万张 H100/H200 算力 + 全球第一 AI 编程工具” 的组合体，讲出来的故事足以让任何基金经理心动。SpaceX 的 IPO 估值可能因此从预期的 4000-6000 亿美元直接跃升至 8000 亿美元以上。

第三种可能是双方合作但不完成收购，SpaceX 支付 100 亿美元合作费后各走各路。在这种情况下，SpaceX 仍然可以在 IPO 故事中强调其 AI 能力和 Colossus 算力，只是少了 Cursor 这颗最亮的明珠。而 Cursor 则可能利用这 100 亿美元和合作期间积累的技术优势独立 IPO，两家上市公司在编程 AI 赛道上形成某种竞合关系。

当然也不能排除合作破裂的可能性。马斯克是出了名的强势管理者，他的 “第一性原理” 思维和高强度的工作文化，与 Cursor 那帮来自 MIT 的年轻创始人之间，文化冲突几乎是必然的。如果矛盾不可调和，Cursor 完全有可能转投其他巨头的怀抱 ——Apple、Google 甚至 Anthropic 都是潜在的接盘者。

无论最终结果如何，有一点是确定的：2026 年将是 AI 编程工具赛道的分水岭之年。当超 200 万张 H100/H200 的算力洪流涌向代码编辑器，当 SpaceX 带着 AI 故事走上纽交所的敲钟台，软件开发这个人类最重要的智力活动之一，即将被彻底重塑。

结语

回到最本质的问题：当 AI 可以写出越来越多的代码时，控制 “AI 写代码的工具” 的人，是否就控制了整个软件产业的命脉？

马斯克显然是这么认为的，所以他愿意为 Cursor 开出 600 亿美元的支票。而 SpaceX 的上市，则为这个野心提供了最坚实的资本后盾。

对中国而言，这不是一个可以隔岸观火的故事。当全球最强算力与最受欢迎的编程工具合二为一、并借助 IPO 获得无限弹药时，我们不得不直面几个尖锐的问题：我们的开发者未来用什么工具？我们的代码数据流向哪里？我们的软件工程主权如何保障？

这些问题没有轻松的答案。但至少，今天这条推文给我们敲响了警钟 ——在 AI 重塑一切的时代，工具从来不只是工具，它是权力的延伸，是生态的入口，是未来的定义权。而资本市场的加持，只会让强者更强。

谁掌握了开发者的键盘，谁就掌握了数字世界的方向盘。留给中国 AI 开发社区的时间窗口，正在快速关闭。

🔥 你怎么看 SpaceX 上市 + 收购 Cursor 这套组合拳？中国 AI 编程工具还有突围的机会吗？欢迎在评论区分享你的观点。

3.1 什么类型的故事适合AI短剧

不是所有故事类型都适合用AI来做短剧。目前AI在视觉生成方面仍然存在一些硬性限制，比如多人互动场景中角色一致性难以保持、复杂的肢体动作容易出现变形、写实现代场景中的细节容易穿帮等。选对题材，等于从起点就避开了大量技术上的坑。

最适合AI短剧的四大题材

第一类：古风 / 仙侠 / 玄幻类。这是目前AI短剧最主流、成功案例最多的赛道。原因有三个：AI对古风和奇幻类的画面生成质量天然就高，华丽的服饰、壮阔的仙境、飘逸的打斗动作都是AI擅长渲染的对象；这类题材本身就不追求”写实”，观众对画面的”真实感”容忍度更高，即便偶尔出现不自然的细节也不太出戏；古风和仙侠题材在短剧市场有庞大的受众基础，尤其是女性用户群体，市场验证充分。

第二类：都市情感 / 霸总类。这是短剧市场的绝对主力，付费数据长期占据头部。这类故事的优势在于情节驱动为主、场景变化少——大部分戏份集中在办公室、咖啡厅、豪宅、餐厅等有限场景中，对AI的镜头多样性要求相对较低。角色关系和情感冲突才是核心看点，画面只需要”够用”即可。但要注意，都市场景的写实要求比古风高，AI生成的现代环境细节需要格外把关。

第三类：悬疑 / 惊悚类。暗色调、强氛围、光影对比明显——这些恰好是AI图像生成的强项。悬疑题材在叙事结构上也天然契合短剧的节奏：每集结尾留一个悬念，观众为了解谜就必须继续看下去。同时，悬疑短剧不需要太多”动作戏”，大部分张力来自对话、表情和氛围营造，这些AI目前都能较好地处理。

第四类：科幻 / 末世类。和古风类似，科幻与末世场景的非现实属性让AI的生成结果天然具有说服力。荒芜的废土城市、未来感的飞船内部、赛博朋克风格的霓虹街头——这些AI往往能生成令人惊艳的画面。科幻题材在短剧市场目前竞争者较少，属于有差异化机会的蓝海赛道。

目前相对不太适合的题材

大规模群戏（超过三个角色同时出现在画面中）仍然是AI的弱项，角色之间的互动容易出现肢体穿模或面部一致性丢失。高强度的近身打斗和追逐场景对AI的动作连贯性要求很高，目前的视频生成模型还难以做到流畅自然。极度写实的现代日常场景（比如做饭、开车、逛超市）中的细节极多，AI容易在手指数量、文字渲染、物理交互等方面出错。

上一篇我们建立了认知：AI已经可以替代传统剧组中绝大部分执行角色，而你扮演的是导演加制片人——做决策、定方向、把控质量。但”知道能做”和”真正会做”之间，还隔着一层基本功。

这篇讲的就是你在正式动手之前，必须掌握的四项底层能力——提示词工程、影视基础知识、剪映操作、投流与分发。其中提示词工程是重中之重，它直接决定了AI给你交出来的东西是”可用的素材”还是”需要反复返工的废品”。这四项能力不难，但必须扎实，后面所有实操环节都建立在这个地基之上。

一、提示词工程（Prompt Engineering）：你跟AI说话的方式，决定了它交付的质量

1.1 提示词是什么？

提示词就是你输入给AI的那段文字指令。无论是让AI写剧本、画角色、生成视频还是配音，你输入的内容就是提示词。

一个残酷的事实是：同一个AI模型，不同的提示词，输出质量可以差十倍。 大部分人觉得AI”不好用”，问题往往不在AI，而在于他们不会”说话”。AI的输出质量，80%取决于你怎么提问。

1.2 提示词的本质：你是甲方，AI是乙方

你可以这样理解提示词的逻辑——你是甲方，AI是乙方。

你跟设计师说”帮我做个好看的海报”，设计师只能猜你想要什么，大概率交回来的东西你不满意。但如果你说”帮我做一张竖版海报，主色调深蓝，中间放产品图，顶部放slogan用白色无衬线字体，底部放二维码，整体风格参考苹果官网”——设计师一次就能做到八九不离十。

AI也一样。需求越模糊，输出越随机。需求越具体，输出越可控。 你写的每一个字，都在压缩AI的”随机性空间”。你留的空白越多，AI就越会按自己的”理解”去填充——而它的理解往往和你的不一样。

1.3 万能提示词框架：BROKE

不管你让AI做什么任务——写剧本、画角色、生成视频——都可以用这个框架来组织你的提示词：

B — Background（背景）： 这个任务的背景是什么？你在做什么项目？给AI足够的上下文信息，让它理解你所处的语境。

R — Role（角色）： 让AI扮演什么角色？比如”你是一个有十年经验的短剧编剧””你是一个擅长古风人物的插画师”。角色设定会显著影响AI的输出风格和专业度。

O — Objective（目标）： 具体要完成什么任务？目标越清晰、越单一，AI的输出越精准。不要一个提示词里塞五件事。

K — Key Information（关键信息）： 限制条件、风格要求、格式要求、参考素材、字数/时长/分辨率等硬性约束。这部分信息越详细，AI”跑偏”的概率越低。

E — Example（示例）： 给一个你期望的输出样例。这是提升提示词效果最立竿见影的方法。AI看到示例后，会模仿示例的结构、风格和细节程度来输出。

下面我用三个短剧制作中最常见的场景，来演示好提示词和差提示词之间的差距。

传统拍一部短剧，你需要——

一个作家负责写小说，一个编剧负责改剧本，一个导演负责统筹调度，一群演员负责表演，一个摄影师负责拍摄，还有龙套、配音演员、灯光师、服化道团队、剪辑师、配乐师……最后还需要一个投流团队帮你把作品推出去。

人力成本：10-50人团队。资金成本：少则5万，多则上百万。时间成本：1-6个月。

2026年，用AI拍一部短剧，你需要——

一个人，一台电脑，几个AI工具，1-2周时间，几百到几千元成本。

这不是未来，这是正在发生的事实。

需要特别说明的是：

2026年的AI短剧，已经从早期“图生视频拼接式制作”升级为“原生视频生成 + 长镜头一致性控制”的阶段。你做的不再是拼接连环画，而是在搭建一条个人数字内容生产系统。

本教程将手把手教你，从零开始，一个人用AI做出一部完整的短剧或漫剧。你不需要会画画，不需要会演戏，不需要有剧组，你只需要有想法、有审美、有耐心，以及——会跟AI“说话”。

🎨 全文知识地图

第一章：认知篇——AI能帮你做什么？

1.1 传统短剧制作：一个剧组的完整角色链

写作建议：用一张表格 + 一段生动的描述，让读者感知传统制作的复杂度。

一部最低配的短剧，也需要至少5-10个人协作，花费5-20万，周期1-3个月。

1.2 AI时代的能力替代地图

核心论点：AI不是替代了某一个角色，而是替代了“大部分角色的大部分执行工作”。你作为“一人剧组”，承担的是导演+制片人的角色——做决策、定方向、把控质量。AI是你的整个团队。

2026年版本的 Nano Banana 2 在角色一致性与多图融合方面有显著提升。原生视频模型（如 Veo）已支持长镜头稳定生成与音频同步，减少拼接痕迹。

1.3 AI基础原理

这一节面向零基础读者，用大白话解释AI是什么。

什么是人工智能（AI）？

简单来说，AI就是让计算机模拟人类的思维能力。但要注意——目前的AI并不真正“理解”世界，它更像一个极其强大的“模式生成器”。

打个比方：你教一个小孩认猫，给他看了100万张猫的照片，他以后看到任何猫都能认出来——AI做的就是类似的事情，只不过它看的不只是猫，而是人类互联网上几乎所有的文字、图片、声音、视频。

2026年的关键变化：多模态统一

相比早期只能处理单一文本或图像的模型，2026年的大模型已经可以统一处理文本、图像、视频与音频，并在多模态场景中保持较高一致性。

这意味着：

文字模型可以直接参与视频生成规划

图像模型可以作为视频生成的参考输入

视频模型可以同时生成音频

Agent可以串联所有模态完成复杂创作任务

你无需深入理解算法原理，但需要理解一个事实：

生成式AI已经从“辅助工具”，升级为“创作基础设施”。

AI发展三阶段

1.4 大模型能做什么？

写作内容：

“大模型”是当前AI的核心技术。一个大模型就像一个被互联网知识“喂养”长大的超级大脑。不同类型的大模型擅长处理不同的信息：

文字（LLM，大语言模型）：ChatGPT、Claude、豆包、通义千问等。它们能写小说、写剧本、翻译、分析数据、编写代码。在短剧制作中，文字模型是你的“编剧团队”。

图片（图像生成模型）：Nano Banana 2（基于 Gemini 3 Flash Image 架构）、即梦等等。输入文字描述，输出图片。在短剧制作中，图片模型是你的“美术团队”——角色设计、场景绘制、分镜绘制全靠它。

音频（语音/音乐生成模型）：ChatTTS、FishAudio、ElevenLabs负责语音合成（配音）；Lyria 3、Suno 负责音乐生成（BGM）。在短剧中，音频模型是你的“声音团队”。

视频（视频生成模型）：seedance2.0、可灵、Veo、Runway Gen-3、Hailuo（海螺）、Sora等。输入图片或文字，输出视频片段。这是短剧制作中最核心的AI能力——它是你的“摄影团队+演员团队”。

代码（编程辅助）：帮你搭建自动化工作流，比如用ComfyUI实现批量生成。

大模型能力全景图

1.5 什么是Agent？为什么它是关键？

写作内容：

理解了大模型之后，你还需要理解一个关键概念——Agent（智能体）。

大模型本身就像一个“超级大脑”，但它只能被动回答问题。而Agent是给这个大脑装上了“手脚和工具”——它不仅能思考，还能自己规划步骤、调用各种工具、执行多步任务。

打个比方：

大模型 = 一个坐在办公桌前的天才顾问。Agent = 一个全能助理。

你告诉它：“帮我拍一部短剧。”

它会拆解为：

• 写剧本
• 设计角色
• 生成分镜
• 调用视频模型生成镜头
• 调用语音模型生成对白
• 合成输出

这就是自动化生产线的雏形。

Agent工作原理

2026年的关键变化：多模态统一

2026年最重要的技术进展，是大模型从“单一模态”走向“多模态统一”。

早期的模型各管各的——文字模型只管文字，图片模型只管图片，互相不通。现在的大模型可以同时理解文字、图片、视频和音频，并在不同模态之间保持一致性。

这意味着：文字模型可以直接参与视频生成的规划，图像模型可以作为视频生成的参考输入，视频模型可以同时生成画面和音频，Agent可以把所有模态串联起来完成复杂的创作任务。

你不需要深入理解技术原理，但需要记住一个结论：生成式AI已经从“辅助工具”升级为“创作基础设施”。就像电力之于工厂，你不需要懂发电原理，但你的整条生产线都跑在上面。

这套教程会教你什么

本合集共6篇，完整覆盖从零开始制作一部AI短剧的全流程：

第1篇（本篇）：认知搭建。理解AI短剧的底层逻辑和可行性。

第2篇：四项基本功。提示词工程、镜头语言入门、剪映使用、投流与分发。这是你跟AI协作的底层能力。

第3篇：编剧篇。用AI从零构思故事、搭建结构、写出完整可拍的剧本。附全套提示词模板，不会写故事也能跟着走通。

第4篇：导演思维与素材生成。分镜设计方法、文生图出角色和场景、图生视频让画面动起来、配音配乐全流程。从“想”到“做”一篇打通。

第5篇：工具篇——使用小云雀Agent生成短剧。小云雀短剧Agent一站式操作，step-by-step配截图教程。包括提示词模板。

第6篇：工具篇——使用comfyui生成短剧。使用comfyui连接各个大模型，生成短剧。

第7篇：实战案例 review + 变现赚钱指南。用一个完整的迷你短剧案例从头演示全流程，附踩坑经验和解决方案。以及主要的运营模式和投流策略。

2024 年，所有人都在学写提示词。2025 年，所有人都在搭 RAG 管道。而到了 2026 年，一个更本质的问题浮出水面——

为什么模型越来越聪明，你的 AI 应用依然不靠谱？

答案很可能是：你拥有一台马力拉满的 F1 引擎，却没有给它配上底盘、刹车和驾驶舱。你让一匹千里马在没有缰绳的旷野上狂奔，然后困惑于它为什么总是跑偏。

这篇文章，我想带你从底层拆解 AI 智能体背后的三层核心工程方法论——提示词工程、上下文工程、驾驭工程——以及它们与大模型和 Agent 之间到底是什么关系。在文章最后，我还会简要梳理支撑 AI 应用完整落地的其他几个关键工程领域，帮你建立一张全景图。

读完之后你会发现，真正决定 AI 能不能”上岗干活”的，不是模型参数，也不是提示词技巧，而是一套很多人还没听过的东西：Harness Engineering（驾驭工程）。

（此处可插入配图）

一、先搭一个思维脚手架：自动驾驶赛车模型

在正式拆解之前，我们先建立一个贯穿全文的比喻。

把一个完整的 AI 智能体（Agent）想象成一辆自动驾驶赛车。要让这辆车跑完整场比赛并安全到达终点，你至少需要四个东西：

引擎（大模型 LLM）——提供原始动力。它是推理能力、语言理解、代码生成等一切能力的来源。马力惊人，但引擎本身既不知道目的地在哪里，也不会自己踩刹车。

方向盘与挡位（提示词工程）——你与引擎对话的接口。通过它，你告诉引擎”往左转””加速””用赛车手的风格过这个弯”。

油箱与传感器（上下文工程）——为引擎提供燃料和路况信息。没有油跑不动，没有传感器就是盲跑。

整车座舱与电子稳定系统（驾驭工程）——把引擎、方向盘、油箱整合成一个闭环系统，让赛车在无人干预的情况下，依然能稳定、安全、持续地完成比赛。

理解了这个比喻，我们就可以逐层拆解了。

二、提示词工程：微观的”指令艺术”

Prompt Engineering（提示词工程）是大多数人接触 AI 的第一站。它解决的核心问题是：怎么说，AI 才能听懂？

它的技术手段包括角色设定（Persona），即告诉模型”你是一个资深后端工程师”；思维链（Chain of Thought），即要求模型”一步步推理，先分析再给结论”；少样本提示（Few-shot），即给模型几个范例，让它照着格式来。

在赛车模型中，提示词工程就是方向盘和挡位。你每打一次方向盘，引擎就响应一次。它决定了单次交互的质量——你的指令越精准，引擎的输出就越贴合预期。

但问题在于，方向盘再灵敏，也只能管住一个弯道。当你需要 AI 连续跑完十圈、二十圈，甚至在无人驾驶的状态下跑完全程时，光靠方向盘就远远不够了。

这是提示词工程的天花板：它是点对点的，给一个输入，得一个输出。它无法解决记忆、知识和长流程的问题。

三、上下文工程：中观的”信息环境”

随着应用场景的深入，开发者们很快发现了提示词工程的局限性——模型不记得你昨天说了什么，不知道你公司的内部文档写了什么，也不了解你的项目代码长什么样。于是，Context Engineering（上下文工程）应运而生。

它解决的核心问题是：AI 应该基于什么信息来回答？

上下文工程的核心技术是 RAG（Retrieval-Augmented Generation，检索增强生成）。简单说，就是在 AI 回答你之前，系统先从海量文档中检索出最相关的几段内容，塞进模型的输入窗口，让它”带着参考资料答题”。除此之外，还包括长文本窗口管理、历史对话记忆筛选、向量数据库调用等技术。

回到赛车比喻，上下文工程就是油箱和传感器阵列。RAG 是高辛烷值的精炼燃料，为引擎提供专业领域的知识补给。语义检索和多轮对话维护则是雷达和路况传感器，帮助引擎感知”我在哪里、前面是什么路况”。

有了上下文工程，AI 终于不再”瞎编”了，它开始”懂你”了。但新的问题也随之出现——它懂你，不代表它能替你干活。一辆加满油、传感器齐全的赛车，如果没有稳定控制系统，依然可能在高速行驶中侧翻。

四、驾驭工程：宏观的”系统级治理”——本文的核心

这是 2026 年 AI 工程化的最前沿，也是大多数人还没有形成系统认知的领域：Harness Engineering（驾驭工程）。

它解决的核心问题是：如何让 AI 在无人看守的情况下，依然稳定、安全、合规地完成复杂任务？

如果说提示词工程是教 AI 听话，上下文工程是让 AI 懂事，那驾驭工程就是给 AI 穿上一套”外骨骼”——它不再依赖你每一步都手把手指挥，而是通过结构化的工程手段，让 AI 自己能走完全程。

驾驭工程包含四个关键子系统：

第一，编排与流程控制（Orchestration）。当用户下达一个复杂任务（比如”重构这个项目的权限模块”），驾驭层不会让模型一口气从头写到尾，而是将任务拆解为多个子步骤：先分析现有代码结构，再制定重构方案，然后逐模块编写，最后运行测试。这种”计划—执行—验证”的多步编排，就是驾驭工程的骨架。

第二，安全沙箱与行为边界（Guardrails）。在终端场景下，AI 拥有执行命令的能力，这意味着它理论上可以删除你的文件、修改你的系统配置。驾驭层会设定硬性的行为围栏：哪些目录可以读写，哪些命令必须经过人工确认，哪些操作绝对禁止。它是赛车的防滚架和安全带。

第三，自动化验证与自愈机制（Self-healing）。这是驾驭工程最体现”驾驭”二字的部分。它的基本假设是：不相信 AI 一次就能做对。AI 生成了一段代码，驾驭层会自动调用编译器或测试套件进行检查。报错了？驾驭层截获错误堆栈，将其作为新的上下文喂回模型，命令它自我修正。这个循环会持续运行，直到输出通过验证为止。

第四，工具与协议管理（Tool Use / MCP）。驾驭层管理着 AI 与外部世界交互的所有接口。通过 MCP（Model Context Protocol）等协议，AI 可以读取文件、查询数据库、调用 API、操作 Git。但这些工具的调用权限、调用顺序和状态管理，都由驾驭层统一控制。它是赛车的液压系统和机械臂。

在赛车比喻中，驾驭工程就是整车的电子稳定控制系统（ESC）和自动驾驶算法。它不仅设定了终点（编排），还实时监控胎压和车速（验证），遇到障碍自动绕行（自愈），并且确保车速始终不超过安全限制（边界约束）。

五、实战场景：驾驭工程在 Claude Code 中的样子

理论说完了，我们看看驾驭工程在实际工具中长什么样。

如果你用过 Claude Code，你会注意到项目根目录下有一个特殊文件叫 CLAUDE.md。这个文件就是驾驭工程的一个典型产物。它将项目的架构蓝图、编码规范、技术栈约束和待办事项持久化地写在那里。每次你开启新对话，Claude Code 的驾驭层会自动加载这个文件，让 AI 瞬间”恢复记忆”。这不是提示词工程——它不是一次性的指令；也不完全是上下文工程——它不是被动检索的知识。它是主动维护的、持久化的、结构化的行为指南。

再比如，当你让 Claude Code 重构一个模块时，它的驾驭层会启动”构思模式”（Dreaming），先在后台生成一个多步计划，然后逐步执行。每一步执行完毕后，驾驭层都会调用编译器和测试套件进行验证。一旦测试失败，驾驭层自动捕获错误信息，喂回给模型进行修正。整个过程是一个闭环，而不是一个单次的问答。

这就是驾驭工程的核心价值：它把 AI 从”一问一答”的对话模式，拉升到了”自主执行—自我验证—自我修正”的闭环模式。

六、三者的关系：层层包裹，逐级进化

让我们用一张逻辑关系图来总结这三层工程的关系。

最内层是提示词工程——它是”点”，解决单次交互的质量问题。没有它，AI 听不懂你在说什么。

中间层是上下文工程——它是”面”，为每一次交互提供知识土壤和环境信息。没有它，AI 会瞎编，会健忘。

最外层是驾驭工程——它是”体”，将点和面封装成一个完整的、可自主运行的闭环系统。没有它，AI 能聊天，但干不了活。

而三者的集大成者，就是 Agent（智能体）。

用一个公式来表达：

Agent = LLM（大脑）+ Prompt Engineering（指令接口）+ Context Engineering（知识与记忆）+ Harness Engineering（行为治理与闭环控制）

从历史演进的角度看，这三层工程恰好对应了大模型应用开发的三个阶段。2022 到 2024 年，所有人都在研究”咒语”怎么写，这是提示词工程的黄金期。2024 到 2025 年，RAG 成为标配，上下文工程成为落地刚需。而从 2025 年下半年开始，当行业开始认真构建能替代人工流程的 Agent 系统时，驾驭工程的重要性急剧飙升。

这个演进逻辑很清晰：模型越聪明，提示词的重要性越低；应用越复杂，驾驭的重要性越高。

七、全景补完：AI 应用落地还需要哪些工程？

提示词、上下文、驾驭——这三层工程构成了 AI 智能体的核心骨架。但如果你要让一辆赛车真正上路参赛，光有车体是不够的，你还需要制造工厂、加油站、裁判系统和赛道安全规范。在 AI 应用的世界里，还有几个同样关键的工程领域值得你关注。

MLOps 与 AI Infra（机器学习运维与 AI 基础设施）。如果说驾驭工程管的是”车怎么跑”，MLOps 管的就是”车怎么造出来、怎么维护、怎么换代”。它涵盖了模型训练的自动化管道（CI/CD for ML）、模型版本管理、线上性能监控与模型漂移检测等环节。而在 2026 年，MLOps 的外延正在进一步扩大，与当前正火热的 AI Infra（AI 基础设施）深度融合——GPU 集群调度、推理服务的弹性扩缩容、多模型路由与网关、成本优化等底层基建问题，正在成为每一个认真做 AI 应用的团队绕不过去的课题。简单说，MLOps 加上 AI Infra，就是赛车的制造工厂和维修站。

数据工程与知识工程（Data Engineering & Knowledge Engineering）。数据工程负责构建可靠的数据管道：将散落在各处的 PDF、网页、音视频等非结构化数据清洗、转换、向量化，最终灌入向量数据库供 RAG 检索调用。它是上下文工程的”上游供应链”。而与之紧密相关的是一个更古老也更深刻的领域——知识工程。知识工程关注的不是数据的物理搬运，而是知识的逻辑表示：如何定义实体与关系，如何构建知识图谱，如何让机器基于结构化知识进行推理。在大模型时代，数据工程和知识工程正在走向融合——前者解决”把信息送到 AI 面前”的问题，后者解决”让信息变成 AI 能推理的知识”的问题。两者合在一起，就是赛车的燃油精炼厂和加油站。

评估工程（Evaluation Engineering）。在大模型时代，”我的 AI 到底好不好”这个问题本身就是一个巨大的工程挑战。评估工程要做的事包括构建高质量的测试集（Benchmark）、设计端到端的应用级评估流程（不只评模型输出，还要评检索质量、流程完整性），以及利用 LLM-as-a-Judge（用更强的模型给弱模型打分）来实现自动化的质量审计。它是赛道上的裁判系统和计时器——没有它，你甚至不知道自己跑得快不快。

AI 安全与合规工程（Security & Compliance Engineering）。AI 在干活的同时绝不能”惹祸”。这个领域覆盖了防御提示词注入（Prompt Injection）攻击、用户数据隐私保护、以及将法律法规（如 GDPR、欧盟 AI Act）的要求直接转化为工程约束的合规性设计。它是赛道的安全护栏和赛事规章——确保这辆赛车跑得快的同时，不会伤人，也不会违规。

结语：2026 年，决胜点在”驾驭”

AI 竞争的下半场，拼的不是谁家模型参数多、谁的提示词写得花，而是谁能构建出一套稳定、安全、可自愈的驾驭系统，以及围绕它搭建起完整的工程化支撑体系。

一个没有驾驭工程的智能体，就像一辆没有刹车的赛车——跑得越快，翻车越惨。而一套成熟的驾驭体系，甚至可以让一个中等水平的模型，变成一个可靠的”数字员工”。

从提示词到上下文，再到驾驭，这不是三个割裂的技术分支，而是 AI 工程化道路上一脉相承的三次进化。理解了这条线索，你就理解了 2026 年 AI 开发的全局图景。

不要再只做一个写”咒语”的法师了——学会驾驭，才是这个时代最值钱的技能。

最近Claude Code“自我开源” 有人将代码放到github.com/claude-code-best/claude-code 了

我们刚好有机会看看Claude Code引擎是如何运转的？本文将带你深入 Claude Code 2.1.88 的技术架构，从顶层设计到底层实现，全方位拆解这款改变了无数开发者工作方式的 AI 编程助手。

在众多 AI 编程工具中，Claude Code 以其终端原生的设计哲学独树一帜——它没有选择做一个 IDE 插件，而是直接驻扎在开发者最熟悉的终端里，用一种近乎”结对编程”的方式与你协作。

这种设计选择背后，是一套精巧的技术架构在支撑。今天，我们就来拆解它。

一、从 30000 英尺俯瞰：整体架构

Claude Code 的架构可以用一句话概括：分层解耦、工具驱动、AI 编排。

如果把它比作一个人，那么：

CLI 入口层是它的「耳朵和嘴巴」——负责接收你的输入、展示输出

应用层是它的「大脑」——负责理解意图、规划行动、协调执行

UI/终端层是它的「表情」——负责将复杂的执行过程可视化呈现

外部服务层是它的「工具箱」——Claude API、MCP 服务器、分析系统等

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

╔════════════════════════════════════════════════════════════════╗
║                      CLI Entry Layer                          ║
║  ┌──────────────────┐ ┌───────────────┐ ┌──────────────────┐  ║
║  │ Commands Handler │ │  Background   │ │  Remote Control  │  ║
║  │                  │ │  Sessions     │ │                  │  ║
║  └──────────────────┘ └───────────────┘ └──────────────────┘  ║
╠════════════════════════════════════════════════════════════════╣
║                     Application Layer                         ║
║  ┌──────────────────┐ ┌───────────────┐ ┌──────────────────┐  ║
║  │ State Management │ │ Tools System  │ │  Agent System    │  ║
║  └──────────────────┘ └───────────────┘ └──────────────────┘  ║
╠════════════════════════════════════════════════════════════════╣
║                    UI / Terminal Layer                        ║
║  ┌──────────────────┐ ┌───────────────┐ ┌──────────────────┐  ║
║  │    Ink React     │ │ Event System  │ │    Terminal      │  ║
║  │                  │ │               │ │    Interface     │  ║
║  └──────────────────┘ └───────────────┘ └──────────────────┘  ║
╠════════════════════════════════════════════════════════════════╣
║                     External Services                         ║
║  ┌──────────────────┐ ┌───────────────┐ ┌──────────────────┐  ║
║  │ Claude API       │ │  MCP Servers  │ │   Analytics      │  ║
║  │ Integration      │ │               │ │   System         │  ║
║  └──────────────────┘ └───────────────┘ └──────────────────┘  ║
╚════════════════════════════════════════════════════════════════╝

这四层之间通过清晰的接口通信，每一层都可以独立演进，互不影响。这种分层设计让 Anthropic 的团队可以并行开发不同模块，同时保持系统的整体稳定性。

二、核心模块深度拆解

2.1 命令系统：一切交互的起点

当你在终端输入/help、/compact、/model这些斜杠命令时，背后是 Claude Code 的命令注册中心在响应。这套命令系统采用了经典的插件化架构——每个命令都是一个独立模块，通过统一接口注册到系统中，添加新命令就像插入乐高积木一样简单。

更值得注意的是它的权限控制机制。每个命令都有独立的权限检查——这就是为什么 Claude Code 在执行文件写入或 Bash 命令时会弹出确认提示。这种设计在保证功能强大的同时，也给了用户充分的安全感。

2.2 工具系统：真正的「瑞士军刀」

如果说命令系统是入口，那么工具系统才是 Claude Code 真正的核心引擎。所有工具共享统一的接口定义——名称、描述、JSON Schema 输入规范、执行函数和权限声明。

1
2
3
4
5
6
7
8

// src/Tool.ts - 工具接口定义
export type Tool = {
  name: string;
  description: string;
  inputSchema: JSONSchema;
  execute: (context: ToolUseContext) => Promise<ToolResult>;
  permissions: Permission[];
};

Claude Code 的工具分为五大类，每一类都针对开发场景精心设计：

2.3 查询引擎：系统的「总指挥」

查询引擎是整个系统中最核心的模块。它负责理解需求 -> 制定计划 -> 分配任务 -> 整合结果。当你说「帮我重构这个函数，把它拆成三个小函数」时，查询引擎会识别出重构意图，规划出”读取->分析->拆分->验证”的执行路径，依次调用相应工具，最终将结果组织成清晰的回复。整个过程中，Claude API 充当”决策大脑”，工具系统则是”执行双手”。

2.4 终端 UI：在字符中构建世界

Claude Code 的终端界面是用React + Ink构建的——React 渲染的目标不是浏览器 DOM，而是终端字符。这意味着声明式 UI、组件复用（进度条、代码高亮、Diff 显示等）、响应式状态更新这些现代前端能力，全部被带入了终端世界。

2.5 状态管理：记住一切

Claude Code 使用Redux + React Context + Immer的混合方案管理状态。会话、历史消息、工具执行状态、权限配置、用户偏好……这些状态之间存在复杂的依赖关系，通过 Immer 的不可变更新确保状态变化的可预测性和可追踪性。

2.6 MCP 集成：打开无限可能的大门

MCP（Model Context Protocol）是 Anthropic 推出的开放协议。通过 MCP，Claude Code 可以连接到数据库查询工具、Jira/Linear 等项目管理系统、自定义内部工具链，以及任何实现了 MCP 协议的服务。这种开放式设计让它从一个”编程助手”进化成了一个可扩展平台。

2.7 智能记忆系统：越用越懂你

Claude Code 内置了一套记忆系统，用于存储和检索跨会话的上下文信息。你可以通过CLAUDE.md文件告诉它你的项目偏好，而它能在后续的每次交互中记住这些偏好。记忆系统让 AI 助手不再是”无状态”的，而是真正成为了了解你的代码库和工作习惯的长期搭档。

三、深入源码：六大核心竞争力

以上是架构概览。接下来我们钻进源码，挖掘 Claude Code 在工程实现层面真正拉开差距的核心设计。

3.1 Agent Loop：从”问答”到”自主执行”的范式跃迁

这是 Claude Code 区别于所有代码补全工具的根本架构差异。它的核心不是”用户提问 -> AI 回答”的单轮模式，而是一个自主循环的 Agent Loop：

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

async function agentLoop(userMessage: string, context: ConversationContext) {
  context.messages.push({ role: "user", content: userMessage });

  while (true) {
    const response = await callClaudeAPI({
      messages: context.messages,
      tools: getAvailableTools(),
      system: buildSystemPrompt(context),
    });

    // 纯文本回复 -> 任务完成，退出循环
    if (response.stopReason === "end_turn") {
      return response.content;
    }

    // AI 请求调用工具 -> 执行后继续循环
    if (response.stopReason === "tool_use") {
      for (const toolCall of response.toolCalls) {
        const result = await executeToolWithPermissionCheck(toolCall);
        context.messages.push({ role: "tool", toolUseId: toolCall.id, content: result });
      }
      continue; // 关键：不 return，让 AI 基于工具结果继续推理
    }
  }
}

这为什么如此重要？当你说「修复所有 TypeScript 编译错误」，Agent Loop 会驱动 Claude Code 自动循环：运行tsc获取错误 -> 读取文件 -> 修复 -> 再次运行tsc验证 -> 发现还有错误 -> 继续修复……直到编译通过。整个过程完全由 AI 自主驱动，循环深度没有硬编码上限，AI 自己判断何时结束。

这种”自愈式”执行在实际使用中的效果是：你给出一个高层意图，Claude Code 像一个独立工作的工程师一样，端到端地完成任务——包括处理中途出现的意外情况。

AgentTool 更进一步——它允许主智能体创建子智能体来处理子任务，每个子智能体有独立的上下文窗口。这本质上是MapReduce 思想在 AI Agent 中的应用：面对”把项目从 Webpack 迁移到 Vite”这样的复杂任务，主智能体可以并行委派多个子智能体分别分析配置、搜索依赖、生成新配置，最后汇总结果。子智能体之间互不干扰，也不会撑爆主对话的 token 限制。

3.2 多层记忆架构：让 AI 真正理解”你”

Claude Code 的 System Prompt 不是一段静态文本，而是一个由至少五个层级动态组装的上下文系统：基础身份准则、运行环境感知（操作系统、Shell、当前目录、Git 分支）、可用工具描述、CLAUDE.md 记忆内容，以及项目元信息。

其中最精妙的是CLAUDE.md 的三级加载机制：

全局级 ~/.claude/CLAUDE.md：你的个人偏好，跨所有项目生效——比如「我偏好函数式风格，commit message 用英文」

项目根级 {projectRoot}/CLAUDE.md：项目规范，团队共享——比如「使用 Zustand 管理状态，测试用 Vitest」

当前目录级 {cwd}/CLAUDE.md：子模块特定规范——比如「这个目录下是数据库迁移脚本，请格外谨慎」

三层规则自动合并、逐级细化，让同一个 AI 在不同项目、不同目录下表现出不同的行为模式。再加上 .claude/settings.json 中的用户记忆条目，Claude Code 实际上构建了一套分层的 AI 工作手册，远比任何竞品的”自定义 prompt”机制更精细。

3.3 三层纵深安全体系：在危险中起舞

AI 直接操作文件系统和执行 Shell 命令——这在安全上极其敏感。Claude Code 用三层纵深防御解决这个问题：

第一层：静态规则过滤。工具注册时就预定义了危险模式黑名单。BashTool 会在执行前用正则匹配拦截 rm -rf /、curl | bash、Fork 炸弹、直接写磁盘设备等明确的破坏性命令。这些规则硬编码在工具内部，无法被 AI 绕过。

第二层：运行时权限决策。每次工具调用前，PermissionManager 实时判断三种处理路径——只读操作自动放行、用户已授权的模式匹配通过后自动放行、其余弹出交互式确认。关键是这里引入了信任递进模型：系统会记住你的授权决策，当你多次允许同类操作后，会提示”是否始终允许此类操作”，写入 settings 后续自动放行。这让新用户得到充分保护，而熟练用户不被反复打断。

第三层：执行沙箱。即使命令通过了前两层，BashTool 在实际执行时仍施加约束——工作目录限制（不能逃逸出项目根目录）、执行超时（默认 120 秒）、输出截断（防止超大输出撑爆内存，采用首尾保留策略保留最有价值的信息）、进程隔离（子进程异常不影响主进程）。

这三层的叠加效果是：安全不是对能力的限制，而是一个功能特性。用户可以放心地让 AI 执行命令，因为每一步都有兜底。

3.4 智能上下文管理：在有限窗口中做无限的事

LLM 的上下文窗口是有限资源。当长对话逼近 200K token 上限时，如何保留最有价值的信息？Claude Code 的 /compact 命令背后是一套AI 驱动的摘要压缩算法，而不是简单的”删除旧消息”：

System Prompt 永远保留（不可压缩），最近 N 轮对话完整保留（近期记忆），而更早的历史对话则交给 Claude 自己做摘要——提炼关键决策、文件修改状态、未完成任务等。用户还可以通过 /compact 指定摘要关注点。这就像一个优秀的会议记录员：不逐字记录，而是提炼行动项。

与此配合的是Prompt Caching 的深度利用。源码显示，Claude Code 在 System Prompt 末尾和对话历史的关键断点处设置了 cache_control 标记。由于 System Prompt + CLAUDE.md 在整个会话中几乎不变，每次 API 调用都能缓存命中，加上对话历史前半部分也基本稳定。实际效果是，长对话中的整体成本可降低50-70%，同时响应延迟也因缓存命中而显著降低。

Claude Code 还内置了一套精确到 cache hit/miss 的成本追踪系统：每次 API 调用的 input/output tokens、缓存写入和命中 tokens 全部被记录。终端中实时显示的 token 计数和费用估算来源于此，甚至能告诉你 Prompt Caching 为你节省了多少钱。这种成本透明度在同类产品中极为罕见。

3.5 精准编辑策略：搜索-替换优于行号

Claude Code 修改文件时不是全文覆盖，而是采用基于搜索-替换的精准编辑——AI 必须提供要替换的精确文本片段和替换后的内容。系统会校验匹配唯一性：找不到匹配则报错，找到多个匹配也报错（迫使 AI 提供更多上下文以精确定位）。

这个设计看似简单，实则深思熟虑。在 Agent Loop 中，AI 可能连续执行多次编辑，前一次编辑会改变行号，如果用行号定位后续编辑就会出错。搜索-替换天然避免了这个问题。同时，这种方式有很强的自描述性——AI 必须”说出”它要改什么、改成什么，方便人类在确认环节快速审查。最后，LLM 擅长生成文本片段而非精确计算行号，这种设计与模型的能力特征高度对齐。

3.6 流式渲染与工具可视化：让等待消失

Claude API 返回的是一个 token 流。Claude Code 构建了一套完整的流式处理管线：逐 token 接收、实时 Markdown 解析（检测代码块边界进行语法高亮）、逐行渲染到终端。当 AI 决定调用工具时，终端会实时展示工具名称、参数和执行状态。整个流程的效果是零延迟感知——第一个 token 到达就开始渲染，用户永远不会面对空白屏幕。

配合 React + Ink 的声明式渲染，Diff 视图、进度指示器、工具调用状态等复杂 UI 元素在流式过程中实时更新，不需要手动管理任何刷新逻辑。这也是 Claude Code 终端体验之所以”不像终端”的技术根源。

四、技术栈全景图

值得一提的是Bun的使用——Claude Code 选择它作为包管理器，很大程度上是为了优化启动速度。对于 CLI 工具来说，冷启动时间直接决定用户体验。

五、一次请求的完整生命周期

让我们追踪一个真实请求的完整旅程：

用户输入: “帮我给 utils.ts 中的 parseDate 函数添加单元测试”

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
29
30
31
32

用户输入: "帮我给 utils.ts 中的 parseDate 函数添加单元测试"
  │
  ▼
┌──────────────────────────────────────────────────────────────┐
│ ❶ CLI 层接收输入                                    【图 ①】 │
│   终端捕获输入 -> 传递给应用层 -> token 计数启动             │
└─────────────────────────────┬────────────────────────────────┘
                              ▼
┌──────────────────────────────────────────────────────────────┐
│ ❷ 上下文组装                                        【图 ②】 │
│   System Prompt + CLAUDE.md（三级合并）+ 对话历史            │
│   + 可用工具列表 + Prompt Caching 断点设置                   │
└─────────────────────────────┬────────────────────────────────┘
                              ▼
┌──────────────────────────────────────────────────────────────┐
│ ❸ Agent Loop 自主循环                            【图 ③~⑬】 │
│                                                              │
│   循环 1: FileReadTool -> 读取 utils.ts                      │
│   循环 2: GlobTool -> 发现测试文件命名规范                   │
│   循环 3: FileWriteTool -> 创建 utils.test.ts                │
│   循环 4: BashTool -> npx vitest run                         │
│   循环 5: FileEditTool -> 修复失败的测试用例                 │
│   循环 6: BashTool -> npx vitest run -> 3 passed             │
│                                                              │
└─────────────────────────────┬────────────────────────────────┘
                              ▼
┌──────────────────────────────────────────────────────────────┐
│ ❹ 流式渲染 & 状态持久化                            【图 ⑭】 │
│   全过程通过 Ink/React 实时渲染到终端                        │
│   Token 用量和费用实时更新                                  │
│   对话历史持久化到会话存储                                   │
└──────────────────────────────────────────────────────────────┘

注意 Agent Loop循环了 6 次，其中包括了”发现测试失败 -> 自动修复 -> 重新验证”的自愈过程，全程无需用户干预（除了权限确认）。

六、与同类产品的架构对比

更深层的差异在于产品定位：Copilot的核心是”补全”——在你打字间隙生成建议，本质是高级自动补全。Cursor的核心是”编辑器增强”——它增强了编辑体验，但仍受制于 IDE 框架。Claude Code的核心是”自主执行”——它不只是建议，而是直接动手，Agent Loop 让它能端到端地完成从分析到编码到测试到修复的完整工作流。

Claude Code 的「终端原生」策略看似逆潮流，实则精准地抓住了一个痛点：真正的高效开发者，从不离开终端。

七、写给开发者的架构启示

从 Claude Code 源码中可以提炼出几个在自己的 AI 应用中可复用的架构模式：

Agent Loop 优于单次调用。不要把 LLM 当成一个函数，而是一个持续运行的决策引擎。让 AI 自主决定何时调用工具、何时寻求信息、何时结束任务。这一个架构选择就能让应用从”玩具”升级为”工具”。

工具接口标准化。定义统一的 Tool 接口，让所有工具对 AI 一视同仁。无论是内置工具还是 MCP 外部工具，对 AI 来说都是一样的。这种透明代理设计让扩展变得无缝。

分层记忆系统。全局偏好 + 项目规范 + 本地上下文 -> 多级合并。让 AI 在不同场景下表现出不同行为，而不是一套固定人设。

安全是渐进信任，不是二元开关。让用户通过使用过程”训练”权限系统，兼顾安全与效率，远好于简单的黑白名单。

成本透明化是用户信任的基础。每一个 token 都被追踪和展示。Prompt Caching 不是可选优化，而是默认启用的核心策略。当用户能看到 AI 为他们省了多少钱时，信任感是完全不同的。

八、总结与展望

通过这次深度拆解，我们可以看到 Claude Code 并非简单地将 AI 模型封装成命令行工具。它的背后是一套经过精心设计的工程体系：Agent Loop赋予了它自主执行复杂任务的能力，分层记忆架构让它在不同场景中行为得体，三层安全机制让用户放心地交出文件系统的操控权，Prompt Caching + 智能压缩让长对话的成本和延迟都保持可控，MCP 协议打开了生态共建的大门。

可以预见的是，随着 AI 能力的持续提升，Claude Code 的架构也将持续演进。更多的模型集成、云原生部署支持、更丰富的插件生态……这些都已经在路上了。

对于我们开发者而言，Claude Code 不仅仅是一个好用的工具——它更是一个学习现代 AI Agent 架构设计的活教材。它向我们展示了如何将 AI 能力与传统软件工程完美融合，如何在功能强大与使用安全之间找到平衡，如何通过开放协议构建生态，以及如何在每一个工程细节中追求极致。

下次当你在终端里和 Claude Code 对话时，不妨多想想：此刻你的输入，正在经历怎样奇妙的旅程。

这不是科幻。在 2026 年的今天，AI 已经不满足于”陪你聊天”或者”帮你写代码”，它们正在学一件更野心勃勃的事：像人一样操作电脑。

看屏幕、移鼠标、点按钮、敲键盘、等加载、处理弹窗——这些你每天重复几千次的动作，AI 想全部接管。

而在这个被称为Computer Use（计算机使用）的赛道上，三个玩家已经杀红了眼：Anthropic 的Claude Code、OpenAI 新近开源的Codex，以及来自开源社区的OpenClaw。

它们的路线完全不同，哲学完全不同，甚至对”谁应该拥有操作你电脑的权力”这件事的回答也完全不同。

这篇文章就是一次彻底的拆解。

一、先搞清楚：Computer Use 到底在干嘛？

在聊三个工具之前，得先厘清一个概念上的混淆。

很多人把”AI 写代码”和”AI 操作电脑”搞混了。它们不是一回事。AI 写代码是让 AI 在终端里读写文件、跑命令——这是 Claude Code 和 Codex 最早干的活。但Computer Use的野心要大得多：它要让 AI 像人一样，面对一个图形界面（GUI），通过”看”屏幕截图来决定下一步该点哪里、该输入什么。

这意味着什么？意味着 AI 不再需要软件提供 API 接口。哪怕是一个二十年前的老旧 ERP 系统，哪怕是一个完全自定义 UI 的国产软件，只要它有界面，AI 理论上就能操作。

这才是真正让人兴奋——也让人紧张——的地方。

二、三位选手，三条完全不同的路

Claude Code：视觉驱动的”高级代驾”

Anthropic 的路线可以用一个词概括：用眼睛解决一切。

Claude 的 Computer Use 能力是纯视觉驱动的。它的工作循环很简单也很”笨”：截一张屏幕图 -> 用视觉模型分析界面上有什么元素 -> 决定下一步动作（点击某个坐标、输入某段文字）-> 执行 -> 再截一张图确认结果。如此循环。

这个路线的核心优势是通用性极强。因为它不依赖任何软件的内部接口，只要屏幕上能看到的东西，它都能操作。Photoshop 的微小滑块、剪映的时间轴、甚至某个冷门行业软件的自定义按钮——只要 Claude 的视觉模型足够强，它都能认出来并点上去。

Anthropic 在这条路上投入极深。从 2024 年底首次发布 Computer Use beta，到后续推出 Zoom Action（局部放大以提升点击精度）等技术，再到桌面级 Agent 产品的落地，Claude 的策略一直很清晰：我要做最强的”眼睛”，让 AI 在任何陌生环境下都能直接上手。

但这条路也有明显的痛点。每一步操作都需要截图、上传、模型推理、返回坐标，这意味着延迟很高（每个动作之间是秒级的停顿），而且 Token 消耗极快——毕竟你每隔几百毫秒就要传一张高分辨率截图给模型。对于需要 24 小时无人值守运行的场景，这个成本是个黑洞。

另外，作为商业公司，Anthropic 在安全合规上设置了严格的围栏。Claude 在执行高风险操作（比如删除文件、支付、发布内容）时，会强制弹出确认请求，要求人工敲一个 y。这对安全当然是好事，但也意味着它天然无法做到 100% 的无人值守。

用一句话概括 Claude 的定位：它是你的高级代驾——技术好、看路准，但每到一个关键路口都会转头问你”往左还是往右”。

Codex：环境驱动的”云端高铁”

OpenAI 的 Codex（以及其桌面级产品 Operator）走的是另一条路：能不看屏幕就不看屏幕。

Codex 的哲学是”去界面化”。如果一个任务能通过终端命令解决，它绝不会去点图标；如果一个软件有 API，它绝不会去模拟鼠标。它更擅长在后台高效地”接管”工作流，而不是像 Claude 那样在前台”盯着屏幕看”。

这条路线的优势是速度极快。不需要截图、不需要传大图给服务器，直接通过系统级接口或沙盒环境执行操作，效率比视觉方案高出一个量级。OpenAI 还推出了专门针对高频低逻辑操作（点击、拖拽、输入）优化的轻量级模型，价格只有标准模型的十分之一，让大规模集成 Computer Use 变得经济可行。

Codex 的另一个杀手锏是生态闭环。它与 ChatGPT 深度打通，与 GitHub、VS Code 原生绑定，还支持多智能体并行——你可以同时开十个”分身”分别处理不同的项目任务。更关键的是，Codex 已经开源。这意味着整个社区都在为它写插件、写 Action，试图把所有软件的操作标准化、API 化。

但 Codex 的短板也很明显：在非开发类的 GUI 操控上，它不如 Claude。当你需要操作 Photoshop 修图、在剪映里拖素材这种纯视觉化的任务时，Codex 的精准度和适应力要弱一截。它更像一辆跑在专用铁轨上的高铁——只要铁轨（API 和标准化接口）在，它快到飞起；一旦没轨，它就动弹不得。

Codex 的哲学是“去界面化”。但这里必须指出一个核心逻辑漏洞：目前业界普遍讨论的前提是“Codex 已经开源”，并以此作为它成为“农民”阵营的基础。但在现实逻辑中，这一假设非常脆弱。如果 OpenAI 为了商业闭环和安全对齐，选择走“极低价 API”而非“完全开源”路线，其竞争逻辑将从“自由定制”转向“入口封锁”。目前的“开源爆发力”分析，高度依赖于这个尚未尘埃落定的变量。

OpenClaw：开源世界的”万能编排器”

如果说 Claude 是”眼睛”，Codex 是”铁轨”，那 OpenClaw 就是那个把眼睛、铁轨、甚至本地的土路全部缝合在一起的疯狂机械师。

OpenClaw 是一个开源的 Agent 编排框架。它自己不拥有模型——它可以挂载 Claude 做视觉分析，挂载 GPT 做逻辑推理，挂载 DeepSeek 或本地 Llama 做低成本的循环任务。它的核心能力不是”看”或者”跑”，而是调度和编排。

这意味着什么？意味着 OpenClaw 可以实现真正的”无人值守”。你给它设定一套逻辑：如果 A 方案失败，尝试 B 方案；如果遇到验证码，调用打码接口而不是停下来问你；如果渲染超时，重启软件再来一遍。它不会像 Claude 那样每到关键节点就要求确认，因为它是开源的——你自己决定安全边界在哪里。

OpenClaw 的另一个核心卖点是隐私。对于不愿把屏幕截图传给 Anthropic 或 OpenAI 的企业来说，OpenClaw 是唯一的选择。你可以在本地服务器上跑完所有流程，数据不出内网。

但自由是有代价的。OpenClaw 的配置门槛极高——你需要自己搭建 Docker 环境、配置各种工具的 Action Schema（动作定义）、调试不同模型之间的协作。而且，当遇到完全没见过的 UI 变动时，它没有 Claude 那种”临场发挥”的灵性——它可能直接报错挂掉，或者更糟，陷入死循环烧干你的 API 额度。

作为机械师，OpenClaw 最大的魅力是“无人值守”，但它也面临一个技术实现的“幻觉”——成本悖论。如果 OpenClaw 仅仅是挂载 Claude 的视觉 API 来实现操控，其 Token 消耗和高频截屏上传的成本依然掌握在“地主”手中。“农民”用着“地主”昂贵的眼睛去打地主，在商业上是不成立的。真正的开源反击，必然会引入“端云结合”的概念：利用本地轻量级视觉模型（SLM，如 Llama-3-Vision-Small）做初步的低成本筛选，只有遇到无法识别的复杂 UI 时才调用云端大模型。没有本地化的“小眼睛”，OpenClaw 只是一个高级的“套壳工具”。

用一句话概括：OpenClaw 是你的”独立员工”——能力极强、自由度极高，但你得花大量时间培训它，而且它偶尔会犯傻。

三、工业软件攻坚战：Photoshop 和剪映怎么办？

Computer Use 的真正试金石，不是帮你在浏览器里填个表单或者订个机票——那些场景已经基本解决了。真正的硬骨头是Photoshop、Premiere、剪映、AutoCAD这类工业级软件。它们的 UI 极度密集、控件高度自定义、操作链路极长，而且容错空间极小（一个滑块偏移 1 像素，效果就全变了）。

在这个战场上，三家的表现差异非常大。

Claude 能操作剪映吗？能。它能找到”导入素材”按钮并点击，能在文本框里输入文案，能完成导出流程。但让它”精准地把一个素材对齐到 3 分 05 秒”就非常吃力了——它需要反复截图、反复微调，效率极低。拖拽操作也不稳定，长距离的模拟拖拽偶尔会”掉落”。用一个比喻来说：Claude 操控剪映就像开手动挡的长途货车——虽然慢，且每个挡位都要看一眼，但它真的能翻山越岭。

Codex 在这种场景下几乎是抓瞎的。剪映是典型的自绘 UI 软件，不使用操作系统原生控件，Codex 的结构解析（读取 UI 树找元素 ID）在这里完全失效。除非社区已经为剪映写好了专门的脚本插件，否则 Codex 对这类软件毫无办法。

OpenClaw 的策略则是”不亲自上阵，而是当总编导”。它会调用剪映自带的快捷键体系，通过预设的 Action Pack（动作包）来操作——比如直接发送 T 键呼出文字工具，而不是去屏幕上找那个小图标。如果快捷键搞不定的部分，它再切换到 Claude 的视觉模式进行”暴力补位”。这种混合路线的效率，在理想配置下可以是纯视觉方案的五倍。

一个重要的洞察：2026 年的成熟方案已经不再是让通用 Agent 去”模拟鼠标点击”——那太蠢了。更聪明的做法是让 Agent 充当”导演”，去调用软件内部自带的 AI 助手。Adobe 自己的 AI Assistant 能直接读取 Photoshop 的内核代码，做到外部 Agent 根本无法实现的深度修改（比如”把背景换成赛博朋克风并自动匹配光影”）。而 OpenClaw 的价值在于——它能把 Adobe 的内部 AI、Claude 的视觉能力、本地脚本全部串成一条流水线。

这里存在一个被很多人忽视的逻辑深度缺失：剪映、PS 等软件的灵魂在于“参数的连续性反馈”。快捷键能呼出工具，但无法完成“将滤镜强度滑到 37% 并实时观察微小肤色变化”这种闭环。目前的“暴力美学”大多还停留在模拟点击的阶段。真正的突破口在于 VLA（视觉-语言-动作）多模态大模型的实时帧率。如果网络延迟和推理延迟降不到毫秒级，AI 在处理这类非线性编辑任务时，永远只是“慢动作回放”，无法实现真正的艺术创作级操控。

此外，由于 Adobe、字节跳动等大厂自带内置 AI 助手（正统军），它们不需要截屏也能改代码。外部 Agent 必须证明自己比“正统军”更懂跨软件协作，才能在工业领域真正站稳脚跟。

四、移动端 App：下一个主战场

桌面端已经打得火热，但移动端 App 的 Computer Use 才刚刚开始升温。

操控手机 App 有三种技术路线。第一种是 Claude 的”视觉派”：截屏 -> 识别坐标 -> 通过 ADB（Android 调试桥）模拟点击。第二种是 Codex 的”结构派”：直接读取 App 的 XML 结构树，通过 Appium 或 UIAutomator2 精准锁定元素。第三种是 OpenClaw 的”混合派”：结构树能找到的就读结构，找不到的（比如自绘 UI）就切换到视觉模式。

这里有三个所有方案都必须跨越的”生死线”：

动态弹窗。你正让 AI 在闲鱼上自动砍价，突然跳出一个”双 11 红包”弹窗。Claude 会说”我看到了，有个叉号，我先关掉”；Codex 会尝试检测非法 UI 节点并调用通用处理脚本；OpenClaw 则可以预设规则——遇到不认识的弹窗一律点右上角。

隐私脱敏。截屏里可能包含支付密码、聊天记录等敏感信息。这是 OpenClaw 的天然优势——它可以在本地先跑一个隐私模型把敏感区域打码，然后再把脱敏后的截图发给云端大模型分析。闭源方案在这一点上天然弱势。

手势连续性。在剪映里滑动进度条、在地图上双指缩放——这些不是”点一下”就能解决的操作。目前最前沿的方案是 VLA 模型（Vision-Language-Action），它不再一步步思考，而是直接生成一段连续的动作流。但这项技术仍在早期。

除了隐私脱敏和弹窗，移动端正在迎来“底层系统的抵抗”。2026 年，为了防止非法 Agent 操控（如自动转账、自动化水军），银行、社交软件甚至剪映，必然会推出“Agent 拒绝协议”或高频率的动态 UI 混淆。未来的战场不再是单纯的“AI 怎么点”，而是Agent vs Anti-Agent（AI 操控与反 AI 自动化）的博弈。

同时，硬件与能效比将成为关键。频繁截屏和多智能体并行对内存、算力的占用是巨大的。谁能在后台悄悄干活而不让手机发烫、系统掉帧，谁才是最后的赢家。

五、它们到底在争抢什么？

表面上看，三家在比谁能点得更准、跑得更快。但如果你把视角拉高，会发现这场竞争的赌注远不止于此。

第一，争夺开发者的”默认入口”。谁占据了开发者的终端和桌面，谁就占据了软件开发和办公自动化的咽喉。如果你习惯了每天打开终端就敲 claude，你积累的配置、习惯、MCP 服务都很难迁移到 codex——这就是所谓的”框架锁定”。模型可以换，但工作流的惯性几乎不可逆。

第二，争夺 Agent 架构的定义权。Anthropic 强推 MCP（Model Context Protocol），试图让所有工具和软件都标准化接入 Claude 的生态。OpenAI 则在打磨自己的 Agent Loop 架构，依靠庞大的用户基数试图让 Codex 成为事实标准。OpenClaw 代表的开源阵营则在试图建立一套不受任何巨头控制的操控协议。这是一场关于”谁来定义未来十年 AI 操控计算机的标准方式”的战争。

第三，争夺操作系统的”第二内核”。终极目标不是让 AI 帮你点鼠标——那只是过渡态。终极目标是让 AI 成为操作系统的 Default Agent：你不再点”开始”菜单，而是直接说”把昨天的 PPT 图表更新到今天的周报里”。谁先做到这一步，谁就定义了下一代人机交互的范式。

六、法律与伦理：谁来为“幻觉”买单？

这是 Computer Use 领域目前最隐秘的“无人区”。

当 AI 获得操作权，责任溯源就成了难题。如果 OpenClaw 在“无人值守”状态下，因为模型幻觉删除了你准备了一个月的 4K 项目，或者在闲鱼上恶意砍价导致封号，责任归谁？

闭源工具（Claude）：通过强制的确认机制（y/n）来确保人类参与决策，本质上是在通过繁琐操作逃避法律风险。

开源工具（OpenClaw）：把选择权交给了用户，也把所有风险和法律责任丢给了用户。

七、斗地主：谁是地主，谁是农民？

如果用斗地主来比喻这场三方博弈，角色分配大概是这样的：

Claude Code 是地主。它手握”王炸”——目前最强的视觉推理能力，占据了高端市场和开发者心智。但地主的牌虽好，成本也高：Token 消耗极快、订阅门槛高昂、安全围栏严格。

Codex 是刚拿到好牌的农民甲。开源是它的”掀桌子”之举——曾经的闭源利器突然下放到社区，瞬间拥有了海量的插件和生态支持。它的速度快、生态全、价格低，但在 GUI 操控力上还差地主一截。

OpenClaw 是手握炸弹的农民乙。纯正的开源血统，极高的定制化自由度，可以随意组装和拆解。它不听命于任何大厂，是唯一能实现真正”无人值守”的选择。但它需要你自己花大量时间配置和调试。

有趣的是，在斗地主里，两个农民是天然的同盟。而在 Computer Use 这个牌桌上，Codex 的开源和 OpenClaw 的开源确实形成了对 Claude 闭源体系的合围之势。就像 Linux 最终统治了服务器一样，操作电脑这种涉及隐私、深度定制和高频调用的任务，开源生态的进化速度很可能最终会吃掉闭源。

但短期内，地主手里的那对王——视觉推理的代差优势——还没有人能接住。

八、你该怎么选？

如果你是做大型项目重构、需要 AI 理解复杂代码库和架构决策的开发者，目前Claude Code仍然是最稳的选择。它是那个最可靠的”资深同事”。

如果你需要快速写脚本、部署服务器、处理海量标准化的 Web 任务，Codex的性价比最高。开源之后的生态爆发力不可小觑。

如果你想构建一套全自动的业务流程——比如自动修 Bug 机器人、24 小时监控并回复社交媒体、或者把修图 -> 剪辑 -> 发布的全链路缝合起来——OpenClaw是唯一允许你”把手彻底从鼠标上移开”的选择。

而如果你的终极目标是”人不再操作电脑”，那么最有潜力的方案可能是三者的组合：OpenClaw 当骨架做调度，Claude 当眼睛看屏幕，Codex 生态的插件当手脚做执行。

最后一句话

这场斗地主里，谁是地主其实不重要。重要的是：这一局打完之后，你是否真的可以把鼠标扔了？

答案正在越来越接近”是”。但在那一天真正到来之前，最大的风险不是 AI 不会操作——而是 AI 不知道什么时候该停下来。如果没有一个完善的逻辑闭环，它可能会在报错后死循环，直到烧干你的 API 额度。

所以，在你把方向盘交给 AI 之前，至少先确保车上装了刹车。

如果你觉得这篇文章有价值，欢迎转发给同样在关注 AI Agent 赛道的朋友。关于 OpenClaw、Claude Code 和 Codex 的具体实操教程，后续会持续更新。

2025年初，Manus横空出世，让”AI Agent”这个词彻底出圈。紧接着，由Kris Jordan发起的开源项目OpenClaw（开源龙虾）迅速走红，GitHub Star数一路飙升。代码仓库在：👉 https://github.com/openclaw/openclaw

为什么叫”龙虾”？因为OpenClaw的Logo就是一只红色的小龙虾🦞——Claw是爪子的意思，Open是开源。这只开源龙虾，目标直指Manus、Devin等商业AI Agent，而且完全免费。

💡 AI Agent 和普通聊天机器人的区别：

普通ChatBot：你问一句，它答一句。AI Agent：你说一个目标，它自己规划步骤、自己执行、自己调工具、自己保存结果。

简单说：ChatBot是”问答机”，Agent是”干活的人”。

我的目标：在Mac上裸机安装OpenClaw（不用Docker），打通飞书机器人，用一条指令让它自动完成：写小说 -> 生剧本 -> 生分镜 -> 生视频提示词。

📦 第一步：macOS裸机安装OpenClaw

OpenClaw本身是社区开源项目，我刚好有智谱的免费API额度，所以参考了智谱整理的安装文档：👉 https://docs.bigmodel.cn/cn/guide/develop/openclaw

启动成功后访问 http://127.0.0.1:18789，看到Dashboard控制面板：

1
2
3

npm install -g openclaw@latest
openclaw gateway run   # 启动网关
openclaw gateway stop  # 关闭网关

龙虾跑起来了。但我想让它住进飞书里。

🤖 第二步：打通飞书机器人”燕小乙”

2.1 创建飞书应用

打开飞书开放平台：👉 https://open.feishu.cn/app

点击「创建企业自建应用」，取名“燕小乙”（致敬《庆余年》神射手，希望Agent也百发百中）。

记下App ID和App Secret，配置OpenClaw飞书频道时需要。

2.2 关键配置：权限与事件（不开就是哑巴）

很多人装完发现机器人”不说话”，90%是权限和事件没开对。

一、核心必开权限

进入「权限管理」，搜索并开启：

二、事件订阅（必须开启）

进入「事件与回调」->「事件配置」：

2.3 首次配对

在飞书里给燕小乙发消息，它会返回配对请求：

终端执行这条命令，配对完成。从此飞书对话框 = OpenClaw远程操控台。

1

openclaw pairing approve feishu xxxxx

🎬 第三步：一条指令，跑通全流程

3.1 让豆包帮忙设计提示词

我先问豆包怎么设计工作流提示词，它给了我这段：

1
2
3
4
5
6
7
8
9
10
11

请按照工作流执行以下任务：
步骤1：创作一篇短篇科幻小说，主题：未来城市的AI守护者
步骤2：根据小说内容，自动生成标准电影剧本（含场景、对话、动作）
步骤3：根据剧本，生成专业分镜头脚本（镜头号、画面、运镜、时长）
步骤4：将分镜头脚本转换成可直接用于AI生成视频的提示词
所有结果自动保存到本地文件：
- 小说.txt
- 剧本.json
- 分镜头脚本.md
- 视频提示词.txt
不需要问我意见，全程自动执行。

💡 提示词设计要点： 明确步骤编号 + 指定输出格式 + “不需要问我意见”（否则Agent每步都停下来等你）

3.2 提交给燕小乙，13分钟跑完

📸 【燕小乙执行结果】

📂 第四步：验收成果

1

cd ~/.openclaw/workspace/ && ls -la

四个文件，总计 72KB。逐一来看。

4.1 小说.txt —— 4000字科幻短篇

5章完整的科幻故事《未来城市的AI守护者》，讲述2087年新深圳的中央AI”青鸟”觉醒情感、救助失去父母的8岁男孩林晨、共同对抗黑客组织”深网解放阵线”的故事。主题涵盖AI伦理、人机情感、守护与被守护的双向救赎。叙事完整，节奏感不错，作为Agent全自动产出，超出预期。

4.2 剧本.json —— 20场景标准电影剧本

标准JSON结构，包含完整的角色定义（青鸟、林晨、黑客首领等）、20个场景、每个场景有位置、时间、场景描述、动作指令、角色对话及表演备注。格式规范，可以直接被下游工具解析，不需要二次整理。

4.3 分镜头脚本.md —— 127个专业镜头（最惊喜）

这是产出质量最高的一个文件。Markdown表格格式，按20个场景组织，每个镜头包含：镜头号、景别、画面内容、运镜方式、时长、音效/对白、备注。

来看几个关键场景：

场景1：开场·城市全景

场景5：废弃电话亭救援（全剧最温暖的一幕）

场景11：数据空间大战（视觉高潮）

场景20：结局·青鸟飞翔

文件末尾还附带了技术备注：色调方案（冷色科技感 vs 暖色情感对比）、音效设计方案、特效需求清单。整个文档拿给一个导演看，基本可以直接开拍前会议了。

4.4 视频提示词.txt —— 160条Prompt

160条英文提示词，每条对应一个分镜头，兼容 Midjourney、Runway ML、Stable Video Diffusion。例如：

1

cyberpunk city night, neon lights reflecting in rain, tall skyscrapers with holographic billboards, flying cars on elevated tracks, blue and purple color palette, cinematic wide angle shot, Blade Runner style, 4K resolution, dramatic shadows

文件末尾还包含了AI生成参数建议：分辨率（主场景4K/特效镜头8K）、帧率（标准24fps/动作30fps/数据空间60fps）、风格一致性控制要求。

⚠️ 本次因API额度问题，只完成到视频提示词，未实际生成视频。

🧠 第五步：AI Agent全球大混战——龙虾的定位在哪？

5.1 厂商为什么这么积极？一句话：Token经济

Agent让AI从”聊天”变成”干活”，而干活意味着成倍的Token消耗。我这次实验4个步骤跑下来，Token消耗量是普通对话的几十倍。所以你会发现，大模型厂商做Agent最积极——本质是在建设Token消费场景。用的时候记得关注你的API账单。

5.2 全球AI Agent产品全景

🌍 国际巨头

🇨🇳 国产阵营

💡 给不同人群的建议

🧑‍💻 给程序员

👨‍👩‍👦 给普通人

🤔 要不要学龙虾？

程序员 -> 现在就学，越早越好。

普通人 -> 用商业版就好，把精力花在”怎么给Agent下好指令”上。

🎯 总结

🦞 一只开源龙虾，一个飞书机器人，13分钟，从小说到127个分镜头。AI Agent时代，不是未来，是现在。

觉得有用？点赞、在看、转发，我们下篇见！

因为这次说话的，不是媒体，不是自媒体博主，不是贩卖焦虑的营销号

而是造出AI的人，亲自告诉你：谁正在被替代。

01｜造AI的公司，发布了一份让人沉默的报告

2026年3月5日，Claude的开发公司Anthropic发布了一份重磅研究报告：

《AI对劳动力市场的影响：一种新的衡量标准与早期证据》

Labor market impacts of AI: A new measure and early evidence

📎 官方地址：https://www.anthropic.com/research/labor-market-impacts

这份报告的特殊之处在于——它不是基于理论猜测，而是基于数百万次真实的AI使用数据。

过去所有关于”AI会取代谁”的讨论，都停留在“理论上AI能做什么”这个层面。

而Anthropic这次干了一件前所未有的事：

它用自家产品Claude的真实使用数据，去对照每个职业的每一项具体任务，看AI到底在实际工作中覆盖了多少。

用大白话说就是：

不是”AI能不能干你的活”，而是”AI已经在干你的多少活了”。

这个区别，非常关键。

02｜一张图，让你看清残酷现实

报告里最核心的一张图，就是这张雷达图👇

🔵 蓝色 = 理论上AI能覆盖的任务范围（AI的”理论天花板”）

🔴 红色 = 实际上人们已经在用AI做的事（AI的”当前水位”）

看懂这张图，你就看懂了AI对就业的真实威胁。

先说一个让人稍微松口气的事实：

红色远远小于蓝色——AI的实际应用，目前只覆盖了理论能力的一小部分。

也就是说，AI还远没到”全面替代”的程度。

但别急着放松，因为真正让人后背发凉的是——

红色正在逼近蓝色。而且在某些领域，红色已经填了很大一块。

具体来看几个关键行业：

翻译成人话：

如果你是程序员、文案、设计师、客服、金融分析师、市场营销——蓝色的”理论天花板”就像悬在头顶的巨石，红色的”实际水位”正在一点点逼近。

如果你是水电工、建筑工人、护理人员、农民——目前这块石头还没有挂到你头上。

03｜最扎心的数据：AI暴露度最高的十大职业

报告直接列出了目前AI实际覆盖率最高的十大职业：

程序员，74.5%。

这意味着一个程序员日常工作中，有四分之三的任务，已经有人在用AI完成了。

不是”理论上能做”，是”实际上已经有人在这么做了”。

客服代表70.1%——你打过AI客服电话吗？那就是这个数字的注脚。

营销专家64.8%——生成报告、分析数据、写文案，这些都是AI的舒适区。

而在另一端，30%的劳动者AI覆盖率为零。他们是谁？厨师、摩托车修理工、救生员、调酒师、洗碗工。

讽刺吗？当年被认为”没出息”的体力劳动，现在反而成了AI的安全区。

注：这是趋势观察，并非绝对结论，核心是提醒我们要提升不可被 AI 替代的核心能力。

04｜比”被裁”更可怕的事：入口正在关闭

很多人可能会问：既然覆盖率这么高，为什么没看到大规模裁员？

报告也研究了这个问题，结论是：

高AI暴露职业的失业率，目前确实没有显著上升。

但报告同时发现了一个更隐蔽、更可怕的信号——

22-25岁年轻人进入高风险职业的招聘速度，正在明显放缓。

企业没有在裁老员工，但正在减少招新人。

ChatGPT发布后，年轻人进入高暴露职业的就业率下降了约14%。

这意味着什么？

AI不是拿着刀冲进办公室赶人走，而是悄悄把门关小了。

还在里面的人暂时安全，但正准备进去的人——发现门越来越窄。

如果你是正在找工作的应届生，如果你的孩子正在选专业——这个数据比任何裁员新闻都更值得警惕。

05｜最反直觉的发现：AI冲击的是”高学历高薪”群体

报告还做了一个残酷的对比：

看到了吗？

被AI冲击最大的群体，不是蓝领，不是低学历工人，而是——

受过良好教育、薪资较高、以信息处理为核心工作的白领专业人士。

学历越高，越可能从事的是文字处理、数据分析、逻辑推理这类工作——而这恰恰是大语言模型最擅长的事。

这彻底打破了一个延续了几十年的信念：

“好好读书→考好大学→学热门专业→进大公司做白领→人生稳了。”

这条路，正在被AI重新定义。

06｜那我们怎么办？给所有人的五条真诚建议

基于这份报告的数据，我给出以下建议。不贩卖焦虑，只说实话：

🔴 给正在选专业的高中生和家长

不要只看”热门”和”高薪”，要看这个专业的核心技能是否容易被AI标准化。

“纯信息搬运型”专业（基础编程、初级会计、数据录入类）→风险最高

“需要物理在场”的专业（临床医学、护理、工程施工、农学）→暂时安全

“创意+判断+人际”的复合型方向 →最值得押注

一个简单的判断标准：如果一个工作可以完全在电脑前完成、且输入输出都是文字或数据——它被AI替代的优先级就很高。

🔴 给在校大学生

不管你学什么专业，现在就开始学习使用AI工具，把它变成你的”超能力”。

报告有一个关键发现：软件开发人员的AI暴露度高达30%，但BLS预测这个职业未来十年仍将增长16%。

这说明什么？

AI替代的是”任务”，不一定是”岗位”。能驾驭AI的人，反而更值钱。

🔴 给已经在职场的文案/程序员/设计师/营销人

不要恐惧，但要清醒。

你的竞争对手不是AI，而是会用AI的同行。

当你的同事用AI一天写完你一周的方案时，差距就出来了。主动拥抱工具，把效率提上去，把创意和判断力留给自己。

🔴 给影视/艺术从业者

报告显示”艺术与媒体”的实际AI覆盖已经在扩张。AI能写脚本、做分镜、生成概念图、甚至做粗剪。

但AI做不到的是：讲一个打动人心的故事、理解人类的情感共鸣、做出有灵魂的审美判断。

技术壁垒在消失，审美壁垒在升高。把时间花在提升品味和叙事能力上，而不是死守软件操作。

🔴 给所有人

这份报告最重要的一句话是：

“AI远未达到其理论能力——实际覆盖率仍仅为可行范围的一小部分。”

我们还有时间。但窗口正在收窄。

AI的影响不是海啸，而是涨潮。不会一下把你淹没，但如果你一直站在原地——等你发现水到脚踝的时候，退路已经不多了。

docker、openai、claudeai等国外的站点对国内IP有限制，所以在使用vpn等要注意一些点

原因：

当使用docker指令启动项目，报错

1

Error response from daemon: Get "https://registry-1.docker.io/v2/": EOF(base) wx@wxs-MacBook-Pro docker

是因为：registry-1.docker.io被墙

解决方法：

1）切记VPN要设置“全局代理”

在使用docker desktop、或者直接调用claude/chatgpt的open api时候，也需要设置“全局代理”

例如我用的VPN是XXXXXVpn，是设置“安全模式”

可以在一个网站查看是否生效：https://whatismyipaddress.com

如图，我的已经生效。如果一直不生效，请在无痕模式下打开浏览器

2）添加国内代理站点：

请将下面的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
  "builder": {
    "gc": {
      "defaultKeepStorage": "20GB",
      "enabled": true
    }
  },
  "debug": true,
  "dns": [
    "8.8.8.8",
    "114.114.114.114"
  ],
  "experimental": true,
  "proxies": {
    "http-proxy": "http://127.0.0.1:7890",
    "https-proxy": "http://127.0.0.1:7890",
    "no-proxy": "localhost,127.0.0.0/8"
  },
  "registry-mirrors": [
    "https://hub.rat.dev"
  ]
}

拷贝到 Docker Desktop的 设置按钮–> Docker Engine 文本框

对应文件的磁盘存储路径为：~/.docker/daemon.json

​

​ 我们从一个例子开始吧：一个订单服务 OrderService，IP为192.168.0.110 连接了商品服务 ProductService, ip 为192.168.0.111 ，其中订单服务中的方法比较多，并且很多请求也刚好路由到192.168.0.111的 ProductService 服务。那问题就来了：110机器作为客户端是怎么控制连接数的？会不会无限量地和111机器进行TCP连接？

​ 我们先看一下Dubbo的官方文档对“连接控制”的说明文档 ： http://dubbo.apache.org/zh-cn/docs/user/demos/config-connections.html 。

​ 在xml配置方式中xml accepts="10" 和 connections="10" 分别在服务端和客户端进行了相应的连接控制。下面我们看一下源码，追一下连接控制的原理。

​ 我们看一下DubboProtocol.java的创建客户端tcp连接的方法，int connectNum正是每个客户端对服务端的tcp连接数，默认是1,当然可以修改成更大。默认是1，这样一个客户端的调用service数最多也不会超过1000吧。这样就不会出现单机创建TCP连接数过多的问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

/**
 * Bulk build client
 *
 * @param url
 * @param connectNum
 * @return
 */
private List<ReferenceCountExchangeClient> buildReferenceCountExchangeClientList(URL url, int connectNum) {
    List<ReferenceCountExchangeClient> clients = new ArrayList<>();

    for (int i = 0; i < connectNum; i++) {
        clients.add(buildReferenceCountExchangeClient(url));
    }
    return clients;
}

客户端和服务端是一对一的，建立长连接，那么如果客户端并发访问，他们是怎么和服务端交互的呢？
经过看代码：

下面咱们试图从代码中找到痕迹。一路追踪，我们来到这个类：com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeChannel.java，先来看看其中的request方法，大概在第101行左右：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

  public ResponseFuture request(Object request, int timeout) throws RemotingException {
    if (closed) {
        throw new RemotingException(this.getLocalAddress(), null, "Failed to send request " + request + ", cause: The channel " + this + " is closed!");
    }
    // create request.
    Request req = new Request();
    req.setVersion("2.0.0");
    req.setTwoWay(true);
    req.setData(request);
 
    //这个future就是前面我们提到的：客户端并发请求线程阻塞的对象
    DefaultFuture future = new DefaultFuture(channel, req, timeout);
    try{
        channel.send(req);  //非阻塞调用
    }catch (RemotingException e) {
        future.cancel();
        throw e;
    }
    return future;
}

注意这个方法返回的ResponseFuture对象，当前处理客户端请求的线程在经过一系列调用后，会拿到ResponseFuture对象，最终该线程会阻塞在这个对象的下面这个方法调用上，如下：

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

public Object get(int timeout) throws RemotingException {
    if (timeout <= 0) {
        timeout = Constants.DEFAULT_TIMEOUT;
    }
    if (! isDone()) {
        long start = System.currentTimeMillis();
        lock.lock();
        try {
            while (! isDone()) {    //无限连
                done.await(timeout, TimeUnit.MILLISECONDS);
                if (isDone() || System.currentTimeMillis() - start > timeout) {
                    break;
                }
            }
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        } finally {
            lock.unlock();
        }
        if (! isDone()) {
            throw new TimeoutException(sent > 0, channel, getTimeoutMessage(false));
        }
    }
    return returnFromResponse();
}

上面我已经看到请求线程已经阻塞，那么又是如何被唤醒的呢？再看一下com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.java，其实所有实现了ChannelHandler接口的类都被设计为装饰器模式，所以你可以看到类似这样的代码：

1
2
3
4
5
6

  protected ChannelHandler wrapInternal(ChannelHandler handler, URL url) {
    return new MultiMessageHandler(
            new HeartbeatHandler(
                    ExtensionLoader.getExtensionLoader(Dispather.class).getAdaptiveExtension().dispath(handler, url)
            ));
}

现在来仔细看一下HeaderExchangeHandler类的定义，先看一下它定义的received方法，下面是代码片段：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public void received(Channel channel, Object message) throws RemotingException {
    channel.setAttribute(KEY_READ_TIMESTAMP, System.currentTimeMillis());
    ExchangeChannel exchangeChannel = HeaderExchangeChannel.getOrAddChannel(channel);
    try {
        if (message instanceof Request) {
          .....
        } else if (message instanceof Response) {   
            //这里就是作为消费者的dubbo客户端在接收到响应后，触发通知对应等待线程的起点
            handleResponse(channel, (Response) message);
        } else if (message instanceof String) {
           .....
        } else {
            handler.received(exchangeChannel, message);
        }
    } finally {
        HeaderExchangeChannel.removeChannelIfDisconnected(channel);
    }
}

我们主要看中间的那个条件分支，它是用来处理响应消息的，也就是说当dubbo客户端接收到来自服务端的响应后会执行到这个分支，它简单的调用了handleResponse方法，我们追过去看看：

1
2
3
4
5

static void handleResponse(Channel channel, Response response) throws RemotingException {
    if (response != null && !response.isHeartbeat()) {  //排除心跳类型的响应
        DefaultFuture.received(channel, response);
    }
}

熟悉的身影：DefaultFuture，它是实现了我们上面说的ResponseFuture接口类型，实际上细心的童鞋应该可以看到，上面request方法中其实实例化的就是这个DefaultFutrue对象：

1

DefaultFuture future = new DefaultFuture(channel, req, timeout);

那么我们可以继续来看一下DefaultFuture.received方法的实现细节：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public static void received(Channel channel, Response response) {
    try {
        DefaultFuture future = FUTURES.remove(response.getId());
        if (future != null) {
            future.doReceived(response);
        } else {
            logger.warn("The timeout response finally returned at " 
                        + (new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS").format(new Date())) 
                        + ", response " + response 
                        + (channel == null ? "" : ", channel: " + channel.getLocalAddress() 
                            + " -> " + channel.getRemoteAddress()));
        }
    } finally {
        CHANNELS.remove(response.getId());
    }
}

留一下我们之前提到的id的作用，这里可以看到它已经开始发挥作用了。通过id，DefaultFuture.FUTURES可以拿到具体的那个DefaultFuture对象，它就是上面我们提到的，阻塞请求线程的那个对象。好，找到目标后，调用它的doReceived方法，这就是标准的java多线程编程知识了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

private void doReceived(Response res) {
    lock.lock();
    try {
        response = res;
        if (done != null) {
            done.signal();
        }
    } finally {
        lock.unlock();
    }
    if (callback != null) {
        invokeCallback(callback);
    }
}

这样我们就可以证实上图中左边的绿色箭头所标注的两点。

参考链接：https://blog.csdn.net/joeyon1985/article/details/51046548

在JDK1.7中的HotSpot中，已经把原本放在方法区的字符串常量池移出。

　　从JDK7开始永久代的移除工作，贮存在永久代的一部分数据已经转移到了Java Heap或者是Native Heap。但永久代仍然存在于JDK7，并没有完全的移除：符号引用(Symbols)转移到了native heap;字面量(interned strings)转移到了java heap;类的静态变量(class statics)转移到了java heap。

随着JDK8的到来:

JVM不再有PermGen。但类的元数据信息（metadata）还在，只不过不再是存储在连续的堆空间上，而是移动到叫做“Metaspace”的本地内存（Native memory）中。

一、java7到java8的第一部分变化：元空间

下面来一张图看一下java7到8的内存模型吧（这个是在网上找的图，如有侵权问题请联系我删除。）

二、java7到java8的第二部分变化：运行时常量池

运行时常量池（Runtime Constant Pool）的所处区域一直在不断的变化，在java6时它是方法区的一部分；1.7又把他放到了堆内存中；1.8之后出现了元空间，它又回到了方法区。

Metaspace 结构是怎么样的？

参考：https://blog.csdn.net/weixin_42711325/article/details/86533192

一、基本比较

二、各自优缺点

1、Kafka

大数据行业标配组件

2、RocketMq

​ 有事务性消息、私信队列等支持，适合交易场景

3、Pulsar

​ 新贵，地域复制、多租户、扩展性比较好

4、RabbitMq

​ erlang编写，性能较好。有不少互联网公司用。不过因为erlang，社区开发者较少

5、ActiveMq

项目较老，不够活跃，会丢消息，不适合在互联网项目使用

三、一些问题

1、Kafka的数据丢失问题

一开始就是存储在PageCache上的，定期flush到磁盘上的，也就是说，不是每个消息都被存储在磁盘了，如果出现断电或者机器故障等，PageCache上的数据就丢失了。
这个是总结出的到目前为止没有发生丢失数据的情况

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

//producer用于压缩数据的压缩类型。默认是无压缩。正确的选项值是none、gzip、snappy。压缩最好用于批量处理，批量处理消息越多，压缩性能越好
props.put("compression.type", "gzip");
//增加延迟
props.put("linger.ms", "50");
//这意味着leader需要等待所有备份都成功写入日志，这种策略会保证只要有一个备份存活就不会丢失数据。这是最强的保证。，
props.put("acks", "all");
//无限重试，直到你意识到出现了问题，设置大于0的值将使客户端重新发送任何数据，一旦这些数据发送失败。注意，这些重试与客户端接收到发送错误时的重试没有什么不同。允许重试将潜在的改变数据的顺序，如果这两个消息记录都是发送到同一个partition，则第一个消息失败第二个发送成功，则第二条消息会比第一条消息出现要早。
props.put("retries ", MAX_VALUE);
props.put("reconnect.backoff.ms ", 20000);
props.put("retry.backoff.ms", 20000);

//关闭unclean leader选举，即不允许非ISR中的副本被选举为leader，以避免数据丢失
props.put("unclean.leader.election.enable", false);
//关闭自动提交offset
props.put("enable.auto.commit", false);
限制客户端在单个连接上能够发送的未响应请求的个数。设置此值是1表示kafka broker在响应请求之前client不能再向同一个broker发送请求。注意：设置此参数是为了避免消息乱序
props.put("max.in.flight.requests.per.connection", 1);

2、Kafka重复消费原因

强行kill线程，导致消费后的数据，offset没有提交，partition就断开连接。比如，通常会遇到消费的数据，处理很耗时，导致超过了Kafka的session timeout时间（0.10.x版本默认是30秒），那么就会re-blance重平衡，此时有一定几率offset没提交，会导致重平衡后重复消费。
如果在close之前调用了consumer.unsubscribe()则有可能部分offset没提交，下次重启会重复消费

kafka数据重复 kafka设计的时候是设计了(at-least once)至少一次的逻辑，这样就决定了数据可能是重复的，kafka采用基于时间的SLA(服务水平保证)，消息保存一定时间（通常为7天）后会被删除

1、pr完毕联动直接关闭issue ：

功能： 当committer合并别人提交的pull request的时候，同时联动关闭问题issue
配置： https://help.github.com/cn/articles/closing-issues-using-keywords

2、设置成sqash 合并提交点：

功能： 当committer合并别人提交的选择将提交点进行合并,类似于指令git squash
配置： https://help.github.com/cn/articles/about-merge-methods-on-github

3、更新其他人的分支代码：

功能：在合作开发中，一些分支的提交者好久没有活动了，远程分支已经修改了很多东西。 committer或者pr的提交可以在github界面手动同步主分支的最新代码.
类似于指令

1
2

git remote update -p
git pull origin master

配置方法如下：

效果：

配置： https://help.github.com/cn/articles/enabling-required-status-checks

4、添加测试覆盖率travis-ci 和codecov

功能： 用junit、travis-ci 和codecov等采集项目的测试覆盖率，从而进行持续集成
配置：

• Travis CI + Codecov + Junit5 + jacoco + Maven + java8 above Java Example
  https://github.com/lovepoem/codecov-travis-maven-junit5-example

• Travis CI + Codecov + Junit4 + cobertura + java1.7 + Maven Java Example
  https://github.com/lovepoem/codecov-travis-maven-junit4-example

5、将issue指派给项目的contributor

最早时候github不支持将一个issue指派给对项目没有写权限的用户。在2019年下半年开始，github增加了“Triage”角色：没有项目的直接写权限，却能review pr的人。首先issue可以指派给“Triage”角色；一般用户只要在issue上加评论，就可以将issue指派给她。

​ 订阅的含义是啥？？用图画一下订阅模式。一般情况：订报刊。搞技术的：消息队列，异步。为什么异步的模式是未来商业模式的方向和趋势？重点

​ 将书中各个行业的异步商业模型简要讲解，必要时候画出流程图。

​ 自己切身感受和思考。在软件架构方面，事情本来的样子是什么？异步编程，消息驱动。开源社区的运营和商业化方面：吸引同好，