2小时实测：手搓代码VS AI编程 ，传统手艺能否赢AI？

最近圈子里到处都在讨论“AI能不能替代程序员”，各类观点众说纷纭、莫衷一是，让人难以分辨。

到底是人机协作还是人机竞争？AI究竟是不是比手搓代码更厉害？为了评估AI在实际开发场景中的表现，我们组织了一场人工手搓代码与OpenAI Codex的比赛，看看在实际研发场景中，两者到底谁更胜一筹。

这次要解决的问题场景是研发团队最日常的研发工作——解Bug！

解Bug不仅考验技术功底，更需要对项目逻辑、业务场景的熟悉度，也是最能体现编程实操能力的环节。

比赛规则：

产品经理提前准备好10个Bug和1个需求，由参赛的两组选手同时处理。

处理完成后，需要提交代码，再由禅道研发负责人刚哥负责评审双方的代码质量，最后由2名测试工程师分别对两组提交的成果进行测试，重点验证Bug是否完全解决、需求是否实现。

接下来，让我们隆重介绍古法编程参赛选手：

以及新新新新新势力AI参赛选手：

（AI辅助组，依靠OpenAI Codex，搭配禅道研发总监金庸哥哥完成所有任务。）

比赛当天9点10分，两组同时开始处理，11点20分结束，全程耗时2小时10分钟。

（请看现场播报）

最终比拼结果如下：

Tips：此次主要聚焦日常解Bug的场景，后续还会补充更多的测试情况，覆盖不同场景下的真实表现。

综合本次比拼的全程表现，我们的复盘总结如下：

首先，AI组的整体进度主要卡在了前4个Bug的处理阶段，由于对禅道的近期功能设计并不熟悉，遇到“设计如此”类问题时，AI会在无效路径中反复尝试，导致耗时偏高；而人工组则更熟悉禅道设计，对于“设计如此”的Bug能够快速给出判断，同时整体的Bug处理速度和节奏也明显更快。

其次，在OpenAI Codex的使用过程中暴露出了几个明显问题，这也是影响AI效率的关键因素：

• AI组未参与部分功能开发，对项目的已有逻辑不熟悉，如果操作人员无法给出进一步的精准提词，Codex就会一直在多种解决思路中反复尝试，反而消耗大量时间，这也是前期进度受阻的核心原因之一；
• 禅道的代码存在不少特殊判断逻辑，Codex在没有明确提示的情况下，很容易给出错误的解决方案，需要后续反复调整；
• 缺少完善的项目文档支撑，Codex每次处理任务时，都需要从0开始阅读整个代码库，浪费了大量不必要的时间，也间接影响了整体进度。

基于上述发现，我们也能够梳理后续的AI辅助的优化方向，既能提升AI的使用效率，又能完善团队自身的研发流程：

一是增加前端和后端业务的Skill文档，让AI能快速了解项目业务逻辑和代码规范，减少无效尝试；

二是可以让AI对接visual、用例和日志，实现反馈循环，让其能根据测试结果和日志信息自动调整解决方案，提升准确性；

三是优化产品代码库的整体组织，让代码结构更清晰，方便AI快速检索关键信息；

四是在业务流程中，相关人员提Bug时可带上对应url，这样能够实现一步定位到模块方法，减少AI阅读代码库的时间，提升定位效率。

手搓 VS AI，究竟哪方更胜一筹？

从比赛的全程及后续的优化方式来看，基于不同的人员操作，AI确实能实现提效，但效果并没有我们想象中那么惊艳，不存在AI能够“一键替代程序员”的情况。

同时，AI辅助编程也存在一定的成本，比如需要投入时间整理文档、优化提词、调整AI给出的错误方案，这些都需要人工参与，并没有大家说的那样省心省力。

当然，还有很多人认为AI编程完全“不需要熟悉代码，全部交给AI干就可以”，但从实际结果来看，对代码的熟悉程度虽然不影响AI的使用，但会影响提词的精准度，进而影响AI的效率和解决方案的准确性。

整体来看，AI能达到20%~30%的提效，就已经能够满足日常研发的需求了。而通过这次实测，我们也更清晰地明确了AI的定位：它更适合作为辅助工具，用来提升编程效率、减轻人工负担，而不是完全替代程序员。毕竟在实际研发场景中，项目的特殊逻辑、个性化需求、代码质量的把控，以及问题的精准定位，依然离不开人工的专业判断。

那些在担心AI能不能替代自己的程序员们，或是在思考能不能用AI替代程序员的老板们，看到这个结果，大家会作何感想？