从玩具 Demo 到稳定交付：个人开发者的 3 条 AI 编程工程铁律
大家好，我是不会喷火的小火龙。
最近半年，我的私信和评论区被同一类问题淹没了：
"小火龙，我用 Cursor 10 分钟做了个 App，本地跑着没问题，一部署就各种报错，改了一下午越改越烂……"
"AI 帮我写了个后台管理系统的 Demo，看着挺好的，我加了两个需求之后整个项目就崩了，连回退都回退不动。"
这些问题指向同一个根源。今天我把这件事说透。
一、喝着咖啡看 AI 刷屏很爽，直到我第一次尝试把它部署上线
下面这张图基本就是大部分人的真实状态。
Vibe Coding 这个词是 Andrej Karpathy 在 2025 年 2 月造的。他当时在推特上说：
"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
翻译一下：给 AI 一句话描述你要什么，然后 Accept All，不读代码、不看 diff、不关心底层实现。跑不通就把报错贴回去，通常它就自己修好了。
但 Karpathy 自己紧跟着补了一句，很多人选择性忽略了：
"It's not too bad for throwaway weekend projects, but still quite amusing."
注意 throwaway weekend projects 这几个词。用完即弃的周末玩票项目。
你拿着这套方法，想做一个要长期维护、要部署上线、要给真实用户用的产品，那就好比拿一次性筷子去炒铁锅大灶，不折才怪。
我自己也经历过一模一样的过程。去年用 Claude Code 做一个数据看板工具，前 40 分钟觉得"AI 时代来了，编程已死"。然后我加了一个用户权限模块，AI 在写权限的同时悄悄改了数据库的字段命名规则，所有查询接口全挂了。我花了整晚把项目恢复到能跑的状态。
后来我发现，几乎所有用纯 Vibe Coding 做"正经事"的人，都在经历同一个循环：
10 分钟出 Demo → 觉得自己是天才 → 加需求 → AI 连环翻车 → 越修越烂 → 推倒重来。
二、为什么 Vibe Coding 一碰复杂工程就必成屎山？
很多人把翻车归结于"AI 还不够聪明"。不对，问题出在 Vibe Coding 这套工作方式本身。
沉默假设：AI 替你做了一百个决定，但没问过你一次
当你给 AI 一句"帮我加个用户登录功能"，它需要自行决定至少十几个技术问题：用 session 还是 JWT？密码存 bcrypt 还是 argon2？数据库加哪些字段？路由怎么组织？错误码怎么定义？
AI 不会说"我不确定，先问问你"。它悄悄选一个最常见的方案直接写下去。这些沉默假设累积起来，你的项目被塞了大量你不知道的技术决策。下次你再加需求，新代码和旧的隐式决策冲突，系统就崩了。
改一个点，炸三个面
大模型按 token 序列预测下一个字符，注意力集中在"当前这段对话要解决什么"。它没有一个独立运行的"架构守护进程"来检查跨模块的依赖。
所以你说"把这个按钮改成蓝色"，它可能在改 CSS 的同时顺手"优化"了组件的 props 接口。你其他三个页面引用了这个组件，全挂了。
这不是 AI 犯蠢，是工作模式使然。如图 2 所示，纯聊天模式和有规范约束的模式，在复杂度增长后走向完全不同：
左边是个发散循环，复杂度指数膨胀直到崩盘。右边通过先收敛方案、再局部执行、最后测试验证，把失控风险限制在每次迭代的小范围内。
你省掉的那些"无聊步骤"，恰恰是软件工程的地基
Simon Willison（sqlite-utils、datasette 的作者）在谈用 LLM 写代码时说过一条规矩：
"My golden rule for production-quality AI-assisted programming is that I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else."
大白话就是：如果你没法给别人讲清楚这段代码在干嘛，就不该把它合进项目里。
Vibe Coding 恰恰跳过了这一步。你 Accept All 的时候不知道 AI 改了什么，也没跑测试验证它改得对不对。你在没有安全网的钢丝上裸奔，功能稍微复杂一点，摔下来就是必然的。
三、治好 AI 乱写屎山的 3 条防翻车铁律
我在过去半年的项目里总结出 3 条规则，配合 Cursor、Claude Code、Windsurf、Copilot 都能用。遵守这 3 条不会让 AI 编程变慢，反而会省掉返工的时间。
铁律 1：范围与权限隔离
每次只准 AI 动你指定的文件，不准它自作主张碰别的地方。
这条最容易执行，效果也最直接。AI 乱改代码的根本原因是你给了它全库漫游的权限。你说"帮我修个 Bug"，它可能把整个项目的目录结构重新组织了一遍。
具体做法：
- 在 prompt 里明确列出允许修改的文件路径。比如"只修改
src/components/LoginForm.tsx和src/api/auth.ts，不要碰其他文件"。 - 严禁 AI 擅自新建文件和引入新依赖。需要新文件或新库，要求它先说明理由，你确认后再建。
- 单次任务只解决一个问题。不要一句 prompt 里塞三个需求。
GitHub 上最近有个项目叫 ponytail，它的 README 写了一句话我觉得总结得到位：
"Makes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote."
让你的 AI 像团队里最懒的高级工程师一样思考。最好的代码是你根本不用写的代码。
铁律 2：规格与意图前置
让 AI 先说清楚它打算怎么改，你同意了它再动手。
在 AI 动手写代码之前，要求它先输出一份简短的变更方案（Spec），包含：
- 准备修改哪些文件
- 每个文件改动的具体逻辑
- 涉及哪些接口或数据结构变更
- 有没有潜在的副作用
你审核这份方案，觉得没问题，再让它写。
这一步可能就 30 秒，但能省掉后面 30 分钟的连环修 Bug。绝大多数翻车，都是 AI 在方案阶段就跑偏了，你在这一步拦住它，后面的代码天然不会乱。
具体的 prompt 模板：
▼text复制代码在写代码之前，先用中文给我一个简短的变更方案，包含： 1. 需要修改的文件列表 2. 每个文件的修改逻辑（2-3 句话） 3. 涉及的接口/数据结构变更 4. 潜在的副作用或风险 等我确认后再开始编写代码。
这段话可以直接写进项目的 Rules 文件里，AI 每次开始工作都会先过这个流程。
铁律 3：自动化验证闭环
AI 写完代码必须自己跑通测试，跑不通就继续改，不要让你当人肉审阅器。
很多人的做法是 AI 写完了，自己肉眼看一遍 diff，感觉差不多就合并了。这样做等于把质量保障全压在你的肉眼上，而你的肉眼不可能看出所有边界条件和隐式依赖。
在项目规则里要求 AI 每次修改后自行运行测试命令。跑不通就继续修，直到测试全绿。你要做的是验收，不是 Debug。
在 Rules 里加上这样一段：
▼text复制代码完成代码修改后，必须运行以下验证命令并确认全部通过： - `npm run typecheck`（或对应的类型检查命令） - `npm run test`（或对应的单元测试命令） - `npm run build`（确认构建不报错） 如果任何一项未通过，自行修复后重新运行，直到全部通过再提交。
如图 4 所示，三条铁律组合起来，形成一个防翻车的工程闭环：
▼mermaid复制代码flowchart TD A["你提出需求/意图"] --> B["AI 输出变更方案 Spec"] B --> C{"你审核方案"} C -- 不通过 --> B C -- 通过 --> D["AI 在限定范围内写代码"] D --> E["AI 自行运行测试"] E --> F{"测试全通过?"} F -- 否 --> D F -- 是 --> G["你验收最终结果"] G --> H["合并到主分支"]
人机分工很清楚：你负责定方向、审方案、验收结果，AI 负责出方案、写代码、跑测试。
四、直接抄作业的 Rules 模板
下面这份 Rules 模板是我自己在多个项目里打磨后的版本，可以直接复制到项目根目录的 .cursorrules、CLAUDE.md 或 RULES.md 文件里。
▼markdown复制代码# 项目 AI 编程规范 ## 核心原则 - 每次修改前先输出中文变更方案（Spec），包含：修改文件列表、逻辑说明、接口变更、潜在风险。等待确认后再写代码。 - 只修改明确指定的文件，不擅自新建文件、不引入新依赖、不重构未被提及的模块。 - 如需新增文件或依赖，先说明理由并等待批准。 ## 代码风格 - 遵循项目已有的命名规范和目录结构，不擅自变更。 - 中文注释，简洁明了，不写废话注释（如 // 获取用户列表 → getUserList()）。 - 不做过度抽象，不为"可能的未来需求"提前设计。 ## 验证要求 - 完成修改后必须运行以下命令，全部通过后再提交： - 类型检查（如 tsc --noEmit / mypy） - 单元测试（如 npm test / pytest） - 构建验证（如 npm run build / go build） - 任何一项未通过，自行修复后重新运行。 ## 禁止事项 - 禁止 Accept All，每次修改必须可解释。 - 禁止在未经确认的前提下修改数据库 schema、API 接口签名或核心配置文件。 - 禁止删除或注释掉已有的测试用例。
简单解读几条：
"等待确认后再写代码"：对应铁律 2，防止 AI 一上来就闷头写，方向错了全白费。
"不做过度抽象"：AI 特别喜欢搞 Factory Pattern、Strategy Pattern 这类设计模式，你只是做个简单功能，它能给你造出五层抽象。这条直接掐住。
"禁止删除已有的测试用例"：血泪教训。AI 在修 Bug 时发现测试不通过，它的解法有时候不是修代码，而是把测试删了。你不写这条规则，迟早遇上。
五、AI 时代的真功夫
回到开头的问题。Vibe Coding 到底有没有用？
有用。验证想法、做原型、探索可行性，它依然是最快的方式。一个周末用 AI 搓出一个能跑的 Demo，看看这个想法值不值得认真做，完全没问题。
但当你决定"这个东西要认真做"的时候，你得换一套工作方式，从无约束的 Vibe Coding 切换到有规范的 Spec-driven 模式。
你去看那些真正能独立做出产品、持续交付、靠此盈利的开发者，他们用 AI 的时间可能比你还多，区别在于他们知道什么时候该让 AI 飞，什么时候该把缰绳拉回来。
享受 Vibe Coding 带来的灵感和速度。但当你要交付产品的时候，带上那 3 条铁律。它们不会让你变慢，但能让你不翻车。
我是不会喷火的小火龙。在这里，我不聊虚头巴脑的 AI 概念，只记录一个真实开发者用 AI 搓工具、做产品、踩坑填坑的全过程。如果你也想用 AI 做出真正能稳定上线的小产品，欢迎关注我的公众号「小火龙AI 手记」。少走一点弯路，我们一起把 AI 驯化成趁手的生产力工具。
