先交个实底我是一年前入职一家互联网公司做后端开发的校招生。刚进组那阵子熟悉的业务还没跑明白身边同事聊得最多的却是 AI Coding。一开始我也把 AI 当高级搜索引擎用——报错贴进去、让它生成一段代码、再复制到项目里跑。结果三个月里有大量时间花在“填 AI 挖的坑”上。后来在组里一位导师的提醒下我开始重新搭自己的开发流程不是让 AI 偶尔插一脚而是把 AI Coding 作为工具嵌到需求分析、技术方案、编码、自测、提交和 Code Review 等环节里逐步形成了自己每天都在跑的一套工作流。这篇文章就把这套工作流的拆解思路、工具配置、完整实操和踩坑记录都写出来适合刚接触 AI 编程的应届生也适合想把 AI Coding 落到日常开发里的团队参考。1. 先把 AI Coding 从“工具思维”升级成“流程思维”1.1 我踩过的第一个坑把 AI 当搜索框用刚入职时我的典型用法非常朴素遇到编译错误直接把报错信息丢进对话窗口写某个工具方法先描述需求让 AI 给我一段能跑的函数联调崩了把整段堆栈贴过去让 AI“分析原因”。前几周确实觉得效率有提升毕竟省去了自己在网上翻答案的时间。但到了第二个月问题就出来了AI 给我的代码经常“能跑但不对”修好 A 点又冒出 B 点尤其是老项目里的隐式约定AI 完全不知道。后来我慢慢意识到问题不在 AI 模型本身而在我用它的方式。搜索框是“你要什么它给你找什么”但完整开发流程里的大部分任务不是“找”而是“从一个工件产出下一个工件”。需求文档要变成改动点清单改动点清单要变成接口设计接口设计要变成可编译的代码代码要变成测试用例和提交说明。每一步都有明确的输入、输出和校验标准。AI 只有被放到这些具体岗位里才知道该关注什么、该输出什么。“角色化”这个词在 AI Coding 圈里已经被说滥了但放在工作流语境里它其实意味着给 AI 划定边界它才可能稳定输出。这一个转变对我这种应届生尤其重要。应届生最大的误区是让 AI 替我做决定比如“给我设计一下订单导出的方案”。AI 会给你一份看着很专业的方案但它不了解系统的瓶颈在哪、团队的技术栈偏好是什么、历史包袱有哪些。你应该自己做技术决策让 AI 帮你把决策落到文档、代码和测试里。它处理的是执行密度不是判断责任。1.2 完整开发流程里 AI 的六个固定岗位我给自己搭的这套工作流里AI 承担的是六个相对固定的“岗位”。这里用岗位这个词是因为它强调的是边界每个岗位只做一类输入到一类输出的转换。这样设计的好处是每份 AI 产物都是独立的小单元出了问题很容易定位也方便在不同粒度上加入人工校验。流程环节AI 负责什么典型指令片段输出产物需求解读把 PRD 转成改动点清单和疑问清单“列出涉及的表、接口、潜在风险”需求分析.md技术方案基于现状生成候选方案和取舍分析“给出两种方案并比较改动范围”方案对比文档编码实现按约束生成接口、DTO、单测骨架“只实现这个方法不改其它文件”可编译的代码 diff自测辅助生成边界用例清单、推断日志根因“列出 10 个边界场景并排序”自测点记录提交辅助根据 diff 生成 commit message 和 MR 描述“按约定格式改写 commit”提交说明文本Review 预检扫描空指针、资源泄漏、异常吞噬等“给出 blocker/major/minor 列表”预审问题清单把 AI 固定到这些岗位之后我的使用逻辑就从“我遇到问题 → 问 AI”变成了“我走到某个流程节点 → 把当前节点需要的材料和约束交给 AI → 人工校验产物 → 进入下一节点”。这样做还有另一个很实际的好处每个 AI 产出的质量都被限定在一个很小的范围内不会出现 AI 在某个隐藏角落帮你改了另一个模块的代码这种事。需要说明的是业务规则确认、技术取舍、对外承诺这类需要“人做判断”的节点我没有放进上面任何一行。AI 擅长从已知信息里做归纳和生成但不具备对业务环境的真实感知。判断权留在人手里执行委托给 AI这套流程才算成立。2. 工具链分工编辑器、对话模型、仓库规则各管一段2.1 编辑器内补全型 AI让注释先于代码我日常的主力环境是 JetBrains 系 IDE也会用 VS Code 处理一些轻量脚本。不管用哪款编辑器补全型 AI 的行为逻辑都是类似的它根据你光标前的代码上下文预测下一段内容。GitHub Copilot、通义灵码、CodeGeeX 这类插件我都先后用过团队里甚至有基于内部大模型封装的公司内版本实测下来决定补全质量的往往不是模型而是你给它的上下文质量。我养成的第一个习惯是“注释先行”。以前写代码是先写函数名再靠补全硬猜后来改成先写一句清晰的注释描述意图再写函数签名让 AI 顺着注释补全实现。比如我想写一个订单筛选方法// 从 orderList 中筛选出 status1 的订单按 createTime 倒序返回前 10 条 public ListOrder filterTopOrders(ListOrder orderList) {这行注释把数据来源、过滤条件、排序规则、返回条数全部讲清楚了补全出来的实现通常比“光给个函数名”靠谱得多。原理也好理解补全模型本质上在做概率预测注释相当于把预测空间缩小到了你的真实意图附近。第二个习惯是分段接受。如果补全一次性冒出 20 行以上我不会直接 Tab 全收而是先扫一遍关键位置import 有没有引入多余依赖、返回类型和 null 处理是否符合团队规范、异常有没有被吞掉。很多翻车现场都是“一键接受大段代码”造成的因为模型会在你不注意的角落塞进一个不存在的 API 或者一个不符合项目规范的条件判断。第三个习惯是“注释里的约束要写死”。比如“不要改方法签名”、“不要新增依赖”、“错误码用统一枚举”这些约束写进注释或 prompt 后AI 的输出质量会显著上升。它本质上是在告诉模型你可以自由发挥的空间只有这些。边界越清晰产出越可控。2.2 对话式 AI上下文不是越多越好对话式 AI 是我的第二类主力工具用来做方案讨论、代码审查、日志分析和文档生成。工具选择上我比较常用的是 DeepSeek、Kimi、通义千问这类国产模型不同阶段的版本能力差异很大但真正影响效果的从来不是模型排名的细小差距而是上下文怎么组织。新人最容易犯的错是把上下文当成“越多越聪明”一上来就把整个项目目录贴进去。实际体验是上下文窗口变大之后模型反而更容易被无关信息干扰回答也会越来越“泛”。我现在的原则是“一次只喂一个任务的必要信息”。比如分析一段代码只贴相关的方法、调用点和异常栈写一个功能只贴接口字段清单和必要约束做技术方案对比把现状的核心类结构贴进去就够。控制在几百行代码以内比贴一大坨动辄几千行的业务代码要稳定得多。另一个很实用的做法是“让 AI 先说假设”。在我给 AI 下任务时会加一句“如果没有外部依赖你基于哪些假设先列出假设再给代码”。为什么有效因为模型的很多错误输出都来自它脑补了不存在的依赖和常量。让它先把隐性假设显式化等于给了你一次人工纠偏的机会。比如它假设“Order 对象存在 getStatus() 方法”如果实际没有你可以马上在下一轮纠正而不是等到代码编译失败才发现。我还维护了一个docs/ai-agents.md文件本质上是给 AI 的协作说明书。里面写着这个仓库的语言版本、禁止使用的语法、命名规范、错误码规范、常见依赖列表。每次新建对话处理编码任务我会把相关片段贴进去。模型没有持久记忆把约定外置到文件里比每次重复解释高效得多。3. 一次真实需求的完整实操从 PRD 到 MR 全程接入 AI这部分是全文最核心的实操记录。我以一个实际做过的“订单导出优化”需求为例把整条链路上 AI 参与的节点一步步拆开。这套方法不一定适用于所有项目但思路是通用的每个开发节点都给 AI 定义输入、输出和校验点。3.1 需求阶段让 AI 先把 PRD 变成任务草稿拿到需求后我不会直接开写代码而是先自己读两遍 PRD把业务目标记在脑子里。然后打开对话窗口粘贴需求的关键描述让 AI 帮我产出“改动点清单”。我当时的 prompt 是这样的去掉了具体业务字段需求订单列表页的导出功能需要在 30 秒内生成文件 文件超过 50MB 时自动拆分打包。 请基于以上描述列出 1. 可能涉及的数据表和服务 2. 前端调用点的改动 3. 后端接口或配置的改动 4. 潜在风险性能、并发、存储上限。 每条尽量给出原因不要只给结论。AI 输出了一份带原因的清单但我的处理方式是把它当“草稿”而不是“报告”。因为 AI 不了解我们这个订单系统的历史设计它列出的很多“可能涉及”需要我拿着清单在代码库里逐条验证。比如它提出“可能需要加订单归档任务”但我们系统已经有一个 weeklyArchive 任务这个点就需要修正。把 AI 的输出落成一份带 checkbox 的requirement_analysis.md逐个勾选确认这一步就完成了。经验是越早把 AI 介入到需求解读后面写代码时的返工越少。但千万不能直接拿 AI 的分析结果去开评审会它漏掉业务上下文是常态人审是刚需。3.2 编码阶段先定接口和数据契约再让 AI 补实现到了编码环节我的顺序不是“让 AI 直接生成整个类”而是先从最小的数据契约开始。第一步我自己写下接口和关键字段的文字描述。例如订单导出模块我先定义一个轻量接口字段含义都写在注释里public interface OrderExportService { /** * 按时间范围导出订单到 Excel 文件。 * 返回文件相对路径。 * 查询结果为空时抛 BizException(ORDER_EXPORT_EMPTY)。 */ String exportOrders(String bizId, Date startTime, Date endTime) throws BizException; }第二步让 AI 按接口注释补全实现。prompt 里我会把范围卡得非常死请实现 OrderExportService 接口中的 exportOrders 方法要求 - 查询使用 orderQueryMapper.selectByTimeRange(bizId, startTime, endTime) - 分批查询每批 500 条防止内存溢出 - 文件写入 /tmp/order_export/文件名包含 bizId 和时间戳 - 查询结果为空时抛出 BizException错误码 ORDER_EXPORT_EMPTY - 只能修改 OrderExportServiceImpl.java不要改动其它文件 - 不要引入任何新的第三方依赖。这种 prompt 的写法有四个关键点确定了数据来源、确定了分批粒度、确定了输出位置、锁死了改动范围。AI 在这些约束下产出的代码基本能直接进 MR diff剩下的是看它有没有处理并发下的文件名冲突、Excel 大文件流关闭之类细节。第三步是测试约束。我试过两种顺序先让 AI 写实现再补测试和先让 AI 写测试再写实现。实测下来后者的幻觉明显更少。让 AI 先产出 5 个测试用例空结果、正常导出、时间区间倒置、并发调用、路径非法我再把这些用例补成可运行测试然后让 AI 基于测试反馈修改实现。测试先行本质上是把“正确性”拆成了可验证的小步AI 每走一步都能看到边界在哪。3.3 自测与联调阶段让 AI 处理日志和边界场景联调阶段最耗时间的往往不是写代码而是日志分析。以前我拿到异常栈第一反应是搜索报错文案后来改成把关键异常栈和相关代码片段一起贴给 AI让它按概率排序可能原因。举个真实例子当时导出大文件时出现java.lang.OutOfMemoryError: Java heap space。我没有把整页日志倒进去只贴了异常栈顶部和OrderExportServiceImpl中处理文件写入的核心片段然后问以下是异常栈和相关代码。请按可能性从高到低列出原因 并针对每种原因给出最小验证方案。AI 给出的原因排序是分批查询但汇总到内存时溢出了Excel 写入未使用流式模式导出文件对象持有过大。验证方案里最有用的两点是看堆转储确认大对象以及用流式写入模式替换普通写入。我按顺序排查最后确实命中了流式写入缺失的问题。这个过程省掉的不只是搜索时间更重要的是它给了我一个验证路径而不是让我在日志里瞎猜。自测环节我还会让 AI 生成一份“边界用例清单”。比如对 exportOrders 方法要求它列出 10 个边界场景并排序空结果、时间区间倒置、并发调用、文件名冲突、磁盘空间不足、结果集超过内存等等。这份清单既可以直接转成测试用例也可以当作自测记录的模板。我在实际执行过每一项之后会把结果贴进 MR 描述里作为自测证据。3.4 合入前commit message、MR 描述和 AI 预审开发完成不代表工作流结束。我在提交阶段会做三件事全部有 AI 参与但全部有人的确认。第一件是让 AI 根据git diff生成 commit message。我有一个团队约定的格式type(scope): subjectprompt 这样写以下是 git diff。请按约定格式生成 commit message 格式 type(scope): subject type 可选 feat/fix/refactor/test/docs subject 用中文动词开头不超过 30 字。 只输出一行 commit message不要解释。AI 产出的通常是feat(order): 订单导出支持按时间范围过滤这类规范结果极大的减少了我咬笔杆的时间。但我会在真正执行 commit 前自己过一遍确认它描述的改动和 diff 一致。第二件是生成 MR 描述。我会要求 AI 按“变更背景 / 改动点 / 影响面 / 自测结果 / 风险自查”五个段落来组织其中“自测结果”留白由我填。这一步容易踩坑的地方是 AI 会自动虚构“已通过测试”这绝对不行。MR 是整个团队 Review 时看的门面虚假描述会让人失去信任。第三件是 AI 预审。我会把整段 diff 交给 AI让它重点扫描空指针、资源未关闭、异常被吞掉和事务边界这四类问题并输出带优先级的清单请作为 Java 代码评审员审查以下 diff 逐条检查 - 是否存在空指针风险 - 资源IO、JDBC是否都被正确关闭 - 异常是否存在被吞掉或包装过粗的情况 - 事务边界是否合理 每条建议标注 blocker / major / minor。AI 预检结果我会当作“待办清单”处理blocker 全部修复major 大部分修复并说明minor 选择性记录。这个预检替代不了人工 Code Review因为业务语义、架构方向这类问题 AI 看不到但它能先帮我们把低级问题过滤掉人工 Review 就可以把时间花在真正有判断量的地方。4. 踩坑实录应届生把 AI 接进开发流程最容易翻车的几个场景4.1 幻觉代码AI 一本正经地编造 API第一个最典型的坑是幻觉。刚接入 AI 的第三周我让它实现一个导出逻辑它用了一个叫ExportFileUtil.toExcelFile()的方法看起来非常合理参数也对得上甚至异常处理都在。结果一编译方法根本不存在。我后来回看发现它是把另一个开源项目的工具类“嫁接”到了我们的代码里。处理这类问题的思路是别急着骂模型先让它给出依据。我问它“这个工具类在哪个 jar 包里”它答不上来再补一条约束让它重写“只能使用以下代码库中已有工具不允许发明新 API”。从那以后我养成了一个习惯对关键依赖先把 jar 里的核心类列表贴给 AI 当“白名单”尤其是内部封装的老库。这个坑的根本原因是模型擅长拼装和预测不擅长核查版本和符号是否存在。它生成的内容看起来语法正确但符号引用可以完全来自“训练数据里的混合记忆”。所以凡是生成代码里出现没见过的方法名第一时间先去代码库里搜索确认而不是相信格式正确就一定能编译。4.2 上下文污染对话越聊越糊涂第二个坑是上下文污染。我曾经在同一个对话里连续处理同一个文件的三轮修改前五轮都很正常但到第七轮AI 开始把我前一轮已经删掉的变量又加了回来甚至把两个方法实现混在一起。这个现象在长对话里非常常见原因是对话历史里的旧代码和新需求互相干扰。解决方式很朴素每个子任务开一个新对话。我把“AI 协作约定”放在docs/ai-agents.md里每次新对话只粘贴与本任务相关的片段。比如我在里面维护了这样几条## AI 协作约定 - 本仓库是 Java 8 Spring Boot禁止使用 var 和 Java 11 语法 - 业务异常统一走 ErrorCodeEnum禁止直接 new BizException(String) - 不修改 OrderExportService 之外的类除非明确要求 - 生成代码时如果有假设请先列出假设再写代码。把这些约定在新对话开头贴一遍效果比我让它在同一个对话里“记住”好很多。模型对上下文是有窗口限制的但更重要的是历史上下文里那些“过期的指令和代码”会持续干扰后续输出。宁可每次多花三四十秒贴约定也不要赌它能从长对话里记住你的最新意图。4.3 流程自动化不能替代人工判断卡点第三个坑来自一个更宏观的层面。组里有一阵子讨论过要不要把“AI 生成代码 → 自动跑测试 → 自动合入”整条链做成全自动流水线。我的态度非常明确不要把自动测试通过当作业务正确性的充分信号。举一个我实际见过的例子AI 为某个排序功能生成的单元测试全部通过了但它把排序方向写反了因为测试里的基准数据恰好用反了也没被识别出来。测试通过只能说明代码满足了你设定的断言而不能说明它满足了业务预期。“业务预期”这个词目前只能存在于会读 PRD、懂用户场景的人脑子里。所以我的工作流里始终保留三个人审卡点开发自测、人工 Code Review、冒烟回归。AI 可以压缩这三个卡点上的工作量但不能让整个节点消失。这也是为什么我反复强调“判断权留在人手里”——对校招生来说这不仅是工具使用方法更是一种职业习惯。把所有产出都直接信任表面上效率最高其实是在把风险后置。4.4 Prompt 模板速查表可直接抄作业最后把我在这套流程里最常用的 prompt 整理成一张速查表方便你直接复制修改。使用场景Prompt 核心指令易错点需求拆解“请列出涉及的改动点、数据表、接口和潜在风险按优先级排序”输出当草稿逐条在仓库核实方案对比“基于现状给出两种实现方案比较改动范围、性能影响和风险”让 AI 推荐方案但最终决策自己做生成代码“按字段清单实现 XX只改 XX 方法不引入新依赖统一错误码”约束写不满AI 会自由发挥测试设计“请站在测试工程师角度为 XX 方法列出 10 个边界场景并排序”转成可运行测试后再信日志分析“以下是异常栈和代码片段按概率列出原因和最小验证方案”不要贴整页日志只贴关键片段Commit 信息“根据 git diff 按 type(scope): subject 生成 commit”自己复核一遍主题和差异是否一致MR 描述“按背景/改动点/影响面/自测结果/风险自查生成 MR 描述”自测结果必须自己填真实验证证据Review 预检“检查空指针、资源泄漏、异常吞噬、事务边界标记等级”预审发现的问题仍需人工判断这张表不是我一次性想出来的是前三个月在真实交付里一点点调出来的。最初我什么都想让 AI 干后来发现越是把 prompt 限定到具体动作、具体文件、具体约束产出越稳定。你现在如果刚开始搭自己的 AI Coding 工作流不用急着复刻我所有步骤先挑一个你最头疼的环节比如日志分析或测试设计接入跑顺之后再往上下游扩展。拿我自己来说坚持跑这套工作流半年多最大的收获反而不是“节省了多少时间”而是对 AI 产出的敏感度提高了。看到一段生成代码我已经能条件反射地去想它的边界条件、依赖假设和业务语义有没有问题。这份敏感度才是 AI Coding 时代开发者的核心竞争壁垒。希望这篇校招生视角的实操记录对正在折腾 AI Coding 工作流的你有参考价值。