AI 时代的工程地基：规范，才是项目持久化的解药

2026年08月11日 21:09

　　这不是 AI 的问题，而是我们对"快"的理解出了问题。AI 最擅长往前写，却几乎不回头看全局。它写每个功能时，都只基于当下那一段局部上下文——前面已经有过的两段代码、用过的命名、定下的结构，它一概不记得。

　　于是项目慢慢长成拼凑的样子：A 功能一套命名，B 功能另一套；数据这儿塞一点，那儿挤一下；模块之间没有边界，全靠"好像谁都没错"在硬撑。真正麻烦的是"能跑"带来的假安全感——三分钟跑起来的东西，你误以为是 MVP，其实是技术债的定金。前期越顺利，后期越是雷区。

　　AI 放大的是执行的速度，不是决策的质量。地基恰好属于决策。

　　规范不是一句话，也不是一份文档。它是三层叠起来的地基，每层干每层的活，缺一层楼就歪。

　　最底下是契约层——数据长什么样、接口怎么签名、代码放哪个目录。它规定一切，AI 每写一个功能都该去查它，而不是自由发挥。目录结构就是项目的宪法，定好了，代码才会落在该落的地方。

　　中间是规则层——把工程纪律写进一份机器可读的文件（比如 AGENTS.md），让 AI 每次动手前先读它。改动前先看结构、命名统一、哪些不许碰、拿不准是停下问还是按惯例做。这份文件一旦存在，规范靠的就是必然执行，而不是反复提醒。

　　最上面是流程层——测试、lint、类型检查、构建，全部自动化，让坑在测试里提前爆炸，而不是在生产里伤人。再配一个固定的重构窗口，别只加功能，定期清理。技术债是复利的，不还，它替你利滚利。

　　三层立好，还不等于持久。一套规范活得久，取决于三件事。

　　第一，机器可读。规范不是给人背的，是给 AI 每次都能读到的。它躺在项目里、路径固定，AI 动手前先读它。任何靠人的记忆维系的规范都会失效，因为人会忘，上下文会断。

　　第二，单一来源。规则只写一处，不散落各处。这个项目一份、那个项目复制一份，最后必然漂移成两套。只有一处，改起来才敢改，才对得上。

　　第三，有强制力。光写"要遵守"没用，得让违反的人"报错"——CI 不过就拒绝合并，类型不对就编译失败，测试红了就亮灯。凡是重要的规范，都要变成"不做就报错"，而不是"忘了就提醒"。

　　AI 是很好的施工队，但不是好的包工头。它可以帮你垒砖、砌墙、抹灰，可放线、定承重墙这件事，得你来，至少你来拍板。

　　让 AI 打地基不是不行，但你要当监理。先让它输出架构方案、数据模型，你 review 拍板，再让它顺着这框架持续迭代。地基定稳，后面每一层都又快又齐；地基歪了，盖得越快，塌得越快。

　　我自己的博客就是这么干的：每次重构文章，核对系统时间、更新 lastmod、重建站点，把发布规范写进记忆和规则文件——AI 每次都会自动遵守，而不是我每次重新叮嘱一遍。这股劲儿，就是"把规范固化，而不是靠提醒"。