尧图网站建设 
1. 校招入职第一周我发现代码写不完不是因为手速慢刚入职那会儿我每天最焦虑的事情不是看不懂代码而是看懂了也写不完。需求文档丢过来接口定义、数据模型、单元测试、异常处理、日志埋点一套下来少说几百行。mentor 给的排期是按人天算的但我发现隔壁工位的同事下午三点就提交了 MR而我还在跟一个空指针异常较劲。后来我观察了一下他的操作习惯发现他并不是打字比我快而是把 AI 嵌进了整个开发流程的每一个环节——不是简单地让 AI 写一段代码然后复制粘贴而是从需求理解、方案设计、编码实现、测试补全到 Code Review 准备每一步都有 AI 参与但每一步的参与方式都不一样。这个发现让我开始重新思考一个问题AI Coding 到底应该怎么用是把它当成一个更聪明的代码补全工具还是当成一个可以对话的结对伙伴用了大半年之后我的结论是都不对。正确的用法是把它当成一个需要你主动管理上下文的协作者——你给它什么信息、在什么阶段给它、以什么形式给它直接决定了输出质量的高低。这篇文章就是我这大半年踩坑踩出来的完整工作流。适合刚接触 AI Coding 的校招生、想系统化提升编码效率的初中级工程师以及那些装了插件但不知道怎么用到位的开发者。我不会讲什么AI 将改变世界的宏大叙事只讲我每天实际在用的东西什么环节用什么工具、提示词怎么写、上下文怎么管、哪些坑我踩过你别再踩。2. 先搞清楚 AI Coding 工具的能力边界在哪里2.1 三类工具的定位差异市面上主流的 AI Coding 工具按交互形态大致可以分成三类每类的适用场景完全不同。很多人用不好 AI Coding根本原因就是拿 A 类工具去干 C 类工具的活。工具类型典型形态擅长的事不擅长的事行内补全型IDE 插件灰色文字提示补全重复代码、写样板逻辑、根据注释生成实现跨文件重构、理解业务上下文对话型侧边栏 Chat 面板解释代码、生成方案、调试报错、写测试需要精确控制每一行输出的场景代理型命令行 Agent / 自主执行多文件修改、批量重构、按描述完成完整功能需要频繁人工确认的高风险操作我自己的分工是这样的行内补全负责手的工作对话型负责脑的工作代理型负责腿的工作。手就是敲键盘的活脑就是思考和方案腿就是跨文件跑腿。三者配合起来效率提升才明显。刚开始我只用行内补全感觉也就那样省了大概 20% 的敲键盘时间。后来加上对话型工具做方案设计和调试整体效率大概提升了 40% 到 50%。再后来开始用代理型工具做批量重构和测试补全才真正感觉到质变。2.2 上下文窗口不是越大越好这里有一个很多人容易误解的点上下文窗口大不等于效果好。我实测下来当你往对话里塞太多无关信息时模型的输出质量反而会下降。它会分心把注意力分散到不相关的代码片段上。我的经验法则是每次对话只给模型它完成当前任务所必需的最小上下文。比如你要让它帮你写一个 Service 层的方法你需要给的是这个方法的接口定义、相关的数据模型、以及一两个类似的已有方法作为风格参考。不需要把整个项目的代码都贴进去。具体操作上我一般这样做用文件路径的方式精确引用相关文件而不是全选粘贴如果项目有清晰的模块划分只引用当前模块的文件对于跨模块调用只引用接口定义文件不引用实现文件对话轮次多了之后主动开新对话把关键结论带过去提示如果你发现模型开始胡言乱语或者答非所问第一反应应该是检查上下文是不是太杂了而不是怀疑模型能力不行。2.3 什么任务适合交给 AI什么任务必须自己来这个问题我踩过坑。刚上手的时候什么都想让 AI 写结果有些代码 review 的时候被 mentor 打回来重写反而更费时间。后来我总结了一个简单的判断标准适合交给 AI 的任务有明确输入输出定义的纯逻辑代码重复性高的样板代码DTO、Mapper、配置文件单元测试的用例生成报错信息的初步分析和修复建议代码注释和文档的初稿必须自己来的任务涉及核心业务规则的决策逻辑需要权衡多个技术方案的架构设计涉及数据安全和权限控制的代码对性能有严格要求的核心链路需要理解历史遗留代码意图的修改这个边界不是固定的随着你对 AI 工具越来越熟悉适合交给它的任务会越来越多。但有一条底线你提交的每一行代码你都要能解释为什么这么写。如果 AI 写了一段你看不懂的代码要么搞懂它要么重写。3. 我的日常开发流程AI 在每一步具体怎么介入3.1 需求理解阶段让 AI 帮你做翻译拿到需求文档之后我的第一步不是打开 IDE而是把需求描述丢给对话型工具让它帮我做三件事提取关键实体和关系需求里提到了哪些业务对象它们之间是什么关系列出需要变更的接口新增哪些接口修改哪些接口影响范围是什么生成待确认问题清单需求里有哪些模糊的地方需要跟产品确认这一步看起来简单但实际价值很大。因为需求文档往往是产品经理用业务语言写的而我要把它翻译成技术语言。让 AI 先做一轮翻译我再基于它的输出做修正比我从零开始想要快得多。举个例子之前有个需求是用户可以收藏商品收藏列表要支持分页和排序。我把这句话丢给 AI它帮我拆出了收藏关系实体用户ID、商品ID、收藏时间、收藏接口新增收藏、取消收藏、查询收藏列表、分页参数页码、每页数量、排序字段收藏时间、价格等。然后它自动生成了一份需要跟产品确认的问题清单比如取消收藏是物理删除还是逻辑删除收藏列表是否需要返回商品的最新价格。这些问题如果我自己想可能要花半小时AI 几秒钟就列出来了。当然它列出来的不一定全对但至少给了我一个起点。3.2 方案设计阶段用 AI 做方案对比需求确认清楚之后下一步是技术方案设计。这个阶段我会用对话型工具做一件事让它给我出至少两个方案并列出各自的优缺点。比如要实现一个商品搜索功能我可能会这样问当前项目技术栈是 Spring Boot MySQL Redis 需要实现商品关键词搜索数据量大约 50 万条 QPS 峰值预计 200。请给出两种实现方案 分别说明优缺点、适用场景和大致实现思路。AI 一般会给出类似MySQL LIKE 查询 索引优化和引入搜索引擎两种方案然后分别分析。我要做的不是直接采纳而是基于它的分析做判断。比如它可能没考虑到我们团队没有搜索引擎的运维经验或者没考虑到数据同步的延迟问题。这些就是我要补充的。这个阶段的核心价值不是让 AI 替我做决策而是帮我快速穷举可能性避免遗漏。很多时候方案设计的问题不是选错了而是根本没想到还有别的选项。3.3 编码实现阶段行内补全 对话式生成配合使用真正开始写代码的时候我的习惯是这样的第一步先写接口定义和核心逻辑的骨架。这部分我自己写因为它是整个功能的骨架决定了代码的结构和质量。我会写好方法签名、参数校验、核心分支逻辑但具体的实现细节留空。第二步用行内补全填充实现细节。比如我写了一个方法签名和注释行内补全就会自动提示实现代码。这时候我按 Tab 接受然后快速扫一遍逻辑对不对。不对的地方手动改。第三步用对话型工具生成辅助代码。比如 DTO 转换、单元测试、异常处理分支这些代码逻辑简单但写起来费时间直接让 AI 生成。这里有一个关键技巧给 AI 的提示词要包含足够的约束条件。不要只说帮我写一个查询用户的方法而要说帮我写一个根据用户ID查询用户信息的方法 要求 1. 使用 MyBatis-Plus 的 LambdaQueryWrapper 2. 如果用户不存在抛出 BusinessException错误码 USER_NOT_FOUND 3. 返回的 UserVO 需要脱敏手机号中间四位替换为**** 4. 方法上需要加 Cacheable 注解缓存 key 为 user:info:{userId}约束条件越具体生成结果越接近可用状态。我一般会从项目里找一个类似的已有方法连同提示词一起发给 AI让它参考风格。3.4 测试补全阶段AI 最被低估的使用场景说实话写单元测试是我以前最讨厌的事情。不是不会写是觉得重复劳动太多。但用了 AI 之后这个环节反而变成了我最省时间的环节。我的做法是写完一个类之后直接把整个类丢给对话型工具让它生成对应的单元测试。提示词大概是这样的请为以下类生成 JUnit 5 Mockito 的单元测试 要求 1. 覆盖所有 public 方法 2. 每个方法至少覆盖正常流程和异常流程 3. 使用 Mock 和 InjectMocks 注入依赖 4. 断言要具体不要只用 assertNotNull 5. 测试方法命名格式方法名_场景_预期结果生成出来的测试代码大概有 70% 到 80% 可以直接用剩下的需要我补充一些边界条件。但即使这样也比我手写快了三倍以上。注意AI 生成的测试用例有时候会假装覆盖了某个分支实际上断言写得很敷衍。我一般会检查每个测试方法的断言部分确保它真的在验证预期行为而不是只跑通不报错。3.5 Code Review 准备阶段让 AI 先帮你审一遍提交 MR 之前我会做一件事把 diff 内容发给对话型工具让它帮我做一轮预审。提示词大概是请 review 以下代码变更重点关注 1. 是否有空指针风险 2. 是否有线程安全问题 3. 是否有资源未关闭的情况 4. 是否有更简洁的写法 5. 是否有遗漏的异常处理AI 会列出一堆问题有些是误报有些确实是我疏忽了。我一般会把它提出的问题分成三类必须改的、可以改的、不用改的。必须改的就是真正的 bug 或隐患可以改的是代码风格优化不用改的是 AI 理解错了上下文。这一步帮我省了不少被 mentor 打回来的次数。因为很多低级问题在提交之前就被 AI 拦下来了mentor review 的时候就能聚焦在更重要的设计问题上。4. 上下文管理决定 AI Coding 效果的关键变量4.1 为什么你的 AI 总是答非所问用了几个月之后我发现AI Coding 效果不好的原因八成以上出在上下文管理上。具体表现有这几种模型生成的代码用了项目里不存在的工具类模型不知道项目已经有一个类似的方法重复造轮子模型对业务概念的理解和项目实际定义不一致对话轮次多了之后模型开始忘记前面的约束条件这些问题的根源都是一样的模型不知道它不知道的东西。它只能基于你给它的信息做推理你没给它的它就只能猜。猜对了是运气猜错了是常态。4.2 我的上下文管理三板斧第一板斧项目级上下文用规则文件固化。很多 AI Coding 工具支持在项目根目录放一个规则文件比如.cursorrules或类似的配置文件用来告诉模型这个项目的技术栈、代码规范、目录结构。我一般会写这些内容技术栈Java 17 Spring Boot 3.x MyBatis-Plus Redis 代码规范 - Controller 层只做参数校验和路由不写业务逻辑 - Service 层返回 DTO不返回 Entity - 所有异常统一用 BusinessException错误码定义在 ErrorCode 枚举中 - 日志使用 Slf4j关键路径打 info 日志异常打 error 日志 目录结构 - controller/ 接口层 - service/ 业务层 - mapper/ 数据访问层 - model/entity/ 数据库实体 - model/dto/ 数据传输对象这个文件写一次后面所有对话都会自动带上这些信息省得每次都要重复交代。第二板斧任务级上下文用精确引用。每次开始一个新任务的时候我会用符号精确引用相关文件。比如要改一个 Service 方法我会引用这个 Service 文件、它依赖的 Mapper 接口、相关的 Entity 和 DTO。不会把整个模块都引用进来。第三板斧对话级上下文定期清理。一个对话窗口不要用太久。我一般完成一个完整的功能点之后就开新对话。如果确实需要延续之前的上下文我会手动总结一下关键结论带到新对话里。比如之前我们确定了用策略模式实现多种支付方式 支付策略接口是 PaymentStrategy 已经实现了 AlipayStrategy 和 WechatStrategy 现在需要新增一个 BankCardStrategy。这样比让模型去翻几十轮之前的对话要可靠得多。4.3 上下文超限时的处理策略用代理型工具的时候经常会遇到上下文超限的问题。报错信息大概是context is too large或者maximum context length exceeded。遇到这种情况我的处理顺序是先检查是不是引用了不必要的文件。很多时候是不小心把整个目录都引用进来了。把大文件拆成小文件。如果一个文件超过 500 行考虑拆分。用摘要代替全文。对于不需要修改的依赖文件只给接口定义不给实现。分阶段执行。把一个大任务拆成几个小任务每个任务单独执行。提示代理型工具在执行多文件修改时会先把相关文件读进上下文。如果项目很大建议在规则文件里配置忽略目录比如 node_modules、target、.git避免把无关文件读进来。5. 那些让我效率翻倍的提示词技巧5.1 角色设定 任务描述 约束条件 输出格式我总结了一个提示词模板基本上所有场景都能套角色你是一个有 10 年经验的 Java 后端工程师 任务帮我实现一个商品收藏功能 约束 - 使用 Spring Boot 3.x MyBatis-Plus - 收藏关系存在 user_favorite 表字段id, user_id, product_id, create_time - 需要支持分页查询使用 MyBatis-Plus 的 Page 对象 - 取消收藏是逻辑删除用 deleted 字段标记 输出先给表结构再给 Entity、Mapper、Service、Controller 的完整代码这个模板的关键在于约束条件要具体到可以直接执行。不要说代码要规范而要说使用 MyBatis-Plus 的 LambdaQueryWrapper。不要说要考虑异常情况而要说用户不存在时抛出 BusinessException。5.2 用示例代替描述有时候用文字描述不清楚的事情直接给一个示例更高效。比如我想让 AI 按照项目现有的代码风格生成代码我会从项目里找一个类似的类连同提示词一起发过去请参考以下代码风格实现一个订单查询的 Service [粘贴一个已有的 Service 类] 现在需要实现的功能是根据用户ID和订单状态查询订单列表支持分页。这种方式比用文字描述代码风格要简洁、要有注释、要用 Lombok要有效得多。5.3 让 AI 先提问再回答这是一个很多人不知道的技巧在提示词里加一句如果你有不确定的地方先问我。这样 AI 在信息不足的时候会主动提问而不是瞎猜。比如我需要实现一个定时任务每天凌晨清理过期的优惠券。 如果你对清理规则、批量大小、失败重试策略有不确定的地方先问我。这样它可能会问过期是指超过有效期还是超过使用期限清理是物理删除还是标记删除单次清理数量有限制吗这些问题正好是我需要想清楚的。5.4 分步骤执行复杂任务对于复杂的任务不要指望一次对话就能搞定。我的做法是拆成多个步骤每一步确认无误后再进行下一步第一步让 AI 分析需求列出需要变更的文件清单第二步确认清单后让 AI 逐个文件生成代码第三步让 AI 生成对应的单元测试第四步让 AI 做一轮自查列出潜在问题每一步的输出都是下一步的输入这样既保证了质量也方便定位问题。6. 踩过的坑和对应的解决方案6.1 AI 生成的代码看起来对但跑不通这是最常见的问题。AI 生成的代码语法没问题逻辑看起来也合理但实际运行就是报错。原因通常是它用了项目里不存在的依赖或者调用了不存在的方法。我的解决方案是生成代码后先编译编译通过后再看逻辑。不要等到写完一堆代码再一起编译那样排查起来很痛苦。另外在提示词里明确告诉 AI 项目用的是什么版本的依赖能减少很多这类问题。6.2 对话轮次多了之后质量下降这个问题的本质是上下文污染。前面的对话里有一些错误的尝试、废弃的方案这些信息会干扰模型后面的判断。解决方案就是前面说的完成一个功能点就开新对话。如果必须延续手动总结关键结论。我一般一个对话窗口不会超过 20 轮。6.3 代理型工具自作主张改了不该改的文件用代理型工具做批量重构的时候它可能会顺手改一些你没让它改的文件。比如你让它重命名一个方法它可能把相关的注释、文档、甚至测试代码都改了。解决方案是执行前先让它列出计划修改的文件清单确认后再执行。大部分代理型工具都支持dry run模式先看它打算做什么确认无误再让它真正执行。6.4 过度依赖 AI 导致自己能力退化这个问题比较隐蔽但影响深远。我有一段时间什么都让 AI 写结果发现自己对某些基础 API 的记忆越来越模糊遇到问题第一反应是问 AI 而不是自己查文档。后来我调整了策略核心链路的代码自己写辅助代码交给 AI。比如涉及金额计算、权限校验、状态流转的代码我一定自己写写完再让 AI 帮我 review。这样既保证了代码质量也保持了自己的技术敏感度。7. 一些零散但实用的经验关于工具选择我的建议是不要贪多。行内补全、对话、代理三类各选一个用熟就行换来换去反而浪费时间。我目前用的是 IDE 自带的行内补全 一个对话型工具 一个命令行代理工具基本覆盖了所有场景。关于提示词不要追求完美提示词。我见过有人花半小时写一个提示词就为了让 AI 生成一段 20 行的代码。有那个时间自己都写完了。提示词够用就行生成结果不满意就补充约束条件再来一轮比一次性写一个完美提示词要高效。关于学习成本AI Coding 工具的学习曲线其实很平缓但有一个前提你得先会写代码。如果你本身对编程不熟悉AI 生成的代码你无法判断对错那用起来反而更危险。我的建议是先把基础打牢再把 AI 当成加速器而不是替代品。关于团队协作如果团队里有人不用 AI有人用 AI代码风格可能会不一致。我们团队的做法是在规则文件里统一了代码规范不管是不是 AI 生成的代码提交前都要过一遍 Checkstyle。这样至少保证了风格统一。最后分享一个我最近在用的技巧让 AI 帮我写 commit message。提交之前把 diff 发给它让它按照 Conventional Commits 规范生成 commit message。这个虽然是小事情但积少成多也省了不少时间。而且它写的 commit message 往往比我手写的更规范因为我会偷懒它不会。 AI Coding 实战：从需求到 Code Review 的完整工作流
1. 校招入职第一周我发现代码写不完不是因为手速慢刚入职那会儿我每天最焦虑的事情不是看不懂代码而是看懂了也写不完。需求文档丢过来接口定义、数据模型、单元测试、异常处理、日志埋点一套下来少说几百行。mentor 给的排期是按人天算的但我发现隔壁工位的同事下午三点就提交了 MR而我还在跟一个空指针异常较劲。后来我观察了一下他的操作习惯发现他并不是打字比我快而是把 AI 嵌进了整个开发流程的每一个环节——不是简单地让 AI 写一段代码然后复制粘贴而是从需求理解、方案设计、编码实现、测试补全到 Code Review 准备每一步都有 AI 参与但每一步的参与方式都不一样。这个发现让我开始重新思考一个问题AI Coding 到底应该怎么用是把它当成一个更聪明的代码补全工具还是当成一个可以对话的结对伙伴用了大半年之后我的结论是都不对。正确的用法是把它当成一个需要你主动管理上下文的协作者——你给它什么信息、在什么阶段给它、以什么形式给它直接决定了输出质量的高低。这篇文章就是我这大半年踩坑踩出来的完整工作流。适合刚接触 AI Coding 的校招生、想系统化提升编码效率的初中级工程师以及那些装了插件但不知道怎么用到位的开发者。我不会讲什么AI 将改变世界的宏大叙事只讲我每天实际在用的东西什么环节用什么工具、提示词怎么写、上下文怎么管、哪些坑我踩过你别再踩。2. 先搞清楚 AI Coding 工具的能力边界在哪里2.1 三类工具的定位差异市面上主流的 AI Coding 工具按交互形态大致可以分成三类每类的适用场景完全不同。很多人用不好 AI Coding根本原因就是拿 A 类工具去干 C 类工具的活。工具类型典型形态擅长的事不擅长的事行内补全型IDE 插件灰色文字提示补全重复代码、写样板逻辑、根据注释生成实现跨文件重构、理解业务上下文对话型侧边栏 Chat 面板解释代码、生成方案、调试报错、写测试需要精确控制每一行输出的场景代理型命令行 Agent / 自主执行多文件修改、批量重构、按描述完成完整功能需要频繁人工确认的高风险操作我自己的分工是这样的行内补全负责手的工作对话型负责脑的工作代理型负责腿的工作。手就是敲键盘的活脑就是思考和方案腿就是跨文件跑腿。三者配合起来效率提升才明显。刚开始我只用行内补全感觉也就那样省了大概 20% 的敲键盘时间。后来加上对话型工具做方案设计和调试整体效率大概提升了 40% 到 50%。再后来开始用代理型工具做批量重构和测试补全才真正感觉到质变。2.2 上下文窗口不是越大越好这里有一个很多人容易误解的点上下文窗口大不等于效果好。我实测下来当你往对话里塞太多无关信息时模型的输出质量反而会下降。它会分心把注意力分散到不相关的代码片段上。我的经验法则是每次对话只给模型它完成当前任务所必需的最小上下文。比如你要让它帮你写一个 Service 层的方法你需要给的是这个方法的接口定义、相关的数据模型、以及一两个类似的已有方法作为风格参考。不需要把整个项目的代码都贴进去。具体操作上我一般这样做用文件路径的方式精确引用相关文件而不是全选粘贴如果项目有清晰的模块划分只引用当前模块的文件对于跨模块调用只引用接口定义文件不引用实现文件对话轮次多了之后主动开新对话把关键结论带过去提示如果你发现模型开始胡言乱语或者答非所问第一反应应该是检查上下文是不是太杂了而不是怀疑模型能力不行。2.3 什么任务适合交给 AI什么任务必须自己来这个问题我踩过坑。刚上手的时候什么都想让 AI 写结果有些代码 review 的时候被 mentor 打回来重写反而更费时间。后来我总结了一个简单的判断标准适合交给 AI 的任务有明确输入输出定义的纯逻辑代码重复性高的样板代码DTO、Mapper、配置文件单元测试的用例生成报错信息的初步分析和修复建议代码注释和文档的初稿必须自己来的任务涉及核心业务规则的决策逻辑需要权衡多个技术方案的架构设计涉及数据安全和权限控制的代码对性能有严格要求的核心链路需要理解历史遗留代码意图的修改这个边界不是固定的随着你对 AI 工具越来越熟悉适合交给它的任务会越来越多。但有一条底线你提交的每一行代码你都要能解释为什么这么写。如果 AI 写了一段你看不懂的代码要么搞懂它要么重写。3. 我的日常开发流程AI 在每一步具体怎么介入3.1 需求理解阶段让 AI 帮你做翻译拿到需求文档之后我的第一步不是打开 IDE而是把需求描述丢给对话型工具让它帮我做三件事提取关键实体和关系需求里提到了哪些业务对象它们之间是什么关系列出需要变更的接口新增哪些接口修改哪些接口影响范围是什么生成待确认问题清单需求里有哪些模糊的地方需要跟产品确认这一步看起来简单但实际价值很大。因为需求文档往往是产品经理用业务语言写的而我要把它翻译成技术语言。让 AI 先做一轮翻译我再基于它的输出做修正比我从零开始想要快得多。举个例子之前有个需求是用户可以收藏商品收藏列表要支持分页和排序。我把这句话丢给 AI它帮我拆出了收藏关系实体用户ID、商品ID、收藏时间、收藏接口新增收藏、取消收藏、查询收藏列表、分页参数页码、每页数量、排序字段收藏时间、价格等。然后它自动生成了一份需要跟产品确认的问题清单比如取消收藏是物理删除还是逻辑删除收藏列表是否需要返回商品的最新价格。这些问题如果我自己想可能要花半小时AI 几秒钟就列出来了。当然它列出来的不一定全对但至少给了我一个起点。3.2 方案设计阶段用 AI 做方案对比需求确认清楚之后下一步是技术方案设计。这个阶段我会用对话型工具做一件事让它给我出至少两个方案并列出各自的优缺点。比如要实现一个商品搜索功能我可能会这样问当前项目技术栈是 Spring Boot MySQL Redis 需要实现商品关键词搜索数据量大约 50 万条 QPS 峰值预计 200。请给出两种实现方案 分别说明优缺点、适用场景和大致实现思路。AI 一般会给出类似MySQL LIKE 查询 索引优化和引入搜索引擎两种方案然后分别分析。我要做的不是直接采纳而是基于它的分析做判断。比如它可能没考虑到我们团队没有搜索引擎的运维经验或者没考虑到数据同步的延迟问题。这些就是我要补充的。这个阶段的核心价值不是让 AI 替我做决策而是帮我快速穷举可能性避免遗漏。很多时候方案设计的问题不是选错了而是根本没想到还有别的选项。3.3 编码实现阶段行内补全 对话式生成配合使用真正开始写代码的时候我的习惯是这样的第一步先写接口定义和核心逻辑的骨架。这部分我自己写因为它是整个功能的骨架决定了代码的结构和质量。我会写好方法签名、参数校验、核心分支逻辑但具体的实现细节留空。第二步用行内补全填充实现细节。比如我写了一个方法签名和注释行内补全就会自动提示实现代码。这时候我按 Tab 接受然后快速扫一遍逻辑对不对。不对的地方手动改。第三步用对话型工具生成辅助代码。比如 DTO 转换、单元测试、异常处理分支这些代码逻辑简单但写起来费时间直接让 AI 生成。这里有一个关键技巧给 AI 的提示词要包含足够的约束条件。不要只说帮我写一个查询用户的方法而要说帮我写一个根据用户ID查询用户信息的方法 要求 1. 使用 MyBatis-Plus 的 LambdaQueryWrapper 2. 如果用户不存在抛出 BusinessException错误码 USER_NOT_FOUND 3. 返回的 UserVO 需要脱敏手机号中间四位替换为**** 4. 方法上需要加 Cacheable 注解缓存 key 为 user:info:{userId}约束条件越具体生成结果越接近可用状态。我一般会从项目里找一个类似的已有方法连同提示词一起发给 AI让它参考风格。3.4 测试补全阶段AI 最被低估的使用场景说实话写单元测试是我以前最讨厌的事情。不是不会写是觉得重复劳动太多。但用了 AI 之后这个环节反而变成了我最省时间的环节。我的做法是写完一个类之后直接把整个类丢给对话型工具让它生成对应的单元测试。提示词大概是这样的请为以下类生成 JUnit 5 Mockito 的单元测试 要求 1. 覆盖所有 public 方法 2. 每个方法至少覆盖正常流程和异常流程 3. 使用 Mock 和 InjectMocks 注入依赖 4. 断言要具体不要只用 assertNotNull 5. 测试方法命名格式方法名_场景_预期结果生成出来的测试代码大概有 70% 到 80% 可以直接用剩下的需要我补充一些边界条件。但即使这样也比我手写快了三倍以上。注意AI 生成的测试用例有时候会假装覆盖了某个分支实际上断言写得很敷衍。我一般会检查每个测试方法的断言部分确保它真的在验证预期行为而不是只跑通不报错。3.5 Code Review 准备阶段让 AI 先帮你审一遍提交 MR 之前我会做一件事把 diff 内容发给对话型工具让它帮我做一轮预审。提示词大概是请 review 以下代码变更重点关注 1. 是否有空指针风险 2. 是否有线程安全问题 3. 是否有资源未关闭的情况 4. 是否有更简洁的写法 5. 是否有遗漏的异常处理AI 会列出一堆问题有些是误报有些确实是我疏忽了。我一般会把它提出的问题分成三类必须改的、可以改的、不用改的。必须改的就是真正的 bug 或隐患可以改的是代码风格优化不用改的是 AI 理解错了上下文。这一步帮我省了不少被 mentor 打回来的次数。因为很多低级问题在提交之前就被 AI 拦下来了mentor review 的时候就能聚焦在更重要的设计问题上。4. 上下文管理决定 AI Coding 效果的关键变量4.1 为什么你的 AI 总是答非所问用了几个月之后我发现AI Coding 效果不好的原因八成以上出在上下文管理上。具体表现有这几种模型生成的代码用了项目里不存在的工具类模型不知道项目已经有一个类似的方法重复造轮子模型对业务概念的理解和项目实际定义不一致对话轮次多了之后模型开始忘记前面的约束条件这些问题的根源都是一样的模型不知道它不知道的东西。它只能基于你给它的信息做推理你没给它的它就只能猜。猜对了是运气猜错了是常态。4.2 我的上下文管理三板斧第一板斧项目级上下文用规则文件固化。很多 AI Coding 工具支持在项目根目录放一个规则文件比如.cursorrules或类似的配置文件用来告诉模型这个项目的技术栈、代码规范、目录结构。我一般会写这些内容技术栈Java 17 Spring Boot 3.x MyBatis-Plus Redis 代码规范 - Controller 层只做参数校验和路由不写业务逻辑 - Service 层返回 DTO不返回 Entity - 所有异常统一用 BusinessException错误码定义在 ErrorCode 枚举中 - 日志使用 Slf4j关键路径打 info 日志异常打 error 日志 目录结构 - controller/ 接口层 - service/ 业务层 - mapper/ 数据访问层 - model/entity/ 数据库实体 - model/dto/ 数据传输对象这个文件写一次后面所有对话都会自动带上这些信息省得每次都要重复交代。第二板斧任务级上下文用精确引用。每次开始一个新任务的时候我会用符号精确引用相关文件。比如要改一个 Service 方法我会引用这个 Service 文件、它依赖的 Mapper 接口、相关的 Entity 和 DTO。不会把整个模块都引用进来。第三板斧对话级上下文定期清理。一个对话窗口不要用太久。我一般完成一个完整的功能点之后就开新对话。如果确实需要延续之前的上下文我会手动总结一下关键结论带到新对话里。比如之前我们确定了用策略模式实现多种支付方式 支付策略接口是 PaymentStrategy 已经实现了 AlipayStrategy 和 WechatStrategy 现在需要新增一个 BankCardStrategy。这样比让模型去翻几十轮之前的对话要可靠得多。4.3 上下文超限时的处理策略用代理型工具的时候经常会遇到上下文超限的问题。报错信息大概是context is too large或者maximum context length exceeded。遇到这种情况我的处理顺序是先检查是不是引用了不必要的文件。很多时候是不小心把整个目录都引用进来了。把大文件拆成小文件。如果一个文件超过 500 行考虑拆分。用摘要代替全文。对于不需要修改的依赖文件只给接口定义不给实现。分阶段执行。把一个大任务拆成几个小任务每个任务单独执行。提示代理型工具在执行多文件修改时会先把相关文件读进上下文。如果项目很大建议在规则文件里配置忽略目录比如 node_modules、target、.git避免把无关文件读进来。5. 那些让我效率翻倍的提示词技巧5.1 角色设定 任务描述 约束条件 输出格式我总结了一个提示词模板基本上所有场景都能套角色你是一个有 10 年经验的 Java 后端工程师 任务帮我实现一个商品收藏功能 约束 - 使用 Spring Boot 3.x MyBatis-Plus - 收藏关系存在 user_favorite 表字段id, user_id, product_id, create_time - 需要支持分页查询使用 MyBatis-Plus 的 Page 对象 - 取消收藏是逻辑删除用 deleted 字段标记 输出先给表结构再给 Entity、Mapper、Service、Controller 的完整代码这个模板的关键在于约束条件要具体到可以直接执行。不要说代码要规范而要说使用 MyBatis-Plus 的 LambdaQueryWrapper。不要说要考虑异常情况而要说用户不存在时抛出 BusinessException。5.2 用示例代替描述有时候用文字描述不清楚的事情直接给一个示例更高效。比如我想让 AI 按照项目现有的代码风格生成代码我会从项目里找一个类似的类连同提示词一起发过去请参考以下代码风格实现一个订单查询的 Service [粘贴一个已有的 Service 类] 现在需要实现的功能是根据用户ID和订单状态查询订单列表支持分页。这种方式比用文字描述代码风格要简洁、要有注释、要用 Lombok要有效得多。5.3 让 AI 先提问再回答这是一个很多人不知道的技巧在提示词里加一句如果你有不确定的地方先问我。这样 AI 在信息不足的时候会主动提问而不是瞎猜。比如我需要实现一个定时任务每天凌晨清理过期的优惠券。 如果你对清理规则、批量大小、失败重试策略有不确定的地方先问我。这样它可能会问过期是指超过有效期还是超过使用期限清理是物理删除还是标记删除单次清理数量有限制吗这些问题正好是我需要想清楚的。5.4 分步骤执行复杂任务对于复杂的任务不要指望一次对话就能搞定。我的做法是拆成多个步骤每一步确认无误后再进行下一步第一步让 AI 分析需求列出需要变更的文件清单第二步确认清单后让 AI 逐个文件生成代码第三步让 AI 生成对应的单元测试第四步让 AI 做一轮自查列出潜在问题每一步的输出都是下一步的输入这样既保证了质量也方便定位问题。6. 踩过的坑和对应的解决方案6.1 AI 生成的代码看起来对但跑不通这是最常见的问题。AI 生成的代码语法没问题逻辑看起来也合理但实际运行就是报错。原因通常是它用了项目里不存在的依赖或者调用了不存在的方法。我的解决方案是生成代码后先编译编译通过后再看逻辑。不要等到写完一堆代码再一起编译那样排查起来很痛苦。另外在提示词里明确告诉 AI 项目用的是什么版本的依赖能减少很多这类问题。6.2 对话轮次多了之后质量下降这个问题的本质是上下文污染。前面的对话里有一些错误的尝试、废弃的方案这些信息会干扰模型后面的判断。解决方案就是前面说的完成一个功能点就开新对话。如果必须延续手动总结关键结论。我一般一个对话窗口不会超过 20 轮。6.3 代理型工具自作主张改了不该改的文件用代理型工具做批量重构的时候它可能会顺手改一些你没让它改的文件。比如你让它重命名一个方法它可能把相关的注释、文档、甚至测试代码都改了。解决方案是执行前先让它列出计划修改的文件清单确认后再执行。大部分代理型工具都支持dry run模式先看它打算做什么确认无误再让它真正执行。6.4 过度依赖 AI 导致自己能力退化这个问题比较隐蔽但影响深远。我有一段时间什么都让 AI 写结果发现自己对某些基础 API 的记忆越来越模糊遇到问题第一反应是问 AI 而不是自己查文档。后来我调整了策略核心链路的代码自己写辅助代码交给 AI。比如涉及金额计算、权限校验、状态流转的代码我一定自己写写完再让 AI 帮我 review。这样既保证了代码质量也保持了自己的技术敏感度。7. 一些零散但实用的经验关于工具选择我的建议是不要贪多。行内补全、对话、代理三类各选一个用熟就行换来换去反而浪费时间。我目前用的是 IDE 自带的行内补全 一个对话型工具 一个命令行代理工具基本覆盖了所有场景。关于提示词不要追求完美提示词。我见过有人花半小时写一个提示词就为了让 AI 生成一段 20 行的代码。有那个时间自己都写完了。提示词够用就行生成结果不满意就补充约束条件再来一轮比一次性写一个完美提示词要高效。关于学习成本AI Coding 工具的学习曲线其实很平缓但有一个前提你得先会写代码。如果你本身对编程不熟悉AI 生成的代码你无法判断对错那用起来反而更危险。我的建议是先把基础打牢再把 AI 当成加速器而不是替代品。关于团队协作如果团队里有人不用 AI有人用 AI代码风格可能会不一致。我们团队的做法是在规则文件里统一了代码规范不管是不是 AI 生成的代码提交前都要过一遍 Checkstyle。这样至少保证了风格统一。最后分享一个我最近在用的技巧让 AI 帮我写 commit message。提交之前把 diff 发给它让它按照 Conventional Commits 规范生成 commit message。这个虽然是小事情但积少成多也省了不少时间。而且它写的 commit message 往往比我手写的更规范因为我会偷懒它不会。