每年入职季都会看到一批刚毕业的同学带着Copilot、Cursor这些AI工具冲进代码库然后在第一轮Code Review里被疯狂打回。我自己也是校招生进来的第一年写了不少代码也被AI坑过不少次。现在回头看我搭起来的这套AI Coding工作流其实不是“让AI多写代码”而是把AI拆成不同角色塞进需求、设计、编码、测试、Review、上线这条完整的研发流水线里。这篇主要想分享这套工作流怎么搭、每一步我踩过哪些坑、以及最终沉淀下来的一些模板和习惯。适合刚入职场的工程师也适合团队里想系统性引入AI Coding的同学。先说结论AI Coding的价值不在自动补全那几行代码而在让每个环节的上下文传递更顺、让重复劳动尽量自动化。1. 我为什么非要把AI接进完整开发流程而不是只在写代码时打开1.1 校招新人最常见的两个极端刚入职那阵子我见过两类同届同事。一类把AI当搜索引擎用遇到报错就贴上去问问到能跑就完事另一类干脆禁用一切AI觉得AI生成的代码自己看不懂、不敢用。这两类人很快都会撞墙——前者入职两个月开始频繁被Review打回因为代码风格不一致、边界条件缺失、甚至把AI编造的API写进生产代码后者则陷入纯体力劳动改个字段命名要全局搜索半天效率在团队里垫底。我自己最初属于第一类。记得有一次处理内部配置中心的迁移我让AI帮我写了一个批量读取配置的脚本它生成得很流畅我当时也测了几个case觉得没问题。结果上线那天才发现它把配置key的大小写规则搞混了漏掉了一类环境前缀直接导致部分实例配置为空。那次事故之后我意识到AI不是不能用而是不能只作为“编码阶段的补全工具”来随便用。它必须在流程里被约束、被校验、被分工。1.2 工作流的核心目标让AI当流程里的角色不是当流程本身我搭这套工作流的出发点是把AI的能力注入到已有研发流程的各个环节而不是让研发流程退化成“把需求丢给AI等它交代码”的黑盒。听起来保守但大厂研发体系里从需求评审到上线复盘都有严格的节点新人在这些节点上往往是被动等待的一方——等产品给需求、等TL评审方案、等测试提bug。AI真正能帮我的是在这些等待和沟通的缝隙里把个人操盘的效率拉起来。举个例子。需求评审阶段产品给了一份很长的PRD里面藏着几个前后矛盾的边界描述。以前我要么自己慢慢看要么在评审会上被问到才发现。现在我让AI先按PRD生成一份结构化拆解把用户故事、变更点、风险点、测试线索都列出来我再拿着这份东西去对照原文。这样在评审会上我能直接指出矛盾点而不是一脸懵地记笔记。这个习惯保持下来之后TL对我的印象不是“写代码快”而是“靠谱”——这在职场初期比写代码快值钱多了。1.3 一套完整的全景视图先看清楚AI在哪些节点发力很多文章喜欢把AI Coding工作流画成流水线图我这里用文字描述一下骨架方便后面展开。整条链路我分成六个大节点需求理解与技术方案设计。AI负责PRD拆解、方案预审、接口设计草案、风险检查。编码实现。AI负责代码生成、单测补充、重构辅助、仓库上下文问答。代码Review与变更自检。AI负责第一轮静态检查、变更影响分析、提交信息整理。测试与问题排查。AI负责测试用例补全、日志分析、错误栈语义化。文档与联调协作。AI负责接口文档生成、排障记录整理、跨团队信息拉齐。上线与回归复盘。AI负责执行检查清单、生成发布说明、整理复盘材料。每个节点我都遇到过“AI可用但需要用对姿势”的场景下面一个个拆。2. 需求理解与方案设计阶段让AI当评审的顾问而不是替我做决定2.1 用AI做PRD拆解把产品语言翻译成技术语言这一步我把它叫“需求翻译层”。产品给的PRD经常是自然语言描述夹杂着截图和表格信息密度低。我现在的习惯是拿到一份PRD后先用AI提取关键信息生成一份结构化的技术需求摘要包含变更点、涉及模块、依赖关系、边界条件、疑点列表。我在内部用的是自己搭的一个Prompt模板核心逻辑是让AI“不要总结而是列举”。总结容易丢失细节列举才能暴露出前后矛盾的地方。比如有一次PRD里写“用户可在24小时内取消订单”但同一份文档的流程图里又写着“取消时限为支付成功后30分钟”。AI帮我并排列出来后我一眼就看到冲突省去了在评审会上被追问的尴尬。这里要注意AI的拆解结果一定要标清“原文出处”也就是让它引用原文中的原句。没有原文引用的拆解等于幻觉放大器看起来逻辑合理实则信息是从它自己的知识库编出来的。实操中我会在模板里加一句话对于每一个提取出的需求项必须附带原文对应的句子或段落不要改写不要推测。如果原文没有明确说明单独列为“待确认项”。这样做还有个好处后期需求变更时我能沿着原文出处快速定位改动影响范围而不是重新看整篇PRD。2.2 用AI做技术方案的预审找出你自己看不见的漏洞校招生写技术方案最容易犯的毛病是“自我感觉良好”因为经验不足很多坑根本预见不到。写方案的时候也不会有人全程帮你把细节过一遍。我的办法是写完草稿后让AI站在不同角色的视角去审方案。具体操作是准备一套角色扮演模板请你分别以下列角色审查这份技术方案 1. 资深后端工程师关注接口设计、数据一致性、性能损耗、异常处理。 2. 运维/稳定性工程师关注发布风险、回滚方案、监控告警、依赖故障场景。 3. 测试工程师关注可测性、埋点覆盖、边界条件、灰度策略。 4. 新接手该模块的校招生关注文档是否清晰、能否独立理解并落地。 每个角色至少提出3个具体风险点不要只说“这个没问题”必须给出理由。这套模板帮我在一次存储方案设计里提前发现了兼容性问题。当时我想引入一个新的缓存字段来存用户偏好方案看着没什么大问题但“运维视角”提示了一个点旧数据没有预热逻辑新字段上线后首轮请求会全部打到数据库可能导致连接池雪崩。后来我在方案里补了一段双读双写的灰度逻辑才避免了上线后可能的故障。这种视角是当时的我完全不具备的AI虽然不能替代真正的架构评审但能扮演一个廉价的全视角杠精。2.3 把需求拆成可执行的开发任务让AI产出todo清单方案确定后我会让AI把技术方案拆成开发任务清单每个任务包含目标、涉及文件、接口签名、验收标准、依赖关系、预计改动量。这一步的目的是让你自己的编码过程有节奏而不是打开编辑器后边写边想。拆任务这个环节我踩过一个坑一开始我让AI直接拆它拆出来的任务列表很漂亮但粒度完全不对——有的任务大得不得了有的又碎成一行代码。后来我发现必须在模板里给粒度标准比如“每个任务应该能在30分钟内完成初版实现超时的任务要继续拆分”。加入这个约束后AI拆出来的任务就实用多了。拆完我再人工微调一遍最终形成的todo会同步到我们内部的看板系统。3. 编码实现阶段多角色分工的AI实操方法3.1 本地IDE里的AI和终端里的AI各管一摊我现在日常编码开两套AI工具IDE里装一个自动补全型助手比如Copilot或者通义灵码终端里再开一个能读仓库的编程智能体比如Claude Code这类能自己改文件、跑命令的工具。两者分工不同。IDE补全工具干的是“短距离填空”负责把已经想好的逻辑快速补完变量名、函数体、样板代码这些用补全很爽因为它不需要跨文件理解只需要顺着当前上下文顺滑地往下走。终端里的Agent工具则负责“长距离任务”比如“帮我在pkg/user/repository里新增一个查询接口按order_time倒序注意要加索引提示再给这个接口补上单测”它需要理解仓库结构、约定风格才能产出靠谱的东西。我实测下来的结论是如果只开IDE补全写小函数效率高但遇到跨模块改动时它频频跑偏如果只开终端Agent整体生成能力强但细粒度补全时有点笨重。两个配合是互补的关系。3.2 写好种子代码再让AI生成而不是让它从零编很多同学用AI写代码失败是因为让AI“从零写一个功能”。它没有方向只能从训练数据里找一个最像的函数来拼接。大厂内部代码库里有很多约定比如错误处理必须用统一轮子日志必须带traceId配置项必须走配置中心这些约束AI看不到所以它写出来的代码经常风格对不上。我摸索出来的方法是“种子代码 约束清单”。先自己花5分钟搭出核心结构比如函数签名、类型定义、错误处理骨架然后在注释或者单独的指令里告诉AI本模块错误码前缀是UC_不要自创。日志必须通过logging包的GetLogger获取禁止使用fmt.Println。所有外部依赖必须走接口注入不要直接new。数据库操作使用仓库层的标准封装不要裸写SQL。这部分很关键种子代码定义了骨架约束清单定义了规则。AI在两者夹缝里发挥产出的代码质量一下子高很多Review时也很少被要求返工。3.3 上下文管理让AI始终看到该看的东西AI Coding最常见的翻车原因就是上下文失控。仓库很大工具记不住全部你不在同一段会话里给它关键信息它就只能瞎猜。我的做法有三个一是把关键约定写进仓库根目录的说明文件让Agent每次启动时先读一遍。比如模块结构、代码风格、常用命令、测试入口都在里面写明。这相当于给AI一份“员工手册”。二是会话内只聚焦单个任务做完就开新会话。千万不要在一个会话里连续塞十几个文件让AI一起改它会前后混淆。一个会话修一个模块改完验证完再开下一个。三是在重要任务开始前手动把相关文件路径和关键函数签名喂给它不要依赖工具自己去“探索”。“探索”会花掉大量上下文额度等它真正开始写代码时上下文快满了反而容易出错。3.4 AI生成代码后我做一轮强制自检AI生成的代码不能直接提交这是我这边的铁律。每次拿到AI代码后我会检查这几项有没有用AI幻觉出来的API。检查方式是把涉及的外部包和函数名一个个手动确认尤其是新引入的依赖。边界条件是否完整。AI最擅长写“主流程”最容易漏掉空值、超时、并发、重复请求这些边角。错误处理是否统一。AI喜欢给每个错误分别返回不符合内部约定。日志是否可追踪。每条关键路径都要有日志日志里要带关键参数而不是笼统写一句。这套自检流程我在前面说的配置中心事故之后写成了一份自查表每次提交前过一遍。别嫌麻烦AI生成的代码确实“看起来太对了”不逐项检查真会被带沟里。4. Code Review与测试阶段让AI当第二双眼睛4.1 分层ReviewAI先审一遍人工再审主题现在我们的团队已经形成了“AIReview 人工Review”的分层模式。AI先做机械性审查比如代码风格、明显bug、缺少注释、魔法数字、重复代码这些交给AI刀快但AI不会做逻辑正确性判断也不会判断这个改动是不是产品想要的所以人工Review必须聚焦在变更意图和架构影响上。我一般是提交MR之前自己先跑一遍AI Review工具把反馈里合理的部分改掉再把AI报告一并贴到MR描述里。这个动作看着简单实际很加分——评审人打开MR时看到的不是一个只写着“fix bug”的空描述而是带着自动检查报告、变更影响说明、测试记录的完整提交。评审人心态会好很多回复速度也明显快。4.2 让AI补全测试用例重点补异常分支而不是主路径写单测很耗时但又是校招生必须练的基本功。我的习惯是让AI先写主路径测试自己再补异常分支和边界case。为什么不全丢给AI因为AI写的测试同样会犯“顺着实现逻辑写测试”的毛病实现怎么走它就怎么写最后测试根本测不出bug只是把代码又跑了一遍。正确的姿势是先给AI看实现代码让它列出风险点和边界场景清单再基于这些场景写测试写完测试后我会故意把某个逻辑改错验证测试能不能抓出来。这招叫“mutation测试思维”不需要真的引入框架只要抽查几个case就好。如果测试跟着逻辑一起错说明测试形同虚设要重新写。4.3 用AI做变更影响分析减少低级回归大厂代码库模块依赖非常复杂你改了一个函数可能影响十几个调用方。以前我只能靠IDE的全局搜索一个个看效率低又容易漏。现在我会把变更文件列表和差异摘要丢给AI让它分析影响范围、依赖链路、潜在回归点并输出一份影响清单。这一步的操作要点是给AI的diff要精简不要贴整个大文件只贴变动的代码块。另外要明确告诉它“不要输出建议只输出影响面”否则它会自动开始提优化建议虽然看着热闹但可用性低。我实际用的Prompt是这样以下是本次变更的代码片段。请分析 - 被改动函数的所有直接调用路径 - 对调用方行为的潜在影响是否可能改变返回结果、异常行为或性能特征 - 可能受影响的测试用例 只输出影响清单不输出改进建议。这个方法帮我提前拦下过一次线上回归所以我对它的信任度比较高。5. 文档、联调与上线的效率杠杆把AI从编码工具变成流程工具5.1 让AI生成接口文档但必须人工确认后再发出去文档在开发流程里被严重低估。刚入职时我觉得文档就是给团队走的过场后来发现接口文档不清晰联调阶段每个问题都要拉群问浪费时间远超写文档的时间。现在每次写完接口我会让AI基于代码生成一份接口文档包含请求示例、参数说明、错误码表、边界行为。这里有个值得提醒的点AI生成的文档经常把“参数非必填”理解成“参数可以随便传”在文档里会漏掉一些隐式校验逻辑。所以AI生成的文档我每次都会对标代码过一遍尤其是参数校验和数据格式然后才会发给下游团队。联调时再配一版用真实请求跑出来的样例几乎不会被人追问第二遍。5.2 联调排障时让AI做日志翻译工联调阶段最耗时的是拿着日志一点点追问题。我们现在内部的标准习惯是结构化日志字段都是全的但排障时还是要人眼扫几百行日志。我现在的办法是把报错日志和时间段日志喂给AI让它先做语义化摘要把调用链拉出来标出异常点和可疑的耗时瓶颈。这个流程看起来简单但要对AI设置好边界必须区分“日志里明确记录的”和“推测的”否则AI会脑补出完整的故障故事而故事里的关键转折是它自己编的。教AI“区分事实与推断”很重要我一般让它这样输出请按以下格式输出排查结果 1. 日志事实列出日志中直接记录的异常、状态码、时间点。 2. 链路还原基于日志事实还原请求处理过程标注每一步发生的先后与耗时。 3. 可疑点推断基于上述事实给出候选原因每条都标注“推断”或“确定”。这样做的好处是我自己能快速掌握故障概况需要深入时重点看规范化日志中的疑点链路把原本需要半小时的日志排查缩短到几分钟。5.3 上线检查清单与发布说明自动化上线是最容易让人紧张的环节尤其是校招生第一次独立上线。我的流程是上线前让AI基于变更内容生成发布说明和执行清单。发布说明包含变更目的、影响模块、依赖的服务、是否需要数据迁移、回滚方案执行清单包含上线步骤、验证点、监控指标、回滚触发条件。需要注意AI生成的执行清单只能作为参考底稿最终必须由负责人确认。我见过有同事直接把AI生成的发布说明贴到群里结果里面写了“该接口应该加缓存”但实际代码里根本没加。究其原因就是AI把“建议”混进了“事实”。现在我在模板里明确区分“本次变更事实”与“优化建议输出”防止这类事件重演。6. 常见问题与避坑实录6.1 AI把“看着正确的API”写进代码怎么办这在我刚入职时发生过AI引用了某个内部包的API运行起来直接报未定义。根因很简单AI的知识来自公开代码和文档而大厂内部有很多私有包和内部版本它不知道。现在我的强制手段只有一个引入新依赖或调用不熟悉的API时必须手动确认该API在当前代码库中真实存在不确认就不提交。查证方法包括直接看包源码、看仓库里已有调用示例、以及问组里的老同事。6.2 上下文超长之后AI开始胡说八道长会话里AI跑到后面会混乱尤其你让它同时记着“旧接口逻辑”和“新改动方案”时它极有可能在改到一半时把两者混在一起。我的解决办法是一个会话只做一个任务任务做完立即开新会话重要信息用简短要点重新贴进新会话而不是依赖原会话的“记忆”。遇到复杂问题要来回讨论时把关键结论先写入本地文件再重新加载避免在对话历史里无限翻滚。还有一点值得留意我们做AI流程编排时有时会陷入“先让AI生成方案再让AI按方案实现”的循环这很消耗项目预算和上下文。现在锁定方案后我会把最终方案固化成简短版任务描述所有上下文以该描述为准成员只按简版去处理。6.3 AI生成的代码风格和团队风格不一致引发Review大战一开始我提交的AI生成代码总被同事说“这代码风格不像模块内的风格”。后来发现AI是按照GitHub上那些知名开源库的风格来写的而内部老模块的风格是几十个人多年沉淀的结果差异巨大。解决办法就是把团队代码风格的关键要求写进AI的约束文件里包括缩进、命名、注释语言、错误处理、日志规范等。这事要团队统一做如果每个人各搞一套提示词风格还是乱。6.4 权限和合规红线哪些代码不能喂给AI大厂对代码外发很敏感这一点校招生一定要重视。我的原则是内部代码、含客户信息的配置、密钥相关内容绝不喂给个人外部AI工具。只能使用公司内部部署或明确允许的AI工具处理内部代码。让AI生成代码时涉及敏感逻辑只提供抽象的伪代码结构不粘真实实现。这条的重要性不亚于代码本身。刚来的同学容易图方便把所有上下文都丢给AI一旦涉及敏感信息轻则被安全约谈重则影响绩效。切记。6.5 实测收益和边界AI Coding没有想象中的神话最后说点真实数据。我目前的个人效率大概在这几个维度有可见提升常规增删改查和单测编写类任务提速约40%到50%跨模块理解和排障类任务提速主要靠减少搜索时间体感明显但没有统计得那么精确方案设计和评审类任务提速不多但质量提升明显相当于多了一个穷举所有可能性的助手。但同时也要承认边界AI在我完全不熟悉的领域并不比随机搜索更好用。尤其是那种连需求本身都很模糊、业界也没有成熟方案的任务AI给的答案基本是“热门方案拼接”不具备真正的新颖设计能力。它更适合被当作一个“思维外挂”和信息聚合器而非替代思考的决策器。所以成熟的AI Coding工作流核心从来不是“AI有多强”而是“人在什么节点介入、用什么方式校验”。写到这里把自己一年多的弯路和习惯都摊开来了。如果你也在把自己的AI Coding工作流推向深入我的建议很朴素把AI当新同事而不是万能工具给它清晰的任务边界、规则手册和上下文再在关键节点用人工卡住质量。校招生的成长靠的不是把代码写得飞快而是把每一段代码为何这样写、这样写会影响什么想清楚——AI能把“写”变快但“想清楚”这件事终究要落在自己身上。
