因为我就是初级程序员，总得给口饭吃吧？
1 - AI时代的程序员危机
开个玩笑。处于鄙视链底端的SQL工程师甚至往往都算不上程序员......
随着vibe coding的热潮持续，各大厂商的AI编程工具能力在短短2年中突飞猛进。如今，任何非技术背景的用户，只需简单说几句话就可以在10分钟内快速创作一个网页甚至一个简单应用，立即可以运行，效果炫酷到和真实的现代应用难以分辨，AI的创作能力着实令人惊叹。
于是乎，网上开始盛传一股程序员危机，有了AI今后的世界不再需要程序员，尤其是那些初级程序员。扎克伯格在去年初就预言2025年内AI将达到中级程序员水平，以meta为首的科技巨头纷纷开始裁员......
事实是否果真如此？如今的互联网充斥着各种炒作与贩卖焦虑，圈外的人无非都是看个热闹，大家习惯了等泡沫破灭或是剧情反转。到底能信多少？唯有实践才能出真知。
接下来我作为一个Vibe coding 3个月不到水平的初级程序员，将用国内顶尖的编程IDE TRAE和国内顶尖模型MiniMax M2.1亲身测试用AI重构一个真实的代码工程。
2 - 重构对象
我需要重构的一套"祖传代码"信息大致如下
由于工作需要，之前已经人肉重构过一版, 这次尝试用AI来替我干活。当时第一次当我打开代码, 看到上千行的pandas处理和html交织，内心是百感交集。
果然拿来就能跑的期望是不现实的，最终花了2~3天才勉强跑通。
本次重构任务在基于此前人工重构的经验之上从头开始，分为以下A、B、C 3个阶段，其中Phase C人工还没做过。
-
Phase A: 环境准备。另外通读代码回味一遍, 规划Phase 2/3的具体任务
-
Phase B: 将日本的祖传代码迁移到国内环境运行。具体改造点
❶将OpenAI模型切换为国内大模型
❷将BigQuery数据源切换为本地CSV
-
Phase C: 代码优化, 增强可扩展性和可维护性
3 - 重构准备
Phase A的具体工作见下图。主要在回味一遍原始代码后，把一堆肉眼可见的坑先列举出来。
4 - 环境迁移重构
Phase B的目标清晰, 代码放到国内环境能跑就行。理想情况是利用TRAE SOLO强大的Agent能力, 唰唰改造两个功能点就完工了, 岂不20分钟搞定？而现实是：花了至少1天半时间。
最痛苦的过程在B-16数据结果调试，前后挣扎了近100分钟。定位逻辑错误往往比运行时异常更困难，加之由于项目本身业务逻辑也调用LLM, 其结果的不确定性导致难以定义测试的标准答案。
第一次任务(任务可包含多轮对话)，AI在反复运行→修复→运行的循环后竟然自行放弃了。
第二次任务里加上了人工修复提示, 终于在继续挣扎30分钟后解决了问题。
下图节选了挣扎过程
除此之外，有4个任务我直接或最终选择了人工修复，因为人工对特定业务逻辑和运行环境的理解，能够更快解决问题。
拿B-4举例来说：当测试数据极少, 必然会出现某些分类标签为空。当打不出特定标签时则不生成中间文件，导致后续生成data frame错误。
AI的解法是构造空的data frame继续往后运行，然而人工基于业务逻辑判断, 直接忽略整个文件处理即可。但如果要花10分钟把这个规则给AI讲清楚然后再等待10分钟调试(可能不止)，我可能更愿意自己花5分钟改完。
其他观察到几个显著的问题
易出现修改遗漏
不严格遵循指令，自我加戏
改出幻觉
花时间修改未被使用的函数
配置字符串被篡改
语法错误(离谱了)
破坏性修改
最后每一步的完整结果记录可见下图。其中AI prompt数字标识代表多轮对话。
5 - 代码优化重构
接下来开始Phase C的代码优化。
这个行业流传的处世哲学是能跑的"祖传代码"就千万别去碰, 如果非得加新功能就往下堆新函数新文件。 不得不承认这是最安全的方法......
我记得2021年在一个技术峰会上，MegaEase的创始人陈皓分享了他认为杰出程序员的一个特质，就是"不能忍"。忍不下去 → 敢于挑战 → 不断进步，我认同这个逻辑链是对的，当然前提是你要确认你的几行代码不会造成上百万的损失。
在刚入行一年多的时候，我造成了一场生产事故。原因是大刀阔斧地用存储过程修改了一坨极其难懂又冗余的低代码的ETL，那时候我们甚至没有上线审批流程。几天后，业务部门发现了数据逻辑错误，大约花了一周修改并恢复数据。
首先, 这是一个反面例子, 完备的回归测试很重要！事故后果很严重: 老板们一周看不到正确报表数据。那又怎么样呢? 最终毒瘤被消除了，团队运维负担也减轻了。在AI时代, 相信会有更多践行者。编码门槛降低了，试错成本也降低了，原来不敢动的代码，在AI辅助下也会更有底气。
有点扯远了，来看下AI优化结果如何。
真切感受是一方面AI快速指出了很多问题和正确的解决方向；而另一方面其实际改造结果仍然差强人意, 局部可以做到效果良好，但如果期望它自主地以一个全局视角, 做到根本架构层面的重新规划与构建，距离这个理想差距还很大。
有意思的是在最后, C-7任务中让AI重新梳理给出建议时, 它提到的"tagger大量重复代码"正是在上一步C-6时自己没有改完的坑。
任务C-6的承诺
任务C-7的吐槽
当中还遇到一次幻觉删错代码
5 - 总结
简单在下图中统计了数值指标。可以看出虽然AI问题解决率虽然不算太低，但需要大量人工介入指导。
METR机构去年发表的一项研究显示出，借助AI编码时生产力反而下降了19%。尽管该结果也存在一定争议，但无疑是给AI编程的神话般叙事泼了一次冷水。
最后总结下我对当前AI辅助编码的看法
1.对于强依赖业务需求和业务逻辑理解的任务，应当由人类开发者主导，AI无法取代(至少在相当长的一段时间内如此），无论是否SPEC Coding。我认为这一点是人类开发者的绝对优势和价值体现，而其他的问题, 包括架构设计最终可能都会有技术解决方案，只是时间问题。
2.顶层架构设计，当前应当由人类开发者制定，AI可以参与辅助讨论和规划。期望AI完美地设计方案并控制编码走向目前还不现实。
从实践角度来说，AI对于代码的解读分析，给出的修改建议都极具参考价值。因此先由AI生成文档，再让AI辅助编码，小步前进反复迭代的模式是正确的有效路径。
3.人工应当仔细审阅AI生成的代码，其中可能包含逻辑错误、幻觉、遗漏等各种问题，放任AI自由发挥极易造成事故。论其中原因本人难以评价，从现象来看推测存在上下文污染问题，以及在超长上下文中有效信息的检索能力存在瓶颈。
4.必须做好代码管理，本地/远程git, 甚至额外备份；高危命令设置禁止名单，必须人工确认执行。破坏性修改后果不堪设想，AI删除整个D盘或是数据库的报道已是屡见不鲜。
5.在快速生成项目原型，验证新技术集成和运行错误调试方面, AI表现极强。很多时候可以快速生成一次性代码，完成一个特定任务，用完即删。
最后声明：本文并非宣传抵制AI编码；恰恰相反的是，我相信积极学习与实践，在编程中用对AI用好AI才是新时代程序员的必备技能。
AI代替初级程序员的论调简直是天方夜谭，因为我就是个初级程序员。饭碗暂时保住了。
