大家好，感谢关注呀🌹

接着上一期聊到了AI写代码后没人能看懂的情况，今天再聊点很多人不愿承认的实话。相信很多公司都陆续出现过这种情况了吧？

招的实习生，项目里出现了古法易语言，果然不出所料。。。

上周我们排查线上一个接口性能问题，翻到核心逻辑那段代码时，整个组都沉默了。

语法是正经Java，格式也整整齐齐，但写法别扭到离谱——循环套着判断，变量名全是拼音缩写，连自带的工具类都不用，硬生生用最基础的语法手搓了一遍功能，说难听点，像把别的语言机翻过来凑数的。

我们对着代码研究了半小时，组长突然冒出来一句：“这写得怎么一股子易语言味？”

大家本来还当笑话听，翻完提交记录当场笑不出来：提交人是刚来两周的实习生，备注写的“AI生成，已自测通过”。追问下去才知道，哥们上学学的Java拉胯的一批，实操经验少，刚入门，怕完不成任务，就把产品需求大白话组装成‘易语言代码’粘给了AI，让AI直接转成Java，跑通了就直接提交了。。。。

他说他把产品需求写成“易语言格式”，方便加强业务理解和代码排查，排查出错先看“易语言”，再定位代码加强熟悉感。。。。

后来我们找他要来了当初喂给AI的原版源码，短短几十行堆了五六个条件判断，全是按索引位置走分支的硬逻辑，味儿太冲了：

而AI翻译出来的Java代码，长这样：

一眼看过去，不光循环嵌套的结构原封不动，连「索引等于几就执行对应操作」「超过多少索引才开校验」这种非常个人化的硬编码逻辑都一字不差搬了过来。变量名是拼音直译，数组扩容全靠手动复制，Java自带的HashSet、ArrayList工具类一个都没用——AI完美完成了语法翻译，也完美保留了易语言的全部灵魂。

额。。。这段代码居然一路过了测试、过了代码评审，安安稳稳跑了几周。毕竟谁也不会想到，一个Java项目的主干里，能混进一段从易语言翻译过来的逻辑。

AI成了万能代码翻译机，什么来路的逻辑都能混进项目？

这事听起来像扯淡事儿，实则是现在很多团队的常态。

你要知道，AI写代码普及之后，最先被打破的不是效率天花板，是技术栈的门槛。以前你要写Java，得先学语法、懂集合、熟悉常用类库，半吊子根本写不出能上线的代码；现在不用了，不管你原来写的是‘易语言’、js，Python、c，还是按键精灵脚本，只要粘给AI，它都能给你翻译成项目要求的语言，语法不出错，功能能跑通，看起来像模像样。

可翻译过来的代码，终究是“机翻味”。

它不会用对应语言的最佳实践，不会考虑性能和扩展性，甚至连异常处理都生搬硬套。就像把中文论文逐字翻译成英文，单词都对，读起来却处处别扭，本地人一看就知道不对。但在快节奏的交付压力下，没人会深究“这段代码为什么这么写”，只要功能正常、测试通过，就直接合入。也别谈什么规范，评审和规则了，内卷效率能跑为王的情况，做这些评审等等就是增加成本。

于是项目代码库慢慢就成了大杂烩：

有人拿C[#的思路让AI写前端](javascript:😉，全是面向对象那套写法，JS原生特性一个不用，现在好多公司把前端干掉，让后端写前端，很多依然是这种情况，前端代码中一骨子java味儿；

有人把Python脚本扔给AI转Go， goroutine不用，channel不会，硬生生写出了同步脚本的味儿；

更有甚者，直接把网上找的老旧VB，jquery等代码扔给AI一转，混进了新项目里。

表面看全是统一的技术栈，扒开底层，什么来路的逻辑都有，千奇百怪，防不胜防。

新人不用再打基础，反正AI能帮着“转代码”？？

如果说机翻代码埋的是技术债，那对新人的影响，才是最隐蔽的坑。

五六年前带实习生，第一步先补语言基础，对着项目规范一条条抠，写个工具函数都要改三四遍，慢是慢，但每一行代码为什么这么写、有什么更优写法，他心里是清楚的。踩过的坑、改过的写法，都是实打实的基本功。

现在完全反过来了。

实习生入职第一天，先教怎么用AI写代码、怎么写prompt。遇到需求不用先想逻辑，先找有没有现成的类似代码，不管是什么语言的，扔给AI一转就能交差。交付速度看着特别快，一周就能上手做需求，比以前的新人效率高好几倍。

可深究下去就会发现：他根本不懂这门语言的特性，不知道为什么要这么写，甚至连基础API都记不住。他只会“喂需求给AI，改改报错”，只会在AI生成的代码上修修补补，离了AI，连一个完整的功能都写不出来，还有甚者说：“艾呀，咱们AI token用没了，没法干活啦”，纯粹就是把效果当成代码，效果有那就说明代码正常。。。。

就像这个写“易语言”的实习生，你不能说他不努力，他也在想办法完成任务。但长期这么干，他永远学不会正经的Java开发，永远停留在“用AI转代码”的层面。看似站在了工具的肩膀上，实则连地基都没打牢，哪天工具不好使了，立刻就会摔下来。

而团队招进来的，也不再是能成长的开发者，而是AI的“输入输出操作员”。

但是话说回来，我想说一句话，石器时代的结束难道是古人找不到石头了么？？也不能怪他。

代码评审名存实亡，我们拦不住奇奇怪怪的代码

有人会问：代码评审是摆设吗？这么离谱的代码都看不出来？

现实是，真的很难。

以前人工写代码，一天产出几十上百行，评审的时候能逐行抠逻辑、看规范、挑问题；现在AI一开，一天几千上万行代码往仓库里提，评审的人连通读一遍的时间都没有，大多只能扫一眼大体逻辑、跑一遍单元测试，没问题就过了。

更何况，AI生成的代码太有迷惑性了。

它格式工整、命名规范，甚至还会自动加注释，看起来特别像“正经人写的优质代码”。你很难第一眼就发现，它的底层逻辑是从易语言翻译过来的，是用最笨的方式堆出来的。只有真的出了性能问题、边界bug，往深了扒，才能发现里面藏着的离谱内核。

我们总说“人把控质量，AI做执行”，可当AI的产出速度远远超过人的审核速度时，所谓的把控质量，最后就只剩下“能跑就行”。

今天混进来一段易语言翻译的代码，明天混进来一段逻辑错误的生成代码，日积月累，整个项目的代码库就变成了看不见底的黑盒。你知道它能跑，但你永远不知道，下一个爆出来的坑，藏在哪段AI翻译的奇葩逻辑里。

其实AI本身没有错，它本来就是用来降低重复劳动、提升效率的。

但可怕的是，很多人把AI当成了“不用学习的借口”和“蒙混过关的遮羞布”。不会的语言不用学了，不懂的逻辑不用想了，反正AI能转、能写、能兜底。

但是现状很多公司是：

前端开发，把需求文档扔给AI，figma 设计图扔给cursor，再按目录整理下提示词和rules，几乎就不看代码（不是不看，是慢慢被同化变懒了+没时间），页面有能操作就行。

后端开发，把需求文档拆成模块让写（只要架构模块说的过去就行），都懒得手动建sql了，直接让AI上，codex打开一顿操作。。。

可代码骗得了人，骗不了运行时。机翻的逻辑、凑数的代码、悬空的基础，早晚都会在线上爆出来。到最后，收拾烂摊子的，还是人自己。

所以，该怎么破局呢？

学会把产品需求“翻译”成AI能理解的结构化Prompt。一个清晰的Prompt，胜过无数次“改改改”？？

当AI接管了大部分编码工作，开发者的核心价值在哪里？

评论区聊聊，你们项目的AI开发操作？

往期精彩回顾：

AI写代码半年后，我们公司的代码已经没人能看懂了!

这几个灵魂拷问，你能抗住几个?

有人说：有了AI，程序员是不是一天只要干一小时的活？我：。。。