很多人说AI不是在“写代码”而是在“写片段”。你给它一个明确的小任务比如“写一个冒泡排序”它完成得很好你把一个大型项目拆成几十个模块让它逐个实现一开始一切顺利两周后项目就变得面目全非——函数命名前后不一致、接口悄悄变了、旧功能被新功能无意破坏AI浑然不觉。这不是AI变笨了而是你用错了协作方式。我自己在过去一段时间里用AI辅助完成了不少中型项目也眼睁睁看过项目从“进展神速”滑向“改一行崩三处”。后来我意识到问题从来不是“AI能不能写大型项目”而是“大型项目到底意味着什么”。如果只是把任务切成碎片丢给AI等于让一个记忆力有限的人同时管一百个线头他每个线头都拿得住连在一起就全乱了。这篇文章想聊的不是某个提示词魔法也不是某种“调教AI”的玄学。我想拆解的是为什么AI推进大型项目会失控以及如何通过脚手架、文档约束和流程设计让AI在长周期、多模块、多轮迭代的任务里保持稳定。如果你正在用AI做完整工具、做网站、做数据系统这篇文章大概率能帮你避免几个通宵。1. 先搞清楚真正的问题AI不是写不完而是“接不住”很多人第一次尝试用AI做大型项目通常会经历三个阶段。第一阶段是兴奋。你发现AI能生成完整的模块代码接口、注释、异常处理都给得挺全。你觉得自己找到了生产力突破口。第二阶段是困惑。项目做了一半你让AI修改某个功能它改完之后另一个毫不相关的地方开始报错。第三阶段是崩溃。你尝试让AI自己看日志、找问题、修复结果它不断赔礼道歉然后继续修出新的问题。这不是AI能力不够而是上下文被切碎了。这里要引入一个计算机系统里的经典概念状态。大型项目之所以复杂不是因为代码量大而是因为模块之间的状态相互依赖。你改了用户模块的数据结构订单模块就会受影响你调整了某个工具函数的返回值所有调用它的地方都要跟着变。人类程序员靠什么应对这种复杂度靠记忆、靠文档、靠规范、靠测试。我们记不清每一行代码但我们知道“项目里有个模块负责用户信息”知道“订单模块依赖用户模块的字段”。AI不一样。它每次接收的上下文是有限的一旦超出窗口它就只能看到你贴给它的那几百行代码。它不知道项目里还有一个订单模块更不知道用户模块改了字段会影响订单模块。所以真正的问题不是“AI写不出大项目”而是“AI接不住已经发生过的修改”。1.1 “公地悲剧”为什么每个模块都很完美整体却崩了我用AI辅助开发时最常犯的错误是“分头喂料”——给AI看某个模块的需求文档让它实现再看另一个模块的需求让它实现。每个模块单独看都很漂亮但拼合的时候两个模块对同一个数据的理解不一样。比如A模块把一个时间字段处理成字符串B模块需要的是时间对象。分开看两个都没错合起来运行时报错。这很像“公地悲剧”每个模块都在自己的局部范围内做最优决策没有人对全局一致性负责。人类程序员在团队里靠架构师、靠代码评审、靠规范文档来避免这种悲剧。但当你一个人加一个AI时这些机制全部消失了。AI不会主动去看其他模块的代码你不给它它就想不起来。我后来总结了一句话AI是极其优秀的执行者但它是极差的全局记忆者。它记得住你给它的一切记不住你没给它的一切。1.2 你以为在“指挥”其实是在“靠运气”很多人用AI推进项目的方式是不断下达新指令“把登录功能加上”“给列表页加个筛选”“把这个接口改成POST”。AI每次都听话地执行你每次都以为它在稳步推进项目。但实际上你不一定在“指挥”你是在“撞运气”。因为你没有建立一个机制来确保AI每次修改都基于全部上下文所以每一次修改是否安全取决于这次任务是否碰巧没有踩到旧逻辑。运气好的时候AI只改了你让它改的那一段运气差的时候它在某个底层函数里悄悄改了返回类型所有调用方全部遭殃。它不是坏它是不知道这会殃及其他模块。它的大脑里没有“全局影响图”这个概念。所以与其问“怎么让AI写更大的项目”不如先问“怎么让AI每次动手前都能看到项目全貌”。这才是稳定推进的起点。2. 让AI“接得住”项目的核心方法内外双层护栏为了不让项目失控我后来摸索出了一套方法。它不复杂但需要你转变一个心态别把AI当“写代码的工具”把它当“加入你项目的短期协作者”。协作的前提是信息同步。这里面最关键的是两个双层护栏外部文档护栏和内部代码护栏。2.1 外部护栏给AI建一份“项目全局手册”什么是外部护栏就是在项目目录里专门放一个文档把项目的整体情况写清楚。每次让AI动手改代码之前先把这份文档喂给它或者至少让它知道这份文档的存在。我自己常用的文档结构大概是这样的project/ ├── docs/ │ ├── architecture.md # 架构总览模块划分、数据流 │ ├──>