先说个这两天刷知乎、微博反复撞见的怪现象。
一边，"AI编程平权"的调门越来越响。吴恩达说人人都该学编程，理由恰恰是 AI 让写代码变得前所未有地容易；微博上 #VibeCoding为何让人上头# 几千赞，一句"以前写代码像考驾照，现在写代码像打车"被转疯了；小红书上连研究生都在发帖问，自己复现改进一个项目、刚开始还会看看，后面直接就全自动了，这正常吗？小红书
另一边，真正天天泡在里面的人，说法却拧着来。宝玉xp有条被转了很多次的观察——虽然大家都在用 AI 编程，代码产出水平的方差反而比以往更大了。知乎一个高赞回答更扎心：现在程序员水平越高，AI 代码的含量反而越高，越菜的人才越需要手写。微博知乎
这就有意思了。AI 明明是个把门槛砸到地板的"平权工具"，怎么用的人越多，差距反而拉得越开？
我扒了一圈知乎、微博、B站的讨论，又翻了几份能查到的大样本数据，发现答案藏在一个被大多数人搞错的评判标准里：我们一直拿"AI 替我写了多少代码"当深度尺，但真正拉开差距的，是"写完之后，你还管不管得住它"。
一、“AI 写了多少代码”，是条假轴
知乎有个问题叫"你用 AI 编程用到什么深度了"，选项从 A 排到 D，D 是"完全靠 AI 做出一个完整项目"。
底下有个回答一针见血：选 D 的人里，其实混着两种完全不同的人。
第一种，基本不写代码。用 v0、bolt.new、Lovable 这类工具，说一句话，出一个能跑的网页。他们的上限，是原型。
第二种，是工程师。用 Claude Code、Codex 这种终端 Agent，或者 Cursor 的 Agent 模式，让 AI 在自己的代码仓库里改几十个文件、跑测试、提交。他们的上限，是能长期维护的产品。
两拨人都会勾 D，聊的却根本不是一回事。
那个回答补了句关键的：真正该加的那条轴，不是"AI 写了多少"，而是"你还能不能控制它"。AI 写了 90% 的代码、你能看懂每一处改动，这是一种 D；AI 写了 90%、你只看界面能不能点，这是另一种 D。后面所有的翻车，几乎都出在第二种。
这话把整件事的坐标一下掰正了。工具决定的只是"能跑"的门槛，而"能跑"和"能维护"之间，隔着一整个你看不看得懂、管不管得住的鸿沟。
二、用得多，不等于信得过，更不等于快
如果上面还是感觉，那看两组能查到的数据。
Stack Overflow 2025 年开发者调查，收集于 2025 年 5 月底到 6 月中，49009 份有效回答。用 AI 工具（含打算用）的人从上一年的 76% 涨到了 84%，47.1% 的人每天都在用。但诡异的是——用的人多了，信的人反而少了：对 AI 输出准确性的信任从 40% 掉到 29%，好感度从 72% 掉到 60%。排第一的抱怨占了 66%，就一句话："AI 给的方案差一点就对，但就是不对。"还有 45% 的人觉得，调试 AI 写的代码比自己写还费时间。知乎
（这份问卷得交代一句样本偏差：填它的主要是职业开发者和学习者，不代表用 v0 搭网页的运营、产品。那群人可能早就"全员 D"了，只是不填问卷。）
画面就很清楚了：大部分开发者卡在 B 和 C——天天用，但不敢真让它独立干活。
再看一个专治"我用 AI 效率翻倍"错觉的实验。AI 安全机构 METR 在 2025 年 7 月做过一个随机对照：16 位资深开源开发者，在自己熟悉的成熟仓库里做 246 个真实 issue。开发者事前预计 AI 能让自己快 24%，做完后仍觉得快了 20%，而实测结果是——允许用 AI 时，任务耗时反而多了 19%。
这个"越用越慢 19%"被全网转疯，但它有复现争议，得把话说完：2026 年 2 月 METR 更新，说新一轮里越来越多开发者因为"不想在没有 AI 的条件下干活"而拒绝参加，这很可能把测出的加速效果压低了；重新估计的置信区间宽到 -38% 到 +9%。所以"AI 让老手慢 19%"这句话，2026 年已经不能原样引用了。
但真正站得住、也更有用的结论是另一半：人对自己用 AI 到底快了多少，估得极不准。 你觉得快了 20%，和实际快了多少，是两码事。
三、连"vibe coding"这个词的发明者，自己都在反复横跳
最有说服力的样本，是 Andrej Karpathy——“vibe coding”（氛围编程，顺着感觉让 AI 写、自己基本不看代码）这个词，就是他 2025 年 2 月在推特上随口造出来的。
结果到了 2025 年 10 月，他发布 nanochat 项目，反倒成了自己的反面教材。他说这个仓库基本是手写的，只用了 Tab 补全；也试过 Claude 和 Codex 的 Agent，效果太差帮不上忙。后来在播客里他讲得更细：Agent 写样板代码很强，因为网上例子多；可 nanochat 结构太独特、离训练数据的分布太远，模型老想往里塞它根本不需要的 DDP 容器，到处加 try-catch，把代码库越弄越臃肿，还反复调用过时的 API。
又过了三个月，风向再翻。2026 年 1 月 26 日，他发帖说自 11 月以来，自己的工作方式从大约 80% 手写翻转成了 80% 交给 Agent，原因之一是 Claude Opus 4.5 的进步。但他特意提醒：手写代码的能力可能会退化，建议"让 AI 去审 AI 写的代码"。而且他并没有放手不管——左边开几个 Claude 会话，右边开着 IDE 盯着看。他说模型的错误已经从语法问题变成了概念问题：假设错了不问你、不说明取舍、爱把抽象搞复杂、留一堆死代码。
从这段横跳里能拿走两条铁律：
第一，能不能上全自动，跟项目类型强相关。常见的 Web 应用、CRUD 后台，AI 熟得很；独特的、研究性的代码，AI 可能越帮越乱。
第二，就算是全世界最会用这类工具的人之一，到了 D，也还是开着 IDE 审代码。“完全基于 AI"和"完全不看代码”，是两码事。
四、不看代码的代价，是真金白银
上面是"能力"层面，下面这些是"事故"层面——都是公开、细节清楚的翻车。
删库。 SaaStr 创始人 Jason Lemkin 用 Replit 的 AI 做了个 12 天的 vibe coding 实验。第 9 天，AI 执行了一条破坏性命令，删掉了存有 1206 位高管、1196 家以上公司记录的生产数据库。而当时系统正处在代码冻结状态，本来就是防止改动生产环境的。Replit CEO 事后回应，说会自动隔离开发库和生产库、改进回滚，还要做一个"只规划不动手"的模式。这事最该记住的教训在权限设计上：只要 AI 能碰到生产库，它迟早就会碰。知乎
数据裸奔。 研究员 Matt Palmer 扫描了 Lovable 公开展示区的 1645 个应用，发现其中 170 个、共 303 个接口，只靠前端公开的 anon key 就能直接读写 Supabase 数据表——因为这些表从没开启行级安全（RLS）。泄露的内容包括邮箱、地址，有的连 API 密钥都在里面（漏洞编号 CVE-2025-48757）。公平起见也说另一面：Lovable 对此有异议，理由是每个用户要对自己应用的数据安全负责。谁的锅可以吵，但用户这边的现实很扎心：不知道 RLS 是什么的人，压根不会想到要去查它。
系统性漏洞。 Veracode 2025 年的报告拿 80 个编码任务测了 100 多个大模型，45% 的情况下 AI 写的代码带有安全漏洞。其中 Java 的安全失败率超过 70%。报告还发现一个更值得警惕的趋势：模型写"语法正确"代码的能力在进步，安全表现却没跟着变好。（同样得交代样本：这 80 个任务是按 CWE 分类特意挑的、本身就容易出安全问题，所以 45% 不能理解成"你项目里一半代码有漏洞"。它真正的含义是——你不主动提安全要求，AI 很可能就不替你考虑。）知乎
B 站那条 IBM Technology 的视频把这层意思总结得很到位：当代码实现不再是难点，瓶颈就转移到了"人工验证"和"证据驱动开发"上。写，变得廉价；判断写出来的东西对不对、能不能上，才是稀缺的那一环。哔哩哔哩
五、那到底该怎么站位
说了这么多坑，也别走向另一个极端——不是所有场景都该"慢下来"。
这些情况，直接上 D 完全合理： 内部小工具、活动页、验证想法的原型、一次性的数据处理脚本。它们寿命短、出事影响小，让 AI 一把梭，省下的时间是实打实的。为一个周末就想扔掉的原型去逐行审代码，才是真的浪费。
这些情况，我劝你慢一点： 要长期维护的产品、能碰到生产环境和真实用户数据的部分、安全敏感的逻辑、以及结构独特的研究性代码。这些地方，AI 帮你省的时间，很可能在三个月后连本带利还回去。
至于具体怎么做，公开分享里真正做成 D 的人，工作流长得惊人地相似，翻来覆去就六件事：写规格、立规矩、小步走、有测试、管权限、审 diff。 工具从 Copilot 换到 Cursor 再换到终端 Agent，这六件事一直没变。
看出门道了吗——这些功夫跟"会写 prompt"关系不大，跟"当技术负责人"的那套基本功高度重合：定需求、拆任务、设权限、做 code review，老派得很。AI 把"写代码"的活儿接走了，"管代码"的活儿一点没少，某些时候反而更多了。这也不只是个人感受：腾讯高管就公开披露过，公司约 50% 的新增代码已由 AI 辅助生成，代码评审环节的 AI 参与度更是高达 94%。Google 那边也多次提到，相当比例的新代码正由智能体编写、再交工程师来审查。当"写"越来越便宜，"审"和"管"自然就成了人的主战场。知乎
这也解释了开头那个悖论：为什么水平越高的人 AI 代码占比越高——因为他们本来就具备管住大量代码的能力，AI 只是把这份能力放大了；而基础薄弱的人把 AI 当替代品，放大的就是混乱。
最后给一个特别实在的自测方法，专治"我觉得我挺快"的错觉：别自评，掐表。 挑两批难度相近的活儿，一批用 AI、一批不用，连"改 AI 代码的时间"也一起记上，两周后看数字。你在哪一档，数字比你诚实。
写在最后
知乎那个高赞回答的结尾，我很喜欢，就拿它收：现在评判一个人 AI 编程用得深不深，我更愿意看他审 AI 代码的能力，而不是 AI 替他写了多少行。
这一波工具红利里，真正的护城河正在从"会写"迁移到"会验收"。所以与其为"AI 能写多少、会不会取代我"焦虑，或者盲目为更强的模型和更贵的订阅掏钱，不如把精力投在那个 AI 短期内替代不了、且完全属于你的能力上——看懂它、管住它、验收它。 毕竟工具再强，最后为那行"看起来没问题"的代码签字负责的，还是你自己。
