为什么用了 Codex，反而感觉更累了？？？

念头通达 2026-07-18 10:21 1

为什么用了 Codex，反而感觉更累了。^-^

以前自己一行一行写代码，虽然慢，但每个模块、每个方法为什么这么设计，心里都很清楚。出了问题，基本知道该从哪里查，也知道后续该怎么改。现在交给 Codex，一次能并行做好几个任务，功能确实很快就出来了。但问题也随之而来——很多代码自己根本没来得及看，只知道"能跑"，却不知道它为什么这么实现。

当项目越来越大，回头再维护这些代码时，才发现最耗时间的不是写，而是理解。为了改一个小功能，可能要先花半小时读 AI 写的代码，甚至比自己重新写一遍还累。AI 确实提高了编码速度，但也在透支对代码的掌控感。

如果只是追求把功能做出来，它很好用；可一旦项目需要长期维护，真正的成本不是生成代码，而是在交给Codex之前的“超级详细的架构设计、业务设计、各种保姆级的约束”。

不知道大家有没有遇到过。

新功能、新模块还好，任务小、代码量少，交给 Codex 写确实挺舒服，效率也很高。但一旦涉及老项目、大改造、跨多个模块联动，问题就开始出现了。Codex 对局部任务完成得很好，却很难真正理解整个项目的业务背景和历史包袱。它会按照当前看到的上下文去修改，看起来每一步都没问题，可最后拼在一起，总感觉差点意思。而且幻觉问题还是挺明显的。有时候一个很简单的问题，它会越改越复杂；有时候为了兼容一种情况，引入一堆其实用不到的设计。对于我这种做后端服务的来说，一个需求经常涉及多个系统、多个服务、多个模块联调，真正难的从来不是写代码，而是理解业务、理解上下游依赖，以及知道这次改动会不会影响其他地方。

所以我现在越来越觉得，AI 最适合做的是"实现"，而不是"决策"。架构怎么设计、边界怎么划分、哪些地方不能动、哪些历史坑需要绕开，这些还是得开发者自己把关。

也因此，我一直有个疑问：那些说完全不会写代码，只靠 AI 就能开发完整系统的人，到底是真的已经找到了一套成熟的方法，还是只是把 Demo 跑起来了？至少以我目前的体验来看，一个能长期维护、能持续迭代、能支撑业务的系统，光靠 AI 生成代码，距离真正落地还有不小的距离。

我查了一些资料，有研究显示，开发者真正用于编写代码的时间只有约 14%，远低于很多人的想象。剩下的大部分时间，其实都花在需求理解、架构设计、沟通协作、代码 Review、测试、调试和维护上。这也解释了为什么很多人用了 AI 之后，感觉编码快了，但整体开发效率并没有想象中提升那么多。

当然，AI 不只是会写代码，它还能参与设计、测试、文档等很多环节。但对于企业项目来说，最耗时间的往往是业务理解、系统设计、跨系统联调、历史代码维护和风险控制，而这些恰恰也是最依赖上下文和经验的部分。

最后说一下感受吧！

AI 已经非常强了，作为一个做了 10 年后端开发的人，深度使用下来，我最大的感受是AI真的能提高效率。不管是短期、还是长期来看，它对行业的影响非常大。程序员不会完全消失，而是单个工程师的产能越来越高，同样规模的项目不再需要过去那么多人。IT 行业的蛋糕本来就那么大，甚至现在还缩水了，以前需要一个10人团队完成的项目，未来2个人配合AI就能完成。以后真正有竞争力的，可能不是写代码最快的人，而是最懂业务、最懂架构、最会利用AI解决复杂问题的人。

最新回复 (19)

🛡️Rice R. Rug 💛🍋⭐️💫 07-18 10:22

1楼

工具效率越高人越累

一直都是这样
wang-test 07-18 10:24

2楼

不是程序员的我，感觉很方便大大便利了我的生活之前想搞个小东西自己不会，现在随便ai 可劲造只要输出我想要的结果就ok
Nakano Azusa 07-18 10:25

3楼

感觉ai只适合开新的项目用，改老项目总是会出现比较大的问题 ^-^
chunluren 07-18 10:27

4楼

同感，之前有5h额度的时候真是守着点去下任务。每次他刷新我就感觉是喊我上班呢。

歪个楼，我是菜鸟开发者，白天在笔记本晚上在macmini，有没有好的方法让两边的codex共享一个项目的记忆呢。实现下班无缝开发
AfricChang 07-18 10:27

5楼

为啥要读或者理解ai写的代码？ai一天能产生多少屎山？你让另一个Ai去审核，理解不就行了。Ai搞项目需要完整的文档体系，我用Ai写了一个项目(私活)，动手前讨论了很多方案，写了很多文档，现在要实现新功能或修改缺陷，基本是指哪打哪，我代码都不看了，只测试，然后用其他ai审。我现在是“老板”，只看效果，结果，做决策。

如果要说累，就是当了“老板”后总有一种穷逼心理∶我特么给了钱的，不能让它闲着！
念头通达楼主 07-18 10:30

6楼

是啊，主要是人需要设计、需要测试什么的
Underthemoon 07-18 10:30

7楼

"完全不写代码只靠AI开发系统"的人，demo跑起来和系统能用是两个次元的事，前者交个作业，后者是要背锅的，表示理解。^-^
lurenyv 07-18 10:34

8楼

当，当的就是超级代码审核员，整个项目改造根本不可能用ai，它都看不懂项目
CooDdk 07-18 10:34

9楼

你自己写好需求文档和验收标准，然后再交给AI去做
念头通达楼主 07-18 10:40

10楼

是啊，累够呛，系统复杂了之后，改起来超级累，聊着聊着就各种幻觉、骗人
念头通达楼主 07-18 10:42

11楼

是的，写个小demo可以，作为10年程序员的人，深度使用之后，发现确实提高效率，随着时代进步，最终我们也会被淘汰
小半 07-18 10:46

12楼

ai编程是这样的，质量不可控，review不谨慎就会出现业务逻辑上的漏洞，然后上生产就爆炸，心里没谱
lihua 07-18 10:47

13楼

心智负担变大了，不断需要你做决策
乘二 07-18 10:48

14楼

bro 打开思路，用 demo 做体感 harness，然后定好广义规则，goal 就行了。本质是先用水面上的轻量实现锚定需求，再用成熟的工程化体系给 ai 限制目标完成路线。至于 review 说实话也只能在大方向把控。
念头通达楼主 07-18 10:53

15楼

每次AI写的代码， review 提出一会问题，修了之后，不是功能改了、坏了、不能用了，就是产出新的问题，只能用，不能深挖
LANDO 07-18 10:54

16楼

把你电脑的.codex托管到github的私有仓库（如果没有敏感数据的话），然后通过git同步这个目录就可以共享一些session、配置等
Hugo 07-18 10:54

17楼

我用 vps 使用 codex，那样记忆都在 vps 上，这是我的方法。而且这样还会避免 windows 上 codex 的一些 bug。
AmazingBeing 07-18 10:55

18楼

和大佬有类似的感觉，做老项目时阅读代码成本更高了。
Bliner 07-18 11:32

19楼
分享一个我的大项目迁移的使用经验：
1. 我是先把一个成熟的开发框架，让他先梳理出代码规范和设计要求。
2. 比如业务逻辑写在哪儿？抽象写在哪儿？接口写在哪儿？调用规则是什么？
3. 我让他参考这个项目，再对老项目进行改造。
基本上能有个 70% 相似度。

不过那句话说的是对的，局部的上下文一长了，它就容易丢失，就忘记时刻要按照设计文档要求执行了。

在这个执行基础上，我会让他逐个模块地去完善成我设计要求的样子，这样效率还是高一些的。

简言之：
1. 一个成熟的项目，让它拆分出使用说明、代码风格、代码要求等文档。
2. 写的时候让他务必参考这个项目的设计规范，和上述文档。
3. 最后再根据执行情况，逐个模块地完成迁移。
其实大模型对代码的理解和使用能力上没问题，需要人为去引导。