AI 写代码越写越乱，问题往往不在模型，而在你没给它立死规矩。 今天读到 Lauren 的 tibo dog 工程复盘（@AYi_AInotes 做了拆解）：1 个人、4 天、约 1150 个 PR，搓出一个直接跑在 X 帖子里、包体仅 124KB 的完整游戏。 比起开发速度，我更想抄的是她写进代码仓库里的那套“铁律”。 我的判断是：AI 编程协作的上限，取决于你把多少工程经验转化成了机器能自动执行的硬约束。写在上下文里的口头提醒它会忘，但写进仓库的 Lint 规则它绕不过去。 我把她的核心做法，按“往自己项目里抄的容易程度”重新排了个序： 1️⃣ 把 Bug 变成 Lint 规则 每踩一个坑，不只修当前这一处代码，而是直接让 AI 写一条自定义 Lint 规则把这种写法封死。把单点修复变成全局免疫，同类错误全项目绝不再犯。 2️⃣ 禁用“解释性注释” 用 Lint 拦住所有试图解释代码逻辑的注释。如果一段代码需要注释才能看懂，要么重构换个更自解释的命名，要么补一个单元测试来说明意图。 3️⃣ 用文件后缀隔离高频热路径 高频执行的代码统一用 `.hot.ts` 后缀。针对这类文件配置专属 Lint，严禁在里面出现对象字面量、闭包和 `new` 操作，从源头杜绝内存分配，压住 GC 导致的掉帧。 4️⃣ 核心状态机上形式化验证 直接用 TLA+ 对核心状态机做形式化验证，在代码真正运行前，从数学层面排掉死锁和极端状态冲突。 5️⃣ 全确定性运行（Deterministic） 整个游戏逻辑完全确定性：服务端只需重放玩家的输入流就能做反作弊校验；同时直接跑无头（Headless）Bot 日夜挂机刷关卡，靠测试数据来调优难度曲线。 如果今天就开始在自己的项目里落地，我建议先只抄第 1 条。 实操动作很简单：打开项目的 `CLAUDE.md`（或 `.cursorrules`），加一行硬性指令—— “每次修复 Bug 时，不能只改业务代码，必须同时提交一条能拦住同类写法的 Lint 规则或回归测试。” 先跑一周，看看你的仓库里能沉淀出多少条专属于你业务边界的防呆规则。 提示词只是说明书，Lint 才是护栏。