为了让交付更快、更稳，我通常会先和 AI 一起把需求的整体设计讨论清楚

快乐虎

为了让交付更快、更稳，我通常会先和 AI 一起把需求的整体设计讨论清楚，包括前端交互设计、后端 MVC 结构、代码逻辑抽象、组件复用、开放模块设计、稳定性设计，以及架构和工程层面的优化。


一轮讨论结束之后，AI 通常会生成 3～5 个文件，对应不同维度的项目变更设计文档。

接下来，就会让 AI 根据项目复杂度选择合适的模型配置，同时开启多个进程跑 CLI，或者拉起多个子 Agent 一起干活。

这个模式的效率确实很高，不过带来的最大问题只有一个：钱不够烧。

我在 Codex 上买了两个账号轮着用，Github Copilot 也买了两个账号。用了一段时间之后发现，Codex 的 token 限额算是最亲民的，5 小时窗口 + 周限额窗口。周限额有时候看起来还挺随机，昨天还显示要等一周才能恢复，结果第二天一看，额度已经恢复到 100%。

Github Copilot 刚开始没有太注意，它其实是按照 Request 来限流的。有一次为了调一个细节，一晚上来回聊了很多次，直接把月额度干没了。后来慢慢摸索出一个用法：专门让 Copilot 处理大的需求，一个 Request 里塞进去好几个复杂任务，反而会觉得“真香”。

Google One 的 Family 方案其实也很香，用 Antigravity Tools 做反代就能跑。不过最近封号有点猛，现在基本不太敢用了。

当所有账号都被干到限流之后，也试过用国内的一些模型，比如 Kimi-k2.5、GLM-5。做一些常规的小需求其实问题不大，一旦遇到复杂问题，就很容易陷入无限递归循环：

排查 → 修复 → 没改好 → 继续排查。

这个时候就会特别怀念 Codex-5.3-xhigh 和 Claude-Opus-4.6。

另外，这几天刚出来的 Codex 5.4 表现更明显，之前需要排查好几轮才能解决的问题，它经常一把就能过。