用过 AI 写代码的人，大概都经历过这个循环：一句话需求，AI 十几秒给你改完二十个文件，一运行，崩了。你想回退，发现压根没打存档点，只能对着屏幕发呆。
小项目还好，推倒重来成本低。项目一大，问题就变了性质：AI 不是不会写，是写得太快、改得太多、炸了没后路。
这是大项目 AI 开发的第一课。下面这套方法，来自一个数十万行代码级项目的实战整理，拆成四道闸门和一份清单。每一条都能直接抄走用。
AI 改代码的速度远超人眼审查的速度，所以必须给车装刹车。三条规矩：
git status + git diff，确认它改的是你想让它改的地方，再提交。这三条不解决"AI 会不会写错"，解决的是"写错了你回不回得去"。回得去，错误就是成本；回不去，错误就是事故。
项目越做越乱，多半不是能力问题，是规则不统一：这个工具一套规矩，那个工具一套规矩，AI 来回打架。
解法是项目根目录放一份 AGENTS.md，当作全项目唯一的规则源：目录结构、命名规范、提交规范、技术栈约定，全写进去。其他工具各自的规则文件（.cursorrules、GEMINI.md 这类）全部软链到这一份，避免多份规则互相矛盾。
再把关键规则标成 "Always"：写代码前必须先读架构文档，每完成一个里程碑必须更新架构文档。规则一旦是硬性的，AI 就不会"看心情"执行。
人类写代码不用每步记文档，AI 项目必须记——不记，你就不知道它到底干了什么。
让 AI 每做一件事写一份记录：需求背景、做了什么、关键决策、验收结果、后续 TODO。但光有文档不够：文档一多，AI 每次全查一遍，token 直接爆炸。所以要有一个索引文件（agents.md），像字典的目录一样：每份文档在哪儿、干什么用。AI 每次干活前必须先查索引，看有没有干过或者准备干的事。
一句话：文档让 AI 的行为可追溯，索引让追溯不烧钱。缺了索引，这套机制跑不起来。
代码量一大，AI 出幻觉的概率就上来。治幻觉有三样东西：文档+索引（让它知道自己干过什么）、人溜一眼（验收把关）、模块化架构（约束它不乱跑）。其中架构是最治本的那个。
具体做法：模块化设计、单向依赖、高内聚低耦合——像生图工具的负面提示词一样，每次提需求都反复强调。再带上硬约束：禁止兜底、禁止兼容旧逻辑、独立模块只做呈现。
就算做到这一步，高端模型也大概率跑偏。所以架构要当成命根子维护：三分之一到一半的时间花在重构上，是正常状态。好在 AI 把重构成本打下来了，这笔投入值得。
很多 AI 项目第一步就错了——不是选框架，而是没想清楚数据存在哪儿。这一步定反了，框架选得再对也得推倒重来。
判断就两问，顺序不能反：
很多人漏掉第二问："多人共享"和"必须放我这儿"是两件事。十几个同事共用一个库，跟这个库归谁管，完全可以分开。
再记一条原则：能存本地的就别收服务器。数据一旦上了你的服务器，安全、备份、泄露、合规的责任就全归你扛；数据留在用户电脑上，这些责任一样不用背。能不收的数据，就别收。
拿不准的时候，把下面这段话原样发给你的 AI，让它按格式输出结论：
请先读项目里的立项文档和功能清单，然后判断这个软件的数据应该存在用户自己的电脑上还是必须放到我的服务器上。分开告诉我三件事：一、哪些数据只属于用户自己，可以存本地；二、如果要存本地，用 SQLITE 够不够？还是功能清单里已经有需要在用户那边装满 SQL 这类数据库的场景；三、哪些功能必须联网找我（账号、多设备同步、付费校验、调用第三方服务）。每一条都注明你是从文档的哪一处看出来的，先给结论和理由。别写代码，等我确认。
AI 回答后，重点复核它说"必须联网"的那几条——有些 AI 会把用户设置、使用记录这种明明可以存本地的东西划到服务器上。看到就问：这条为什么不能存在用户自己电脑上？
每次发布、合并之前，把这份清单过一遍，全绿才放行：
代码质量
工程秩序
可靠性（人强制落实，AI 不会主动做）
数据
上线
项目进度，用四段式看板管：自动化测试 → 内部演示 → 小范围测试 → 公网生产。每个阶段有明确的验收标准，项目此刻在哪个阶段、下一步做什么、中断后从哪恢复，一眼看清。
最后说一个判断：AI 项目的核心竞争力，最终不是模型接得多快，而是系统管理做得多稳。项目一旦进入中大型区间，项目管理本身就变成了产品能力的一部分。真正重要的不是"再多写一点"，而是让复杂度被看见、让迭代有节奏、让反馈能闭环。
以上四道闸门、一份清单、一个数据判断方法，我们整理成了完整的开源工具包（含 AGENTS.md 模板、数据归属判断指令模板、质量门禁清单、四段式验收看板，可直接复制使用），免费下载：