5条使用Codex编写真实软件的建议

文章较长，建议大家收藏观看。

大家好，这里是AI奇点观察室

前些天在隔壁粉色小电视刷到一个4月份的视频，是王自如讲解AI开发软件的录播，他提到我们在用AI写代码开发产品的时候，现在已经不用写前端的交互原型了，你可以直接在HTML里面直接做一个可交互的预览版本。但是AI写出来的代码还是要人做很多收尾工作， AI目前可以做出很好的准生产产品，但是从准生产到生产这之间的鸿沟还是需要专业的软件工程师帮你解决。否则在生产环境下还不能达到真正好的标准。

当时我很惊讶。但是转念一想视频是26年4月的，具有时效性。于是我去问了公司的程序员，也问了AI。得出的结论是王自如是对的，而且时隔半年，情况依旧如此。虽然这6个月AI在软件开发上的能力有了肉眼可见的跃升，但距离“完全自主达到纯生产环境标准”，仍然存在一道结构性的、尚未被跨越的鸿沟。“工程师收尾”不仅没有消失，反而在新的分工形态下变得更加关键。

也就是说，我们在用AI做真实项目的时候，去给企业做落地配套的时候，一个完全没有项目经验的小白是很难独立开发应用的。Codex大家都在用吧，在Claude Code大面积封禁国内IP的背景下，Codex CLI我们用的尤其多。它虽然能帮你提升效率，但是良好的软件工程实践依然重要。

很多人开始用AI写代码之后，都有过这样的体验：

一句话丢进去，哗啦啦生成几百行，看起来挺像回事。兴冲冲跑起来，然后报错。再让AI改，改好了这里，那里又坏了。折腾一晚上，最后自己也不知道这个项目里到底有些什么东西。

我们公司有AI辅助编程的程序员以及纯VibeCoding的开发者。这两年几乎每个项目都在用AI帮忙写代码。AI出现之前和之后，我们都完整做过应用。

折腾下来我发现一件事：AI确实让我快了很多，但真正决定项目能不能成的，还是那些老办法。

下面是5个我总结自他们一直坚持、也确实有用的习惯。尽量说得白一点，不整术语：

一、先想明白要做什么，做规划，别急着让AI动手

很多人打开AI的第一句话就是"帮我写一个XX"。

我的做法正好相反：先聊，不写。

我会先跟AI聊我到底想做个什么东西。比如：

• 这个东西大概分成哪几块？
• 数据存在哪儿、怎么存？
• 有几种做法，各有什么好处和坏处？

聊的过程中我会不断追问、不断质疑。它说A方案好，我就问：那B方案差在哪儿？它给的建议我拿不准，就自己去查资料核实一遍。

这一步看着挺花时间，其实是在省钱。不需要一开始就把每个细节都想清楚，但心里得有个大致的结构。

否则做到一半你会发现：连地基都打错了，上面的东西只能拆了重来。

二、把自己的项目也当成正式项目来做

我自己做的小项目，一样有这些东西：

• 代码统一存在Github项目里，随时能找回历史版本。
• 列一份清单(Issue)，记录要做的事和已经做完的事。
• 列一份路线图(Roadmap)，知道先做哪块、后做哪块。

规划好之后，我会把大目标拆成一个个小任务，一个一个来。

我不会同时开五六个AI，指望它们自己商量着把整个应用做出来。

也许有人这么干能成，但我更愿意一步一步走。

听起来是不是有点慢？

慢是慢一点，但你始终清楚这个项目是怎么一块一块搭起来的。快而不失控，才是真的快。

三、计划赶不上变化

做了这么多年，我最深的一个体会是：很少有人第一次就把所有决定都做对。

有时候做到一半，你突然发现有个更聪明的做法。

有时候你之前认定的一个前提，最后证明是错的。

这都不是问题，这就是做软件的日常。

正确的应对方式是：把清单(Issue)改一改，路线图(Roadmap)调一调，重构一下，然后继续往前走。

别因为原来的方案是AI帮你写的，就硬着头皮照着做。

我遇到这种情况，还是会让Codex帮我一起重新想：现在这个变化意味着什么、有哪些选择、改动的代价有多大。但最后拍板的人是我，不是它。

四、一定要看懂AI帮你写的东西

这一条，我认为是5条里最重要的。

如果Codex写出来一段我看不明白的东西，我绝不会直接用。我会追问它：

• 这段为什么能跑通？
• 你为什么选这个做法，不选别的？
• 还有哪些别的选择？
• 万一这里出问题，会发生什么？

公司的程序员老张在刚开始学编程的时候，没有AI，他靠的是Stack Overflow、官方说明、书、还有别人的代码。但他一样会想办法搞懂自己在写什么。

AI没有改变这件事的必要性，只是让搞懂它变得更容易了。

你不需要把每一行代码都背下来。但你至少应该知道：

• 你的项目主要由哪几块组成
• 这几块之间是怎么配合的
• 出问题时，大概该去哪儿找

如果哪天东西突然不工作了，而你完全不知道原因——那后面的维护会非常痛苦。你会陷入"改一下试试、再改一下试试"的循环，越改越乱。

五、留好"后悔药"，多做检查，大胆尝试

我的习惯是：

所有东西都在Github留档。 每一份重要修改都有记录，做错了能退回去。

不同任务和清单Issue分开做。 尝试新想法的时候，我在一份单独的副本上动手。就算Codex把事情搞砸了，正式版本毫发无伤，我随时能扔掉这份副本，换个思路重来。

检查要边做边写，不要拖到最后。 每完成一小块，我就让Codex顺手写一些自动检查——相当于给这块内容配了几个"小哨兵"，以后不管谁改了什么地方，只要碰到这块，马上就能发现有没有弄坏。

先把东西做出来，再让它更好。 等项目能正常跑了，我会回头看：哪些地方可以更简单、更快、更省资源。第一遍不用追求完美，那是第二遍的事。

最后还有一点：你遇到的问题，大概率不是全新的。

在你之前，很可能已经有人踩过同一个坑。这时候AI特别好用——你可以让它帮你找别的解决思路、帮你分析到底哪儿出了问题、帮你想下一步怎么走。

我最大的体会：

Codex 让我的生产力有了显著提升，但我做软件工程的基本方法其实没怎么变。

我依然是规划、设计、实现、测试、自审、迭代，只不过现在手上多了一个能让我把这些事做得快得多的工具。

只不过现在，每一步都有个帮手，让我能走得快得多。

我不需要一个AI大军，也不需要一套花里胡哨的全自动流程，才能做出像样的东西。

因为最终要为成品负责的，还是你自己。Codex是个非常好用的工具，但工具不会替你承担结果。

我们是AI奇点观察室，你的AI新纪元的金牌向导，有我在不迷茫，我们下期见~

如果这篇内容对你有帮助，欢迎点赞、收藏、转发

最后祝大家生活顺利，身体健康。