一、使用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.提问技巧

场景 推荐做法
设计方案 描述业务背景 + 现有代码接口 + 目标,让AI输出流程或者伪代码,确认后再写代码
生成代码 明确方法签名、异常处理策略、日志/埋点风格,参考已有代码的写法
有约束条件 明确说出约束(如:“不能修改现有方法逻辑”),AI会给出更合适的方案
发现重复代码 直接问“这段代码是否可以抽象”,AI会分析最合适的抽象层次
需求变更 直接描述变更内容,AI会在已有代码基础上做最小改动
逻辑验证 问“是否有遗漏调用”等,AI能帮你发现隐藏的逻辑问题

2.2.注意事项

注意事项 具体做法
多轮对话后注意清理 多次修改同一文件后,可能产生重复注释或冗余 import,让AI 做一次清理。
重构要分步执行 一次只改一个文件,确认 diff 正确后再继续,避免批量改动难以排查。
保持上下文连贯 在对话中引用具体的类名、方法名、常量名,AI 能更精准地定位代码。
异常处理要明确 告诉AI 失败时是抛异常、返回错误码还是只打日志,避免生成不符合业务语义的代码。
配置要注明 新增动态配置时,在常量定义处注明默认值和语义,方便后续维护。
等待部署时不要闲着 部署期间可以让 AI 整理测试用例、检查其他文件是否有遗漏,充分利用等待时间。

2.3.利用碎片化时间,让机器不休息

AI 辅助开发的一个重要优势是:机器不需要休息,人可以。合理利用午休、晚饭等碎片时间,把耗时较长的任务交给 AI 在后台执行,人只需偶尔回来看一眼进展,效率可以大幅提升。

2.3.1. 适合在碎片时间执行的任务:

  • 代码生成(尤其是涉及多个文件的批量改动)
  • 单元测试编写
  • 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。

Logo

有“AI”的1024 = 2048,欢迎大家加入2048 AI社区

更多推荐