今天下午我坐高铁去深圳旁边是一位正在找实习的大三学生。聊了一会儿发现她刚好要面试 AI 应用开发岗位我就和她交流了一下 AI 开发的经验。聊着聊着她问了我两个问题“现在大家都用 AI 做项目我应该拿什么当作品集”“如果以后都让 AI 写代码我看不懂它写的代码怎么办那我现在辛辛苦苦学编程还有意义吗”她的担心里藏着两个等号AI 写代码 我学代码不再有价值。我不能逐行理解 这份代码更差、更乱、更不可靠。这两个等号我先不发表意见。我先想到的是另外两个问题她为什么会把“AI 开始写代码”和“自己几年白学了”连在一起为什么一想到自己不能逐行理解脑子里先出现的就是“AI 写出来的东西可能很垃圾”而这两个问题又把我带回了一个从 AI 编程出现起就没停过的争论AI 写的代码到底能不能用为什么有些人总是高高在上地嘲讽用 AI 写代码的人尤其喜欢抓住一点你连 AI 写的代码都看不懂代码质量一定很差。我觉得这件事刚好值得讨论一下。为什么“必须逐行看懂代码”这件事情值得怀疑先说“看不懂”这件事。别再拿“能不能逐行看懂 AI 代码”判断一个人配不配做开发。我尤其想问那些人一句你能看懂 0 和 1 吗你能逐条审核编译之后的机器指令吗如果做不到凭什么把“逐行看懂”拿来当优越感今天写程序的开发者有几个能逐条解释编译器生成的机器指令不说机器指令汇编语言懂的人又有很多吗大部分也都是只会高级语言。操作系统、数据库和网络框架的全部实现又有几个人完整读过现代软件本来就建在一层层抽象上。我们要知道所用能力提供什么、会在哪里失效不需要先把下面几层重新手写一遍。AI 当然不是编译器。编译器的语义相对稳定AI 是概率系统会误解需求会重复造轮子也会在一次看似无关的修改里破坏旧行为。我拿机器码做类比不是要抹平这种差别而是因为它们都在做同一方向上的事把人的意图继续转成更低层的执行细节让人的注意力向上迁移。既然软件开发早就允许人依赖没有逐行读过的抽象层为什么到了 AI 这里“逐行看懂所有实现”又突然成了开发者的资格证我反对的不是理解代码而是把“逐行看懂代码”当成开发者的阶层准入门槛。AI 没有发明屎山它只是放大器先说第二个等号不能逐行理解就意味着代码更差、更乱、更不可靠。如果一个人连自己的项目解决什么问题、为什么这样解决都答不上来没有测试没有回滚路径只剩一句“AI 说它完成了”这当然是垃圾工程。但这真的是 AI 的专长吗难道人类不会产出屎山代码安全漏洞、重复代码、坏抽象和屎山都早于 AI。人一样会为了赶进度复制粘贴会在没有测试时改坏旧功能也会把临时方案留成谁都不敢动的永久架构。AI 改变的是速度。以前一个人要花一周堆出来的混乱现在一天就够。反过来边界清楚、约束明确、测试扎实的团队也能用同样的速度推进。真正的问题是代码生产突然变快了验证体系却没有同步长出来。自动测试、接口契约、静态分析、变更记录、风险分级、真实环境验收和回滚设计必须接住多出来的产能。我们缺的不是重新逼所有人逐行阅读而是一套能判断这些代码究竟能不能交付的稳定方法。所谓控制是系统地图、风险边界和验证方法不能一起消失。证据不足时就让 AI 解释、缩小改动或者重构出了问题就把范围收进某个模块、某条数据流或某次变更。一个周末原型和医疗、金融、安全关键系统当然不能采用同样的理解深度。失败代价越高、验证越弱、维护时间越长人就越要深入实现必要时直接接管关键部分。你承担多大的责任就要拿出多深的理解和多强的证据。代码可以有没逐行读过的部分但工程不能跟着变成盲盒。AI 编程争的到底是代码质量还是话语权既然 AI 的风险是真的为什么我还要把话说得这么尖锐因为很多围绕 AI 编程的争论表面上在谈代码底下争的却是谁有资格定义什么叫开发者。真正担心安全就指出攻击面和失败样例担心维护就指出耦合、依赖和修改影响担心回归就看测试和发布门禁。这些都可以拿证据讨论。可有些争论根本不谈证据。它们从“这段代码有什么问题”直接跳到你必须亲手写。你必须逐行理解。你必须按照旧有的方式完成学习。否则你就不算真正的开发者。这就不再是在审代码而是在划职业边界。一个人花十年熟悉语法、框架、API 和各种工程细节过去这些能力足以形成一道很高的门槛。现在 AI 把其中不少实现工作变得便宜一个经验没那么深的人也可能很快做出过去需要多年经验才能完成的功能。被威胁的当然不只是工作还有晋升、薪资、自尊和专业地位。这时最容易发生的不是平静地承认“我的一部分能力正在失去稀缺性”而是重新定义什么才算真正的开发我最熟悉的方式才是唯一正统的方式。我不是说每个批评 AI 的人都害怕失业也不需要猜每个人心里在想什么。只要看讨论有没有从“结果哪里不可靠”滑向“用这种方式的人不配”就够了。前者是工程批评后者是资格审查。旧能力当然有价值。但任何一个职业群体都不能因为新的工具威胁了自己的稀缺性就把自己的不安全感包装成行业真理吧。我反对的不是理解代码而是把自己熟悉的那一层实现包装成所有人进入开发者职业的唯一门票。我在 Curio 里实际负责什么拿我自己来说。我现在也基本上是用 AI 写代码。你说我不理解我的代码我也不辩解。但我到底在做什么系统怎么分、功能接进哪条产品路径是我定它实现。代码什么时候应该停下来简化哪些函数和模块需要重新抽象是我提出它执行。功能做到什么程度才算交付是我定义它完成我验证。这里面我没有消失吧开发 Curio 时我更常先想清楚用户现在在哪里接下来最自然的动作是什么中途改变主意时什么东西不能丢一个新功能应该接进现有哪条产品路径而不是再造一套看起来差不多的页面。需求还没对齐时我不会急着让 AI 写正式代码。我先让它画原型把理解变成一个看得见、点得动的东西。原型不对就继续改理解而不是先制造一堆以后要删的代码。原型对齐以后我再让 AI 去读代码、找实现位置、提出方案、补测试和完成修改。结构变复杂了我会叫它停下来简化或者重构。出了问题我未必会先扑进去逐行定位但我会让 AI 挨个代码段检查、分析、测试把问题缩到某个模块、某条数据流或者某次变更再决定能不能交付。我也不会看到“测试通过”四个字就觉得结束了。代码写完、自动测试、模拟器、真机、内测和公开发布是不同的门禁。每一道门禁都只证明自己一层层通过我才会把新版本交到用户手里。脏活累活可以让 AI 干但产品应该是什么样、工程有没有失控、证据够不够、最后交不交仍然是我负责。所以如果问我在 Curio 里贡献了多少我不会用代码行数回答。我负责定义什么算对驱动 AI 把它做出来再对最终交付负责。基础没有失去价值只是用途变了回到列车上那位学生。她学过的代码当然没有白费只是不必再把用途限定为亲手生产每一行。而且所谓“亲手生产”过去不也包括 CtrlC、CtrlV以及去开源项目里“借鉴”吗她学过的语法、框架和调试经验今后更多会被用来判断 AI 的方案、识别风险、设计测试、控制复杂度以及在关键位置接管。你知道状态为什么会丢才能要求 AI 检查数据生命周期你知道模块为什么要有边界才能看出它是不是为了赶功能把所有东西揉在一起你真的调试过才知道“页面能打开”和“问题被解决”之间还隔着多少东西。基础没有失去价值只是从生产工具变成了判断工具。初学者仍然要亲手写、亲手调。没有那些失败和修正所谓技术直觉只是自我感觉。区别在于学习的终点不再是永远手写所有实现而是能约束 AI、看出坏设计并在必须接管时真的接得住。AI 应用开发的作品集到底该拿什么证明自己现在可以回答她的第一个问题了AI 应用开发的作品集到底该拿什么证明自己不要再凭空做一个 Todo List也不要靠堆功能证明自己。找一款成熟、边界清楚、最好能单机运行的软件实际用一遍留下截图和录屏再跟 AI 一起拆它的页面和流程为什么搜索放在这里为什么这个动作在右边为什么先选东西再命名拆完以后复刻其中最小的一条闭环。复刻的重点不是把界面描得多像而是说清楚原产品为什么这样做、自己保留了什么、删掉了什么。AI 在实现中犯过的错也应该放进案例里错在哪里怎样发现最后用什么证明已经修好。现在“做出一个东西”已经很便宜了。作品集继续晒代码量意义只会越来越小。拿去面试时她应该讲清楚自己怎样看懂这个产品又怎样把一个问题一直带到交付。如果第二天就开工可以把这件事压成具体动作第一件事选一款成熟、边界清楚、最好单机运行的软件截图并拆出最小闭环。第二件事让 AI 协助分析设计、画原型、完成复刻同时做一个不同于原产品的判断。第三件事实现功能建立测试、模块约束和变更记录把 AI 犯过的错误也留下来。第四件事整理为什么选、如何拆、AI 做了什么和错了什么、怎样验证、自己的判断是什么、最终交付到了哪里。这份案例不靠功能数量取胜。面试官应该从中看到产品由她定义AI 参与实现验证和交付由她负责。至于她问的第二个问题——“我现在学代码到底还有没有用”当然有。只是代码基础以后更多用来判断方案、发现风险和关键接管不必再拿它和 AI 比谁写得快。她也不需要先拿到某群人颁发的“真正程序员”资格才开始做产品。把一件事做出来说清楚为什么做、哪里有风险、怎样验证并对结果负责这些比“每一行是不是亲手写的”重要得多。谁能定义问题、控制工程风险并完成交付谁就在做真正的开发。如果你看完了还觉得 AI 写代码是违背祖宗之法那我只能说你对。