Fable 5 与 GPT-5.6 Sol：每天 16 小时的 AI 开发工作流

Fable 5 和 GPT-5.6 Sol 如今已成为一名开发者自述的每日 16 小时编程流程的核心，但两个模型都没有获得项目的完全控制权。

AIHOT 背后的开发者表示，Fable 5 负责起草大型实施计划，GPT-5.6 Sol 对计划提出质疑，Codex 则执行修正后的规范。他有时会让编程智能体连续工作数小时，同时远程监控结果。

这一说法来自中国科技作者 Kha’Zix 于 7 月 15 日发布的一篇文章。它描述的是个人工作流，而非对照研究，其中的性能主张尚未得到独立验证。

尽管如此，这一流程仍体现了 AI 辅助软件开发中的一项重要变化。生成代码正变得越来越容易，而规划、测试以及判断结果是否可信则需要投入更多精力。

这套工作流也否定了关于前沿模型的一种常见假设。它并不追问 Fable 5 或 GPT-5.6 Sol 是否在所有方面都更优秀，而是根据观察到的优势，为每个模型分配更明确、更有限的任务。

Fable 5 扮演架构师的角色。GPT-5.6 Sol 成为持怀疑态度的审查者。Codex 则充当持续执行者，负责编辑文件、运行测试并处理失败。

这种分工比任何单项基准测试的胜利都更加重要。它将模型之间的分歧视为一种质量控制机制，而不是麻烦。

Fable 5 与 GPT-5.6 Sol 的 AI 开发工作流

据介绍，这套工作流将设计、批评和执行分离开来，而不是让一个模型承担所有角色。

根据原文描述，整个流程始于对预期产品变更的详细说明。该说明包括目标、相关文件、已知约束和预期行为。

Fable 5 首先接到主要任务。作者认为，它尤其擅长设计大型技术方案的初始版本。

这份计划不会被直接交给编程智能体。作者会将其交给 GPT-5.6 Sol，并要求这个 OpenAI 模型检查方案中的错误。

据称，Sol 能够发现 Fable 遗漏的严重缺陷，其中可能包括错误的假设、缺失的边界情况，或与现有代码库相冲突的步骤。

修订后的计划随后会返回 Fable 5。两个模型可以反复进行这一审查循环，直到作者认为规范已准备好进入实施阶段。

只有到这时，Codex 才会开始进行修改。作者表示，他使用的是 Codex 的目标导向执行模式，该模式能够在较长的工作过程中持续保持对某一结果的关注。

OpenAI 将目标描述为 Codex 会持续追求的长期目标，直到完成、暂停或需要请求更多信息。其指南建议在设定该目标前先规划工作。

这一区别十分重要。传统提示词请求的是一次响应，而持久目标则为智能体提供一个结果、边界和完成标准。

作者声称，有一次 Codex 连续运行了 17 个小时。这个数字描述的是个人体验，并非有记录的运行上限或典型运行时长。

长时间执行并不意味着始终在取得进展。智能体可能会花时间读取文件、运行测试、从错误中恢复，或反复尝试无效的方法。

因此，这套工作流依赖检查点。开发者会审查测试结果、检查变更的文件，并在智能体偏离已批准计划时进行干预。

这一流程就像是一个被压缩到软件之中的小型工程组织：

• Fable 5 提出架构和实施路径。

• GPT-5.6 Sol 进行对抗式设计审查。

• 人类解决分歧并批准规范。

• Codex 实施已批准的工作并运行验证。

• 人类在接受变更前评估相关证据。

这并不是完全自主的软件开发。人类仍然负责选择目标、判断批评意见、批准风险，以及定义结果何时算作完成。

随着智能体运行时间延长，这种责任会变得更加重要。当执行者拥有更强的持续工作能力和更广泛的权限时，一个错误假设可能会扩散到更多文件中。

因此，这套 Fable 5 与 GPT-5.6 Sol AI 开发工作流最有价值的特征并不是持续时间，而是对权限的刻意分离。

为什么代码生成不再是主要瓶颈

随着编程智能体变得更快，稀缺资源正从敲击键盘转向可靠的判断力。

传统开发工作流需要花费大量时间将设计转化为语法。开发者创建文件、连接接口、编写重复性测试，并修复简单直接的编译器错误。

编程智能体压缩了大量此类机械性工作。它们可以检查代码仓库、编辑相关组件、执行命令，并在测试失败后进行迭代。

这种加速并没有消除工程工作，而是将难点转移到了如何明确正确的变更，以及如何证明实现能够正确运行。

AIHOT 的作者将测试、验证和计划审查描述为新的瓶颈。这一观察与其工作流的结构相吻合。

薄弱的计划仍然可以生成看似合理的代码。结果可能能够成功编译，却无法正确处理状态、权限、故障恢复、并发或现有用户数据。

自动化测试只有在衡量正确行为时才能降低这种风险。智能体可能在满足不完整测试套件的同时，保留底层缺陷。

这会形成验证缺口。智能体产生变更的速度超过了人类理解这些变更综合影响的速度。

长时间运行会扩大这一缺口。每一次额外编辑都可能引入难以从最终摘要中还原的依赖关系。

解决办法并不只是生成更多测试。模型可能会在实现和测试中重复相同的误解。

Fable 与 Sol 的审查循环试图在实施开始前引入认知多样性。一个模型负责创建连贯的计划，另一个模型则获得对其发起质疑的明确授权。

这种方法类似于工程设计审查。当另一位审查者主动寻找故障条件，而不是润色方案的语言时，方案会变得更有价值。

OpenAI 的 GPT-5.6 发布公告体现了向更长时间智能体工作的整体转变。该公司表示，Sol 可以协调工具、处理中间结果并选择后续操作。

OpenAI 还声称，其在编程智能体评估和长时间运行的专业任务中取得了进步。即使采用了独立的基准测试框架，这些数据仍然由厂商发布。

Anthropic 同样将 Fable 5 定位于要求较高的工作场景。该模型回归 Claude Code，为开发者规划和执行复杂的代码仓库变更提供了另一种选择。

实际压力落在开发者和工程团队身上。他们需要能够跟上生产力日益提高的智能体的评估系统。

其中不应只有单元测试。团队还需要集成测试、真实的测试夹具、安全检查、性能测量和明确的验收标准。

他们还需要能够显示智能体尝试过哪些操作的日志。当智能体修改了无关行为时，仅凭一条声称所有测试均已通过的最终消息几乎无法提供帮助。

代码仓库的组织方式如今具有了不同的意义。清晰的文档、稳定的命令和明确的归属规则会成为人类和智能体共同使用的操作说明。

可搜索的架构决策记录也变得十分有用。团队可以通过严格的文档管理或工程知识库来维护这些上下文。

竞争优势不再是打字速度，而是以最小歧义将产品构想转化为可测试规范的能力。

Fable 制定计划，Sol 寻找缺陷

这场核心较量并不是 Fable 5 对阵 GPT-5.6 Sol，而是单一模型的自信对阵结构化分歧。

模型比较通常试图选出一个胜者。基准测试对模型进行排名，开发者分享自己偏好的助手，厂商则强调其系统领先的类别。

AIHOT 的工作流得出了不同的结论。一个模型的价值恰恰可能来自它与另一个能力出色的模型存在分歧。

作者认为，Fable 5 在生成大型解决方案的初始版本方面异常出色。这是一项基于密集个人使用体验的主观评价。

优秀的初始计划需要在众多决策之间保持一致。模型必须追踪依赖关系、安排实施步骤的顺序，并预判某项变更会如何影响现有系统。

这种能力并不能保证可靠的自我批评。一旦模型确定了某种方法，后续审查可能会继续保留最初的框架。

在这一流程中，GPT-5.6 Sol 充当外部批评者。据作者称，Sol 经常能在 Fable 的方案中发现重大问题。

OpenAI 将 Sol 宣传为面向复杂专业工作的旗舰模型。该公司声称，它在编程、浏览、计算机使用和长周期智能体评估中表现强劲。

这些被报告的优势使审查者这一角色显得合理。然而，发布时的基准测试无法证明 Sol 能够可靠地发现每一份由 Fable 生成的计划中的错误。

Fable 也并不永远垄断架构设计的优势。对于其他开发者、代码仓库或任务而言，偏好的顺序可能会完全相反。

价值来自角色分配。每个模型都会收到针对某一职责优化的提示词，而不是一个模糊的“正确构建此功能”请求。

规划提示词应要求列出假设、受影响的组件、迁移风险、测试覆盖范围和回滚条件，还应要求明确说明不确定性。

审查提示词则应采取相反立场。它应该寻找矛盾、缺失的依赖关系、安全问题，以及可能出现误通过的测试。

随后由人类比较两者的输出。这一步可以防止审查模型悄无声息地用另一种缺乏依据的偏好取代原本合理的计划。

结构化分歧还能形成有价值的记录。开发者可以看到提出了哪些风险、接受了哪些风险，以及哪些风险改变了最终设计。

当实现后来失败时，这些记录会变得至关重要。它有助于区分执行错误与已被嵌入获批规范中的缺陷。

这套工作流类似于生成器—验证器模式。一个系统生成候选解决方案，另一个系统则根据约束和潜在故障情况对其进行评估。

然而，验证器并不是全知全能的。GPT-5.6 Sol 可能会臆造问题、误解代码仓库，或建议不必要的复杂性。

同样，Fable 也可能会为一份建立在错误前提之上的优雅计划辩护。两个模型达成一致并不能证明结果正确。

它们共有的训练模式也可能产生相关性错误。两者可能都会忽略同一条特定领域规则，尤其是当这条规则只存在于未文档化的团队知识中时。

人类审查仍然是最终决策层，因为人类掌握着模型可能缺少的信息，其中包括业务优先级、运营历史和风险承受能力。

核心启示比“使用更多模型”更加具体。团队应该建立不同的角色、不同的提示词和不同的证据标准。

如果没有这种结构，第二个模型可能只会成为另一个输出自信措辞的来源。有了它，分歧就能在假设变成代码之前将其暴露出来。

Codex 目标模式将计划转化为长期运行的任务

持久化代理将实现过程从一连串提示转变为受监督的执行流程。

计划通过审查后，AIHOT 的作者会将其移交给 Codex。这一转变会把静态规范转化为代码仓库中的实际操作。

OpenAI 针对 Codex 的指南强调：描述期望结果、引导代理查阅相关材料、设定边界，以及定义怎样才算完成工作。

这些细节决定了长期运行能否持续产生有效成果。“实现这个功能”留下了太多隐含的决策。

更好的目标会明确预期的用户行为、允许操作的目录、必须执行的检查、禁止进行的更改，以及需要人工批准的条件。

随后，Codex 可以检查文件、编辑代码、运行命令，并针对测试失败采取行动。这个过程类似于一名初级工程师按照详细的工作指令执行任务。

目标模式改变了交互方式，因为目标会持续保留。开发者可以发送后续指令，而不必在每条消息中重新构建完整上下文。

作者表示，他在前往办公室的途中仍会远程继续编码。这个场景说明了为什么持久化执行不同于自动补全或聊天。

代理会在用户变换地点时继续在代码仓库中工作。人类的角色从亲自完成每一处编辑，转变为监督连续不断的操作。

OpenAI 的 Codex 指南建议在规划模式下启动较大的任务。目标应定义预期结果以及证明任务已完成所需的证据。

一次持续 17 小时的会话听起来令人印象深刻，但时长并不是衡量质量的标准。一次经过验证的短时运行，可能比一次主要耗费在反复重试上的长时会话更有价值。

有用的指标包括被接受的更改、回归率、审查时间、漏检缺陷，以及代理工作被人类丢弃的比例。

团队还应衡量干预频率。持续不断的纠正表明，目标、代码仓库上下文或任务边界仍不充分。

长期运行的代理需要明确的停止条件。在执行破坏性操作、出现意外的架构变更、权限变更或反复失败后，它们应暂停工作。

它们还需要受限访问权限。执行代理只能获得完成已批准任务所必需的凭据和系统权限。

拥有广泛生产环境访问权限的编码代理，可能会把规划错误演变成运营事故。持久化能力使最小权限控制变得更加重要。

版本控制提供了另一层边界。包含描述性消息的小型提交，可以让审查者逐步检查更改，并精准回滚局部故障。

测试结果应始终与这些更改关联在一起。声称验证成功时，应明确说明所用命令、环境和相关输出。

对于面向用户的功能，代理不仅应测试孤立的函数，还应测试真实的工作流程。这可能包括浏览器交互、数据迁移，以及操作中断后的恢复。

规范应区分强制测试与可选探索。否则，代理可能会耗费数小时扩大任务范围，而不是完成已批准的更改。

正是在这里，Fable 5 和 GPT-5.6 Sol AI 开发工作流不再只是模型之间的比较。规划质量直接决定了持久化执行的实用程度。

优秀的执行代理会放大它所接收计划的效果。它不会自动修复上游的每一个战略错误。

16 小时的日常安排只能证明投入程度，不能证明可靠性

所报告的日程体现了热情和充分的使用条件，但无法验证最终软件的质量。

原帖称，作者每天大约花 16 小时进行氛围编程。他描述了自己工作到深夜、短暂睡眠，然后通过远程访问继续工作的状态。

这段叙述为故事赋予了引人注目的标题，也构成了最值得谨慎看待的原因。

使用编码代理的时长并不会直接转化为工程质量。疲劳可能会降低开发者发现细微错误或质疑模型中看似可信输出的能力。

这种日程也可能难以持续。围绕一位积极性极高的创始人持续监控而设计的工作流，未必适用于更大的团队。

“氛围编程”通常指通过自然语言指令构建软件，同时由 AI 完成大部分实现。这个标签涵盖了差异极大的技术监督水平。

一些用户只做视觉检查便接受输出。另一些用户则会检查差异、设计测试套件、衡量性能，并将每一项生成的更改都视为不可信内容。

AIHOT 流程更接近后一种类型。它的规划和审查阶段所体现的结构化程度，高于“氛围编程”这个词通常暗示的水平。

不过，所报告的 17 小时执行仍只是一个自述案例。公开叙述并未提供完整的任务日志、代码仓库差异或独立的缺陷分析。

AIHOT 所报告的受众增长也是如此。作者称该服务的月活跃用户数已超过 50 万，但没有发布独立的分析数据。

这些缺口并不意味着该工作流毫无用处。它们只是界定了哪些内容应被读者视为观察结果，而非已经确立的证据。

供应商的声明也应受到同样审慎的对待。OpenAI 报告称，GPT-5.6 Sol 在多项代理式编码评测中表现出色，而且通常使用更少的 token 和时间。

这些测量结果提供了有用的信号，但基准测试简化了真实的代码仓库。生产系统包含未记录的依赖项、不断变化的需求，以及组织特有的风险。

Anthropic 近期的经历也表明，外部条件可能改变访问权限。Fable 5 于 6 月 9 日发布，随后立即受到政府限制。

Anthropic 表示，由于无法可靠地实时核实国籍，因此暂停了访问。在相关管制解除后，该公司恢复了全球可用性。

这条 Fable 5 时间线对于依赖特定模型构建的工作流十分重要。可用性可能成为一种技术依赖。

这些限制源于对网络安全能力的担忧。Anthropic 后来表示，能力较弱的模型也能够复现被引用的漏洞演示。

OpenAI 也先通过受限预览发布 GPT-5.6，之后才全面开放。一篇 Axios 报道描述了政府对该模型网络安全能力的审查。

这些事件引出了一个更广泛的运营问题：当首选的规划模型或审查模型突然无法使用时，该怎么办？

团队需要制定替代方案。提示词、评估标准和设计记录应能够在不同模型提供商之间迁移。

团队还应测试角色发生变化时，工作流是否仍能成功。Sol 可以起草计划，而 Fable 或另一个模型负责审查。

这种练习可以揭示质量究竟来自所选择的模型，还是来自围绕它们建立的严格审查结构。

另一个风险是自动化偏误。开发者可能会把详细的解释误认为证据，尤其是在看到代理正确完成许多常规任务之后。

最好的防御措施是可观察的验证。测试、差异、日志和可复现的命令，比自信或雄辩更重要。

第二道防线是有选择性的人工审查。安全边界、数据迁移、计费逻辑和不可逆操作，比外观上的更改更值得严格审查。

最后一道防线是工作负载纪律。即使 token 供应看似充足，人类判断力仍是一种有限资源。

如果一个流程产生的工作量超过开发者能够负责任审查的范围，它就已经超出了安全吞吐量。

未来三个月开发者应关注什么

只有持续证据表明多模型审查能够在不压垮人工审查者的情况下减少缺陷，这种工作流才真正具有重要意义。

第一个信号是真实代码仓库中的独立性能数据。公开基准测试可以建立基线，但无法衡量生产环境中的所有约束。

开发者应寻找单模型与多模型工作流之间的对照比较。最有力的测试会使用相同的任务、代码仓库、权限和验收标准。

相关结果包括完成率、缺陷严重程度、审查时间，以及随后被删除的生成代码量。

如果先由 Fable 规划、再由 Sol 审查的方式能够持续减少严重缺陷，AIHOT 方法就会获得支持。如果结果与单模型工作流相同，那么额外阶段只会增加复杂性。

第二个信号是 Codex 在持久化目标执行期间的行为。OpenAI 将长周期执行视为一项重要能力，但可靠性比最长持续时间更重要。

团队应检查 Codex 请求澄清、放弃某种方法、重复失败命令或超出已批准范围的频率。

他们还应跟踪较长时间的运行是否会产生连贯的提交。成功的会话应留下一条易于理解的更改链，而不是一个过于庞大的差异。

更好的进度报告将增强该模式。开发者需要简洁说明已完成的工作、剩余的不确定性，以及执行期间收集到的证据。

当人类可以放心离开时，持久化目标最有价值。这需要可预测的暂停条件和可见的状态。

第三个信号是提供商稳定性和模型可移植性。Fable 5 和 GPT-5.6 Sol 发布时，都因高级网络安全能力而受到政府不同寻常的关注。

未来的限制、安全保障调整、使用限额或产品更新都可能改变模型行为。过度依赖某一对模型的工作流仍然十分脆弱。

团队应保留与模型无关的规范和评估套件。他们应能替换规划模型、审查模型或执行代理，而无需重新设计整个流程。

这也会赋予组织谈判筹码。针对特定任务的评估可以揭示哪个模型在其环境中实际表现最佳。

因此，近期的竞争将不仅仅围绕基准测试分数展开。OpenAI 和 Anthropic 必须证明其代理在长期、混乱且需要审计的工作中仍然有用。

开发者不应根据一次发布周期就选定永久赢家。模型性能变化很快，而可靠的评估实践始终具有价值。

AIHOT 的叙述提供了一种引人注目的早期模式：用一个模型制定计划，让另一个模型审视并攻击该计划，并且只有在解决分歧后才开始执行。

其更深层的主张是，如今的软件开发更需要编排，而不是提示词技巧。这个主张值得认真检验。

可以在一个拥有现有测试套件、范围明确的功能上尝试这种模式。保留两份计划，记录每一次干预，并将结果与你的常规工作流进行比较。

然后提出真正重要的问题：Fable 5 和 GPT-5.6 Sol AI 开发工作流是否让你更快地获得了可验证的软件，还是仅仅产生了更多需要审查的软件？