这两天知乎上又冒出一串几乎同题的问题：「用 AI 写代码后，你会逐行看懂再提交，还是先跑通功能再说」「用 AI 编程写完一个小项目后，你会愿意直接把代码提交到生产环境吗」「你们团队用 AI 写代码，code review 还是人挨行看，还是生成的就先合」。往前翻，从 5 月到现在同类提问至少有八个，最热的一条底下挂了 159 层楼。这不是新问题，是被 AI 代码量逼到墙角的老问题。知乎知乎
有个高赞回答把自己的变化讲得很直白：前两年 AI 写一个方法，他逐行检查；近一年 AI 直接写整个功能模块甚至整个项目，「一行一行读代码已经可行性不大了」，只剩让 AI 写完、自己跑功能、出 bug 再让 AI 改。看和跑，似乎只剩一个能选。知乎
两组数据都对，但都答不了这个问题
要判断该选哪边，先看数据。正面阵营够硬：GitHub 与微软研究院的受控实验里，用 Copilot 的开发者完成任务快 55.8%，PR 周期从 9.6 天压到 2.4 天；麦肯锡调研 150 家企业的 4500 名开发者，常规编码任务时间降了 46%；Anthropic 的 2026 报告给样板代码和脚手架算了 78%、测试编写 64%。知乎
反面数据同样真实：METR 在 2025 年 7 月的随机对照实验里，16 位资深开源开发者在自己熟悉的成熟仓库上用 Cursor、Claude 干活，反而慢了 19%——最扎心的是，他们自己觉得快了 20%。DX 平台 2026 年分析了 12.1 万名开发者：93% 在用 AI，AI 使用量涨了约 65%，PR 吞吐量却只涨了 9.97%。还有一项纵向研究直接发现，Copilot 用户采纳后 commit 数量没有统计显著提升，主观生产力感受却是正面的。知乎
把两边摆在一起，规律就浮出来了：提效高度集中在「低复杂度、高重复、边界清晰」的任务——样板代码、单元测试、注释、脚手架，大概占开发者时间的三成；任务一复杂，提效曲线急速下滑，甚至转负。所以「快 55.8%」和「慢 19%」根本不矛盾，它们在给不同地形画地图。
真正值得抄走的是那个「觉得自己快了 20%」：主观感受连当提效证据都不够格，更不能当提交依据。「逐行看」靠的是「我全扫过一遍」的安心感，「先跑通」靠的是「功能没报错」的确定感——这两种感觉，恰恰都是数据里最先破产的东西。
社区自己已经跑出来的第三种答案
吵归吵，真正每天在交代码的人已经收敛出一套按影响面和可撤回性分档的打法，而不是按行数。
知乎那条被大量引用的回答给了三档：改样式、文案、加个重试——跑一遍看结果就行，「逐行看完听起来最负责，实际上是第一个会被放弃的标准」，一次几百行的 diff 读完要四十分钟，可能只有两行是关键改动；改接口契约、错误分支、状态流转——看的不是代码本身，是谁在调它、失败时会发生什么；写数据、动权限、改并发——不要读代码，直接在真实环境里验证行为。三档里最容易被跳过的恰是最后一档，因为它最慢，「但出事也只出在这一档」：前两档错了，报错信息会告诉你；最后一档错了，是几天后从线上和用户那里知道的。知乎
团队场景有人直接立了四道闸门：SDD+TDD 保证测试本身正确，AI 对着规格再 review 一遍，人工黑盒测试兜效果，人肉粗看大致逻辑收尾——「任何一项没有，就是不对代码负责任」。这条路线有人跑过实操：一位后端把 AI 生成的六个页面代码按团队正常流程提交评审，被同事挑出 14 条——命名和可读性 6 条（全是习惯问题）、异常和边界 5 条、并发和事务 3 条，结构问题只有 2 条。他对比后承认：要是手写代码，估计只会被挑五六条；多出来的八九条，集中在「没有团队习惯的位置感」和对业务上下文的无感知——批量上限是多少、要不要处理并发，工具都不知道答案，因为没人告诉过它。他的结论值得抄下来：AI 给的不是免检品，是「一份质量不错的初稿」，十四条全部能在 review 阶段拦住，前提是这一步真做了。知乎知乎
而彻底的「不读派」其实也不是裸奔。一位独立开发者的流程是：第一遍让 AI 把架构、重要接口契约与数据流写成总结，人来核对有没有偏离施工文档（AI 很喜欢在文档边界模糊处「顺手优化」）；第二遍派一堆子 Agent 去挖逻辑错误和冗余调用；然后让 AI 设计大量边界测试，出 bug 修到全过。人从头到尾不管代码长什么样，只盯三件事：算法架构有没有偏离、有没有低效冗余、边界测没测到。知乎
小红书上一篇「AI 写代码久了，小心这 4 种隐形债」补了更狠的一刀：AI 把查资料、写原型、推翻重来这段慢过程跳过去，功能交付了，判断力却没长出来——偏偏审 AI 的输出，靠的就是这份判断力。它给的两个解法很具体：别急着让 AI 动手，先生成分阶段计划、审过再实现（代码还没写，人已经知道它大概长什么样）；再学 Matt Pocock 的 /grill-me，让 AI 反过来追问你，被问住的地方，就是没想清楚的地方。底线一句话：AI 写了什么，人得说得清。小红书
明天就能用的三个动作
提交前，说出这次改动「在什么情况下会出错」。 说得出来，哪怕只看了三十行也算读懂；说不出来，逐行看完也只是眼睛滑过。知乎
让 AI 用三句话总结这次改动和它自己认为的风险点。 它说不利索的地方，恰好是你该重点看的地方——这也是「AI 既当球员又当裁判」的破法：测试也是 AI 写的，通过不了的 case 可能被它悄悄删掉，你根本不知道，所以测试这层必须有人盯着。知乎
要求「产物+证据」而不是「我看过了」。 类型检查、测试跑通、diff 对比，都算证据。一位踩坑合集的开发者总结得朴素：给它一条能跑的命令，比给它更多的提示词有用一百倍。知乎
三种人，三种风险，不是一个答法
Solo 玩票/新项目党：「先跑通」短期风险可控，真正的雷是三个月后没人说得清这坨是怎么搭起来的。最低标准就一条：AI 说不清、你也说不清的模块，别合。
团队协作党：把没读过的生成代码直接合，本质是把审查成本转嫁给同事。微博上一条 263 赞的讨论说得很准：AI 把生成成本压到地板后，「拉开差距的是技术判断力和责任心」，只取中间生成那一步、跳过需求分析和验收的人，「是在用 AI 批量生产别人的负债」——AI 没法承担责任，代码出事，背锅的还是署名提交的那个人。微博
成熟仓库老兵（METR 那类人）：最反常识的一档——越熟悉代码，AI 越可能不帮你提速，因为瓶颈在理解和取舍，不在打字。你的审查预算最该花在第二档：接口契约和状态机，那才是你比模型值钱的地方。
为什么这事只会更紧
规模已经不是假设：知乎那条讨论「AI 代码会不会变成屎山」的 159 评回答里转述，Google 在 2025 年四季度财报电话会上明确说了，大约一半的代码已经由智能体编写、再由工程师审查。10 月 1 日 Codex Cloud 上线，编程任务可以在云端持续执行，从手机发起、合上电脑接着跑。方向很清楚：AI 单次产出还在按小时翻倍，「读不完」只会更彻底。与其等到 PR 堆成山再被迫选边，不如现在就把「读多少」从习惯问题变成预算问题——先拿你最近三次返工或线上事故复盘一下：问题是不是都落在数据、权限、并发、接口契约这几类上？答案就是你该把阅读预算花在哪一档。知乎知乎
至于「逐行看还是先跑通」，按这个分法，两个都不用选：能撤回的看结果，不能撤回的验行为，说不清的别合。
