我记得刚入职那会儿最焦虑的不是业务不熟而是每天的节奏完全跟不上。需求评审完leader给我两天时间把一个小模块写出来我光是在庞大的工程里找到对应代码就花了半天剩下时间全在和AI聊天框搏斗——“帮我写个 xxx 接口”它给了我一个看起来正确的答案我贴进去编译报错再贴回去再报错。那两天我基本就是在“粘贴错误信息→收到泛泛的修改建议→继续粘贴新错误”的循环里度过产出少得可怜。后来我复盘发现问题不在AI不够强也不在我基础太差而是我压根没有一套“把AI嵌入开发各个环节”的方法。我拿它当搜索引擎用偶尔得到一点代码片段仅此而已。经过半年多的摸索和大量试错我逐渐沉淀出一套适合校招生、也适合中小团队落地的大厂风格AI Coding工作流。它覆盖从需求理解、技术方案、编码、自测、CR到文档沉淀的完整链路。这篇文章就把它完整拆开讲包括每个环节我总结的提示词模板、工具选型思考、以及踩过的最大的几个坑。1. 为什么要搭一套工作流而不是零散用AI先讲一个最反直觉的结论在大厂环境里AI Coding的价值瓶颈不在模型的代码生成能力而在工程管线对AI的“接入方式”。换句话说你我手里的大模型现在写单点小函数已经足够强了真正拖后腿的是我们只在“要写某一行代码”的时候才把AI叫出来而前后一大段黑盒流程——需求怎么拆、接口怎么定、改动影响哪些模块、怎么验证——全凭人肉扛。校招生最容易犯的一个错误是把AI Coding等同于“写代码时用Copilot补全”。这套“零散用法”在写LeetCode、写个人项目时问题不大因为代码量小、依赖简单、坏了对自己的影响有限。但在大厂的工程环境里问题很快暴露需求层面直接让AI“实现一个功能”它给出的往往是一个理想化的独立模块而大厂后端代码永远长在巨大的复杂工程里依赖RPC、数据表、消息队列、配置中心、权限体系AI看不到这些上下文就乱编接口比不写更危险。交付层面新版功能不止要“代码跑通”还要考虑兼容性、降级策略、埋点、日志、耗时优化。这些“软性交付物”AI不会主动给但如果你的工作流里没有强制它参与你大概率会漏。验收层面代码写完只是开始单测、CR、联调、QA验收环环相扣。AI能不能帮你把这些环节的成本降下来而不是仅仅帮你把第一版代码“从0到1”快速糊出来决定了它到底是提效杠杆还是制造返工的工具。所以我定义的工作流不是某个工具而是一套过程管理习惯在开发流程的每个关键节点上我明确知道AI该承担什么角色、不该承担什么角色并且用固定的提示词模板和校验清单来保证每一次接入的质量。下面这张表是我整理的各环节分工后续每个环节我都会展开讲。开发环节AI参与方式AI不做什么我的主责需求理解拆解PRD、提取验收点、列出歧义问题不做业务决策对齐预期、确认边界技术方案生成方案初稿、对比选型、评估风险不做最终选型画架构图、定接口编码实现生成模板代码、补全边界逻辑、解释调用链不直接操作线上配置设计核心逻辑、审查产线自测阶段生成单测、构造边界用例、辅助排查失败原因不替代测试策略跑通主链路、记录结果CR评审生成改动说明、列出检查清单、圈出可疑点不直接给approve解答疑问、吸收建议文档沉淀生成初稿、统一风格、补全注释不编造方案细节审核事实、补充心路在这套流程跑通之前我也试过很多“网红用法”比如把整个PRD丢给AI让它“直接写需求”或者让AI生成一整块“完美代码”然后拿来就用。结果基本都是灾难。现在回看反而是那种“每个环节让AI干一点但不过界”的编排方式效率最稳、返工最少。接下来我按真实开发流程把每个环节的具体落地方法和提示词模板逐一拆开讲。2. 大厂环境下的工具选型先把“能用的AI”装对聊工作流之前必须先聊工具。大厂和其他公司有个本质区别代码资产是企业核心机密几乎不可能允许你把业务代码贴到外部公有云服务里。所以我的第一个建议是入职第一周先搞清楚公司允许用什么、不允许用什么别上来就装一堆看起来很酷的插件然后踩到合规红线。这不是危言耸听我见过真有实习生把公司内部代码片段贴到公网ChatGPT上差点酿成安全事故。在学校里你可能习惯了ChatGPT或Claude网页版、GitHub Copilot带公有代码库补全到了大厂内部这些基本都不可用。比较常见的有三个选项公司的私有化代码生成服务。很多大厂内部已经部署了基于开源模型微调的代码补全服务以IDE插件的形式提供它们能访问到公司代码库但不会外泄。这是最合规、最省事的选项优先用它。IDE自带的AI能力。比如JetBrains全家桶和VS Code陆续内置了AI补全能力通常也能选择连到内网服务或私有化部署的模型端点。比起公司统一的插件它更自由但要注意具体聊天内容是否会被记录。自建/自托管模型网关。适合对模型能力有更高要求、且组里有GPU资源或能申请到内部模型网关的同学。通过本地服务把请求转发到内网模型兼顾合规和数据安全。我自己最终选的是“公司私有化代码补全插件 本地模型网关用来做长上下文对话 IDE内置AI聊天”三者组合。这个组合的好处在于写代码时用补全插件获得低延迟的联想遇到复杂问题把相关代码上下文放进本地网关做深度分析日常语法层面小问题直接用IDE内聊天解决。我强烈建议校招生不要在这个环节花太多精力“折腾最强模型”。因为在大厂环境里真正影响AI Coding体验的往往不是模型聪明程度而是能不能让它看到你的项目上下文。一个能直接索引你本地仓库、理解依赖关系的插件远远比一个只会聊天的“超级大脑”好用。这个道理我一开始不明白总想着把各种网页版AI拼到一个IDE里折腾了整整两天最后利用率最高的还是那个能看到工程结构的补全插件。选型落地后就可以正式进入流程了。第一个环节也是最容易被校招新手忽略的——需求理解。3. 需求理解与技术方案AI帮我先画靶再射箭很多新人拿到需求直接就开始写代码这是大忌。在大厂需求理解本身就是开发流程的一部分而且往往是最重要的一部分。因为大厂的需求通常经过产品、运营、算法等多轮流转到了你手里的PRD已经夹带着大量背景信息读不懂就会做出和预期南辕北辙的东西。我的做法是拿到PRD后先不急着看技术细节而是把PRD里“能给AI看的非敏感部分”抽取出来让它帮我做三件事拆解可验收的业务规则。比如“用户领取优惠券后7天内有效过期自动失效”AI会帮我枚举出其中隐含的状态机变更而不是只看到一句简单的业务描述。列出需求中合理的歧义点。比如“有效”怎么定义是从领取时刻算起还是从第二天零点算起这种细节如果不主动问很可能上线后跟QA定义不一致反复扯皮。根据需求草拟测试要点。注意这里只让AI列“功能验收角度”的测试点不和真实系统细节绑定只是当作检查清单。这个环节我惯用的提示词模板大致长这样你是一名资深后端开发工程师接下来我会给你一段经脱敏的产品需求描述。 请你完成三件事 1. 以表格形式列出全部可验收的业务规则每条规则注明 “业务场景/输入条件/预期输出”。 2. 列出需求描述中任何含糊不清、可能产生歧义的点以问题列表的形式给出。 3. 给出这份需求的端到端功能测试要点覆盖正常路径和边界条件不要涉及具体代码实现。 注意如果没有把握请基于常识做出合理假设并明确标注“需要与产品确认”。按照这个模板走一遍基本半小时内就能产出一份“需求盲点清单”。拿着这份清单去跟产品或leader对齐大概率会得到很多正面反馈因为说明你真的把需求读进去了。技术方案设计阶段也类似。我会先把当前系统里和这个需求相关的核心模块、接口、存储结构整理成一段描述有时AI能直接看懂我贴的关键类名和方法签名让AI基于这些信息产出一版技术方案的初稿。初稿通常不能直接用但它最大的价值是帮我“先画靶”——它会给出一个备选的实现路径、需要改动的位置和潜在风险点我再基于这个靶去核实、调整和决策。这里有一个关键心得让AI产出方案的初稿比自己从空白开始想要快得多但永远不要直接采纳AI的架构结论。因为AI不了解你们系统里那些暗坑比如某个看似合理的方案会和旧数据兼容性冲突某张表其实有存量脏数据需要先清洗。AI的作用是帮你打开思路、提供骨架、逼着你去思考每一个细节而不是替代你做技术判断。编码阶段之前还有一件小事值得单独提一下让AI帮你梳理现有代码的调用链。打工人每天接触的新模块代码量远超校园项目光看代码根本不知道它被谁调用、内部调用了谁。以前我都是人肉“Ctrl 点击”一层层跳效率极低。后来我发现把核心类名和方法签名丢给AI让它先基于代码索引给出调用链摘要再告诉我“哪些位置最可能是改动点交集半径”可以省掉大量无效阅读。我会把这类问题稳定地交给IDE内聊天去处理上下文足、速度快。4. 编码阶段的核心循环从调用链梳理到联调自查进入编码阶段之后我的工作流大概分成四个子步骤按顺序循环推进。这一个循环跑熟了效率能比不带AI时提升一倍以上。4.1 让AI先梳理“改动波及面”而不是直接写代码大厂代码最忌讳“瞎改”。你改了一个方法签名可能连带着几十个调用方报编译错误你改了一个存储字段可能另一个团队的消息消费逻辑就崩了。所以我编码第一步通常不是让AI“帮我写xxx”而是先让它基于仓库索引梳理出当前要实现的改动理论上需要碰哪些文件、哪些接口、哪些存储变更。这一步我会把刚才需求理解和方案设计的结果作为上下文一起喂给IDE内聊天让它输出一份“改动清单”。我拿到清单后再人工核对一遍把多余的、遗漏的补上确保自己对整个改动范围心里有数。很多同学说“AI写代码太不可控”很大一个原因就是跳过了这个“圈定边界”的步骤——AI没有边界自然就乱写。4.2 用项目风格约束生成代码而不是裸问等边界确定了才开始真正请AI写代码。但我从来不会只给一句话“帮我实现下单功能”而是一定会把下面几类上下文给足否则生成出来的代码风格和架构八成跟你项目不一致还要大量返工项目使用的框架和版本比如Spring Boot 2.7、MyBatis-Plus、RedisTemplate、Kafka客户端不同版本的API和坑点不一样AI不知道就容易胡写。相似模块的现成代码我常直接把“哪个文件里已经实现过一个很像的功能”告诉AI让它模仿那种写法比让它自由发挥稳定得多。数据结构与接口定义包括数据库表的字段、RPC接口的入参出参结构、消息体的格式这些硬约束不给全AI生成的代码基本等于废纸。给足上下文后我的常用提示词长这样参考项目现有代码风格尤其是 controller/service/mapper 分层方式、统一返回结构、异常处理方式为我实现 {具体功能} 。 约束条件 - 使用 {框架名/版本} 提供的能力不要引入新的依赖。 - 数据表结构为 {字段列表} 请基于这些字段完成 ORM 映射。 - 错误处理统一抛 {自定义异常} 由全局异常处理器捕获。 - 不要输出解释直接给代码文件。注意最后一句“不要输出解释直接给代码文件”对很多人很关键因为AI一旦开始长篇大论解释你反而容易忽略了它贴给你的代码里有没有暗伤。我自己实测下来这种“工程上下文喂足 风格约束明确”的方式比裸问的可用性高非常多。裸问时AI给出的代码可能单看每行都对但组合进项目里就会遇到“这个类不存在”“那个方法没有重载”“循环依赖”等等问题让人心力交瘁。而喂足上下文后生成的代码往往能“基本可用”我要做的只是检查边界和补充特殊情况。4.3 编码中遭遇报错别急着贴错误信息编码过程难免遇到编译错误或运行报错。很多人的第一反应是把报错信息原样丢给AI让它看。我也经常这么做但后来总结经验是直接贴错误日志往往效果一般因为AI缺少定位错误所需的上下文。更高效的做法是先把报错对应的文件、具体行号、报错堆栈中最上层那几行挑出来。结合对应的代码片段和关键配置一并喂给AI。让AI先说明**“这段报错的根因可能有哪几种”**再给修复建议。这样让AI先做“可能性排序”而不是“唯一答案”反而能逼迫它把常见的三类原因——比如“对象为null”“类型不匹配”“配置失效”——都列出来你自己结合现场情况筛选会快很多。这里有个学校与工业界的差异我特别想说一下校园项目里遇到报错认真读报错信息、自己尝试修复是重要的能力成长工作后遇到报错快速定位问题、找到最优解法并落地才是生产效率的关键。AI可以在后者给你巨大帮助你应该把它当作“经验助手”它看过的报错模式比你多得多排障思路能覆盖你一年积攒的宽度。但根因判断最终要你结合业务和现场下结论因为它不会知道你代码里那个奇怪的全局拦截器在哪一行。4.4 写完之后的自查清单我见过很多同学写完代码特别开心觉得自己效率惊人结果提交到仓库后被reviewer打回一堆问题。为了减少这种来回拉扯我在使用了AI工作流之后专门沉淀了一份“AI生成代码自查清单”边界条件检查空值、超长字符串、默认值、列表为空等边界是否处理了。事务与并发多步写操作是否在一个事务里有没有并发写同一个键的风险。幂等性消息消费或API重试是否幂等重复执行会不会产生重复数据。资源释放是否有文件流、数据库连接、锁未正确释放。日志与监控关键路径有没有日志指标有没有埋点。兼容性修改的字段、接口是否有调用方依赖旧逻辑是否做了兼容。降级与容错下游异常时是否有兜底逻辑还是直接让链路崩溃。这份清单是AI也不会主动帮你想到全套的组合拳。所以你可以在编写完成后把代码丢给AI“以审查者的角色挑刺”但最终过一遍这个清单的人必须是你自己。我常常会用一句提示词让AI再做一轮兜底请以资深 review 者的身份审查这段代码重点检查空值/边界、事务一致性、并发安全、资源释放、日志规范、兼容性。 不要修改代码只输出问题和对应行号并按照严重程度从高到低排序。一轮下来基本能把低级问题消灭殆尽reviewer挑刺的空间就小很多。5. 测试、CR与测试环境AI侧的“陪跑”角色说实话大多数校招生并不喜欢写单测和CR觉得这是额外负担。但大厂的流程绕不开这些东西而且它们恰恰是AI Coding工作流里性价比最高的场景。因为单测和CR这类“结构化产出物”是AI最擅长生成的类型而代码本身的业务判断才是它最容易出错的。把AI用在它擅长的地方效率会翻倍。5.1 别让AI“生成测试”让它“生成测试设计”我最初用AI生成单测直接说“帮我给这个类写单元测试”生成出来的基本都是“给getter/setter赋值然后断言”的垃圾测试覆盖率上去了但啥也没验证到。这个问题的根子在于你让AI只做了“写代码”没让它做“思考测什么”。现在我换了一个思路先让AI基于被测函数生成“测试用例设计表格”也就是输入、预期输出、覆盖场景等这个表格我确认过一遍之后再让AI按表格一项项翻译成测试代码。这样既榨干了AI梳理边界的能力又保证了测试的意图是经过人工判断的不至于变成自嗨工具。一个常用的模板如下请为函数 {函数签名} 设计一份单元测试用例表要求覆盖 1. 正常路径 核心返回值断言 2. 边界值空、极值、超长、负数等 3. 异常路径非法参数、依赖异常 4. 状态变化如果有内部状态 每一行请给出“测试名称 / 输入构造 / 期望行为 / 模拟依赖方法”四个字段。 在未收到我的确认前先不要生成实际测试代码。用这个流程之后我提交的单测质量明显好了一截reviewer也很少再对我的单测本身提意见。5.2 让AI帮你“描述CR”而不是替你做CRCR这个环节刚加入大厂时我心里发怵因为我写的代码自己都觉得不够干净怎么好意思让别人审。后来我发现CR最大的敌人不是代码写得烂而是reviewer看不懂你的改动背景和意图。如果提交描述写得清清楚楚哪怕是初出茅庐的实现reviewer也更愿意帮你补全而不是打回重写。这时候AI能做的事有两件生成“自描述”的CR信息。我自己写CR描述时经常不知道该写多细后来都是把diff和相关文件列表丢给AI让它帮我整理成“改动背景/核心实现思路/影响范围/测试说明”几个模块。我再校验一遍事实性避免它编造我根本没做的设计。从reviewer视角给自己找茬。我会让AI把我的改动当成一个陌生人的代码来审站在“最挑剔的资深工程师”角度列出问题清单。这个环节我打死也不会让AI直接替我“上pr”比如让它自动给reviewer留言因为任何冒充行为在真实团队里都是致命的信任透支。AI在我这里永远是一个“放大我表达效率”的工具而不是“替我发言”的替身。5.3 测试环境的联调与回归AI帮你快速构造数据到了联调和测试环境验证阶段我每天花费最多时间的往往是造数据、改参数、看日志这些事。AI在这里也有一个高效的用法让模型根据你的对象定义直接生成一串可以粘贴到数据库或Redis里的样例数据JSON。比如我在测试用户领取优惠券的场景时我会把优惠券表、用户表、领取记录的字段定义贴给AI让它生成几组带不同状态的数据覆盖“未领取”“已领取未使用”“已使用”“已过期”等等。以前我都是人肉往库里插入这些数据一个晚上全浪费在造数据上了。现在这个活儿基本让AI干了省时还省脑子。另外联调阶段遇到“线上日志报错了但我看不懂”的情况也可以把脱敏后的日志和关键代码片段给AI让它先提炼“哪一段日志是关键错误”“链条上哪个环节最先断开”我再用自己的业务知识去验证定位是否正确。注意这里的“脱敏”非常重要绝不能把线上真实数据、敏感ID原样贴给任何外部AI服务。5.4 一个必须强调的底线AI生成代码的合规门我之前提到过公司内部代码不能随意贴到公网大模型这里想再展开说一下具体操作层的红线因为很多新人真的不知道。在大厂特别是有国际化业务的公司代码仓库、用户数据、真实流量数据都可能涉及高度敏感信息。在用AI Coding时你需要遵守几条近乎铁律的原则优先使用公司私有化部署的模型服务而不是公网ChatGPT或Claude。绝不在对话里明文字段名关联真实业务语义以上下文已经足够AI生成代码了不要画蛇添足把“这是一张存储用户手机号的表”当作说明补进去。对真实日志、真实JSON、真实返回结果做脱敏把ID、姓名、电话、IP等替换成测试样式的假数据。和供应商相关细节不要透露包括内部工程名、机型、客户名等。说句实在话AI Coding能力再强也不值得拿工作安全去换。尤其在试用期合规意识本身就属于大厂对一个校招生最基本的考核维度。6. 文档沉淀与其他环节AI最容易提升“复盘”质量最后一环也是很多人觉得“没技术含量”的一环——文档。但对校招生来说文档水平在大厂直接影响信任评级。你写清楚一份简洁高效的设计文档比写了一千行能跑的代码可能还要加分因为文档代表你把思路理清了代表你的交付可传承、可维护。AI在这里帮我的方式主要有三种全文润色与规范化。我自己写设计文档经常口语化严重、结构不齐AI可以快速把初稿改成格式统一、条理分明的版本。注意它通常会“过度写长”我拿到之后往往要大砍一半只留下真正可行的东西。从代码抽取“已完成事实”。比如让我交付的模块写使用说明我会把代码和关键类发给它让它抽出类职责、接口列表、配置项、注意事项生成一份合理的README初稿。这一步以前完全靠人工回忆经常遗漏重大信息。基于工作记录生成日/周复盘。我每天会随手记录“今天改了哪几个文件、解决了什么问题、收获了哪些可复用的打法”攒一周后让AI把它们按“问题背景/解决方案/效果/经验”重组写周报或者做项目复盘时特别省力。因为是校招第一年的关系我每个月都会做一次个人编码习惯复盘重点检查自己在哪些环节容易被AI带偏。有一个很真实的体会AI工作流最大的隐藏成本是它会让你减少思考量。比如以前写代码需要手动翻API文档过程虽然慢但能加深印象现在AI直接告诉你用哪个API你可能会把内部机制忘得干干净净。半年后技术上深度不足比半年后代码量不够更致命。我自己的对策是给自己立一个规矩——AI生成的代码必须等到我能对它的每个关键部分说出“为什么这么做”之后才允许进仓库。有时候我会故意用一句话让AI解释它写的一段复杂逻辑然后自己再复述一遍说不上来就说明我还没真的掌握需要继续挖。这个方法很土但对我这种自控力一般的人很有效。7. 从Copilot式辅助到Agent式协作我对AI Coding工作流后续形态的思考写到这里我相信你已经看到我讲的工作流本质上是“AI作为发动机我作为导航和方向盘”的协作方式。但最近一段时间很多团队开始尝试让AI更进一步直接以Agent的形态跑完一小段开发流程比如自动写单测、自动修BUG、自动提PR。我也在内网里看过几个内部实验项目有成功也有翻车这里聊聊我的观察帮助大家判断自己该怎么用。所谓Agent式开发通俗讲就是你给AI一个目标“修好这个单测失败”AI自己规划、执行、看结果、再调整直到目标达成。听起来很美好但在真实大厂场景里最卡脖子的仍然不是模型能力而是你能不能让AI在大量复杂的工程约束里持续获得真实反馈。比如自动定位一个线上问题它需要能查日志、能连测试环境、能改代码跑CI这一整套基础设施是否允许AI接入才是关键。对校招生而言我个人建议不用急着上Agent先把我在前面写的那套“环节级AI工作流”跑熟因为它的收益更确定、失败风险更低。等你在一个领域里积累了足够的业务上下文和代码语感再去玩Agent式的探索会顺手很多。反过来如果你连“这个需求到底要改哪些文件”都没法一眼看出来给了Agent再强的能力你也hold不住它。往后回顾我这一年多的实践最幸运的一件事其实是刚入职时没有放弃自己的人工审查和思考。AI Coding让我把更多时间从机械劳动中解放出来投入到业务思考、方案权衡和跨团队沟通上。它没有让我变成“更快的打字员”而是让我更快成长为“更像资深工程师的人”——能把一件事想清楚、讲明白、交付漂亮。如果你也在大厂刚起步我建议你从今天开始按照我这套流程里的某个环节做一次实践比如下个需求先让AI帮你拆解PRD和验收点再动手写码。等某个环节用顺了再扩展覆盖到全部流程大概率你也会有一种感受——原来AI Coding的正确打开方式真的不是“写代码时呼来唤去”而是把它编排进你日常工作的每一个节点里。