入职第一天Leader丢给我一个已经迭代了六七年的服务端仓库让我先熟悉代码顺手修一个边界条件的小bug。那是我第一次面对真正的大厂代码库——几十万行代码、复杂的目录结构、一堆我不认识的内部中间件封装。我当时的反应和多数校招生一样打开编辑器准备找同事问或者对着代码硬啃。但事实是我效率最高的方式不是去问人而是把手里的AI工具彻底重构了一遍——从一个能在编辑器里自动补全的插件变成了贯穿需求理解、代码定位、实现、审查、测试、文档全流程的协作对象。现在回头看真正拉开差距的不是用不用AI而是怎么把AI接进整个开发流程。这篇就聊聊我作为校招生在大厂真实业务场景下沉淀出来的AI Coding工作流。包括我踩过的坑、每个环节的具体做法、任务说明书的写法和一套可以直接抄走的检查清单。内容偏实战适合刚入职场的同学也适合想把自己AI用法体系化的朋友。1. 入厂第一周我推翻了对AI Coding的原始认知1.1 校招生最容易走的两条弯路刚用AI写代码的人基本都会经历两个阶段。第一阶段是玩具心态觉得AI写代码真神描述两句需求就能生成一坨能跑的东西于是什么功能都想先丢给它结果生成的代码要么风格和项目不搭要么调了一晚上边界条件第二阶段是质疑心态觉得AI生成的代码有问题只能自己动手写把它退回聊天机器人的位置。这两条弯路我都走过。我的教训是AI Coding不是让AI替你写代码而是让AI替你承担认知负荷。写代码只是开发流程中最末端的一个动作真正的难点在于搞清楚要写什么、为什么这么写、改哪里、影响了什么。AI最有价值的地方不是生成速度而是它能把你的意图快速转译成代码同时通过反问帮你把模糊的想法逼成清晰的需求。想通了这一点我就没有再纠结哪家AI写得更聪明而是开始琢磨怎么围绕整个开发流程去设计协作方式。1.2 大厂环境下AI工具的选型逻辑和网上教程说的不一样网上教程普遍推荐的做法是装个插件配好模型然后开始对话。但进了大厂你会发现现实要复杂得多。首先是代码安全。公司的代码绝大多数不能上传到外部服务所以内部自研的AI助手、合规的私有化部署平台才是主要阵地。校招生入职后第一件事应该是问清楚团队允许用什么工具、哪些仓库可以开放给外部AI、哪些只能在内部平台使用。别图方便把一个内部服务的鉴权代码贴进公网AI对话框这在大厂是红线。其次是在可用工具里做分工。我最终的工作流同时用了三类AI能力能力类型典型工具在流程中的职责自动补全IDE插件边写边补处理样板代码、单元测试骨架对话式辅助内部AI助手 / Web端对话需求拆解、代码勘察、方案讨论、审查提问仓库级理解仓库索引工具 / AI编程平台跨文件分析、调用链梳理、批量重构建议选型的核心逻辑不是哪个模型最强而是每个环节需要什么形式的AI配合。补全类工具要的是低延迟、低打扰对话类工具要的是推理深度和上下文长度仓库级工具要的是能正确建立索引、准确检索。这里补充一个务实的建议校招生往往对工具链特别热衷但工具永远只是载体。我见过不少同学同一周换了三个插件却没有沉淀出一套稳定的用法。真正的工作流应该是工具固定下来、方法不断优化而不是每天在换工具中消耗精力。2. 需求拆解与代码勘察动手写码前AI已经在创造价值2.1 把模糊需求变成可执行任务大厂的需求通常不是给我做个登录页这种一句式描述而是从一个业务目标出发经过产品经理、技术负责人的层层转化最后到你面前的可能是一段描述、一个原型、或者一个线上问题单。校招生最容易栽的坑就是拿到需求就打开编辑器。我现在的做法是拿到任何需求之后先不分心去读代码而是先把需求原文、相关上下文喂给AI让它协助我做三件事第一提炼验收标准。让AI把用户希望实现什么拆成一条条可验证的验收项例如当库存不足时订单接口返回错误码XXX且不扣减用户余额。这一步的价值在于很多需求描述里隐含了一堆边界条件AI可以通过枚举帮你把它们显式化。第二寻找矛盾点。让AI以质疑视角去审视需求这些描述之间有没有不一致有没有缺少异常处理的定义我实际测下来AI找出的问题往往和后来代码评审中老同事提出的问题高度重合。第三生成提问清单。把不确定的内容整理成问题带着问题去问产品或Leader效率远高于边写边问。举个例子我曾经接到一个需求优化列表页加载速度。这个描述几乎无法编码。我先把接口代码丢给AI让它分析当前慢的可能原因AI基于代码里的循环查库、未分页、重复查询等特征给出了几个假设然后我带着这些假设去确认最终把模糊目标变成将列表接口P95响应从1200ms降至500ms以下取消循环内N1查询并按需加载产品图片。从那以后我养成了习惯需求不转成可量化的任务清单不动手写码。2.2 用AI做存量代码的局部地图大厂的代码库对新人来说最大的问题是上下文断层你接手的是别人写了很多年的代码里面充满了各种约定俗成和只有原作者才知道的背景。我的办法是通过内部仓库索引工具把目标模块的代码批量投喂给对话式AI然后围绕它做定向勘察。这里有几个固定的问题模板梳理一下这个模块从入口到落库的完整调用链标出关键类和方法的职责。这个接口当前有哪些调用方如果修改返回结构哪些地方会受影响这个模块里有哪些明显可以删除的死代码或废弃逻辑实测下来AI对结构清晰、命名规范的代码理解得非常好能输出一份像老员工口述的模块地图。但要注意AI给出的调用方清单一定要用代码检索二次确认。因为大厂的代码里经常有动态注册、反射调用、SPI扩展这些黑魔法纯静态扫描很难覆盖全。AI给出的结论是线索不是事实。2.3 写方案前让AI先做一轮预审大厂写技术方案或者叫设计文档是校招生存活的必修课。我见过很多同学方案写得像流水账——背景、方案、工作量列一列就完了完全没有论证过程。这里AI能帮上大忙。我写方案的模式是先把背景和我的初步设计思路整理成文喂给AI然后明确要求它角色扮演一个十年经验的资深架构师从以下角度找问题安全性有没有越权、注入风险、扩展性后续需求来了能不能改、一致性和现有代码风格与设计模式是否统一、性能边界有没有明显的性能坑。这相当于在真正评审之前做了一轮低成本预审。AI提出的问题我自己先消化写进方案里再拿去给Leader评审。方案质量提升了不止一个档次——Leader看到你连失败模式、回滚方案、监控报警都提前想过了信任感会有质的飞跃。3. 编码实现我给AI写任务说明书而不是丢需求聊天3.1 为什么请写一个XX功能是最低效的提问方式很多同学用AI写代码习惯是帮我写一个限流器帮我实现一个登录接口然后AI给一堆代码贴进去报错再继续帮我修一下。这种用法效率极低因为AI没有上下文只能生成泛化代码和你的业务场景根本不匹配。我的做法是把每次AI辅助编码都当成一次外包协作你先写一份任务说明书再发包。一份合格的任务说明书包含六个要素角色定位明确AI扮演的角色例如你是一名熟悉Go后端开发、重视工程规范的工程师。背景信息这个功能在什么模块、服务什么场景、被谁调用。目标描述本次任务的明确产出。约束技术栈、编码规范、现有封装、不允许改动的部分。验收标准代码合入前必须满足哪些条件比如单测覆盖、边界处理。不得事项明确告诉AI不要做什么比如不要修改公共配置文件的格式。拿一个我实际写过的代码来看角色你是一名熟悉Java的后端工程师代码风格偏向简洁小步重构。 背景在订单服务的pick模块中当前有一个SimplePicker负责从待处理队列选取订单 但选取逻辑里存在循环内调用外部计价服务的性能隐患。 任务把循环内的计价调用改成批量预取模式保证单批处理耗时可控。 约束 - 只能修改PickServiceImpl.java和OrderPriceClient.java两个文件 - 保持现有日志打印格式不要引入新的日志框架 - 计价批量接口已经存在位于com.example.price.BatchPriceClient。 验收 - 不改变待处理队列的顺序语义 - 增加测试用例覆盖批量预取失败时回退到单次调用的逻辑 - 不修改对外接口签名。 不得事项不要重构整个包结构不要改动其他模块代码。把这份说明书丢给AI它生成的代码比我直接说帮我优化下单逻辑生成的代码可用度高出非常多。原因很简单AI生成代码的质量取决于你提供约束的质量。约束越明确AI的搜索空间越小生成结果越能落在你期望的范围内。3.2 小步生成、小步提交是保命底线明确约束之后还有个关键习惯让AI小步生成而不是一次性生成整个功能模块。我有一次让人工智能一次性帮我实现整个订单导出功能它生成了两百多行代码从查询、组装、格式化到写文件的逻辑全在里面。我贴进去编译过了跑起来却有个隐藏问题它对分页的假设和现有代码不一致导致大数据量下内存溢出。那次debug花了一整个下午。现在的做法是把一个大任务拆成多个小任务每个小任务生成后立即检查、编译、测试、提交。例如先让AI生成数据查询部分跑通再生成导出文件组装部分跑通最后拼接逻辑。每个小步之间保证代码可运行出了问题也能快速定位到具体任务而不是在一大坨代码里翻找。这里想强调一个很多人忽略的点AI生成代码合入前diff审查是必须做的而且要看上下文diff而不是只盯着新增行。AI有时会在你以为它只改一行的地方顺手把注释改了、格式重排了、变量名微调了这些都会让代码评审变得痛苦。我一般要求AI最小化改动并且在提交信息里明确改动范围。3.3 处理AI生成错位代码的通用方法不管说明书写得再好AI依然会生成错位代码——那种看起来能跑、实际上没有接入正确业务逻辑的代码。以下是我实际验证过的三招第一招代码审查时优先盯接口边界。看AI写的代码不要盯中间逻辑先看入参校验、返回值处理、异常分支——大部分错位代码出问题都在边界处。第二招让AI解释它自己写的代码。如果AI解释不清某个变量为什么这么命名、某个循环为什么这么写那多半有问题。第三招对AI生成的代码持不信任态度强制自己补测试。AI生成的代码我只当作草稿没有通过自测和单测验证绝不进评审。把AI当成一个很聪明但经常粗心的实习生你的心态会平和很多。4. 审查与调试AI作为第二双眼睛的正确用法4.1 让AI做代码审查先想明白审查什么代码审查是校招生最容易紧张也最不想面对的环节——大leader坐在对面指着你提交的MR逐行点评那种压迫感谁都经历过。我后来发现AI完全可以当陪练。我的做法是把自己的改动喂给AI之前先给它设定审查重点。不是让它笼统地说这段代码有什么问题而是让它按这几个维度输出正确性有没有边界条件漏处理、状态一致性被破坏安全与权限有没有越权调用、参数校验缺失、敏感信息泄露可维护性命名是否清晰、函数是否过长、魔法数字是否应该提取常量性能有没有明显的循环内重查询、重复创建对象、无谓拷贝兼容性改动是否影响旧调用方是否考虑灰度与回滚我还要求AI对每个发现标注严重程度和具体行号。这样我就能快速定位关键问题而不是读完一大篇泛泛而谈。有一个细节值得展开让AI审查自己生成的代码效果往往不太好。因为AI在生成时已经把这个方案的假设合理性内化了会让它自己的立场站在这套代码是对的这边。更好的办法是一个人负责生成换一个角色设定或干脆换个工具来审查角色分离能显著提升审查效果。4.2 调试阶段复现线索与二分定位法调试是大厂开发中占比最高的隐性成本。AI在调试中最有用的不是直接给出修复方案而是帮你快速缩小范围。遇到线上问题或测试失败时我通常是这么折腾的第一先把异常栈、日志片段、相关配置喂给AI请它列出可能的原因清单并标注每个原因对应的排查路径。这一步能帮你把毫无头绪变成从清单里挑最可疑的几项。第二利用AI做二分定位。我最近处理过一个诡异的偶现问题一个接口偶尔超时但日志里没有任何业务异常。我把调用链日志整理后丢给AI它指出超时主要集中在两个外部依赖同时调用的时间段怀疑是连接池竞争。我按这个线索去排查果然发现连接池配置过小造成了排队。如果不用AI提前圈定范围这种问题靠人肉翻日志不知道要翻多久。第三修复之后别急着提交。把修复代码再喂给AI让它从破坏者视角指出这个修复可能带来的新问题。大厂代码依赖复杂很多修复是按下葫芦浮起瓢AI的这一步二次审查能帮你提前规避不少线上回滚。4.3 上下文窗口共享被90%的人忽视的工作流细节我在接入AI过程中踩过最深的坑是上下文碎片化。很多时候我把需求文档在一个对话框里聊了一遍过一会儿写代码又在另一个对话框里重新描述一遍AI对我的业务背景的记忆每次都从零开始。这就导致同一套逻辑上午生成的代码和下午生成的代码风格完全不同。后来我把工作流改成了这样为每一个功能模块建立一个专门的AI对话会话首先把需求拆解结论、模块代码地图、技术方案摘要这三份文档一次性投进去作为项目记忆。之后所有的生成、审查、调试都在这个会话里进行AI就能共享这个业务上下文。虽然每次会话的上下文有限但持续的构建方式能让它的回答精准度逐步提升。还有一个经验是定期给AI复核它对业务背景的理解。让它用自己的话总结一遍这个模块是做什么的、当前任务的目标是什么如果总结准确你才敢继续依赖它如果总结有偏差赶紧修正不然它会带着错误假设帮你优化到沟里去。5. 测试、文档与提交信息AI提升的不只是写代码速度5.1 让AI补测试先给测试意图而不是测试用例补单测是校招生的日常也是最枯燥的活。很多同学的用法是帮我给这个函数写单元测试AI生成一堆覆盖各种分支的用例。但这种测试有个致命缺点断言太弱全是不为空不为null这种毫无意义的验证或者只覆盖了典型路径边界条件完全没照顾到。我现在的做法是给AI测试意图而不是测试用例。比如这个函数从消息队列读取订单事件并更新状态请围绕消息乱序、重复投递、状态非法这三种异常场景补测试保证状态机不出现非法跳转。当你给出明确的测试意图AI生成的测试才有真正的业务价值。这里分享一个经验AI生成测试后你要刻意做一步测试消灭实验。把被测代码里的正确逻辑故意改坏再看AI生成的测试能不能抓出来。如果抓不住说明测试的断言语义太弱。这一步能极大提升AI生成测试的质量也会让你对测试代码的真实有效性有概念。5.2 自动文档的边界哪些该让AI写哪些不该很多同学让AI一键生成代码注释和文档结果生成了一堆这段代码遍历集合并使用lambda表达式处理这种毫无价值的注释。我的判断标准很简单AI写注释永远应该解释为什么而不是是什么。是什么读者看代码就知道为什么才是代码背后真正的知识沉淀。例如// 这里不走事务因为外部计价服务的响应耗时较长 // 持有事务会锁住数据库连接拖垮整体吞吐。 ListPriceResult results batchPriceClient.query(orders);这种注释才是AI应该补的。我会在任务说明书里明确要求不要给每行代码写注释只对非常规逻辑、性能考量、业务约束添加为什么型注释。这样AI生成的注释才不会被老同事在评审时要求删掉。至于接口文档、README和技术方案的结构性文档AI的用处在于扩写和结构化而不是凭空生成。我通常会把代码逻辑和自己在实际业务中踩到的约束丢给AI让它帮我组织成H2目录、操作步骤、注意事项。它能节省很多排版和措辞的时间。5.3 提交信息模板化让AI当你的工程秘书大厂对提交信息的要求五花八门有的要求带需求单号有的要求按Conventional Commits格式有的团队还要求写明测试影响范围。校招生最容易在这个地方被反复打回。我的策略是让AI在每次提交前处理提交信息。把本次diff 需求单号 改动说明丢给它要求它按团队模板生成提交信息。注意这一步放在diff稳定之后再操作不要边写边让它提交。AI生成的提交信息有个额外好处它会把代码中实际发生的变化描述出来如果你的你以为的改动和AI从diff里读出来的改动不一致说明你还没真正理解自己做了什么。这种语义对比其实是一个很好的自我检查手段。6. 把整条工作流固化成清单校招生也能快速上手的落地姿势6.1 我每天开工前会过一遍的自动检查顺序下面这张清单是我这段时间提炼出来的可以帮你把上述所有环节串成一条固定的每日工作流。刚入厂的校招生可以直接拿它当checklist用。拿到需求后先喂给AI做验收标准拆解找出矛盾点生成提问清单用仓库索引工具圈定相关代码让AI产出模块地图人工确认关键链路写技术方案前让AI做一轮架构师预审把问题补进方案编码前写任务说明书角色、背景、目标、约束、验收、不得事项分步生成每步生成后先开diff审查再编译单测最后小步提交提交前让AI做分维度代码审查重点盯边界条件和逻辑一致性补测试时给AI测试意图并要求测试消灭实验通过生成为什么型注释和结构化文档用AI按团队模板生成提交信息人工核对语义全部合入前让AI做一轮破坏者视角的二次审查。这套清单看似繁琐但它把AI的使用从灵光一闪变成了稳定复现。就像做菜一样老手凭手感但新手需要精确到几克盐、几分钟火候。等流程内化成肌肉记忆你就能逐步省略一些步骤只保留最关键的环节。6.2 几个边界场景的处理规则流程跑顺之后有几类场景需要特别处理否则容易被AI带偏。第一类是线上紧急修复。这种场景最重要的是快我会跳过文档和方案预审直接进入定位修复。但提交前依然保留必做三项diff检查、单测补充、提交信息规范化。紧急不等于可以降低质量门禁。第二类是涉及资金、账户、权限的核心逻辑。这类代码我基本不会让AI直接生成实现而是让AI做预审和检查实现部分自己手写。AI在这里的价值是补漏不是代写。宁可慢一点也不能让它在核心链路里放飞。第三类是与外部系统交互的逻辑。大厂内部系统之间的接口契约常常依赖专门的文档和配置中心AI不了解这些隐式契约。遇到这种任务我会把接口文档、配置样例、契约说明全部喂给AI之后再让它动手否则它只能生成一个看起来对但实际对接不通的假实现。6.3 后续迭代校招生如何持续优化自己的AI工作流工作流不是一成不变的。我的经验是按周复盘这一周AI在哪一步最省时间在哪一步产生了返工返工的根因是说明书写得不清楚、还是AI能力边界导致的返工数据是优化工作流最好的信号。如果某个环节返工率特别高大概率不是AI的问题而是你的输入不够结构化。我目前正在尝试的方向是把团队代码规范和架构沉淀成一份团队级AI知识包每次对话都自动附带这样AI的输出会更符合团队既有风格。还有一个值得留意的趋势是多智能体协作。我自己已经在尝试让多个AI角色分工——一个负责代码生成、一个负责审查、一个负责测试、一个负责文档——它们共享同一个需求背景类似于一个虚拟工程小组。现阶段效果还有起伏但方向上确实能减少我在不同角色间切换上下文的成本。最后分享一点最真实的体会AI Coding工作流的核心不是AI而是你对自己开发流程的理解。我刚入厂时以为AI是来提高写码速度的后来发现它真正的价值是逼我变得更清晰——把需求理解清楚、把约束写明、把变更边界想透、把风险排查前置。这些能力本来就是高级工程师的核心素养。AI没有替代这些思考它只是让你用更低的成本把这些思考落实到每个环节。如果你也是一名校招生正在被大厂的代码库和流程压得喘不过气不妨别急着把AI当提效工具试着把它当成思考伙伴。从第一份需求拆解开始一步一步把AI嵌入你的完整开发流程。用上两周之后回来再看你会感谢当时那个愿意重新设计工作流的自己。