一次近16小时的部署，超过95%的时间耗在AI自己设的阻塞上

一位开发者让 Sol 6.1 High 执行生产环境部署。第一次约14小时，第二次接近16小时。同期消耗掉 ChatGPT Business 订阅可用额度的九成以上。

应用本身不大。前端构建约25秒，后端准备约25秒，PostgreSQL 备份约80秒，加起来两分钟出头。剩下的时间去了哪儿，他自己做了一遍审计。

审计结果：超过95%的部署时间花在自我设置的阻塞、重复验证和恢复流程上。部署框架有50多个模块，主部署脚本一个文件就约9800行 Python。过程中出现11个连续的部署阻塞，每一次都要改代码、测试、提交、再走一遍恢复程序。

部署期间记录的6个发布变更里，5个是在修部署基础设施本身，只有1个动到应用功能。系统反复扫描源文件、重算哈希、重新校验数据库结构、检查历史部署产物。

每失败一次，就往上加一层

他对成因的判断很直接。Sol 6.1 High 每遇到边缘情况或部署失败，就往上加东西。更多抽象、更多验证层、更多兼容机制、更多永久性防护。它很少简化流程，也很少直接解决眼前那个问题。部署基础设施于是堆起了自定义 SQL 解析器、Python AST 分析、加密状态绑定。恢复机制也越来越复杂。

结果是基础设施严苛到修复一个问题就会触发另一个问题。换句话，失败一次就多一层保护，保护本身又制造下一次失败。

他也划了边界。生产部署需要防护，备份和必要的检查不在批评范围内。他批评的是那些与风险不成比例、最后自己变成故障来源的保护措施。他也承认，仅凭这一次经历无法确定更高的推理投入是否会强化这种行为。但他担心会。一个更强的推理模型不应该自动产出更复杂的方案。

问题不出在编码能力上。按他的说法，Sol 构建复杂系统的能力，有时超过它判断这些系统是否必要的能力。

多代理编排里有同一笔账。一个过度谨慎的主编排器，会把专业子代理的优势抵消掉。它靠的是过度协调、重复验证和不必要地扩大范围。

他给了7条改进方向：
- 偏好简单可维护的方案，别不断累积防御性抽象
- 先看现有防护够不够用
- 别把一次性事故变成永久架构要求
- 找出并删掉重复验证和无用代码
- 让验证强度跟实际运维风险成比例
- 验收标准满足了就收尾
- 编排专业代理时别重复它们的工作

评论区里的同类经历

不少人认领了类似遭遇。有人说 Astra 上同样如此，称 GPT-6 系列模型是“适得其反的垃圾”。

有人指出 CI/CD 对所有模型都是难题。模型没接受过这类训练，得手动引导。它们写规则时总要额外加点东西，设一些任意超时，“几个小时就这么在零进展里耗掉”。

有人问发帖人，为什么不在30分钟时就停下来问情况，毕竟构建脚本要么能跑要么不能跑。也有人说是靠 Opus 才把问题修好。还有人说自己必须盯着，或者在放它自己跑之前把架构计划写明确。不然就会陷入打补丁的循环。他正在考虑取消订阅、去试 Anthropic。

一位评论者把矛头指向 GPT-6 系列。从那时起每个文件都配上 sha 校验，简单任务也能生成一堆文件。他让模型重写 UI，花了2.5天、几次重置，最后连一个基础按钮都不工作。他认为 Anthropic 现在领先很多，OpenAI 这边“只给了 Dots”。

另一位说，所有模型都靠加东西来修问题。它们把现有的冗余、遗留和不完整实现当成不可更改的东西。还有人质疑编排本身：如果编排真的更好更高效，OpenAI 或 Anthropic 为什么不默认推荐。

这7条建议，和评论区里反复出现的“加东西修问题”，指向同一件事。过度设计不太像一次部署的偶发失误，也不只出现在这一个模型身上。高推理设置是不是诱因，他自己也说这一次定不了。