阅读视图

发现新文章,点击刷新页面。

从IDE到Terminal:适合后端宝宝体质的Claude Code工作流|得物技术

一、背景

事情是这样的,之前对 AI 编程一直是观望态度,但是部门最近在做 AI 辅助编程 POC,有幸成为 POC 用户,用上了自己舍不得买的高级编程模型 (感谢公司)。尽管我自认为是一个在代码上很挑剔的人,但是试了下感觉居然还可以 (Go、React)!只能说还得是谷歌,调整重心略微发力,Gemini 3 表现确实很不错。既然尝到甜头了,觉得自己是时候好好地琢磨琢磨,研究研究,沉淀一套自己的工作流、方法论,解放自己的生产力,顺应潮流努力成为 AI 时代的受益者,而不是被淘汰的人!

新的开发范式需要搭建新的开发环境和匹配自己开发习惯的工作流,这就像刚学编程那会,需要挑一个自己喜欢的 IDE、熟悉 IDE 快捷键和优化 IDE 设置一样。过程中间肯定有阵痛,Java 开发者们回忆一下多年之前从 Eclipse 转 IDEA 那会的阵痛吧,但是磨刀不误砍柴工,阵痛之后一定是生产力提升。借本文分享下我摸索后的方案,供大家参考。

二、工具选型

目前 AI 辅助编程领域热火朝天,各种 GUI 工具、TUI 工具如雨后春笋让人目不暇接,这对于花心的强迫症选手(比如我)来说选型很困难。但是我觉得有两个基础认知可以帮助我们更好地做决定:

(一)AI 辅助编程工具由脑和手两部分组成。脑是外接的大模型 API,手是各个产品调教的提示词和内部工作流。按我理解,【脑】决定了工具的上限,【手】决定了工具的下限。在这个场景里,大模型就像是汽车里的发动机,而且所有型号的汽车支持的【发动机】规格都是通用的、统一的、标准化的。有了这个基础,我们可以随便选一个趁手的工具,然后自行按场景选配【合适】的【发动机】。

(二)AI 辅助编程当前是一个【千帆竞发】的热门领域,而且单纯就【工具】来说,这个领域【没有技术壁垒】。A 产品抛出的杀手级特性,不出半个月一定会有 B 产品跟进。毕竟现在软件迭代的速度借助 AI 提升了很多,A 产品验证过的想法,B 产品可以很快地跟进和实现。Claude Code CLI 的开发者就使用 Claude Code CLI 迭代 Claude Code CLI,有点绕口,大概就是【工具自举】的意思吧。

Claude Code CLI

综上,其实没啥纠结的,我们照着这两点来选型就好:1. 这个工具一定得便捷地支持模型插拔,就是我随时可以根据场景换一个更适合的、更便宜的、表现更好的大模型。而且这种插拔一定要简单。 2. 这个工具一定要有积极的维护者,不断地迭代、优化它的工作流、提示词。最好是一个商业化产品,因为商业化产品出于其商业目标,一定会投入资源积极进行迭代。 

当前满足这两个条件的,我想也就是 Claude Code CLI 了: 1. Claude Code CLI 是一个商业化产品,有专门的技术团队在不停地更新、迭代。 2. Claude Code CLI 可以非常便捷地支持大模型插拔,我可以随时根据成本、效率、体验来切换合适的大模型。因此,这个环节我选 【Claude Code CLI】。

后文以CC代指Claude Code CLI。

快速切换模型

我通过自定义 Shell 函数来实现便捷的模型切换,不同的场景、不同的任务使用不同的模型。基本原理就是,CC 支持环境变量注入 LLM 配置信息,因此我只需要按场景注入【行内临时环境变量】即可。

详见:Bash - 行内环境变量,Bash 是标准的 Shell 实现,其他 Shell 如 Zsh 都兼容其行为。

Shell配置

我到处弄了一堆免费的、收费的模型用,然后给他们取了我记得住的别名:

使用效果

为了兼容,设置了一个 claude 别名:

这样输入claude 时,默认使用智谱 GLM 模型。

脚本源码

Shell 脚本大概这样,可以修改后配置到自己的 ~/.zshrc 中。如果不熟悉 Shell,嫌麻烦也可以试试这个开源工具:farion1231/cc-switch。

# claude 默认
alias claude='zcc'
# Kimi
function kcc(){
    echo Kimi Claude Code...
    local model="kimi-k2.5"
    ANTHROPIC_BASE_URL="https://api.moonshot.cn/anthropic" \
    ANTHROPIC_AUTH_TOKEN="sk-xxxxxxxxx" \
    ANTHROPIC_SMALL_FAST_MODEL="$model" \
    ANTHROPIC_DEFAULT_OPUS_MODEL="$model" \
    ANTHROPIC_DEFAULT_SONNET_MODEL="$model" \
    ANTHROPIC_DEFAULT_HAIKU_MODEL="$model" \
    CLAUDE_CODE_SUBAGENT_MODEL="$model" \
    launch_claude_code $@
}
# 智谱GLM
function zcc(){
    echo GLM Claude Code...
    ANTHROPIC_BASE_URL="https://open.bigmodel.cn/api/anthropic" \
    ANTHROPIC_AUTH_TOKEN="sk-xxxxxxxxx" \
    launch_claude_code $@
}
# 七牛
function qcc(){
    echo QiNiu Claude Code...
    local model="minimax/minimax-m2.1"
    ANTHROPIC_BASE_URL="https://api.qnaigc.com" \
    ANTHROPIC_AUTH_TOKEN="sk-xxxxxxxxx" \
    ANTHROPIC_SMALL_FAST_MODEL="$model" \
    ANTHROPIC_DEFAULT_OPUS_MODEL="$model" \
    ANTHROPIC_DEFAULT_SONNET_MODEL="$model" \
    ANTHROPIC_DEFAULT_HAIKU_MODEL="$model" \
    CLAUDE_CODE_SUBAGENT_MODEL="$model" \
    launch_claude_code $@
}
function launch_claude_code(){
    CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 \
#    clear
    command claude $@
}

三、开发环境

在当前的气氛下,我想我算是一个【古板】的开发者,我做不到【fire and forget】,或者说完全靠黑盒的自然语言对话来完成代码开发。

我还是只将 AI 当助手,还是想要白盒的掌控 AI 写的代码,还是希望最终交付的代码有我的风格、我的审美、我的品味。毕竟 AI 也只能帮我写代码,并不能帮我背锅。尽管我选择了 TUI 工具 Claude Code CLI,但是我还做不到全程只在终端操作,我还是习惯 JetBrains 特色的双栏 diff。

因此,当前我开发流程的起点还是传统的 IDE,比如我最喜欢的 JetBrains。每天上班第一件事是接水,第二件事就是打开 IDE。所以我需要想办法来将 GUI 工具和 TUI 工具流畅的衔接起来,减少代码开发时的频繁切换产生的割裂感!

多屏协作

如上图,我有 3 个显示器,我的构想是这样的:

  1. MacBook 内置显示器 —— 常驻两个空间:一个用来打开浏览器,还有 VPN、网易云音乐、Finder 软件,用来承接各种临时的操作。一个用来打开飞书,用来沟通、协作。

  1. 中间主屏 —— 常驻两个空间:一个用来打开浏览器,用来做各种【输出】。一个用来打开 IDE,专注于写代码、看代码,用标签页打开多个 Project。

  1. 左边竖屏 —— 常驻两个空间:一个用来打开浏览器,用于看文档、查资料等各种【输入】。一个用来打开 TUI 工具,进行辅助编程!

GUI/TUI衔接

现在问题来了,我希望我的开发工作的【主轴】是 IDE,流程的起点是 IDE。但是我的 IDE 在中间屏幕,终端在左边屏幕,它俩是独立软件,没法协作、自动跟随切换 Project 的工作目录。我希望有个【自动化流程】,当我在 IDE 里切换项目的时候,CC 自动跟随切换!

衔接流程

我期待的流程是这样的:

因为某个原因,我在 IDE 里打开了一个项目 A  准备写代码了,点击 IDE 里的某个【按钮】,左边屏幕自动【新建】一个项目 A 的 CC 会话终端并激活到前台显示   我跟左边的 CC 对话,让他干活  我在中间的 IDE 里评审、调试、诊断  因为某些原因我又要在 IDE 打开一个别的项目 B  我再次点击那个【按钮】,左边屏幕自动【新建】一个项目 B 的 CC 会话终端并激活到前台显示  我在 IDE 里又切回了项目 A,我又点击了那个【按钮】,左边屏幕自动【切换】到 A 的 CC 会话终端并激活到前台显示。

好的想法已经有了,AI 时代就怕你没有想法,有想法就一定有办法实现!

代码实现

  1. macOS 上的原生软件,大部分支持 AppleScript 自动化,也就是说我们可以写脚本驱动软件的行为、模拟人机交互,比如打开软件、新建 tab、点击按钮等。

  2. JetBrains IDE 支持集成外部命令,也就是说:可以在 IDE 里点击一个按钮,自动执行一个 Shell 脚本或者别的可执行文件。

产品需求清晰了,接下来开始让 AI 干活!一顿沟通和调试之后,我们有了一个【自动化】创建 iTerm2 新标签的可执行脚本!

这是给大模型的需求提示词,大家可以按需选用,做个性化的调整:

## 📌 工具功能说明
请帮我创建一个 macOS 上的 iTerm2 自动化工具,主要功能包括:
### 核心需求
1. **智能窗口管理**:自动使用或创建 iTerm2 窗口
2. **项目标签管理**:为每个项目目录维护独立的标签页,支持标签复用
3. **三面板布局**:自动创建固定的三面板布局(上方一个全宽面板,下方两个并排面板)
4. **命令自动执行**:在每个面板中自动切换到项目目录并执行预定义的命令
### 使用场景
```bash
# 基本用法:在当前目录打开
./open-claude-in-iterm.sh
# 指定项目目录
./open-claude-in-iterm.sh /path/to/project
```
---
## 🎯 技术架构要求
### 技术栈
- **Shell 脚本** (open-claude-in-iterm.sh):参数处理、路径规范化、日志管理
- **AppleScript** (open-claude-in-iterm.applescript):iTerm2 自动化核心逻辑
**依赖**:macOS、iTerm2、Bash
---
## 📋 详细功能规格
### 1. Shell 脚本 (open-claude-in-iterm.sh)
#### 参数处理
- **参数1**:项目目录(可选,默认当前目录)
- **自动处理**:相对路径转绝对路径
#### 面板命令配置
```bash
PAN1_CMD="claude"     # 上方面板命令
PAN2_CMD="claude"     # 左下面板命令
PAN3_CMD="claude"     # 右下面板命令
```
### 2. AppleScript (open-claude-in-iterm.applescript)
#### 主要流程
**步骤1:窗口管理**
- 检查 iTerm2 是否运行(未运行则自动启动)
- 使用当前激活的 iTerm2 窗口,如果没有则创建新窗口
**步骤2:标签管理(关键逻辑)**
- 在找到的窗口中,查找 `session.path` 变量等于项目目录的标签
- **复用逻辑**:如果找到现有标签 且 窗口不是新创建的 → 直接切换标签并返回
- **创建逻辑**:如果未找到标签 或 窗口是新创建的 → 创建新标签和布局
**步骤3:三面板布局创建**
```
布局示意图:
┌─────────────────────────┐
│   上方面板 (全宽)         │
│   执行: PAN1_CMD         │
├──────────────┬──────────┤
│  左下面板    │  右下面板 │
│  PAN2_CMD   │  PAN3_CMD │
└──────────────┴──────────┘
```
**分割顺序(重要)**:
1. 初始状态:一个全屏 session(上方面板)
2. 第一次分割:对上方 session 执行**水平分割**,创建下方面板
3. 第二次分割:对下方 session 执行**垂直分割**,创建右下面板
**步骤4:命令执行**
在每个面板中依次执行:
1. 切换到项目目录:`cd "/path/to/project"`
2. 清屏:`clear`
3. 等待 0.3 秒(确保目录切换完成)
4. 执行命令:`PAN_CMD`
5. 等待 0.5 秒(确保命令启动)
## ⚠️ 常见错误
- ❌ 符号链接未处理,导致找不到 AppleScript 文件
- ❌ 分割顺序错误,导致布局不正确
- ❌ 缺少 delay,导致命令执行失败或在错误目录执行
- ❌ 新窗口处理错误,导致多余空白标签
- ❌ 标签复用逻辑错误,导致同一项目创建多个标签
- ❌ 路径未引用,导致包含空格的路径失败

IDE配置

创建外部工具

添加到工具栏

使用效果

点击工具栏按钮后,自动在全屏的 iTerm2 窗口新建或激活项目目录下的 CC 会话,下图里就是 3 个项目。

四、多Agent协作

会的越多,让你干的就越多。既然 AI 那么牛,一个 CC 会话已经满足不了我膨胀的想法和需求了。我希望我可以同时支配多个 AI 开发工程师,而我变成 PM!所以参考酒米的思路,我给每个项目的终端,自动化的划分了 3 个子窗口,每个子窗口都是一个 CC 会话。效果大概这样:

主从架构

每个项目自动打开 3 个常驻的 AI 会话,我设想的工作流是这样的:

【架构师】上面的大屏,用贵的模型!专门用来跟我聊需求、对方案、产出任务列表。

【开发者】下面的两个小屏,用领域特定的模型,专门用来落地大屏架构师产出的方案和任务。比如前端需求用前端效果好的模型,后端需求用后端效果好的模型。

知人善用才是好 PM!这个模式也很匹配现实中的组织架构和成本取舍,现实中每个需求一般也都是由一个架构师和多个中高级开发者来协作完成!感谢热心市民无声雨,给我们小组共享了自己采购的纯血 Claude 模型,所以目前我用 Claude 模型来对方案,用 GLM 或者 MiniMax 来实施方案!

规范驱动开发(SDD)

主从智能体的协作很重要,我跟【架构师】聊了半天确定的方案和设计,需要有一个清晰的、对大模型友好的方案和任务文档作为【开发者】的输入。这就很巧,刚好最近在流行 SDD,规范驱动开发。大致就是模拟现实中的软件开发流程将开发生命周期拆分为 3 个阶段:

  • 【proposal】需求对齐、方案设计、【任务细化】;
  • 【apply】开发任务实施;
  • 【archive】功能验收、文档沉淀

围绕这个流程,开源社区设计和研发了一系列对大模型非常友好的工具和提示词(比如 OpenSpec),【阶段 1】和【阶段 2】中间通过格式设计良好的【设计文档和任务文档】来进行上下文交接。

也就是说,我可以在上述的 3 窗口环境中,按照 SDD 流程来:【proposal】跟【架构师】交互,对齐需求、设计和任务 A  【apply】让【开发者 1】着手完成任务 A  【proposal】继续跟【架构师】交互,对齐需求、设计和任务 B  【apply】让【开发者 2】着手完成任务 B  【proposal】继续跟【架构师】交互,对齐需求、设计和任务 C  【apply】让【开发者 1】着手完成任务 C  ……

五、CC拓展

CC 当然很厉害,但它本质上也就是一个朴素的 ReAct 模式智能体。

ReAct 这么火,大家肯定也都耳熟能详了,我们也就不说太多。当然 CC 团队围绕编程这个课题做了很多细致的提示词调优和内置工作流设计,这个我们黑盒的用就好了,也没必要关注太多。我们最需要关注的,是 CC 提供给我们使用者的【拓展点】,那些允许我们个性化设置的东西。

命令(command)

命令的本质就是预定义的提示词模板。目的是为了省事,不用每次都重复的输入类似的提示词。比如想让 CC 帮我提交代码,每次我们可能都要交代一大堆字,比如:

请调用 git diff --cached 获取当前暂存区的代码变动。
忽略所有的 node_modules 或二进制文件。
基于变动内容,判断这是一个 feat (新功能), fix (修复) 还是 chore (杂务)。
生成一个不超过 50 字符的标题,并在正文详细列出影响的文件。
由我确认后执行 git commit。”

就像写代码的时候将重复代码提取为一个独立方法一样,我们可以把这些可以复用的提示词固定成一个【命令】,后续使用的时候,直接输入命令名字就好。斜杠命令是一段提示词的快捷方式。

技能(skill)

技能和命令最大的差别就是:命令是用户主动提交的提示词,而技能是 Agent 自己决策后自动导入的提示词。当然技能包里除了提示词,一般还会携带一些配套的工具、脚本、命令或者文档。

比如,我安装了一个【html 转 pdf 的技能包】,这只能提示 CC 可以使用这个技能,但是具体用不用、什么时候用、怎么用都是 CC 自己规划、决策的。

子代理(subAgent)

SubAgents 是可以并行处理任务的独立 AI 代理,每个子代理拥有独立的上下文窗口,可以分配不同任务以提高效率。【主代理】的上下文窗口中包含有【子代理】的【简短】描述信息,可以基于这个描述信息规划、决策使用哪个子代理。

{
  "agents":{
    "code-reviewer":{
      "description":"专门负责代码审查的子代理",
      "model":"claude-opus-4-5",
      "instructions":"你是一个专业的代码审查专家,专注于检查代码质量、安全漏洞和性能问题。",
      "tools":["read","search","git"],
      "permissions":{
        "allowWrite":false
      }
    },
    "test-writer":{
      "description":"专门负责编写测试的子代理",
      "model":"claude-sonnet-4-5",
      "instructions":"你是一个测试工程师,专注于编写全面的单元测试和集成测试。",
      "tools":["read","write","bash"]
    },
    "doc-generator":{
      "description":"专门负责生成文档的子代理",
      "model":"claude-sonnet-4-5",
      "instructions":"你是一个技术文档专家,专注于生成清晰、准确的技术文档。",
      "tools":["read","write"]
    }
  }
}

独立上下文窗口的好处是:避免上下文污染和占用。比如我要在代码里找一个接口的所有实现类,这个就很适合子代理来做。主代理只需要交代给子代理接口名,然后就等子代理返回实现类列表。

这样在主代理的上下文窗口里,只会有子代理的输入和输出(几个类文件路径),而子代理在搜索过程中遍历文件、目录、读取文件内容产生的临时 token,不会对主代理产生影响。我目前认为 SubAgent 和 Skill 差不太多。不过我不确认 Skill 是不是在独立的上下文中执行。

MCP

MCP 和技能一样,都是由 CC 自主规划、决策使用的。差别有两个:

  1. MCP 工具的说明信息占用的上下文太多了!不管是否被使用,每次都需要一口气提交所有工具的完整元信息(使用说明 + 出入参 Schema)供大模型规划、决策,占用大量上下文。而【技能】选择了【渐进式披露】,先向大模型提供少量关键信息,只有在大模型选择了使用技能时,才告诉大模型更多关于技能的补充说明信息,让大模型进一步推理、决策。

  2. MCP 工具更多的偏向【远程 RPC】,基于网络来实现原子化的远程能力调用。而【技能】更多的偏向【本地 IPC】,具体能力更多通过【编排】本地脚本、本地命令来实现,有点像 stdio 模式下的 MCP。

钩子(hook)

hook 是在特定事件触发时自动执行的脚本,用于自定义工作流、拦截危险操作、自动格式化代码等。就类似 Linux NetFilter,CC 在很多地方植入了流程执行的劫持点,将流程上下文交给用户开发的脚本或者命令。

插件(plugin)

plugin 就是上述各种拓展打包、分发、安装的一种格式。你可以把它想象成 npm 包、pip 包、apk 包等我们比较熟悉的概念。然后我们可以按流程和格式建设插件市场,类似 pip-index、npm-index 等。

我没有细看流程和格式,但是大概也就是一个特定文件布局的 zip 文件包,里面有插件描述信息和各类拓展,比如可以包含:

  • 5 个 Skills;
  • 10 个斜杠命令;
  • 3 个 MCP 服务器配置;
  • 2 个 SubAgent 定义;
  • 若干 Hooks。

六、CC技巧

飞书MCP

飞书官方提供了 MCP,我主要用它来读写飞书文档,蛮好用的,大家可以试试。比如我每周都要在固定目录下创建固定标题格式的【系统巡检文档】,所以我借助飞书 MCP 整了个自定义 Command 帮我自动创建这些文档去除重复劳动,感觉真香!之前每次都要手动建 3 个文档、选目录、改名字!

@模糊搜索

有时候我们需要精确的告诉 CC,哪个文件需要读或者改,其实不用从 IDE 里复制文件路径,直接在终端里模糊搜索就好了。

WebFetch

CC 默认集成了 WebFetch 命令,就是指定 URL 读取网页内容,这个理论上就是一个本地执行的 curl 命令,没有云端成本,不需要云端协作。但是有个问题:(一)CC 在访问地址之前,会先调用 anthropic.com 的一个风控接口,判断这个网络地址是否有安全风险。(二)政策原因,anthropic.com 会拒绝所有来自中国大陆、香港的请求,风控接口返回 404 或者其他。(三)风控不通过,WebFetch 失败。

在 ~/.claude/settings.json 中添加如下配置,禁用 WebFetch 工具前置的风控检查就好了。

{
  "skipWebFetchPreflight":true,
}

详见:linux.do/t/topic/114…

WebSearch

WebSearch 是需要云端协作的,需要有个搜索引擎服务提供能力。因为我们没有用官方的付费订阅,所以默认的 WebSearch 工具我们用不了,调用 WebSearch 工具得到的结果都是 0。

办法是去找一个免费或者收费的 MCP 服务。免费的我看大家都推荐 Brave<brave.com>,大家也可以找找别的。收费的也有很多,我看智谱的套餐里限量提供了 <联网搜索 MCP - 智谱 AI 开放文档>。也有很多按量付费的,大概几分钱一次,有需要的可以找找。

添加了 MCP 搜索工具后,建议禁用 CC 自带的 WebSearch 工具,不然每次跟大模型交互时,工具信息还会带给大模型,产生额外的 token 开销和推理误判。在 ~/.claude/settings.json 中添加如下配置:

{
  "permissions":{
    "deny":[
      "WebSearch"
    ]
  }
}

iTerm2通知

终端上的任务需要我们输入的时候,可以配置下,让 iTerm2 发出声音和通知。这样我们就不会因为忘记确认操作而阻塞进度。

详见:Optimize your terminal setup - Claude Code Docs

清空上下文

因为我们每个项目都复用一屏内的 3 个子窗口,一般不会重开。为了避免上下文溢出或者之前对话对新任务产生干扰,当我们完成一个任务时,需要及时的执行 /clear 命令,清空上下文,从 0 开始新对话。

如果任务没有完成,但是又不得不 clear,那么可以维护一个自定义命令,在 clear 后提示大模型根据 git status 看到的文件变更快速找回上下文。把 git 状态当作 AI 的 “短期记忆快照”,/clear 只清上下文,不清工作进度。

# Context Catch-up
当前对话已被 `/clear`,请通过 git 状态恢复上下文。
使用方式:
1. 阅读 `git status`(必要时结合 `git diff`2. 仅基于文件变更推断正在进行的任务
3. 延续现有实现思路,不要假设额外背景
4. 在未收到明确指令前,先给出你对当前上下文的判断
目标:
- 快速找回任务状态
- 避免旧对话或错误假设干扰新任务

注意力哨兵

在记忆文件里要求大模型扮演一个特别的角色,如果聊着聊着角色行为丢失了,说明大模型注意力失焦了,已经丢掉了你最开始的要求。这时候就该 clear 一下重开会话了。

拓展市场

为了便于相关个性化拓展物料的分发、便于大家搜索、安装,市面上已经有了相关的分发平台和便捷安装命令了。

  1. skills.sh

  1. www.aitmpl.com

状态行个性化

状态行显示在 Claude Code 会话界面底部,可以自定义显示的内容,比如git分支名、目录名、模型名等。推荐使github开源项目:claude-code-statusline-pro-aicodeditor,效果如下:

详见:github.com/HorizonWing…

七、总结

差生文具多,尽管我暂时还没有使用 CC 产出啥说得上来的东西,但是确实花了很多时间琢磨怎么让它用起来更顺手。一些不成熟的想法,希望可以给到大家启发。

参考:

  1. www.ginonotes.com/posts/how-i…
  2. www.cnblogs.com/knqiufan/p/…

往期回顾

1.AI编程能力边界探索:基于 Claude Code 的 Spec Coding 项目实战|得物技术

2.搜索 C++ 引擎回归能力建设:从自测到工程化准出|得物技术 

3.得物社区搜推公式融合调参框架-加乘树3.0实战

4.深入剖析Spark UI界面:参数与界面详解|得物技术

5.Sentinel Java客户端限流原理解析|得物技术

文 /羊羽

关注得物技术,每周更新技术干货

要是觉得文章对你有帮助的话,欢迎评论转发点赞~

未经得物技术许可严禁转载,否则依法追究法律责任。

比阿里开源的 page-agent 更强?AutoPilot: 网页内置一个真正能"稳定跑完"的智能体

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

你在公司内部系统里打开一个工单填写页,想着:"要是能直接跟它说一句话,让 AI 帮我把表单填完、提交,再确认一下结果就好了。"

或者,你负责一个 ERP 系统,每天有大量重复操作——找到入口、填数据、点提交、看结果——用户叫苦不迭,你也知道这事该自动化,但一直没有好的切入点。

又或者,你看到 AI Agent 这几年火起来,想给自家产品加一个"AI 助手",但发现市面上的方案要么太重(整套后端 RPA),要么太弱(只能回答问题,不能真的操作页面)。

这篇文章要讲的,就是一个让你的网页直接内置智能体的方案——AutoPilot


先聊聊阿里的 page-agent

去年阿里开源了 page-agent,方向很对:让 AI 直接操作浏览器页面,完成复杂的交互任务。

它的定位和 AutoPilot 很像——同样是纯浏览器端运行、无需后端、BYOK(自带 API Key)架构,同样支持 OpenAI 兼容接口,同样内置 UI 面板,用一个 <script> 或 npm 包就能接入。

值得肯定的地方:

  • 纯客户端设计,Agent 与用户同活在页面内部,无需服务端支持
  • 内置 ask_user 工具,支持人机协同(HITL)随时介入干预
  • 提供 Chrome 扩展,可跨标签页执行复杂工作流
  • 阿里背书,社区活跃

但在执行稳定性长任务可靠性上,它还有明显的短板:

维度 page-agent AutoPilot
长任务拆解 顺序执行,每步依赖上一步结果,长链路易跑偏 REMAINING 协议增量消费,每轮基于最新快照决策
执行稳定性保障 每次 LLM 调用前重新提取 DOM 14 层收敛保护机制
任务完成验证 无独立验证,依赖 AI 自判 AI 驱动的三阶段独立断言
空转/死循环 依赖 maxRounds 兜底 多维空转检测,提前识别并停机
停机可观测性 无结构化停机原因 stopReason 枚举,每次停机原因清晰可查

其他方面,比如 Chrome 扩展跨标签页控制、HITL 人机协同等,page-agent 各有其优势,两者各有侧重。

核心差距就一句话:page-agent 能跑起来,AutoPilot 能稳定跑完。


AutoPilot 是什么

AutoPilot 是一个浏览器端原生 AI Agent SDK,让你的网页直接内置一个可以真正操作 UI 的智能体。

它不需要后端,不需要 Playwright,不需要 Puppeteer——直接运行在你的前端项目里,作为一个 npm 包引入,配上 API Key,告诉它一句话,它就开始干活。

npm install agentpage
import { WebAgent } from "agentpage";

const agent = new WebAgent({
  token: "your-api-key",
  provider: "openai",   // 也支持 deepseek / qwen / doubao / claude 等
  model: "gpt-4o",
});

agent.registerTools(); // 注册内置 Web 操作工具

const result = await agent.chat("打开新建工单弹窗,填写标题为「紧急Bug」,优先级选高,然后提交");
console.log(result.reply);      // AI 的最终回复
console.log(result.stopReason); // "assertion_passed" / "converged" / ...

这段代码会让 AI 真正地在你的页面上找到按钮、点击、填写表单、提交——而不是生成一段操作步骤让你自己去执行。


技术深度:为什么能"稳定跑完"

这是本文的核心。大多数 Agent 方案面临的最大问题不是"能不能执行",而是"执行过程中崩不崩、转不转圈、最后有没有真正完成"。

AutoPilot 针对这个问题做了系统性设计,下面讲最关键的四个机制。


机制一:REMAINING 协议 — 增量任务消费

问题背景: 给 AI 一个长任务("填三个字段,提交,然后跳转到详情页验证结果"),AI 很可能在第一轮就试图把所有事情一次性规划完,但页面状态是动态变化的,第一轮的规划到第二轮就失效了。

AutoPilot 的解法: REMAINING 协议。

AI 每轮返回时,除了工具调用,还必须在回复末尾写一行:

## REMAINING: <还没做的任务>

或者任务全部完成时写:

## REMAINING: DONE

这样,Agent Loop 每轮只根据当前快照来执行当前能执行的动作,然后把"剩余任务"传给下一轮,而不是靠 AI 记忆来维持状态。

实际执行流示意:

总任务: "填写姓名和手机号 → 点提交 → 确认成功提示"

Round 1: 快照显示表单可见
  → AI 执行: fill(姓名输入框, "张三")
  → AI 执行: fill(手机号输入框, "138xxxx")
  → REMAINING: 点提交 → 确认成功提示

Round 2: 快照显示表单已填,提交按钮可点击
  → AI 执行: click(提交按钮)
  → REMAINING: 确认成功提示

Round 3: 快照显示成功弹窗
  → AI 调用: assert({})
  → 断言通过 → stopReason: "assertion_passed"

每轮的决策基于最新 DOM 快照,不靠记忆,不靠猜测,快照驱动


机制二:14 层收敛保护 — 稳定而非偶然成功

"能偶尔成功"和"能稳定成功"之间,差了一套系统性的保护机制。AutoPilot 内置了 14 层,分为几大类:

① 元素定位失败的恢复

元素 #abc123 未找到
  → 等待 100ms
  → 刷新快照(此时可能 DOM 已更新)
  → 重试定位,最多 2 轮

② 空转与死循环检测

// 连续多轮"只读不写"(只调 snapshot、get_text 等,没有 click/fill)
// → 触发空转检测 → stopReason: "idle_loop"

// 连续 3 轮提交了完全相同的工具调用批次
// → 触发防自转 → stopReason: "repeated_batch"

// 近 4 轮内反复在 ≤2 个元素上循环点击
// → 将这些元素加入拦截集,同时推荐周边可点击元素

③ 快照指纹变化检测

每轮执行后,AutoPilot 计算快照指纹。如果动作执行了但快照没有变化(说明点击无效),下一轮会注入强提示,强制 AI 换目标,而不是继续重复同一个无效操作。

④ 协议修复

如果 AI 的回复里忘写 REMAINING 协议(大模型偶尔会忘),Agent Loop 不会直接崩,而是注入修复提示,要求 AI 补全协议,给它一次改正机会。

⑤ 稳定等待

每轮有 DOM 变化后,自动等待:

  • 检测 loading 状态消失(.ant-spin.el-loading-mask.bk-loading[aria-busy="true"] 等主流组件库均已内置)
  • DOM 进入静默窗口(200ms 内无变化)
  • 总超时兜底 4000ms

所有保护机制都有对应的 stopReason,执行结果完全可观测:

type StopReason =
  | "converged"          // 正常完成(REMAINING: DONE)
  | "assertion_passed"   // 断言全部通过
  | "assertion_loop"     // 断言失败后陷入死循环
  | "repeated_batch"     // 连续相同工具调用
  | "idle_loop"          // 空转检测触发
  | "no_protocol"        // 多轮无 REMAINING 协议
  | "stale_remaining"    // 任务多轮不推进
  | "max_rounds"         // 达到最大轮次上限
  | "dry_run";           // 干运行模式

机制三:AI 驱动的三阶段断言 — 任务是否真的完成了

问题背景: AI 执行完操作,认为自己完成了,但页面上可能出现了报错弹窗、表单校验失败、或者根本没有跳转成功。

AutoPilot 的断言不是简单的"是否有某个元素",而是让一个独立的 AI 实例(不继承 system prompt、不带 tools)去判断任务是否真正完成。

三阶段快照设计:

快照 拍取时机 用途
Initial 任务开始前 基线:判断页面是否发生了预期变化
Post-Action 工具执行完、页面稳定前 捕获瞬态:成功提示、确认弹窗(这些可能几秒后消失)
Current 稳定后 最终状态:确认结果是否持久存在

断言 AI 拿到这三个快照,再加上已执行的操作记录,独立判断:任务描述所要求的结果,是否在页面上得到了体现?

自定义断言示例:

const result = await agent.chat("关闭开关,满意度评五星,标签选灰度", {
  assertionConfig: {
    taskAssertions: [
      {
        task: "关闭开关",
        description: "开关组件不应有 is-checked class",
      },
      {
        task: "满意度评五星",
        description: "满意度 slider 的 5 个 star 均应有 is-active class",
      },
      {
        task: "标签选灰度",
        description: "灰度 checkbox 应处于 checked 状态",
      },
    ],
  },
});

不传 assertionConfig 时,默认以用户原始消息作为整体断言依据,零配置开箱即用。

断言失败不会直接停机,而是把失败信息注入上下文,让 Agent 继续重试,直到全部通过(或触发断言死循环保护)。


机制四:RefStore + 快照 — 确定性元素定位

问题背景: 基于 CSS 选择器或 XPath 的定位方式,在动态渲染的现代前端框架中极易失效——组件库升级、动态 class 生成、条件渲染都会让选择器失效。

AutoPilot 的做法是:快照时给每个可交互节点分配一个临时的 #hashID,存入 RefStore(一个 WeakRef 映射表)。AI 的工具调用使用 #hashID 指定目标,执行时从 RefStore 里取真实 DOM 元素。

快照片段(AI 看到的):
  <button #a3f2 role="button">提交</button>
  <input #b91c type="text" placeholder="请输入标题" />

AI 工具调用:
  click({ ref: "#a3f2" })
  fill({ ref: "#b91c", value: "紧急Bug" })

执行时:
  RefStore.get("#a3f2") → 真实 DOM 元素 → 执行点击

#hashID 每轮快照后刷新,不跨轮复用,确保每个 ID 始终指向当前 DOM 中真实存在的元素。


5 分钟上手:从安装到运行

安装

npm install agentpage
# 或
pnpm add agentpage

基础用法

import { WebAgent } from "agentpage";

const agent = new WebAgent({
  token: import.meta.env.VITE_API_KEY,
  provider: "deepseek",   // 支持: openai / anthropic / deepseek / qwen / doubao / minimax
  model: "deepseek-chat", // 性价比之选
});

// 注册所有内置 Web 工具(click / fill / navigate / wait / evaluate 等 34 种动作)
agent.registerTools();

// 监听执行过程
agent.callbacks = {
  onRound: (round) => console.log(`[Round ${round + 1}]`),
  onToolCall: (name, input) => console.log(`  → ${name}`, input),
  onToolResult: (name, result) => console.log(`  ✓ ${name}`),
  onText: (text) => process.stdout.write(text),
};

// 执行任务
const result = await agent.chat(
  "进入用户管理页,搜索「张三」,点击第一条结果,把邮箱改成 zhangsan@example.com,保存"
);

console.log("停机原因:", result.stopReason);
console.log("总轮次:", result.metrics.rounds);
console.log("工具调用次数:", result.metrics.toolCalls);

内置 UI 面板(零依赖,开箱即用)

如果你想直接给页面加一个聊天框,不用自己写 UI:

const agent = new WebAgent({
  token: "your-api-key",
  provider: "openai",
  model: "gpt-4o",
  panel: true, // 右下角浮窗,零框架依赖
});

agent.registerTools();
// 用户在面板里输入任务,AI 直接在当前页面执行

企业落地:按路由构建 AI Skill

真实的企业应用通常有几十上百个页面,每个页面有自己的业务逻辑和操作边界。AutoPilot 支持按路由定义 AI Skill

const routeSkills: Record<string, {
  prompt?: string;
  tools?: () => void;
}> = {
  "/tickets": {
    prompt: `你在工单列表页。
可以执行:筛选工单、查看详情、批量操作。
不允许:删除工单、修改其他人的工单。`,
  },

  "/deploy": {
    prompt: `你在发布管理页。
执行发布操作前,必须先确认环境和版本号。
危险操作(回滚、强制发布)需要用户二次确认。`,
    tools: () => {
      // 注册部署专用工具
      agent.registerTool(createDeployConfirmTool());
      agent.registerTool(createRollbackTool());
    },
  },

  "/reports": {
    prompt: `你在报表页。只读模式,不允许任何写操作。`,
  },
};

// 路由切换时更新 Skill
router.afterEach((to) => {
  agent.clearCustomTools();
  agent.clearSystemPrompts();

  const skill = routeSkills[to.path];
  if (skill) {
    if (skill.prompt) agent.setSystemPrompt(skill.prompt);
    skill.tools?.();
  }
});

这样,AI 在每个页面都有明确的操作边界,既能发挥能力,又不会越权乱操作。


支持的 AI Provider

// OpenAI / Azure OpenAI
{ provider: "openai", model: "gpt-4o" }

// Anthropic Claude(推荐长任务场景)
{ provider: "anthropic", model: "claude-sonnet-4-20250514" }

// DeepSeek(性价比首选)
{ provider: "deepseek", model: "deepseek-chat" }

// 通义千问
{ provider: "qwen", model: "qwen-plus" }

// 豆包(字节 Ark 协议)
{ provider: "doubao", model: "doubao-1.5-pro-32k" }

// MiniMax
{ provider: "minimax", model: "MiniMax-M2.5" }

// 自定义(任何 OpenAI 兼容接口)
{
  provider: "openai",
  baseURL: "https://your-proxy.com/v1",
  model: "your-model",
}

为什么选 AutoPilot

你的场景 AutoPilot 给你的
想快速验证 AI Agent 方案可行性 npm install,5 分钟跑通,不需要部署任何后端
B 端系统有长流程、多步骤任务 REMAINING 协议 + 14 层保护,长任务稳定执行
担心 AI 操作失控或越权 按路由 Prompt 约束 + 可观测 stopReason
需要验证任务是否真正完成 三阶段快照断言,而不是 AI 自己说"完成了"
在中国大陆部署,需要国内模型 DeepSeek / Qwen / 豆包,全都支持
想定制 Agent 能力和 UI 工具注册、Prompt 覆盖、面板配置,全部开放

结语

把 AI Agent 内嵌到网页里,不是遥远的未来,现在就可以做到。

但"能跑"和"稳定跑完"之间的差距,比想象的要大。AutoPilot 花了大量精力在稳定性和可观测性上——14 层保护机制、REMAINING 协议、三阶段断言,都是为了让 Agent 不只是偶尔成功,而是可靠地完成任务

项目还在持续迭代中,任务后台模式、可视化调试、测试用例框架等能力都在路上。


如果这个项目对你有启发,欢迎去 GitHub 点个 ⭐ Star 支持一下,这对开源作者真的很重要!

🔗 GitHub:github.com/wenps/AutoP…

有问题、有想法,欢迎在 Issues 里交流,或者直接提 PR。

刚刚,阿里ATH事业群甩出王炸「悟空」!企业级正规军下场,龙虾们这次真要炸了

昨晚,阿里巴巴突然宣布成立 Alibaba Token Hub(ATH)事业群,CEO 吴泳铭直接负责,这可能是阿里在 AI 时代最重要的一次组织架构调整。

Token ,AI 时代的通用货币。

吴泳铭的逻辑是:未来大量数字化工作将由「数以百亿计的 AI Agent」支撑运行,而这些 Agent 的运行,由模型产生的 Token 驱动。

创造 Token、输送 Token、应用 Token,这将是阿里新的的主线。

其中内部信中还有一个首次出现在公众视野里的名字:悟空事业部。官方对悟空事业部的定位是:「打造 B 端 AI 原生工作平台,将模型能力深度融入企业工作流。」

也就是说原来的钉钉,被提到了一个更核心的战略位置,和千问一起分别在 B 端和 C 端承载阿里 AI 的目标。

这次发布会,悟空事业部交出了成立以来的第一份作业—— AI toB 旗舰应用「悟空 WuKong」,这也是首个以企业智能体为核心的 AI 原生工作平台。

这是ATH 事业群成立第二天,阿里巴巴集团 CEO 吴泳铭也出现在今天的「悟空」发布会现场。

最近在「养龙虾」席卷社交媒体后,每个人或多或少都感受到发现 AI 真的能操控电脑、帮你干活。

然而也便随这混乱,龙虾删邮件停不下来,敏感数据被 AI 随意读取,公司 IT 部门一句「这东西不合规」,大多数企业用户就此止步。

AI Agent 走到了哪一步,能不能广泛使用,还只是个技术问题。企业组织敢不敢用,才是真正的问题

APPSO 在现场给大家快速梳理了这场发布会的要点:

  • 悟空 WuKong:全球首个以企业智能体为核心、更安全、商业可交付的 AI 原生工作平台
  • 首创 AI 原生文件系统 Real Doc:每一步操作可追溯可回退
  • 钉钉全面 CLI 化:重写底层代码,给 AI 造了一套原生操作语言,可以 CLI 原生安全地访问钉钉应用和数据
  • 十大 OPT 行业方案:一人电商、一人门店、一人知识博主……Skill 即生产力
  • AI 能力市场:企业级 Skill 生态完整体系上线,全部纳入统一的安全扫描和分级管控体系
  • AI 硬件:A1 Pro 录音卡 + Cleer H1 AI 耳机首亮相
  • 原生级企业安全架构:底层沙箱隔离与全链路审计,让企业真正敢用 AI

钉钉为 AI 打造钉钉

在理解悟空之前,先要消除一个刻板印象,它绝对不是「钉钉加了一个 AI 对话框」。这句话值得重复一遍——悟空不是钉钉加了一个 AI 功能

过去两年,我们见过太多「产品加 AI」的案例:Word 加了 Copilot,微信加了元宝,网页端加了摘要按钮。这类产品的逻辑是:原有功能不动,AI 作为辅助层叠加在上面,帮你写写文字、润色润色、总结一下。

悟空的逻辑完全不同。

悟空是一个以企业智能体为核心的 AI 原生工作平台。 它能操作我们的电脑、编辑本地文件、调用桌面应用程序、连接钉钉文档 / 审批 / 日程 / 听记等全系产品。

当你对悟空说:「帮我把上周所有客户拜访的记录整理成周报,发给张总确认一下」。

悟空不会给你写一份模板然后让你自己填,它会直接打开你电脑上的拜访记录文件夹,读取每一份记录,生成周报,保存到指定位置,然后在钉钉里发给张总发起审批。

全程,你只说了一句话。

更关键的是:手机可以远程指挥悟空唤起本地环境完成工作。不需要坐在电脑前。出门见客户的路上,发一条消息,悟空在家帮你把活干完。

这是「本地执行 + 远程可控」的 Agent 工作架构,也是悟空正在定义的新工作方式——说一句话,就能干活。

▲体验网址:https://www.dingtalk.com/wukong

悟空与 OpenClaw:解同一道题,用的是不同答卷

很多人的第一反应:这不就是「中国版 OpenClaw」吗?

表面看都在让 AI 操作电脑,但两者的关系,更接近「Linux 的开源社区」和「Red Hat 企业版」,底层技术同源兼容,但面向的战场完全不同。

OpenClaw 证明了 AI Agent 可以操控电脑这个概念,它依赖「视觉模拟」和操作系统原生命令行,让 AI 像人一样看屏幕、点鼠标。这套方案很酷,但也很脆弱,毕竟界面一更新,命令一修改,整个流程就可能崩掉。

更要命的是,OpenClaw 在本地运行时,几乎拥有与用户完全相同的系统权限。理论上,一台实习生电脑上的 OpenClaw,可以读取他不该看到的任何数据。安全机构已发现其技能市场存在数百个恶意程序,Gartner 将其企业部署评级为「不可接受的网络安全风险」。

OpenClaw 是 Agent 的「Linux 时刻」——开源、自由、极客驱动、生态繁荣,但没有企业敢直接用。

悟空要解的题不一样:兼容开源生态的全部 Skill 能力,同时从架构层面把安全内建进去,而非事后打补丁。

统一企业身份认证、专属沙箱隔离、网络代理管控、全链路审计日志——每一层安全都在回答同一个问题:让 IT 部门敢拍板,让 CEO 敢买单

这是 Enterprise Agent 和「开源 Agent 框架」的本质差距。

钉钉 CEO 无招在发布会现场表示,「今天,我们把钉钉打碎,用 AI 重建,炼出悟空。过去是人用钉钉来工作,未来是 AI 用钉钉来工作。和市面上所有的龙虾 Agent 不一样,悟空天然就长在企业组织中,可以在真实的企业环境中安全使用。

CLI 化:给 AI 造一套原生操作语言

要理解悟空为什么「真的能干活」,关键是它有一套让 AI 能「听懂」软件的语言。

过去,几乎所有的 AI Agent 都在试图模拟人类的键鼠操作。这就像是蒙着眼睛,靠别人在旁边喊「往左一点,点击」来用电脑,不仅极度低效,而且极其容易出错。

为了让悟空真正能「干活」,钉钉做了一个相当疯狂的决定:所有底层代码重写了一遍

他们将整个钉钉的既有能力体系全面 CLI 化(Command-line Interface,命令行界面),所谓 CLI 化,就是把钉钉从一个「给人用的图形界面」,变成一个「给 AI 用的命令行接口」。

AI 不再需要「看懂」按钮在哪里,而是直接通过标准化指令调用能力,这相当于给 AI 装上了神经末梢

其中,包括文档、日程、审批、会议甚至 AI 表格,所有的钉钉产品,全部重写为标准的 CLI 指令。

这意味着,悟空不再需要像人类一样去「点击」按钮,而是通过原生指令,直接调用钉钉的一切能力和数据。

不仅是钉钉应用,阿里集团旗下的淘宝、天猫、支付宝、阿里云等核心业务能力,也将逐步作为 Skill 接入悟空。悟空,正在成为整个阿里巴巴 AI 能力在企业工作场景的统一出口。

当用户说「帮我整理下周的客户拜访记录并生成周报」,悟空不是「看懂」这句话,而是直接触发一系列 CLI 指令:调取日程 API → 抓取 CRM 数据 → 运行听记解析 → 写入文档 → 发起审批流。全程没有模拟点击,没有视觉识别,只有机器对机器的精准调用。

这个逻辑,在行业报告「未来属于智能体:万亿 AI 正在重新定义软件」里有一段话说得非常准确:

你构建的一切都必须是 API 优先的。如果一个功能没有 API,它就相当于不存在。如果不能通过 CLI 或 MCP 服务器暴露,你就是处于劣势。

换言之:在 AI 智能体成为软件「主要用户」的时代,不能被 AI 原生调用的软件,等于不存在

▲图片来源:X@karpathy

钉钉理解了这个逻辑,所以选择了极其昂贵的方式——重写服务全球 8 亿用户、2700 万家企业的产品底层。钉钉全面 CLI 化之后,Agent 才能从「能聊天」变成「能干活」。

Realdoc,AI 终于有了原生的文件操作语言

但 CLI 化只解决了「AI 能不能调用钉钉」的问题。还有一个更底层、常被忽视的问题——AI 怎么操作文件

目前市面上几乎没有 AI Agent 产品专门为 AI 设计过文件系统。所有人都在用传统文件系统凑合,结果是什么?

AI 要改一份文档里的一个词,必须先把整篇文档读进内存,改完再整篇写回去。就像改一本书里的一个错别字,却要把整本书重新抄一遍——荒诞,但这就是现实。

这带来三个连锁问题。

第一是 Token 爆炸,每次操作都吞进整篇文档,成本直线飙升,有用户实测用 AI 制作一个 PPT,消耗了 2.7 亿 Token,约合 500 美元。

第二是无法回退,AI 覆盖写入即生效,改坏了没有存档可以回溯,只能从头再来;

最后是文件失控,Agent 随机创建文件,企业根本不知道 AI 在哪里生成了什么,散落的结果是既找不到,也管不住。

悟空为此专门从零搭建了一套 AI 原生文件系统 Realdoc,这是行业首次,有人专门为 AI 重新设计一套文件操作语言

在 Real Doc 里,悟空可以像外科医生一样,按行号、按关键词定位,只动需要动的地方,其他内容一字不碰。Token 消耗大幅压缩,不再因为改一个词而把整篇文档走一遍。

更关键的是版本管理。AI 每执行一步操作,Realdoc 自动保存完整快照——就像游戏里的自动存档点,每一步操作都有记录,可随时退回任意版本,还能自动对比两个快照之间的 Diff,精确到每一行的变动。

还有文件归宿的问题。Realdoc 为每个 AI Agent 分配独立的云端工作空间,AI 产出的每一份文件都有「户口」——存在哪里、谁创建的、哪个 Agent 在什么时候改过,企业管理者一目了然。

到这里,悟空做出了大多数企业级产品还没意识到的改变:不再让 AI 套用到现有工具中,要为 AI 重新造一套工具

悟空首发 十个 OPT Skills 套件,钉钉原生协同

如果说 CLI 化解决了「AI 如何干活」,那么接下来的问题是:AI 该干哪些活,谁来告诉它怎么干

答案是:Skill。

Skill 是悟空的最小生产力单元——一个封装了行业专家 SOP、可直接调用的能力模块。我们不需要懂 AI,不需要写 Prompt,一键启用,AI 团队立刻就位。

这不是一个新概念,但悟空把它推向了一个全新的量级。

悟空首批推出十大行业 OPT(One Person Team,一人团队)技能套件,覆盖一人电商、跨境电商、知识类博主、开发、门店、设计、制造、法律、财税、猎头十大场景。每个行业包预置了若干串联 Skill,把过去需要团队协作才能完成的工作流,压缩成一个人可以独立驾驭的操作序列。

以跨境电商为例。过去,一个店主每天要在亚马逊上找爆款,去 1688 上比价,跟供应商确认库存,再想破头优化商品描述,一个人能管三个品就是极限。

现在接入悟空 OPT 方案后,「选品雷达」每天定时抓取亚马逊热榜数据写入 AI 表格;发现爆款后,「AI 找同款」瞬间完成国内供应链匹配;直接确认样品、生成产品描述、输出视频脚本,都有行业级的 Skills 辅助。从发现需求到供应链跟进,一个人用一个下午,干完了一个小团队一周的活。

「一人门店」的场景更让人感慨。街边的汽修店、美甲店老板,白天忙服务,晚上还要强打精神刷小红书学竞品写文案。现在,同样是多个 Skill 串联,AI 自动监控同行爆款,提炼出可复用的创作模板,自动生成原生网感文案并发布,甚至能 7×24 小时智能回复客户私信。

「当一个店主用 AI 运营账号的质量,比竞争对手请的代运营公司还好时——这件事就不只是效率提升了。这是小微门店生存逻辑的重写。」

这正是 Skill 即生产力的核心逻辑:把行业专家的隐性经验,变成人人可调用的标准化能力。Skill 不只是提高效率,它在重新分配能力——让不具备专业背景的人,也能获得专业级的产出。

这个逻辑的更大野心,体现在钉钉同步上线的 AI 能力市场

Anthropic 推出 Claude Skills 开放标准后,微软、OpenAI、Cursor 等巨头迅速跟进。行业共识正在形成:下一阶段的竞争,不是「谁的模型更强」,而是「谁的 Skill 生态更完整」

钉钉 AI 能力市场覆盖 Skill、Agent、Service 完整体系,从开发、审核、上架、分发到管理,全链路打通。

企业可以把资深员工的方法论固化成私有 Skill,彻底摆脱人才流失的阵痛;开源社区里数千个现成的能力,也能在企业级安全架构下被随时调用。

这是悟空最有想象力的部分,它在搭建 AI 时代的生产力基础设施——Skill 是这套基础设施里流通的「货币」,谁掌握更多高质量的 Skill,谁就掌握了 AI 时代更大的生产力。

AI 新硬件

除了软件,在这场发布会上,钉钉还发布了多款 AI 硬件。

DingTalk A1 Pro:录音卡形态,专为会议和工作场景设计,支持多麦克风阵列拾音,AI 实时转录、翻译、摘要,把「开完会还要整理纪要」的低效循环彻底斩断。

Cleer H1 AI 耳机:钉钉与 Cleer 联名推出,首款与悟空深度联动的 AI 耳机。戴上耳机,语音即可直接与悟空对话下达指令,无需打开屏幕,从而实现真正的「所想即所达」。

更值得关注的是 Real AI 硬件(Realbox):搭载 1 台 PC 环境 + 5 台手机环境,支持多人共用、多并发任务处理。企业部署一台 Realbox,可以同时为多个员工运行多个悟空实例;部署多台 Realbox,可构建 AI 计算机集群,任务并行处理,弹性扩展。

不难看出,钉钉这些 AI 硬件并不是独立存在市面上的同类产品抢夺市场,核心都是为了更好地打通 AI 工作流,成为软硬一体的 AI 原生工作平台。

OpenClaw 跑在一台电脑上,做一台电脑能做的事;悟空搭载 Realbox 集群,正式宣告:AI 算力,可以像水电一样,以基础设施的形式在企业内部流通了

AI 时代的组织生产力

在观看这场发布会时, 我想起前段时间 Sam Altman 在采访中提到的观点:「历史上第一家由一个人独立运营的十亿美元公司,即将出现。」

彼时龙虾还没火爆,一人团队(OPT)的概念也只是在 AI 圈子里。他没有解释这个人会用什么工具,会在哪里,会干哪个行业。但看完这场发布会,这句话变得具体了一些。

这个人,大概率会有一套像悟空这样的东西在身边。过去十一年,钉钉一直在让人学会用工具。悟空想做的,是逐渐让工具真正学会理解人。

当工具开始理解人,一件以前不可能的事情正在变得可能:组织生产力,第一次可以真正被数字化封装、分发和扩展。当 Skill 把行业专家的经验变成人人可调用的能力货币,当 AI 原生平台成为个体接入组织能力的操作系统,一个人或组织能做的事情的边界,将被彻底重新定义。

Sam Altman 看到的是「一人公司」这个终点,悟空要做的,是让更多普通人有机会走到那条路上。它不是专门为天才准备的工具,而是为所有「想做更多但苦于一个人精力有限」的人,提供一套 AI 时代的组织生产力基础设施。

AI 原生工作平台,正在成为这个时代最关键的组织变量。 谁先跑通它,谁就先拿到了超级个体时代的入场券。

之前有一个观点,燃烧 Token 的速度,决定了人的进化速度。而悟空的 1.0 版本,指向的就是人和组织进化的下一个版本。

文|李超凡

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

刚刚,英伟达龙虾登场!黄仁勋暴论频出,「人车家天地芯」冲击万亿收入

今年英伟达 GTC 主题演讲,应该是史上悬念最少的一届。

2022 年说元宇宙,2023-2024 年说生成式 AI,2025 年说物理 AI。但今年不一样,即便台上英伟达创始人黄仁勋的演讲还没有开始,但台下所有人已经知道答案了——Agent。

包括英伟达也悄悄在 GTC 园区里开设了「Build-a-Claw」互动专区,让与会者现场搭建自己的AI Agent。 从芯片到模型,从英伟达版龙虾到数据中心,今年主题演讲的潜台词只有一句话:

一切都要为 Agent 让路。

专为 Agentic AI 打造的 Vera Rubin 正式发布

如果说 Hopper 架构开启了生成式 AI(Generative AI)的时代,让机器学会了「说话」;那么 Vera Rubin 的使命,就是开启智能体(Agentic AI)时代,让机器学会「干活」。

  • 英伟达 Vera Rubin 架构包含七款芯片、五套机架系统,以及一台用于 AI Agent 的超级计算机
  • 七款芯片分别是 NVIDIA Vera CPU、NVIDIA Rubin GPU、NVIDIA NVLink™ 6 交换机、NVIDIA ConnectX-9 超级网卡、NVIDIA BlueField-4 DPU 和 NVIDIA Spectrum™-6 以太网交换机,以及新集成的 NVIDIA Groq 3 LPU
  • 五个机架分别是 NVIDIA Vera Rubin NVL72 机架、NVIDIA Vera CPU 机架、NVIDIA Groq 3 LPX 机架、NVIDIA BlueField-4 STX 存储机架,以及 NVIDIA Spectrum-6 SPX 以太网机架。

过去的 AI 像是一个极其聪明的图书馆管理员,我们问一个问题,它慢条斯理地翻书,然后把答案整理出来。我们对这种速度是宽容的,因为我们自己打字看书也慢。

但 Agent 完全不同。它不仅要用大模型思考,还要疯狂地调用工具——比如打开浏览器、控制云端的虚拟 PC、在无数个数据库里来回比对。更要命的是,AI 对工具的容忍度极低,它要求一切操作都在毫秒级完成。

「它会狠狠地捶打内存。」黄仁勋在台上这样形容。

当模型越来越大,上下文长度从十万 Token 飙升到数百万,还要同时处理结构化和非结构化的数据,传统的算力架构开始喘不过气了。为了应对这种「捶打」,英伟达交出了第一份答卷,全新的 Vera CPU。

这颗芯片特立独行,它是世界上首款专为智能体 AI 和强化学习时代打造的处理器,其效率是传统机架式 CPU 的两倍,速度提升 50%,采用 LPDDR5X 内存,能实现极高的单线程性能、大型的数据吞吐量和极致的能效。

黄仁勋甚至毫不掩饰他的骄傲:「我们从没想过会单独卖 CPU,但现在,这绝对是一个价值数十亿美元的业务。」

紧随其后的是 Rubin GPU,单片芯片直接塞进了高达 288 GB 的海量内存。它就像是一个拥有无限脑容量的思考者,专门用来装载那些体积越来越庞大的超大语言模型,以及处理成百上千万的上下文 KV 缓存。

除了堆叠 CPU 和 GPU,英伟达这次发布的 Vera Rubin 架构,直接把 NVLink 的带宽翻了一倍——260 TB/s 的全互联带宽。

十年前,DGX-1 用第一代 NVLink 把 8 张卡连在一起,那是专为 AI 研究员打造的奇迹;到了 Hopper 时代,是 NVLink 4;而前不久的 Blackwell 架构,用 NVLink 72 实现了 72 张 GPU 的全互联,带宽达到 130 TB/s。

为了配合 Vera Rubin,黄仁勋甚至掏出了被称为 Kyber 的全新机架。在这个机架里,计算节点垂直插入,背后是第六代 NVLink 交换机。完全抛弃了传统的以太网或 InfiniBand 限制,在一个 NVLink 域内直接打通 144 张 GPU。

即便强如 Vera Rubin,在面对「无限生成 Token」的极端需求时,也会感到吃力。

在算力世界里,吞吐量(Throughput,同时处理巨量任务的能力)和延迟(Latency,单次任务的极速响应)是一对物理学上的死敌。英伟达是吞吐量的绝对霸主,但在极致低延迟的 Token 生成上,传统 GPU 架构显得过于笨重。

这时候,Groq 出场了。英伟达早在之前就「收购」并授权了 Groq 团队的技术,在今天正式推出了 Groq LPU(语言处理单元)。

黄仁勋用一款名为 Dynamo 的软件,把这两者完美捏合,首创了「解耦推理(Disaggregated Inference)」。

  • AI 推理前半段的 Prefill(预填充)和极其耗费算力的 Attention(注意力机制),全部交给 Vera Rubin 这个性能王者来处理;
  • 后半段的 Decode(解码),也就是生成 Token 的瞬间,直接卸载给 Groq LPU 来降低延迟。

结果显示,在最具商业价值的高端推理层级,这种组合让性能直接飙涨了 35 倍,且每兆瓦的吞吐量同样提升了 35 倍。

一个开源项目,让所有 CEO 都睡不着觉

主题演讲的后半部分,黄仁勋抛出了一个让全场屏息的判断:OpenClaw,将是这个时代的 Linux,是这个时代的 HTML。

OpenClaw 上线仅数周,下载量和影响力已经超过了 Linux 三十年的积累,其本质上是一套智能体操作系统。它能调用大模型、管理文件、拆解任务、协调子智能体,还能发邮件、发短信,以任何模态与人沟通。

在黄仁勋看来,每一家 SaaS 公司,迟早都会变成 AgaaS 公司,也就是「Agent-as-a-Service(智能体即服务)」公司。而每一位 CEO 现在都必须回答同一个问题:你的 OpenClaw 战略是什么?

当然,开源意味着自由,但企业更需要的是安全。这也是 OpenClaw 规模化落地前最大的障碍。

为此,英伟达联合以 OpenClaw 创始人 Peter Steinberger 为代表的团队,召集了一批顶级安全与计算专家,推出 NeMoClaw 参考架构。

它内置 OpenShell 技术、网络防护机制和隐私路由能力,可以让企业可以在自己的私有环境中安全运行智能体系统。

而支撑这套智能体生态的,是英伟达一整条开源模型产品线。

比如 Nemotron 主攻语言推理,Cosmos 聚焦世界建模,Groot 面向通用机器人,Alpha Mayo 服务自动驾驶,BioNeMo 深耕数字生物学,Earth-2 则专注 AI 物理仿真。

黄仁勋特别强调,这些模型不只是排行榜上的名字。英伟达会持续投入推进,Nemotron 3 之后有 Nemotron 4,Cosmos 1 之后有 Cosmos 2,每一代都会更强。

更重要的是,这些模型全部以基础模型形式开放,任何企业都可以在此基础上继续微调和后训练,打造专属于自己业务场景的定制化智能。英伟达还宣布将与各地区合作伙伴协作,帮助不同国家和市场孵化本土化 AI 能力。

在台上,黄仁勋还宣布了一份让人眼前一亮的合作名单。Black Forest Labs、Cursor、LangChain、Mistral、Perplexity、Sarvam,以及 Mira Murati 创立的 Thinking Machines,悉数加入,共同推进 Nemotron 4 的研发。

划重点,英伟达不甘心只做卖铲人,更要亲自下场带头挖金矿,更重要的是,英伟达也是在构建一个生态,一个围绕智能体时代的完整体系。

玩家的显卡钱,是一场长达 25 年的「众筹」

要理解英伟达今天的恐怖统治力,黄仁勋首先把时钟拨回了 25 年前。

那时候没有 ChatGPT,没有大模型,只有一群为了让游戏画面更流畅而疯狂攒机的年轻人。「GeForce 是英伟达有史以来最伟大的营销活动」,黄仁勋在台上笑着说。

黄仁勋非常直白地承认,GeForce 就是用来吸引未来客户的。他们在我们还买不起企业级产品的时候,通过游戏显卡潜伏进我们的电脑。日复一日,年复一年。

也正是依靠一代代游戏玩家的「供养」,英伟达在 20 年前做出了一个当时看来堪称疯狂、甚至差点拖垮公司利润的决定——研发 CUDA,并将它送到了全世界每一个开发者的桌面上。

这可以说是一个在黑暗中蛰伏的故事。连续 13 代架构,长达 20 年的死磕,英伟达彻底把 CUDA 变成了一个装机量过亿的庞然大物。

这也解释了为什么当深度学习的「宇宙大爆炸」来临时,Alex Krizhevsky 和 Ilya Sutskever 们环顾四周,发现除了英伟达的 GPU,他们别无他选。

Nvidia 不是碰巧站在了风口上,而是花了 20 年时间,自己造了一台造风机。

飞轮一旦转动,就再也停不下来了。因为在这个飞轮里,硬件只是载体,真正黏住开发者的是那成千上万个工具、框架和开源项目。

既然当年是 GeForce 游戏显卡把 AI 算力(CUDA)带给了这个世界,那么十年后的今天,是时候让彻底长大的 AI,反哺它最初的「老家」了。

黄仁勋在台上甩出了惊艳全场的 DLSS 5。简单来说,英伟达正在用 AI 重新发明计算机图形学。传统的 3D 渲染是「结构化数据」,它是死板的、百分百可控的;而生成式 AI 是「概率性计算」,它是天马行空、极其逼真的。

以前这两派路线完全不同,但在 DLSS 5 里,英伟达硬是把它们揉在了一起,用可控的 3D 数据打底,用生成式 AI 去脑补和渲染细节。我们看到的画面,既不会出现 AI 经常犯的幻觉错位,又拥有近乎现实的惊人质感。

「生成出来的世界,变得极其美丽,同时又完全受控。」

但这也不只是一帮极客为了高帧率打游戏搞出来的炫技。黄仁勋说,这种将「结构化数据」与「生成式 AI」融合的逻辑,将会在每一个行业里一遍遍重演。

「这是我最喜欢的一页 PPT」

在演讲的高潮,黄仁勋放出了一张极其复杂的架构图,说这是他最喜欢的一页 PPT。接着,他又半开玩笑地说,团队屡次劝他别放这张图,但他偏要放,「反正你们有些人也是免费进来的,这就是门票钱」。

这张「最不听劝的 PPT」,真正揭示了英伟达接下来要吞噬的真正猎物,全球企业的数据中心。

过去,企业的数据分为两类。

一类是结构化数据,也就是常见的数据库 SQL、Pandas 里的那些庞大表格,它们是商业运转的地基。另一类是非结构化数据,比如海量的 PDF、视频、语音,占据了世界 90% 的信息,却因为难以检索而如同废纸。

过去几十年来,处理这些巨型 Excel 表格一直是 CPU 的绝对领地。当人类去查询这些表格时,CPU 的速度勉强够用。但黄仁勋一针见血地指出了未来的趋势,「未来,使用这些结构化数据库的,将是 AI Agents」。

当成千上万个不知疲倦的 AI Agent,以远超人类百万倍的速度同时向数据库发起查询时,传统的 CPU 计算系统连喘息的机会都没有,只会被瞬间压垮。

为了处理这个问题,英伟达掏出了第一把底层杀器:cuDF。它直接越过 CPU,用 GPU 的恐怖并行算力,把这群数据的处理速度拉爆。

而针对非结构化数据,英伟达掏出了第二把杀器,针对向量数据库和非结构化数据的 cuVS。有了这两个底层库,英伟达实际上是捏住了全球数据处理的咽喉,它正在用 AI 的方式,重新定义企业到底该怎么处理数据。

两个工具库的效果也是相当明显。黄仁勋举了非常多合作伙伴的例子,其中提到雀巢公司每天要处理覆盖 185 个国家的庞大供应链数据,在换上英伟达加速的 IBM Watsonx.data 后,速度飙升了 5 倍,成本却骤降了 83%。

这就是「加速计算」的恐怖之处。当速度实现了几个数量级的跃升,成本就会呈断崖式下跌,新的商业模式就会在此刻涌现。

黄仁勋的演讲进行到这里,满嘴都还是「算法」、「库(Libraries)」和「数据帧」,他直言「英伟达是一家算法公司。」

英伟达将自己的算法库深度嵌入每一家云端,客户为了用 Nvidia 的算力和框架,才会去购买云服务。这也是为什么几乎世界上所有的云服务巨头——Google Cloud、AWS、微软 Azure、Oracle,都得排着队,把英伟达的服务请进自己的机房。

曾经呼风唤雨的云厂商,在加速计算时代,似乎都正悄然沦为英伟达庞大生态的「底层基础设施」和「分销渠道」。

英伟达为什么能做到这一切?黄仁勋给出了一个极度反常识的定义,英伟达是世界上第一家「垂直整合,却又水平开放」的公司。

向下,它自己造芯片、造系统;向上,它懂每一个行业的应用场景。

金融界的量化交易员在用它,医疗行业的医药研发在用它,连电信行业那个只会发射信号的基站,在未来也会变成运行 AI 算法的边缘计算节点。

英伟达甚至还推出了机密计算(Confidential Computing),让极其敏感的企业数据和模型可以在完全隔离的环境下运行,连操作员都看不到。这直接打消了巨头们拥抱 AI 的最后一点顾虑。

它把自己封装成一个个底层算法库,然后像水和电一样,悄无声息地接入了所有人的基础设施;看似把所有的利润都分给了生态伙伴,但实际上,英伟达已经牢牢掌握了整个 AI 时代的命脉。

1 万亿美元,而且还会供不应求

根据黄仁勋的判断,到 2027 年,全球 AI 基础设施规模至少达到 1 万亿美元,而且这还是保守估计,实际计算需求会远超这个数字。

这个数字从何而来?答案藏在过去一年英伟达做的那件最重要的事里——AI 推理。

黄仁勋直言,很多人觉得推理很容易,但事实恰恰相反。

高难度推理是 AI 领域最难的事,也是最重要的事,因为它直接带来收入的增长。为此,英伟达在 Hopper 架构巅峰期做出大胆决定,彻底改变架构,打造出 NVLink 72,引入 NVFP4 精度格式,配合 Dynamo、TensorRT-LLM 及全套新算法,还专门建造了超级计算机来优化整套技术栈。

英伟达押注的结果,远超所有人的预期。

黄仁勋曾宣称 Grace Blackwell NVLink 72 每瓦性能提升 35 倍,当时没人相信他。后来 SemiAnalysis 发布评测报告,分析师 Dylan Patel 说黄仁勋说得太保守了,实际提升是 50 倍。

▲黄仁勋打趣道「Monkey King」「Token King」。

按摩尔定律,一代产品通常只能带来约 1.5 倍提升,没人预料到这次会是 50 倍。

性能提升之后,摆在面前的是另一个问题。一座 1 吉瓦数据中心,按 15 年摊销,建造成本就高达 400 亿美元,设备还没放进去。在这样的投入规模下,放进工厂里的计算系统必须是全球最好的,否则每一瓦浪费的电力都是真实流失的收入。

黄仁勋坦言,全球 AI 工厂里正有大量电力被白白浪费。

为此,英伟达发布了 NVIDIA DSX 平台,基于 Omniverse 数字孪生技术,让工程师在真正动工之前,先在虚拟空间里把整座 AI 工厂仿真一遍,从散热到电网,全部模拟清楚。

配合 Max-Q 技术,系统可以在功耗与算力之间实时动态调节。

黄仁勋说,这里面至少还藏着两倍的优化空间。同一套硬件,英伟达更新算法与软件后,Fireworks 等服务商的 token 生成速度从每秒 700 个跃升至接近 5000 个,提升 7 倍。这就是「极致协同设计」的真实含义。

过去数据中心存放文件,现在它生产 token。土地、电力、机房空间决定了工厂上限,而架构优劣决定了产出多少。黄仁勋说,未来每一家公司都会认真思考自己 token 工厂的效率问题,因为算力,就是收入本身。

更重要的是,地球上的 AI 工厂还没建完,英伟达已经把目光投向了太空。

英伟达 Thor 芯片已通过抗辐射认证,率先应用于卫星之上。英伟达正与合作伙伴联合研发名为 NVIDIA Space-1 Vera Rubin 的新型计算机,目标是直接在太空中建设数据中心。

太空没有空气,无法对流散热,散热是一道极其棘手的工程难题。黄仁勋坦承这件事非常复杂,但他相信英伟达有足够优秀的工程师来攻克它。从地面到轨道,英伟达算力扩张的路线,仍在持续。

自动驾驶的 ChatGPT 时刻,已经到来

物理 AI 是未来十年最重要的课题,而黄仁勋用一句话宣告,自动驾驶的 ChatGPT 时刻,已经到来。

英伟达 RoboTaxi Ready 平台此次新增四位重量级伙伴:比亚迪、吉利、五十铃、日产,携手打造 L4 级自动驾驶汽车。

这四家车企每年合计生产约 1800 万辆汽车,体量惊人。加上此前已加入的梅赛德斯、丰田和通用,英伟达的自动驾驶版图已覆盖全球最重要的一批整车制造商。

英伟达还与 Uber 签署合作协议,计划将具备 RoboTaxi Ready(无人出租车就绪)能力的车辆部署至多个城市,并直接接入 Uber 的全球出行网络。

在工业机器人领域,英伟达与 ABB、Universal Robots、库卡等头部企业展开合作,将物理 AI 模型集成至仿真系统,推动机器人大规模进入制造产线。卡特彼勒的加入,意味着重型工程机械也开始走向智能化。

主题演讲的最后,依旧是经典的机器人环节。

近期,《冰雪奇缘》的雪宝机器人已经现身迪士尼海外游乐园,而这一次,它也迈着憨态可掬的步伐登上 GTC 2026 的舞台,和黄仁勋有来有往地对话,动作自然,反应流畅。

它的肚子里装着英伟达 Jetson 计算机,这是整套系统的大脑。它的步态和动作,全部在 Omniverse 虚拟环境中完成训练,靠的是由英伟达、迪士尼和 Google DeepMind 三方联合研发的 Newton 物理引擎,运行于英伟达 Warp 之上。

正是这套物理仿真系统,让雪宝在进入真实世界之前,就已经充分适应了现实物理规律。黄仁勋说,未来的迪士尼乐园所有角色都将拥有真正的智能,在园区里自由走动,与每一位游客展开真实的互动。

演讲开始的时候,黄仁勋说,我要提醒你们,这是一个技术大会。我们将要谈论技术,谈论平台,最重要的是,我们要谈论生态系统。

生态系统?他实在太谦虚了,用生态帝国也不为过,黄仁勋曾经用一块五层蛋糕来描述 AI 产业的结构:最底层是能源和芯片,往上是基础设施、模型,最顶层是应用。

每一层都不可或缺。这个比喻听起来像是在描述一个分工清晰、各司其职的产业格局。但当你把这块蛋糕从底看到顶,会发现每一层里都有英伟达的手笔。

从最早「潜伏」在玩家机箱里的显卡,到主宰全球云厂商的底层框架;从太空里的抗辐射数据中心,到迪士尼乐园里和我们谈笑风生的机器玩偶。

英伟达用 20 年时间造了一台造风机,如今这台机器已经化身为一台永不停歇的 Token 生产厂。在这个工厂里,算力即权力,生态即壁垒。

当所有的企业、用户都在为如何落地 AI 焦虑时,黄仁勋已经悄悄把通往 Agent 时代的门票,塞进了世界上每一台服务器的咽喉。

这场关于未来 AI 的赌局,英伟达不仅既做庄家又做玩家,它甚至要把牌桌都买下来了。

作者:张子豪、莫崇宇

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

Agent Skill 和 Rules 有什么区别?

用过 Cursor 或者 Claude 的人对 Rules 应该不陌生——在设置里写几条规则,AI 就会按你的要求来。

那它和 Agent Skill 有什么不同?我见过不少人把这两个混用,或者干脆不知道该用哪个。

Rules 是什么

Rules 就是约束条件,告诉 Agent "你必须怎样,不能怎样"。

比如:

- 回复必须用中文
- 代码注释不能用英文
- 不要使用 var,统一用 const/let
- 每次修改代码后,提醒我写单元测试

Rules 的特点是全局生效,只要在对话范围内,每一次交互都受它约束。它不是在教 Agent 怎么完成某件事,而是在限定 Agent 的行为边界。

Agent Skill 是什么

Skill 是执行方法,告诉 Agent "这件事应该怎么做"。

同样是 Code Review 场景:

## Code Review 执行指南
1. 优先检查安全漏洞,标记 [HIGH]
2. 检查边界条件和空值处理
3. 评估性能问题
4. 输出格式:问题 + 等级 + 修改建议

Skill 是按需触发的,用户发起相关任务时才加载进上下文,完成后卸载。

核心区别

Rules 管边界,Skill 管方法。

Rules Agent Skill
本质 约束 / 行为准则 执行方法 / 操作流程
生效范围 全局,始终有效 按需,任务触发时加载
解决什么 Agent 该怎么"做人" Agent 该怎么"做事"
类比 公司规章制度 岗位工作手册

同一场景,两者分工不同

还是代码助手的例子:

Rules 负责的部分:

- 所有建议必须附带代码示例
- 不要直接帮用户改代码,先说明问题让用户自己改
- 回复保持简洁,不要长篇大论

这些是行为约束,不管 Agent 在做什么任务,都要遵守。

Skill 负责的部分:

Code Review 时:先查安全 → 再查逻辑 → 再查性能 → 按模板输出报告

这是执行流程,只在做 Code Review 这件具体任务时才生效。

两者叠加的效果:Agent 做 Code Review,按 Skill 定义的流程走,同时遵守 Rules 里"必须附带代码示例"和"保持简洁"的约束。


什么时候用 Rules,什么时候用 Skill

用 Rules:

  • 希望 Agent 在所有场景下保持某种风格或约束
  • 涉及输出格式、语言、态度等通用行为
  • 内容简短,几条原则就能说清楚

用 Skill:

  • 某类任务有明确的执行步骤和质量标准
  • 不同任务之间的执行逻辑差异很大
  • 执行内容较重,不适合一直挂在上下文里

一个判断方法:如果这件事对所有任务都适用,写进 Rules;如果只在特定任务里才需要,封装成 Skill。

常见的混用错误

把执行流程塞进 Rules:

# 错误示范
Rules:
- 做 Code Review 时,先检查安全漏洞,再检查逻辑问题,
  再检查性能,最后输出报告,报告格式为……(一大段)

这段内容只在 Code Review 时有用,却全局常驻在上下文里,纯属浪费 token,应该封装成 Skill。

把约束写进 Skill:

# 错误示范
code-review Skill instruction:
- 回复必须用中文
- 保持简洁
- 不要直接帮用户改代码

这些是通用行为约束,不只 Code Review 需要,应该写进 Rules 全局生效。

总结

  • Rules:全局约束,管的是 Agent 的行为边界,始终生效
  • Skill:执行方法,管的是具体任务怎么做,按需加载
  • 两者不冲突,配合使用——Rules 定底线,Skill 定打法

设计 Agent 系统时,把该全局的放 Rules,把该按需的封 Skill,结构会清晰很多。

不用折腾部署 OpenClaw,我用 MiniMax Agent 一键养「龙虾」,还拍了个短剧

春节假期,帮亲戚朋友们部署 OpenClaw 成了我一份额外的工作。虽然不一定能真正用上,但这只龙虾是不得不拥有。

AI 进入我们的工作流,在 OpenClaw 爆火之后,这种感觉变得更加强烈。在「不用 AI 会被淘汰,用了 AI 也像是能被替代」的悖论下,不错过任何一个能放大自身价值的 AI 工具,让人陷入了无止境的 FOMO。

越来越多的「龙虾变体」也涌现出来,但是当被问到打算怎么把这个部署好的 OpenClaw 融入工作流,答案往往又是个未知数。更不用说光是部署好 OpenClaw,就有两道大关,一是要手动部署和配置复杂的模型 API,二是让人心疼的额外 API 费用。

今天,更新后的 MiniMax Agent 推出了两项新功能。

专业度更高,更会干活的 Expert 智能体社区,涵盖从技术开发、创意写作到音视频图片生成等多模态领域,超过 1.6 万个专家,且还在持续增长。大多数场景下,我们几乎都能直接找到现成可用的专家;即便没有完全匹配的,用几句话还能快速创建一个自己的 Expert。

另一项新增的 MaxClaw 模式,能让我们一键打通 OpenClaw 生态,而且完全不需要自己配置 API,以及承担额外的 API 费用,解决了「不知道 OpenClaw 能做什么」和「怎么部署 OpenClaw」这两个问题。

这也就意味着,即便是纯小白,现在也能拥有开箱即用的专属 AI 专家团队了

APPSO 也实测了一波智能体专家和 MaxClaw 这两项新功能,它确实和一般的智能体 Agent 不同,结合了 Skills 的能力和 OpenClaw 的兼容能力,我们直接就能操作飞书、钉钉等即时通讯软件。

而和市面上不同版本的 OpenClaw 对比,MiniMax Agent 的 MaxClaw 又有了预置的专家智能体,整个体验会更加友好。

体验地址:国内版🔗 https://agent.minimaxi.com
海外版🔗 https://agent.minimax.io

超过 1.6 万个 Experts 的大社区

对于 AI 创作来说,无论是文本还是多媒体,大多数时候用大模型,最痛苦的就是「AI 味太重」或者「废话连篇」。究其原因,往往是「提示词不当」、「模型不够强」,总结在普通的聊天形式缺乏深度的垂直领域优化。

MiniMax Agent 这次推出的 Expert(专家智能体) 虽然还是在聊天对话里进行,但底层逻辑做了一些改变。它主打即开即用,提供了针对各种深度垂类场景优化的 Agent

▲MiniMax Agent 内提供了办公效率、商业金融、教育学习、生活娱乐等上万个专家

在处理对应垂直领域的任务上,和非专家的单纯对话形式相比,专家能交付更专业、质量更高的结果。为了验证这一点,我们直接从它目前已经 1.6w+公开的 Expert 库(大部分是用户创作)里,挑了几个热门的场景进行实测。

PPT、网页、行业分析,AI 开始按场景分工干活

从目前 Expert 社区的使用热度来看,用户最先跑起来的,往往还是那些直接指向生产力的刚需场景,比如办公制作、内容搭建,以及金融与行业分析。

在 MiniMax Agent 首页,我们点击左侧边栏的「探索专家」,就能进入已经按场景分好类的专家社区。不同专家不仅标注了能力方向,还能看到背后调用的「子代理」和完整项目指令,相当于把一套成熟工作流直接摆在用户面前。

找到合适的专家后,点击「开始聊天」,输入需求,它就会按既定流程自动推进任务。

▲股票价值分析专家介绍

在办公与内容生产场景中,落地页生成和 PPT 制作依然是浏览量最高的一类专家。

我们先测试了 Landing Page Builder 专家。输入需求:「我要给初中生做一个五代十国历史的网页,得让他们真的能听进去,内容翔实有考据,一节课 45 分钟的内容。要解释清楚、配图到位、动效得当、沉浸感强,举的例子能让他们产生共鸣,再加几道题检验下理解程度。」

整个过程中,专家几乎不需要额外干预,而是按照预设流程自动完成结构设计、内容填充和页面生成。

▲预览链接:https://qvwu1nyvju2u.space.minimax.io/

从最终效果来看,这类 Expert 和传统 Agent 最大的区别在于,它从边聊天边拼凑,转成了沿着一条完整生产流程在推进,结果的稳定性和完成度明显更高。

生成的网页不仅信息完整,画面和动效也有一定沉浸感,相比过去一些 vibe coding 产品常见的模板化和渐变紫风格,要更克制也更可用。

在偏专业的分析类任务上,Expert 的优势会更明显。我们选择了 McKinsey PPT(麦肯锡风格演示文稿生成)专家进行测试。按照介绍,它会自动补充数据、图表以及行业洞察。

实际测试中,我们只输入了一句非常简单的需求,「制作一份关于全球机器人市场的10页幻灯片演示文稿」。但最终生成的 PPT,在信息密度、结构完整度和图表配置上都没有明显缩水,基本具备拿来就能用的初稿质量。

这类场景也很能体现 Expert 的定位,它尝试把一整段专业工作流程产品化,从增强单次问答的模式里彻底跳了出来。

有了多模态能力的专家,一句话拍出顾北辰的短剧宇宙

还没听说过有能生成视频的通用 Agent 产品,但现在结合多个不同的 Skills、Agents 的专家,输入一段剧情,直接就能给我们一部短剧。

▲提示词:霸总重生在电子厂打螺丝,宫崎骏动漫风格,1-3分钟视频长度,台词激烈有冲突,剧情跌宕起伏有反转。

我们使用 AI 短剧导演+摄影+剪辑师专家进行测试,和一般的视频生成模型只能产出 5-10s 左右的视频不同,这个专家能自动生成完整的分镜,并且把视频进行剪辑和拼接。

最后生成的视频,完成度很高,虽然没能对口型把台词一字一句说出来,但是也配了一段应景的 BGM。而且大概率是检测到了提示词里面的「宫崎骏」,整个动画的风格,乃至角色和公司名字,都透露着一股日漫的味道。

简单对话,每个人都能创建一个专家

如果觉得官方或别人做的专家,还不够贴合我们的使用习惯和工作场景,MiniMax Agent 也提供了自定义功能,通过简单的一两句话就能创建一个专家。

我们完全不需思考什么是 Skill 或者专家,也不用遵守标准文件的规则设置等,只需要通过自然语言交互,就能更方便地把个性化的工作流、SOP 等集成,创建专属 Expert。

热点追踪是媒体编辑一项非常重要的工作,我们在 MiniMax Agent 的专家社区里,也使用过多次热点追踪的专家。例如当我们要求它基于输入的「春晚被机器人刷屏」这个主题,去搜索最新消息和近期热门话题时;它最后能给我们一份完整详细的长文,但是不够个性化。

于是,我们开始自己来创建一个 APPSO 的热点追踪。

▲在探索专家页面右上角点击「创建专家」,输入自己的需求,MiniMax Agent 会自动帮我们完成创建

创建专家的过程是可以连续对话,如果对目前专家的输出不满意,我们可以继续在对话框内要求 MiniMax Agent 进行更新。

创建完成之后,我们只需要发送一句「开始,帮我整理今天的科技快讯」,专家就会给我们 24h 内最值得关注的 AI 消息,并且以早报的文风和格式要求写好。此外,这些自己创建的专家,MiniMax 还提供了 15 轮免费,即不消耗积分的优惠,体验门槛更低。

▲APPSO 自定义的专家,现在可以自主完成一份快讯早报

除了大量可以直接使用和自定义的 Experts,更值得关注的是即将上线的 Marketplace。用户创建的 Expert,如果被使用,就能获得相应的积分,可以用来在 MiniMax Agent 里完成更多的任务。

而后续 MiniMax 还将开放专家自行定价,这意味着如果你在某个垂直领域有真正的专业积累,封装成 Expert 除了分享自用,还可能是一种新的变现路径。

说白了,一个 Skills 专家的应用商店雏形,已经摆在我们面前了。

一键接入 OpenClaw 的 MaxClaw

如果说 Expert 是强大的大脑,那么 MaxClaw 就是让大脑连接到现实的双手,这也是 MiniMax Agent 这次升级里,玩法最丰富的一个功能。我把它叫做升级版的 OpenClaw。

根据网络上到处都是的 OpenClaw 指南,想要真正好用的OpenClaw生态,我们要先学会手动部署、配置复杂的模型API,还要时刻盯着后台,生怕一不小心跑出天价的 API 账单。

对于绝大多数不懂代码的普通小白来说,这门槛属实是太高了。我只是想把好用的 AI 接入自己的飞书或钉钉,创建一个机器人,但是第一步就困住了。

MiniMax Agent 新增的 MaxClaw 模式,一键打通了 OpenClaw 生态,不需要繁琐的手动部署和配置模型 API,通过MiniMax Agent 网页端就可以快速上手。

目前,它也兼容手机端多个即时通讯交互工具,我们可以在飞书、钉钉、Telegram、WhatsApp、Discord、Slack 中使用。

拿部署到飞书机器人举例,甚至不用额外的部署指南,我们只需要点开首页左侧边栏的 MaxClaw 按钮,点击「立即开始」,我们可以选择使用默认配置,或者其他专家。

这也是 MaxClaw 对比 OpenClaw 的一大亮点,除了能像 OpenClaw 一样连接到不同的聊天应用,在自己常用的 App 里就能指挥 AI 干活;我们在初始配置时,就可以直接选择那些已经有的预置专家 Agent 配置。

创建之后,在对话框里发送消息,「我想连接到飞书」,按照 MaxClaw 回复的消息,我们点击飞书开放平台的链接,登录之后,按照流程,创建一个企业自建应用,获取 App ID 和 App Secret。接着把复制的信息发送给 MaxClaw,它会提示重启,重启之后在飞书的配置事件订阅里选择添加对应的事件就能启用。

不出所料,整个过程肯定会有一些问题。例如我们在拿公司飞书账号测试时,就被提示相关的授权需要审核才能发布,以及在权限管理和事件配置部分,飞书里面的内容太多太杂乱,根本不知道授予哪些权限。

这个时候,直接回到 MaxClaw,把遇到的问题统统发给它,跟着它的提示走,基本上都能解决。

顺利部署之后,我们在自己的飞书里,就能看到一个对应名字的机器人,然后直接开启对话,所有的对话也会同步在 MiniMax Agent 网页里的 MaxClaw 显示。

▲现在,飞书就能指挥你的 MaxClaw

让 MaxClaw 帮我们干活,都只用在飞书里面指挥它。我们直接把之前创建的「热点追踪」专家的指令发给它,然后在飞书里对话,输入一句简单指令,「帮我整理今天的快讯」。

很快,一份结构完整的 AI 早报就直接回到了飞书对话框里,完全按照要求的格式,摘要、关键信息提炼、标题等全部都有。并且还能设置定时任务,让 MaxClaw 在飞书里主动给我们发送消息。

除了热点追踪,之前的股票价值分析等专家,我们现在也可以直接通过飞书聊天的方式,就让 MaxClaw 为我们总结出一份逻辑清晰的完整报告。同时,继续让它为我们监控英伟达最新的动态。

而如果直接在配置的时候,选择对应的专家,我们可以看到它的 Skills 情况,MaxClaw 会自动添加开箱即用的 Skills 来帮助我们更好的上手。

▲在效率工具里面有「博客监控」和「内容摘要」等 Skills 用于「热点追踪」专家

时间一到,MaxClaw 在飞书里,准时给我们推送了最新的资讯。

「Claw」是 Agent 之后一种新的智能阶段

这次更新,真正值得关注的,其实不是又多了一个 Agent 工具。

OpenClaw 的爆火,让我们看到了一个能真正干活的「Agent」是什么样。它是个性化的,部署在自己的电脑上,告别了过去一个网页解决所有用户问题的统一;它是互联互通的,打穿了终端设备上不同应用的壁垒,在 Telegram 也能指挥 AI 帮助我们回复工作邮件……

▲知名博主 Simon Willison 提到 Claw 似乎正在成为像 Agent 一样的专用术语,用来描述一种新的智能体类别|图片来源:https://simonwillison.net/2026/Feb/21/

这本质上是在提醒我们一件事:AI 正在从「辅助回答问题」,走向「直接进入工作流」。当 AI 开始能够调用工具、跨应用执行任务、甚至在后台持续运转,我们原有的工作组织方式,本身就已经在发生变化。

问题只在于,大多数普通用户其实卡在门外。

▲全球 81 亿人中, 84% 的人从未用过 AI,而只有 0.3% 的用户愿意为 AI 付费|图片来源:https://global-ai-adoption.netlify.app/

一边是大家都知道 Agent 很强、OpenClaw 很火;另一边,是复杂的部署流程、看不懂的 API 配置,以及随时可能失控的调用成本。很多人不是不想用,而是很难真正用起来。

MiniMax Agent 这次做的事情,某种程度上就是在把这道门槛往下搬,让普通打工人也能轻松搭建自己的顶级 AI 工作流。

▲MiniMax Agent 会员定价|对比大部分 AI 动辄 20 美元一个月的订阅费用,MiniMax Agent 39 元的价格,大约一杯咖啡的钱,却已经足够能帮我们把写稿、做 PPT、跑多 Agent 工作流一口气打通,让这只「龙虾」多线程干活

Expert 把过去需要反复调 Prompt、反复试错的专业流程,打包成了即开即用的专家社区;MaxClaw 则把原本偏极客向的 OpenClaw 生态,压缩成了一键可用的连接能力。

对于普通用户来说,这种变化的意义很直接,我们不用懂什么是终端,不用让自己费尽力气做个半吊子「工程师」,也能开始搭建自己的 AI 工作流。

▲METR 此前的研究显示 AI 工具对开发人员生产力的影响,导致生产力下降了 20%;但 METR 表示现在这一发现已经过时,生产力提升似乎更有可能|图片来源:https://x.com/METR_Evals/status/2026355544668385373/

当越来越多「Agent」能够被像软件一样使用,AI 对工作方式的影响,才会真正开始外溢。

从这个角度看,MiniMax 推出这些产品,价值或许不只在于功能多了两个按钮,更在于它正在把一套原本属于少数人的先进工作范式,逐步变成更多人可以上手的日常工具。

对普通用户来说,这或许才是 Agent 真正开始变得有用的时刻。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


几天手搓的Claude Code拓麻歌子火了:成本几乎为0,一句话做硬件时代来了

1996 年,一家日本公司推出了 Tamagotchi(电子宠物)。这个小小的蛋形塑料设备风靡全球,成为一代人的童年记忆。

1997 年,拓麻歌子(Tamagotchi)还让它的创造者日本万代公司,获得了当年的搞笑诺贝尔经济学奖,而原因是,

他们创造了人类供养虚拟宠物的新型经济模式,成功转移了数百万人的工作时间,用于饲养虚拟宠物。

去年八月,万代公司表示,拓麻歌子从 1996 年以来,产量已经达到了一亿台。在那个时代,生产一款这样的产品,大概需要一个工业设计团队、需要电子工程师设计电路板、需要长达一年的开发周期……

2026 年,一个开发者用 AI 做了一个 Tamagotchi。他需要的只是一台电脑和 Claude Code。成本接近零,开发周期可能只有几天。

这个最新的 Claude Code 版拓麻歌子,最近在 X 上吸引了一大波网友的关注。

▲视频来源:https://x.com/SamuelBeek/status/2022614292411940897

网友把命令行里面跳动的 Claude Code 符号,转到了能够触摸得到的、随身携带的拓麻歌子上。当 Claude Code 在命令行里面思考,或者是问,是否同意执行下面的步骤时,手里的拓麻歌子都会弹出消息来,指示我们下一步操作。

电子宠物成精了,还会拦截 Bug

和以前那些 AI 硬件的逻辑不同,Claude Code Tamagotchi 不是一味的把大模型放到布娃娃、手表、闹钟、书包、甚至是马桶里。

这个 Claude Code 拓麻歌子要做的是一种转移,一种无法被替代的存在。

目前已经有多款不同的 AI 拓麻歌子小玩意,其中关注度最高的由开发者 Ido Levi 创建的 Claude Code Tamagotchi。

▲视频来源:https://www.instagram.com/reel/DUMAlN7Dpx7/

乍一看,它就是一只住在终端里的像素风格宠物。有一些简单的表情、有状态、还会对用户的行为做出反应;但它不是一个简单的怀旧游戏。

当我们在用 Claude Code 编程时,放在桌子边上的这只宠物,会一直在你的终端界面中显示。它在观察 Claude Code 的每一个操作,确保这个 AI 助手真的在按照我们的意图工作。

如果 Claude Code 表现良好,宠物会开心地摇尾巴。如果 AI 开始不听话,比如未经允许重构代码,或者修改了你明确说不要动的文件,宠物会变得暴躁,甚至会直接中断 AI 的操作。

▲项目地址:https://github.com/Ido-Levi/claude-code-tamagotchi

目前,Claude Code 拓麻歌子这个宠物项目,已经在 GitHub 上开源,我们也可以直接把这个电子宠物部署到自己的 Claude Code 里面。它具体是如何工作的呢,根据作者对项目的介绍,举几个例子来说明一下。

项目主打的就是「实时监控」,当我们直接对 Claude Code 说,「只修复这个 bug,不要动其他文件。」

Claude Code 开始工作,终端里的宠物睁大眼睛盯着看。几分钟后,Claude Code 完成了修改,只改动了目标文件。
这个小宠物就会开心地摇尾巴:😊 (◕‿◕)。

而当这个小宠物检测到违规时,他还能发出「违规警告」。我们明确告诉 Claude Code 说,不要重构,保持代码原样。但 Claude Code 还是开始重构整个模块,可能它觉得这样代码会更优雅。

这个时候,电子宠物的表情变了:😠;屏幕上还会显示,「⚠ 警告:AI 正在违背你的指示」。

除了提示,它也能实际的做一些越界拦截之类的工作。比如我们给出的指令里面非常明确的提到了,千万不要动数据库。Claude Code 在修复一个相关 bug 时,尝试修改数据库。

小宠物就会立即中断:❌ 操作被阻止。Claude Code 的操作被拦截,我们的数据库安然无恙。宠物露出得意的表情:💪

这种从软件到硬件的交互,也让我想到了我们之前分享的 Vibe Coding 小键盘。

这几天,在 X 上还有一个硬件版 Cursor 特别火。目前的 Cursor 是专门用来开发软件产品的工具,而这个 Cursor for hardware 就是用来实现,一句话做一个硬件设备。

▲ 为硬件开发设计的 Cursor,地址:https://www.schematik.io/

网友 marcvermeeren 就用这个工具,搭建了一个叫做 Clawy 的可爱小助手,用来管理他的 Claude Code 对话。

还有网友 dspillere 也做了一个类似的产品,他说虽然已经部署了 OpenClaw,但他完全不知道 OpenClaw 什么时候在思考,什么时候在执行任务。这个小巧的桌面助手就应运而生,放在他的桌子上,可以实时的更新 OpenClaw 的最新信息。

▲视频来源:https://x.com/dspillere/status/2018752036968304660

在评论区里,大家都在问什么时候发货,可以去哪里买。也有人说,这是一个全新的领域,我们一直在关注人的状态,关注人类的电子使用记录,是时候应该关注 Agent 的情况了。

▲Agent 的物理反馈是一个被严重低估的用户体验问题

软件开发的 AI 红利,终于轮到硬件了

去年,我们还在想 AI 最好的软件载体是什么,是大家都在做的对话框,还是连 OpenAI 都一窝蜂涌进去要重做的浏览器,但最后证明都不是,今年 OpenClaw 的爆火,证明了 AI 在软件上,最终的归宿就是 Agent。

关于硬件的讨论就更不用多说,光是今年 CES 上那些让人哭笑不得的发明,就能看到 AI 硬件这块还是个巨大的未知数。

如果说 Agent 的成功是靠着「人人都能做软件」慢慢成长起来的,那么 AI 硬件也会在「人人都能做硬件」里面,不断沉淀。

▲Schematik 的发起人 Samuel Beek,现为 VEED.io 首席产品官

像 Schematik 这类工具已经设计出来,用来帮助我们更快开发 AI 硬件。它把硬件设计变成了和网页开发一样,我们只需要用自然语言描述硬件需求。告诉 Schematik 想要构建一个「带温度传感器和 OLED 显示屏」,不需要查阅各种数据表,不需要引脚编号、元件代码或任何的手动查找。

过去,如果我们想做一个简单的「温湿度监测器」。需要做的是,

  1. 搜索传感器型号,下载 DataSheet。
  2. 确认引脚定义(VCC 是接 3.3V 还是 5V?接反了直接冒烟)。
  3. 寻找对应的驱动库,处理版本冲突。
  4. 在 Arduino IDE 里写代码,改 Bug。

而 Schematik 的出现,把这个过程极简化成了「一句话的事」。几秒钟后,Schematik 会吐出我们需要的一切。完整的、通过验证的固件代码;一份清晰的接线图;分步组装指南。

它生成的接线图,清晰地展示了每一根线该从哪里接到哪里,解决了新手最大的恐惧,「我这根线接对了吗?」。一键部署的功能,更是一步到位,它能直接生成基于 PlatformIO 的工程文件,直接导入。

PlatformIO 是一个强大的嵌入式开发生态,我们可以直接在 Schematik 里点击「Flash」,固件就会被编译并烧录进板子里。从「我想做一个东西」到「这东西跑起来了」,中间可能只需要不到一分钟。

前段时间,Claude 发布的 Cowork 以及相关企业级 AI 插件重挫软件股,直接蒸发人民币约两万亿。以前我们想要一个 P 图工具,需要去应用商店搜索下载安装,现在,一句话自己都能做一个。

但 Claude Code Tamagotchi 这类产品的出现,还有硬件版 Cursor,让我们不得不怀疑,硬件开发的「Cursor 时刻」是不是也要来了。

未来的硬件开发,或许也会变成,只需要我们提供「创意」和「逻辑」,剩下的脏活累活,无论是写代码还是画电路图,都将由 AI 代劳。

也许这样的未来不会很远。但更重要的是,在这个时代,动手能力的定义已经变了。

以前动手能力强是指一个人会焊接、会画板子、会写代码;以后,动手能力强,是说他擅长用 AI,从从容容、游刃有余地指挥原子和比特为他起舞。

我已经想到了,下一个爆火的 AI 硬件,甚至可能会是一个挂在包上的 OpenClaw 版 Labubu。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


实测 GPT-5.3-Codex,OpenAI 史上第一个高危模型,连 API 都还不敢给我们

今天凌晨发布的 GPT-5.3-Codex 可以说是 OpenAI 对这段时间来,各种本地 Agent 爆火的一记重拳回击,当然主要是对 Anthropic 的反击。

配合 OpenAI 前几天的发布的 Codex 桌面版应用,Skill、Cowork、Claude Code,甚至是 Openclaw,这些热门工具能实现的功能,现在通过 Codex 的外壳 + GPT-5.3-Codex 模型能力,都能做到了。

▲ 在 Codex App 内可以直接选择 GPT-5.3-Codex 模型,也能选择深度思考的强度

和之前介绍 Cowork 的能力一样,我们也丢了一些类似的任务让 Codex 来完成,像是直接处理本地文件、各种格式转换、调用不同的 Skills 组合能力、做 Word/PPT/Excel、下载视频、开发 App……

GPT-5.3-Codex 的表现确实亮眼,相比较从头开始安装 Claude Code,对新人用户来说,现在直接下载 Codex 会是一个更好的选择。这也是未来模型厂商的一种趋势,一开始大家都是从黑乎乎的命令行终端开始做本地 Agent,接着都慢慢回归到可视化的友好界面。

网上对 Codex 的评价在这几天也有了不少逆转,许多开发者从 Claude Code 转向 Codex,一些在国内的独立开发者也表示 Codex Plus 会员就可以用,而且还不会像 Claude 那般总是无情封号。

奥特曼更是激动的宣布,Codex 的活跃用户已经超过 100 万。在模型更新博客,也是毫不掩饰和留有余地的夸赞,

GPT-5.3-Codex 是我们第一个能够自我构建的模型。通过使用 5.3-Codex,我们能够以如此快的速度发布 5.3-Codex。

跟 Claude 团队用两周的时间,使用 Claude Code,100% AI 代码,搓出一个 Cowork 一样;还有 OpenAI 去年年底发布的文章,「使用 Codex 在 28 天内构建 Android 版 Sora」,Agent 的时代真的来了。

用 Codex 取代我的 ChatGPT 和 Claude Code

和大多数的本地 Agent 一样,无论是终端还是 Cowork,我们都是先选择一个工作文件夹。在 Codex 中,我们可以创建多个 Project,选择对应的文件夹,再进一步开始对话,Codex 把它们叫做 Threads 线程。

先用最普遍和简单的例子,我们添加了一个空的下载文件夹,然后点击开始一个线程,选择 GPT-5.3-Codex 模型;就像在 ChatGPT 里面对话一样,输入指令。

要求它帮我们下载一个 X 视频,Codex 会自动检查可用的 Skills 来处理,接着通过 yt-dlp 工具进行下载,这个视频有四个多小时长,Codex 会一直在对话框里自动更新下载进度。

▲GIF 图经过加速处理

视频下载后,我们还可以要求它提取视频的逐字稿,给我们一份双语版本的文档,最后让它把整个流程打包为一个 Skill,方便下次使用。

如果视频中有一些比较有意思的片段,想要裁剪视频,或者是把裁出来的视频转成 GIF 图,在 Codex 里都能做到。

例如,我们这里下载了一个视频,然后要求它把视频的 5s-25s 裁剪出来成为一个新的视频;得益于 GPT-5.3-Codex 的 Token 快速处理,整个过程不需要很长时间,反而更多是取决于本地电脑的硬件解码编码能力。

▲ GIF 图经过加速处理

或者我们也可以直接要求它把视频的前 5s 转成一个 GIF 文件,并且确保大小在 10MB 以内,帧数可以自行调整,清晰度上将宽度控制在 640px。

很快,我们就能得到对应的 GIF 文件。更极端一点,还能让它把整个视频转成图片,每秒 30 帧,每一帧就是一张图。

这些对本地文件的直接处理,和 GPT-5.3-Codex 在 Terminal-Bench-2 测试集上的优异表现,让 Codex 基本上能满足各种生产力工具、效率工具的功能实现。

作为对比,同样是刚刚发布的 Claude Opus 4.6 在 Terminal-Bench 2.0 上得分是 65.4%,GPT-5.3-Codex 是 77.3%。

▲ 图片来源:https://x.com/neilsuperduper/status/2019486017703547309/

例如在这个文件夹中,有多张图片,我们首先是要求它根据图片内容,对这些图片文件进行重命名,并保持文件名不超过 20 个字母,不允许使用符号。

▲ GIF 图经过加速

自动修改完成后,我们还能要求他对这些图片进行拼接,无论是垂直拼接还是水平,调用对应的工具,Codex 都可以做到。

和 Claude Skills 一样,Codex 也能安装 Skills 市场上丰富的技能,并且在应用内,就已经提供了包括 pptx、xls、word、canvas、notion 在内的多款技能。

回到基础的编程能力,升级后的 GPT-5.3-Codex 表现也比 GPT-5.2 要好上不少。我们直接要求它写一个「每日一词」的 App。和在 ChatGPT 里面直接用 Canvas 给我们一个带不走的网页不同,Codex 能在本地从零开始,完成项目,然后使用 Vercel 或 Cloudflare 等 Skills 部署到网页上。

这里我们选择的推理模式是 Extra High,超强推理模式,于是在每一步操作之前,GPT-5.3-Codex 都会询问我下一步的操作选择,这也和 Codex 内部能直接根据任务情况,调用不同 Skills 有关,其中的头脑风暴 Skill,会自动进行不断对话的模式。

最后,它基本上还是完成了我一开始要求它完成的全部功能,并且还能进一步开发 macOS、iOS,和安卓版本。

如果我们有现成的代码项目,也可以选择该项目文件夹,在 Codex 中打开,GPT-5.3-Codex 会分析项目存在的 Bug,并且修复它。

在过去很长一段时间里,无论是工具还是模型,开发者的首选其实都是 Anthropic 的 Sonnet/Opus 模型和 Claude Code 工具。OpenAI 在编程、尤其是长代码逻辑推理上的掉队,曾让不少开发者转投阵营。

GPT-5.3-Codex 的出现,就是为了终结这场争论。现在 GPT-5.3-Codex 在编程基准测试和实际表现上,不仅碾压了自家的前代模型,也确实有把友商模型按在地上摩擦的前兆。它真正具备了编写、测试和推理代码的能力。

做游戏项目,是这次模型介绍博客里,网站开发部分主要案例,我们也让 GPT-5.3-Codex 做了一个简单的物理弹球游戏,整体的效果虽然没有达到我的期待,因为我在提示词里面有说希望这是一个 RPG 的游戏,但 GPT-5.3-Codex 给我的界面还是过于简陋了。不过,好在还是能玩。

我们也在 X 上找到了一些用 GPT-5.3-Codex 做的小游戏,像这个类似超级玛丽的收集金币。

▲来源:https://x.com/Angaisb_/status/2019548783869325331

强中更有强中手

对 Anthropic 来说,OpenAI 今天玩的这些,可能会说,这都是我们玩剩下的。无论是代码、或者 Agent 的能力,还是开始着手去做本地 Agent,从之前 Codex 的终端转成现在的 macOS App。

在技术的领域,OpenAI 仿佛都是跟着 Claude 的脚步在走,Claude 深耕代码能力,OpenAI 搞了 Sora、日报、浏览器、ChatGPT agent,都没什么水花,于是也在代码上发力;Claude 一月初推出 Cowork,OpenAI 也紧接着在二月初发布 Codex App。

就和今天的密集发布一样,凌晨 1:45,Claude 官方发 X 推出 Claude Opus 4.6,紧接着就是 OpenAI 端上 GPT-5.3-Codex。两款模型其实都是为了给 Agent 更强大的基座能力,以前是说代码/vibe coding,但现在 Agent 能做好,基本上都是「写代码写得好」。

Opus 4.6 虽然在 SWE-Bench 上的表现甚至不如 Opus 4.5,并且 Terminal-Bench 2.0 上的成绩也没有 GPT-5.3-Codex 强,但是 Opus 破天荒地把上下文长度拉到了一百万 token 的窗口。而且,这些 benchmark 的表现还没有相差很多。

Claude 说,我的 Sonnet 5 还没上来,那才是真功夫。

我们在网上也找了一些 Opus 4.6 最新的测试案例,有网友说 Claude 4.6 Opus 只是一次调用,就完全重构了他的整个代码库,将原来混乱的代码「屎山」全部模块化,并且没有模型能像 Opus 这样做到。

还有网友拿 Opus 4.6 和 4.5 进行对比,让两个模型玩同一款经营游戏,看谁的账户等级、财富和装备更高。测试博主提到,4.6 版本在初期制定战略的时间更长,但是做出了更好的战略决策,并且在最后确实做到了遥遥领先。

还有网友也做了一个游戏,不过是一个宝可梦的克隆版。博主提到这是他用 AI 做出来的最酷的东西。他提到,Claude Opus 4.6 思考了 1 小时 30 分钟,使用了 11 万个 Token,并且只迭代了三次。

▲ https://x.com/chatgpt21/status/2019679978162634930

在 CLaude 官方演示和早期用户的反馈中,也提到了一个 Opus 表现优秀的案例。Opus 4.6 在一天内自主关闭了 13 个 issue,issue 即项目存在的待解决问题,并将另外 12 个 issue 准确分派给了正确的人类团队成员。

和 Kimi K2.5 的智能体蜂群一样,Opus 4.6 也能管理一个 50 人规模组织的代码库。在 Claude Code 中,我们可以组建 Agent Teams,召唤出一整个队伍的 AI,不再是一个 AI 在战斗。这些AI 可以有的负责写代码,有的负责 Review,有的负责测试,它们之间自主协作。

也有网友测试了 Claude Code 里面的 Agent 蜂群,提到启用蜂群之后的 Opus 4.6,速度提升 2.5 倍,并且效果也更好。

我们现在的状态就跟这张图片一样,虽然一山比一山高,但都绕不出这个圈。前几个月可能是 Gemini 赚走了风头,一月份来,应该是 Claude,然后看样子又要轮到 OpenAI,或者马斯克的 Grok。

好在这个轮回的过程中,作为用户的我们,能明显感觉到 AI 的能力一直在变强。

GPT-5.3-Codex 的 API 还没有开放,原因是模型太强了,会存在很大的风险,所以 OpenAI 还在考虑怎么安全地启用 API。

Claude Opus 4.6 已经可以在 Claude 通用聊天应用、Claude Code、API 多种方式使用,这两个作为今年国外御三家首发的两款模型,非常值得一试。

未来,更好的服务 Agent,让 Agent 为我们做事,还会是大模型更新的重点。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


❌