AI 写代码前，我会让它先回答的 6 个问题

本文目录

问题 1：你对任务的理解是什么，目标和范围分别是什么
问题 2：哪些信息缺失，哪些假设必须人工确认
问题 3：现有项目中，应该遵守哪些上下文和约束
问题 4：有哪些可选方案，推荐哪个，为什么
问题 5：最容易出错的边界、异常和安全风险是什么
问题 6：怎样才算完成，应该如何验证

![在这里插入图片描述](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/187bca368d214e07934f3bbd633f092b~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5YWo5qCI5byE5r2u5YS_:q75.awebp?rk3s=f64ab15b&x-expires=1790221157&x-signature=I16yEXgptnU0Gsip5OBlN1gAD6Y%3D)

开篇

让 AI 写代码之前，你通常会做什么？

很多时候，流程是这样的：

收到需求
  ↓
把需求粘贴给 AI
  ↓
拿到代码
  ↓
复制进项目
  ↓
在报错和返工中补充上下文

这种方式看起来很快。

但真正消耗时间的，往往是后面那些原本可以提前发现的问题：

AI 理解的功能和产品真正想要的不一样。
代码没有遵守项目现有分层和异常规范。
关键权限、状态和边界场景没有处理。
实现范围比需求大很多，影响了不相关模块。
测试写完后，才发现验收标准根本没有定义。

上一篇文章我们讨论了“先写方案，再写代码”。

但日常开发中，并不是每个任务都需要一份完整方案。

有时你只需要在开始生成代码前，让 AI 回答几个关键问题，就足以避免大部分无效输出。

这篇文章分享我会固定问 AI 的 6 个问题。

它们不是为了拖慢开发，而是为了让代码生成建立在更可靠的前提上。

本文不会讨论什么

这 6 个问题不是一套必须逐字照抄的仪式。

本文不会：

要求简单的变量改名也写完整方案。
用 6 个问题代替需求评审和技术评审。
认为 AI 的回答已经等同于事实。
因为问题问得完整，就跳过测试和代码审查。
建议把生产密钥、隐私数据和未脱敏日志粘贴给 AI。

它们的目标只有一个：

在写代码前，把 AI 最容易擅自假设的部分先暴露出来。

一、为什么要让 AI 先回答问题

AI 生成代码时，会根据已有上下文补全缺失信息。

这是一种能力，也是一种风险。

如果你只说：

帮我实现绑定邮箱功能。

AI 需要自行猜测：

用户是否需要登录？
是否需要邮箱验证码？
一个邮箱能否绑定多个账号？
绑定后是否允许修改？
是否需要重新登录？
邮箱是否要脱敏展示？
验证码错误、过期和频率限制怎么处理？
当前项目的 Controller、Service、异常和测试规范是什么？

它可能会给出一份完整的实现。

但完整不代表适配。

在代码生成前多问几句，本质上是在把“模型的默认假设”变成“开发者可以确认的问题”。

默认假设
  ↓
显式问题
  ↓
确认规则
  ↓
最小实现
  ↓
可验证交付

这就是 6 个问题存在的意义。

二、写代码前，我会让 AI 回答的 6 个问题

问题 1：你对任务的理解是什么，目标和范围分别是什么

先让 AI 复述任务，而不是直接开始写代码。

请先不要写代码。

请复述你对“绑定邮箱”功能的理解，并分别说明：
1. 本次功能目标。
2. 本期包含的范围。
3. 本期明确不处理的内容。
4. 你认为可能存在歧义的描述。

这一步可以快速发现“我们说的是不是同一件事”。

例如，产品说“绑定邮箱”，可能只是用于通知，也可能意味着邮箱登录、找回密码、账号唯一标识等完全不同的业务范围。

问题 2：哪些信息缺失，哪些假设必须人工确认

这是最重要的一问。

基于当前需求，请列出：
1. 已知事实。
2. 你准备做出的假设。
3. 必须由产品、业务或开发者确认的问题。

请不要自行决定未提供的业务规则。

对于绑定邮箱，AI 应该主动追问：

待确认问题	为什么重要
是否必须验证邮箱所有权	决定验证码和安全流程
一个邮箱能否绑定多个账号	决定唯一约束和异常策略
用户是否可以解绑或更换邮箱	决定状态和历史数据处理
验证码有效期和发送频率	决定防刷与用户体验
绑定成功后是否触发安全提醒	决定通知和审计范围

如果 AI 没有列出这些问题，开发者也可以把它当作需求检查清单继续补充。

问题 3：现有项目中，应该遵守哪些上下文和约束

AI 不知道你的项目结构，除非你明确提供。

在进入实现前，我会让它先确认需要哪些上下文：

为了实现这个功能，你需要了解哪些现有项目上下文？

请按以下维度列出：
1. 相关模块和调用入口。
2. 数据模型和已有接口。
3. 分层、异常、日志和鉴权规范。
4. 验证码、通知或用户安全模块是否已存在。
5. 测试方式和需要阅读的文件。

然后只提供与任务相关的最小信息，例如：

项目上下文：
- 后端使用 Java + Spring Boot。
- 用户信息由 UserService 管理。
- 身份验证由 AuthService 管理。
- 业务错误统一使用 DomainException。
- 验证码能力已经由 VerificationCodeService 提供。
- 用户邮箱字段已经存在，但当前允许为空。
- 修改后需要补充 Service 层单元测试。

先问“缺什么上下文”，再补上下文，比一开始把整个仓库塞给 AI 更清晰也更安全。

问题 4：有哪些可选方案，推荐哪个，为什么

这一步适合包含状态、安全、跨模块或长期影响的任务。

请不要写代码。

基于当前规则，给出绑定邮箱功能的可选实现方案。

每种方案请说明：
1. 处理流程。
2. 涉及的模块。
3. 优点和缺点。
4. 对安全、用户体验和维护成本的影响。
5. 推荐程度和推荐理由。

例如，绑定邮箱至少可能有两类方案：

方案	过程	适用情况
直接更新邮箱	用户提交邮箱后立即保存	邮箱只作为普通资料字段
验证后绑定邮箱	发送验证码，验证成功后再保存	邮箱涉及登录、安全或通知可信度

AI 可以帮助比较取舍。

但最终选择仍然要由业务目标和项目风险决定。

问题 5：最容易出错的边界、异常和安全风险是什么

写代码前不问风险，生成后通常就只能被动补洞。

可以这样提问：

请列出绑定邮箱功能中需要重点处理的：
1. 参数与格式异常。
2. 权限与越权风险。
3. 重复请求和并发问题。
4. 验证码、安全和频率限制问题。
5. 数据一致性与审计问题。
6. 需要补充的测试场景。

请按风险优先级排序，并说明每项应如何验证。

预期应该覆盖的场景包括：

邮箱格式非法。
验证码错误、过期或已使用。
邮箱已经被其他账号绑定。
重复提交绑定请求。
并发绑定同一个邮箱。
非当前用户尝试修改他人邮箱。
日志中意外打印完整邮箱或验证码。

如果这些问题在代码生成前就已经出现，后续实现会更有方向。

问题 6：怎样才算完成，应该如何验证

最后一问决定 AI 的输出能否进入工程闭环。

请根据当前规则设计验收标准和测试矩阵。

请按“正常、边界、异常、安全”分类。
每项需要包含：
1. 前置条件。
2. 输入或操作。
3. 预期结果。
4. 覆盖的规则。
5. 验证方式。

暂时不要写测试代码。

例如：

类别	场景	预期结果
正常	用户输入有效邮箱和正确验证码	邮箱绑定成功
边界	用户重复提交同一次绑定	返回一致结果或明确幂等行为
异常	验证码过期	绑定失败并返回业务错误
安全	邮箱已被其他账号绑定	不修改数据并返回明确错误
权限	未登录用户发起绑定	拒绝访问

只有完成标准清楚后，才知道 AI 生成的代码和测试是否真的覆盖了任务。

三、实战：把 6 个问题放进一次真实协作

下面是一段可以直接使用的第一轮 Prompt。

任务：
为用户中心新增“绑定邮箱”能力。

已知项目上下文：
- 后端使用 Java + Spring Boot。
- 用户信息由 UserService 管理。
- 验证码能力由 VerificationCodeService 提供。
- 业务错误统一使用 DomainException。
- 用户邮箱字段已存在，但允许为空。
- 修改后需要补充 Service 层单元测试。

请先不要写代码，请依次回答下面 6 个问题：

1. 你对任务目标、本期范围和非范围的理解是什么？
2. 当前信息中哪些是已知事实，哪些需要人工确认？
3. 为了实现功能，还需要阅读或确认哪些项目上下文？
4. 有哪些可选方案，各自的安全、体验和维护取舍是什么？
5. 最容易遗漏的边界、异常、权限、并发和安全风险是什么？
6. 怎样定义验收标准和测试矩阵，才能判断功能完成？

输出要求：
- 不写代码。
- 每个问题使用清晰的小标题。
- 不确定的内容单独列为“待确认项”。
- 最后给出进入代码阶段前的最小确认清单。

在这轮回答后，你应该先做三件事：

确认业务规则
  ↓
补充项目上下文
  ↓
确定实现范围和验收标准

只有这些前提稳定后，再请求 AI 生成某个具体方法或模块。

四、什么时候不需要完整问完 6 个问题

不是每次修改都需要走完整流程。

例如下面这类任务，通常可以简化：

已有明确测试失败，只需要修一个确定的条件判断。
在已有模式下新增一个同结构的字段映射。
已经评审过方案，只需要实现一个小方法。
文案、注释、格式化或无行为变化的重命名。

但即使是简单任务，至少也建议确认两件事：

1. 修改范围是什么，哪些文件不应该动？
2. 修改后用什么方式验证？

可以把 6 个问题理解为一套“按复杂度展开”的清单：

任务复杂度	建议使用的问题
简单、局部、易验证	问题 1 + 问题 6
中等、涉及业务规则	问题 1、2、3、5、6
复杂、跨模块或高风险	完整 6 个问题

这样既不会为小改动增加负担，也不会让复杂任务在缺少判断的情况下直接进入编码。

五、把 6 个问题变成你的代码生成前检查卡

可以把下面这张卡保存到项目文档或个人 Prompt 库：

AI 写代码前，先确认：

[ ] 1. 任务目标、范围和非范围是什么？
[ ] 2. 哪些规则缺失，哪些假设必须人工确认？
[ ] 3. 需要哪些项目上下文、规范和相关代码？
[ ] 4. 是否存在可选方案，需要比较什么取舍？
[ ] 5. 边界、异常、权限、并发和安全风险是什么？
[ ] 6. 怎样验收，哪些测试场景必须覆盖？

确认后再进入：
最小代码实现
  ↓
代码审查
  ↓
测试验证

这张检查卡不保证 AI 一定写出正确代码。

但它可以大幅减少“问题没问清、代码已经写了一堆”的情况。

六、总结

在让 AI 写代码前，我会先让它回答 6 个问题：

任务目标、范围和非范围是什么？
哪些信息缺失，哪些假设必须人工确认？
现有项目中需要遵守哪些上下文和约束？
有哪些可选方案，推荐哪个，为什么？
最容易出错的边界、异常和安全风险是什么？
怎样才算完成，应该如何验证？

这些问题不是为了让 AI 显得更聪明。

它们是为了让开发者更早看见不确定性，并在代码生成前保留对任务的控制。

请记住：

好的 AI 编程不是更快地得到代码，而是更早地得到正确的问题。

下一篇文章，我们进入陌生代码库场景：

用 AI 快速读懂陌生项目：代码库导览工作流。

如果这篇文章对你有帮助，欢迎点赞、收藏、关注专栏。
也欢迎在评论区留言：这 6 个问题里，你过去最容易跳过的是哪一个？

✍坚持原创，求关注，点赞，收藏