新手的PR彻底让全网开发者抓狂！资深工程师警告：新人用AI更容易翻车!反而是老手越来越强，弱者越弱

作者 | Can Elma

编辑 | 云昭

出品 | 51CTO技术栈（微信号：blog51cto）

“AI 会不会完全接管编程？”这个问题已经被问烂了，人们还在不断尝试回答。我不觉得还有什么特别新鲜的说法。但今天，我想分享一些自己的观察。

这里只是想说一件事：之前市场所鼓吹的“新人+AI”打造高质量代码的叙事模式，基本告吹了。恰恰相反，现实中，公司需要的是更多的“资深+AI”。

为什么老手更能驾驭 AI？

大模型辅助编程工具的长处很明显：

• 快速生成样板代码和脚手架
• 自动化重复性工作
• 尝试不同实现方案
• 借助快速迭代来迅速验证
• 只要明确目标，就能快速上线功能

但前提是，你得知道自己要什么。资深工程师正好具备三样关键能力：

1. 清晰目标感他们知道问题的边界，能把需求拆解成明确的 Prompt。模糊提问，只会得到模糊答案。
2. 经验兜底AI 写的东西再快，也免不了出 Bug。老手一眼就能看出逻辑漏洞，快速修正。新人往往还在琢磨“这代码到底对不对”。
3. 架构思维AI 不会真正设计架构，它只是拼装。老手能用经验控制复杂度，让 AI 产出的东西在正确的轨道上运行。

在老手手里，AI 就像一台加速器：写代码更快，验证更快，上线更快。而且最重要的是——可控。

而对于新人来说，想要将这些优势真正转化为价值，并不是不可能，只是难度大得多。

为什么新人更容易翻车？

在更多新人手里，AI 往往变成了“坑爹导师”。

1. 不会提问新人最常见的 prompt 是：“帮我写个 XX。”问题是，不说清楚业务逻辑和边界条件，AI 只能给出“看似合理”的代码，结果漏洞一堆。
2. 不会判断AI 输出的内容，不管对错都照单全收。遇到 bug，不知道是 AI 搞错了，还是自己用法不对。于是越改越乱，掉进“幻觉迷宫”。
3. 不会自查很多新人直接把 AI 写的代码提交，连最基本的 review 都没过。资深一看，全是坑：命名混乱、逻辑重复、安全漏洞。最后返工比从头写还累。

一位网友这么形容：新人把 AI 当“万能外挂”，结果却是“放大短板的显微镜”。

毕竟，今天的AI还需要保姆级照料

归根结底，编程是一件系统工程。而 AI 目前也只是从海量公开的代码中学习到了部分概率分布而已。如果想要真正支棱起来，下面这几项都是需要开发者所注意的。

• 代码审查：AI 不能真正推理。它的审查有点帮助，但一旦出现边界情况（而 AI 生成的代码里常常会出现），你还是得依赖资深开发者。
• 糟糕的 Prompt：谁能写好 Prompt？只有真正理解自己在构建什么的人。如果缺乏知识，最多能得到“还行”的结果，但没有合适的验证手段，只会带来 bug 和麻烦。
• 架构设计：没有扎实的架构，软件价值会快速缩水。今天的 AI 还做不到真正设计好架构。它看起来好像能，但这种推理还是需要人。弱架构起步的项目，最终都会淹没在技术债务里。
• 代码质量：如何选择正确的抽象、正确运用设计模式、保持整洁和上下文匹配，这些 AI 依旧很难。
• 安全性：就像一栋没有门，或者门锁坏掉的房子。新人 + AI 组合下，安全漏洞出现得更频繁。当然，安全问题到处都有，但资深至少有一定的意识和谨慎。
• 错误的学习：如果一个人没能力评估代码，他可能根本意识不到 AI 产出的代码哪里有问题。在公司里，这可能意味着带来损害而不是价值。

还有更多例子，但核心结论是：AI 目前对资深开发者还不是威胁，反而可能增强了他们的优势。这不是在批评新人，而是不要让他们在不切实际的期待下陷入高风险场景。

目前看，AI 应该被用在的地方

那么，既然大模型还不能做到接管编程工作，它真正的用武之地应该在哪里呢？

• 快速原型：非常适合快速尝试一个想法。
• 加速日常工作：最重要的用途。把那些你熟悉且经常重复的事情自动化。
• 跨学科工作：填补知识空白，推荐有用的方法或库，帮助在多领域交叉时建立联系。
• 功能测试：简单、重复、低风险且容易核查的代码。

在我看来，目前的状况就是这样：我们仍然必须阅读 AI 写下的每一行代码。它还远不完美，没有意识，推理只是模仿，结果不可预测，所以我们还得依赖测试这种确定性的东西。但问题是，你真的会放心让 AI 写测试，然后用来验证它自己写的代码吗？

我想起自己发过的一条推文：有人写了一个 Prompt，让 AI 在不知道时回答“I don’t know”。我的看法是：“如果这样的 AI 说‘I don’t know’，你也不能确定它是真的知道自己不知道。”

AI还没有真正普惠编程

“新人 + AI”的组合曾经很诱人，看起来更便宜，还能加深“AI 会抢我们工作”的恐惧。但当你把软件行业和其他行业对比，就会发现它依然显得很不成熟。

建筑行业有建筑师设计，软件里甚至“架构师”还在亲自写砖头一样的代码。我们的分工还不够专业化，价值驱动不够明确，成本控制却占据主导。这让工作被贬值，也让人精疲力竭。

所以，现在的情况是：AI 并没有真正普惠编程，反而更多地把力量集中到专家手里。期待和现实出现了偏差。未来会怎样还不好说，我对 AI 长远发展保持乐观，但短期内我们可能需要重置一下期待，不要让它继续被扭曲。

网友炸锅：我不知道，Claude写的？一听就抓狂

实际体感上，很多网友也是遇到了这样的问题。

一位昵称“kaydub”的网友，对于“AI+新人”模式作出如此的评论：

因为新人不知道什么时候自己已经被带进了“兔子洞”。所以他们会让大模型在幻觉里越陷越深。

我有个新人，本来只是要部署我写好的一个 Terraform 模块。这个任务拖了很久，我去问问进展。他跟我说遇到问题，请我帮忙看一下。

结果我一看他的仓库，简直一团糟，一眼就能看出是 Claude 把他带偏了。我问：“这里为什么会有一堆 Python？模块本身是独立的啊。” 

他回答：“我不知道，Claude 写的。” 这完全印证了我的猜测。他们缺乏经验，对大模型工具过度依赖。不仅在设计和实现阶段如此，连排查问题也一样。

如果你用一个会“幻觉”的工具来调 Bug，而你自己又没能力判断它是不是在幻觉，那你这趟旅程会很漫长。

对比之下，自己对于AI工具的把握还是要好很多。

与此同时，大模型工具帮我减掉了很多我讨厌的活。我通常能很快看出它是不是在走偏（至少大多数时候能），并在它继续之前及时叫停。结果就是，我反而重燃了对写代码和构建软件的热情，产出更多，质量也更好。

另一位网友victor9000则更是提出了一句“小白金句”： 

我不知道，Claude 写的。

我是那种会认真读代码、提出追问的 reviewer。我从新人和资深工程师口里都听过这句话。真让人抓狂，他们一本正经地说出这种话，还指望保住工作？如果有人在提交自己都不理解的代码，那他们就是团队、产品和雇主的负担。

最逗趣地是，还有一位网友爆料道：

我老板曾经决定用 Devin 提一堆 PR。我告诉他，我花在审查 PR 上的时间，比他节省的时间还要多。

总之，关于代码评审这块，网友是彻底刹不住车了。大模型生成的代码各种明线和暗线的bug，不可不查、不可布防！

好消息是，AI再一次被证明替代不了人类程序员！

参考链接：​​https://elma.dev/notes/ai-makes-seniors-stronger/​​

本文转载自51CTO技术栈，译者：云昭