刚开始用 AI 编程时，我经常直接输入：
帮我写一个完整的后台管理系统，要有登录、权限控制、用户管理和数据统计。
AI 几秒钟就能生成一套看似完整的代码：目录清晰、注释齐全，甚至连页面样式都写好了。
但真正运行时，问题很快就出现了：依赖版本对不上、接口字段不一致、登录状态无法保存，修完一个报错又冒出新的报错。
后来我才明白，AI 不是不会写代码，而是我一次交给它的任务太大了。
复杂功能很难靠一条提示词直接完成。把需求拆成几个可以单独检查的小任务，生成结果反而更可靠。
一、需求写得很长，不代表写得清楚
很多人认为，提示词越详细，AI 生成的代码就越准确。
例如：
使用 Vue 3 开发一个后台管理系统，
包含登录、权限控制、用户管理和数据统计，
页面简洁，代码完整，可以直接运行。
这段话看起来已经很具体，但仍有不少关键信息没有确定：
- 使用 JavaScript 还是 TypeScript？
- 状态管理是否采用 Pinia？
- 登录信息保存在 Cookie 还是 localStorage？
- 权限控制到页面级还是按钮级？
- 接口已经存在，还是需要 Mock 数据？
- 使用哪一个 UI 组件库？
- 项目的 Node.js 和依赖版本是什么？
这些条件没有说明，AI 就会按照常见方案自行补全。生成的代码可能没有明显语法错误，却未必适合当前项目。
所以，写提示词的重点不是堆积描述，而是减少模糊选项。
二、先让 AI 理解需求，不要急着生成代码
现在接到一个功能后，我通常先让 AI 整理需求：
先不要写代码。
请根据下面的需求，整理：
1. 功能目标
2. 输入和输出
3. 涉及的模块
4. 可能出现的边界情况
5. 目前还缺少哪些信息
需求：用户连续登录失败5次后，账号锁定30分钟。
AI 往往会继续提出几个有价值的问题：
- 失败次数保存在数据库还是 Redis？
- 账号不存在是否计入失败次数？
- 锁定期间再次登录，是否重新计算锁定时间？
- 登录成功后什么时候清除失败记录？
- 管理员能否手动解除锁定？
这些细节如果不提前确定，最终都会变成返工。
开发中真正麻烦的，通常不是某一行代码不会写，而是大家对需求的理解并不一致。
三、把一个功能拆成四个阶段
我现在习惯把 AI 编程任务分成设计、实现、测试和审查四个阶段。
1. 先确定实现方案
请设计“登录失败5次后锁定30分钟”的实现方案。
技术栈：
- Java 17
- Spring Boot 3
- Redis
- MySQL
说明数据结构、处理流程、异常情况和并发问题。
暂时不要生成代码。
这一步主要检查整体方向。
如果数据结构或处理流程本身不合理，继续生成代码只会放大问题。
2. 每次只实现一个模块
方案确认后，再让 AI 完成其中一部分：
根据已经确认的方案，实现登录失败次数记录服务。
要求：
- 使用 Redis 记录失败次数
- Key 中包含用户ID
- 第5次失败后写入30分钟锁定标记
- 登录成功后清除失败记录
- 不修改登录接口和其他业务代码
任务边界明确后，AI 不容易随意补充其他功能，生成的代码也更方便检查。
3. 根据真实场景补测试
不要只让 AI “写几个单元测试”，而要直接给出测试场景：
请为当前服务补充单元测试，覆盖以下情况：
1. 第1次登录失败
2. 连续第5次登录失败
3. 登录成功后失败次数被清除
4. 锁定期间再次尝试登录
5. Redis记录自然过期
6. 两个请求同时更新失败次数
先列出测试思路，再生成测试代码。
先看测试思路，可以判断 AI 是否真的理解了业务，而不是机械地生成几条断言。
4. 最后再做代码审查
请以代码审查者的角度检查当前实现，重点关注：
- 是否存在并发问题
- Redis Key 是否可能冲突
- 过期时间设置是否正确
- 是否会暴露账号是否存在
- 异常情况下是否会留下错误状态
不要重写全部代码，只指出问题并给出最小修改建议。
让 AI 只提出必要修改，可以避免一次审查变成一次全面重构。
四、与其描述代码规范，不如提供一个现有示例
AI 需要了解项目背景，但没有必要一次提交整个代码仓库。
如果只是新增一个接口，通常提供这些内容就够了：
- 当前接口或相关服务代码；
- 请求参数和返回结构；
- 使用的框架及版本；
- 需要遵守的异常处理方式；
- 项目中一个相似功能的实现。
例如：
请参考下面“订单查询接口”的写法，
实现“退款记录查询接口”。
保持一致的内容：
- 分页参数
- 返回值结构
- 异常处理
- 日志格式
- 方法命名
一个已经通过审查的同类文件，往往比几百字的编码规范更有用。AI 可以直接识别项目现有的命名、分层和返回格式，生成结果也更统一。
五、明确告诉 AI 哪些地方不能改
在已有项目中，AI 很容易出现“顺手优化”。
原本只是修改日期格式，它可能同时调整变量名、抽取公共方法、替换工具类，导致改动范围迅速扩大。
因此，我会在任务中加入限制条件：
只修改日期格式化逻辑。
限制：
- 不修改接口字段
- 不重命名现有变量
- 不新增第三方依赖
- 不调整目录结构
- 不重构其他方法
- 输出具体修改位置和修改原因
对于维护中的项目，改动更大并不代表方案更好。无关修改越少，代码审查和回归测试的成本越低。
六、不要问“能不能运行”，要给出验收条件
“这段代码能运行吗？”很难得到可靠答案。
AI 只能根据当前看到的代码进行判断，它并不知道你的本地环境、配置文件和真实数据是否一致。
更有效的问法是：
请给出验证当前功能所需的命令，并说明：
1. 正常情况下应该出现什么结果
2. 哪些现象代表验证失败
3. 最可能遇到的环境问题
4. 对应的排查方式
遇到真实报错时，也不要只截取最后一行。最好提供完整错误信息，并要求 AI 优先定位最早出现的有效错误：
下面是实际运行后的完整报错。
请找到最早出现的有效错误，判断后面的内容是否属于连锁报错。
本轮只分析根因，并给出最小修改方案。
这样可以避免被大量重复堆栈信息带偏。
七、一套可以直接使用的任务模板
我现在经常使用下面这套模板：
你需要在现有项目中完成一个小范围开发任务。
【任务目标】
说明最终需要实现的结果。
【项目环境】
- 编程语言及版本：
- 框架及版本：
- 相关依赖：
- 运行方式：
【现有实现】
提供相关代码或涉及的文件。
【输入与输出】
说明参数、返回值和异常情况。
【修改范围】
列出允许修改的文件或方法。
【限制条件】
- 不新增依赖
- 不修改公共接口
- 不调整无关代码
- 保持现有命名和代码风格
【验收条件】
列出正常流程、异常流程和边界场景。
请先复述你对任务的理解，并指出缺失信息。
确认后再开始生成代码。
它的价值不在于格式，而在于提前确定三个问题：要做什么、不能改什么、如何判断已经完成。
八、AI 适合完成哪些开发工作？
AI 比较适合处理边界清晰、结果容易检查的任务，例如：
- 补充重复性的业务代码；
- 生成单元测试初稿；
- 解释陌生项目的调用关系；
- 根据报错缩小排查范围；
- 将旧 API 迁移到新写法；
- 检查空指针和异常分支；
- 整理接口文档与变更说明。
但涉及业务规则、权限设计、数据库结构、事务处理和长期维护成本时，仍然需要开发者做最终判断。
AI 能快速给出“常见方案”，却不知道当前项目经历过哪些历史调整，也不了解团队真正要解决的问题。
写在最后
AI 更像一个编码速度很快、知识面很广，但不了解项目历史的协作者。
需求模糊时，它会主动补全细节，也可能非常自信地走错方向；任务清楚时，它又能迅速完成大量重复工作。
因此，AI 编程效率的关键，不是寻找一句可以生成完整项目的“万能提示词”，而是把复杂需求拆成一组边界明确、结果可检查的小任务。
先确认需求，再设计方案；每次实现一部分，用测试验证结果，最后进行审查。
做到这些之后，AI 生成的代码才会从“看起来能用”，逐渐变成“真正可以放进项目里”。
