Codex 6.0 的编码能力虽强，但产品上线时被资源消耗、Docker 打包和部署耗时折腾得够呛。从 5.6 切换到 6.0 后，排查一次问题就能吃掉 5 小时额度，Windows 本地开发到 Linux 云端部署更是频频踩坑。

Codex编码能力是一绝，根本没啥问题，但是在我最近产品上线的过程中，Codex的问题频出，让我应接不暇。

不知道你有没有同款问题。

第一：资源消耗问题

最近我把codex的模型，从5.6切换到了6.0，不得不说，6.0之后的模型消耗资源的速度实在是太快了。

它排查一个问题，基本上就能把你5个小时的用量给消耗完。

我仔细看了一下它的做法，它会先分析定位问题，通过写测试用例，然后进行测试，最后分析跑出来的日志，然后定位问题，再来修改代码，然后再测试，确定问题被解决。

虽然这样方便了很多，但是token消耗的是真快。这种解决问题消耗token倒是还能接受，最让人接受不了的，它打包消耗token的速度也超出了我的想象。

第二：打包问题

我所有的应用程序是本地开发，最近部署的时候选择了docker部署，我需要把本地的包打包成docker的镜像，到云端去部署。

现在最难受的问题，本地测试没问题的镜像，到云端之后就会有问题，都是一下缺少库，数据库表不完善的问题。

每次遇到这样的问题，都需要在本地修改，然后再打包到线上部署。

这就导致，本地测试没问题的代码，到线上需要重新测试。

这个本质上还是自己编码的习惯问题，如果基于linux系统开发，或直接基于daoker开发应该就没有这样问题了。

第三：耗时问题

我看了codex每次打包耗时都很久，它会有一个很复杂的思考的过程，在思考结束之后才进行工作。

在这个过程中可能还需要下载第三方的组件，这就导致消耗时间比较多。还是基于Windows开发，使用linux打包导致的问题。

你看，原来我只是觉得在本地把系统写好，到线上只是复制代码，下载组件就可以解决问题，但是现在看来并没有那么简单。

完整的开发一套系统，从一开始就要思考清楚后续的部署方式，我这种就熟悉典型的重复造轮子，只是浪费时间，并没有实质性的业务进展。

原来我基于php开发应用，只需要把环境搭建好，无非是代码的写法略有不同，不会出现这种功能还不一致的问题，现在好了，问题越来越多做。

到目前为止，我还在往线上打包、部署。

不知道，你目前有没有被Codex，部署到线上搞疯。