前言
在日常开发工作中，AI 编程助手正在成为开发者的"配对程序员"。但很多人有一个困惑：“我告诉了 AI 要做什么，结果出来的代码却需要大量修改，甚至完全跑偏。”
问题的核心不在于 AI 能力不足，而在于：沟通方式和信息传递的质量决定了代码产出的质量。
本文将结合实际项目（Java 分层架构后端）的开发案例，总结一套与 AI 高效协作生成代码的方法论。
一、核心原则：AI 是"需求执行者"，不是"需求分析师"
AI 不了解你的业务背景、代码风格、命名规范、架构约束。你给的信息越精确，它产出的代码离"正确"越近。
常见误区示例：
低质量提示：
帮我写一个查询接口
高质量提示：
在 OrchDefectRecordAPI 中新增根据单个 defectRecordId 查询的接口，
入参为 BaseIdParams，新建返回值类 AuditDefectRecordDetailDTO（不要复用现有DTO），
具体实现逻辑在 DefectRecordServiceImpl 中，通过 OrchDefectRecordController 调用，
有问题请告诉我我来确认
关键差异：
- 明确了修改哪个文件（OrchDefectRecordAPI）
- 明确了入参类型（BaseIdParams）
- 明确了返回值设计决策（新建，不复用）
- 明确了实现逻辑的归属层（ServiceImpl）
- 授权 AI 主动提问（有问题告诉我）
二、结构化提示三要素
要素一：定义边界 —— 告诉 AI 在哪里改
不说清楚范围，AI 可能在错误的文件里写代码，或者在正确的文件里改错位置。
示例：
在 imx-quality 项目
→ OrchDefectRecordAPI（接口定义）
→ OrchDefectRecordController（Controller实现）
→ DefectRecordServiceImpl（业务逻辑）
这三个文件中分别做对应修改
要素二：提供约束 —— 告诉 AI 不能做什么
约束条件往往比"要做什么"更重要。
示例：
不要使用 AuditCheckAreaDTO 和 QmsCheckAreaZoneDTO，
而是新建返回值类，字段和这两个 DTO 大概相同
这一句话避免了 AI 直接复用已有类，导致职责混乱、后续难以独立扩展。
要素三：授权提问 —— 让 AI 在不确定时问你
这是最被忽视却最重要的一点。
有问题请告诉我我来确认
这句话会让 AI 在面临设计决策点时停下来问你，而不是自行脑补一个可能错误的方案。
三、设计决策点的确认流程
在实际使用中，一个"新增接口"的需求往往涉及多个设计决策。AI 会把这些决策整理成问题列出来，你逐一确认后再开始实现。
实际案例 —— 新增 Audit 检查区域详情接口：
AI 提问：
1. 返回值类命名：AuditCheckAreaDetailDTO 还是其他？
2. 返回结构：区域基本信息 + zones 分区列表，是否可以？
3. Service 方法签名：
- 选项 A：AuditCheckAreaDetailDTO getCheckAreaDetailById(Long id)
- 选项 B：AuditCheckAreaDetailDTO getCheckAreaDetailById(CheckAreaParams params)
4. 权限配置：和检查区域详情一样的权限？
用户回答：
1. AuditCheckAreaDetailDTO
2. 可以
3. A
4. 和详情一个权限
这种"问答式确认"的优势：
- 避免了 AI 在关键设计节点做错误假设
- 将架构决策权牢牢掌握在开发者手中
- 最终输出的代码与预期高度一致，几乎不需要返工
四、信息质量决定代码质量
4.1 提供现有代码的上下文
不要假设 AI 知道你的项目结构。把相关文件路径或目录结构提供给它。
示例 —— 把文件夹结构贴给 AI：
imx-quality/
├── application/
│ └── defectrecord/service/impl/DefectRecordServiceImpl.java
├── presentation/
│ └── aggregate/defectrecord/dto/DefectRecordDTO.java
└── orch/
└── aggregate/defectrecord/controller/api/OrchDefectRecordAPI.java
AI 就能正确理解：
- presentation 层存放 DTO
- application 层存放 Service 实现
- orch 层是对外暴露的 API
4.2 说明架构规范（如有）
项目采用分层架构：
- Controller 层只做参数传递，不写业务逻辑
- 业务逻辑全部在 Service 层实现
- DTO 新建，不复用现有类
这几句话能让 AI 生成的代码自然符合项目架构，而不需要你在代码出来之后再手动"搬运"逻辑。
4.3 明确枚举、类型等细节
字段类型一旦说错，会引发大量编译错误。
示例：
status 字段是 QmsCheckAreaStatusEnum 枚举类型，
不是 Integer，需要通过 getById(configStatus) 进行转换
五、分阶段迭代策略
复杂需求不要一次性交给 AI，分阶段进行更稳妥。
阶段一：先理解，再实现
先让 AI 分析现有代码，再基于分析结果提出实现方案。
先分析 RegionOverlapUtil 类各个方法的作用，然后
告诉我如何判断一个点是否在某个区域内
让 AI 先"读懂"代码，你确认它理解正确后，再让它写新代码。
阶段二：MVP + 迭代
先实现核心功能，再根据实际运行情况补充细节。
第一轮：
先实现基础的 getAuditDefectRecordDetail 方法，
返回 defectRecordPO 的所有字段
第二轮（用户调整后）：
删除 woNumber、carModel 等基础字段，
新增 checkAreaId、checkItemId、coordinate、defectLevel、defectDomain 字段
这种分批迭代比一次性描述全部需求更精准，因为在看到第一版代码后，你更清楚自己真正想要什么。
六、让 AI 自检
代码生成完成后，不要直接运行，先让 AI 做编译检查。
提示语：
检查一下这个文件是否有编译错误
AI 会主动检查：
- import 路径是否正确
- 类型是否匹配
- 接口方法是否都有实现
- 枚举转换是否正确
实际案例 —— AI 自检发现的典型问题：
// ❌ 错误：直接赋值 Integer 给枚举字段
result.setStatus(checkAreaPO.getConfigStatus());
// ✅ 正确：通过枚举的 getById 方法转换
result.setStatus(QmsCheckAreaStatusEnum.getById(checkAreaPO.getConfigStatus()));
七、高效沟通的核对清单
在向 AI 提出需求前，用以下清单自查：
| 维度 | 检查项 | 示例 |
|---|---|---|
| 边界 | 是否明确了要修改的文件？ | OrchDefectRecordAPI.java |
| 约束 | 是否说明了不能做的事？ | 不复用现有DTO，新建返回值类 |
| 层次 | 是否指定了逻辑实现的层？ | 在 ServiceImpl 中实现 |
| 类型 | 入参和返回值的类型是否已确定？ | 入参 BaseIdParams，返回 DTO |
| 授权提问 | 是否告知 AI 遇到不确定时可以提问？ | 有问题请告诉我我来确认 |
| 命名 | 新建类/方法的命名是否已决定？ | AuditDefectRecordDetailDTO |
八、总结
与 AI 高效协作写代码，本质上是把模糊的脑海想法转化为精确的书面指令的能力。
几个核心习惯：
- 提问前先整理清楚：你想让 AI 改哪几个文件、每个文件的职责是什么
- 让 AI 提问，而不是让 AI 猜测：遇到设计决策，人来拍板，AI 来执行
- 分阶段迭代：先跑通主流程，再完善细节
- 利用 AI 自检：代码生成后让 AI 检查编译问题，比自己肉眼找错更高效
- 上下文越充分，结果越准确：把项目结构、架构规范、枚举类型等背景信息一起提供
AI 不是万能的，但"精确的指令 + 合理的迭代策略"能让 AI 成为真正高效的编程搭档。
本文案例来自实际生产项目（Java Spring Boot 分层架构），核心技术栈：MyBatis Plus、DDD 分层架构、RESTful API。