摘要：AI 写代码很快，写错也很快。真正好用的 AI 编程，不是把判断交给模型，而是先讲清问题、管住边界、审好结构、测过以后再留下。
这两年，用 AI 写代码的人越来越多。
一开始，大家都会觉得它很神奇：一句话生成页面，一句话改接口，一句话写脚本。以前需要半天搭起来的小工具，现在十几分钟就能跑。尤其是做 Demo、写内部工具、改小功能，AI 的确能省下不少时间。
但用久了，另一面也会越来越明显。
AI 写代码很快，写错也很快。它经常给你一段看起来很完整、命名合理、注释也像样的代码。简单场景能跑，一进复杂业务就出问题。更麻烦的是，很多问题不是立刻暴露，而是过几天再改需求时才发现：结构乱了，依赖重了，数据模型不对，权限校验漏了，测试也没有。
所以，用 AI 写代码不能只靠感觉。它可以帮你提速，但前提是你知道怎么管住它。
我自己总结了十条规矩。
第一条：先把问题讲清楚，再让 AI 写
很多人一上来就说：“帮我做一个后台系统”“帮我写一个知识库”“帮我开发一个审批流”。
这种提示太宽了。
AI 会马上动手，而且通常会写得很积极。但它写出来的东西，很可能只是一个“看上去像那么回事”的版本。因为它不知道你的业务规则，不知道哪些数据重要，不知道哪些地方不能随便改，也不知道这个系统以后会怎么扩展。
所以，在让 AI 写代码之前，先把问题拆开。
这个功能解决什么问题？谁来用？输入是什么？输出是什么？哪些情况必须处理？哪些情况不能发生？哪些规则不能被破坏？
比如做库存系统，不能只说“增删改查库存”。要先讲清楚库存代表什么：账面数量、可用数量、锁定数量，还是在途数量？一次出库失败后要不要回滚？多个人同时操作怎么处理？是否需要保留流水？
这些问题没说清楚，AI 写得越快，返工越多。
第二条：不要只给目标，还要给限制
AI 很擅长自由发挥，这既是优点，也是麻烦。
你让它做一个登录功能，它可能顺手加上注册、找回密码、Token、邮箱验证、角色管理。看起来很丰富，但也可能完全不符合你的项目。
所以，提示里不能只有“做什么”，还要说明“不能做什么”。
用什么技术栈？能不能加新依赖？只能改哪些文件？接口格式要不要和旧系统一致？错误信息怎么返回？日志里能不能出现用户数据？权限在哪一层判断？
这些限制越清楚，AI 写出来的东西越接近可用。很多时候，提示不是写得越长越好，而是边界说得越准越好。
第三条：先看数据结构，再看页面效果
AI 做页面很快，做 CRUD 也很快。但项目后面好不好改，很多时候取决于一开始的数据结构。
页面错了可以调，按钮丑了可以改，接口名字不顺也可以改。数据模型错了，后面会很痛苦。
比如任务管理系统，任务、项目、成员、角色、状态、审批、附件、日志之间到底是什么关系？任务状态是一个字段，还是一组事件？删除任务是真删，还是归档？负责人变化要不要留记录？
这些问题如果一开始不想清楚，AI 可能会给你一个能跑的表结构，但后面一加需求就开始崩。
所以，让 AI 写功能前，先让它把数据对象、字段含义、状态流转写出来。你先审这个，再让它写代码。
功能是表面，数据结构才是骨架。
第四条：AI 写出来的代码，先当草稿看
AI 写的代码不能直接当成成品。
它可能语法没错，但逻辑有问题；可能简单样例能跑，边界条件不行；可能功能实现了，权限没管住；可能本地没问题，线上遇到并发就出错。
这不是说 AI 不行，而是写代码本来就需要验证。
人写的代码要审，AI 写的更要审。因为 AI 写错的时候，经常错得很像对。变量名、注释、结构都挺正常，但里面藏着一个关键漏洞。
所以，看到 AI 生成的代码，第一反应不要是“完成了”，而应该是“草稿出来了”。
接下来要检查：能不能跑？异常输入怎么办？空值怎么办？重复提交怎么办？权限有没有校验？错误能不能定位？未来改起来会不会麻烦？
能跑只是第一步。能解释、能测试、能改，才算真正进入项目。
第五条：让 AI 自己反过来挑毛病
AI 写完代码以后，不要只问：“这段代码有没有问题？”
这个问法太温和，AI 很容易给你一些无关痛痒的建议。
更好的问法是：
- 假设这段代码有三个严重问题，分别可能在哪里？
- 如果有人恶意调用这个接口，怎么绕过限制？
- 如果数据量扩大一百倍，哪里会最先出问题？
- 如果明天要加一个新角色，哪部分最难改？
- 如果线上报错，日志够不够排查？
这种问法更有效。它会迫使 AI 换一个角度看自己刚才写的东西。
也可以让 AI 分角色检查：测试工程师看边界，安全工程师看权限，架构师看结构，运维人员看日志和部署，业务人员看流程有没有漏。
写代码是一轮，挑毛病还要再来一轮。
第六条：测试要跟功能一起写
很多人用 AI 写代码时，只让它写功能，不让它写测试。
这是一个坏习惯。
AI 最容易生成“看起来能用”的代码，而测试就是把“看起来”变成“确实通过”的过程。
所以，写提示的时候，最好同时要求 AI 给出验收标准和测试用例。
例如，不要只说“写一个登录接口”，而要说清楚：用户不存在怎么办？密码错误怎么办？账号被禁用怎么办？Token 过期怎么办？连续输错要不要限制？返回字段里不能有什么？哪些情况要写日志？
先列测试场景，再写实现代码。写完以后，再让 AI 补单元测试、接口测试、异常测试。
没有测试的 AI 编程，前面很快，后面一定慢。因为每改一次都不知道会不会把别的地方弄坏。
第七条：一次只让 AI 改一小块
AI 能一次生成很多代码，但不代表你应该让它一次改很多东西。
任务越大，上下文越乱，AI 越容易忘记前面的约束。它可能重复造轮子，可能改错文件，可能为了修一个小问题重构半个项目。
比较稳的做法是小步修改。
一次只改一个功能。一次只处理一个模块。一次只解决一个明确问题。改完就运行，运行完就测试，测试过了再提交。
不要让 AI 一口气做完一个大系统。这样看起来快，实际风险很高。
AI 编程最舒服的节奏，是每一步都看得懂、测得过、回得去。
第八条：关键代码必须有人读懂
有些代码可以放心让 AI 多写一点，比如脚本、页面样式、普通工具函数、数据转换。
但有些代码不能糊弄。
账号、权限、支付、企业数据、任务调度、设备控制、模型调用、生产流程，这些地方必须有人认真读。
如果一段关键代码没人能解释清楚，就不要放进核心系统。
至少要搞明白：为什么这样设计？权限在哪里判断？失败了怎么处理？数据写到哪里？异常怎么记录？用户输入有没有校验？哪些调用可能超时？出问题怎么回滚？
AI 可以写关键代码，但不能让关键代码没人负责。
第九条：Demo 和生产系统要分开看
AI 特别适合做 Demo。
你有一个想法，让它快速搭个页面；你想验证一个流程，让它写个小工具；你要给客户看效果，让它先做一个可交互原型。这些都很合适。
但 Demo 能跑，不代表产品能用。
从 Demo 到生产，中间还有很多工作：权限、异常、日志、测试、部署、备份、监控、安全、文档、回滚。
很多项目的问题，不是 AI 没把 Demo 写出来，而是把 Demo 直接当产品用了。
Demo 的目标是验证想法。产品的目标是长期可用。这两个标准不能混在一起。
第十条：人定方向，AI 提速度
用 AI 写代码，最重要的不是学会某个神奇提示词，而是重新分工。
AI 适合做实现、补代码、写样例、生成测试、查错误、改重复劳动。
人要负责方向、规则、取舍、审查和责任。
你不能把判断交给 AI。它可以告诉你几种方案，但你要决定选哪种；它可以写一段实现，但你要决定能不能合入；它可以修一个 Bug，但你要确认有没有引入新问题。
它可以提高速度，但质量线还得人来守。
代码越来越容易生成以后，真正拉开差距的，不是谁打字快，而是谁问题拆得清楚，边界定得准，审查做得细，系统管得住。
这就是我理解的 AI 编程。
它不是神秘方法，也不是偷懒工具。它更像多了一个很快、很勤奋、但需要你管住的开发助手。
你越清楚，它越好用。你越含糊，它越容易乱写。你越会检查，它越能帮你省时间。你越不检查，它越可能把坑埋得很深。
最后，把这十条规矩压成一句话：
先想清楚，再让模型动手；先验证过，再把代码留下。