别让 AI 编程毁了你的职业生涯，请把它们当作你的实习生，而不是员工/老师！

声明：本文无任何 AI 生成内容，纯手写。如果有什么废话、词不达意或偏离主题，大抵是笔者本人能力有限。

昨天看到一些表达忧虑的言论，比如「AI 正在培养一代不会编程的“文盲程序员”」。记得更早时候，也有人提过：“AI 会毁了低级程序员”。无论你是赞同还是反对，都必须承认这样的观点有一定道理，绝非空穴来风。

提取下这些表达忧虑的论点：

1. AI 辅助编程导致解决问题能力退化，自己主动思考的机会少了
2. 对 AI 编程有“戒断”反应，甚至感觉自己更笨、更慢了
3. “我们并没有因为 AI 成为‘10倍程序员’，我们只是对 AI 的依赖变成了 10 倍”

说说我自己，我却因此感到比较幸运：在大语言模型大行其道前（或者说出现前），我就已经“耐着性子”打下了相对牢固的计算机基础，把浙大数据结构、MIT操作系统等等经典课程的作业、课设和考试都认认真真做完了。2022年底，等我要写毕业论文的时候，最初版的大语言模型 GPT3.5/ChatGPT 才横空出世，来得恰到好处。

如果我晚几年上学，我现在定然会质疑学习基础知识的意义。即便想明白了，开始学习，也未必能愿意如“前 AI 时代”那般扎实地学习：经典论文直接扔给 AI ，让它直接告诉我要点即可，没看懂的地方会选择追问 AI ，而非自己去论文里找；课程作业 AI 直接帮我自动补全了，人都是有惰性的，我也很难克服——“好嘛，帮我补全了一大堆，哎呀反正就是那个意思，我已经懂了，能跑通完成作业就可以啦”！更可悲的是，由于课程作业的答案早早就成了 AI 训练数据，被 AI 补全的内容极大概率是完美的——本该在学生时代磨练的用 gdb 苦苦捉虫的能力，被省略了——当这个学生以后解决实际问题时，在 AI 的方案没那么完美时，其面临的挑战则比“前 AI 时代”出身的工程师们更严峻了。

然而，与历史上所有面临“淘汰威胁”的工种不同，软件工程师，或者说程序员，是最拥有“积极拥抱新事物”的态度的——这也是其工作要求所致。

那么话说回来，面对双刃剑般的“魔鬼”，我们该如何安全地“拥抱”它呢？

请把 AI 辅助编程当作你的实习生，而非员工、同伴或者老师！

1）你的下属或同事会对自己的代码负责，但你的实习生不会

你用 AI 写的代码出了错误，你会把 AI 公司告上法庭吗？显然不会，它们早就做了免责声明。即便是 AI 写的代码、 AI 提的 commit ，那也最终算在你头上。

什么？你们公司已经把 AI 集成在 CI/CD 中了，比如用 AI 流程化编写单元测试？没问题，如果 AI 的代码出了问题，谁部署的 AI 谁负责。

总之，责任一定是要落到某个“人类”头上的。如果你百分之一百把工作放心地交给你的 AI 工具，那么请记得，你没法在出问题时说：“这是我让 XXX 写的，你找 TA 去吧！”

AI 写的重要的逻辑一定要自己检查，就像实习生写的代码，如果要进入生产环境，你难道不好好 review 下吗？

此外，是否让 AI 接触高度敏感的信息，也更加值得注意。就好比你不太可能让一个暑期实习生接触你们公司最具竞争力的核心技术。否则，想象下，等暑假结束了，实习生拍拍屁股走人，靠着在你这学到的机密，直接拿到了你们竞争对手的正式工作 offer 。难道你连实习生都要签竞业协议吗？显然不现实。

AI 辅助编程也有这个隐患，虽然大概率 AI 公司也看不上我们写的垃圾业务代码。但是对于程序员来说，如何保管核心数据/密钥/代码，的确是值得思考的问题，我的初步建议是：

• 将密码/token等敏感信息存放在类似 ~/.bashrc 这种 profile 文件中，以环境变量的形式在运行时读取
• 或者保证你的项目内 config 会被 AI 工具 ignore 掉

2）一次只让你的实习生做一件事，别操之过急

回忆一下，当你和你带的实习生第一次开会时，面对这位初次参加实习、一脸稚气的愣头青，你是怎么介绍接下来的工作的？

是这样吗：

• 你好这位同学，现在假设你是一位资深 Go 语言工程师，你将为我提供安全、优雅的 Go 后端系统解决方案
• 我需要制作一个图床的后端系统，需要支持图片上传、图片下载、图片列表查询等功能
• 尤其需要注意的是图片存储方案以及预览图的缓存生成方案，项目成本是我们的重要考量因素
• 要选择生态最完善的 Go 语言服务框架，确保后续开发维护流程顺利
• 项目可扩展性要强，要有相应的热更新方案
• 要输出足够优秀的接口文档，方便和前端对接
• lint / static check / unit test 一个都不要差

你把上面的 AI prompt 说给这个实习生，那你将会看到“一脸懵逼”最具像化的阐释。显然你不会这么做。

对于 AI ，你也不应该这么做。换句话说，过于贪心，往往得到不满意的结果，还浪费了时间。我们应该把与 AI 的每次交互，都看作是与实习生的一次次会议。

比如：

• 第一次会议（询问 deepseek-r1 或其他推理模型）：我希望设计一个高性能图床后端系统，我比较擅长 Go ，有什么推荐的现有方案吗？如果没有，我们该如何设计？如何规划项目呢？

  • 第一次会议，就好比你让实习生自己规划自己的暑期项目，并且予以纠正，最终拍板决定
  • 你可以在聊天的最后，让 AI 输出设计方案的概括、结构图、技术栈等等，就好比你让实习生自己对项目做了个汇报总结给你，之后，你可以拿着这份汇报，开启第二次会议 / AI 聊天

• 第二次会议（可以把上次的“会议总结”作为 AI 编程工具的 pre-prompt ）：基于目前的项目设计，让我们从一个最小可用功能开始实现，让我们先来设计依赖注入中的第一个服务！

  • 第二次会议开始，让 AI 开始生成具体代码，则相当于让实习生自己写代码
  • 你觉得不好的地方，则自己直接修正，防止一错再错
• 接下来的会议，则都是日常工作的推进

这里有个小建议：

1. gpt-o1 / deepseek-r1 等等 reasoning 推理模型很强，但是它们速度一般（因为要 reasoning 再开始输出正式内容），而且成本较高，因此建议拿来做项目设计
2. 对于日常的代码生成，则使用 deepseek-v3 / claude-sonnet-3.5 这类 inference 模型即可，速度和成本都更好，且如果你的项目上下文足够多、足够规范，那么其代码质量往往是不差的；尤其是你已经有了一个单元测试的实现，那么接下来的单元测试 AI 都会照着已有的内容完美实现，反之，如果需要 AI 凭空写单元测试，则很难完美切合你心意

3）实习生的项目，你不可能一点都不动手

这点是我的切实体会。我有一个小强迫症，每天都得写点代码。但是在最近半年，这个习惯却变成了“每天让 AI 生成点代码”。我惊奇地发现，我的产出反而慢了...

过年期间，我希望做一个简单的 SPA （单个网页应用），一段简单的 Vue3 逻辑，足足 5 天，我没有任何进展。因为过年期间静不下心看代码，我选择干脆完全交给 AI 辅助工具。

最终我惊奇的发现 AI 在我的项目里绕圈：我定义了一个基础的 FileUploader.vue 组件（这个组件有点复杂），在 XXXView.vue 中，我的 AI 却对于是否选择使用这个组件还是自己写一个文件上传逻辑犹豫不决，由此又带来了许多新问题。

假期快结束的时候，我才坐下来仔细看了看，才发现是多么简单的逻辑啊！三下五除二我自己就写好了。

你可以说是我的 AI 工具用得不对，也可以说比起 Vue 它们更擅长 React 。但你可能也无法保证，这个黑箱不会在面对较为创新的问题时出现“停滞不前”这种情况。

尤其是，当你的代码在生产环境出问题时，你不能指实习生从学校飞奔过来为你解决，就好比你不能在火急火燎的情况下期望 AI 给你准确的答案。

对于 AI 写的项目，你也最好了解其是怎么实现的。这样，当你决定要修改它时，你可以比较快速地上手。

4）你不可能把实习生当做你的搜索引擎

遇到一个 bug 就立即复制给 AI ，这是荒唐、可笑、可悲的。就算 AI 再进步十年，这个行为都将是荒唐、可笑、可悲的。除非有你头上接着最先进的脑机接口，把所有的感知、背景都作为上下文输入给 AI 。

把错误信息交给 AI 当然没问题。但是，这不应该成为条件反射。否则，为什么找你来当工程师？能用大脑定位出方向的问题，简单地使用一次搜索引擎，要比扔给 AI 更快更合适。

对于基础资料查阅也是如此。现在的程序员，似乎文档都懒得看了。

想象一下，当你在用 aws s3 sync 命令时，你想知道 --exact-timestamps 这个参数的具体作用，你会把实习生叫过来，然后问 TA ：“这个参数的作用是什么，并且给我几个具体例子”吗？！

2 分钟过去了，这个实习不知搜罗了哪些野鸡博客，自己汇总了下，把一个 markdown 格式的报告交给了你。你看得似懂非懂，又不知道到底依据都准不准确。

为什么不直接在搜索引擎搜索 doc: aws s3 sync --exact-timestamps 呢？只需要 5 秒钟，最官方、最确定、最直白的文档就会呈现在你眼前。同样是文字描述，你为什么一定更喜欢别人嚼烂的呢？

5）实习生可以是某方面的专家，这不丢人

假设你们领导要开展涉及 CUDA 业务线，你被任命为了技术负责人。你大可以招一些在学校里就已经在做 CUDA 的实习生，并且在项目设计时聆听这些人的想法。

同理，在我们面对新问题找不到方向时，大可以“请教” AI 。因为对于实习生，我们同样也可以进行“请教”，术业有专攻，这十分正常。

但是，对于实习生，你大概率不会不加思索地问一些肤浅的问题。就算是这个问题可能很简单，你都要以严谨的方式问出：“那么考虑到目前的情况，更好的技术路线应该是哪个？请基于生态、开发难度、维护难度、性能、成本等角度为我概述。”同理，你也应该如此与 AI 交流，以最大化我们获取有效信息的效率。

---

结语 ：熟悉我的读者知道，在一年以前，每当提到“AI”，我都要如此用引号起括来这两个字母。因为我不认为如今的概率模型具备真正的“智能（Intelligence）”。如今我依旧这么认为。但是，我也认为，我们应该与时俱进，而非在形式上固步自封。我虽然主观上不喜欢 AI 工具，但我敢说我是除了专业研究人员外，最积极、最主动、最大量地尝试各种 AI 新工具的一批人。让我们一起批判地学习，持续改善，良品良考。