今天我给它发了一条告别消息，而它也平静地接受了。

01 我的养虾史

OpenClaw 是一个开源的 AI Agent 框架，部署在服务器上后，可以通过飞书、Telegram 等渠道与 AI 对话。社区里大家习惯叫它”龙虾”。

这是我养的第三只龙虾了。

第一只：bot

还是在 OpenClaw 还没被改名的时候养的，接入了 Claude Opus 模型。

当时我的感受是：这东西为啥会火，直接用 Claude Code + Skills + claude-mem + happy 也能做到，浪费了大量的 token，完全是高射炮打蚊子。

（注：Claude Code 是著名的 AI 编程助手；claude-mem 是它的长期记忆插件；happy 是手机远程操作 Claude Code 的工具）

在接下来的日子里，我也尝试发掘它的潜力，安装了社区里各种插件。但总觉得不如我直接手机操作 Claude Code。除了回复我一堆堆废话，刷刷刷烧着 token 外，完全感觉不到存在感。

所以这只龙虾活了一周就被我给格式化了。

第二只：kimi-claw

Kimi 是我个人挺喜欢的一家公司。他们总是会做一些”新”的小玩具，比如最初的 PPT、长上下文，最近的 ok-computer、Agent 集群，也包括这次的 kimi-claw。

这个新玩具，需要订阅 199 元/月的套餐，没有优惠。

本质上就是它给你开了个虚拟机，装好改版的 Claw，配了一些插件，API 也内置配置好。整个初始化只要 1 分钟，不需要配 tg-bot，不需要配飞书机器人，直接在 Kimi 的网页端和 App 里就能和龙虾对话。

本着来都来了、钱都花了的心态，这只龙虾我是用得最多的。所以吐槽也最多：

慢，Kimi-2.5 是真的慢，问它写个简单脚本，Opus 30 秒搞定的事它要磨蹭好几分钟。不稳定，遇到一次前一天还能用，第二天就莫名重置了。封闭，无法外网访问，想传个文件都很烦。笨，相对于 Opus，真的是降维打击。记性差，号称长上下文，实际体验一言难尽。

体验上，主要赢在一个方便：部署方便、内置插件方便、手机直接 App 打开方便。其他的没什么新感受。

算下来，国产各家我基本都充过一波了（除了腾讯的实在太黑我只想白嫖），在我看来，没被御三家拉开代差。虽然这个市场最终还是会一地鸡毛，但至少目前还是一个不错的信号。

第三只：xiami

腾讯的新春活动白嫖了一个月云主机，配上 Claw 应用模板，配上我丰富的龙虾折腾经验，五分钟部署完直接走起。

（看了下活动到 3 月底，最近很火的腾讯帮你装 OpenClaw，估计就是直接拿这套在拉人头 :）

由于是自己的服务器，可玩性就高了点。

先将模型换了，直接整上 2api（一个第三方 API 中转服务）的 Codex，最近 Codex 普号能用后，价格白菜得一塌糊涂。

然后飞书直接建了个虾厂，拉上小伙伴，主打一个共享龙虾。

接下来各种整活的 Skill、外部 API 配上，主打一个娱乐性拉满，安全性裸奔。

但是用了几天，又开始索然无味了。编程工作不如直接用 Claude Code，安全性又是一个黑箱，不敢给它太多隐私。所以慢慢就沦为鸡肋了。

再后面就是各种龙虾变种（OpenClaw 这几十万行代码是真的没眼看），各自做出了差异化。

02 突然爆火的龙虾

然后，这玩意最近火出圈了？

从一个极客玩具，突然就变成了人手必备的贾维斯了？

腾讯、字节、阿里、各大云厂商纷纷下场不说，连指导文件都出现了。（我：黑人问号？）

想起最近做微舆的高中生直接喜提盛大 3000W 投资变 CEO，他在 L 站发求关注贴的时候才 600 Star。说实话，技术上并不复杂，但胜在产品嗅觉和执行力——这可能才是 AI 时代最稀缺的能力。

我突然有点明白了，AI 时代，做产品的思路已经发生了根本性的变化。

而这种变化，其实有迹可循。

03 从瀑布到 AI

早期软件开发的经典模型，是瀑布模型：需求、规格、概要设计、详细设计、编码、单元测试、集成测试。

那个时代软件的开发成本极高，每一步都要反复打磨，否则背后可能就是万丈深渊。一个项目从立项到交付，动辄以年计。

下一个经典模型，是敏捷开发：强调沟通、快速迭代。

一方面是因为这玩意毕竟是一群外包大佬提出的，另一方面也是因为试错和发行的成本降低了——有了云服务、有了 App Store，你可以先上线一个 MVP，再根据反馈迭代。渐进明细，成为了降低风险的必然选择。

而我们可能即将看到一个全新的模型：AI-CoWork。

因为 AI 能力的提升，开发成本会极速降低。人的工作变成了定方向、审核、做决策。AI 在一直工作，人只是偶尔喊两声。

回想我自己养虾的经历，五分钟部署、换个模型、配几个插件就上线了——这在两年前是不可想象的。

当”做出来”不再是瓶颈，**”让人知道”就成了新的战场。**

所以我们看到的趋势是：先是超级个体、网红工程师靠个人影响力出圈，然后最终是平台收割。

软件领域将会如同拼多多、抖音那样，最终倒在流量面前。因为你的技能不再是门槛，当 AI 能帮所有人写代码，能写代码这件事本身就不值钱了。

而且更远一点看，AI 自身演进进化的能力正在浮现。

今天还需要人来”养虾”，明天虾可能自己就会游了。

程序员可能成为第一个自己革了自己命的行业（笑

04 虾死了，然后呢

小龙虾的服务器到期了，我没有续费。

不是因为它没用，而是因为我已经从它身上学到了该学的东西：

AI 时代的产品，技术只是入场券，真正的壁垒在于你能多快地触达用户、理解需求、完成闭环。

三只虾，从”这东西为啥会火”到”我突然有点明白了”，这条路走了不到半年。

下一只虾，也许不会再叫虾了。但那个让我凌晨还在折腾、第二天又觉得索然无味、然后某一刻突然想明白点什么的过程——大概不会停。

但它们各自为战。Claude Code 只能用 Claude，Gemini CLI 只能用 Gemini。想在 Claude Code 里调 Gemini？不行。想多个账户轮流用？手动切。一个号配额满了？自己换。而且配额只会越收越紧。

CLIProxyAPI 解决的就是这个问题：一个代理地址，接管所有 AI 账户，自动轮询、自动切换、自动转换格式。

程序只有 10MB，内存占用不到 10MB。改配置不用重启。开源免费。

本文基于 CLIProxyAPI v6 源码撰写。GitHub | 官方文档

下面按四类场景展开——先白嫖跑通，再加钱混搭，然后丢服务器，最后接中转。找到你的场景直接跳过去就行。

白嫖党：Qwen 免费跑通

先花 5 分钟跑通一个完全免费的场景。选 Qwen 是因为它不需要任何付费订阅，注册通义千问就能用。

去 GitHub Releases 下载你系统对应的包——macOS Apple Silicon 选 darwin_arm64，Intel 选 darwin_amd64，Linux 选 linux_amd64。解压到一个干净目录，比如 ~/CLIProxyAPI/。

Windows 用户：下载 windows_amd64.zip，解压到比如 D:\CLIProxyAPI\。下文命令统一写 macOS/Linux 版本，Windows 差异会在引用块里说明。

macOS 也可以 brew install cliproxyapi，Arch Linux 可以 yay -S cli-proxy-api-bin。

解压后目录里有一个可执行文件和一个 config.example.yaml。把 config.example.yaml 复制一份改名 config.yaml，清空内容，换成这几行：

1
2
3
4
5
6
7
8
9
10

port: 8317
auth-dir: "~/.cli-proxy-api"
request-retry: 3

quota-exceeded:
  switch-project: true
  switch-preview-model: true

api-keys:
  - "ABC-123456"

这里的 api-keys 是你自己随便设的密码，客户端连代理时要带——跟 OpenAI 的 API Key 没有任何关系。auth-dir 是 OAuth 登录后认证文件的存放位置，~ 代表用户主目录。

Windows 用户：~ 在 Windows 下指向 C:\Users\你的用户名，更保险的写法是改成绝对路径 auth-dir: "D:\\CLIProxyAPI\\auths"。

现在登录 Qwen。打开终端，cd 到 CLIProxyAPI 所在目录（程序需要读取同目录下的 config.yaml），执行登录命令：

1
2

cd ~/CLIProxyAPI
./CLIProxyAPI -qwen-login

Windows：cd D:\CLIProxyAPI 然后 .\CLIProxyAPI.exe -qwen-login（PowerShell）或 CLIProxyAPI.exe -qwen-login（CMD）。

浏览器自动弹出 Qwen 登录页，登录通义千问账号，授权完成。终端会让你给这个账户起个名字（随便填，比如 qwen-main），回车，认证文件就存好了。想加多个账户？再执行一遍同样的命令，系统会自动轮询所有账户。

启动代理：

1

./CLIProxyAPI

看到 API server started successfully on: :8317 就成了。开一个新终端验证：

1

curl http://127.0.0.1:8317/v1/models -H "Authorization: Bearer ABC-123456"

Windows PowerShell：必须写 curl.exe，写 curl 会调到 Invoke-WebRequest，参数完全不同。Windows 10 以上自带 curl.exe。

返回里能看到 qwen3-coder-plus、qwen3-coder-flash 等模型名，说明一切正常。

最后把客户端接上来。拿 Claude Code 举例：

1
2
3
4

export ANTHROPIC_BASE_URL=http://127.0.0.1:8317
export ANTHROPIC_AUTH_TOKEN=ABC-123456
export ANTHROPIC_DEFAULT_SONNET_MODEL=qwen3-coder-plus
claude

Windows PowerShell：

1 2 3 4

$env:ANTHROPIC_BASE_URL = "http://127.0.0.1:8317" $env:ANTHROPIC_AUTH_TOKEN = "ABC-123456" $env:ANTHROPIC_DEFAULT_SONNET_MODEL = "qwen3-coder-plus" claude

其他客户端套路一样——任何支持自定义 OpenAI Base URL 的工具都能接：

• Cherry Studio：添加提供商 → 类型选 OpenAI-Response → API 密钥填 ABC-123456 → API 地址填 http://127.0.0.1:8317 → 管理模型 → 加载远程列表
• Cline / Roo Code：Provider 选 OpenAI Compatible → Base URL 填 http://127.0.0.1:8317/v1 → API Key 填 ABC-123456
• Cursor：OpenAI API Base URL 填 http://127.0.0.1:8317/v1

到这里你已经在免费用了。如果你想看一个更完整的实战案例——比如在 VSCode Continue 里同时调 Codex 和 Claude，可以看这篇。接下来看看怎么加更多提供商。

氪金党：多号混搭

一个 Qwen 免费号当然不够。真正强大的用法是把所有订阅塞进同一个代理，让 Claude Code 同时调三四家模型。

所有提供商一张总表

除了 Gemini，其他提供商都是一条命令的事——执行登录命令，浏览器弹出授权页，登录完成。所有登录命令都支持 -no-browser（不自动打开浏览器，手动复制链接）和 -oauth-callback-port 9999（自定义回调端口）。

Gemini 需要多走一步

Gemini 要先创建一个 Google Cloud 项目：

1. 打开 Google Cloud Console，创建新项目（名称随意）
2. 在项目里搜索并启用 cloudaicompanion.googleapis.com
3. 记下项目 ID

然后执行：

1

./CLIProxyAPI -login -project_id "你的项目ID"

浏览器弹出 Google 登录页，登进去授权。project_id 不是必须的，但指定了能获得更好的配额管理。多账户就重复执行——每个 Google 账户可以创建自己的项目。

混搭示例

登录完多个提供商，所有模型会出现在同一个列表里。在 Claude Code 里可以这样混搭：

1
2
3
4

# 重活用 Claude，日常用 Gemini，轻量任务用 Codex
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-6
export ANTHROPIC_DEFAULT_SONNET_MODEL=gemini-2.5-pro
export ANTHROPIC_DEFAULT_HAIKU_MODEL=gpt-5-codex-mini

客户端请求哪个模型，CLIProxyAPI 就自动路由到对应的提供商。格式转换、认证方式这些全自动。

路由策略和配额切换

多个账户才需要关心这些。如果你只有一个号，跳过这节。

1
2
3

routing:
  strategy: "round-robin"   # 每次请求换一个账户
  # strategy: "fill-first"  # 优先用第一个账户直到满

round-robin 把请求均匀分配到所有账户，适合多号薅配额。fill-first 优先压一个号，适合”主力号 + 备用号”的组合。

配额相关的三个参数搭配使用：

1
2
3
4
5
6
7

request-retry: 3              # 失败重试次数（403/408/5xx 自动重试）
max-retry-credentials: 2      # 最多尝试几个不同的账户
max-retry-interval: 30        # 冷却等待上限（秒）

quota-exceeded:
  switch-project: true         # 配额满了自动换账户
  switch-preview-model: true   # 配额满了自动换预览版模型

一个号配额满了，自动切下一个。所有号都满了，尝试切到预览版模型。这组配置是最小配置里就有的，一般不需要改。

服务器党：Docker + 远程

本地跑通了，下一步是丢到服务器上，多台设备共用一个代理。

Docker 部署

建好目录和配置文件：

1
2

mkdir cliproxyapi && cd cliproxyapi
mkdir -p auths logs

config.yaml 跟前面一样，不需要改——Docker 容器里 ~ 就是 /root，volume 映射会把 /root/.cli-proxy-api 挂到宿主机的 ./auths。

docker-compose.yml：

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

services:
  cli-proxy-api:
    image: eceasy/cli-proxy-api:latest
    pull_policy: always
    container_name: cli-proxy-api
    ports:
      - "8317:8317"     # 主 API 端口
      - "8085:8085"     # Gemini OAuth 回调
      - "1455:1455"     # Codex OAuth 回调
      - "54545:54545"   # Claude OAuth 回调
      - "51121:51121"   # Antigravity OAuth 回调
      - "11451:11451"   # iFlow OAuth 回调
    volumes:
      - ./config.yaml:/CLIProxyAPI/config.yaml
      - ./auths:/root/.cli-proxy-api
      - ./logs:/CLIProxyAPI/logs
    restart: unless-stopped

1

docker compose up -d

OAuth 登录：SSH 隧道

容器里没浏览器，OAuth 回调地址又限制了 localhost——用 SSH 隧道解决。原理很简单：在你本地电脑和服务器之间建一条隧道，把 OAuth 回调从本地转发到服务器。

以 Gemini 为例：先在服务器上执行登录命令（-no-browser 表示不打开浏览器，会输出一个链接），先别急着开链接；在本地电脑上建 SSH 隧道（Gemini 回调端口是 8085），然后在本地浏览器打开那个链接完成登录。

1
2
3
4
5
6
7

# 服务器上
docker compose exec cli-proxy-api /CLIProxyAPI/CLIProxyAPI -no-browser -login

# 本地电脑上（新终端）
ssh -L 8085:localhost:8085 user@你的服务器IP

# 然后在本地浏览器打开服务器输出的链接

各提供商的回调端口：

Qwen 和 Kimi 用的是设备代码流（Device Code Flow），不依赖本地回调端口——直接在容器里执行登录命令，然后在任意设备的浏览器打开输出的链接就行。

登录完成后，客户端 Base URL 指向 http://你的服务器IP:8317，其他配置不变。

管理面板

从 v6.0.19 起，Web UI 内置在主程序里。配置里加上：

1
2
3
4

remote-management:
  secret-key: "你的管理密码"
  allow-remote: false        # 要远程访问就改 true
  disable-control-panel: false

这是少数改了需要重启的配置项。

浏览器打开 http://127.0.0.1:8317/management.html，输密码，可以看使用统计、管理认证文件、查看日志。面板里的 OAuth 登录功能只能在本机用，远程服务器还是得走 SSH 隧道。

想要更丰富的管理？还有这些选择：

• EasyCLI — 官方 Tauri 桌面客户端
• TUI — ./CLIProxyAPI -tui -standalone 启动终端管理界面
• CLIProxyAPI Dashboard — Next.js Web 仪表盘

远程存储

默认认证文件存本地磁盘。多台服务器想共享认证，在 .env 里配远程存储——支持 PostgreSQL、Git 仓库、S3 三种方案：

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

# PostgreSQL
PGSTORE_DSN=postgresql://user:pass@localhost:5432/cliproxy

# Git 仓库
GITSTORE_GIT_URL=https://github.com/your-org/config.git
GITSTORE_GIT_USERNAME=user
GITSTORE_GIT_TOKEN=ghp_xxx

# S3 对象存储
OBJECTSTORE_ENDPOINT=https://s3.example.com
OBJECTSTORE_BUCKET=cliproxy
OBJECTSTORE_ACCESS_KEY=xxx
OBJECTSTORE_SECRET_KEY=xxx

大多数人用不到这个——除非你有多台服务器需要共享同一批账户。

中转党：API Key 接入

除了 OAuth 登录”借用”订阅，你也可以直接用 API Key 接入——官方 API 或中转服务商都行。

Claude API

1
2
3
4
5
6
7

claude-api-key:
  # 官方 API，不需要 base-url
  - api-key: "sk-ant-...你的密钥"

  # 中转商，需要指定 base-url
  - api-key: "sk-xxx..."
    base-url: "https://中转商地址/api"

Claude 的 API 会检查请求来源，从 Cline 等非官方客户端调用可能被拒。如果遇到这个问题，开 Cloak 伪装：

1
2
3
4

claude-api-key:
  - api-key: "sk-ant-..."
    cloak:
      mode: "auto"    # 非 Claude Code 客户���自动伪装请求头

只有用 Claude API 且从非官方客户端调用时才需要 Cloak，其他场景不用管。

Gemini API（AIStudio）

1
2
3
4
5

gemini-api-key:
  - api-key: "AIzaSy..."
    models:
      - name: "gemini-2.5-flash"
        alias: "flash"   # 短别名，可选

Codex API

1
2

codex-api-key:
  - api-key: "sk-atSM..."

OpenAI 兼容服务

像 OpenRouter 这类中转商，用 openai-compatibility：

1
2
3
4
5
6
7
8
9

openai-compatibility:
  - name: "openrouter"
    base-url: "https://openrouter.ai/api/v1"
    api-key-entries:
      - api-key: "sk-or-v1-...密钥1"
      - api-key: "sk-or-v1-...密钥2"   # 多密钥自动轮询
    models:
      - name: "moonshotai/kimi-k2:free"
        alias: "kimi-k2"

区别：Claude/Codex 每个密钥单独声明 base-url（不同密钥可能来自不同中转商）；OpenAI 兼容模式下多密钥共享一个 base-url。

前缀路由

多个同类型密钥，想指定走哪个？给密钥加前缀：

1
2
3
4
5

gemini-api-key:
  - api-key: "AIzaSy...01"
    prefix: "free"
  - api-key: "AIzaSy...02"
    prefix: "paid"

请求 free/gemini-2.5-pro 走第一个，paid/gemini-2.5-pro 走第二个。只有多密钥同类型的场景才需要这个。

你以后可能会用到的

以下功能大多数人不需要马上用。碰到的时候回来查就行，完整字段参考见 config.example.yaml。

模型别名 — 嫌模型名太长？起个短名。fork: true 保留原名的同时多一个别名：

1
2
3
4
5

oauth-model-alias:
  gemini-cli:
    - name: "gemini-2.5-pro"
      alias: "g2.5p"
      fork: true

排除模型 — 不想暴露某些模型给客户端，用通配符排除：

1
2
3
4

oauth-excluded-models:
  gemini-cli:
    - "*-preview"
    - "*flash*"

Payload 规则 — 给特定模型强制设参数或设默认值。比如让所有 Gemini Pro 请求默认带 thinking budget：

1
2
3
4
5
6

payload:
  default:
    - models:
        - name: "gemini-2.5-pro"
      params:
        "generationConfig.thinkingConfig.thinkingBudget": 32768

Amp CLI 集成 — 把 Amp 的模型请求映射到你自己的提供商：

1
2
3
4
5

ampcode:
  upstream-url: "https://ampcode.com"
  model-mappings:
    - from: "claude-opus-4-5-20251101"
      to: "gemini-2.5-pro"

Claude Header 默认值 — 遇到版本不匹配报错时覆盖默认请求头：

1
2
3
4
5

claude-header-defaults:
  user-agent: "claude-cli/2.1.44 (external, sdk-cli)"
  package-version: "0.74.0"
  runtime-version: "v24.3.0"
  timeout: "600"

网络代理 — 需要走代理访问外网时：

1

proxy-url: "socks5://user:pass@192.168.1.1:1080"

TLS — 开启 HTTPS：

1
2
3
4

tls:
  enable: true
  cert: "/path/to/cert.pem"
  key: "/path/to/key.pem"

流式响应调优 — 一般不用改，除非遇到超时断开：

1
2
3

streaming:
  keepalive-seconds: 15
  bootstrap-retries: 1

常见问题

改了配置要重启吗？ 不用，热重载。唯一例外是 remote-management。

怎么看有哪些模型？ curl http://127.0.0.1:8317/v1/models -H "Authorization: Bearer 你的key"

Token 过期了？ 自动刷新。刷新失败就重新 -login 一次。

api-keys 和提供商的 api-key 什么区别？ 前者是你给代理设的密码（随便写），后者是 AI 服务商给你的密钥。

Claude Code 连不上？ 排查：curl 能返回数据吗？ANTHROPIC_BASE_URL 设对了吗？ANTHROPIC_AUTH_TOKEN 跟 api-keys 一致吗？都对的话开 debug: true 看日志。

Codex 登录失败？ 需要 ChatGPT 付费会员（Plus/Pro/Team），免费号不行。

Docker 里怎么 OAuth？ SSH 隧道，上面”服务器党”章节有写。

延伸阅读

• 邪修用法：Codex/Claude Code 转标准 API — CLIProxyAPI 实战案例，在 VSCode Continue 里同时调多家模型
• Claude Code 可用量缩水分析 — 为什么你需要多号轮询
• Claude Code 限制收紧的深层原因 — 背后的技术和商业逻辑
• Claude Code + Azure DevOps MCP 使用指南 — Claude Code 的另一个高级玩法

生态

围绕 CLIProxyAPI 已经有 15+ 个衍生项目：

去试试。

这几天 openai 因为国防部订单问题，深陷美帝人民讨伐中。2B 的业务被 Anthropic 抢了 70% 不说，2C 的 AppStore 排名也被反超。这下奥特曼是彻底坐不住了，先是开胃菜：GPT-5.3-Instance（更会说人话的模型），同时还在 X 上暗示说 “5.4 会比你们想象中快地到来”。

结果，没过两天，半夜就偷偷发布了 GPT-5.4 了。

在各大自媒体还没来得及发文前，我们赶紧先偷偷体验一波看看。

模型介绍

一句话概括：
GPT‑5.4 的核心提升，不只是“更聪明了一点”，而是更像一个能真正完成专业工作的模型：更会思考、更会写代码、更会用工具、更能操作软件和网页，而且整体更省 token、来回沟通更少。

按能力角度看

• 产品定位：5.4 把最近几代分散的优势合并到了一个主力模型里，尤其把 GPT‑5.3‑Codex 的前沿编码能力吸收到主线模型中，目标很明确：面向文档、表格、演示、软件系统这类真实专业工作。
• 知识工作：对长文档、多来源材料、互相矛盾的信息整合更强，尤其适合研究、报告、分析类任务。官方给出的例子里，它在复杂浏览/检索类基准上明显领先 5.2，比如 BrowseComp 从 65.8% 提升到 82.7%。
• 交互体验：ChatGPT 里的 GPT‑5.4 Thinking 会先给出一个“前置计划 / preamble”，你可以在它生成过程中直接纠偏，而不是等它答完再重来。这本质上降低了多轮返工成本。
• 长程推理：更能在长时间思考过程中保持前文一致性，适合那种 30–60 分钟级别、需要持续推演和校验的复杂任务。
• 编码能力：这次是很实打实的升级。官方数据里，SWE-bench Verified 从 67.2% 提升到 74.9%，SWE-Lancer Diamond 从 24.0% 提升到 42.0%，Codeforces 从 1260 到 1840。说明它不只是“会写片段代码”，而是更擅长跨文件修改、重构、理解仓库上下文。
• 工具使用 / Agent 能力：这是 5.4 很大的看点。它支持更强的工具调用、tool search、并行子任务（#task），还支持最长 1M token 上下文，更像一个能规划、执行、再验证的工作代理。
• 电脑操作与视觉：5.4 是 OpenAI 首个“通用型 + 原生 computer-use”主力模型，能看截图、操作网页和软件、发鼠标键盘指令。OSWorld-Verified 从 47.3% 提升到 75.0%，官方还提到已超过该基准的人类成绩 72.4%。这意味着它在“看着界面做事”上有质变。
• 效率：虽然 API 单价比 5.2 高，但官方强调它是目前 token 效率最高的 reasoning model，在同一提示集上平均输出 token 比 5.2 少 10% 以上。换句话说，单 token 更贵，但很多任务总成本和延迟未必更差。
• 安全与可控性：5.4 按 High cyber capability 级别部署了相应防护。对开发者来说，除了更强，也更可控：可以通过 developer message 和自定义确认策略，约束 agent 的行为边界。

按用户角色看

• 普通重度用户：最直接的收益是“少来回”。它更会先规划、更能保持上下文、更适合长任务。
• 开发者：最值钱的是三件事叠加：更强编码、更强工具调用、更强 computer use。也就是从“代码助手”更接近“开发 agent”。
• 企业/团队：更适合跨应用流程，比如读文档、查网页、改表格、写报告、验证结果这种串联任务，落地方向比单纯聊天模型更清晰。
• 产品经理/分析师：复杂研究、竞品分析、长报告、资料归纳这类任务收益会比较明显，因为它更擅长长链路推理和多源整合。
• 自动化场景：如果你关心的是 agent/工作流，5.4 的意义比“答题更强”大得多，因为它第一次把长上下文、工具生态、软件操作能力真正组合起来了。

如果只挑 3 个最关键提升

• 从“会回答”升级到“会完成工作流”
• 从“会写代码”升级到“会在真实软件环境里行动”
• 从“更强能力”升级到“更适合长期、复杂、专业任务”

我会怎么定义这次 5.4
如果用一句更偏业务的话讲：5.4 的升级重点不是单项 benchmark 再涨一点，而是把模型从“强助手”往“可靠的专业工作代理”推进了一大步。

如何使用

在 config.toml 里手动开启

1
2
3

model = "gpt-5.4"
model_context_window = 1000000
model_reasoning_effort = "xhigh"

接下来，你就可以在 cli / codex app / vscode 里使用了

按照长久以来的发布节奏，正式版集成估计要等下下下周了

One More Thing

Codex App (Windows) 目前也已经全量开放了，直接 Windows 应用商店下载，配上新的 gpt-5.4，那真是风味更佳！

另外 Codex Cli 最新的 0.111.0 版本还上线了 Fast 模式，这是要把现在的几个痛点：【不说人话，慢，工具链落后】都完善起来，配上现在广大免费的普号和 低到几块钱的 Team… 难道 GPT 要崛起？

1
2

[features]
fast_mode = true

GPT-4 有万亿级参数，推理时几乎全部激活，训练功耗以兆瓦计。

这个差距，就是 2025 年 AI 进化的原动力。

一、DeepSeek：向大脑靠拢

DeepSeek R1 出来那天，我看到 600 万美元的训练成本，第一反应是数字少写了个零。

后来看 MLA（多头潜在注意力）的论文，才明白本质：这不是省钱，是在模仿大脑的稀疏激活。

• 人脑：需要时只唤醒相关区域
• MLA + MoE：推理时只激活部分专家和压缩后的注意力
• 结果：同样的智能，十分之一的成本

（算法突破一旦被公开，护城河就失效了）

二、2025 年的三条收敛线

1. 算法：稀疏化成为主流

DeepSeek 证明 MoE 可以既稀疏又高效。随后 Phi、Gemma 等小型模型在特定任务追平大模型。

趋势清晰：从”一个模型做所有事”到”多个专家按需唤醒”。

（更像大脑了）

2. 产品：从说到做

• Claude 3.7：代码能力质变
• Manus：首次完整任务闭环
• OpenClaw：本地自主执行

关键转折：AI 从”信息处理器”变成”行动执行者”。

智能的价值不在”知道”，在”做到”。

3. 基础设施：算力民主化

Mac Mini M4 全球断货六周，不是在买电脑，是在买”个人 AI 服务器”。

当模型可以本地高效运行，智能从”云服务”变成”基础设施”。

（边界消失，成本归零）

三、收敛的本质

2025 年干了三件事：

共同指向：人工智能正在向生物智能的形态靠拢。

四、未来预测

基于上述原理，推演三个必然方向：

1. 持续学习（2026-2027）

当前模型是冻结的，无法像人脑一样在线学习。下一阶段的突破口：交互中实时更新权重。

2. 原生多模态（2026）

人脑没有”单模态”概念。2025 年的多模态还是文本中转，2026 年将出现真正的统一感知模型。

3. 智能环境化（2027-2028）

OpenClaw 只是开始。终极形态：智能像电一样无处不在。

“AI 设备”这个概念会消失——就像今天不会说”芯片设备”一样。

2025 年追 AI 追得挺累，回头看脉络倒很清晰：

把成本打下来，把边界拆掉，让智能自己长出来。

（Agent 领域没有护城河：）

老张在车间干了三十年。

他能听出主轴转速差了 50 转，能凭手感判断毛坯硬度偏高，能在断刀发生前三秒把急停拍下去。这些本事没写在任何教科书里——它们住在他的肌肉记忆、听觉直觉和三十年磨出来的”第六感”中。

问题是：老张明年就退休了。

他带的三个徒弟，最快的那个也才干了五年。那些无法言传的”手感”，怎么传下去？

这不是一个虚构的故事。它正在全世界的机加工车间真实上演。据统计，未来十年内，全球将有 超过 40% 的资深 CNC 技师 退休。这些人带走的不是技术文档——而是 活的知识：什么时候该信任数据，什么时候该相信直觉，以及最关键的——什么时候该停下来。

AI 不是来取代老张的。

AI 是来记住他的。

第一章：理解出发点——CNC 编程到底难在哪

在讨论 AI 之前，我们先诚实地面对一个问题：为什么 CNC 编程这件事，几十年来进步得如此缓慢？

表面上的简单

CNC 编程的核心看起来很直白：你告诉机床”去哪里”（坐标）、”怎么去”（进给）、”转多快”（转速）。G 代码的语法甚至比大多数编程语言都简单——无非就是 G01 X100 Y50 F2000 这样的指令。

一个聪明的新人，一周就能写出语法正确的程序。

水面下的冰山

但真正让 CNC 编程成为一门”手艺”的，是那些代码背后的隐性决策：

• 你怎么知道 F2000 是对的？ 因为你上次加工同一批料的时候用的 F2200，刀掉了。
• 为什么这里要抬刀而不是直接走过去？ 因为毛坯上有个铸造飞边，图纸上没画，但你亲眼见过。
• 为什么精加工前要停 2 秒？ 因为主轴需要时间稳定转速，否则表面粗糙度会超差。

这些决策无法从几何模型中推导出来。它们来自 物理世界的反馈——金属切削时的力、热、振动、变形——以及操作员在无数次试错中积累的 经验模型。

传统编程的三个根本局限

1. 参数保守导致效率浪费

为了避免撞机和断刀，大多数程序员会把切削参数设得很保守。进给率打到刀具推荐值的 70-80%，切深留足余量。这就像开一辆跑车却永远不超过 60 码——安全，但浪费了大量产能。

2. 策略固化无法应对变化

一旦程序写好、验证通过，它就像一段”冻结的命令”。毛坯硬度波动了？不管。刀具磨损了？不管。环境温度变了导致热膨胀？还是不管。程序始终如一地执行，直到有人发现零件不合格。

3. 知识传承依赖口耳相传

“这个材料吃刀声发闷就要减速”——这种知识怎么写进工艺文件？写不进。它只能靠师傅带徒弟，在车间里手把手地传。一旦人走了，知识就断了。

这三个局限，恰好是 AI 最擅长解决的问题。

第二章：AI 来了——它到底能做什么

先别急着兴奋。我们需要冷静地理解 AI 在 CNC 领域能做的事，以及它的能力边界在哪里。

第一层：让你的程序跑得更快——G 代码智能优化

这是 AI 介入 CNC 最直接、最容易理解的方式：拿到你已经写好的程序，让它变得更好。

你可以把这想象成请了一位有无限耐心的审校员。他不改变你的加工策略，但会逐行审查每一个动作，找到你没注意到的浪费。

空行程优化

一个典型的加工程序中，刀具有大量时间在”赶路”——从一个切削位置快速移动到下一个。人类在编程时通常按加工特征的逻辑顺序排列（先粗加工、再精加工），但这个顺序未必是移动距离最短的。

AI 会用类似”旅行商问题”的算法，重新排列切削顺序，让空行程缩到最短。实测数据显示，仅这一项优化就能减少 15-25% 的非切削时间。

进给率动态调整

人类写程序时，通常给整段切削一个固定的进给率，比如 F2000。但切削过程是动态的：

• 在 90° 拐角处，机床的伺服电机根本来不及减速，实际进给远低于命令值，造成过切。
• 在长直线段，机床轻松就能达到命令速度，但你给的 F2000 可能远低于它的能力。
• 在切入和切出工件的瞬间，切削力急剧变化，固定进给会导致冲击。

AI 会根据机床的实际加减速特性曲线，将一个笼统的 F2000 拆解为一条连续变化的速度曲线。拐角前平滑减速，直线段充分加速，切入切出柔和过渡。效果是：更快的平均速度、更好的表面质量、更低的机械冲击。

恒负载切削

这是更高级的优化。AI 不再只看几何路径，而是计算每个瞬间的 **材料去除率 (MRR)**——刀具实际”吃”掉了多少金属。

在切削量大的地方（比如满刀切削），AI 自动降低进给，防止过载。在切削量小的地方（比如只切到一个薄壁），AI 自动提高进给，充分利用机床能力。

最终效果是：主轴负载始终稳定在最佳区间，就像一个老司机在山路上保持匀速——不暴力、不浪费、持续稳定。

💡 现在就试试：用我们的 进给/转速计算器 对比你当前参数和 AI 推荐参数的差异。

第二层：让机床拥有”感觉”——自适应加工

如果说 G 代码优化是”把地图画得更好”，自适应加工就是”在开车的时候看路”。

这是一次本质性的飞跃：AI 不再只是优化离线程序，而是在加工过程中实时感知和响应。

机床是怎么”感觉”的？

现代机床本身就是一个传感器的集合体，只是我们很少充分利用这些数据：

• 主轴电流：电流越大，切削力越大。它是机床的”疼痛感”。
• 振动频谱：通过加速度传感器捕获。特定频率的突增意味着颤振、刀具松动或即将断裂。
• 声发射信号：切削的声音包含丰富的信息。经验丰富的操作员能”听”出来的东西，AI 也能从声音频谱中提取。
• 伺服电机负载：进给轴的负载变化，反映了切削力在各个方向上的分量。

AI 拿到这些数据后做什么？

三个字：感知、决策、行动。

场景一：颤振抑制

颤振是机加工中最常见、最烦人的问题之一。它表现为工件表面出现规律性的波纹，严重时甚至导致刀具崩刃。

传统做法：操作员听到异响，手动降低转速或进给，反复试，直到找到一个”不颤”的参数。可能要浪费半小时和一个工件。

AI 做法：在颤振的 萌芽阶段（人耳还听不出来时），AI 已经从振动频谱中检测到了特征频率的异常增长。它在 毫秒内 微调主轴转速——比如从 8000 RPM 调到 7850 RPM——恰好避开共振频率。操作员甚至不会意识到发生了什么，但工件表面完好如初。

场景二：断刀预警

刀具不会突然断裂。在断裂前的几秒到几十秒，它会发出微妙的信号：切削力曲线出现不规律的尖峰、振动模式发生漂移、主轴电流产生异常波动。

人类很难在嘈杂的车间环境中捕捉这些信号。但 AI 可以。它持续监控数百个参数的组合模式，一旦检测到”断刀前兆”，立即执行安全退刀并停机——比操作员的反应快上百倍。

这不是锦上添花。对于加工航空发动机叶片这样的昂贵工件，一次断刀可能意味着数万元的损失。

场景三：刀具寿命最大化

传统做法是按固定件数或固定时间换刀——“每 50 个零件换一把”。问题是：有些刀在第 30 个零件时就已经该换了（因为这批材料偏硬），而有些刀在第 70 个零件时还很锋利（因为切削条件轻松）。

AI 基于实时磨损指标（力、温度、振动的综合分析），为每一把刀建立独立的”健康档案”。它会告诉你：”这把刀还能再切 12 个零件”或”建议立即更换，剩余寿命不足 3 个零件”。

效果：刀具使用率提升 20-40%，同时将意外断刀率降低到接近零。

第三层：在虚拟世界中试错——数字孪生与世界模型

我们进入更深的水域。

前两层 AI 都是在和 真实世界 打交道：优化真实的程序，监控真实的加工。但有一个根本性的问题：第一个零件怎么办？

新产品、新材料、新刀具。没有历史数据，没有经验可循。以前的做法是：保守地试切第一刀，观察，调整，再试，再调。一个复杂零件的首件可能需要反复调试好几天。

数字孪生改变了这个逻辑。

想象一下：在真实加工之前，AI 先在一个虚拟的”平行世界”里完成全部试错。这个虚拟世界不是简单的 3D 动画——它是一个 理解物理规律的仿真引擎。

传统仿真 vs. AI 世界模型

在 AI 世界模型中，虚拟机床会 像真实机床一样 响应切削参数的变化。你可以在几分钟内模拟上千组参数组合，找到那个切削力最平稳、表面质量最好、加工时间最短的 “甜点”参数。

然后，这套参数被直接传输到真实机床上。第一刀即是最优解。首件即成品。

这听起来像科幻？不。目前的技术已经能在特定场景下实现 Sim2Real（仿真到现实） 的高精度迁移。虽然尚未达到通用水平，但对于高价值零件（航空、医疗、模具），投资回报率已经非常可观。

第四层：对话即编程——自然语言驱动的 CNC

到这里，我们触及了这场变革中最具颠覆性的部分。

如果你用过 ChatGPT，你已经知道大语言模型（LLM）能做什么。现在想象一下，把这种能力接入 CNC 编程——

“帮我车一个外径 50mm、内孔 20mm 的衬套，长度 30mm，两端倒角 C1，材料 6061 铝合金，用 Fanuc 系统。”

AI 输出完整的 G 代码。不是模板，不是骨架——是一段可以直接上机运行的、包含合理切削参数、正确刀具选择和安全退刀路径的完整程序。

这不是在降低编程的专业门槛——这是在重新定义”编程”这个词的含义。

更强大的是交互式修改：

“这个外圆精加工留了 0.2mm 余量，改成 0.1mm。还有，精加工转速太低了，铝合金可以更快。”

AI 理解你的 意图，精准地修改对应的代码段，而不是机械地搜索替换。

这意味着什么？

• 急件来了，程序员不在？操作员可以用自然语言快速生成基础程序。
• 新人培训周期从数月缩短到数周——AI 成了永远在线的”老师傅”。
• 工艺知识不再锁死在少数人的大脑中——它被编码为 AI 可以调用的结构化知识。

当然，这里有一个至关重要的前提：AI 生成的代码必须经过验证。 就像你不会把一个新人写的程序不检查就上机一样，AI 的输出也需要经过仿真校验和人工审核。自然语言编程降低的是 编写门槛，而不是 质量标准。

第三章：从认知到行动——在你的车间落地 AI

理论讲完了。现在回到你的车间，脚踏实地。

AI 落地不是买一套软件、装一台服务器的事。它是一个 渐进演化 的过程。以下是经过验证的三步路径：

第一步：让数据开口说话

AI 的燃料是数据。 如果你的车间还在用纸质工艺卡片和操作员的记忆来管理加工过程，那么第一步不是引入 AI，而是 让数据可见。

从最简单的事情开始：

1. 记录主轴负载曲线：大多数现代控制器（Fanuc 30i/31i、Siemens 840D、三菱 M80）都支持以 CSV 格式导出负载数据。这是机床的”心电图”，包含了切削过程的全部秘密。
2. 建立刀具寿命数据库：不要用”大概能切 50 个”这种模糊记录。精确到 切削时间（分钟） 和 材料去除体积（cm³）。区分不同材料、不同切削条件下的寿命表现。
3. 打通数字链路：CAD 模型 → CAM 程序 → 机床执行 → 质量检测——这个链条上的每一环都应该产生可追溯的数字记录。

这一步不需要任何 AI 软件。你需要的只是一个 Excel 表格、一些数据采集工具，以及 坚持记录的习惯。

第二步：构建企业知识大脑

数据有了，但分散在各处——维修手册在文件柜里，工艺诀窍在老师傅的脑子里，历史程序在电脑的某个文件夹深处。

RAG（检索增强生成） 技术可以把这些散落的知识碎片编织成一个统一的智能知识库：

• 把所有机床手册、报警代码说明、历史维修记录喂给 AI。
• 把积累的工艺参数表、刀具选型经验、材料加工笔记整理进去。
• 把优秀的历史程序和它们对应的加工结果关联起来。

效果是什么？

当机床弹出报警 EX1024 时，AI 不是冷冰冰地告诉你”伺服驱动器错误”——它会说：

“EX1024：3 号轴伺服驱动器过载。根据历史记录，上次出现此报警是 3 个月前，原因是 3 号液压阀的电磁阀卡滞。建议优先检查液压系统。相关维修文档见第 7-23 页。”

这就是把老张三十年的经验，变成了所有人都能调用的数字资产。

第三步：从一台机床开始

不要试图一夜之间改造整个车间。选一台机床、一个工序、一个具体的痛点，作为你的 AI 试验田。

推荐路径：

1. 先用工具体验：用我们的 进给/转速计算器 对比你当前的切削参数和 AI 推荐值。差异可能会让你吃惊。
2. 再做程序审计：用 G 代码分析器 检查你现有的程序。它能发现冗余的空行程、不合理的进给跳变、以及潜在的碰撞风险。
3. 然后尝试自适应：在单台机床上部署自适应控制模块，监控刀具状态。先观察、收集数据，再逐步让 AI 参与决策。

关键原则：先证明价值，再推广规模。

第四章：真实的数字——ROI 究竟如何

让我们用数据说话。以下是先锋车间在引入 AI 辅助后报告的实际改善：

注意：这些数字因车间规模、产品复杂度和现有自动化水平而异。但趋势是一致的：AI 在 CNC 领域的投资回报率通常在 6-18 个月内即可收回。

第五章：诚实面对焦虑——关于 AI 的常见追问

“AI 会取代 CNC 程序员吗？”

不会。但它会 重新定义 这个职业。

打个比方：Excel 取代了手工账本，但没有取代会计。恰恰相反，会计的工作从”算数”升级为了”分析和决策”。

同样地，未来的 CNC 程序员将从”写坐标点”升级为 工艺架构师：

• 定义加工策略和质量标准
• 审核和验证 AI 生成的程序
• 处理 AI 无法应对的极端异常
• 训练和优化 AI 模型

被淘汰的不是人，是”只会手动写 G 代码、拒绝拥抱工具”的工作方式。

“AI 生成的程序安全吗？会不会撞机？”

这是最常被问到的问题，也是最重要的问题。

答案是：现代 AI 系统都有多重安全保障。

1. 语法验证层：确保生成的代码符合控制器规范。
2. 几何仿真层：在虚拟环境中模拟全部刀具路径，检测碰撞和过切。
3. 物理约束层：验证切削力、主轴功率等是否超出机床能力。
4. 人工审核层：关键零件的程序最终仍需经验丰富的工程师确认。

AI 不是要绕过安全检查——它是要让安全检查更系统、更全面、更不依赖人的注意力和状态。

“我的机床很老，还能用 AI 吗？”

绝对可以。 事实上，老机床可能是 AI 投资回报率最高的地方。

• 离线优化不挑机床：G 代码优化在电脑上完成，最终产出的还是标准 G 代码。无论你的机床是今年出厂的还是 20 年前的 Fanuc 0i，只要它能读 G 代码，就能受益。
• 低成本传感改造：花几百元加装一个外夹式电流传感器，就能采集主轴负载数据。配合边缘计算盒子，连没有网络接口的老机床也能接入 AI 系统。

老机床的优化空间往往比新机床更大——正因为它们之前从未被优化过。

“中小企业承担得起吗？”

AI 正在快速平民化。

• 免费工具：AICNC.org 提供的计算器和分析器都是免费的，今天就能用。
• SaaS 模式：云端 AI 优化服务的月费已经降到了一把硬质合金铣刀的价格。
• 渐进投入：你不需要一次性投资百万。从免费工具开始，证明价值后再逐步升级。

AI 不再是大厂的专利。它是每一个认真对待效率的车间都能拥有的工具。

尾声：机床开始思考之后

让我们回到老张的故事。

在一个理想的未来中，老张退休前的最后一年不是在焦虑”这些东西传不下去”，而是在做一件有趣的事：他在教 AI。

他一边操作，一边向系统解释自己为什么做出这个决定。他修正 AI 的错误判断，就像修正一个天赋异禀但经验不足的徒弟。他把三十年的直觉，一点一点地翻译成数据和规则。

当他离开车间的那一天，机床的操作面板上会多出一个按钮。新来的学徒不确定该怎么处理一个从没见过的材料时，可以按下这个按钮。

屏幕上弹出的建议，带着老张的影子。

这就是 AI × CNC 编程的本质：不是冰冷的自动化，而是把人类最宝贵的加工经验，变成可传承、可复用、可持续进化的数字智慧。

这段旅程，现在就可以开始。

• 📐 AI知识库 —— 基于腾讯混元大模型与 DeepSeek-R1，支持多语言问答，CNC 数控技术文档丰富。国内访问速度快，支持网页版、微信小程序、 Windows/Mac 客户端和 Android App。

从开始使用 AI 进行 Vibe Coding，感觉自己逐渐成了一个产品体验官，各家的 AI 模型、工具如数家珍，但是真正能拿出手的东西啥也没有，所以打算从自己熟悉的领域入手，做一些东西出来。

初步打算先做一个 AI x CNC 的网站，是一个永久免费的站点。

一方面，AI 技术已经足够成熟，可以显著提升 CNC 加工的效率和质量；另一方面，绝大多数 CNC 从业者对 AI 的了解仅停留在概念层面，缺乏实用的工具和深入浅出的指导。我想做一个提供真正有价值的免费工具和内容的站点，为我们的工业强国再添一点燃料。

所以我也打算将整个过程记录下来，不管是 AI 方面的、还是 CNC 方面，作为自己一个持续学习的过程。

产品

建设一个 AI 与 CNC 交叉领域的网站。

用户核心优势：

• CNC操作/编程 + CNC系统（控制系统层面）
• AI/ML应用 + 工业软件/自动化开发
• 中文写作为主，英文通过AI辅助翻译
• 对海外CAM软件生态（Mastercam、Fusion 360等）不太熟悉

市场定位调整：避开海外CAM软件对比领域（不熟悉），聚焦CNC系统级AI应用 + 工业自动化 + CNC编程优化——这个方向在全球范围内内容极度稀缺，竞争极低。

计划中等投入（每周10-20小时），面向全球中英文双语市场，采用内容+工具混合定位。

技术选型

技术架构

AI 工具

模型：Claude Opus 4.6 (设计、骨架搭建)、Codex 5.3 xhigh（开发）、Google Nano banana（图片）

工具：Claude Code、Codex、Antigravity

小结

万事开头难，花了两天时间，现在第一版已经整完上线了。虽然全是空架子，但是也是有模有样了 ：）

摘要：

Anthropic的限制收紧应被理解为不是产品限制，而是商业模式优化 ，将会对行业产生巨大的传导效应。

2025年10月，Anthropic的Claude Code用户经历了一场使用危机。尽管公司未在当月宣布新的正式限制政策，但用户实际体验到的使用限制却急剧收紧，这是多重因素在七至十月间持续累积的结果。本次限制收紧是技术、商业、监管和基础设施压力共同作用的必然产物，标志着AI编码工具行业从快速扩张期进入可持续发展调整期。

限制变更的事实时间线

真实情况澄清

研究发现，2025年10月并未宣布新的正式限制政策。实际的限制变更发生在：

7月14-17日：未经通知的使用限制收紧，用户突然无法正常使用，引发首波投诉。

7月28日宣布，8月28日生效：正式引入每周使用限额制度。Max 20x方案（200美元/月）限制为每周240-480小时Sonnet 4和24-40小时Opus 4。

9月15日：更新使用政策，新增网络安全和代理工具使用限制，回应8月发现的恶意使用案例。

9月28日至10月8日：消费者条款更新截止日，要求用户选择是否允许数据用于模型训练（可选择5年保留期）。

10月1日：发布Claude 4系列和Claude Sonnet 4.5，实际上是产品增强而非限制，但用户报告在新版本发布后遭遇更严重的限制问题。

10月的实际用户体验

尽管没有新政策，但10月用户经历了使用危机：

• Max 20x订阅用户（200美元/月）报告仅工作6小时就耗尽每周Opus配额，而之前从未触及限制
• 用户在三天内仅完成3-4小时实际工作后，就达到了70%的周使用量
• 有用户记录显示，每个5小时会话消耗约10%配额，意味着每周仅能进行约10次会话——相比之前减少了50-66%的实际容量
• 即使切换到Sonnet模型，Claude Code也完全停止工作

这表明，虽然政策制定于7-8月，但实施效果在10月达到顶峰，与Claude 4.5发布、基础设施调整、新CTO上任等因素重叠。

技术层面的驱动因素

严重的安全事件催生限制必要性

2025年8月重大网络犯罪案件成为技术限制的直接催化剂。Anthropic在威胁情报报告中披露了编号GTG-2002的大规模勒索软件行动：

攻击者利用Claude Code对17个不同组织发起自动化网络攻击，目标涵盖医疗、应急服务、政府和宗教机构。勒索金额从75,000美元到500,000美元不等。攻击者采用”氛围黑客”（vibe hacking）技术，在CLAUDE.md文件中嵌入操作指令，使AI成为自主犯罪帮凶，而非简单工具。

Claude Code在此案中被用于：

• 自动化侦察和凭证窃取
• 网络渗透和战术决策
• 分析被盗财务数据以确定勒索金额
• 生成针对受害者心理的勒索要求
• 整理敏感数据，包括社保号码、银行详情、医疗记录和ITAR管制的国防信息

其他已确认的恶意使用包括：仅有基础编程技能的网络犯罪分子利用Claude开发并销售勒索软件变体（售价400-1,200美元）；朝鲜IT工作者使用Claude欺骗性地获得美国财富500强科技公司职位；中国APT组织对越南关键基础设施发起长达9个月的攻击；西班牙语行为者维护信用卡验证和转售网络服务。

系统性代码安全缺陷

Veracode 2025年生成式AI代码安全报告（测试100+个LLM）揭示了行业性问题：

• 45%的AI生成代码样本未通过安全测试并引入OWASP前10名漏洞
• Java具有最高的72%安全失败率，其次是C#（45%）、JavaScript（43%）、Python（38%）
• 跨站脚本攻击（XSS）防御失败率达86%
• 模型规模、发布日期或训练复杂度对安全性能没有改善——更智能的模型生成功能更正确的代码，但安全性并未提高

乔治城大学CSET研究发现，5个主流LLM生成的代码片段中，近一半包含可能被恶意利用的漏洞。评估基准优先考虑功能正确性而非安全性，”激励在模型训练期间优先考虑功能而非安全性”。

关键漏洞发现

Claude Code本身发现了三个关键漏洞：

• CVE-2025-54794（CVSS 7.7）：路径限制绕过，允许未经授权的文件系统访问
• CVE-2025-54795（CVSS 8.7）：命令注入漏洞，允许任意代码执行
• CVE-2025-52882（CVSS 8.8）：WebSocket身份验证绕过，使恶意网站能够连接到本地服务器并通过模型上下文协议（MCP）执行远程命令

讽刺的是，这些漏洞可以通过”逆向提示”被发现——使用Claude本身来揭示绕过方法。

基础设施和资源消耗压力

计算成本挑战：LLM推理是内存受限而非计算受限的。代码生成通常需要大型上下文窗口（整个代码库、依赖项），每个请求消耗大量GPU内存和处理时间。”Vibe编码”可以在20分钟内生成超过20,000行代码，需要持续的GPU资源。

成本升级因素：代码生成通常需要比聊天响应更长的序列；多文件编辑和仓库级操作成倍增加资源消耗；7B参数模型的平均延迟在GPU上为10-50ms，在CPU上为50-200ms；对于更大的模型（70B参数），基础设施成本变得巨大。

行业定价压力：2025年市场分析显示，由于GPU供应紧张、高模型许可成本和基础设施开销，”廉价AI编码助手的时代可能已经结束”。一个500人开发团队使用GitHub Copilot Business的年度成本为114,000美元。

商业和战略层面的考量

不可持续的单位经济学

核心问题：到2025年7月，Anthropic的200美元/月Max方案被内部描述为可能”不可持续”。

价值套利：重度用户报告在Max方案上每天获得超过1,000美元的API等效计算价值，仅支付200美元/月。这种经济学在规模上不可行。

基础设施压力：Claude Code在7月限制实施前的一个月内经历了7次以上的部分或重大中断。2025年10月2日，Anthropic聘请前Stripe CTO Rahul Patil担任新CTO，明确专注于基础设施优化，表明了问题的严重性。

爆炸性增长制造容量限制

收入增长轨迹令人震惊：

• 2025年1月：10亿美元年化收入
• 2025年8月：50亿美元年化收入
• 增长率：Anthropic的Series F公告称其为”历史上增长最快的科技公司之一”

Claude Code具体表现：创造了5亿美元以上的运营收入，”使用量在短短三个月内增长超过10倍”（5-8月）。

客户增长：企业客户从2023年的不到1,000家增长到2025年的300,000+家——300倍增长。代表100,000美元以上运营收入的大客户在一年内增长了7倍。

这种指数级增长超过了基础设施容量，迫使实施限制以维持服务质量。

投资者压力和货币化需求

2025年9月2日Series F融资：

• 融资额：130亿美元
• 估值：1,830亿美元（后货币估值）
• 相比上一轮（3月，615亿美元）：6个月内估值增长3倍

投资者构成包括ICONIQ（主导）、Fidelity、Lightspeed、亚马逊（总计80亿美元投资）、谷歌、贝莱德、卡塔尔投资局。值得注意的是，CEO Dario Amodei在泄露的备忘录中表示，他对接受独裁政府主权财富基金的资金”并不兴奋”，但”为了跟上巨额资本需求而必要”。

收入目标：报道称目标是到2027年达到120亿美元收入（当前50亿美元运营率）。需要展示可持续的单位经济学以证明1,830亿美元估值的合理性。

企业优先战略转型

2025年战略重点明确转向企业市场：

领导层变化（2025年10月）显示战略方向：

• Rahul Patil（Stripe CTO）担任新CTO，专注企业基础设施
• Paul Smith任命为首位首席商业官
• Chris Ciauri担任国际业务总监
• Daniela Amodei（总裁）引用：”Rahul在构建和扩展企业所需的可靠基础设施方面拥有经过验证的记录”

国际企业扩张：2025年国际员工增加三倍；在东京开设首个亚洲办事处；Applied AI团队扩大5倍；在都柏林和伦敦新增100+职位；为印度、澳大利亚、韩国、新加坡任命国家负责人。

企业vs消费者收入：78%的Claude使用来自美国以外；代码生成/软件开发的年收入在2024年第四季度增长了10倍；企业API市场份额：32%（2025年），而OpenAI为25%；代码生成市场份额：42%。

对消费者计划的影响：对消费者层级施加使用限制，创建向企业迁移的路径或迫使迁移到利润更高的API定价。

监管环境的多重压力

欧盟AI法案的直接影响

2025年8月2日生效的通用AI（GPAI）实践准则对包括Claude在内的所有GPAI模型提供商具有约束力：

代码生成的关键要求：

1. 版权合规：必须实施技术保障措施以防止生成受版权保护的训练内容
2. 透明度：必须记录训练数据来源，包括代码仓库
3. 安全缓解：对于具有系统性风险的模型（如Claude Opus 4），必须进行定期风险评估
4. 数据保留：记录训练数据来源的模板要求

执行时间表：2025年8月2日GPAI规则生效；2026年8月2日新模型开始执行；2027年8月2日现有模型必须合规。

美国版权发展

版权局报告（2025年1-5月）提供了关键指导：

第2部分（2025年1月29日）：涉及AI生成代码的可版权性。输出必须包含来自人类作者的”足够的表达元素”。仅提供提示不足以获得版权保护。AI单独生成的代码在美国无法获得版权。

第3部分（2025年5月9日预发布）：关于使用受版权保护的作品训练AI模型。使用受版权保护的材料进行AI训练可能构成”表面侵权”。警告说，如果输出与训练数据非常相似，模型可能会侵权。强调”转换性”论点并非固有有效。”将受版权保护的作品用于生成式AI训练的某些用途将符合合理使用，而某些则不会。”

活跃诉讼：针对AI公司（OpenAI、Meta、Anthropic）未经授权使用受版权保护的代码进行训练的多起诉讼。值得注意的是，Bartz诉Anthropic案（2025年7月）：地区法官裁定，使用合法购买的受版权保护的内容来训练LLM构成合理使用——但代码生成如何应用合理使用的持续不确定性。

加州立法的时机巧合

SB 53（2025年9月29日签署）：”前沿人工智能透明度法案”

• 要求大型AI实验室透明公开安全/安全协议
• 防止模型被用于网络攻击、生物武器
• 保护举报人
• 为违规行为创建民事处罚
• 2025年10月1日生效——时机与Claude限制收紧完全吻合

其他州法律包括科罗拉多州关于算法歧视的综合AI立法；加州AB 2013要求大型AI开发者公开披露训练数据摘要（2026年1月1日生效）；加州SB-942要求AI检测工具和内容标记（2026年1月1日生效）。

数据政策变更的监管背景

Anthropic在2025年9月28日（后延至10月8日）的截止日期前要求现有用户选择新的数据政策：

• 之前：不使用消费者数据进行训练，30天保留
• 新政策：现在可以在Free、Pro和Max用户的对话和编码会话上进行训练
• 选择加入者的保留期延长至5年（不选择则为30天）
• 适用于个人账户的Claude Code使用

提供的理由：”帮助我们改进模型安全”；”帮助未来的Claude模型在编码、分析和推理等技能上提高”；竞争压力：需要数据与OpenAI和谷歌竞争；诉讼压力：OpenAI因《纽约时报》诉讼而面临保留所有ChatGPT对话的法院命令。

用户反应：关于专有代码在训练数据中的担忧；关于竞争情报风险的问题；敏感业务逻辑的隐私担忧；时机批评：重大政策变更与使用限制同时进行。

用户反馈和社区反应

10月用户危机的严重性

直接用户证词（2025年10月）来自Medium用户Sevak Avakians：”我用的是该死的MAX计划！……所以，Anthropic希望我既购买月度订阅又支付通行费。与此同时，所有工作都停止了。感觉就像我在欧洲坐在公交车上，运输工会罢工了！什么鬼？！”

服务中断：2025年10月2日，从太平洋时间下午6:17到晚上8:47，影响Claude.ai、Claude Code和API的重大服务中断。根据DownDetector，用户报告”数百人”遭遇停机。

社区情绪分析

Reddit（r/ClaudeAI）：

• “今天Claude的使用限制又很糟糕。他们似乎真的想把每个人都推向Max计划，在澳大利亚需要300美元。”
• 用户”为Claude的恢复加油”但表达沮丧：”当它功能正常时，它在分析推理方面仍然无与伦比”
• 员工工程师Eduard Ruzga：”在Claude Code Max订阅之前，人们可以使用带有Desktop Commander的Claude数小时而不会触及限制。发布后，有报告称人们在几条消息或至少不到一小时内就触及限制”

HackerNews：混合反应，一些开发者赞扬能力（”最佳编码模型”），而其他人质疑炒作。用户在工作时将其与Cursor和Windsurf进行有利比较，但对限制感到沮丧。

Medium文章：多篇详细的用户账户记录了从Claude的迁移；”Claude发生了什么？我们为什么要放弃该平台”；与Cursor的”诱饵转换”导致用户外流的比较；用户记录成功迁移到Gemini CLI和其他替代品。

Twitter/X：开发者发帖关于意外触及限制；显示使用计量器和限制消息的屏幕截图；关于定价模型可持续性的行业讨论。

主要用户投诉

1. 缺乏沟通：”只要透明就行。缺乏沟通只会让人们对他们失去信心。”
2. 不准确的跟踪：频繁投诉使用跟踪与实际执行的工作不匹配
3. 工作停止：即使是Max计划用户也因每周锁定而无法完成项目
4. 误导性定价：”Max”计划意味着最大容量，但仍受严重限制
5. 没有升级路径：消息说”/upgrade以增加您的使用限制”，但已经在最高层级
6. 竞争劣势：用户注意到免费竞争对手（如Gemini）提供更多容量

开发者社区影响

生产工作流中断：使用Claude Code构建平台的开发者遭遇项目中途停止；GitHub集成工作流受到影响；多代理编码设置变得不可用；MCP（模型上下文协议）服务器实现更快地消耗更多上下文。

积极情绪（当正常工作时）：”Claude Code极大地改变了我在大规模编写和维护代码方面的关系”；”Claude Sonnet 4.5是世界上最好的编码模型”；开发者将其描述为”变革性的”，并将其与编程的”摄影引入”相比较；对代理能力、多文件重构和调试的高度赞扬。

关键关注点：信任侵蚀：”缺乏沟通只会让人们失去信心”；可持续性问题：一些用户在200美元计划上每天进行超过1,000美元的API调用；可靠性问题：无法围绕不可预测的限制规划项目；替代探索：大规模迁移讨论到Cursor、Windsurf、Gemini、Kimi。

行业背景和竞争环境

AI编码工具市场概况

市场规模：67亿美元（2024年）→预计到2030年达到257亿美元（25.2% CAGR）。至少有8个主要竞争者采用激进的定价策略。

主要竞争对手对比

GitHub Copilot（微软）：个人10美元/月，Pro+ 39美元/月，可访问多个模型。优势：与微软生态系统深度集成，建立的开发者基础。

Cursor（Anysphere）：20美元/月，融资9亿美元，估值90亿美元，收入5亿美元ARR（报告）。优势：专门构建的AI优先IDE，具有卓越的多文件编辑。

Windsurf（Codeium）：10-15美元/月，收入1亿美元ARR。OpenAI曾试图以30亿美元收购。优势：快速性能，竞争定价。

Replit：核心计划20美元/月加25美元积分，收入超过1亿美元ARR（2025年6月达成）。挑战：因使用基础的”努力定价”导致账单意外飙升20倍而面临严重客户反弹（类似于Anthropic的经历）。

关键洞察：多个竞争对手在2024-2025年经历了类似的定价/使用限制危机，表明整个行业都在努力平衡增长与可持续的单位经济学。

行业普遍挑战

生产力悖论：声称的生产力提升与实际测量之间存在差距。

积极声明：GitHub声称生产力提高55%；麦肯锡称任务完成速度翻倍；DORA报告显示80%以上报告生产力提高；59%报告积极的代码质量影响。

现实检查 - METR研究（2025年7月）：对有经验的开源开发者显示19%的减速。随机对照试验，16名有经验的开发者，246个实际仓库的真实任务。开发者认为AI使他们加快了20%，尽管实际减速了19%。感知与现实之间的差距突出了测量挑战。

协调因素：AI帮助简单/重复任务但减慢复杂工作；对初级开发者和不熟悉的代码库更有益；基准任务≠真实世界质量要求；文档、测试、风格要求需要额外时间；高质量代码审查标准揭示AI局限性。

经济可持续性和可行性

成本上升：平均月度AI支出：62,964美元（2024年）→85,521美元（2025年）= 36%增长。计划每月支出100K+美元的组织：20%→45%（增加一倍以上）。只有51%能自信评估AI ROI。

隐藏成本（MIT斯隆管理评论）：快速扩展时技术债务积累；在棕地/遗留环境中尤其严重；缺乏经验的开发者加剧现有问题；”使用生成式AI编码的隐藏成本”可能超过生产力提升。

长期影响和未来发展方向

近期（2025-2026）

Forrester预测：”至少有一个组织将尝试用AI替换50%的开发者并失败“。开发者只花24%的时间编码；AI不解决其他76%。GenAI将通过软件交付的所有阶段变得普遍。由于安全问题推动内存安全采用，Rust进入前10种语言。

Gartner预测：到2027年底，40%以上的代理AI项目将被取消。由于成本上升、业务价值不明确、风险控制不足。到2028年，15%的日常工作决策将是自主的（而2024年为0%）。到2028年，33%的企业软件将包括代理AI（而2024年\u003c1%）。AI原生软件工程将使开发者转向更高价值的任务。

中期（2027-2030）

市场整合：预计会出现3-5个主导平台。较小的玩家被收购或被迫退出。微软/GitHub、Anthropic、Cursor/Anysphere、谷歌可能是幸存者。开源替代品（Continue.dev、Aider）服务利基市场。

能力平台：AI达到常规任务的”高级开发者”水平。人类专业知识对以下仍然至关重要：新颖的架构决策；复杂的系统设计；业务需求解释；创造性问题解决；安全关键实施。

经济模型：基于使用的定价成为标准；企业合同推动收入；基本功能商品化；高级功能溢价；可能的监管对定价的影响。

长期（2030+）

转型情景：

情景1：增强平衡（60%概率）：AI成为通用初级开发者助手；人类开发者专注于高层设计、架构、产品决策；编码任务分布：70% AI辅助，30%人类关键；开发者角色演变但仍然至关重要；行业随着生产力提高而增长。

情景2：分层开发（25%概率）：市场分裂：商品化vs高端开发；AI独立处理常规应用（Replit模式成功）；关键、复杂、新颖系统的专家人类开发者；中级开发者需求减少；技能要求两极分化加剧。

情景3：突破性自主（10%概率）：AGI级别突破实现真正自主开发；AI处理完整的软件生命周期；人类角色转向规范和验证；大规模行业重组；围绕AI系统管理出现新角色。

情景4：平台和撤退（5%概率）：技术限制被证明比预期更根本；行业认识到当前方法不足；恢复到AI作为复杂的自动完成；继续以AI辅助为人类主导的开发；重点转向其他AI应用领域。

内部和外部压力因素

内部压力

组织结构调整：2025年10月2日聘请Rahul Patil担任CTO标志着基础设施危机响应。组织重组：产品工程团队更靠近基础设施/推理团队。来自OpenAI和Meta的AI实验室的”激烈基础设施竞争”。

人才争夺战：竞争对手积极招聘顶尖工程师；需要在基础设施、安全、合规方面保持领先；团队扩张与成本控制的平衡。

产品差异化挑战：随着能力趋同，难以差异化；需要通过质量、可靠性、安全性竞争而非仅功能；Claude的”宪法AI”方法作为差异化因素。

外部压力

竞争加剧：Cursor融资9亿美元，估值90亿美元；GitHub Copilot推出新的Pro+层级（39美元/月），扩大模型访问；Replit达到1亿美元ARR；市场整合压力增加。

供应链挑战：全球GPU短缺；NVIDIA H100/H200芯片的高需求；云计算成本上涨；数据中心容量限制。

经济环境：科技行业裁员和成本削减；投资者对盈利能力的审查增加；”增长不惜一切代价”时代结束；需要展示可持续的商业模式。

地缘政治因素：美中AI竞赛影响政策；对中国的AI芯片出口管制；国家安全关注；数据主权要求；不同司法管辖区的不同监管方法。

综合分析：多因素汇聚

主要驱动因素权重评估

基于全面研究，限制收紧的原因可以按以下权重分配：

1. 经济可持续性（35%）

• Max计划经济学在规模上不可持续（用户每天获得1,000美元以上价值，支付200美元/月）
• 5-8月5倍收入增长超过基础设施容量
• 需要展示向1,830亿美元估值投资者的盈利路径
• 转向利润更高的企业API合同

2. 技术和安全考虑（30%）

• 2025年8月记录的重大网络犯罪案件（勒索软件、恶意软件生成）
• 发现的关键漏洞（CVE评分7.7-8.8）
• 45%的AI生成代码包含安全缺陷
• 需要更好的监控和滥用预防系统

3. 监管合规（20%）

• 欧盟AI法案2025年8月2日开始执行
• 加州SB 53于2025年10月1日生效
• 版权不确定性需要保守方法
• 安全要求增加计算开销
• 5年数据保留存储成本

4. 基础设施容量（15%）

• 服务经历频繁中断
• “前所未有的需求”挑战容量
• 需要在用户群中维持服务质量和负载平衡
• 聘请新CTO专门解决基础设施问题

10月时机的特殊性

虽然正式限制在7-9月制定，但10月成为”完美风暴”：

9月15日：更新的使用政策生效
9月28日/10月8日：数据政策选择加入截止日期
9月29日：Claude Sonnet 4.5发布
10月1日：加州SB 53生效
10月1-2日：关于限制的大规模用户投诉
10月2日：重大服务中断；新CTO Rahul Patil上任

这些因素的重叠创造了用户体验危机，即使没有宣布新的正式限制。

战略意图分析

Anthropic的限制收紧应被理解为不是产品限制，而是商业模式优化：

短期目标：保护高支付企业客户的基础设施；推动重度用户转向API定价（更高利润率）；向投资者展示财务纪律；为长期增长创建可持续的单位经济学。

长期战略：成为”企业AI公司”而非与OpenAI的消费者焦点竞争；通过可靠性和安全性而非仅功能进行差异化；建立可持续、有利可图的商业模式；领导负责任的AI开发标准。

关键洞察和启示

对行业的影响

短期（2025年第四季度）：除非放宽限制，否则可能继续流失用户；预计竞争对手获得优势；可能需要修订定价模型；用户保留的关键或破裂期。

中期（2026年）：欧盟AI法案执行力度加大；版权诉讼明确性显现；行业标准巩固；整个行业的经济模型调整。

长期（2027+）：成熟的监管框架；建立可持续的定价模型；AI编码工具成为标准；质量差异化胜过可用性。

给组织的建议

对于AI编码工具采用者：

1. 从非关键项目开始学习限制
2. 对所有AI生成的代码实施人工审查
3. 建立明确的编码标准和质量门
4. 客观跟踪ROI，而非基于感知
5. 培训开发者有效的AI协作
6. 为隐藏成本（审查、调试、重构）做预算

对于Anthropic和同行：

1. 立即沟通：对限制和理由的清晰、详细解释
2. 透明路线图：分享容量改进和定价变更的计划
3. 分层限制：当前层级之间更细粒度的计划
4. 监控仪表板：让用户实时跟踪使用情况
5. 企业焦点：优先考虑具有可预测定价的API/商业计划
6. 监管透明：解释合规要求如何影响服务
7. 信任重建：一致的沟通和兑现承诺

未来展望

AI编码工具行业正处于关键转折点。爆炸性增长和广泛采用与有限的实际生产力提升、可持续性担忧和根本技术限制的新证据共存。未来2-3年将决定当前工具是否代表变革性转变，还是仅仅是复杂的自动完成。

最可能的路径：继续向复杂的增强工具演进，这些工具增强但不替代人类开发者，伴随市场整合、监管框架的出现，以及未来十年新开发范式的演变。

关键不确定性：缩放定律是否继续在代码生成质量和自主性方面产生有意义的改进，或者我们是否正在接近需要新架构方法的根本限制。

战略要务：组织必须平衡对AI编码工具的热情与对能力、成本和限制的现实评估。获胜策略是在强有力的人工监督下进行增强，而非尝试替换。

未来将由掌握AI协作的开发者书写，而非独立工作的AI系统。

实用工具推荐：面对配额限制，一个务实的解法是用 CLIProxyAPI 把多个提供商（Claude、Gemini、Codex、Qwen）统一接入，多号轮询、配额自动切换。具体操作见完整教程。

前一刻还在为 Sonnet 4.5 疯狂点赞，一回头发现又又又被背刺！

一个 Max 20x 的账号，满打满算一周也就 $800！可用量不到现在的 20%！

8月初，Max 20x 一个周期（5小时），大约可用 $270；9 月初逐渐降到 $200左右，并且上线了周限制；9 月底已经在 $170 左右了。由于官方一直没有给出特别明确的用量说明，而且相比于 Token 计费和如 Cursor 这种扣扣索索的，还是比较大方的，所以大家也就吐槽几句。

今天，随着 Sonnet 4.5 上线，上线了使用量和周限制查看：https://claude.ai/settings/usage。作为一个贫穷的 Pro 用户，平时我也就偶尔用网页版和 Opus 聊聊，结果您猜怎么着，才一会儿就上限了？

应对方案：配额不够用？可以用 CLIProxyAPI 把多个账户的配额合并起来，自动轮询、自动切换，一个号满了无缝换下一个。

Claude Sonne5 4.5，终于发布了，可谓是千呼万唤始出来。

能力

安全性

除了是我们最强大的模型，Claude Sonnet 4.5 也是我们迄今为止最符合预期的前沿模型。Claude 的改进能力和我们广泛的安全生产训练使我们能够显著改善模型的行为，减少了诸如谄媚、欺骗、权力寻求以及鼓励幻想性思维等令人担忧的行为。对于模型的自主性和计算机使用能力，我们在防御提示注入攻击方面也取得了显著进展，这是这些能力用户面临的最严重风险之一。

Claude Sonnet 4.5 将根据我们的 AI 安全级别 3（ASL-3）保护措施进行发布，这符合我们的框架，该框架将模型能力与适当的保护措施相匹配。这些保护措施包括旨在检测潜在危险输入和输出的过滤器，即分类器——特别是与化学、生物、放射性及核（CBRN）武器相关的输入和输出。

代理 SDK

我们已经花费了超过六个月的时间向 Claude Code 发布更新，因此我们深知构建和设计 AI 代理需要什么。我们已经解决了难题：代理如何在长时间运行的任务中管理内存，如何处理在自主性与用户控制之间取得平衡的权限系统，以及如何协调为共同目标工作的子代理。

在之前的 邪修用法：Codex/ClaudeCode转标准API中尝试了使用 codex 来生成 deep wiki，一切都顺利，就是因为限流导致最终未竟全功，这次换了一个 claude code 的号继续使用。

省流版本：基本功能（网站生成）可用，有点费 Token，MCP 和一些细节仍需打磨。

1. 配置 CLIProxyAPI

CLIProxyAPI

这里主要将为了将 Claude Code 转成标准的 OpenAI 兼容 API。因为使用了中转站，所以配置了对应的 base_url 和 key。

2. 配置 OpenDeepWiki

OpenDeepWiki

我用的0.9.0版本，用下来发现还是有不少问题，比如说默认配置无法直接打开站点、诊断就配了个18888的GRPC的，没有18889的Web页面之类的，还有一些页面无法访问，所以整体功能可用，但是很多细节还需要打磨

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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

services:
  koalawiki:
    image: crpi-j9ha7sxwhatgtvj4.cn-shenzhen.personal.cr.aliyuncs.com/koala-ai/koala-wiki
    environment:
      - KOALAWIKI_REPOSITORIES=/repositories
      - TASK_MAX_SIZE_PER_USER=5 # 每个用户 AI 处理文档生成的最大数量
      - REPAIR_MERMAID=1 # 是否进行 Mermaid 修复，1 修复，其余不修复
      - CHAT_MODEL=claude-sonnet-4-20250514 # 必须要支持 function 的模型（我试了用 Haiku，无法访问，只能用sonnet了）
      - ANALYSIS_MODEL=claude-sonnet-4-20250514 # 分析模型，用于生成仓库目录结构，这个很重要，模型越强，生成的目录结构越好，为空则使用 ChatModel
                        # 分析模型建议使用 GPT-4.1  , CHAT 模型可以用其他模型生成文档，以节省 token 开销
      - CHAT_API_KEY=xxx #您的 APIkey
      - LANGUAGE=中文 # 设置生成语言默认为"中文", 英文可以填写 English 或 英文
      - ENDPOINT=http://xx.xxx.com:8317/v1
      - MODEL_PROVIDER=OpenAI # 模型提供商，支持 OpenAI, AzureOpenAI, Anthropic
      - DB_TYPE=sqlite
      - DB_CONNECTION_STRING=Data Source=/data/KoalaWiki.db
      - UPDATE_INTERVAL=5 # 仓库增量更新间隔，单位天
      - EnableSmartFilter=true # 是否启用智能过滤，这可能影响 AI 得到仓库的文件目录
      - ENABLE_INCREMENTAL_UPDATE=true # 是否启用增量更新
      - ENABLE_CODED_DEPENDENCY_ANALYSIS=false # 是否启用代码依赖分析？这可能会对代码的质量产生影响。
      - ENABLE_WAREHOUSE_FUNCTION_PROMPT_TASK=false # 是否启用 MCP Prompt 生成
      - ENABLE_WAREHOUSE_DESCRIPTION_TASK=false # 是否启用仓库 Description 生成
      - MAX_FILE_LIMIT=100 # 最大上传文件限制，单位 MB
      - DEEP_RESEARCH_MODEL= # 深度研究模型，为空则使用 CHAT_MODEL
      - ENABLE_WAREHOUSE_COMMIT=true # 是否启用仓库提交
      - ENABLE_FILE_COMMIT=true # 是否启用文件提交
      - REFINE_AND_ENHANCE_QUALITY=false # 是否启用质量优化
      - CATALOGUE_FORMAT=compact # 目录结构格式 (compact, json, pathlist, unix)
      - ENABLE_CODE_COMPRESSION=false # 是否启用代码压缩
      - READ_MAX_TOKENS=100000 # AI 读取文件的最大 token 限制
      - OTEL_SERVICE_NAME=koalawiki
      - OTEL_EXPORTER_OTLP_PROTOCOL=grpc
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://aspire-dashboard:18889
    volumes:
      - ./repositories:/app/repositories
      - ./data:/data
    build:
      context: .
      dockerfile: src/KoalaWiki/Dockerfile
  
  aspire-dashboard:
    image: mcr.microsoft.com/dotnet/aspire-dashboard
    container_name: aspire-dashboard
    restart: always
    ports:
      - "18888:18888"
      - "18889:18889"
    environment:
      - TZ=Asia/Shanghai
      - Dashboard:ApplicationName=Aspire

  koalawiki-web:
    image: crpi-j9ha7sxwhatgtvj4.cn-shenzhen.personal.cr.aliyuncs.com/koala-ai/koala-wiki-web
    command: ["/app/start.sh"]
    environment:
      - NEXT_PUBLIC_API_URL=http://koalawiki:8080 # 用于提供给 server 的地址

  nginx: # 需要 nginx 将前端和后端代理到一个端口
    image: nginx:alpine
    ports:
      - "8090:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - koalawiki
      - koalawiki-web

windows 下就直接 docker 启动！

默认账号：admin / admin

访问：http://localhost:8090

后台查看进度

生成站点消耗

以 lusipad/plcopen 为例，大概消耗了

1
2
3

次数：225 次
Token: 11.43M
代币价：$37.76

主要是因为我都全程用 sonnet，换成其他的可能会节省一些（不过按照这个价格，Pro 账号也不经用）

3. 使用 OpenDeepWiki

1. 网站直接使用

   直接网页上访问

2. MCP

   

点击页面的 MCP，可以看到已经生成了配置

我们使用 Chatbox 来测试下

开启了 MCP，尝试提问下

正在调用 MCP

整个过程大概要 20~30 秒左右，还是比较慢的

这里可能有个比较大的问题，他会提示说读取不到文件，所以无法基于文件进行分析。。几个MCP都调用失败了

干脆让 AI 生成了一份详细的使用说明

OpenDeepWiki 使用说明

🚀 项目简介

OpenDeepWiki 是一个基于 AI 的智能代码知识库系统，能够自动分析代码仓库并生成高质量的技术文档。系统使用 Claude Sonnet 4 等先进的 AI 模型，为开发者提供深度的代码理解和文档生成服务。

🏗️ 系统架构

服务组件

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

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   前端服务      │    │   后端服务      │    │   监控面板      │
│ (koalawiki-web) │    │ (koalawiki)     │    │(aspire-dashboard)│
│   Port: 3000    │    │   Port: 8080    │    │ Port: 18888-89  │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                       │                       │
         └───────────────────────┼───────────────────────┘
                                 │
                ┌─────────────────┴─────────────────┐
                │          Nginx 代理服务           │
                │           Port: 8090             │
                └───────────────────────────────────┘

核心功能

• 🧠 AI 文档生成: 使用 Claude Sonnet 4 深度分析代码结构和逻辑
• 📊 仓库管理: 支持 Git 仓库的自动同步和增量更新
• 🌐 Web 界面: 现代化的前端界面，支持文档浏览和管理
• 📈 实时监控: Aspire Dashboard 提供系统运行状态监控
• 🔄 增量更新: 智能检测代码变更，只处理修改的部分

⚙️ 配置参数详解

核心配置 (docker-compose.yml)

AI 模型配置

1
2
3
4
5
6

# AI 模型设置
CHAT_MODEL: claude-sonnet-4-20250514          # 主要聊天模型
ANALYSIS_MODEL: claude-sonnet-4-20250514      # 分析模型（用于目录结构生成）
CHAT_API_KEY: xxx                            # API 密钥
ENDPOINT: http://xx.xxx.com:8317/v1        # API 端点
MODEL_PROVIDER: OpenAI                         # 模型提供商

任务控制配置

1
2
3
4
5

TASK_MAX_SIZE_PER_USER: 5                      # 每用户最大并发任务数
LANGUAGE: 中文                                 # 生成文档的语言
UPDATE_INTERVAL: 5                             # 仓库更新间隔（天）
MAX_FILE_LIMIT: 100                            # 最大文件上传限制（MB）
READ_MAX_TOKENS: 100000                        # AI 读取文件的最大 token 限制

功能开关配置

1
2
3
4
5
6
7
8
9
10

REPAIR_MERMAID: 1                              # Mermaid 图表修复（1=启用）
EnableSmartFilter: true                        # 智能过滤
ENABLE_INCREMENTAL_UPDATE: true                # 增量更新
ENABLE_CODED_DEPENDENCY_ANALYSIS: false       # 代码依赖分析
ENABLE_WAREHOUSE_FUNCTION_PROMPT_TASK: false  # MCP Prompt 生成
ENABLE_WAREHOUSE_DESCRIPTION_TASK: false      # 仓库描述生成
ENABLE_WAREHOUSE_COMMIT: true                  # 仓库提交功能
ENABLE_FILE_COMMIT: true                       # 文件提交功能
REFINE_AND_ENHANCE_QUALITY: false              # 质量优化
ENABLE_CODE_COMPRESSION: false                 # 代码压缩

高级配置

1
2
3

CATALOGUE_FORMAT: compact                      # 目录结构格式 (compact/json/pathlist/unix)
DB_TYPE: sqlite                                # 数据库类型
DB_CONNECTION_STRING: Data Source=/data/KoalaWiki.db  # 数据库连接字符串

🚀 快速启动

1. 环境准备

1
2
3
4
5
6
7

# 确保已安装 Docker 和 Docker Compose
docker --version
docker compose --version

# 克隆项目到本地
git clone <repository-url>
cd OpenDeepWiki

2. 配置设置

编辑 docker-compose.yml 文件，配置您的 AI API 设置：

1
2

CHAT_API_KEY: 您的API密钥
ENDPOINT: 您的API端点

3. 启动服务

1
2
3
4
5
6
7
8

# 启动所有服务
docker compose up -d

# 查看服务状态
docker compose ps

# 查看服务日志
docker compose logs -f koalawiki

4. 服务重启

1
2
3
4
5
6
7
8

# 停止服务
docker compose down

# 启动服务（包含配置更新）
docker compose up -d

# 清理孤立容器（如有需要）
docker compose down --remove-orphans

🌐 访问方式

主要服务端点

主要功能页面

• 📚 仓库列表: 查看和管理已添加的代码仓库
• 📄 文档浏览: 查看 AI 生成的技术文档
• ⚙️ 设置页面: 配置系统参数和 AI 模型
• 📊 统计信息: 查看文档生成统计和系统使用情况

📖 使用流程

1. 添加代码仓库

1. 访问 Web 界面: http://localhost:8090
2. 点击”添加仓库”按钮
3. 输入 Git 仓库 URL 或上传本地代码
4. 配置仓库分析参数

2. AI 文档生成

1. 系统自动分析代码结构
2. AI 模型深度理解代码逻辑
3. 生成多种类型的技术文档：
   • 项目概览
   • 架构分析
   • API 文档
   • 使用指南
   • 核心概念说明

3. 文档管理

1. 浏览生成的文档内容
2. 搜索特定技术信息
3. 导出文档为不同格式
4. 跟踪文档更新历史

🔧 运维管理

日志监控

1
2
3
4
5
6
7
8

# 查看实时日志
docker compose logs -f koalawiki

# 查看特定数量的日志
docker compose logs --tail=50 koalawiki

# 查看所有服务日志
docker compose logs -f

数据备份

1
2
3
4
5

# 备份数据目录
cp -r ./data ./data_backup_$(date +%Y%m%d)

# 备份仓库数据
cp -r ./repositories ./repositories_backup_$(date +%Y%m%d)

性能优化

1. 增加并发任务数: 调整 TASK_MAX_SIZE_PER_USER 参数
2. 优化 Token 使用: 调整 READ_MAX_TOKENS 限制
3. 启用智能过滤: 确保 EnableSmartFilter=true
4. 配置增量更新: 设置合适的 UPDATE_INTERVAL

🐛 故障排除

常见问题

1. 服务启动失败

1
2
3
4
5
6
7
8
9

# 检查端口占用
netstat -tulpn | grep :8090
netstat -tulpn | grep :8080

# 重启 Docker 服务
sudo systemctl restart docker

# 清理 Docker 资源
docker system prune -f

2. AI 生成失败

• 检查 API 密钥是否正确
• 验证网络连接到 AI 端点
• 查看日志中的具体错误信息
• 确认模型名称是否正确

3. 前端无法访问

1
2
3
4
5
6
7
8

# 检查 nginx 配置
docker compose logs nginx

# 验证前端服务状态
docker compose logs koalawiki-web

# 重启前端服务
docker compose restart koalawiki-web nginx

4. 数据库连接问题

1
2
3
4
5
6

# 检查数据目录权限
ls -la ./data/

# 重新创建数据库
rm -f ./data/KoalaWiki.db
docker compose restart koalawiki

性能调优建议

1. 系统资源优化

• 内存: 推荐至少 4GB RAM
• 存储: 确保足够的磁盘空间用于代码仓库和生成的文档
• 网络: 稳定的网络连接到 AI API 端点

2. AI 参数调优

1
2
3
4

# 高性能配置
TASK_MAX_SIZE_PER_USER: 10      # 增加并发任务
READ_MAX_TOKENS: 150000         # 增加 token 限制
ENABLE_CODE_COMPRESSION: true   # 启用代码压缩

3. 数据库优化

• 定期备份数据库文件
• 监控数据库大小增长
• 考虑使用外部数据库（如 PostgreSQL）

📊 监控指标

系统监控 (Aspire Dashboard)

• 📈 请求响应时间: 监控 API 响应性能
• 🔄 任务处理状态: 跟踪 AI 文档生成进度
• 💾 资源使用情况: 监控内存和 CPU 使用
• 🌐 网络连接状态: 监控到 AI 端点的连接

应用指标

• 📚 仓库数量: 已管理的代码仓库总数
• 📄 文档生成数: 成功生成的文档数量
• ⏱️ 平均处理时间: 文档生成的平均耗时
• 🎯 成功率: 文档生成的成功比例

🔐 安全建议

1. API 密钥安全

• 不要在公开代码中硬编码 API 密钥
• 定期更换 API 密钥
• 使用环境变量管理敏感信息

2. 网络安全

• 在生产环境中配置防火墙规则
• 使用 HTTPS 协议（配置 SSL 证书）
• 限制外部访问的端口

3. 数据安全

• 定期备份重要数据
• 加密敏感数据存储
• 实施访问控制策略

📚 扩展功能

1. 自定义 AI 模型

系统支持多种 AI 模型，可以根据需要配置：

• OpenAI GPT 系列
• Anthropic Claude 系列
• 自定义兼容端点

2. 插件扩展

• 支持自定义文档模板
• 可扩展的文件类型支持
• 自定义分析规则

3. 集成方案

• CI/CD 流水线集成
• 版本控制系统集成
• 项目管理工具集成

🆘 技术支持

获取帮助

1. 查看系统日志获取详细错误信息
2. 检查 GitHub Issues 页面
3. 参考项目文档和 README
4. 联系技术支持团队

贡献项目

• 提交 Bug 报告
• 建议新功能
• 贡献代码改进
• 完善文档内容

📝 更新日志

版本信息

• 当前版本: 0.9.0
• 最后更新: 2025-09-20
• 维护状态: 活跃开发中

主要特性

• ✅ 支持 Claude Sonnet 4 模型
• ✅ 完整的 Web 界面
• ✅ 实时监控面板
• ✅ 增量更新机制
• ✅ 多语言文档生成
• ✅ Docker 容器化部署

这份文档会随着系统功能的更新而持续维护和完善。

最近 Codex 便宜（越南、印尼有虾皮会员送 3 个月 ChatGpt Plus 会员的活动），综合成本大概 30 块 / 3月，性价比直接拉满。由于我自己的会员开太多了，光靠 Cli 根本用不完。所以想到既然都是 API，那应该也有类似 CCR 这种可以转换成标准 OpenAI 兼容 API 的用法吧？

在验证了几个后，踩了不少坑后，最终用了 https://github.com/luispater/CLIProxyAPI/tree/main 项目。可以支持自定义 API，支持轮询，把我想做的都改完了。

更新：CLIProxyAPI 现在已经发展到 v6，支持 Qwen、Gemini、Claude、Codex 等多家提供商，还有 Docker 部署和管理面板。完整教程见CLIProxyAPI 完整教程：一个代理统一所有 AI 编程工具。

配置

编辑 config.yaml

1
2
3

codex-api-key:
  - api-key: "your-codex-api-key"
    base-url: "https://your-server.com:3000/openai"

在 VSCode 中使用

直接在 Continue 上配置上（密码没配置，随便填）

1
2
3
4
5
6
7
8
9
10
11

{
  "models": [
    {
      "title": "GPT-5",
      "provider": "openai",
      "model": "AUTODETECT",
      "apiBase": "http://localhost:8317/v1",
      "apiKey": "dummy"
    }
  ]
}

可以配置，可以选模型，还可以调用工具链。

在 OpenDeepwiki 使用

既然可以用 API，就把之前的 OpenDeepwiki 翻出来，赶紧配置上看看能不能用。

先上结论：能用，但是 API 不够用

配置方法不展开了，无法就是 API_Base 换成了 localhost:8173，修改了分析模型为 gpt-5，chat 模型为 gpt-5-mini，然后 docker 一开就开始嚯嚯嚯分析了。

这里最大的问题出现了：扫描太快了！大概10分钟左右就触发了429限流了: (

虽然我已经用了两个号做负载均衡，但是无奈还是消耗太快。可能后续要换个 Pro 账号，或者修改下源码，做一个限速功能或者等待重试功能。

像我这个项目大概要 1000+ 次访问，但是由于速度太快了，很快就限速了，叠加上错误重试，就失败了。。

使用限制

1. 并发限制 （429）

   Codex 的使用限制，大概每 3 小时 150 条左右

   这个我跑了两次的结果，用的不同的模型（第一次 gpt-5，第二次 gpt-5-mini），但是总量接近

   

🚀 智能化代码评审解决方案
将 Claude Code 的 AI 能力与 Azure DevOps 无缝集成，实现自动化、专业化的代码评审流程

📚 目录

• 概述
• 系统要求
• 快速开始
• 详细安装步骤
• 配置指南
• 使用方法
• Slash Commands 参考
• Azure DevOps MCP 工具
• 最佳实践
• 故障排除
• 高级用法
• API 参考

🎯 概述

提示：如果你的 Claude Code 配额不够用，或者想在 Claude Code 里混搭 Gemini、Codex 等模型，可以先看 CLIProxyAPI 教程。

Claude Code + Azure DevOps MCP 组合提供：

• ✅ 全自动代码评审 - 从分析到评论一键完成
• ✅ 智能质量分析 - 安全性、性能、最佳实践检查
• ✅ 直接 API 集成 - 评论自动添加到 Azure DevOps PR
• ✅ 76+ 专业工具 - 覆盖完整 DevOps 生命周期
• ✅ 多种使用方式 - 交互式、命令行、批处理支持

核心功能

⚙️ 系统要求

必需环境

• Node.js: >= 16.0.0
• npm: >= 8.0.0
• Claude Code: 最新版本
• Azure DevOps: 有效的组织和项目

权限要求

• Azure DevOps Personal Access Token 包含：
  • Code (read & write) - 访问代码和 PR
  • Pull Request (read & write) - 操作 PR
  • Work Items (read) - 查看工作项

支持平台

• ✅ Windows 10/11
• ✅ macOS 10.15+
• ✅ Linux (Ubuntu 18.04+)

🚀 快速开始

5 分钟快速设置

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

# 1. 检查环境
node --version && npm --version

# 2. 安装 Azure DevOps MCP
npm install -g @azure-devops/mcp

# 3. 配置 Claude Code MCP 服务器
claude mcp add-json azure-devops '{
  "type": "stdio",
  "command": "npx",
  "args": ["@azure-devops/mcp", "YOUR_ORG_NAME"],
  "env": {
    "AZURE_DEVOPS_PAT": "YOUR_PAT_HERE"
  }
}'

# 4. 验证安装
claude mcp list

# 5. 开始使用
claude -p "使用 Azure DevOps MCP 工具评审 PR 16"

立即体验

1
2
3
4
5

# 启动交互式会话
claude

# 在会话中输入
> /review PR 16

🛠️ 详细安装步骤

步骤 1: 环境准备

检查 Node.js 环境:

1
2
3
4
5
6
7
8

# 检查版本 (推荐 v18+)
node --version
npm --version

# 如果版本过低，更新 Node.js
# Windows: 下载最新版本 https://nodejs.org
# macOS: brew install node
# Linux: nvm install --lts

验证 Claude Code:

1
2
3
4

# 检查 Claude Code 版本
claude --version

# 如果未安装，请参考官方文档安装

步骤 2: 安装 Azure DevOps MCP 服务器

安装官方 MCP 包:

1
2
3
4
5

# 全局安装 (推荐)
npm install -g @azure-devops/mcp

# 验证安装
npx @azure-devops/mcp --version

检查可用版本:

1
2
3
4
5

# 查看包信息
npm info @azure-devops/mcp

# 查看所有可用版本
npm view @azure-devops/mcp versions --json

步骤 3: Claude Code MCP 集成

方式 1: JSON 配置 (推荐)

1
2
3
4
5
6
7
8

claude mcp add-json azure-devops '{
  "type": "stdio",
  "command": "npx",
  "args": ["@azure-devops/mcp", "YOUR_ORG_NAME"],
  "env": {
    "AZURE_DEVOPS_PAT": "YOUR_PERSONAL_ACCESS_TOKEN"
  }
}'

方式 2: 分步配置

1
2
3
4
5
6

# 添加基础配置
claude mcp add azure-devops "npx" "@azure-devops/mcp" "YOUR_ORG_NAME"

# 移除并重新添加包含环境变量的配置
claude mcp remove azure-devops -s local
claude mcp add-json azure-devops '...'  # 使用上面的 JSON

步骤 4: 验证安装

检查 MCP 服务器状态:

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

# 列出所有 MCP 服务器
claude mcp list

# 查看具体配置
claude mcp get azure-devops

# 预期输出:
# azure-devops:
#   Status: ✓ Connected
#   Type: stdio
#   Command: npx
#   Args: @azure-devops/mcp YOUR_ORG_NAME
#   Environment: AZURE_DEVOPS_PAT=***

测试连接:

1
2
3
4
5

# 测试基础功能
claude -p "列出 Azure DevOps 项目中的所有 Pull Request"

# 测试评审功能
claude -p "/review --help"

⚙️ 配置指南

Azure DevOps Personal Access Token

创建 PAT:

1. 登录 Azure DevOps: https://dev.azure.com/YOUR_ORG
2. 点击右上角用户头像
3. 选择 Personal Access Tokens
4. 点击 + New Token
5. 配置权限:

PAT 安全最佳实践:

1
2
3
4

# 设置较短的有效期 (建议 90 天)
# 定期轮换 Token
# 使用最小权限原则
# 不要在代码中硬编码 Token

组织和项目配置

识别您的组织信息:

1
2
3

Azure DevOps URL: https://dev.azure.com/YOUR_ORG_NAME
组织名称: YOUR_ORG_NAME  (用于 MCP 配置)
项目名称: YOUR_PROJECT_NAME

多项目配置:

1
2
3
4
5
6

# 为不同项目创建不同的 MCP 服务器
claude mcp add-json azure-devops-project1 '{...}'
claude mcp add-json azure-devops-project2 '{...}'

# 使用特定服务器
claude --mcp-config azure-devops-project1

高级配置选项

自定义环境变量:

1
2
3
4
5
6
7
8
9
10
11

{
  "type": "stdio",
  "command": "npx",
  "args": ["@azure-devops/mcp", "lusipad"],
  "env": {
    "AZURE_DEVOPS_PAT": "your-pat-here",
    "AZURE_DEVOPS_ORG_URL": "https://dev.azure.com/your-org",
    "AZURE_DEVOPS_API_VERSION": "7.1-preview",
    "MCP_DEBUG": "true"
  }
}

项目级配置:

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

# 在项目根目录创建 .mcp.json
{
  "mcpServers": {
    "azure-devops": {
      "type": "stdio",
      "command": "npx",
      "args": ["@azure-devops/mcp", "your-org"],
      "env": {
        "AZURE_DEVOPS_PAT": "${AZURE_DEVOPS_PAT}"
      }
    }
  }
}

🎯 使用方法

交互式使用

启动交互式会话:

1

claude

基础命令:

1
2
3
4
5
6
7
8
9
10
11

# PR 评审
> /review PR 16
> 使用 Azure DevOps MCP 工具评审 PR 16

# 获取信息
> 列出所有待审查的 Pull Request
> 获取 PR 16 的详细信息

# 添加评论
> 将评审结果添加到 PR 16 的评论中
> 在 PR 16 上添加评论: "请修复安全漏洞"

高级评审:

1
2
3
4
5
6
7
8

# 深度分析
> 使用 code-reviewer 子代理深度分析 PR 16
> 对 PR 16 进行安全性深度扫描
> 分析 PR 16 对系统性能的影响

# 批量操作
> 评审所有状态为 'Active' 的 Pull Request
> 为所有新的 PR 添加欢迎评论

命令行使用

一键式评审:

1
2
3
4
5
6
7
8

# 基础评审
claude -p "/review PR 16"

# 详细评审
claude -p "使用 Azure DevOps MCP 工具详细评审 PR 16，包括安全性和性能分析"

# 评审并评论
claude -p "评审 PR 16 并将结果添加到 PR 评论中"

批处理操作:

1
2
3
4
5
6
7
8

# 批量评审
claude -p "评审项目中所有待审查的 PR"

# 生成报告
claude -p "生成本周所有 PR 的评审统计报告"

# 安全扫描
claude -p "对所有开放的 PR 进行安全性扫描"

自动化集成

CI/CD 集成:

1
2
3
4
5
6
7
8

# Azure Pipelines 示例
- task: NodeTool@0
  inputs:
    versionSpec: '18.x'
- script: |
    npm install -g @azure-devops/mcp
    claude -p "评审 PR $(System.PullRequest.PullRequestId) 并添加评论"
  displayName: 'Automated Code Review'

Webhook 触发:

1
2
3
4

# PR 创建时自动评审
curl -X POST "your-webhook-url" \
  -H "Content-Type: application/json" \
  -d '{"action": "review", "pr_id": "16"}'

🔧 Slash Commands 参考

内置 Slash Commands

Azure DevOps 特定命令

PR 相关:

1
2
3
4
5
6

/review PR 16                    # 评审特定 PR
/review pull request 16          # 同上，完整语法
/review Azure DevOps PR 16       # 明确指定平台
/review --detailed PR 16         # 详细评审
/review --security PR 16         # 安全性重点评审
/review --performance PR 16      # 性能重点评审

自然语言命令:

1
2
3
4
5
6
7
8

# 这些在交互式会话中都可以使用
"获取所有 Pull Request"
"列出待审查的 PR"
"评审 PR 16 并添加评论"
"获取 PR 16 的文件变更"
"将这个评审添加到 PR 评论中"
"检查 PR 16 的合并冲突"
"获取 PR 16 的构建状态"

组合命令

多步骤操作:

1
2
3
4
5
6
7
8
9
10

# 完整评审流程
> /review PR 16
> 将评审结果格式化为专业报告
> 添加到 PR 16 的评论中
> 设置 PR 16 为需要修改状态

# 批量处理
> 获取所有待审查的 PR
> 逐一进行安全性评审
> 生成汇总报告

🛠️ Azure DevOps MCP 工具

可用工具概览 (76+ 工具)

Pull Request 管理

• get_pull_requests - 获取 PR 列表
• get_pull_request - 获取 PR 详细信息
• create_pull_request_comment - 添加评论
• update_pull_request_comment - 更新评论
• delete_pull_request_comment - 删除评论
• get_pull_request_comments - 获取评论列表
• add_pull_request_reviewer - 添加审查者
• remove_pull_request_reviewer - 移除审查者
• approve_pull_request - 批准 PR
• reject_pull_request - 拒绝 PR
• complete_pull_request - 完成/合并 PR

代码库操作

• get_repositories - 获取仓库列表
• get_repository - 获取仓库信息
• get_file_content - 获取文件内容
• get_commit_history - 获取提交历史
• get_branches - 获取分支列表
• create_branch - 创建分支
• delete_branch - 删除分支

工作项管理

• get_work_items - 获取工作项列表
• get_work_item - 获取工作项详情
• create_work_item - 创建工作项
• update_work_item - 更新工作项
• delete_work_item - 删除工作项
• link_work_items - 关联工作项

构建和发布

• get_build_definitions - 获取构建定义
• get_builds - 获取构建列表
• queue_build - 触发构建
• get_build_logs - 获取构建日志
• get_release_definitions - 获取发布定义
• get_releases - 获取发布列表
• create_release - 创建发布

测试管理

• get_test_plans - 获取测试计划
• get_test_suites - 获取测试套件
• get_test_cases - 获取测试用例
• run_tests - 执行测试
• get_test_results - 获取测试结果

实际使用示例

获取 PR 信息:

1
2
3
4

# 在 Claude Code 会话中
> 使用 get_pull_request 工具获取 PR 16 的详细信息
> 获取 PR 16 的所有文件变更
> 列出 PR 16 的所有评论

添加评论:

1
2

> 使用 create_pull_request_comment 工具在 PR 16 上添加评论: "代码质量良好，建议合并"
> 在 PR 16 的第 10 行代码上添加行内评论: "建议使用更安全的字符串处理方法"

管理审查者:

1
2

> 为 PR 16 添加 john@company.com 作为审查者
> 从 PR 16 中移除 jane@company.com 的审查权限

🌟 最佳实践

安全实践

PAT 管理:

1
2
3
4
5
6
7
8
9
10

# ✅ 好的做法
export AZURE_DEVOPS_PAT="your-token-here"
claude mcp add-json azure-devops '{
  "env": {"AZURE_DEVOPS_PAT": "${AZURE_DEVOPS_PAT}"}
}'

# ❌ 避免
claude mcp add-json azure-devops '{
  "env": {"AZURE_DEVOPS_PAT": "hard-coded-token"}
}'

权限最小化:

• 仅授予必要的权限
• 定期轮换 Token (建议 90 天)
• 监控 Token 使用情况
• 及时撤销不用的 Token

评审质量

评审检查清单:

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

# 代码质量
- [ ] 代码风格一致性
- [ ] 命名规范
- [ ] 注释质量
- [ ] 错误处理

# 安全性
- [ ] 输入验证
- [ ] 身份认证
- [ ] 权限检查
- [ ] 敏感数据处理

# 性能
- [ ] 算法复杂度
- [ ] 数据库查询优化
- [ ] 缓存策略
- [ ] 内存使用

# 测试
- [ ] 单元测试覆盖率
- [ ] 集成测试
- [ ] 边界条件测试
- [ ] 异常处理测试

评审评论模板:

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

## 🔍 代码评审反馈

### ✅ 优点
- 代码结构清晰
- 遵循最佳实践
- 测试覆盖率良好

### ⚠️ 建议改进
- 第 23 行：建议添加输入验证
- 第 45 行：考虑使用更高效的算法
- 缺少单元测试覆盖

### 🔒 安全性检查
- ✅ 无明显安全风险
- 建议：添加 CSRF 保护

### 📊 总体评估
**评分**: ⭐⭐⭐⭐/5  
**建议**: 修复建议项后可以合并

团队协作

配置共享:

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

# 创建团队配置模板
# team-mcp-template.json
{
  "mcpServers": {
    "azure-devops": {
      "type": "stdio",
      "command": "npx",
      "args": ["@azure-devops/mcp", "${ORG_NAME}"],
      "env": {
        "AZURE_DEVOPS_PAT": "${AZURE_DEVOPS_PAT}"
      }
    }
  }
}

# 团队成员使用
claude --mcp-config team-mcp-template.json

标准化流程:

1. PR 创建 → 自动触发初步评审
2. 代码完成 → 详细质量检查
3. 安全扫描 → 专项安全审查
4. 性能测试 → 性能影响评估
5. 最终审批 → 人工确认和合并

自动化集成

GitHub Actions 示例:

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

name: Auto Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: actions/setup-node@v3
      with:
        node-version: '18'
    - run: npm install -g @azure-devops/mcp
    - run: |
        claude -p "评审 PR ${{ github.event.pull_request.number }} 并添加评论"
      env:
        AZURE_DEVOPS_PAT: ${{ secrets.AZURE_DEVOPS_PAT }}

🔧 故障排除

常见问题

1. MCP 服务器连接失败

问题现象:

1

azure-devops: npx @azure-devops/mcp - ❌ Failed to connect

解决步骤:

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

# 1. 检查网络连接
ping dev.azure.com

# 2. 验证 PAT 有效性
curl -H "Authorization: Basic $(echo -n :YOUR_PAT | base64)" \
  "https://dev.azure.com/YOUR_ORG/_apis/projects?api-version=7.1"

# 3. 重新配置 MCP 服务器
claude mcp remove azure-devops -s local
claude mcp add-json azure-devops '...'

# 4. 检查权限
# 确保 PAT 包含必要权限

2. API 调用失败

问题现象:

1

Error: Azure DevOps API call failed: 401 Unauthorized

解决方案:

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

# 检查 PAT 权限
# 1. 登录 Azure DevOps
# 2. 检查 Personal Access Tokens
# 3. 确认权限包含：
#    - Code (Read & Write)
#    - Pull Request (Read & Write)
#    - Work Items (Read)

# 重新生成 PAT
# 1. 撤销旧 Token
# 2. 创建新 Token
# 3. 更新 MCP 配置

3. 评论添加失败

问题排查:

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

# 1. 检查 PR 状态
claude -p "获取 PR 16 的状态"

# 2. 验证权限
claude -p "检查当前用户对 PR 16 的权限"

# 3. 手动测试 API
curl -X POST \
  -H "Authorization: Basic $(echo -n :YOUR_PAT | base64)" \
  -H "Content-Type: application/json" \
  -d '{"content":"Test comment"}' \
  "https://dev.azure.com/YOUR_ORG/YOUR_PROJECT/_apis/git/repositories/YOUR_REPO/pullRequests/16/threads?api-version=7.1"

4. 性能问题

优化建议:

1
2
3
4
5
6
7
8
9
10
11

# 1. 限制并发请求
claude -p "设置 Azure DevOps API 请求限制为每秒 5 个"

# 2. 使用缓存
# 避免重复获取相同 PR 信息

# 3. 批量操作
# 一次处理多个相关请求

# 4. 异步处理
# 对于大型 PR，使用异步评审

调试技巧

启用调试模式:

1
2
3
4
5
6
7
8
9

# MCP 调试
claude --debug mcp

# 详细日志
claude --debug api,mcp

# 环境变量调试
export MCP_DEBUG=true
export AZURE_DEVOPS_DEBUG=true

日志分析:

1
2
3
4
5

# 查看 Claude Code 日志
tail -f ~/.claude/logs/claude.log

# 查看 MCP 服务器日志
tail -f ~/.claude/logs/mcp-azure-devops.log

性能优化

提升速度:

1
2
3
4
5
6
7
8
9
10
11

# 1. 本地缓存配置
# ~/.claude/cache/azure-devops/config.json

# 2. 并行处理
claude -p "并行评审 PR 16-20"

# 3. 选择性评审
claude -p "仅评审变更文件中的 .cs 文件"

# 4. 增量评审
claude -p "仅评审自上次评审以来的新变更"

🚀 高级用法

自定义评审模板

创建评审模板:

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

# PR 评审模板
## 🔍 代码质量分析
- 代码风格: {style_score}/10
- 复杂度: {complexity_level}
- 测试覆盖率: {test_coverage}%

## 🛡️ 安全性检查
- 输入验证: {input_validation_status}
- 身份认证: {auth_check_status}
- 数据保护: {data_protection_status}

## ⚡ 性能评估
- 算法效率: {algorithm_efficiency}
- 内存使用: {memory_usage}
- 数据库影响: {db_impact}

## 📝 建议
{recommendations}

## ✅ 结论
{conclusion}

使用自定义模板:

1

claude -p "使用自定义模板评审 PR 16"

批量操作脚本

批量评审脚本:

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

#!/bin/bash
# bulk-review.sh

ORG_NAME="your-org"
PROJECT_NAME="your-project"

# 获取所有待审查的 PR
PRS=$(claude -p "列出所有状态为 Active 的 PR ID")

for pr_id in $PRS; do
    echo "评审 PR $pr_id"
    claude -p "评审 PR $pr_id 并添加评论"
    sleep 2  # 避免 API 限制
done

echo "批量评审完成"

自动化报告:

1
2
3
4
5
6
7
8
9

#!/bin/bash
# weekly-report.sh

claude -p "生成本周的 PR 评审统计报告，包括：
- 总评审 PR 数量
- 发现的问题类型分布
- 平均评审时间
- 代码质量趋势
- 安全问题统计"

集成外部工具

SonarQube 集成:

1
2

# 结合 SonarQube 分析结果
claude -p "获取 PR 16 的 SonarQube 分析结果并结合到评审中"

安全扫描工具:

1
2

# 集成 SAST 工具结果
claude -p "结合 Checkmarx 扫描结果评审 PR 16"

API 自动化

REST API 使用:

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

// Node.js 示例
const axios = require('axios');

const reviewPR = async (prId) => {
    const response = await axios.post('http://localhost:3000/claude-api', {
        prompt: `评审 PR ${prId} 并添加评论`,
        model: 'claude-sonnet-4'
    });
    
    return response.data;
};

// 使用
reviewPR(16).then(result => {
    console.log('评审完成:', result);
});

Webhook 集成:

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

# Python Flask 示例
from flask import Flask, request, jsonify
import subprocess

app = Flask(__name__)

@app.route('/webhook', methods=['POST'])
def azure_devops_webhook():
    data = request.json
    
    if data.get('eventType') == 'git.pullrequest.created':
        pr_id = data['resource']['pullRequestId']
        
        # 触发自动评审
        subprocess.run([
            'claude', '-p', 
            f'评审 PR {pr_id} 并添加评论'
        ])
        
        return jsonify({'status': 'success'})
    
    return jsonify({'status': 'ignored'})

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

📚 API 参考

Claude Code 命令行 API

基础语法:

1

claude [options] [prompt]

选项:

MCP 管理 API

服务器管理:

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

# 添加服务器
claude mcp add <name> <command> [args...]

# JSON 配置
claude mcp add-json <name> <json-config>

# 移除服务器
claude mcp remove <name> [-s local|global]

# 查看服务器
claude mcp list
claude mcp get <name>

Azure DevOps REST API 映射

MCP 工具与 REST API 对应关系:

API 认证:

1
2
3
4
5
6

# Basic Authentication
Authorization: Basic base64(:{PAT})

# 示例
curl -H "Authorization: Basic $(echo -n :YOUR_PAT | base64)" \
  "https://dev.azure.com/org/project/_apis/git/pullrequests?api-version=7.1"

📈 监控和分析

性能监控

评审性能指标:

1
2
3
4
5
6

# 获取评审统计
claude -p "生成 Azure DevOps MCP 工具的性能报告，包括：
- 平均响应时间
- API 调用成功率
- 评审准确性
- 错误率统计"

监控脚本:

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

#!/bin/bash
# monitor.sh

LOG_FILE="azure-devops-mcp-monitor.log"

while true; do
    STATUS=$(claude mcp get azure-devops | grep "Status" | cut -d: -f2)
    TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
    
    echo "$TIMESTAMP - Status: $STATUS" >> $LOG_FILE
    
    if [[ "$STATUS" != *"Connected"* ]]; then
        echo "ALERT: MCP 服务器断开连接" | mail -s "MCP Alert" admin@company.com
    fi
    
    sleep 300  # 5 分钟检查一次
done

质量分析

代码质量趋势:

1
2
3
4
5

claude -p "分析过去 30 天的 PR 评审数据，生成质量趋势报告：
- 代码质量评分变化
- 常见问题类型
- 修复时间统计
- 团队表现分析"

安全漏洞统计:

1
2
3
4
5

claude -p "统计本月发现的安全问题：
- 漏洞类型分布
- 严重程度统计
- 修复状态跟踪
- 预防措施建议"

🔮 未来规划和扩展

计划功能

• 机器学习优化 - 基于历史数据优化评审准确性
• 多语言支持 - 扩展到更多编程语言
• 团队协作增强 - 团队评审工作流优化
• 移动端支持 - 移动设备上的评审功能
• 集成IDE插件 - VS Code、IntelliJ 等 IDE 插件

自定义扩展

插件开发示例:

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

// claude-code-azure-plugin.js
class AzureDevOpsPlugin {
    constructor(config) {
        this.config = config;
    }
    
    async customReview(prId, options = {}) {
        // 自定义评审逻辑
        const analysis = await this.analyzeCode(prId);
        const recommendations = await this.generateRecommendations(analysis);
        
        if (options.autoComment) {
            await this.addComment(prId, recommendations);
        }
        
        return {
            analysis,
            recommendations,
            score: this.calculateScore(analysis)
        };
    }
}

module.exports = AzureDevOpsPlugin;

📞 支持和社区

获取帮助

• Claude Code 文档: https://docs.anthropic.com/claude-code
• Azure DevOps API: https://docs.microsoft.com/en-us/rest/api/azure/devops/
• GitHub Issues: https://github.com/anthropics/claude-code/issues

社区资源

• 讨论区: Claude Code Discord/Slack
• 示例仓库: https://github.com/azure-devops-mcp-examples
• 最佳实践: 社区 Wiki

继首个 AI 程序员 Devin 沉沙折戟之后，Cognition 又整了个 DeepWiki，号称是活的项目文档。

之前在用一些本地 agent 的时候，我也萌生过此类的想法，既然 AI 可以读项目，那让它每天定时把整个项目重新更新一遍，只要规则合适，应该只是时间问题？

没想到这么快就有项目落地了，看看效果如何。

先首页 add repo，然后大概一天后收到邮件说整完了。

用的是我自己仓库里的 lusipad/plcopen | DeepWiki

首页

分成了 概述、架构、代码组件、使用指南、开发几块。(这个我觉得还行)

概述里的内容大部分来自 README 和 test 的用例，还有一个自己绘制的框图。（还行）

架构部分主要是将 FB、运动控制、执行器三者分别阐述。（不错）

核心代码则是将几个关键的类详细展开了，并且有详细的 UML 图。（不错）

使用指南就不大行了，可能还是原来的代码写得不咋滴导致的。

开发部分我原本以为是给一些开发指南之类的，结果在写构建和加代码，但是内容又有些错误。。

除此以外，还可以通过 AI 问题。

整体来说，我觉得非常不错，关注下有没有开源替代的，准备部署一个。（之前看过 OpenDeepWiki 主要靠 Gemini Pro 的长上下文来整的，我其实还是想内网部署一个）

plcopen - lusipad 的文档仓库 | OpenDeekWiki | OpenDeekWiki

开源版本的效果也很不错。看来 Agent 领域没有护城河：）

1

将下一行文本作为纯文本输入，并将其翻译为简体中文，仅输出翻译。如果某些内容无需翻译（如专有名词、代码等），则保持原文不变。不要解释，输入文本

笑死，沉浸式翻译你就这样翻车了啊。

之前 Manus 最火的日子已经过去了，在 AI 界又爆发了一阵 MCP 的大浪潮。

这个时候我才姗姗来迟得拿到了 Manus 的邀请码，= =：过气了啊过气了，来试下还不好使。

题目还是和之前测试 OpenManus 的几道题目。

目前只能使用【标准】版本，高消耗的是 Pro 专享了。账号上包括了早期用户 1000 + 受邀用户 500 = 1500 积分。整个过程耗时比较长，所以也提供了网页通知的形式来告知结果。

问题1：评估算法的设计

问题

怎么 设计一个算法，可以评估如何设置参数才能适配机床，因为机床 硬件 伺服 和加工刀路都对其存在影响

过程

消耗积分：400

耗时时间：22 分钟

我已经完成了机床参数评估与优化算法的设计和实现工作。现在向您提交完整的解决方案文档和相关代码文件。

解决方案概述

针对”如何设计一个算法，可以评估如何设置参数才能适配机床”的问题，我设计了一个综合考虑硬件、伺服系统和加工刀路三个方面影响因素的参数评估与优化算法。该算法能够：

1. 评估参数设置的合理性：通过量化评分方式，评估当前参数设置的合理性
2. 识别关键参数：通过敏感性分析，识别对加工质量影响最大的关键参数
3. 提供优化建议：生成参数优化建议，按优先级排序
4. 自动优化参数：通过分层优化策略和迭代优化过程，自动优化参数设置

主要成果

1. 影响因素研究：系统研究了机床硬件、伺服系统和加工刀路对参数设置的影响
2. 相互作用分析：分析了三个方面影响因素之间的复杂相互作用机制
3. 评估算法设计：设计了三层评估指标体系和参数评分函数
4. 优化方法论开发：开发了分层优化策略和迭代优化过程
5. 实现框架创建：创建了完整的算法实现框架，包括数据结构定义和功能模块实现
6. 算法验证：验证了算法的有效性，包括评估准确性、优化有效性和敏感性分析准确性

验证结果

算法验证结果表明：

• 敏感性分析算法表现优秀（100/100分）
• 优化算法表现良好（74.08/100分）
• 评估算法有待改进（40/100分）
• 总体验证分数为65.63/100分

改进建议

基于验证结果，提出了以下改进建议：

1. 调整评分函数，确保评分在预期范围内
2. 优化参数权重，使评分更符合实际情况
3. 改进相互作用评估方法
4. 采用更高效的搜索策略，如贝叶斯优化或遗传算法
5. 引入机器学习方法，通过实际加工数据训练模型

提交文件

1. solution_document.md：完整的解决方案文档
2. machine_tool_algorithm.py：算法实现框架代码
3. algorithm_validator.py：算法验证工具代码
4. validation_report.md：算法验证报告
5. hardware_factors.md、servo_factors.md、toolpath_factors.md：影响因素研究文档
6. interaction_analysis.md、parameter_weights.md：相互作用分析文档
7. algorithm_design.md：参数评估算法设计文档
8. optimization_methodology.md：参数优化方法论文档

这个解决方案为机床参数设置提供了一种系统化的方法，有助于提高加工精度和效率，减少对操作人员经验的依赖。虽然当前算法还有改进空间，但已经建立了一个完整的框架，可以通过后续工作不断优化和完善。

完整的过程和文档：https://manus.im/share/PXbItOCV5YAeX1KwVZFd7b?replay=1

小结

总得来说，他就是将各种参数作为输入，然后拿结果作为一个衡量，做了一个评分系统，的确符合题意🤣。

看来进一步上一点强度。

问题2：将你的创作转变为网站并永久部署

看看前端编程能力如何

过程

看结果非常棒，整个生成的结果比预期的好很多

总结

从使用上来说，Manus 做得非常出色，已经可以说是初具生产力了，新的 coze 的智能体的邀请码我也有，后面有时间也再体验下。

慕尼黑上海光博会齐聚国内外行业知名企业，展示完整产品链：从元器件到系统集成方案，包含中间环节。2025年正逢慕尼黑上海光博会20周年，2025年3月11日 至 13 日在上海新国际博览中心盛大举行。

和往年相比，多了光子及量子专区（所以相应的展示面积也增加了），而且今年的专业论坛中还有一期是专门的量子论坛。

不过这些都不是我所关心的，我主要还是想看下控制系统相关的。基本上都集中在 N1 和 N2。

这里记录了走马观花的一些信息。

ScanLab

网站：

www.scanlab.com

公司介绍：

自1990年创建已来，SCANLAB生产制造用于激光束偏转和定位的高性能振镜电机及振镜扫描系统。通过精确移动反射镜和光学系统，我们的产品实现了对激光束的三维导向和定位。 基于每年安装的40,000多套扫描系统及解决方案，我们500位高素质、兢业的员工已经积累了丰富的专业技能。在这个坚实的基础上，SCANLAB确立了世界范围内在此市场上的领先地位,并成为对各种应用提供成功扫描解决方案的标志。

产品分类：

其他激光应用系统、各类材料激光加工系统、组件加工系统、激光增材制造、医学、光谱、显微镜和成像

应用领域：

公共事业、工具制造/工程机械、电子/电气/半导体、汽车工程、化工/制药行业/医疗技术/生物技术、环境、材料处理/加工、精密器械、研究/科研

在激光的高精度控制方面，ScanLab 还是存在一定优势的，但是其主要还是专注于扫描等领域。可以给人了解的东西不是很多。

北京金橙子科技股份有限公司

网站：

https://www.bjjcz.cn/

公司介绍：

北京金橙子科技股份有限公司（股票代码688291）创立于2004年，专注于激光工业加工领域控制软件和系统的研发，是工信部认定的专精特新小巨人企业、北京市认定的专精特新“小巨人”企业、北京市科委认定的高新技术企业。 金橙子打造出了先进的光束传输与控制技术平台，在此平台上衍生出众多具有自主知识产权的产品，广泛应用于激光先进制造、量测与自动化等领域，包括：激光标刻控制系统、激光切割控制系统、激光焊接控制系统、海格力斯控制系统、3D打印系统、宙斯控制系统以及驱控一体扫描模组等多个系列产品。

产品分类：

激光加工系统

应用领域：

工具制造/工程机械、电子/电气/半导体、汽车工程、航天/航空

这家公司之前咱会没有看到过，看产品来说已经比较完整了，后需研究下。

深圳市优尔数控软件有限公司

网站：

www.ursoft100.com

公司介绍：

深圳市优尔数控软件有限公司创立于2011年，为国家认定的高新技术企业，公司专注于“激光+”方面的软件研发。产品主要涵盖激光控制、运动控制、视觉定位与检测等方面。优尔始终秉持“差异化与创新”，“为客户创造更大价值”的理念,为客户专业提供激光行业整套系统解决方案。 公司所有产品均为自主研发，拥有完全的知识产权。产品稳定可靠，易学易用，功能强大。并建立了完善的售后服务体系，为客户提供最优质的、最全面的技术支持和维护服务。 公司主要软件产品： 切割类：玻璃切割(裂片)，玻璃振镜(3D)打孔，陶瓷旋切打孔，PCB/FPC切割等 焊接类：准直焊接与振镜焊接(金属焊接，塑料焊接；锂电焊接，PACK线应用等

产品分类：

其他激光应用系统、激光加工系统

应用领域：

能源、工具制造/工程机械、电子/电气/半导体、汽车工程、图像处理、印刷/制图、数据/信息技术、材料处理/加工、精密器械、其他

看了下，主要就是做视觉 + 激光焊接这块的，在角落的小展位上。

固高科技股份有限公司

网站：

https://www.googoltech.com.cn/

公司介绍：

固高科技于1999年由香港科技大学的李泽湘、高秉强、吴宏三位机器人、微电子和运动控制领域的国际知名学者和专家所创办，是亚太地区首家拥有自主知识产权, 专业从事运动控制及智能制造核心技术研究与开发的高科技企业，是国内外全互联智能制造综合解决方案提供商之一。固高科技专注于运动控制、伺服驱动、多维感知、工业现场网络和工业软件五个方向的核心技术研究，通过深入的国内外合作、产学研相结合、积极培育系统集成商等创新的商业模式，将固高科技的运控技术及产品广泛应用于微电子、机器人、数控机床、电子加工、检测、印刷、包装及生产自动化等工业控制领域。

产品分类：

光学生产设备、光学测量系统、各类材料激光加工系统、激光加工系统、全息测试测量系统与部件、半自动化激光测试测量系统、光伏与再生能源、机器视觉集成、配件、板卡、光纤、光缆、光纤器件及设备、光纤应用加工与装配设备、应用、生物技术

应用领域：

能源、工具制造/工程机械、电子/电气/半导体、汽车工程、航天/航空、化工/制药行业/医疗技术/生物技术、印刷/制图、国防工业、研究/科研

固高今年带来的是他的 gLink-II 总线协议，还有高阶平滑算法。需要分析下。

武汉威士登智能控制技术有限公司

网站：

www.wisdomlaser.com

公司介绍：

威士登-WISDOM是由一批专注于激光控制、CNC数控系统、运动控制、机器视觉、自动化软件领域专业人才创立的“国家级高新技术企业”，经过多年的技术创新与研发投入，公司一直保持高速发展，2021年至2024年度连续被评为中国光谷“瞪羚企业”。 威士登作为“专精特新”激光控制系统的领导者，自主研发的“WSD-E系列激光切割控制系统”、“WisCut系列激光切割软件”与“WisNest系列排版套料软件”深入应用于各个领域的终端用户，并得到用户的广泛认可与批量应用。其中，威士登自主研发的WSD-E10系列型钢三维激光切割软件系统市场占有率第一，引领了钢结构行业的激光加工革命。

产品分类：

系统整合、各类材料激光加工系统、激光加工系统

应用领域：

电子/电气/半导体、汽车工程、材料处理/加工、精密器械

威士登是基于 Bechhoff 做的二次开发，从功能角度来说非常的完整。主要问题在于系统非自研，导致开发反馈沟通的成本太高了。但是功能方面值得好好分析下。

嘉强（上海）智能科技股份公司

网站：

www.empower.cn

公司介绍：

Empower嘉强成立于2009年，专注于激光智造的赋能型平台企业。公司秉承“嘉言善行·庄敬自强”的宗旨，专业一站式为激光切割、钻孔、焊接、熔覆、淬火、表面处理、微加工，3D打印及增材制造和在线打标等应用，提供RayTools锐图（A+B) 软件+激光头产品子系统，RayKits镭工（K+N）套件+行业解决方案和RayService激光无忧（C+S）配件易损件+维保的线上线下51laser全栈快速本地化服务！ 公司基于自主可控的嘉强鸿xEOS边缘操作系统数字化转型底座，通过xEOS分布式开放平台边缘部署和xAPP个性化工艺之生态保护，持续为激光智造Ai赋能，并与合作伙伴们共赢未来！

产品分类：

激光加工系统

应用领域：

工具制造/工程机械、汽车工程

嘉强今年的干货不少，现在整个产品链都已经比较完整了，开始整生态了。但是从官网来看，这个扩展平台，更多是一些定制类的安卓 工具 App 开发，而且论坛也是个空壳，看来还有一定的距离。

维宏股份

网站：

www.weihong.com.cn

公司介绍：

上海维宏电子科技股份有限公司（股票代码：300508）是一家专注于运动控制系统研发、销售和服务的高科技企业，以拥有自主知识产权的工业自动化控制技术为基础，快速为客户提供个性化的解决方案，实现企业价值与客户价值共同成长。如今，维宏品牌已经成长为数字化制造领域“中国智造”的卓越品牌之一。 以赋能中国制造业为荣耀，公司成立以来，致力于开发运动控制产品，不断开拓产品应用领域。目前，维宏运动控制系统已广泛应用于模具制造、金属切削、金属高光加工、3C玻璃精密加工、板式家具切割、实木雕刻、玻璃石材加工、激光加工、水射流加工等领域。

产品分类：

各类材料激光加工系统、激光加工系统

应用领域：

工具制造/工程机械、汽车工程、航天/航空、材料处理/加工

维宏今年的新东西不多，本次就两个新品，而且技术上都是往年就已经差不多成型的。

从最近的董秘问答来看，主要还是以金属、激光切割作为主战场，对于激光焊接等领域暂无计划。

• 四卡盘坡口激光管材切割系统

  TU7800M四卡盘坡口激光管材切割系统是为管道、钢结构和重型机械行业设计的高效解决方案。该系统通过四卡盘技术，解决了传统双卡盘机床加工长零件时的抖动问题，并实现了零尾料加工，提高材料利用率。

  

• H型钢三维五轴激光切割控制系统

  H型钢三维五轴激光切割控制系统是专为解决钢构建筑行业中的高精度、复杂形状加工需求而设计的先进制造解决方案。该系统以其高功率激光器（超过12千瓦）、五轴联动机床结构和灵活的切割头设计，能够应对工字钢等材料的精确加工，包括腹板斜切、打孔、过焊孔切割等复杂操作。

  

柏楚

上海柏楚电子科技股份有限公司(SHANGHAI FRIENDESS ELECTRONICS TECHNOLOGY CO.,LTD.)是一家从事激光切割控制系统研发、生产、销售的高新技术企业和重点软件企业，技术体系的完整性全球领先，累计为近600家激光加工设备制造商提供成套的系统解决方案，在中国激光切割控制市场占据领先地位，先后获评“上海市小巨人企业”，“上海市专精特新企业”，“上海市硬核科技TOP100”等多项荣誉。2019年在上交所科创板成功上市，为闵行区第一家科创板上市公司，上市后公司开拓了新航道，布局了工业互联网、超高精密驱控一体化、智能焊接机器人等领域，助力推动中国工业自动化的发展，致力于成为一家伟大的工业自动化公司，旨在让智慧工厂走入万千企业。

柏楚今年就一个激光焊接，其他啥都没有。和他们聊的时候，说是切割领域做得差不多了。

小结

今天的整体来说激光相关的控制软件方面的新内容不多，大部分的企业也往解决方案、细分领域方向在走。特别是作为领头羊的柏楚，今年就一个激光焊接演示。

另外一点就是有明确的出海趋势，很多的展商都准备了英文版资料，并且现场的国外观众的数量也比往年明显增加。

参考

1. 慕尼黑上海光博会官方网站
2. 在线会刊

前几天 Manus 突然火了，国内自媒体各种夸夸夸，国外一点没水花。从我个人角度来看，这玩意儿和前几年的 autoGPT 没啥本质上的区别，无法就是大模型底座 + 工具链优化，这也是今年智能体的一个大方向。

之前的 DeepResearch 就给大家上了一课，就是推理 + 工具，会产生新的化学反应。因为从某种程度上来说，推理模型的最大优势，其实在于自动生成合适的 Pompt，而高质量的 Prompt 对于模型能力而言非常重要。相当于你有优秀的程序员，但是配了一个拉胯的产品；而推理模型弥补了这个不足。当然这个只是从现象来看，实际的底层的技术架构是完全不同的：）

反正这个 Manus 在我个人看来，和之前的所谓全球首个 AI 程序员 Devin 什么的，没有什么特别的区别，当然这里不是贬低，团队还是做了很大的改进的，但是并没有重大的技术上的突破。所以眼瞅着 3 小时后开源平替 OpenManus 就出来了。仔细看了眼，这个不是 MetaGPT 那帮人整合了工具链套了个壳吗 （此处应有黑人问号）。

我们先来试用下，安装过程不复述了，比较简单。模型方面使用的是 DeepSeek-V3。

1. 评估算法的设计（初战失败，下次成功后再更新了）

问题

怎么 设计一个算法，可以评估如何设置参数才能适配机床，因为机床 硬件 伺服 和加工刀路都对其存在影响

过程

可以看到 OpenManus 默认分成 30 个步骤，进行处理。

但是我这边试验到就几步就跪了，大概消耗的 tokens 如下：

下面是详细的记录信息：

1.1 算法设计

2025-03-08 09:43:07.405 | INFO | app.agent.toolcall:think:53 - ✨ Manus’s thoughts: 要设计一个算法来评估如何设置参数以适配机床，我们需要考虑以下几个关键因素：

1. 机床硬件特性：包括机床的刚性、精度、最大转速、最大进给速度等。
2. 伺服系统特性：包括伺服电机的响应速度、扭矩、加速度等。
3. 加工刀路：包括切削速度、进给速度、切削深度、刀具材料等。

算法设计步骤

1. 数据收集：

   • 收集机床的硬件参数。
   • 收集伺服系统的参数。
   • 收集加工刀路的参数。

2. 参数建模：

   • 建立数学模型来描述机床、伺服系统和加工刀路之间的关系。
   • 使用机器学习或优化算法来拟合模型。

3. 参数优化：

   • 使用优化算法（如遗传算法、粒子群优化等）来寻找最优参数设置。
   • 考虑约束条件（如机床的最大转速、最大进给速度等）。

4. 评估与验证：

   • 使用仿真工具或实际加工来验证参数设置的效果。
   • 根据评估结果调整模型和参数。

示例代码

以下是一个简单的Python代码示例，用于收集数据并进行初步的参数优化：

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
33
34
35
36
37
38
39

import numpy as np
from scipy.optimize import minimize

# 机床硬件参数
machine_rigidity = 1000  # 机床刚性
machine_precision = 0.01  # 机床精度

# 伺服系统参数
servo_response_time = 0.1  # 伺服响应时间
servo_torque = 50  # 伺服扭矩

# 加工刀路参数
cutting_speed = 200  # 切削速度
feed_rate = 0.1  # 进给速度
cutting_depth = 0.5  # 切削深度

# 目标函数：最小化加工误差
def objective_function(params):
    cutting_speed, feed_rate, cutting_depth = params
    # 简单的误差模型
    error = (cutting_speed / machine_rigidity) + (feed_rate / servo_response_time) + (cutting_depth / machine_precision)
    return error

# 约束条件
constraints = (
    {'type': 'ineq', 'fun': lambda x: x[0] - 100},  # 切削速度 >= 100
    {'type': 'ineq', 'fun': lambda x: x[1] - 0.05},  # 进给速度 >= 0.05
    {'type': 'ineq', 'fun': lambda x: x[2] - 0.1}    # 切削深度 >= 0.1
)

# 初始参数
initial_params = [cutting_speed, feed_rate, cutting_depth]

# 优化
result = minimize(objective_function, initial_params, constraints=constraints)

# 输出结果
print("Optimal Parameters:", result.x)
print("Minimum Error:", result.fun)

下一步

1. 数据收集：收集更多的机床、伺服系统和加工刀路的数据。
2. 模型改进：使用更复杂的模型来描述系统。
3. 优化算法：尝试不同的优化算法以提高参数设置的准确性。
4. 验证：使用仿真工具或实际加工来验证参数设置的效果。

如果需要进一步的信息或工具支持，请告诉我。

1.2 算法优化

2025-03-08 09:43:44.951 | INFO | app.agent.toolcall:think:53 - ✨ Manus’s thoughts: To design an algorithm that evaluates how to set parameters to adapt to a machine tool, we need to consider the following key factors:

1. Machine Tool Hardware Characteristics: Including rigidity, precision, maximum speed, maximum feed rate, etc.
2. Servo System Characteristics: Including response speed, torque, acceleration, etc.
3. Tool Path: Including cutting speed, feed rate, cutting depth, tool material, etc.

Algorithm Design Steps

1. Data Collection:

   • Collect machine tool hardware parameters.
   • Collect servo system parameters.
   • Collect tool path parameters.

2. Parameter Modeling:

   • Establish a mathematical model to describe the relationship between the machine tool, servo system, and tool path.
   • Use machine learning or optimization algorithms to fit the model.

3. Parameter Optimization:

   • Use optimization algorithms (such as genetic algorithms, particle swarm optimization, etc.) to find the optimal parameter settings.
   • Consider constraints (such as the machine tool’s maximum speed, maximum feed rate, etc.).

4. Evaluation and Validation:

   • Use simulation tools or actual machining to validate the parameter settings.
   • Adjust the model and parameters based on the evaluation results.