AI 编程别只图快：一套避免“越写越多 Bug”的实战流程
AI 编程有个很现实的尴尬：
你让它写代码，确实快。
快到什么程度？一个接口、一个页面、一个脚本，几分钟就能甩给你。
问题来了：能跑，不等于能交付。能交付，不等于以后不炸。
有两组数据挺扎心：
- 有机构想做“用 AI 编程”和“不用 AI 编程”的对照实验，结果实验很难推进，因为开发者已经不愿意脱离 AI。
- 企业里有相当一部分 AI token，花在修 AI 自己生成的 Bug 上。
这事听起来像段子，其实很多团队已经在经历了：
AI 帮你写得更快，然后你用 AI 修它写出来的问题，再买更多 AI token 去修更多问题。
这不是生产力飞升，这是技术债开了自动续费。😅
今天不聊玄学，也不吹工具。
咱们聊一套能落地的 AI 编程流程：怎么让 AI 真帮你干活，而不是把你的项目变成 Bug 养殖场。
一、AI 编程最容易踩的坑：把“生成速度”当成“开发效率”
很多人用 AI 写代码，习惯是这样的：
帮我写一个用户登录功能。
AI 很快给你一大坨代码。
看着很完整：
- 有接口
- 有校验
- 有数据库操作
- 有错误处理
- 甚至还有注释
你复制进去，跑一下，能动。
这时候最危险。
因为你会产生一种错觉：活干完了。
可真实项目不是 demo。
真实项目里还有这些东西：
- 现有代码风格
- 权限边界
- 异常分支
- 数据库事务
- 日志规范
- 安全策略
- 测试覆盖
- 后续维护成本
AI 不知道你团队里的那些“潜规则”。
它会用最像答案的方式回答你，而不是用最适合你项目的方式交付你。
所以别问：
AI 能不能帮我写代码？
要问：
我有没有能力验收 AI 写出来的代码？
这才是分水岭。
二、正确姿势：别让 AI 直接开写，先让它做“技术拆解”
很多 Bug 不是代码阶段产生的，而是需求阶段就埋好了。
你给 AI 一个模糊任务，它就会脑补。
你说“做一个登录功能”，它可能默认：
- 用邮箱登录
- 密码明文传入
- JWT 放本地
- 错误提示直接返回
- 没有频率限制
- 没有审计日志
你没说，它就猜。
它猜得越多，你后面修得越痛。
更好的方式是让 AI 先拆任务，不准写代码。
推荐提示词
你是我的资深后端工程师。
现在不要写代码。
请先帮我拆解这个需求：实现用户登录功能。
请输出：
1. 需要确认的问题
2. 可能的技术方案
3. 安全风险点
4. 需要改动的文件范围
5. 需要补充的测试用例
项目背景：
- 技术栈：Node.js + Express + PostgreSQL
- 鉴权方式：JWT
- 已有用户表：users(id, email, password_hash, status, created_at)
- 密码使用 bcrypt 存储
- 登录失败超过 5 次需要限制 10 分钟
注意这里的关键点：
- 明确告诉它“不要写代码”
- 给出技术栈
- 给出已有表结构
- 给出业务规则
- 让它列出测试点
这样做有个好处：你能在 AI 动手前发现问题。
需求没讲清楚时，代码写得越快，返工越快。
三、给 AI 写代码前，先给它一份“项目说明书”
AI 最怕什么？上下文不完整。
你让它改一个函数，它可能顺手改掉整个风格。
你让它修一个 Bug，它可能新造一套工具函数。
你让它补个接口，它可能把鉴权逻辑绕过去。
这不是它叛逆，是它不知道边界。
建议每个项目都准备一个 AI_RULES.md，专门给 AI 看。
示例：AI_RULES.md
# AI 编程规则
## 项目技术栈
- 后端：Node.js + Express
- 数据库：PostgreSQL
- ORM：Prisma
- 测试：Jest
## 代码风格
- 使用 async/await
- 不允许新增全局变量
- 不允许直接拼接 SQL
- 所有数据库操作必须经过 repository 层
- 错误处理统一使用 AppError
## 安全要求
- 不允许返回 password_hash
- 不允许在日志中打印 token
- 登录接口必须有频率限制
- 所有用户输入必须校验
## 修改规则
- 不要大面积重构
- 每次只处理一个明确任务
- 修改前先说明计划
- 修改后列出影响范围
## 测试要求
- 新功能必须补单元测试
- 修 Bug 必须补回归测试
- 测试文件放在 __tests__ 目录
然后你每次让 AI 开工前，加一句：
请先阅读并遵守 AI_RULES.md。
如果你用 Cursor、Claude Code、Copilot Workspace 这类工具，也可以把这类规则放进项目根目录，或者配置到工具的规则文件里。
这一步很土，但很管用。
它相当于给 AI 戴上安全帽。
四、不要让 AI 一次写完整功能，要切成“小刀口”
AI 最擅长什么？
小范围、边界清楚、反馈明确的任务。
AI 最容易翻车什么？
大范围、跨模块、边界模糊的任务。
别这样问：
帮我完成一个电商订单系统。
这句话一出去，你基本是在召唤技术债。
更好的拆法是：
我们要做订单系统，请按下面顺序协助我，每一步完成后等待确认：
步骤 A：设计订单表结构，只输出 SQL 和字段说明。
步骤 B：实现创建订单接口，只处理参数校验和库存检查。
步骤 C：补充订单创建的单元测试。
步骤 D：实现订单支付状态更新。
步骤 E：补充支付状态变更的回归测试。
现在只做步骤 A。
重点是这句：
每一步完成后等待确认。
别让 AI 一路狂飙。
你要像带一个很快但容易冲动的实习生：
- 给它明确任务
- 控制修改范围
- 每一步验收
- 不满意就打回
别不好意思。
AI 没有自尊心，打回成本很低。
五、让 AI 先写测试，再写实现
如果你只让 AI 写功能，它会优先让代码“看起来能跑”。
如果你让它先写测试，它会被迫思考边界。
比如登录接口，别直接说“实现登录”。
换成这样：
请先为登录接口设计测试用例，不要写实现代码。
要求覆盖：
- 邮箱不存在
- 密码错误
- 用户被禁用
- 登录成功
- 连续失败 5 次后锁定
- 锁定期内再次登录
- 返回结果不能包含 password_hash
请用 Jest 输出测试代码。
测试写出来后，你再说：
基于这些测试，实现最小可通过的登录逻辑。
不要修改测试。
不要引入新的依赖。
这招特别适合下面这些场景：
- 登录注册
- 支付回调
- 权限校验
- 数据导入
- 文件上传
- 账单计算
- 定时任务
这些地方一旦炸，通常不是页面难看，而是钱、权限、数据全出事。
别拿生产环境练胆。
六、修 Bug 时，别让 AI “猜着改”
很多人修 Bug 的提示词是灾难现场：
这个报错怎么修？
然后粘一段错误日志。
AI 开始猜。
你试一次，不行。
再问一次，它换个猜法。
再试一次，又不行。
半小时过去了，你得到三个补丁，外加两个新 Bug。
修 Bug 要给 AI 三样东西：
- 复现步骤
- 期望结果
- 实际结果
推荐模板
请帮我定位这个 Bug，先不要修改代码。
复现步骤：
1. 使用 user_a 登录
2. 调用 POST /orders 创建订单
3. 请求参数为：{ "skuId": 1001, "quantity": 2 }
期望结果：
- 库存足够时创建订单成功
- 返回 orderId
实际结果：
- 接口返回 500
- 日志如下：
[粘贴日志]
相关代码：
[粘贴 controller / service / repository 代码]
请输出：
- 最可能的 3 个原因
- 每个原因如何验证
- 你建议先检查哪里
不要直接给修复代码。
为什么不让它直接修？
因为定位和修改是两件事。
先定位，再动手。
你把这两个步骤混在一起，AI 就容易拿“看起来合理”的代码糊你。
七、AI 写完代码后，必须过一遍“人工验收清单”
别迷信 AI 自评。
你让它检查自己写的代码，它很容易说：
代码整体合理，逻辑清晰，具备良好的可维护性。
这类话听着舒服，价值接近空气。
你要让它按清单检查。
代码验收提示词
请严格审查刚才的修改。
按下面清单逐项检查，只输出问题，不要夸奖：
1. 是否有未处理的异常分支？
2. 是否可能出现空指针或 undefined？
3. 是否有权限绕过风险？
4. 是否返回了敏感字段？
5. 是否引入 N+1 查询？
6. 是否破坏现有接口兼容性？
7. 是否缺少测试？
8. 是否有重复代码？
9. 是否修改了任务范围外的文件？
10. 是否存在并发问题？
这里有两个关键表达：
只输出问题，不要夸奖。
AI 很爱当气氛组。
你不拦着，它就给你写一篇表扬信。
八、把 AI 当“副驾”，别让它坐主驾
AI 编程最健康的关系是：你决定方向，它负责加速。
你不能把判断权交出去。
适合交给 AI 的任务：
- 写样板代码
- 生成测试用例
- 解释错误日志
- 梳理旧代码逻辑
- 生成 SQL 草稿
- 补充注释
- 写迁移脚本初版
- 做代码审查清单
不建议完全交给 AI 的任务：
- 架构设计拍板
- 权限模型设计
- 支付逻辑
- 数据删除逻辑
- 安全策略
- 复杂并发控制
- 生产事故修复
- 大规模重构
不是 AI 不能参与。
是这些任务一旦出错，代价太高。
你可以让 AI 给方案，但拍板的人必须是你。
九、一套可直接照抄的 AI 编程工作流
你可以把下面这套流程贴到团队文档里。
1. 开工前：定义边界
请先分析需求，不要写代码。
输出需要确认的问题、影响范围、风险点和测试计划。
2. 动手前：制定计划
请给出最小修改方案。
要求：
- 不做任务外重构
- 不新增不必要依赖
- 列出将修改的文件
- 每个文件说明修改原因
3. 编码中：小步提交
现在只修改 [文件名]，完成 [具体目标]。
不要修改其他文件。
4. 写完后：补测试
请为这次修改补充测试。
必须覆盖正常路径、异常路径和边界条件。
5. 合并前：做审查
请按安全、性能、兼容性、可维护性四个维度审查这次改动。
只列问题和建议，不要写总结性夸奖。
6. 出问题：先定位再修复
请根据复现步骤和日志定位问题。
先列可能原因和验证方法，不要直接修改代码。
这套流程看起来慢。
实际会让你少掉很多“半夜回滚”的机会。
写代码快不稀奇，少返工才值钱。
十、避坑清单：这些用法很容易把项目带沟里
下面这些情况，建议你看到就停一下。
❌ 1. 一句话让 AI 做完整功能
帮我做一个会员系统。
太大了。
拆小。
❌ 2. 不给项目背景
帮我优化这段代码。
优化什么？性能？可读性？安全？内存？
AI 不知道，就会自由发挥。
❌ 3. 复制代码不看直接提交
这和把陌生人写的代码直接合进主分支没区别。
甚至更危险，因为它看起来很像那么回事。
❌ 4. 修 Bug 不写复现步骤
没有复现步骤，AI 大概率在猜谜。
你要的是修 Bug，不是抽塔罗牌。
❌ 5. 让 AI 大范围重构
大范围重构最容易出现：
- 旧逻辑丢失
- 边界条件消失
- 测试全绿但业务炸了
- Git diff 大到没人想看
重构可以做，但要小步、可回滚、测试先行。
十一、推荐你固定使用的 5 个提示词模板
模板 A：需求澄清
先不要写代码。
请帮我澄清这个需求，列出你需要我确认的问题。
同时指出潜在风险和边界条件。
模板 B：最小实现
请用最小改动实现这个需求。
不要重构无关代码。
不要新增依赖。
修改后列出文件清单和原因。
模板 C：测试生成
请为这个功能生成测试用例。
覆盖正常流程、异常流程、边界条件和安全风险。
先输出测试点，再输出测试代码。
模板 D：代码审查
请审查下面这段代码。
只指出问题，不要夸奖。
重点看：安全、异常处理、并发、性能、可维护性。
模板 E：Bug 定位
请根据复现步骤、日志和相关代码定位问题。
先列可能原因和验证方法。
在我确认前，不要给修复代码。
结语：AI 编程真正的能力，是“可控地变快”
AI 编程不是不能用。
恰恰相反，它已经变成很多开发者离不开的工具。
问题是，别把它当自动驾驶。
更像是副驾：查资料快、写草稿快、补测试快、解释旧代码也快。
方向盘还得在你手里。
记住一句话：
AI 生成代码的速度，不等于团队交付软件的速度。
真正靠谱的 AI 编程，不是让它疯狂输出。
是让它在明确边界里输出，在测试和审查里收敛，在你的判断下合并。
这样用，AI 是帮手。
乱用，它就是 Bug 批发商。
