9月21日这天，知乎编程话题下几乎同时冒出一组"孪生问题"：《用AI写代码后，你们会逐行看完它生成的代码再提交吗？》《AI改了这么多代码，我该怎么看？》《用AI写代码后，你是怎么判断它给出的方案靠不靠谱的？》。其中一个题主的描述很有代表性：他最近让AI帮忙补功能，代码能跑但总怕埋坑，想知道大家会看哪些地方，才敢真正合进项目。知乎
这轮集中爆发不是巧合，是产量曲线变了。知乎用户DBinary在同一天的回答里说得很直白：AI做出一个功能的能力很强，吭哧吭哧就能怼出几万十几万行代码出来，而多数本来并不复杂的功能被怼出几万十几万行，本身就是个巨大的问题。知乎
而且这不是小用户的体感，是头部团队实测出来的系统性问题。Anthropic在9月中旬披露的一组内部数据里，全公司80%的代码由Claude编写，工程师每季度交付的代码量达到2021—2025年平均水平的8倍；测试用例狂飙10倍，CI运行任务量在半年内暴涨25倍，团队连续加核心、分片、每日强制重启三轮补丁都没能彻底扛住。 代码从稀缺品变成溢出品之后，瓶颈正式从"写"挪到了"看"和"消化"。36氪
逐行党睡不着，放养党迟早背锅
先看两个真实立场。
逐行审的极限什么样，有个很诚实的回答说自己还是会一个个看，没办法，可能是强迫症，还不够，要让另一个同等级别的AI也审核一遍，不行就再上一个AI去审核它，这样才能确保安稳，否则总睡不踏实。 人看一遍、AI审一遍、再拿一个AI审第二个AI——情绪是真的，但这条路线的成本也是真的：审查AI的成本快赶上重写一遍。知乎
完全不看呢？另一篇同天的文章《AI写的代码，最后还是你负责》给了标准翻车现场：代码改了三轮，问题还在，AI每一轮都能给出解释——第一次说是初始化顺序，第二次说要处理异步，第三次建议加重试，听起来都有道理，改动越滚越大。最后有人问了一句"接口到底返回了什么？"才发现，最该确认的事，一开始就没确认。知乎
真有人选择不看。前Cursor工程师、现在负责SpaceXAI GrokBot的Lauren Tan在8月底分享时说自己"基本不看代码了"：她同时跑20多个智能体，上个月交付了1000多个PR，一觉醒来，20个PR已经躺在主干分支上了。 但她给出的不是躺平示范，而是一条"信任曲线"——纵轴是信任，横轴是能同时开的智能体数量，从1到成千上万：信任是一档一档挣出来的，先让智能体自己验、自己修，跑通了再放下一档。36氪
两头都走不通，社区这两天真正沉淀下来的，是一套中间打法。
做Claude Code的团队，自己是怎么审的
先把一个容易被忽略的信源摆出来：9月13日，博主宝玉xp翻译了Claude Code团队三位成员（Thariq Shihipar、Sid Bidasaria、Robert Boyce）的播客回顾，里面正好有官方视角的审查分工：
团队70%–80%的工作已经通过Slack原生智能体Claude Tag完成，人只在剩下20%里打开终端做精细调整；
传统人工代码审查中，审查者常挑几个小毛病来"证明自己读过代码"——这类琐碎问题现在交给AI自主处理，人工审查者聚焦API设计逻辑、服务边界划分这些AI写PR时未必理解的架构决策；
更进一步是"MapReduce式审查"：先让多个智能体并行搜索潜在bug，再对每个bug做对抗式审查（从三种视角判断是否真实），最终只把最值得关注的问题交给人。微博
值得注意的是，模型厂商自己的工程团队也没有把"AI自查"当终审——审查流水线的出口仍然是人。人看的东西变了：从"代码行"上移到"问题定义"。
审查本身已经是一门生意
"AI写的代码谁来把关"这个问题大到能撑起一家公司：AI代码审查工具CodeRabbit宣布完成1.43亿美元C轮融资，估值已超过15亿美元，约合人民币108亿元。 它的打法值得看一眼：接入GitHub、GitLab等主流代码托管平台，结合代码库上下文自动分析PR，检测到逻辑、质量和安全问题时直接生成修改建议——本质上就是把上一节官方团队那套"AI先筛、人看关键"做成了产品，按其官方说法，要解决的就是海量AI生成代码的智能分诊。36氪
个人用不用得起另说，但它坐实了一件事：你感觉审查不过来，不是你的问题，是这个阶段的公共问题。
这两天讨论里真正活下来的6个方法
把9月21日这波问答长文里可操作的部分去重、合并，能落地的大概是这6条，按一次审查的时间线排：
1. 入口换成"预期行为"，不是AI的文件列表。 经典例子（出自《AI改了这么多代码，我该怎么看？》）：一个提交按钮防重复点击，AI加了"正在提交"状态、改了按钮显示、还顺手调整了公共请求方法。直接打开diff，很容易先被状态命名、提取是否合理这些细节吸走。正确姿势是先写下三条预期——第一次点击应该正常提交；请求还没结束时再次点击，不应该多发一份；请求失败后用户应该能够重试，不能让按钮一直卡住。 带着这三条再进代码，注意力会自动去找"状态在哪设置、拦截在请求前还是后、失败怎么收尾"。如果阅读顺序完全由AI改了哪些文件决定，你会一路跟着它的思路走，忘了检查它最初有没有走对方向。知乎
2. 单独把失败路径走一遍。 "发请求"和"成功后恢复状态"两段单看都合理，把失败过程走一遍缺口才出现：如果状态只在成功回调里恢复，正常提交一切正常，失败一次按钮就再也点不动了。
3. 隔离"顺手改"。 AI的diff里有一类改动不解决眼前问题、但解释很好听：统一处理方式、减少重复、方便扩展。判断标准就一句——把它拿掉，原来的问题还能不能解决？能，就拆出去单独讨论。公共方法的改动会把你的审查范围从"一个页面"扩大到"所有调用方"。有时候审查最有用的结果，是让这次提交少改一点。Anthropic那组数据还给了一个反向印证：Claude偏爱"更小、更碎、更密"的PR——碎，本身就是留给审查的空间。
4. 把AI的解释变成一次可执行操作。 你问"请求失败后会不会一直卡在提交中？“AI答"不会，恢复逻辑放在finally中”。这不是结论，是线索：实际代码里这个finally是否覆盖了担心的路径？恢复的是不是按钮正在用的那个状态？拿不准就当场模拟一次请求失败，看状态是否恢复、能否重新提交。
5. 让另一个AI审可以，但要递问题，别递案子。 笼统地说"再检查一下有没有问题"，收获的是另一段流畅解释。有效的问法是："这次修改要求请求失败后可以重试。请沿着失败路径检查状态如何恢复，指出对应代码和仍然无法确认的地方。"即使两个AI都说没问题，也要看它们拿出了什么依据——让一段流畅的解释替自己消除顾虑，是审查里最容易松一口气的错误时刻。
6. 合并前，关掉AI的总结，用自己的话讲一遍。 原来的问题是什么，哪几处修改共同解决了它，失败时会怎样，还有什么没确认。说到一半卡住了——卡住的地方就是接下来该看的地方。“每个文件我都看过"不如"我能说清为什么接受这批改动，并且拿代码和验证结果对得上”。
不同人别抄同一份清单
个人项目、一次性脚本：抓第2、4条就够——跑一遍失败场景、拿一个具体动作验证解释。有工程师9月22日在B站发批量材质脚本的视频里那句话很典型：肯定有更优解，但AI一分钟写出来的也够用了，这种脚本花审查时间反而不划算。哔哩哔哩
团队生产代码：第3条是铁律，顺手改公共方法/共享逻辑是本周讨论里公认的事故源，动公共代码单独开PR。分工可以照官方团队那套来：琐碎问题交给AI初审，人盯API设计和边界划分。
还没上手Agent编程的观望党：这轮讨论真正的信息是——工具再变，“责任不会外包”。你省下的写代码时间，有一部分会变成审代码时间，区别只在于你有没有一套固定动作把它压薄。
题主们还在收答案：《用AI编程后，你最舍不得交给它写的代码是哪一类？》的题主自述涉及核心业务逻辑时还是会反复自己写，问大家不放心它碰哪部分——是质量、维护成本，还是怕能力退化。 这三个动机，恰好对应这场讨论里的三种人。知乎
你现在敢让AI写、但不看就提交的，是哪类代码？评论区对一下清单。
