一、使用AI辅助开发的两个核心前提

1.先搞清楚再开口：明确问题边界与目标

在向AI描述问题之前，开发者必须自己先理清整个业务流程、技术上下文和预期目标。这包括：

1. 代码需要改哪里？ 明确具体的文件、类、方法或模块。
2. 改什么？ 是修复Bug、增加功能、优化性能还是重构代码？
3. 参考哪里的写法？ 明确项目中已有的编码规范、设计模式或特定库的用法。

核心逻辑： 如果提问者自己都没想清楚，那么描述给AI的问题本身就可能是模糊、片面甚至错误的。这会导致AI生成的代码方向产生偏差，后续调试时也难以定位问题的根本原因。

案例补充：

• 反面案例（模糊提问）： “帮我写个用户登录功能。”
  • 问题： 缺少技术栈、认证方式、密码存储策略、异常处理等关键约束，AI可能生成不适用或存在安全风险的代码。
• 正面案例（清晰提问）： “在现有的Spring Boot项目中，参考AuthController的写法，增加一个手机号+验证码登录的接口。要求：使用JWT生成token，验证码需从Redis校验并设置1分钟有效期，异常时返回统一的Result对象。”
  • 效果： AI能基于明确的上下文、技术栈和约束，生成更贴合项目实际、可直接Review的代码草案。

行动建议： 在向AI提问前，花1-2分钟在纸上或注释里写下：修改背景、具体位置、输入输出、参考示例、约束条件。这能极大提升与AI协作的效率和产出质量。

2.生成代码后必须人工Review【现阶段】

AI生成代码最好不要直接提交，逐行review diff。一方面为了发现潜在问题，另一方面是让自己知道改了什么–后续出问题时才有印象可以追溯。通过review发现问题、逐步调整，也是熟悉代码的过程。【可以借助AI相关工具辅助review】

二、使用AI（龙虾🦞）开发的经验总结

2.1.提问技巧

2.2.注意事项

适合在碎片时间执行的任务：

• 代码生成（尤其是涉及多个文件的批量改动）
• 单元测试编写
• PR自动化测试
• 文档整理和技术方案撰写
• 代码重构（已确认方案，让AI逐步执行）
  操作建议：在离开之前，把任务描述清楚，明确“做到哪一步停下来等我确认”，然后放心去吃饭/休息。回来后检查进展，确认无误后继续下一步。
  示例：午休时告诉AI：“帮我把xxx方法从连个类中抽象到xxxX类，完成后列出所有改动的文件和diff，等我回来后再提交。”
  紧急需求时的节奏：当需求比较急时，可以充分利用非工作时间让 AI 持续推进。人的精力有限，但 AI 没有疲劳感。合理的节奏是：白天专注于方案确认和关键决策，把代码生成、测试用例整理、文档撰写等执行性工作放到午休或晚饭时间，回来只需 review 结果。这样既保证了质量（人工把关关键节点），也最大化了 AI 的执行效率。

2.4. 人工介入时机：什么时候该出手

AI 辅助开发不是"全程托管"，人需要在关键节点介入，把控方向和质量。以下是需要人工介入的典型时机：

必须介入的时机（不能跳过）：

• 链路图确认后：草稿链路图出来后，必须人工确认改动范围和方向，再让 AI 开始写代码。这是最重要的一个介入点，方向错了后面全白费。- 每个文件的 diff review：AI 生成代码后，必须人工 review diff，确认逻辑正确、没有遗漏、没有引入新问题。不能因为"AI 生成的应该没问题"就直接提交。- 需求变更时：需求调整后，不要直接让 AI 继续，先人工确认变更对已有代码的影响范围，再描述给 AI 。- CR 问题修复前：收到 Code Review 意见后，先自己理解问题，再让 AI 给出修复方案，确认方案合理后再执行。不要直接把 CR 评论扔给 AI 让它自己决定怎么改。

建议介入的时机（提升质量）：

• 多轮对话后做一次全局检查：多次修改同一文件后，让 AI 输出当前完整代码，人工通读一遍，检查是否有逻辑不一致或遗漏的地方。- 部署前的最终确认：提交 PR 前，自己过一遍所有改动文件，确认没有调试代码、临时注释、错误的 import 等遗留问题。- 测试验证阶段：日志和埋点的验证需要人工判断，AI 可以帮你整理验证清单，但最终"这个日志是否符合预期"需要你来判断。

可以放手让 AI 执行的阶段：

• 已确认方案后的代码生成- 重复性的代码清理（冗余注释、import 整理）- 测试用例的初稿生成- 文档的初稿撰写

核心原则：AI 负责执行，人负责决策。凡是涉及"方向对不对"“逻辑对不对”“要不要提交"的判断，都需要人来做。凡是"按照已确认的方案写代码”“整理文档”"清理冗余"这类执行性工作，可以放心交给 AI。