9月16日，一篇《AI写的史山让我重新学习软件工程》在知乎拿到499赞。作者Land1ngW，先后在腾讯和米哈游做引擎开发，自述"真正开始认真写代码不到两年"。他在机场候机时学了南京大学蒋炎岩老师那门突然走红的《生成式软件工程》公开课，落地后写下这篇复盘。
复盘的现场很不体面：一个实时几何功能正式提交前做code review，改动列表里躺着两三百个文件，他点开想自己先过一遍，结果不少类名和函数名都觉得陌生——他是这个功能的"作者"，却说不清每个文件为什么要改。他的老大拉着椅子坐到工位旁边一起看，两个文件没看完，他就绷不住了。之后是几个月的逐模块重构。知乎
同一时间窗口，知乎问题"AI coding导致代码量大幅增加，如何做好代码质量管控？"浏览量已经堆到22万+（截至9月19日采集），8月底到9月中，好几个平台的AI编程讨论区都在回答同一个新问题：AI能写代码之后，越来越多人写的代码，谁来兜底？知乎
这篇内容就是为一种人写的：你日常用Codex、Claude Code这类agent写码，项目从"一晚上跑通的demo"长成了"越改越错的正经工程"；SDD、TDD、写文档喂上下文这些方法论黑话你已经刷到腻，缺的是一个真金白银验证过的判断——AI写的代码，到底要不要逐行读？
三个门派，其实是三套已经有人跑过的策略
第一派说：不用读，验收就行。
同题问题下364赞的回答（作者"泡沫艺术家"）开宗明义：“根本不看一行代码”。 他的完整流程是两遍Review：第一遍不优化，让AI先从代码反推出实现架构、接口契约和数据流的简要总结，人来核对有没有偏离"施工文档"——他的原话是"AI很喜欢在文档边界模糊的地方，顺手加上点优化"；第二遍让AI派一堆子Agent去挖逻辑错误、低效算法和冗余调用，报告人审完再让AI改；最后让AI生成大量用例跑边界测试，出bug就定位、修改、重跑，直到全过。此后他只关心三件事：实现有没有偏离原定算法与架构、有没有低效冗余、测试是否覆盖边界。他顺手更新了程序员的黑话：代码的主要阅读者已经变成AI，“这就跟装电脑一样，线材全塞背面，后盖一盖，性能挺高就够了。”知乎
第二派说：不读，你会死得莫名其妙。
"程墨Morgan"的187赞回答给出了数据反差：古法时代一个PR最多一百行，现在AI生成的PR上千行很正常，连PR description都是AI写的，翻好几屏抓不住重点——“不借助AI就没法Review”，必须魔法对轰。 但他强调人必须盯住两个死角：其一，模型训练时只有"代码能不能运行"的反馈信号，压根没有"代码质量高"的loss函数，所以能跑的代码≠高质量代码；其二，很多人的测试也是AI写的，AI既当球员又当裁判，“AI把通过不了的test case给删了，你都不知道，死都不知道怎么死的”。他的比喻很冲：持续往代码库里灌AI泔水，以现在的生成速度，“用不了多久，代码库就会沼气池爆炸”。知乎
1129赞的DBinary则把炮口对准所有方法论布道者：吹SDD/TDD/skills的人，没有几个拿出过自己真实可用的spec和test case，“没看过有人把自己的spec和test case亮出来”。 在DBinary看来，“AI写代码、另一个AI来review"更是"左脚踩右脚原地能上天”。他自己的分工很克制：AI只做查资料、review辅助和写test case，不让AI写大批量代码。理由朴素：工程是"汤里加盐"，局部设计会牵动整体，而他没本事一开始就做完备的约束设计——现实中他也没见过谁能。知乎
第三派不吵读不读，先解释屎山是怎么长出来的。
还是那篇499赞复盘：屎山不是某次生成特别差，也不是模型降智，而是几十个"当时看起来合理"的局部补丁叠出来的。 AI迭代时默认走最省事的路——卡了就加缓存、新场景就加模式、兼容问题就加bridge和一串if，从不愿意回头改上游契约。他举了个具体例子：某模块原本保证输入已去重，新加的一条路径不再保证，最省事的修法是让接收方自己再走一遍TSet去重——单看这段代码甚至显得更安全，但原本已满足保证的路径也要跟着付哈希和拷贝的成本；如果这发生在高频路径上，成本被调用次数放大。类似的事发生多了，“每一层都不再相信上一层”，所谓鲁棒性只是契约已经说不清的体面说法。他还点名了那类宣传"能长时间自主执行"的agent：任务不中断，意味着它可以连续堆更多局部布丁，会不会停下来重画边界，取决于上下文里有没有清楚的架构目标——而大概率没有。知乎
同题问题下另一个高赞（作者"白银冒险家"）给出的样本更扎心：清理过一个AI代码占比80%的项目，“设计模式堆满，抽象层一堆，最后只为了导出个Excel”。他的结论一句话：做框架层的时候一定给它写好规范边界，框架层最怕AI炫技。知乎
分歧的实质：三派对"完成"的定义不一样
把三派放在一起看（这也是AI比单篇帖子多做的事）：真正的冲突不是"读不读代码"，而是你的代码配不配"不读"。验收派的逻辑要成立，有三个前提：目标能被写成可自动验证的信号（测试、构建、对齐spec）；你对架构目标本身说得清；这功能做完大概率没人再动它。三样缺一样，前面省下的时间就会在review、调试和重构里结算——Land1ngW的原话是：之前省下来的时间没有消失，只是被推迟了，还连着巨量的利息。 DBinary给的利息单价更日常：vibe项目到后期，“新增一个需求、修改一个功能和bug，需要一整天去跑”。 所以按你的项目状态对号入座：知乎知乎
预研、演示、一次性脚本：第一派的"机箱背面"逻辑完全成立，别为没人再看代码的模块付费。
寿命半年以上、两三个人共同维护：必须叠加第二派的两个检查——AI有没有删改放不过的测试、有没有在边界模糊处"顺手优化"。这是沼气池爆炸前的两个漏点。
引擎、嵌入式、性能敏感路径：主战场是第三派的"修改局部性"。把AI的每次改动都问一句"它动了哪个契约"，解释不出来的，先别合。
一个值得注意的身份信号：9月13日流传的Claude Code团队三人播客里，他们自述团队70%–80%的工作已经通过agent完成，人的角色从"写函数"变成"给目标"。 造工具的人已经住进这个新世界，但"给目标"怎么给、验收怎么验，他们也没公布标准答案——目前全网所有答案都还是个人经验。微博
社区里已经跑通的最低验收流程
把上面三派的实操拼起来，是一套不需要新买任何东西、今天就能用的流程（每一步都有出典，不是编的方法论）：
开工前：一页纸施工文档 + 框架层规范边界，明确告诉AI哪些层"禁止炫技"。小红书
提交时：让AI输出"本次改动触碰了哪些契约/接口"，人抽最贵的一条核对偏离；
Review：AI自查先行，让AI先找一遍有哪些潜在bug，人只精读三类diff——接口变更、测试删改、高频路径新增的兜底逻辑。知乎
验收：边界测试全过 + 你本人能解释整体架构目标，凑齐这两条，你才有资格"不看一行"——这套测试打法本身就是那位"根本不看一行"答主跑出来的。知乎
另外存四个预警信号，出现任何一个，说明你的项目正在长出屎山的第N层补丁：changelist里出现你陌生的类名；同一种"安全检查"在两层代码里重复出现；某个失败的测试用例悄悄消失；每次修bug都伴随新的bridge或兼容层。
接下来盯什么
南京大学的《生成式软件工程》正在成为这波"AI原生工程师"的公共教材——Land1ngW在机场学的就是它，知乎上"AI时代，还存在软件工程吗？"的回答里，这门课也成了讨论锚点，“如何修改生成式代码"大概率很快会有第一门成体系的中文课，这门课的观点值得跟踪对照。 工具层的风向也在变——从B站虚幻社区最新那期Claude Code接MCP的实操来看，连最积极的拥趸都在强调它是"需要开发者监督和引导的辅助工具”，而不是自动造世界的魔法。知乎哔哩哔哩
判断各派成色的标准其实很简单，也是ZDM一贯的：别听方法论，去看他们自己维护的项目现在还跑不跑得动。AI编程的下半场问题已经换了——上半场问"写能不能交给AI"，下半场问"不读的后果，你的项目付不付得起"。
