AI编程新时代：如何把Claude Fable与Codex的额度“榨干”到极致？

这几天时间都花在AI脚踏车上了，文章写得少了些。Claude Fable和GPT-5.6几乎同时登场，两家还慷慨地提供了多轮额度重置，眼前的可用额度瞬间膨胀到了创纪录的水平。现在我的头号任务就是拼命把这些额度花出去——也许明天一觉醒来，新一轮重置又来了，要是没花完，可就真的浪费了。

最让我懊恼的是昨天那一幕：Fable第一轮重置之后，我本想这回要省着点用，免得像上次那样两天就把额度烧完干瞪眼。结果才用到20%，官方突然宣布——又重置一轮。唉，真是后悔不已！这可是实实在在的价值损失。

来算一笔账：一周的Claude订阅，如果把Fable的额度拉满，大约能压榨出三五百万token的输出量。按照90%左右的缓存命中率来算，账面价值超过2000美元，折合人民币差不多一万元。想着省着用，结果到期直接清零，等于白白蒸发了八千多块钱。我当场拍断大腿——就算按订阅计费，那也是相当大的经济损失。

这就是“有水快流”的道理：额度这玩意儿攒不住，攒下来的每一分都是亏损，必须可劲地往外花。明天Codex又要迎来一轮重置，今天我正想尽办法、变着花样给它派各种活。

FABLE 5与Codex 5.6的实战体验

这两天新模型发布，我们也在做充分测试。当然，我没那么无聊去专门跑基准测试，但用得多了也就大概心里有数了。理由很简单：让它们互相review代码时，谁能发现对方更多问题，通常谁的洞察力就更强。就这一点来说，我认为Claude Fable还是强于Codex 5.6 Sol。

但Codex的好处是量大管饱，而且我有两个账号，可以尽情地造、使劲地烧。所以在实际使用中，我倾向于做合理分工。Fable想象力狂野、天马行空、极具创意；Codex则是一位稳定可靠的执行者。要把两边的长处都榨出来，工作流应该这样安排：用Fable做顶层设计，输出总体Design；让Codex照着做具体实现；然后Fable/Opus与GPT 5.6轮流进行Review，收敛质量。

举一些具体例子。如果是命令行工具或后端数据库项目，我说解决了什么问题，大家可能对质量没有直观感受，那我们就聊聊前端，差别还是非常明显的。

比如今天我改造了Pigsty（pigsty.cc和pigsty.io）的官网。早先在Claude Opus 4.6时代，是让Opus自由发挥做的，效果比较一般。现在我用Claude Fable让它重新设计改进，保留原有的文案，只是优化形式。左边是改版后的页面，右边是原来的样子。

现在这个版本比之前要好太多：官网的整体视觉和形式有了很大优化。文档站也焕然一新——我甚至让它把Docsy文档框架的CSS按照这个风格重新定制了一遍。只用了半个小时，整个文档站就完全变了样，我只在后面微调了两三轮，基本上就直接上线了。现在大家看到的文档站已经是全新的。

再比如一些从零起步的项目。我手头有一份PG扩展仓库的元数据，我对Fable说，你能不能帮我做一个网站，让用户可以搜索扩展，并把信息更优雅地呈现出来。

也是十几分钟的事，它就直接给我糊出来一个新版本的网站，一把搞定，我觉得看上去还真不错。Fable的能力确实很强，按我的标准，能比得上一个全领域阿里P8的水平。

血泪教训

千万不要在Claude Code里开着UltraCode模式跑任务。

我手贱开了Ultrathink，再挂上Workflow跑一个Code Review任务，结果一个任务下来，五小时的额度直接被干穿，周额度也从0一口气烧到了20%。如果按API计费，这一把火等于烧掉了4000块钱，看得我目瞪口呆。

用网友的话说，这叫“用恒大冰泉洗澡”。澡是洗上了，亏也吃下了，就当交学费。

之后几天Max档也不怎么经耗，跑了几组活额度就见了底，害得我连着好几天没有Fable可用，心痒难耐。

所以我的结论是：Fable这点宝贵额度，拿去做杂活真是浪费。正确的用法是——日常聊天 + 项目规划。把它当导师，别当实习生。日常聊天时，不同的人把AI当不同的角色：有人当聊天搭子，有人当实习生在使唤。但你还可以把它当老师、当导师。当导师用的时候，你永远不会嫌它智力过剩——前提是，你问的问题真得有含金量。净派杂活，是发挥不出Fable真实水平的。

红利还在，抓紧上车

关于订阅的事，之前文章已经写过，不再重复：Coding Plan是你当下能撬动的最高红利，懂的都懂，买到就是赚到。买不起、买不到Codex和Claude的，国产的GLM也能凑合着用。

至于怎么付钱，最近我从美区App Store内购切换到了Airwallex新加坡虚拟卡直接订阅，体验相当不错。目前我知道可行的路子有两条：一是美区App Store绑PayPal；二是新加坡Airwallex虚拟卡。另外也见过几个朋友请美国朋友帮忙代付，这也行。别的路子我就不太清楚了。

但你要是还在用中转站跑Fable、Codex，按量付费，那真是大冤种了。真到这地步，还不如去买GLM的Coding Plan。

几条实用技巧

最后聊聊使用Codex和Claude的几个具体技巧。老实说，没有什么特别新鲜的东西，归根结底还是软件工程那一套：你原来怎么做事、怎么指挥人干活，现在就怎么指挥AI干活，只不过AI的执行速度要快得多。但具体技巧确实还是有的，我觉得最管用的有这么几条。

**一、对抗性Review（Adversarial Review）。**现在也有人管这叫“Oracle模式”，说白了就是管理学里的制衡术：找两个AI互相对抗。能达成共识的部分，通常更可靠；有分歧的，通过反复讨论协商，最终也能收敛到共识。这种共识状态，比一个AI埋头苦干、自己审自己要靠谱得多。

**二、先规划再干活，即“规格驱动设计”（Spec-Driven Design）。**对于中等复杂度以上的项目，先写文档、写设计规格，把Spec打磨讨论到你满意为止，再照着规格去生成代码——而不是像抽卡摇骰子那样一股脑上去就干。小活可以赌一把，复杂特性和工程要还这么玩，质量控制就是一场灾难。Spec-Driven Design就是用来解决这个问题的。

**三、验证闭环。**派任务的关键，是给出清楚的验收标准。比如我让它构建扩展的RPM包，验收标准就两条：第一，构建出来的包在我的标准容器和虚拟机环境里能装上、能跑通，加载不crash、不core dump；第二，按官方文档列出的主要功能点设计测试用例，全部跑通不报错。有了清楚的验收标准，事情就好办了：这类任务可以用GOAL-driven的方式发起——目标明确，它自己就会不断迭代，直到把问题干掉。

**四、上下文管理，重中之重。**你得对一个活的复杂度心里有数：它能不能在一个session的上下文里跑完？跑不完，就要靠拆解来控制复杂度。办法主要有两个：先规划再执行。规划阶段的思考被压缩成一份凝练的SPEC文件；执行阶段直接开新会话读SPEC，规划过程的上下文就全省下来了。

**让Sub-agent干杂活。**比如要在16个Linux平台上构建扩展，主Agent只管调度、收拢结果、派发新任务，具体平台上的构建交给Sub-agent。Sub-agent的上下文被脏活累活填满，最后只吐回一句摘要——成没成、挂在哪。主Agent的上下文因此得到极大节约，就能撑着调度更久、更复杂的工作。

利用最后一条消息，Codex在周额度打满的最后时刻，可以拉起一个巨无霸任务，这个任务会无视配额，直到完成为止。比如我趁着周额度还剩2%，给它派了个编译16个系统下pg_ducklake的任务，足足跑了两天整。

人人都能当嘴哥

总的来说，现在用Claude和Codex干活，是一种非常舒服的编程体验。

在重置还没这么密集之前，我的日常节奏是：给Claude和Codex派一组大活，它们差不多要跑半个小时。这半小时里，我可以上网冲浪、写文章、看小说、打把王者，或者躺一会儿。半小时后回来验收，再派下一波任务。

我独自维护Pigsty这么一个巨型PostgreSQL发行版——几万个RPM包，无数组件要在16个Linux平台上协调、集成、测试。面对这种超大规模的工程，我居然还能做到时间有余，搞搞副业，甚至去接盘个MinIO什么的，说起来，Claude和Codex功不可没。

但我也清楚，这套模式多半没法直接外推到团队。一个人干活不需要沟通，零communication成本；而在大公司里，沟通对齐才是最大的摩擦。个人、一人团队、或者像我这样的OPC（One Person Company），完全没有这个问题——所以很多打法未必能照搬到B端去。

听说阿里最近在搞OPT（One Person Team），我觉得这确实是大方向：极致释放个人的生产力。想象一下，你是个牛逼的架构师，手下配了二十个不知疲倦、速度是人类十几倍的工程师，那会是怎样的概念？大致可以对号入座：Haiku相当于P5工程师；Sonnet是P6高级工程师；Opus是P7专家、主力；Fable则是P8资深专家。

什么，你问P9是什么？P9是不干活的，在阿里俗称“嘴哥”——出嘴画饼写PPT。这个角色，现在就得你自己来演了。如今是人人当“嘴哥”的时代，你能使唤动多少个P8、P7，就看自己的本事了。