提到 AI Coding很多校招生第一反应是“装个 Copilot 自动补全”。但真正把 AI 接入完整开发流程显然不是这个工作量。我去年以校招生身份进了一家互联网公司负责过一块支付相关的后端系统。最开始我也只会在 IDE 里用补全写几个工具函数后来经历了好几个迭代慢慢把 AI 用到了需求拆解、技术方案、编码、测试、评审、故障排查的各个环节形成了一套可以复用的工作流。这篇是我个人的真实操作记录不一定适合所有团队但思路对刚入行的朋友应该有点参考价值。先说结论AI Coding 工作流的本质不是把键盘交给 AI而是把 AI 放进一个你随时能监控的流水线里。它的价值在于“什么时候用、什么时候坚决不用、用了以后怎么验证”这三个问题想清楚比抄一百条提示词都有用。1. 先认清一件事AI Coding 工作流不是“装个插件”很多新人以为接入 AI Coding 就是“IDE 里装个插件然后让它自动补全”。我一开始也这么干结果确实收获得了一些快乐但代码里埋的雷也一点没少。后来我才意识到工具本身不会改变流程只有流程重新设计后工具才会产生真正的杠杆效应。1.1 校招生最常犯的三种误用姿势在带过几个实习生、也观察了新来的校招同事之后我发现最常见的三种误用姿势把 AI 当正确答案生成器。遇到不理解的需求先让 AI 写代码跑出结果合入然后被 Code Review 追问“为什么这么设计”时完全答不上来。只在赶工时才打开 AI。平时基本手写DDL 前复制一坨需求发给 AI让它一次性生成结果质量惨不忍睹。完全不给 AI 上下文。把一个新的接口需求直接丢给 AI生成出来的代码引用了不存在的类、不符合公司规范、甚至把产品逻辑理解歪。这三种姿势背后是同一个问题没有想清楚 AI 在流程里的角色。它不是评审不是负责人也不是替你背锅的而是一个“执行速度很快、但需要严格验收的同事”。它擅长的是把明确的、上下文充足的小任务快速做完不擅长的是在没有细节和边界的情况下闭门造车。所以我在自己的开发流程里给 AI 定的角色是高级代码助理。它负责初稿、补全、检索、翻译、单测生成、文档草稿我负责需求理解、架构决策、代码审查、最终验收。角色定义清楚了后面所有环节都好设计。1.2 工作流的本质是边界划分有一段时间我特别痴迷于让 AI 做“端到端”。比如直接说“帮我实现一个秒杀系统”然后它真的生成了一堆 Controller、Service、Mapper。表面上看有模有样真正跑起来发现事务边界、幂等、缓存一致性全都没有思考。这个过程让我明白AI 能写“代码”但不负责“软件设计”。设计里最重要的权衡比如数据一致性、调用链路、异常处理策略需要人自己用脑子定。边界划分说起来抽象落到实际就是一张决策表环节我做什么AI 做什么需求阶段澄清业务规则搜背景资料、列问题清单方案阶段定架构和接口对比不同技术方案、找坑编码阶段设计核心函数、定边界补全、生成样板代码、重构测试阶段定关键业务场景生成单测、造测试数据修复阶段判断根因复现、打日志、跑分析文档阶段审核准确性生成初稿、整理格式这张表不是一成不变但每次我“越界”让 AI 承担太多判断责任时后果基本都是返工。AI 判断错了不会承担责任最终负责的还是人。研发流程里责任链是不能被外包的这是必须坚持的底线。1.3 我最终把 AI 放在这五个环节上经过几轮迭代我把 AI 固定在五个环节需求拆解、方案预研、编码助手、测试生成、故障辅助。五个环节分别对应前面说的高效辅助场景。需求拆解用来把 PRD 里的自然语言翻译成开发任务它最大的价值是帮忙问出我可能忽略的问题。方案预研用来比较同一需求的不同实现思路列出优缺点、成本、风险点快速生成分析文档。编码助手用 Copilot 之类做行级补全用 Cursor、Claude Code 做文件级重构和跨文件修改。测试生成根据业务规则生成大量边界测试、异常用例和 Spring 单元测试骨架。故障辅助出现线上问题时喂日志和报错信息让它快速定位可能的根因给出排查路径。这五个环节不是每天都用但它们覆盖了完整开发流程的主要入口。把这五个环节跑顺了AI 才算真正“接入”了流程而不是游离在 IDE 之外的玩具。2. 完整工作流长什么样下面按项目阶段展开讲我在每个节点具体做哪些事。重点不是“用了哪个工具”而是每一个步骤的输入、输出和验收方式。2.1 需求阶段用 AI 做背景调研和方案预研大厂的需求往往有成熟业务背景。我刚接手支付模块时根本不明白“支付路由”“对账”“退款幂等”这些词是什么意思。这时候我会先把 PRD 里不认识的词、不清楚的约束列出来贴给 AI让它结合常见行业背景做解释并列出与技术实现相关的风险点。比如有一次需求是“给优惠券增加一种阶梯折扣规则”我先让 AI 帮我理几个问题阶梯折扣是否允许追加或修改、折扣是否与其它优惠叠加、退款时阶梯折扣怎么计算、极端情况下是否可能造成负价。它会基于提示词给出一份清单里面有一部分是它猜的但我可以再拿去业务会议上核对。这帮我少犯了很多“需求没看清就写代码”的错。这里要注意AI 不了解你们公司的特定业务规则它输出的“业务背景”是不能直接当需求的必须人工确认。我会在提示词里明确写“这些只是假设请重点标注不确定项”然后把不确定项带进需求评审。2.2 设计阶段让 AI 当“挑刺的评审”设计方案时我通常先自己画一版架构草图包括模块划分、接口定义、数据模型然后交给 AI 做反向质疑。做法很简单把设计文档贴给它要求它列出“你会从哪里攻击这个设计”尤其是异常场景、性能瓶颈、扩展性、安全边界。比如设计一个新订单状态机AI 会指出重复的异步回调怎么办、状态回跳如何阻止、超时任务如何补偿、多个状态更新并发时是否会出现幻读。这些问题有些是我没想到的有些是大而空的但它的“不提建设性意见只负责挑刺”的能力很适合当设计评审的初筛。我最开始差点跳过这一步觉得 AI 压根不懂分布式系统。后来发现它虽然不懂我们内部的注册中心和配置中心但对通用概念幂等、分布式锁、消息顺序的引用很到位。只要在关键决策上再拉一次评审这个预评审环节能帮我省掉很多来回改的会议。2.3 编码阶段生成、补全、重构、Diff 检查怎么分工编码阶段我把工具分成三个角色行级补全适合写模板代码、getter/setter、简单的参数校验。我用 GitHub Copilot在输入注释和函数签名后补全体验最顺滑。文件级生成适合生成 Mapper 接口、Service 实现、单元测试这些边界清晰的文件。此时我用 Cursor 或 Claude Code给出目录结构和类路径生成整体骨架。跨文件重构适合调整关联关系、抽公共类、调整事务边界。用命令行工具配合 grep 定位引用点先跑编译再让 AI 改。开发过程中最容易犯的错误是让 AI 一次修改多个文件但没有任何验证步骤。我的习惯是每次给它一个“原子任务”比如“只新增一个接口方法”“只抽取小工具类”“只修复一个具体 bug”改完立刻编译加跑关联测试。完成后人工逐条看 diff再继续下一个任务。2.4 测试阶段AI 生成单测和用例设计单测是我最愿意让 AI 做的环节。给一份业务类的输入输出规则AI 能很快生成正常路径、异常路径、边界值、并发异常等用例。我尤其喜欢让它生成测试数据构造器一个复杂的订单对象手动 new 起来太麻烦让 AI 根据对象结构生成 builder 或 fixture能省不少时间。但测试生成也有坑AI 经常“自问自答”地把被测代码里轻微的逻辑错误复制进测试断言导致测试和实现同错。所以我会先手写一个最关键的正向用例作为锚点再让 AI 补全其它用例。关键断言我会认真验收绝不直接全盘接受生成结果。2.5 评审与文档AI 帮你补上下文Code Review 阶段AI 最大的价值是“解释代码”。团队里新接手的模块历史逻辑很多人讲不清楚。我发现让 AI 读一遍 diff让它解释“这段改动会影响哪些调用方、是否违反了现有约定”能提前发现很多问题。文档也类似。每次迭代结束我会把完整的接口定义、业务流程、定时任务、配置项清单喂给 AI让它生成一份更新后的文档初稿。我只需要核对技术细节不用从零开始写。互联网团队最烦文档过时这个习惯至少让我负责的模块文档一直保持可用状态。3. 实操记录五个高频场景和提示词模板这部分是全文最实用的一节我直接写出我会怎么操作以及对应的提示词模板。你可以把它们当成起点再按自己团队规范改成长期可复用的版本。3.1 给一坨 legacy code 加新功能这是校招生最容易遇到的事。模块代码写了很多年没有足够注释测试还少。我一般分三步第一步收集代码上下文。我会先把相关文件的目录结构、类关系、方法签名和调用链整理出来。手工整理太慢可以直接用rg快速定位引用然后喂给 AIrg -n class CouponService|applyDiscount|calculatePrice --type java第二步给 AI 定义任务。示例提示词你是一个 Java 后端工程师。仓库根目录在 /workspace/order-server。 背景现有优惠券模块支持满减和折扣现在要新增阶梯折扣规则。 约束 - 遵循项目现有包名和风格不要改公共接口签名 - 新增逻辑尽量收敛在 coupon 包内不要影响其他模块 - 先列出实现计划再写代码 - 生成后补充单测覆盖阶梯折扣临界值 请先读取 CouponDomain.java、CouponServiceImpl.java、CouponMapper.xml 这几个文件然后给出修改步骤。第三步让 AI 先给计划再给代码。我一般要求它“先列实现计划”这样我能快速判断方向是否正确避免它一上来就把代码写歪。如果方向不对我只需要改一下计划而不是看一堆废代码。3.2 快速定位线上问题线上异常排查我通常会把错误堆栈、相关配置、最近改动 commit 列表喂给 AI。操作上我不会直接问“这是咋回事”而是让它按我的排查框架输出。先让 AI 整理现象这是一个支付回调处理异常 堆栈... 最近改动文件... 期望重复回调应幂等返回。 请帮我把现象归纳成已确认的信息、待确认的信息、可能的根因、验证步骤。这种输出比直接让它“找 bug”靠谱得多。AI 很难替你推理出真正根因但你可以借助它帮你排列排查方向。有一次我排查 RabbitMQ 消费重复问题AI 给出的“确认是否重试导致消息积压”“检查消费线程池是否共用”“确认确认模式是否手动”三个方向里第二个真的命中了。3.3 写单测用例核心提示词给下面的 Service#calculateCouponPrice 写单测要求 - 使用 JUnit5 和 Mockito - 覆盖无优惠、满减边界、阶梯折扣边界、优惠券失效、库存不足异常 - 断言要具体数值或异常类型 - 不要生成无意义测试方法写单测时我特别强调“断言要具体数值”因为 AI 生成测试时经常会用isNotNull()这类无效断言测试虽然过了但什么都验证不了。一个assertEquals(19.9, result, 0.01)比十个assertNotNull有价值得多。3.4 重构前梳理依赖关系重构有风险的代码我先让 AI 用“静态分析 解释”的方式梳理影响面分析 RefundService 类中所有 public 方法的调用方和依赖关系。 输出格式 1. 类被哪些服务调用 2. 方法被哪些接口引用 3. 是否有循环依赖 4. 改动返回值或加参数时的影响范围 请基于当前仓库的代码搜索不要臆测。这一步相当于让 AI 当一个不会漏看的静态分析工具。它虽然可能漏掉通过反射调用或 XML 配置里的初始化逻辑但结合rg和 IDE 的 call hierarchy能覆盖大部分场景。有时候它还会主动提示“这个类在 Spring 上下文里被多个构造器注入”这对我重构很有帮助。3.5 生成接口文档我常用 AI 把代码转成文档请阅读 OrderController.java 和 OrderApi.java基于代码生成 OpenAPI 风格的接口文档。 要求 - 说明每个接口的作用、参数类型、必填项、返回码 - 补充幂等性要求 - 输出 markdown 表格便于插入内部 wiki生成的文档虽然不能直接当作对外契约但作为内部沟通初稿已经足够。更关键的是当接口调整时重新让 AI 同步一次能显著减少文档滞后。有了初稿再去做人工核对效率会高很多。4. 核心避坑上下文、Token、幻觉与安全底线这四个问题是 AI Coding 真正落地的四个门槛。只看重“代码生成速度”的老司机也绕不开这些坑。4.1 上下文窗口不够用怎么办大模型上下文再大也有限。我处理长文档或者大仓库时不会一次性把所有代码都贴进去。我通常这么做用rg先缩小范围只把相关文件的类和关键方法提取出来。使用工具自带的“读取指定文件”“搜索符号”能力而不是把所有源码堆进去。把一个大任务拆成多轮第一轮生成方案第二轮聚焦实现。如果遇到超过模型的记忆长度让 AI 输出“摘要 建议下一步”再基于摘要继续。举个例子修改一个跨模块的状态机我只会贴状态机定义、主要 Service、数据库表结构而不是把整个老项目的 100 个类都喂进去。上下文少模型注意力反而更集中结果通常更干净也更容易审查。4.2 生成代码不等于可合并代码必须过静态检查我们公司有严格的门禁Checkstyle、SpotBugs、单测、覆盖率、编译、打包一条龙。AI 生成代码后我第一件事不是提交也不是用 IDE 肉眼扫一眼而是先跑本地增量编译和静态检查工具。很多时候 AI 生成的 import、异常处理、可空性注解会引一堆编译错误或规范违规。我遇到最多的三类静态检查问题没有处理受检异常、可空性校验缺失、魔数没有定义为常量。这些靠 AI 自己生成时很容易踩坑但用静态检查规范一约束再让 AI 按规范修改就能快速收敛。动作建议进入一个新团队先把公司的 checkstyle 规则文件、代码格式化配置找到配置进 IDE再让 AI 生成代码时把规则摘要贴在提示词里。4.3 防幻觉重要改动先写测试再实现AI 最常见的问题不是“不会写”而是“一本正经地胡说八道”。它可能生成一段能编译但逻辑完全错的代码。要防止这一点最有效的办法不是让它写得更认真而是让测试先行。比如一个重要的价格计算函数我会先用自然语言描述输入输出样例让 AI 快速生成一个最小实现再让我写几个关键断言比如assertEquals(19.9, couponService.calculatePrice(20, DISCOUNT_10), 0.01); assertEquals(15.0, couponService.calculatePrice(30, STEP_DISCOUNT), 0.01);如果 AI 跑不通过这个断言说明它理解错了。校验通过至少核心逻辑是可信的。我几乎所有的核心算法、状态机迁移、金额计算都采用这种“先锚定断言再生成实现”的方式。4.4 安全保密内网数据坚决不能上传这一点不是废话而是实际生产中必须遵守的红线。公司的商城数据、内部接口、供应链价格信息都不能随意粘贴到外部 AI 服务里。我在大厂第一课就被反复教育不能为了图省事把真实代码上传到没有审批的外部 AI 工具。如果团队允许我们可以使用公司内部部署的大模型网关如果没有那就只能把代码脱敏类名、字段名、常量值替换成通用名日志和堆栈里的真实上下文也处理后再说。这也是为什么前面所有提示词模板里我都会强调“代码路径”“类名”而不是完整源码的原因之一——能用检索工具让 AI 读仓库就不要手动复制粘贴内网源码。5. 我踩过的几个坑和排查方案写这些不是为了展示“我很厉害”而是希望大家少走弯路。很多问题不是 AI 不行而是使用方式不对。5.1 提示词没写约束代码风格全乱刚开始我用 AI 写代码直接说“帮我写一个通用的 xx 工具类”结果生成了 Stream 加 Lambda 的写法和团队长期使用的 for 循环风格完全不同。代码评审直接被打了回来。后来我把团队编码规范的关键条目直接写进提示词比如“禁止多重三元表达式”“变量命名用驼峰”“集合操作按团队约定选择 for 循环或 stream”生成质量明显改善。建议不要把规范写在只用一次的提示词里把常用规范沉淀成一个团队共享的code-guideline.mdAI 生成时直接读这个文件作为参考。5.2 看起来正确但漏洞满满的代码有一次让 AI 帮忙写一个“金额格式化”工具它生成了一段看似正确的 BigDecimal 处理代码结果没有考虑负数、没有处理精度溢出的情况。这种问题在视觉上很难发现只能靠测试和评审兜底。现在涉及金额、时间、并发、加密的逻辑我都强制要求 AI 在代码里显式写出异常路径和边界条件另外绝不把金额计算类核心代码直接合入必须过一遍同事评审。5.3 AI 生成大量无用测试CI 越来越慢有一段时间我图省事让 AI 一次性给一个 Service 生成三四十个测试方法看起来覆盖率上去了但很多都是复制粘贴的无效测试CI 时间直接从 10 分钟涨到 30 分钟。后来我清理了无效用例只保留围绕业务规则的边界用例并把“最小有效测试”写进提示词。现在我会明确要求 AI 生成测试前先列“用例设计表”我确认后才生成代码。这样既能保证覆盖面又不会让测试仓库变成垃圾堆。5.4 重构时把切面和依赖注入改丢了这是我踩过最痛的一次坑。让 AI 重构一个类把原先的Transactional、Cacheable切面全部弄丢了因为它在重构时只关注业务方法本身完全没想到这些注解是保证正确性的关键。从那以后重构任务里我会在提示词中强制要求“保持原有注解、事务边界、缓存策略不变”并让它在方案里明确列出哪些注解会被保留。5.5 自动补全越想越离谱我没保存就回滚了关于行级补全我也遇到过“补全越写越跑偏”的情况。如果发现它开始缩小范围只改局部而不是整体推进我会立刻停掉重新用更明确的任务描述。很多时候是因为我没有提供足够类型信息它只能靠猜。补全不应该被当成“自动把整段逻辑写完”而是应该在已有强类型、明确接口签名时填平实现细节。6. 工具选型与配置参考最后说说工具选型。这部分比较主观我讲讲自己的选择依据而不是给你一份“必装清单”。6.1 常用 AI Coding 工具对比工具优势劣势我的使用场景GitHub Copilot行级补全快IDE 集成好跨文件理解弱写样板代码、函数实现Cursor文件级修改强支持多文件上下文需要导入项目不能直接复用公司内部代码库看代码、改功能、小重构Claude Code命令行强适合仓库级任务需要合理控制 token 消耗跨文件重构、整理代码通义灵码中文直觉好国内部署友好大型仓库上下文有限写文档、学习新代码Codex CLI和 Git 仓库绑定方便偶尔上下文超限快速生成 branch 级改动注意这不是绝对推荐取决于团队允许使用哪些工具。重要的是明确“这个工具适合这个场景”而不是“哪个工具最强”。6.2 我的配置建议IDE 里开启行级补全和自动 import关闭“自动接受多行补全”避免大段错误代码写进当前文件。命令行工具设置 diff 模式每次修改生成独立 diff不允许直接覆盖原文件。把code-guideline.md放在仓库根目录提示词里让 AI 优先读取。能连公司内部模型网关就尽量走内部通道没有就做脱敏处理。把 token 消耗控制在合理范围优先让 AI 读文件不复制粘贴每个子任务限定输出长度。6.3 一个小项目从零开始的启动顺序示例结束之前我放一个纯示例的“AI 工作流”启动顺序适合第一次尝试的人参考用git clone拉仓库用rg找到需求涉及的核心文件。在 IDE 里打开 Cursor 或 Copilot先让 AI 勾出核心类的结构。让 AI 根据需求列出实现计划明确模式、接口变化、测试点。逐模块实现每次修改后mvn compile或gradle build验证。让 AI 生成单测并“人工锚定断言”。提交前运行 checkstyle、spotbugs逐条修复。用 AI 生成本次变更说明附到 MR 描述里。这一套下来整个流程中的人工决策点没有增加太多但每一轮的 AI 输出都有明确的验收方式不会变成失控的黑盒。7. 最后分享一点个人体会我自己用 AI Coding 大半年最大感受是它真正解决的是“打字速度”和“资料检索”的问题不是“思考速度”的问题。对一个刚入职场的校招生来说最重要的不是会多少提示词技巧而是能在 AI 面前讲清楚需求边界和验收标准。你越能清晰描述任务AI 越能成为一个靠谱的执行者你越模棱两可它越可能在底层细节上给你挖坑。如果你刚进公司建议从一个小模块开始练手先手动实现一次再用 AI 重构一次对比两份代码的差异慢慢积累出适合自己团队的提示词风格和工作流。时间长了你会发现AI Coding 不是玄学它更像一个能力很强但需要调度得当的队友。