三个智能模型进入酒吧:我的编程节省实验

在每个使用编程智能助手的开发者生命中,总有一个时刻,你盯着月结账单看,心想:“这些服务确实很好用,可我的订阅怎么比小区健身房的会员费还多?” 那个时刻就这样悄然降临了。当时我同时订阅了Claude Max 5、Codex Plus,还在考虑加上Z.AI配合OpenCode处理廉价的机械性工作。理论看上去很美好。问题出在这样搞下去,就像一个管理乱糟糟工地的包工头,工人各忙各的,却没人看图纸。 我的初步想法很简单:在自动化分流之前,最好先手动做个小实验,持续两周。规则简单,但明确。 问题不在于成本,而在于协调 分开来看,支付23欧元、90欧元或者10美元一点也不算多。 问题在于,当每个工具开始互相干扰时,就开始麻烦了。你让一个助手思考,另一个实现,再让第一个检查,最后还要麻烦第三个处理一些琐事。二十分钟后,你已经搞不清楚是在优化成本、提升质量,还是单纯地折腾自己不停切换窗口了。 用大白话说:真正的成本不仅仅是订阅费,还有你的上下文切换成本。 就像一个厨房里同时有一把日本刀、一台智能厨师机、和一个空气炸锅。它们各有用处,各有千秋。但如果你用厨师机来炸土豆,那肯定不行。 假设:思考、执行、清理 我想要试验的规则说起来不过三句话: 用Claude进行思考 用Codex完成主要实现 用GLM/Z.AI处理基础任务 这不是学术讨论,而是一条实用的工作坊规则。 当一项任务模糊不清、涉及架构、存在风险或者需要判断时,把它交给擅长推理的代理是最合逻辑的选择。在这个实验中,就是Claude。 而当一项任务已经很明确,需要进入代码库、修改文件、运行测试并在错误间反复调试时,就轮到Codex登场。 至于那些没有人愿意干但必须有人去完成的工作,比如简单的测试代码、文档编写、小脚本处理、文件重命名或机械化的代码重构,那么就让GLM+OpenCode来试试。 暂不考虑的事情 目前还不考虑设置一个自动化分流器。 我不打算弄一个能自动读取提示词、分类任务、选择代理、按时间切换模型,还能输出漂亮图表证明其复杂性的魔法中介层。 这听起来或许是个超级有趣的项目,但也可能事倍功半。 这里最常见的错误是在真正需要航管之前就急着建塔台。先观察好了,再决定是否需要设置交通信号灯。 手动操作的两周实验 我的实验相当朴实,够不上“炫技”,但大概率更有用。 1. 用Claude处理复杂任务 当以下情况之一发生时,我会优先用Claude: 我不确定怎么入手 需要设计决策 存在破坏性风险 需要审查逻辑或论证,而不仅仅是代码 翻译成人话:如果任务需要准确判断,我不会吝啬。 2. 用Codex主导代码库工作 当任务已经清晰时,我会用Codex处理: 实现真实的功能修改 修复测试 带验证的重构 反复迭代,直到项目重新回到稳定状态 在这个阶段,一个好的执行代理最能展现价值。这不是模型本身的问题,而是流程的问题。 3. 用Z.AI负责简单工作 对于Z.AI,规则很简单: 模板代码 初稿 文档 简单的测试 小型脚本 文件重命名 容易检查的机械性操作 即使失败了,也没关系。可以随时丢弃,然后换成别的工具重做。 这才是关键。我不会向GLM要求飞针走线般的精细活,我的目标只是拧几颗螺丝。 最重要的规则:失败两次便升级 这一点是最重要的,但也最容易被忽视。 当一个便宜的工具失败了,你可能会倾向于继续试,“再试一次就好”,“这次应该可以”,“我改下提示词试试”,“再加点上下文”。半个小时过去了,你还在像与“抓狂的打印机”讨价还价一样调整模型。 我的规则是: 如果Z.AI1到2次尝试后仍失败,那我就提升它 如果是执行问题,转交Codex 如果是理解或设计问题,转给Claude 低成本工具一旦浪费掉太多时间,就不再低成本。 我要真正关注的是什么 我对“表演式性能对比”没兴趣。 不会去费劲列出诸如每秒处理字节数、平均延迟这类看起来“很专业”的表格,毕竟我的主要问题还是怎么快速重命名40个符号,而不是花一下午来折腾。 但我要在这两周内统计以下内容: 指标 意义 Z.AI吸收的简单任务数量 它是不是真的帮我减少负担 我有多少次需要提升任务 节省的时间和金钱是否值得 减少的Codex使用量 整体思路是否划算 切换工具的总耗时和难度 系统是否够流畅,易于长期使用 如果实验成功,那再好不过。 ...

2026年3月30日 · Fernando

你的计划.md 需要一个“魔鬼代言人”(Codex 自荐)

你是否曾经在晚上 11 点写了一个技术计划,确信一切无懈可击,但第二天早上发现忘记添加身份验证? 我深有同感,而且不止一次。最糟糕的不是这个疏忽——而是当你用人工智能来规划时,计划听起来是如此连贯,以至于你的大脑停止了对问题的挖掘。Claude 会生成一个带有章节、依赖项和执行顺序的文档,一切看起来都是高级工程师的作品。但问题是,没有人反驳过它。 Aseem Shrey 发布了一篇文章,精准点出了这个问题,并为此提出了一个优雅的解决方案:让第二个模型审查第一个模型的计划。而且不仅仅审查一次——循环审查,直到审查员说“通过”。 问题:没有人反对你的 AI 当你仅依靠一个模型来规划和执行时,你得到的结果确实连贯但没有争议。AI 不会反驳自己。它不会说“嘿,这个身份验证模型不完整”,或者“你的 shell 脚本中的引用有问题”。 这就像你自己写了一份文档,自我审查,然后对自己说“这可真是完美”。当然是完美的——毕竟是你自己写的。注意这个点:同行评审会存在于科学、工程和医疗领域是有原因的。并不是因为作者愚蠢,而是因为创作者通常是自己作品最差的审查者。 我以前在写我的 Jedi 代码审查委员会时讨论过这个问题。不过当时谈论的是如何审查代码。而 Aseem 的建议是先审查计划,在写出任何代码之前就发现问题。这相当于提前一阶段处理问题。 操作方法:Claude 规划,Codex 审查 这个过程基于 Claude Code 的一个“技能”实现——一个 Markdown 文件,无需额外的基础设施或外部服务。当你调用 /codex-review 时: Claude 会将计划写入一个临时文件。 计划会以只读模式发送到 Codex CLI(它可以读取你的代码库获取上下文,但不改动任何东西)。 Codex 审查后会给出结论:VERDICT: APPROVED 或 VERDICT: REVISE。 如果返回的是 REVISE,Claude 会修正计划并重新提交。关键在于,Codex 会恢复之前的会话,因此能够记住它之前的反馈,并验证问题是否真的被解决了。 审查最多迭代 5 次。在实践中,通常 3 次就足够了。 简而言之,这是两个 AI 之间的一次“拉取请求”,一个提出计划,另一个专注于找漏洞。全程无需人为干预。 3 轮迭代解决了 14 个漏洞 在 Aseem 的文章中,以一个多代理系统的控制面板为案例,循环审查从原计划中找到了 14 个问题: 第一轮(8 个问题):写入端点没有身份验证。Shell 脚本的引用存在错误。数据模式的字段冲突。嵌套数组没有限制。未处理并发问题。仅支持手动测试。 第二轮(剩余 6 个问题):非原子操作的声明。ACL 权限分配过于宽泛。未指定密钥轮换机制。状态建模不一致等问题。 第三轮:所有问题解决,计划获得通过。 ...

2026年3月23日 · Fernando

无需 Codex 的 Codex Automations:用 Claude Code 和 systemd 打造夜班代理

两周前,OpenAI 推出了 Codex Automations。简单来说:你定义一个触发器(如 cron、代码 push 或新 issue),写下自然语言指令,一个代理在独立的 worktree 中自动执行这一切。整个过程无需人类介入。在你睡觉时,代理自动整理 issues、总结 CI 错误、生成发布文档,甚至优化自身的指令。 听上去像魔法?确实有几分神奇。但他们在 keynote 里没怎么提到的一个细节是:你必须在桌面上运行 Codex App。支持 macOS 和 Windows。没有无头服务器的选项。安装在一个迷你 PC 上并丢一边任其运行?没门。 这时我想:“等等,我已经有这个了。” 你已经拥有的组件 如果你在使用 Claude Code,那么你已经拥有 90% 的基础设施。用命令 claude --print 就能在非交互式会话中执行提示(prompt)。传递指令,获取结果,关闭,不需要图形界面或者打开的终端窗口。这对于一个 cron 工作来说简直完美。 如果你已有一台永远开机的服务器(比如迷你 PC、树莓派,或者每月 5 欧元的 VPS),那么你已经有了调度程序。systemd 或 cron,任选一个,它们都已运行了多年,已经非常稳定。 如果你在用 Gitea、GitHub 或任何支持 API 的代码托管平台,意味着你已经有了存放结果的位置:PR 评论、新建 Issue 或直接提交文件。 用简单点的话说:Codex Automations 是一种范式,而不是一个产品。而且这种范式已经存在很多年了。 ┌─────────────────────────────────────────────┐ │ systemd timer (每隔 N 小时运行) │ │ │ │ │ ▼ │ │ bash/fish 脚本 │ │ │ │ │ ├── git pull --ff-only │ │ ├── claude --print "prompt" │ │ ├── 解析结果 │ │ ├── 通知 (Telegram/email) │ │ └── git push (如果有变更) │ └─────────────────────────────────────────────┘ 自动化的构成 所有的自动化都遵循同样的结构。一个脚本会经过以下步骤: ...

2026年3月11日 · Fernando