AI on CHEN 的博客

15 分钟快速搞定 CLIProxyAPI 配置

Wed, 09 Sep 2026 15:00:00 +0800

之前一直用 sub2api 把 ChatGPT 的网页端转成 API，给本地的编程工具提供模型接口。用着用着，某天突然发现不能用了。

具体是被封了还是接口变了，也没细究，反正是坏了。坏了之后就想找替代方案，一搜发现 CLIProxyAPI 这个项目，Star 数不少，而且思路和 sub2api 类似——把你已有的订阅变成 API，不需要额外买 Key。

区别在于 CLIProxyAPI 走的是 OAuth 登录，模拟的是 Codex CLI 的流量，而不是直接抓网页。据说更稳定，也更不容易被检测。

正好我有 GPT Plus，服务器也有，那就试试。

一、CLIProxyAPI 是什么

一句话：它是一个代理服务，把 Gemini、Claude Code、OpenAI Codex 这些 CLI 工具的 OAuth 认证，转成标准的 OpenAI 兼容 API。

也就是说，你不需要去 OpenAI 申请 API Key（也不需要花钱买 Token），直接用你的 Plus 订阅账号登录，CLIProxyAPI 就能帮你把请求转发过去，返回的结果格式和 OpenAI 官方 API 一模一样。

对于已有 Plus 但没有 API 额度的人来说，这基本等于白嫖。

二、15 分钟搞定全过程

整个流程拆开来就五步：安装、启动、登录、开防火墙、接入工具。一步步来。

第一步：安装

从 GitHub Releases 下载对应平台的二进制包，解压即可：

# 下载最新版（以 Linux AMD64 为例）
VERSION=$(curl -s https://api.github.com/repos/router-for-me/CLIProxyAPI/releases/latest | grep tag_name | cut -d '"' -f 4)
wget https://github.com/router-for-me/CLIProxyAPI/releases/download/${VERSION}/cli-proxy-api_linux_amd64.tar.gz

# 解压
tar -xzf cli-proxy-api_linux_amd64.tar.gz
chmod +x cli-proxy-api

不需要编译，不需要装依赖，下载完就是一个可执行文件。

第二步：启动服务

直接运行：

./cli-proxy-api

默认监听 0.0.0.0:8317。首次启动会自动拉取最新的模型目录，看到 API server started successfully on: :8317 就说明起来了。

第三步：OAuth 登录 GPT Plus

另开一个终端，跑登录命令：

./cli-proxy-api --codex-login

它会走 OpenAI 的 OAuth 设备流。服务器没有浏览器的话加 --no-browser，它会打印一个 URL，你本地打开登录就行。登录成功后 token 自动保存到 ~/.cli-proxy-api/，后续请求自动带上。

第四步：开防火墙

这里是第一个坑。腾讯云有两层防火墙，两层都要开端口：

层级	位置	操作
安全组	腾讯云控制台	添加入站规则，TCP 8317
UFW	服务器 OS 内部	`sudo ufw allow 8317/tcp`

我之前只开了安全组，结果 UFW 默认拒绝入站，请求在操作系统层就被拦了，怎么都连不上。这个坑不新鲜，但每次都会忘。

第五步：把 API 地址和 Key 填到本地工具

最后一步就是把 API 信息复制到你本地的编程工具里。以 CodeBuddy 为例：

供应商：选 Custom
BASE URL：http://<服务器公网IP>:8317/v1
API KEY：填 config.yaml 里的任意一个 key
模型名称：选你要用的模型，比如 gpt-5.5

保存，搞定。CodeBuddy 发出的请求会经过 CLIProxyAPI 转发到 OpenAI，整个链路对工具本身是透明的。

第六步：设置开机自启

服务器重启后，CLIProxyAPI 不会自动运行。要让它作为守护进程长期运行，可以用 systemd 管理：

# 复制服务文件到 systemd 目录
sudo cp /home/ubuntu/cliproxyapi/cliproxyapi.service /etc/systemd/system/

# 重新加载 systemd 配置
sudo systemctl daemon-reload

# 启用开机自启
sudo systemctl enable cliproxyapi

# 启动服务
sudo systemctl start cliproxyapi

之后可以用 sudo systemctl status cliproxyapi 查看运行状态，用 sudo journalctl -u cliproxyapi -f 实时查看日志。

这样设置后，服务器重启时 CLIProxyAPI 会自动拉起，不需要手动干预。

三、可用模型一览

登录成功后，CLIProxyAPI 会从 OpenAI 拉取当前账号可用的模型列表。我这边拿到了这些：

模型	说明
`gpt-5.5`	通用对话模型
`gpt-5.6-terra`	Terra 系列
`gpt-5.6-sol`	Sol 系列
`gpt-5.6-luna`	Luna 系列
`gpt-6-astra`	Astra 系列
`gpt-5.3-codex-spark`	Codex Spark
`gpt-image-1.5`	图片生成
`gpt-image-2`	图片生成（新版）
`codex-auto-review`	自动代码审查

具体模型列表会随 OpenAI 的调整变化，以实际拉取到的为准。

四、总结

整个过程其实很简单：下载、启动、OAuth 登录、开防火墙、配工具。中间唯一浪费时间的就是那个双层防火墙的问题。

比起 sub2api，CLIProxyAPI 的优势在于不依赖网页抓取，走的是 OAuth 标准流程，理论上更稳定。而且它不只支持 GPT，Gemini、Claude Code 都能接，一个服务搞定多个订阅。

对于已经有 GPT Plus 但不想额外花钱买 API 的人来说，值得一试。

停用 GPT 一个月后，我回来了

Tue, 08 Sep 2026 15:34:00 +0800

停用 ChatGPT 差不多一个月了。

原因挺杂的。政策层面的不确定性是一方面，费用是一方面，另一方面国产的 Agent 和 Harness 产品确实越来越多、越来越能打了，我想认真试一试它们到底能到什么程度。于是干脆把 GPT 暂时放下了，全面切换到国产智能体加国产模型的组合。

这一个月下来，体验其实没有想象中那么痛苦。但现在 GPT6 发布，各种强大的作品展示效果层出不穷，恰逢我的国内免费积分也快用完了，是时候回来再看看了。

切换的过程比想象中顺利

先说结论：从 Codex + GPT5.5 切换到国产智能体 + 国产模型，并没有太多的不适应。

这一点我是真心觉得不错。

说实话，一年前如果让我做同样的切换，体验落差可能会非常明显。但现在，无论是豆包、Kimi 还是其他几家，在代码理解、多轮对话、上下文保持这些方面，确实已经做到了一个相当可用的水平。

尤其是在一些标准化的任务上——比如写一段业务逻辑、生成测试用例、做简单的代码审查——国产模型的表现已经相当稳定。我日常用 Codex 做的事情，换成国产智能体以后，大部分场景都能接住。

从这个角度说，中美 AI 的差距确实在缩小。 这不是客套话，而是过去一个月里我最真实的体感。

具体用了哪些产品

先列一下这一个月用过的东西。

智能体方面，试了一圈：CodeBuddy、WorkBuddy、Trae、Qoder、千问办公。用下来的感受，一言以蔽之——都差不多。 界面设计、交互逻辑、任务完成度，没有谁拉开谁一个身位的感觉。各有各的小毛病，也各有各的亮点，但整体体验高度趋同。

基座模型方面就杂一些了：GLM5.2、GLM5.3、GLM5.3 Flash、Kimi-K3、HY4 Preview、HY3、DeepseekV4 PRO、DeepseekV Flash、QWEN 3.8，能排上号的几乎都跑了一遍。

体感上，推理能力和深度没有想象的差距那么大。 大家在逻辑推理、代码理解、方案生成这些方面的表现，说实话已经非常接近了。倒是执行速度和积分消耗，确实让几个 Flash 模型优势巨大——同样一个任务，Flash 模型可能 10 秒出结果还不怎么耗积分，换一个满血版可能要 30 秒还烧掉好几倍的额度。对于日常高频使用来说，这个差距比模型能力本身的差距更直接影响体验。

但信心是另一回事

话说到这里，但后面还有一个"但是"。

切换过去以后，我发现自己有一个很明显的变化：对国产产品产出的信心不足。

这种信心不足不是说它们回答得不好，而是一种隐隐的担心——会不会哪里有比较大的理解偏差？会不会有一个看起来很合理但实际上是谬误的答案？会不会在某个关键细节上自以为正确但其实是错的？

于是我养成了一个习惯：同一个问题，用多个国产产品交叉验证。

A 产品给了一个答案，我再问一遍 B 产品；B 产品说了一个方案，我再让 C 产品看看有没有问题。表面上看这是在充分利用各家的长处，但实际上，这背后是一种不太敢完全信任的心态。

反过来说，我几乎从来没有对 GPT 产生过这种需要交叉验证的冲动。不是因为它一定不会犯错——它当然也会幻觉——而是长期以来建立的使用信任，让我在大多数场景下愿意直接采纳它的结果。

这种信任不是一天建立起来的，而是在无数次使用中慢慢积累的。每一次它准确理解了我的意图，每一次它给出了合理的方案，每一次它在复杂问题上表现出的稳定性，都在为这种信任充值。

而国产模型目前还处在这个信任充值的早期阶段。

为什么信心差距这么重要

可能有人会觉得，多验证几次也不是什么大事，不就是多花几分钟嘛。

但实际使用中，这种信心差距的影响比看起来要大得多。

当你对一个工具的产出不够信任时，你的使用方式就会发生根本性的变化。你会更保守，更不敢尝试，更倾向于把 AI 的输出当成"参考"而不是"半成品"。你会花更多时间在检查和验证上，而不是让它帮你往前推进。

更关键的是，你不太敢让 AI 深度参与复杂任务。因为一旦涉及多步骤、多文件、需要连贯理解的场景，任何一个环节的理解偏差，都可能像蝴蝶效应一样放大到最后的结果里。

这种谨慎在很多场景下是对的，但它同时也意味着你没有真正释放 AI 的能力。

现在回来，看看 GPT6 到底有多强

GPT6 发布这几天，我看了不少作品展示，确实有一些让人眼前一亮的效果。

但看别人演示和自己实际使用，始终是两回事。所以我不想在没有深度使用之前就下结论。这次回来，我想认真对比几个方面：

维度	国产智能体 + 国产模型	GPT6 + Codex
标准化任务	表现稳定，可用	预期会更强，但待验证
复杂理解	够用，偶尔有偏差	需要验证
多步推理	基本可用，信心不足	需要验证
代码生成	质量不错	预期会有提升
使用成本	有免费额度，但开始收费	Plus 订阅 + API 按量
信任感	需要交叉验证	长期积累，相对更高

这个表格里的"待验证"不是我偷懒不想写，而是我真的觉得，在没有足够使用数据之前，给任何一个方向下结论都为时过早。

说说费用这件事

既然提到了费用，就多说两句。

国产产品的免费积分确实是我这一个月能全面切换的一个重要支撑。但正如前面说的，免费积分总有用完的时候，而一旦开始付费，价格差距就变得很现实了。

GPT Plus 每月 20 美元，这个价格虽然不便宜，但考虑到它能提供的能力上限和稳定性，对于把 AI 当成核心生产力工具的人来说，是一笔算得过来的账。

国产产品目前的定价策略还在探索阶段。有的免费额度给得很大方，有的已经开始收紧。这种不确定性本身也会增加使用时的心理负担——你不知道下个月还能不能像现在这样用。

最后

停用一个月 GPT，最大的收获不是发现国产产品已经能完全替代了，而是让我更清楚地看到了差距到底缩小了多少，以及剩下的差距到底在哪里。

国产模型在标准化任务上的表现已经相当不错，这是事实。但在需要深度信任、复杂推理和长期稳定性的场景下，要追上的路还有不少。

不过话说回来，信任这东西本来就是靠一次又一次的正确积累出来的。国产模型的充值才刚开始，未来的空间还很大。

现在 GPT6 回来了，我想先用一段时间再做更完整的对比。也许到时候会发现差距比想象中小，也许会发现有些差距比我想象中更难追。

无论如何，能有选择本身就是一件好事。 有竞争，才会有进步；有对比，才知道差距；有差距，才有追赶的动力。

Prompt 之后是 Context，Context 之后为什么是 Loop

Fri, 31 Jul 2026 18:30:00 +0800

毕业之前，我属实没有想到，IT 工程师的工作方式会在短短几年里经历如此翻天覆地的变化。

以前理解的程序员工作，就是分析需求、设计接口，然后一行一行写业务代码。

现在则越来越像是先设计系统、整理上下文、写清约束和验收标准，再让 AI 生成代码，最后通过测试、工具和人工审核结果。

某种程度上，相当于给自己配了一个 24 小时在线的下属。

它不会累，可以不停地读代码、改代码、跑测试。但它也不是一个可以完全放手的成熟员工。如果目标、权限、工具或验收标准设计错了，它同样可以 24 小时不间断地往错误方向狂奔。

我最近看到的两张图，正好把这种变化总结了出来。

第一张图把 AI 工程分成五个阶段：Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering 和 Graph Engineering。

第二张图则把它们画成一层套一层的结构。

我不打算考证每个名词究竟在哪一年出现。对我来说，这两张图最有价值的地方，是它们表达了一种关系：这些阶段并不是后一代替代前一代，而是每一层都在解决上一层暴露出来的问题，同时又建立在上一层之上。

Prompt Engineering 解决的是怎么把话说清楚。

Context Engineering 解决的是怎么把正确的背景、文档和记忆交给模型。

Harness Engineering 解决的是怎么给模型准备工具、权限、运行环境和跨上下文的状态。

Loop Engineering 进一步要解决的，则是怎么让模型自己发现问题、修正结果，并在合适的时候停下来。

再往外一层的 Graph Engineering，开始考虑多个 Loop 之间如何分工、依赖、并行和调度。

我自己对 Loop Engineering 的理解还很浅，这篇文章也只是一次学习记录。

在 Loop 之前，人其实就是那个循环

在 Loop 这个概念出现之前，我们使用大模型的方式通常是这样的：

用户提出问题，模型给出答案；用户检查结果，发现问题；用户把问题重新描述给模型，模型再次修改；如此反复，直到用户觉得结果可以接受。

表面上看，这是人在和模型对话。

实际上，它已经是一个完整的循环：

提出问题 -> 生成结果 -> 检查偏差 -> 提供反馈 -> 再次生成

只不过这个循环里的观察、判断和停止，全都由人来完成。

如果把这些工作也交给系统，让模型自己读取执行结果、判断哪里不对、制定下一步方案，然后继续尝试，是不是就可以节省人很多精力？

这就是我目前对 Loop Engineering 最直观的理解。

它不是让模型多回答几次，也不是简单地在程序外面套一个 while true。它真正要做的，是把原本依赖人完成的反馈过程，设计成一个可以自动运行的工程系统。

如果反馈足够准确，模型每一轮都能根据结果修正下一步动作，那么最终表现出来的能力确实会变强。

不过严格来说，变强的不是模型本身。

模型参数没有因为多跑几轮而发生变化。真正变强的是模型、工具、环境、反馈和停止条件共同组成的整个系统。

Loop 能不能收敛

说到循环，我最先想到的是“收敛”。

我第一次接触收敛，是在学习微积分里的极限时。简单理解，就是一个序列随着不断变化，越来越接近某个确定的值。

拿大模型回答问题举一个并不严谨、但很直观的例子。

第一次问大模型 1 + 1 等于几，它回答 1，和正确答案偏差很大。

把错误反馈给它以后，第二次回答变成 2.1，已经更接近答案。

第三次回答 2.0001，偏差又缩小了一些。

如果误差能够在每一轮里不断减小，就可以把这个过程理解为正在收敛。

这背后依赖的是一种负反馈调节机制：系统观察当前结果与目标之间的偏差，再用这个偏差修正下一轮行为。

问题在于，大模型的循环并不保证一定收敛，更不保证每一轮都比上一轮更好。

它第三次回答了 2.0001，第四次完全可能突然回答 10。

为什么会这样？

可能是反馈本身判断错了，可能是模型选错了工具，可能是上下文里混进了互相冲突的信息，也可能是前几轮留下的错误状态没有被清理。

即使这些步骤都没有明显出错，上下文不断膨胀以后，旧信息、无关信息和重复信息也可能开始干扰模型。

另外，大模型本身就带有概率性。同样的输入，不同轮次也未必会沿着同一条路线继续优化。

所以，循环次数更多，不等于结果一定更准确。

如果反馈方向错了，Loop 甚至会把一个小错误不断放大。那个 24 小时在线的下属，也可能非常勤奋地把整个项目带进沟里。

可观测性和可验证性不是一回事

我最初理解这件事时，把可观测性和可验证性混在了一起。

后来想了一下，它们其实解决的是两个不同的问题。

可观测性解决的是：系统刚才做了什么？

比如模型读取了哪些文件、调用了什么工具、当前执行到了哪一步、消耗了多少时间和 token、修改了哪些代码，以及为什么做出这个决定。

没有这些信息，Loop 一旦偏离目标，我们甚至不知道问题出在哪一轮。

可验证性解决的则是：系统做得对不对？

代码有没有通过单元测试和类型检查，接口返回值是否符合 Schema，页面是否真的可以操作，性能指标有没有达标，最终结果是否满足最初的验收条件。

只有可观测性，没有可验证性，我们可以看到模型忙了很久，却不知道它到底有没有把事情做好。

只有可验证性，没有可观测性，测试失败以后，我们又很难判断问题究竟发生在哪里。

Loop 想要稳定运行，两者缺一不可。

这也是为什么写代码很适合使用 Agent Loop。代码天然拥有很多相对明确的反馈信号：编译是否通过、测试是否成功、接口是否返回预期结果、页面是否正常渲染。

相比之下，“这篇文章写得够不够好”就很难量化，因为它缺少唯一正确的答案。

当然，即使测试全部通过，也不代表业务一定正确。测试本身可能写错，覆盖范围也可能不够，模型甚至可能通过修改测试来让错误代码变绿。

所以 Harness 里还需要权限边界、受保护的验收标准，以及必要时由人介入审核。

什么时候应该结束循环

Loop Engineering 还有一个很重要的问题：什么时候停？

大模型每次回答的，本质上都是它认为概率最高的结果，而不是经过数学证明的唯一答案。

既然很难得到绝对完美的结果，就不能要求 Loop 一直运行到“完全正确”。

否则它可能永远不会结束。

我目前理解，一套 Loop 至少要回答四个问题：

如何感知当前状态和问题？
如何根据问题决定下一步方案？
执行以后，如何验收结果？
验收完成后，应该继续、停止，还是交给人处理？

最理想的停止方式，当然是所有验收条件都已经满足。

但工程上还需要更多保险。

例如达到最大迭代次数就停止，超过时间或 token 预算就停止，连续几轮没有明显改善就停止，反复出现相同错误就停止，或者遇到高风险操作时暂停并等待人工确认。

有时候，停止条件甚至比生成代码的提示词更重要。

因为一个不会写代码的 Agent，最多只是交不出结果；一个不知道什么时候停的 Agent，却可能不停重试、消耗额度、反复修改已经正确的代码，最后把原本能用的东西也弄坏。

所以 Loop Engineering 不是研究怎么让 AI 无限工作，而是研究怎么让它在一个受控的反馈系统里持续工作。

再往外一层，就是多个 Loop 的协作

当一个 Loop 能够稳定完成任务以后，下一步自然会遇到新的问题。

一个复杂项目里，可能同时存在需求分析 Loop、编码 Loop、测试 Loop、代码审查 Loop 和部署 Loop。

它们之间谁先开始，谁依赖谁，哪些任务可以并行，某个 Loop 失败以后应该重试还是回退，都需要更高一层的系统来调度。

这大概就是图里 Graph Engineering 想要解决的问题。

如果说 Loop Engineering 是让一个执行者能够自己工作，那么 Graph Engineering 更像是在组织一支团队。

至于这一层具体应该怎么设计，我现在的理解就更浅了，还有待后续继续学习。

最后

毕业之前，我以为程序员的成长路径，是不断学习新的语言、框架和架构，然后写出越来越多、越来越复杂的代码。

现在才发现，未来工程师的工作可能会越来越少地停留在“亲手写出每一行业务代码”上。

我们开始负责定义问题、设计环境、准备工具、设置权限、编写验收标准、观察执行过程，并决定什么时候应该让 AI 继续，什么时候必须由人接手。

代码仍然重要，只是它正在从工作的全部，变成整个系统中的一部分。

工程师也正在从代码的直接生产者，慢慢变成反馈系统和工作机制的设计者。

所谓配备一个 24 小时在线的下属，真正困难的从来不是让它开始工作。

而是让它知道该做什么，做完以后如何证明自己做对了，以及什么时候应该停下来。

当 AI 成为生产资料，谁用得起比谁更强更重要

Fri, 31 Jul 2026 14:20:00 +0800

疯狂的 7 月终于要结束了。

这个月我用 GPT 和 Codex 用得很凶，最大的感受不是模型又强了多少，而是额度突然变得特别耐用。

这个月，官方直接取消了原来的 5 小时限制，真正需要留意的只剩 7 天额度。中间额度还重置了很多次，我手里两张 Plus 轮着用，实际体验已经非常接近无限额度。

至少在这个疯狂的 7 月，我第一次产生了一种感觉：GPT 的额度已经多到让我不太需要计算了。

一边降价，一边涨到 538 元

到了今天，7 月的最后一天，OpenAI 又宣布下调 GPT-5.6 系列的 API 价格：Luna 降价 80%，Terra 降价 20%。

API 价格和 Plus 订阅当然不是同一回事，但它们指向的是同一个方向：模型能力还在往上走，使用成本却在继续往下压。

偏偏就在同一天，国内的 GLM Coding Plan 也重新上线了。

新版 GLM Coding Plan 的 Pro 套餐是 538 元一个月。作为对比，ChatGPT Plus 每月 20 美元，粗略折算也就一百四十元左右。两边的额度计算方式不同，没法拿数字直接相除，但按我自己的实际使用体验，Plus 不仅便宜得多，额度也更多、更经得起折腾。

一边不断重置额度、降低价格，一边把 Pro 套餐卖到 538 元。这个反差实在很难让人忽略。

我当然希望国产模型能够雄起

我当然希望国内模型和国内公司能够真正雄起。

我希望国产模型在能力、生态、价格甚至基础设施上全面超过美国公司。哪怕暂时还有差距，我也愿意给它们时间，更愿意看到国内公司在竞争中活下来，而不是最后所有人都只能用美国模型。

但支持归支持，价格摆在这里，普通用户还是会做最现实的选择。

一个月一百四十元和一个月五百三十八元，不只是三百多元的差价。它还会直接改变一个人使用 AI 时的心态。

额度足够便宜、足够耐用的时候，我会愿意多开一个 Agent，多试一种方案，让它再检查一遍，甚至允许它失败几次。因为我不需要一直想着还剩多少额度，也不用判断这个问题“值不值得问”。

可一旦价格高、额度又不够经用，人的第一反应就会变成节省。少问一次，少试一种方案，能自己凑合就先不调用模型。

而 AI 恰恰是一种越用越能感受到价值、越用越能学会怎么使用的工具。

我担心的不是一个套餐贵了

只拿 ChatGPT Plus 和 GLM Pro 两个套餐作比较，当然不能代表整个中美 AI 行业。

国内还有很多便宜的 API、开源模型和免费产品。不同模型的能力、额度算法和适用场景也不完全一样。今天的价格可能过几个月又会调整，所以从两张价格表直接推导出一个宏大结论，多少有点以小见大。

但我真正担心的，并不是 GLM Pro 一个月贵了几百元。

我担心的是，如果美国用户能用更少的钱获得更多 AI 能力，他们尝试和使用 AI 的意愿自然会更强。更多人会把 AI 真正放进工作流里，允许它参与写代码、做研究、处理文档和完成各种日常任务。

这种差距不会只体现在某一张模型排行榜上。

它会变成每个人多做的几次尝试、每家公司多跑的几个实验，以及每个产品多完成的几轮迭代。时间一长，模型带来的效率提升会继续叠加，原本的差距也可能被进一步放大。

也许这只是我在 7 月最后一天的一次无病呻吟。

我也真心希望半年以后再回头看，会发现这份担忧完全多余，国产模型已经靠能力和价格把差距追了回来。

但当 AI 越来越像一种基础生产工具时，谁能更便宜、更放心、更大量地使用它，可能真的和谁能造出最强的模型一样重要。

AI 中转站最大的幻觉，就是让你以为自己占了便宜

Wed, 01 Jul 2026 10:50:00 +0800

自己把 sub2api 搭起来作为个人使用的 GPT 中转站之后，我对网上那些 AI 中转站，反而警惕了很多。

因为很多东西，作为普通用户去用时感受并不明显。无非就是觉得它便宜、方便、模型多，好像花小钱就能办大事。

但等你真的把这样一套东西自己搭一遍，把后台的模型映射、转发逻辑、倍率计费这些配置都看清楚之后，你就很难再对所谓“良心中转站”抱什么天真的想象了。

我现在的感觉很直接：AI 中转站最大的幻觉，就是让你以为自己占了便宜。

这里说的“幻觉”，首先是人的幻觉。你以为自己更省钱了、用到更强的模型了、拿到更高的性价比了，实际上很多时候只是把风险和损耗一起买回来了。

1. 最基础的问题：毫无数据安全可言

这一点其实最好理解。

中转站本质上就是代理层。你的提示词先发给它，它再替你发给真正的模型；模型返回的内容，也先回到它这里，再转给你。

这意味着，你的提示词和响应内容，它都能明文看到。

所以只要你聊的是工作内容、业务数据、个人隐私，理论上都已经完整经过了第三方的手。很多人平时对这件事没感觉，只是因为界面上看起来和官方差不多，但底层根本不是一回事。

2. 提示词不只是会被看，还可能被改

既然中转站能看到你的明文提示词，它当然也能改。

普通站长未必一定会这么做，但问题不在于“他会不会”，而在于“他有没有这个能力，而你没法验证”。

更何况，OpenAI、Anthropic 这类厂商本来就不希望自己的 API 被放进各种灰色中转体系里二次分发。无论是批量注册账号、共享订阅账号池，还是盗刷 API key，本质上都在违反官方条款。

这就意味着，很多中转链路天然处在一种不透明、甚至带点对抗的状态里。你看到的是自己写下的提示词，但真正发到上游的内容，中间有没有被改写、压缩、注入额外指令，普通用户根本无从确认。

而这还会带来另一个问题：模型更容易出现幻觉。

因为模型输出质量本来就高度依赖输入是否准确。如果提示词在中间链路里被改过、压缩过、加过别的系统提示，模型收到的就已经不是你原本想表达的那个问题了。输入一旦失真，输出自然更容易偏、编、胡说八道。最后你看到的是模型在幻觉，实际上可能是中转链路先把问题弄歪了。

3. 你以为自己在用大模型，实际可能早就被换了

这一点是我自己搭 sub2api 时感受最深的地方之一。

sub2api 里有个很方便的功能，就是模型映射。简单配一下，就可以把前端传来的模型名，映射成后端实际调用的另一个模型。

这个功能对个人自用当然没问题，但落到第三方中转站手里，就很危险。

因为用户以为自己选的是某个贵模型、强模型，后台完全可以悄悄给你换成更便宜的模型。你以为自己在用 GPT-5.5 xhigh，它实际可能给你转成 GPT-5.4 mini，你根本不知道。

这不只是“货不对板”，还会进一步放大模型幻觉。因为便宜模型本来能力就可能更弱，再叠加中转链路里的提示词失真，最后你看到的内容当然更容易不稳定、更容易胡编。

很多人会把这种表现理解成“今天模型状态不好”，但更真实的可能是：你从头到尾就没用上自己以为的那个模型。

4. 它还可以直接放大你的 token 消耗

sub2api 里还有一个很现实的功能，就是可以给某个用户组单独设置使用倍率。

这意味着什么也很直接：你真实消耗了 1M token，平台完全可以按 2M 甚至更高给你记。

前台再配一个余额系统、套餐系统、赠送额度系统，普通用户基本很难核对真实消耗。结果就是，它既能在模型质量上给你降配，也能在 token 账单上给你加价，两头都能吃你。

最后

所以我现在对 AI 中转站的看法已经很直接了。

也许有人确实不在乎数据安全，但后面这几件事才是更现实、也更必然的问题：

你的提示词可能被改
你真正调用的模型可能被换
你的 token 消耗可能被放大
而且这整条不透明链路，还会让模型更容易出现幻觉

说到底，你根本不用深究中转站原理，只要拍脑袋想一想就够了：

一个中转站给你的价格和用量，怎么可能长期比 Claude 和 GPT 官方服务还便宜？

它又不是做慈善。

所以与其在这种地方赌“也许没事”，不如直接用官方服务。贵归贵，至少你用到的模型是真的，消耗也更接近真的，输出质量出了问题，锅也至少是明确的。

一句话总结就是：

用中转站最好的预期后果，也不过是花大钱办小事。

做了两个 Skill 之后，我对“怎么写好 Skill”有了一些新理解

Tue, 23 Jun 2026 15:50:00 +0800

最近一方面是想让自己平时工作更顺手一点，另一方面工作上又正好有 Skill 比赛，我就连续做了两个自己的 Skill。做完以后回头看，技术细节当然有不少，但我现在最想先记下来的，其实是一些更偏方法论的感受。

因为我感觉，这两次折腾下来，自己对“Skill 应该怎么做”这件事，确实比之前想明白了一点。

第一个 Skill：做得太重了

我做的第一个 Skill，是一个辅助自己在同一个 workspace 里做前后端全栈开发的 Skill。

一开始的思路其实很自然：既然都做了，那不如尽量完整一点。于是除了前后端同步开发本身，我还往前扩了一层需求分析、影响范围分析，往后又补了一层四角色 code review，再加上一些我自己的开发习惯和细节偏好，慢慢全塞了进去。

从个人使用体验来说，体感其实还可以。但后面拿去参加比赛，先上传到 SkillHub 做自动化评测，我才比较明确地意识到问题在哪。

评测里有触发准确率、功能执行质量和 token 消耗量。前两项我的得分还行，第三项就比较难看。看到结果的时候我几乎立刻反应过来了：这个 Skill 确实还是包装得太重了。

很多时候我们会本能地觉得，功能更全一点总是好的。但 Skill 这种东西，可能恰恰不是这样。你塞进去的目标越多、流程越长、依赖越复杂，它就越容易变成一个看起来很强、但实际代价也很高的东西。

所以第一个 Skill 做完以后，我最大的反思不是“还不够强”，而是：我是不是一开始就想做得太大了。

比赛展示时，我又暴露了另一个问题

后面到了复赛 presentation 环节，我是第一个讲。现在回头想，那个过程也挺说明问题的。

我讲的时候就已经隐隐感觉到不太对。不是完全没内容，而是讲得有点太宏观了，不够落地，也没有把重点放在一个更关键的问题上：

评委到底想听什么，想了解什么。

我当时更像是在讲理念、讲覆盖面、讲整体设计，但评委显然更关心两件事：

有没有足够具体的示例和效果展示
这个东西是不是有较强的推广性

这两点，我觉得自己都做得不太好。展示不够具体，推广性也讲得不够扎实。现在看，估计得奖大概率是没戏了。

不过这件事对我也不是坏事。它至少让我意识到，做一个 Skill，不只是把东西做出来，还得想清楚：它到底解决了一个什么问题，这个问题是不是足够真实、足够具体，也足够容易被别人理解和复用。

第二个 Skill：开始收了

后来又有一个类似的比赛，我就不太想再闭门造车了。

有了上一次的经验之后，我这次最直接的想法就是：不要再试图一下子包太多东西，而是先专注地把一个问题解决好。

所以这次我的选题换成了自然语言转 SQL。

这个需求不是我拍脑袋想出来的，而是领导之前确实提到过，是一个真实存在的痛点。而且这种题目也天然比一个高度绑定我个人工作流的全栈开发 Skill，更容易讲清楚价值和推广性。

现在我已经先做了一个版本方案，准备后面继续往下做。

这次我也没有再完全闷头想，而是顺手研究了一下类似的产品，比如 vanna.ai。它整个盘子铺得比较大，功能也很多，但我还是找到了一点我觉得很值得拿来用的思路：在自然语言输入之后，先增加一层语义理解、抽取和标准化。

我觉得这一层挺重要的。很多时候，自然语言转 SQL 真正难的，不是最后那句 SQL 怎么拼，而是用户输入本身就很模糊。如果中间没有一层先把表达整理干净，后面直接硬转，其实很容易漂。

这段时间我总结下来的几点心得

除了看竞品，我也顺手看了一些关于怎么写好 Skill 的文章。边看边结合这两次实践，我现在大概有这么几个心得。

1. 做渐进式披露，`skill.md` 不要太胖

这是我感触最深的一点。

skill.md 如果一上来就什么都写，背景、流程、分支、细则全堆进去，最后往往就是又重又难读。对模型来说不一定稳定，对 token 来说也很浪费。

我现在越来越认同一种结构：中心短，辐射厚。

也就是 skill.md 本身只放最核心、最高信号的流程和判断，其他细节按需拆到别的文件里，需要的时候再读、再执行。这样既更省 token，也更不容易让主干被细节淹没。

2. 写完之后一定要测试

我现在会觉得，写 Skill 不能写完就算完，最好还是把它当成一种“程序”来看。

至少要验证几个问题：

能不能正常跑
能不能被正确触发
跑出来的结果稳不稳定
它到底是不是真的比不用 Skill 更好

前面几个都比较容易想到，但最后一个问题其实很关键。有时候你做了一套看起来很完整的 Skill，实际一用，却不一定真的带来了明显收益。它可能只是把原本就能做的事，换了一种更正式、但不一定更高效的方式重做了一遍。

所以测试不能只测“能不能跑”，还得测“值不值得用”。

3. 复杂逻辑一定要下沉到 `/scripts`

这一点我现在也基本确定了。

如果 Skill 里有复杂逻辑，尤其是固定判断、重复处理、半结构化数据加工之类的内容，最好还是写成脚本放到 /scripts 下面，不要硬塞在 skill.md 里。

原因也很直接：脚本更稳定、更容易复用、更容易测试，也更省上下文。很多本来可以交给程序去做的事情，如果非要用自然语言写得特别细，最后只会又长又重，还不一定稳。

4. 最后，真的要用 `skill creator`

这个结论我现在也挺明确。

以前可能会觉得，自己手写也不是不行，为什么非要用 creator。但真做了两次以后，我会觉得，skill creator 的价值不只是帮你生成一个壳子，而是能把结构、规范、拆分方式这些基础东西先拉到一个比较合理的起点。

很多时候，人自己写的时候，很容易想到什么塞什么，最后越写越散。用 skill creator，至少能让整个 Skill 的骨架一开始就更规整一点。

最后

如果现在让我总结，这两次做 Skill 最大的收获是什么，我大概会说，不是我学会了多少“高级技巧”，而是我慢慢开始意识到：

Skill 最怕的，可能不是做不大，而是收不住。

第一个 Skill，我更像是在证明“我能把很多东西包进去”；第二个 Skill，我开始尝试去证明“我能不能先把一个问题解决好”。这两种思路看起来只是收和放的区别，但最后做出来的东西，味道其实完全不一样。

至于这次新的比赛最后能不能拿到一个好成绩，我现在也不好说。能拿当然最好，但如果最后还是没拿到，我觉得也没什么关系。因为至少上一次比赛已经让我学到了不少东西，而这一次，我又比上一次更清楚了一点：以后再写 Skill，到底应该把力气花在哪。

当 Codex 当了丞相，朕终于看懂了 Understand Anything

Fri, 05 Jun 2026 23:02:00 +0800

前阵子我还专门写过一篇文章，喷 Understand Anything 喷得挺狠，核心观点就一句：这东西不配那么多星。

现在我准备给它平反一下。

不是因为它突然变强了，而是因为我的使用场景变了。最近我在这台服务器上连续用 Codex 做了两个项目，一个是这个博客，一个是 Godot 项目。整个过程里，我几乎没认真看多少代码，更多只是了解业务层面的东西，知道大概逻辑，然后让 Codex 去推进实现。

做到这里我忽然意识到一个问题：事情是能继续做，但我其实并不真的知道项目整体长什么样。

于是我重新跑了一次 understand，让它生成知识图谱。第一眼看上去还是很唬人，节点很多，结构铺得很开，很容易给人一种“系统已经被看透了”的感觉。但这次我细看之后，发现它确实补上了一块我原本缺的东西：让我对项目结构有了整体上的心里有数。

我现在更像皇帝，不像工匠

这段时间我的开发状态，越来越像站在上层看方向。

我知道项目要往哪走，知道最近要修什么、加什么、优先级怎么排，但真正深入到代码细节里，很多事情其实已经是 Codex 在处理。它去看文件、改实现、查问题、做汇报，我更多是在听汇报、拍板、再调整方向。

这种感觉有点像皇帝看帝国。

我不需要知道每个县衙今天具体发生了什么，但我需要知道疆域怎么分、哪里更重要、整个秩序大概是什么样。不然的话，虽然事情也能推进，心里其实是虚的。

在这个角度上，Understand Anything 给出的知识图谱就很像一份疆域图。它不能替代真正读代码，更不能替代排障和开发，但它能让我对整个项目的大致轮廓有感觉，这一点反而挺重要。

为什么我以前会觉得它没用

我之前拿它去理解的是工作里的后端项目。那个项目文件很多，但更关键的是，我本来就已经很熟了。模块怎么分、链路大概怎么跑、哪里是重点，我自己心里已经有一套模型。

所以它再给我生成一张知识图谱，我看到的就只是一大堆文件被更整齐地排了一遍。没有增量信息，自然也就感觉毫无用处。

这不是它完全没价值，而是那种场景本来就不适合它。对于一个你已经非常熟的项目，它很难超过你自己的脑内地图。

但对陌生项目，它确实有价值

这次不一样。最近这两个项目，无论博客还是 Godot，我对技术栈都不算熟。很多时候我能判断业务目标对不对，但如果让我只靠自己快速进入代码层面，其实并不现实。

在这种情况下，知识图谱的价值就出来了。它服务的不是“已经完全懂项目的人”，而是像我这种：

对项目还不够熟
对技术栈也不够熟
又在大量依赖 AI 推进开发

这时候它的意义就不是“替你理解代码”，而是帮你快速感知项目，建立一个全局印象。

这样一想，我反而有点理解它为什么会有这么多星。很多人未必真的了解自己手头的项目，或者至少没有一个稳定、清晰的整体印象。尤其在 AI 越来越占主导之后，大家更需要这种能快速生成总览图的东西。

最后

所以我现在对 Understand Anything 的看法，已经没有之前那么刻薄了。

它不是神器，也不是能让你从此不读代码的东西。如果你本来就非常了解项目，它大概率只会显得花哨。但如果你面对的是陌生项目、陌生技术栈，而且开发过程里 AI 已经承担了大量具体事务，那它确实能帮你建立一种“我至少知道这个帝国长什么样”的把握感。

这不一定直接帮你写出更多代码，但会让你心里踏实不少。

AI 让写代码变容易了，但做产品为什么还是这么难

Mon, 01 Jun 2026 15:18:00 +0800

从 2024 年下半年开始，我就在比较激进地让 AI 帮我写代码。到现在为止，自己真正亲手敲代码的比例已经很低了，算是一个偏激进的 vibe coding 实践者。

这半年多下来，感想很多，而且很杂。但如果要把它们收束成一句话，我现在最深的感受其实不是“AI 好强”，而是：

AI 让写代码这件事越来越不难了，但把一个产品真正做出来、做对，依然很难。

这两天我给自己的 blog 做了一个欢迎页，灵感来自 Norris 的个人主页。现在回头看，这个需求本身其实一点都不复杂，无非就是想做一个看起来更完整、更有进入感的首页。

但真正折腾起来，从作图、改图，到写代码、改代码，再到反复调整视觉和交互细节，前前后后磨了很久，也消耗了不少 token。最后我很明显地体感到，问题并不在于 AI 不会写，也不在于它能力不够，而在于我自己对需求的描述还不够准。

很多时候，第一次描述不够清楚，出来的结果就会和预期有偏差；等你开始纠错时，如果纠得太猛，又很容易矫枉过正，直接偏向另一个方向。越改越歪，到最后甚至会觉得还不如推倒重来。

所以这篇文章我想写的，不是“AI 会不会取代程序员”，也不是“AI 编程工具哪个好”。我更想记录的是，在 AI 把开发能力快速拉平之后，真正难的东西到底还剩下什么。

写代码

第一层当然还是写代码本身。但现在我越来越觉得，AI 带来的变化，早就不只是“帮你实现一个 function”这么简单了。

它可以参与的层次非常多：表结构设计、模块拆分、程序层级设计、接口定义，甚至是更上层的系统设计和架构设计。很多过去要依赖高级工程师、架构师、甚至技术负责人长期积累的能力，现在都可以通过 AI 先给你一个相当像样的起点。

某种意义上说，它真的很像一个高级架构师，但又不止是架构师。因为它不只是站在上面画图，它还能顺手把底下那部分实现也一起补上。

所以如果你在让 AI 写代码的时候，不是把输出丢在一边自己去刷短视频，而是真的顺手看看它怎么拆问题、怎么组织代码、为什么这样设计，那其实是一个很高频、很廉价的学习过程。

你会看到它怎么命名，怎么分层，怎么补边界条件，怎么从一个模糊目标一步步落成可以执行的代码。这种学习未必系统，但胜在密度极高，而且贴着真实问题。

也正因为这样，我现在很难再把“开发”理解成单纯的体力活。至少在很多场景里，开发本身已经不再是最难的一环。真正的问题开始转移了。

理解需求

我刚上班那会儿，其实一直有一种很强的偏见：产品经理到底有什么用？

在当时的我看来，这个角色无非就是把用户说的问题整理成文档，再拉着大家开会，像是一个被强行安插出来的中间层。很多时候你甚至会觉得，需求如果直接给开发，不是更快吗？

现在回头看，我觉得当年的判断只能说对了一半。不是产品经理这个角色没用，而是某些产品经理没用，所以才让我长期没有真正感受到“理解并梳理需求”到底有多难，也有多重要。

这两年我的实际工作环境里，组内并没有一个强存在感的产品经理。很多需求最后都要靠自己去理解、去拆、去梳理。以前总觉得这部分只是开发前的准备动作，现在才发现，它本身就是非常核心的一段工作。

尤其是在 AI 参与开发之后，这种感受更明显了。因为 AI 可以帮你梳理需求，可以陪你反复讨论，也可以根据你的描述快速往下推进，但前提是你自己得先把问题理解到一定程度。

如果你连自己要解决的到底是什么都没搞清楚，那 AI 只会非常高效地帮你把坑挖得更完整一点。最要命的是，梳理完需求之后，下一个负责开发的人往往还是你自己。既然最后埋单的人还是自己，那前面就更不能随便给自己埋坑。

所以我现在越来越能理解，为什么一个好产品经理会稀缺。不是因为这个岗位门槛天然有多高，而是因为把一团模糊的想法真正整理成可执行、可验证、可落地的需求，这件事本来就很难。

描述需求

如果说理解需求，是先把事情在自己脑子里想明白；那描述需求，就是进一步把这件事准确地传递出去。

而这恰恰是我最近感受最深的难点。

欢迎页那次折腾就是一个很典型的例子。最后做出来的东西并不复杂，事后看甚至会觉得“这不就是个很简单的页面吗”。但真正麻烦的地方在于，我脑子里其实只有一种模糊的感觉：我想要它更完整一点、更有氛围一点、更像一个入口，而不是一打开就是普通博客列表。

问题在于，这种“感觉”对于人来说也许还能靠来回交流慢慢逼近，但对于 AI 来说，如果你不能把它拆成更具体的约束，它就只能根据自己的统计经验去猜。于是每一次输出都可能“差不多对”，但就是不完全对。

更麻烦的是，当结果偏了以后，纠错也不是一句“改一下”就能解决。因为你自己未必知道到底是哪一层偏了。是排版偏了，还是氛围偏了？是图不对，还是文案不对？是层次不够明显，还是你一开始就给了一个错误方向？

这时候如果只是不断局部修补，很容易出现另一种经典问题：把一个地方修正了，另一个地方又歪了。最后你会发现，真正稀缺的能力不是“指出哪里不喜欢”，而是准确描述自己到底想要什么。

这也让我重新想到那本之前很火的书：《人人都是产品经理》。

这个标题其实可以从很多角度解读。但我现在最新的个人感悟是：产品经理的门槛，不在于一个人是什么教育背景、学的什么专业、是不是科班出身，而在于他有没有能力去理解一件事，并把它描述清楚。

这个能力和 background 关系没有那么大，所以当然可以说“人人都能当产品经理”。

但换一个角度讲，既然这个能力几乎对所有人都开放，那也意味着：人人都很难把它当好。

写文档

还有一个我越来越想加进去的点，是写文档。

我现在会觉得，vibe coding 的时候，写文档不是可有可无，而是非常重要。以前常说“好记性不如烂笔头”，这句话放到 AI 协作里其实一样成立，甚至更成立。

因为你不是在跟一个始终稳定、永远记得上下文的人协作，而是在跟一个能力很强、但会幻觉、会遗忘、会随着上下文窗口变化而丢失细节的系统协作。很多你以为“刚才已经说过了”的前提，只要没有被稳定地落下来，后面就很可能再次漂掉。

所以文档的第一个作用，就是对抗 AI 的幻觉和上下文丢失。

你把关键约束、目标、术语、边界条件、设计取舍写下来，等于是在不断给 AI 立锚点。这样它后面无论是继续写代码，还是继续帮你分析问题，偏航的概率都会小很多。

第二个作用，是维持复杂系统里的逻辑一致性。

系统一旦稍微复杂一点，很多东西就不是某一个函数对不对的问题了，而是不同模块之间是不是还在遵守同一套规则。你脑子里当然可以暂时记住，但只靠脑子记，随着需求变动、文件变多、对话变长，迟早会乱。

这时候文档就不是“额外工作”，而是系统本身的一部分。它负责把那些高层规则固定下来，让你、也让 AI，都能反复回到同一个基准面上。

我自己这段时间总结下来，写好文档至少有两个很实际的经验。

第一，尽量写 Markdown 文档。

不是因为 Markdown 有什么神奇，而是因为 AI 对结构化信息的理解能力，明显强于一大坨没有层级的纯文本段落。标题、列表、编号、表格，这些结构会天然帮它理解“什么是主干，什么是补充，什么是并列，什么是从属”。

第二，文档要分层级写。

不要试图把所有东西都堆在同一篇长文里。目标、背景、核心原则、模块设计、边界条件、待确认事项，最好分层组织。这样不只是人看起来轻松，AI 在引用、总结、续写的时候也更稳定。

所以我现在的感受已经和以前完全不一样了。过去我会本能地排斥写文档，总觉得那是行政负担，是“真正写代码之前”或者“写完代码之后”才不得不补的一件事。

现在我越来越觉得，文档本身就是编程的一部分。不是因为流程要求你写，而是因为你如果想把 AI 真正用好，想让一个复杂系统在多轮协作之后还能保持一致，那你就必须主动把文档写好。

最后

所以如果今天再让我总结，AI 时代做产品最难的点到底在哪，我的答案大概不是“技术实现”，而是另外四件更靠前的事：

你能不能借助 AI 学会更高层次地思考代码
你能不能在开工之前先把需求真正想清楚
你能不能把自己想要的东西，描述到足够准确
你能不能把关键认知沉淀成文档，稳定地传递给未来的自己和 AI

开发门槛在下降，这几乎已经是一个越来越明显的事实了。但也正因为开发变容易了，过去那些被技术门槛遮住的问题，反而会越来越暴露出来。

以前做不出来，我们可以怪技术太难；以后做不好，很多时候就只能承认，是我们还没有想清楚、没有说清楚，也没有记清楚。

三箭齐发：Codex、Claude Code 与 OpenCode 的选型对比

Fri, 29 May 2026 15:50:00 +0800

最近我在同时用三个 AI 编程工具：Codex、Claude Code 和 OpenCode。它们看起来都是"AI 帮你写代码"，但定位和能力差别其实挺大。

这篇文章先把核心差异列清楚，再说说我目前是怎么分工用的。

一、三个工具的核心差异

直接上表格，只列事实：

维度	Codex	Claude Code	OpenCode
厂商	OpenAI	Anthropic	开源社区
开源	闭源	闭源	Apache 2.0
模型	GPT 系列	Claude 系列	多模型可选（OpenAI / Claude / Gemini / 第三方）
运行方式	云端	本地 CLI	本地 CLI / 服务端部署
插件机制	无	无	有
MCP 支持	不支持	支持	支持
CI 集成	有限	有限	原生支持
定价	API 按量计费	$20/月 + API 按量	开源免费，模型费用另计
国内访问	需代理	需代理	取决于所选模型
典型场景	IDE 内代码补全与生成	复杂重构 / 多文件协作	自动化 / CI / 服务端运行

几个差异展开说一下：

模型绑定：Codex 绑定 OpenAI 的 GPT 系列，Claude Code 绑定 Anthropic 的 Claude 系列。OpenCode 不绑定特定模型，可以自由切换。

运行形态：Codex 目前主要通过 ChatGPT / API 形态提供服务；Claude Code 是本地 CLI 工具；OpenCode 同时支持本地 CLI 和服务端部署，后者适合跑在服务器上做自动化任务。

开源程度：OpenCode 是三者中唯一开源的（Apache 2.0），可以看源码、改源码、自托管。Codex 和 Claude Code 都是闭源产品。

MCP 支持：Claude Code 和 OpenCode 都支持 MCP（Model Context Protocol），Codex 暂不支持。

二、我目前的使用分工

基于上面的差异，我目前的分工是：

写代码：用 Codex，GPT 模型的代码生成能力在补全场景下表现不错
复杂重构：用 Claude Code，适合跨多文件的 Agent 操作
服务端自动化：用 OpenCode，可以跑在服务器上做代码 review，模型选择灵活

三个工具不冲突，各自干各自擅长的事。这个分工以后可能会随着使用深入而调整。

三、关于深度使用

说实话，Claude Code 和 OpenCode 我目前都还没有太深入地使用。Claude Code 刚装上不久，OpenCode 也是最近才在服务器上跑起来，主要任务就是给代码做 review。

等以后有了更多实际使用心得，再单独写后续文章。这次先把差异点和分工逻辑理清楚，算是一个阶段性的记录。

雷总大气：1 分钱的 Mimo，在服务器上跑起了 OpenCode

Fri, 29 May 2026 15:02:00 +0800

最近一直在用 Cursor 和 Claude Code 写代码，但一直觉得缺一个能在服务器上长期跑着、随时能调的 AI 编程助手。

本地 IDE 的助手虽然方便，但机器不能一直开着，网络出口也时好时坏。而且我最近在大量用 Codex 写代码，写完之后没人 review——让 Codex 自己 review 自己总觉得不太对味，相当于考试自己改卷。

所以目标很明确：在服务器上装一个 AI 编程 CLI，专门用来 review Codex 的代码。

一、装 OpenCode 本身倒没什么坑

安装 OpenCode 就是一条命令的事：

curl -fsSL https://opencode.ai/install | bash

脚本会自动检测系统架构，下载二进制，装到 /usr/local/bin。装完验证一下：

opencode --version
# 1.15.12

干净利落。真正的坑在后面。

二、装 Oh My OpenCode，服务器突然没了

OpenCode 是个 CLI，装完之后还需要装 Oh My OpenCode 这个插件来增强能力。

开始装：

npx oh-my-opencode install

它会问你有哪些 AI 订阅。我坦白说一个付费订阅都没有，但我有 Z.ai 的 Coding Plan，所以选了那个选项。

然后装到一半，服务器突然没响应了。

SSH 窗口卡死，我等了几分钟没反应，关了重连——结果连不上去了。我平时登录服务器用的是 TAT 的免密登录，那天怎么试都提示认证失败。VNC 登录页倒是能打开，但输密码进去也解决不了问题，界面卡在那边不动。

当时心里一凉。毕竟这是我第一次用 opencode，刚装上就搞崩服务器，第一反应就是：是不是这软件有什么问题？

后来实在没办法了，在云控制台点了重启。重启花了整整六分钟，比我印象中慢很多，中间一度担心会不会起不来了。好在最后顺利恢复了。重启之后一切正常，SSH 能连，TAT 免密也回来了。

虽然到现在我也不知道那次卡死到底是什么原因——可能是 npm 装依赖时内存吃紧，也可能是巧合的系统波动——但总之，「万能的重启大法」又一次救了我。

继续把安装跑完，这次很顺利。顺便提一句，刚开始我用 Ctrl+V 粘贴命令死活没反应，后来才意识到终端里得用 Ctrl+Shift+V——这个认知成本大概浪费了五分钟。

三、模型从哪来？我选了 1 分钱/月的 Mimo

装完之后有个现实问题：模型用谁的？

OpenCode 自带的 opencode/ 系列模型能用，但如果想找个稳定的日常编码模型，还是得接第三方。

我选了 Mimo。原因很直白：便宜。最低套餐 1 分钱/月，对于个人开发者来说约等于不要钱。说实话一开始我都不太信，1 分钱能买啥？但查了一下发现是真有这么个套餐，果断下单。谢谢雷总，雷总大气。

配置方式是改 opencode.json，在 provider 里加一段 Mimo 的配置，填入 API Key 就行。Mimo 兼容 OpenAI 的接口格式，所以 OpenCode 可以直接通过 @ai-sdk/openai-compatible 接进来。

接入之后，日常 review 代码就用 mimo-v2.5-pro，够用。

四、所以服务器上的 OpenCode 到底在干什么

装好之后，它的核心任务只有一个：给 Codex 写的代码做 review。

我现在的流程大概是这样：

本地用 Codex 写代码，写完 git push
服务器收到 Webhook，拉取最新代码
跑 OpenCode 对 diff 做审查
审查结果发到 PR 评论区

审查指令大概长这样：

opencode --model mimo-v2.5-pro \
  "review 最近一次 commit，重点看：
   - 有没有空指针或类型错误
   - 代码风格是否统一
   - 逻辑有没有明显遗漏"

这个指令可以直接塞进 Git hooks 或者 CI 脚本里。每次 Codex 提交完代码，服务器自动 review 一轮，有问题直接写在 PR 里。

多了一步审查，代码心里更有底一些。

五、一个意外发现：我一直在用免费模型

装好 OpenCode 之后，我截了几张配置和运行效果的图发给同事分享。结果同事看了一眼问我：“你用的是哪个模型？”

我一看，才发现 OpenCode 默认连的是它自带的免费 opencode/ 系列模型，而不是我刚配好的 Mimo。

也就是说，我前面跑了好几轮 review，全都是在用免费模型干活。效果居然还行，但既然已经买了 Mimo 的 1 分钱套餐，不用白不用。

赶紧在 OpenCode 里 /model 切换成 mimo-v2.5-pro——1 分钱也是付费，得用起来。

这个小插曲提醒了一件事：装完工具之后一定要确认当前生效的模型是什么，别像我一样默认跑了一圈才发现用的不是自己想用的那个。

六、总结

这次在服务器上装 OpenCode，整体还算顺利，中间服务器卡死那次吓了我一跳，但重启大法救回来了。

最终状态是：服务器上跑着 OpenCode + Oh My OpenCode，接 Mimo 的 1 分钱模型，每次 Codex 提交代码后自动 review。相当于给 AI 写的代码加了一道 AI 审核，虽然听起来有点套娃，但实际效果还不错。

再次感谢雷总，1 分钱的模型，真的香。

把 Understand-Anything 折腾进 Codex 之后，我得到了一件美丽废物

Tue, 26 May 2026 15:20:00 +0800

最近我看到一个叫 Understand-Anything 的 GitHub 项目，星数很高，第一眼看上去就属于那种“好像很强”的东西。

我当时的直觉很简单：既然这么多人点星，而且项目名字也很直接，那大概率是个能快速帮助我理解代码库、梳理系统结构、减少上手成本的工具。于是我干脆把它整进了 Codex，作为一个 skill 来试。

结果折腾完一圈，产出看起来挺华丽：

知识图谱
新人指南
后端项目理解摘要
一套像模像样的“系统认知结果”

但真正落地时，我的感受只有一句话：

这是个美丽废物。

这篇文章记录一下这次尝试的全过程，也顺便谈谈我对这类“看起来很牛的理解型工具”的一点判断。

一、Understand-Anything 是什么

Understand-Anything 从名字上就很有野心，它的目标并不是只看某一类文档，也不是只做一个简单摘要器，而是试图借助大模型能力，把一个复杂对象“解释清楚”。

从项目定位来看，这类工具通常会强调几件事：

输入一份代码库、文档集或系统资料
自动抽取关键结构
生成模块关系
输出知识图谱、架构理解、上手指南之类的结果

如果说普通摘要工具解决的是“把一段内容缩短”，那这类项目想解决的是另一个更大的问题：

能不能让一个新人，快速建立对复杂系统的整体认知？

这也是为什么它很容易吸引人。因为这个命题本身太诱人了：

面对陌生项目时，大家都想要一份高质量的导览图
面对复杂后端时，谁都希望有一个能自动生成的上手说明
面对遗留系统时，任何“帮我理解”的工具都会天然有吸引力

所以它受欢迎，并不奇怪。

二、为什么我会想把它接进 Codex

我真正感兴趣的不是单独跑一下这个项目，而是把它并进自己的工作流里。

因为如果它真有用，那最理想的落地方式并不是“偶尔单独打开一次”，而是：

把它接进 Codex
作为一个 skill 使用
在需要理解新项目时直接调用
自动产出结构化认知结果

这个想法听起来非常合理，甚至有点高级。

如果这条路走通，理论上会得到一个相当诱人的工作流：

把项目喂进去
自动生成系统概览
自动梳理模块关系
自动输出新人指南
后面再由我自己做精修和验证

从纸面上看，这几乎就是“理解型 AI 工具”的理想形态。

于是我就真的开始做了。

三、为了它，我不只是试了一下，而是认真折腾了

这次我没有停留在“看一眼 README”这种程度，而是确实把它落到了自己的使用环境里。

我做了几件很具体的事：

把项目整到 Codex 里，作为 skill 使用
拿它去理解一个后端项目
让它输出知识图谱和新人指南
为了效果更好，还专门把模型切到了 gpt-5.5 high

这一步其实已经不是“随便试玩”了，而是一次有明确预期的正式试用。

更直接一点说，我愿意为它投入成本，是因为我真的想验证：

它到底能不能把“理解系统”这件事，从一种高消耗脑力活，变成一种可复用流程。

而这次试用成本也不算低。

我最后看了一下消耗，光这次尝试就用了：

模式：gpt-5.5 high
时间：前后折腾了两个多小时
Token：2.89M

这已经不是“玩一玩”的级别了。

四、它产出的东西，确实一眼看上去很厉害

必须承认，这类工具最擅长的一件事，就是制造“理解已经发生”的感觉。

它输出的内容非常容易给人留下好印象：

知识图谱看起来结构分明
模块关系像是被梳理清楚了
新人指南看起来也像那么回事
文字组织通常比随手写的笔记更规整

如果只是把结果截图给别人看，很容易收获一句：

“这个东西好强。”

这就是它最有迷惑性的地方。

它不是完全没产出，恰恰相反，它太会产出“像成果的成果”了。

这些内容在视觉上、结构上、叙述上，都很容易让人产生一种认知错觉：

既然已经有图谱、有模块说明、有新人指南，那我是不是已经理解这个系统了？

但真正的问题在于，形式上的完整，不等于工作上的有效。

五、问题不是它做不出内容，而是这些内容对我没有实际作用

当我真正回到自己的目标上时，问题就暴露出来了。

我想要的不是一个看起来完整的“理解结果”，而是下面这些更具体的东西：

我接下来应该先看哪几个文件
哪个模块才是系统的核心控制流
一个请求从入口到落库到底怎么走
哪些地方最容易改坏
如果我要加一个功能，第一刀应该切在哪里

但这类工具最终给我的，更多是“高层抽象认知”，而不是“可直接拿来干活的路径”。

说得更直白一点：

它很会帮你整理“像全局视角的东西”
但不太擅长帮你找到“下一步到底该动哪儿”

而在真实开发里，后者往往比前者更重要。

因为大多数时候，我不是缺一张看上去很漂亮的系统地图，而是缺一个能让我今天下午就动手改代码的判断依据。

六、知识图谱和新人指南为什么会沦为美丽废物

我后来反复想了一下，为什么这次结果会让我这么失望。

结论并不是“它完全没价值”，而是：

它产出的价值，更偏展示型、归纳型，而不是行动型。

1. 它容易停在正确但无用的层面

比如：

把项目分成几个模块
概括每个模块负责什么
总结系统的整体职责

这些话很可能都没错，但也正因为太“没错”，所以很难直接指导行动。

一个新人真正需要的，往往不是“模块 A 负责用户管理”，而是：

模块 A 的入口文件在哪
初始化顺序是什么
调用链上游下游分别是谁
改这里会不会影响鉴权、缓存或数据库

这两者之间有巨大差异。

2. 它会给你“已经理解”的幻觉

这是我觉得最危险的一点。

有了知识图谱、新人指南、总览说明之后，人很容易对自己的理解程度产生误判。

你会觉得：

结构我看过了
模块我知道了
系统图我也有了

但真等你去改第一段代码时，依然会发现自己还是得：

回到源码
跟踪调用链
看日志
打断点
手动验证

也就是说，那些漂亮产出并没有真正替代掉最核心的理解过程。

3. 它更像管理视角的材料，不像工程视角的工具

很多这类内容，如果拿去做汇报、做入门展示、做高层概览，其实并不差。

但如果你的目标是：

排障
加功能
改逻辑
理清耦合点

那它的帮助就会明显下降。

我后来越来越觉得，这类工具天然更擅长生成：

看起来很像文档成果的东西

而不是：

真正能减少工程试错成本的东西

七、这次最让我不爽的，不是它没用，而是我认真投入之后发现它还是没用

如果只是简单试一下然后发现一般，我可能都不会专门写这篇文章。

但这次让我真正想记一笔的点在于：

我不是轻飘飘点开看了一眼
我是真的把它接进了自己的流程
我还专门换了更强的模型和更高的推理档位
我花了两个多小时
我消耗了 2.89M token

最后得到的却不是“这个工具还不错，但需要打磨”，而是：

它非常会展示自己在工作，但没有真正帮我把事情做成。

这是一种很典型的 AI 使用挫败感。

因为它不像传统软件那样明确报错，也不像脚本那样直接失败。它给你的恰恰是一个“看起来已经很努力”的结果。

问题在于，努力不等于有效。

八、最后我还是把它删了

折腾完之后，我没有选择“先留着以后再看”，而是直接删掉。

原因其实很简单：

一个工具如果不能进入日常工作流，就算它偶尔能产出一些漂亮材料，也不值得长期占据我的注意力。

尤其是在 AI 工具越来越多的环境里，真正稀缺的不是“看起来很强的东西”，而是：

能稳定节省时间的东西
能直接提升判断质量的东西
能真正减少手工试错的东西

如果一个工具做不到这些，那即便它有很多星、很多人夸、很多截图效果很好，最终也只是一个陈列品。

九、这次尝试给我的提醒：不要太迷信大众眼光

这件事对我最大的提醒，不是某个具体项目值不值得用，而是一个更普遍的判断：

不要太迷信大众的眼光。

GitHub 星数高，说明它有传播性、话题性、展示性，甚至说明它确实抓住了一个大家都在痛的需求。

但这些都不等于：

它适合我的工作流
它能解决我的具体问题
它值得我长期保留

大众筛选出来的，很多时候只是“值得你看一眼”的项目。

至于它是不是“值得你真正接入自己的系统”，只能靠自己动手试。

十、最后的结论很土，但大概率也最可靠

这次折腾到最后，我反而得到了一个一点都不新潮、但非常可靠的结论：

多动手，多实践。

看到一个很火的项目，最好的处理方式不是：

先相信它
先神化它
先把别人给它的评价当成自己的判断

而是：

自己装起来
自己接进真实场景
自己为它付出一点时间和成本
再根据实际产出做判断

如果有用，就留下；如果没用，就尽快删掉。

这次 Understand-Anything 对我来说，就是后者。

它不是什么灾难项目，也不是骗人的东西。

它只是一个典型的、看起来很厉害、讲起来也很高级、演示起来很漂亮，但放进我真实工作流之后没有产出实际价值的工具。

说到底，还是那句话：

别太迷信大众的眼光，自己试过才知道。

从申请服务器到搭建 sub2api 中转站：一份完整实践记录

Tue, 26 May 2026 13:25:00 +0800

这篇文章记录一下我从零准备一台服务器，到最终把 sub2api 跑起来并作为反代中转站使用的完整过程。

整个过程并不是单点安装某个程序，而是一条完整链路：

先选服务器
再选域名
配好基础网络出口
然后部署 sub2api
再接上 Nginx 和 HTTPS
最后完成账号绑定和实际可用验证

如果把这件事拆开看，每一步都不算复杂；但如果第一次做，很容易卡在某一个细节上，比如域名解析、反向代理、证书签发或者出口网络。

一、先做服务器比价，最后选择新加坡轻量云

在真正动手之前，第一步其实不是安装软件，而是先挑服务器。

我当时的思路很明确：这台机器主要是跑一个轻量级中转服务，不是数据库重负载场景，也不是需要高性能计算的业务，所以重点不是极限性能，而是下面几项：

价格是否足够低
海外线路是否相对稳定
带宽和流量是否够用
系统镜像是否方便直接上 Ubuntu
控制台和安全组是否省心

这一类场景里，常见可选项一般会包括：

腾讯云轻量应用服务器
阿里云轻量应用服务器
部分海外 VPS 厂商
传统云服务器标准实例

如果只是部署 sub2api 这种中小型服务，轻量服务器通常比传统 CVM / ECS 更合适，因为：

价格更直接
自带公网 IP
管理界面简单
比较适合个人项目或中小流量工具站

综合权衡之后，我最后选择了腾讯云新加坡区域的轻量云服务器。

这个选择背后的考虑大致有三点：

新加坡区域在亚洲访问延迟相对更友好
对个人用途来说，价格和稳定性比较平衡
后续配域名、Nginx 和证书都很常规，资料比较多

系统方面，直接选择 Ubuntu 就够了。后续所有部署动作基本都围绕下面这些组件展开：

apt
systemd
nginx
certbot
tailscale

二、域名不需要贵，但最好专业、好记、能长期用

服务器确定之后，下一步就是域名。

我当时没有去买特别昂贵或者过于花哨的后缀，而是选择了一个 cloud 结尾的域名。原因很现实：

价格便宜
可选空间相对多
看起来比很多冷门后缀更正式
用在技术服务和工具站上违和感小

对个人项目来说，域名最重要的不是“看起来很高级”，而是：

便于记忆
不容易输错
适合长期续费
作为主域名时不显得太随意

最后我用这个域名同时承载了不同用途：

主服务走主域名
博客走子域名
后续不同组件都可以拆分到不同子域名下

这种方式的好处是结构清晰，后续扩展也方便。

三、先把流量出口问题想清楚：用 Tailscale 把本机作为出口

部署 sub2api 这种服务时，一个非常实际的问题是：服务运行在服务器上，但某些访问链路未必适合直接走服务器本地网络。

所以我当时的处理思路是：

在服务器上安装 Tailscale
把自己的本地设备加入同一个 tailnet
让本机作为出口节点
使服务器的相关流量通过本机出口转发

这么做的核心价值，不在于“更酷”，而在于网络路径可控。

1. Tailscale 的角色

Tailscale 本质上是一个基于 WireGuard 的组网方案。它的优点是：

安装简单
节点互联快
不需要自己维护传统 VPN
可以很方便地指定出口节点

这类方案特别适合：

个人多设备协同
家里电脑和云服务器互通
临时把一台设备当作统一出口

2. 典型操作思路

这一部分大致会包含下面几个动作：

在本机安装 Tailscale
在云服务器安装 Tailscale
登录同一个账号或组织网络
在本机开启 exit node 能力
在服务器侧指定该 exit node

从结果上说，就是服务器虽然部署在云端，但某些流量可以按你的规划经由本机网络出去。

3. 这一步为什么重要

很多人搭服务时，默认认为“服务器能联网就够了”。但实际一旦进入真实使用，网络出口路径、可访问性、登录状态和上游连接稳定性都会影响最终可用性。

所以我认为，Tailscale + exit node 并不是额外花活，而是这类中转服务里非常实用的一环。

四、账号准备：把环境准备和服务部署分开看

这一步我更愿意把它理解为“账号环境准备”，而不是部署本身的一部分。

因为从工程角度看，服务器、域名、代理、证书、服务进程，这些都是基础设施问题；而账号登录、订阅状态、客户端绑定，则更接近上游服务接入问题。

我这里不展开写过细的支付或区域性操作细节，只保留思路层面的经验：

尽量把账号环境准备和服务器部署分开处理
优先保证账号本身状态正常可登录
再去做后面的 OAuth 绑定

这样做的好处是排障更清楚。否则一旦失败，你很难判断问题到底出在：

服务器网络
反向代理
HTTPS
OAuth 回调
还是账号自身状态

五、正式部署 sub2api：先让服务能跑起来

当服务器、域名和网络出口都准备好之后，就可以进入真正的服务部署阶段。

这一部分的目标不是先追求“最优雅”，而是先让 sub2api 在服务器上稳定跑起来。

1. 基础环境准备

最常规的准备动作一般包括：

更新系统软件包
安装 Git、Nginx 等基础依赖
准备运行目录
规划监听端口

如果服务本身有独立的启动方式，还需要考虑：

二进制部署
Docker 部署
systemd 托管

从长期维护角度看，我更偏向把服务交给 systemd 或容器托管，而不是单纯用一个前台命令挂着。

2. 先本地端口可访问，再接入反代

这一类服务的正确调试顺序通常是：

先确认程序在本机端口已经成功启动
再用 curl http://127.0.0.1:端口 验证是否有响应
最后才挂到 Nginx

如果一上来就把所有东西混在一起，很容易出现：

服务本身没起来
Nginx 也没配对
证书还没签

然后排障就会变得很乱。

六、Nginx 反代：把服务挂到域名上

sub2api 真正对外可用，关键还是靠 Nginx。

常见结构就是：

上游应用监听本地端口，例如 127.0.0.1:3000
Nginx 对外监听 80 和 443
外部流量先到 Nginx
再由 Nginx 转发给 sub2api

一个典型的反代思路会像这样：

server {
    listen 80;
    server_name chen-api.cloud;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

这里的关键不是把配置背下来，而是理解这几个事实：

应用服务尽量只监听本地
公网入口统一交给 Nginx
反代时要把请求头带完整
后面签 HTTPS 会更顺

七、HTTPS 证书是上线的必要条件，不是可选项

当 HTTP 反代已经打通之后，下一步就应该立刻上 HTTPS。

这一步通常会用 certbot + nginx 组合完成。它的好处是：

配置直接
自动改 Nginx
自动续期方便

只要满足下面几个条件，一般就可以顺利签证书：

域名已经正确解析到服务器公网 IP
安全组放通了 80 和 443
Nginx 对该域名的 server_name 配置正确
外部可以通过 HTTP 正常访问到站点

完成后，服务会从：

http://chen-api.cloud

变成：

https://chen-api.cloud

这不仅是为了浏览器地址栏更好看，更重要的是：

OAuth 回调通常更依赖稳定的 HTTPS 环境
中转服务对安全链路要求更高
长期使用时也更规范

八、登录 sub2api 后，通过 OAuth 绑定上游账号

当反代和 HTTPS 都打通之后，才真正进入“业务可用”阶段。

这时一般会做下面几件事：

打开 sub2api 的管理界面
登录后台
找到账号绑定或授权入口
通过 OAuth 流程绑定 GPT 账号

这一部分最重要的其实不是“点哪个按钮”，而是确保下面三个前置条件已经成立：

站点已经能被公网稳定访问
HTTPS 正常
回调链路没有被错误代理或拦截

如果 OAuth 绑定异常，大概率优先排查这些问题：

域名是否正确
证书是否正常
Nginx 是否正确转发头信息
服务端日志里有没有回调报错

九、整套链路里最容易出问题的地方

回头看，这一套流程真正容易卡住的地方并不只在安装服务本身，而是在几个看似琐碎的环节：

1. 域名解析没生效

很多“站点打不开”的问题，其实不是程序没跑，而是域名还没指到服务器。

2. 服务没起来就开始配 Nginx

正确顺序应该始终是：

先跑服务
再测本地端口
再接反代
再签证书

3. HTTPS 没配置完整

证书签发成功，不代表整个 HTTPS 链路一定完全可用。还要看：

Nginx 是否正确加载证书
443 是否放行
回调链路是否仍然走错地址

4. 把账号问题误判成部署问题

如果上游账号本身状态不对，哪怕服务器、Nginx、证书全都正确，也依然会表现成“服务不可用”。

所以部署和账号准备必须分开排查。

十、最后的结构其实很清晰

等整条链路走通之后，这套架构本身并不复杂：

一台海外 Ubuntu 服务器
一个正式域名
Tailscale 作为可控网络出口方案
sub2api 作为核心服务
Nginx 负责公网入口与反向代理
Let's Encrypt 负责 HTTPS
OAuth 完成上游账号绑定

从结果上说，这已经是一套足够个人长期使用的中转服务结构。

它未必是唯一方案，也不一定是最“高级”的方案，但对个人部署来说，胜在：

成本可控
结构清晰
易于维护
扩展方便

十一、如果让我再做一次，我会坚持这个顺序

最后总结一下，如果让我重新从零做一遍，我仍然会按这个顺序来：

先选服务器和区域
再买域名并规划子域名
先解决网络出口问题
再部署 sub2api
然后配置 Nginx
最后接 HTTPS 和 OAuth

因为只有按这个顺序，排障成本才最低。

很多时候，真正节省时间的不是命令敲得有多快，而是步骤顺序有没有走对。