过去三周，是我在 AI 辅助软件开发中最有启发性的几周。
Claude Fable 回归了，与此同时，OpenAI 发布了搭载 Sol、Terra 和 Luna 的 GPT‑5.6。市场信号很明确：前沿实验室不再只是发布孤立的突破性成果，而是在压缩能力、定价层级和部署节奏之间的差距。Anthropic 现在将 Fable 5 作为其顶级的长周期模型出售，价格大约是 Opus 5 标价的两倍；而 OpenAI 则将 GPT‑5.6 定位为一个从旗舰级能力向下扩展到成本敏感型工作的模型家族。与此同时，xAI 对 Grok 4.5 的定价激进到足以让任何成本效益讨论都必须认真对待它。
然而，在那几周里，我学到的最重要的事情，与发布页面或基准测试幻灯片几乎无关。
我所在环境中的真正突破，在于准备。
我们准备好了故事雏形。我们将工作拆分成了可由智能编码系统实际执行的单元。一旦这个任务队列就绪，产出效率就变得惊人。在 Codex、Claude、Cursor、Grok 以及工作流中的其他工具之间，大约十天时间写下了超过 200 万行代码。这个数字听起来像炒作，但如果你看到是什么让它成为可能，就不会这么认为了：不是魔法，也不是抽象的自主性，而是一系列有边界、结构清晰的持续性工作，让模型能够不断向前推进。
这是太多人仍然忽略的第一件事。产出爆发并非因为模型突然变成了能自我指导的工程师。它之所以发生，是因为人类预先准备好了战场。
我学到的第二件事是，在大规模应用时，错误出现的速度远快于营销宣传所承认的。
Codex 就是一个很好的例子。OpenAI 自己关于长时间运行任务的物料明确指出，持久线程伴随着一个权衡：连续性很有用，但长时间运行的线程也可能变得比重新开始更昂贵、更难管理。Goals 功能的设计正是为了将线程保持在一个有边界的目标上，而不是让每个困难任务都变成一个不断膨胀的提示词。在实践中，这与我观察到的情况相符。如果一个进程运行时间过长，通常更好的做法是停止它，请求一个清晰的交接，重新启动会话，并带着一个新目标继续。这不仅仅是一种便利。它通常是一种操作上的卫生习惯。
还有一个更具体的 Codex 问题，现在已经有了一条清晰可见的公开记录：子代理和本地状态膨胀。
Open issue #34061 记录了一个案例，其中恢复的父线程产生了数千个子 JSONL 日志和数百 GB 的持久化会话历史。另一个问题明确警告说，fork_context=true 可能导致父进程的庞大历史记录被快照到子代理中，从而放大正确性风险和令牌消耗。还有一份公开报告显示，一旦 ~/.codex 积累了大型 SQLite 日志和会话状态，Codex 的冷启动会退化，出现 1-5 分钟的等待。综合来看，这些报告描述了一种许多重度用户会立刻认出的故障模式：一旦本地元数据层变得足够大，会话持久化就成为了产品体验中的一个严肃问题。
这一点之所以重要，是因为多智能体编码在演示中的表现总是比在压力下的开发机器上好得多。
其承诺是清晰的。OpenAI 的多智能体文档解释了为什么并行子代理可以加速独立的工作流，这个承诺是真实的。但同样的文档也警告说，子代理会增加令牌消耗，并且可能不适合涉及频繁写入共享可变状态的任务。ChatGPT Learn 上的并行代理指导则更加明确：从读取密集型工作开始，比如探索、测试、分类和总结；对写入密集型流程要更加谨慎，因为冲突和协调开销会迅速增加。这个警告并非理论上的。任何目睹过一群代理同时冲向完整测试套件的人，都确切知道这意味着什么。
在我的设置中，这现在已成为整个类别的一个关键操作性问题。
问题不在于模型是否足够聪明来实现并行化。它们显然可以。问题在于，它们仍然需要好得多的编排边界，因为“足够聪明来委派任务”与“足够聪明来在争用下维护机器健康、本地优先级和成本纪律”不是一回事。
同样的不匹配也体现在定价上。
Cursor 清晰地展示了这个问题。它目前的定价是透明的：有两个月度使用池，一个用于 Cursor 自己的模型，另一个用于第三方“其他模型”。它还表明，Auto 模式并非单一事物。Auto Cost 使用固定令牌定价，但 Balance 和 Intelligence 模式按路由模型的费率计费，而路由器可能会在 Composer、GPT‑5.6、Claude 或 Grok 等模型之间进行选择。对于偶尔进行交互式工作的人来说，这种灵活性很有吸引力。但对于突发性的、工业级的工作负载来说，它可能变成一个陷阱。一个月的优质预算可能在几个非常高效的日内就消耗殆尽。
我在一个以审查为主的场景中，正好测试了那种故障模式。
一个项目新增了大约 50 万行代码。我们的审查系统在那次变更中标记了大约 1500 个问题，包括重复项和误报。Cursor CLI 被分配去处理它们。原始的令牌量巨大。输出也很有用。但对于我的用例来说，经济性不对。当密集的审查和修复工作可以在一个星期内消耗掉一个月的额度时，这个工具可能仍然很好，但订阅就变得不合理了。
这种张力现在无处不在。
Claude 仍然是我最享受使用的系统。但它也是让我对成本最敏感的一个。Codex，尤其是在更广泛的 GPT‑5.6 生态系统中，其吞吐量往往比批评者承认的要大得多。Grok 4.5 并非儿戏；其公开定价和定位使其成为一个合法的竞争者。Anthropic 自己的定价使得 Fable 与 Opus 之间的权衡显而易见，几乎无需多言：前沿能力摆在那里，但账单也同样醒目。
然后是最难的问题，一个没有发布活动能真正解决的问题。
在我几乎使用的所有前沿编码模型中，仍然存在一个令人沮丧的鸿沟，介于能力不足和过度工程化之间。
我们面临的抉择，往往是一个模型思考不够深入，与另一个模型为手头任务思考过度之间。Anthropic 自己对 Fable 5 的指导实际上承认了这一点。它指出，更高的努力程度可能导致过度规划，常规工作可能受益于较低的努力程度，而简洁的指令通常优于臃肿的脚手架。OpenAI 在其 GPT‑5.6 指南中也说了类似的话：从早期模型迁移时，从相同的推理水平开始，然后测试低一个级别，因为较新的模型通常可以用更少的令牌保持或提高质量。这是一种技术性的说法，本质上与我们许多人从经验中发现的一致：努力程度的旋钮仍然太容易调过头了。
也许部分责任仍在我们身上。
也许指令文件太长了。也许某些脚手架现在不是在帮助模型，而是在与它们对抗。这个理论至少与 Anthropic 自己的上下文工程指导是一致的，后者指出上下文应该信息丰富但紧凑。一个真实的可能性是，我们归咎于模型的一些过度复杂化，正被过度膨胀的提示词基础设施放大。
但即使在考虑了这一点之后，更广泛的结论仍然没有改变。
模型犯的明显错误比以前少了。但它们仍然会犯的错误，往往更加危险，恰恰因为它们更难被发现。它们隐藏在那些看起来经过打磨、深思熟虑且专业的代码中。代码从远处看起来越好，我就越学会保持怀疑。
这就是为什么我对当前这波 AI 编码的胜利主义仍持怀疑态度。
我理解炒作从何而来。如果你没有每天都在这些系统内部工作，单是那吞吐量就足以让人感觉像奇迹。其中一部分也确实是奇迹。但日常的动手使用也会暴露出另一面：计费不确定性、编排失败、长时间会话的脆弱性、在浅层简化与精心过度设计之间摇摆的倾向，以及对人类进行包装、审查和判断的持续需求。
我们距离一个理想的 LLM 编码世界还非常遥远。
炒作并非完全错误。但它仍然远不如操作现实那么诚实。
