前阵子还在讨论"AI能不能写代码"，现在问题已经完全变了。上海一个13岁的初二女孩，几乎不写代码，靠大模型在杭州一场黑客松里做出一个虚拟陪读工具，3天就赚了1.8万。每日经济新闻当"不会写代码的人也能造出能卖的软件"变成新闻日常，AI编程的门槛其实已经踏平了。
但门槛踏平的另一面，是另一批人开始集体头疼：那些靠AI写代码写了几周、几个月，做出过真东西的人，正陆续撞上同一堵墙——代码能跑，却没人能维护，包括自己。这个星期，知乎上"AI写的代码会不会变成屎山"的几个老问题又被顶上热榜，百万级阅读，正反方吵得很凶。
如果你也是"一句话生成一个App"爽过、现在却越改越心虚的那批人，这篇文章替你把这个事掰开：你的项目到底有没有在变屎山，现在补救来不来得及。
"能跑"和"能维护"之间，隔着一个还债期
先说清楚"屎山"在这个语境里指什么：不是代码写得丑，而是补丁摞补丁、没人说得清整体结构、后人（包括三个月后的你）不敢动也动不了的状态。
过去屎山是好几年慢慢堆出来的。AI把这个过程压缩到了几周。原因不是AI"笨"，恰恰是它太能写、太快、太不在乎。下面这三个模式，是社区讨论里反复出现、也最容易在你项目里复现的。
模式一：AI的第一要务是"糊上去"，不是重构
一个被顶到1100多赞的知乎回答说得特别狠：人类编程的核心守则是"偷懒"，能改改继续跑就绝不重写；但AI编程的第一要务是"糊屎"，硬糊糊不动，就干脆拉一坨新的。知乎这不是段子。AI没有"复用代码"的动力，因为对它来说，改一个地方要同时改二十处，和只改一处，成本是一样的，它自动搜索全部改掉就行。于是它遇到冲突的默认动作，是新增而不是收敛。功能越加，重复的实现越多，同一个逻辑散落在好几个文件里，谁也不敢删。
模式二：工作区在膨胀，而且比代码膨胀得更快
一个本周刚发的回答把这个现象概括得很准：AI写代码像喷泉，但你的工作区没有排水系统。知乎每跑一轮，AI都会留下一堆"中间产物"——废弃的实现方案、临时补丁、重复的依赖锁文件、测试桩、半途而废的重构。代码在增长，但工作区膨胀得更快。
这些东西单个看都无害，堆久了就是地雷：你不知道哪个文件是当前在用的，哪个是AI试错留下的尸体，删了怕崩，留着碍眼。
模式三：生成速度碾压审查速度，这是结构性的
这一条是最根本的。一个1000多赞的回答讲了个很真实的场景：主力开发头几天还尝试逐行审阅AI代码，很快就放弃了——几个分支同时拉起来vibe，半小时生成上万行，你就是不下班、一天24小时盯着看，也看不完。知乎AI写代码的速度，远大于你看代码的速度。
这不是你懒，是工具特性。当"产出"和"理解"的速度差出一个数量级，审查就注定追不上，缺口只会越拉越大。连以"敢用AI"出名的黑客Geohot——破解过iPhone和PS3、做过comma.ai那位——深度用了六个月后都感叹，AI Agent正在制造软件史上最大的屎山。知乎专栏开源社区也撑不住了：机器之心8月初报道，Rust项目被AI生成的PR洪水淹了，过去"提一个PR意味着背后有人认真读过代码"的判断标准，开始失效。机器之心
但也有人说：AI代码反而不容易成屎山
公平起见，得把反方观点摆上来。有知乎用户提出一个有意思的论点：正因为AI没有复用动力、到处复制粘贴，它的代码反而是"天生低耦合"的——改一处只影响一处，不像人写的祖传代码那样牵一发动全身，所以其实更不容易塌。知乎这话有一定道理，但只看到了局部。低耦合确实让"单点修改"变安全，可它解决不了两个更要命的问题：一是没人能在脑子里建立这个项目的整体地图，数据和依赖怎么流的、哪些是死代码，全是黑箱；二是"改一处只影响一处"的前提是你得先找到该改哪一处，而在一堆重复实现里定位，本身就是屎山的一种形态。低耦合是战术上的安全，战略上照样失控。
自查：你的项目到哪一步了
对号入座，三类信号，从轻到重：
信号一（轻度）：你开始"绕着走"。 遇到要改的地方，你下意识让AI"再写一个"，而不是去改原来那个；或者你改之前会莫名紧张，怕碰崩别的。
信号二（中度）：你说不清家底。 随便指一个文件或函数，你讲不清它是不是还在用、谁创建的、为什么存在。项目里明显有一批"看起来像废弃但没人敢删"的东西。
信号三（重度）：AI自己也找不着北了。 你加一个新功能，AI每次给的方案都不一样，没有稳定套路，甚至开始改错地方、重复引入已有的依赖。这说明连它都读不懂这个仓库了。
只有信号一，还来得及立规矩；到了二，得专门花时间清一次；到三，通常认真评估一下"推倒重来"反而更划算——注意，重来也要带着架构和规矩重来，不然只是再糊一座新的山。
防屎山工作流：不靠逐行读，也能兜住底
既然逐行审查注定追不上，就得换护栏。社区里被验证有效的做法，基本是这四条：
第一，把角色换过来：人定架构，AI填实现。 一个被反复引用的说法是，可持续的AI编程是"人是规划者、AI是执行者"——你先和AI讨论清需求、总体设计、用哪些现成库，再让它动手。知乎先花十分钟定结构，能省后面十小时擦屁股。
第二，给AI立规矩。 用规则文件（Claude Code的CLAUDE.md、Codex/其他工具的AGENTS.md之类）把底线写死：不要重复造已有的轮子、不要随手新增依赖、改动优先复用现有函数。规矩写在文件里，比每次口头叮嘱靠谱得多。
第三，定期清工作区。 每隔一段，专门让AI做一轮"清道夫"：找出废弃文件、合并重复实现、锁定依赖版本、删掉试错残留。把"还债"变成一个定期的、小剂量的动作，而不是等它堆成山。
第四，用测试和小步提交当护栏。 别指望用眼睛读出来对不对，让测试替你读。关键路径补上测试，提交拆小、写清信息，这样出了问题能秒级定位是哪一步引入的。审查方式从"逐行看懂"换成"测试+契约兜底"，才追得上生成速度。
给三类人的判断
一次性脚本、玩具、用完就扔的：根本不用管屎山，爽完就删，别给自己加戏。
要长期维护的个人工具、副业项目：现在还债成本最低。趁项目还小，把上面四条规矩立起来，边际成本几乎为零，越晚越贵。
已经堆到重度屎山的：先别急着"让AI重构"，它大概率会在旧山上再糊一层。正确动作是先让AI帮你把现状梳理成一份结构说明，评估清楚哪些能救、哪些该扔，再决定是局部清创还是带架构推倒重来。
AI编程的下半场，比的不是谁生成得快，而是谁的东西三个月后还改得动。至于"AI自己写代码、自己审代码"什么时候能真正成熟、把这个缺口补上，那是下一个值得盯的信号——在那之前，护栏得你自己搭。
