入职第三个月mentor 把一个需求页面丢给我“这个你来从评审到上线全跟。” 我盯着需求文档第一反应不是打开 IDE而是打开 AI 插件让它先把需求拆一遍。那时候我刚被 AI 生成代码救过好几次也被它坑得加班到凌晨。也是从那个需求开始我正式把自己的一套 AI Coding 工作流固定下来不再把 AI 当成“偶尔问一问的搜索引擎”而是把它作为完整开发流程里的固定协作者。这篇文章想聊的不是某个工具的广告也不是“AI 会取代程序员”的焦虑帖。我想完整拆开我作为校招生怎么把 AI 接入需求分析、技术设计、编码、测试、Code Review 和文档输出这六个环节以及踩过的那些坑。适合正在用 AI 写代码但总觉得“差点意思”的同学也适合想给团队引入 AI 协作但不知道怎么下手的工程师。1. 为什么一个校招生要折腾一套 AI Coding 工作流1.1 校招新人最大的痛点上下文断裂大部分校招生刚进组时的状态不是不会写代码而是“不知道自己在写什么代码”。接到一个需求背后涉及哪个老系统、哪些服务在调用、数据长什么样、有没有历史包袱这些信息不在任何文档里只散落在老同事的脑子里。新人最常见的动作是一个个问问多了自己都心虚。AI 在这里的核心价值不是“帮你写代码”而是“帮你缩短上下文重建的周期”。我试过的做法是把需求文档、相关接口定义、报错日志直接丢给 AI让它先帮我梳理出“哪些信息我还没掌握”。它会把模糊点列出来我再拿着这份清单去找同事确认沟通成本一下子低了很多。但这里有个关键点上下文信息如果不主动维护AI 每次都是“失忆”的。我见过很多同事把 AI 当对话工具问完一个需求就关窗口下次重复问一模一样的问题。真正的工作流应该让 AI 在项目里持续积累背景知识而不是每次都从零开始。1.2 我把 AI Coding 工作流拆成了六个环节很多人对 AI Coding 的理解停留在“IDE 里弹补全代码”。但我的工作流是把 AI 嵌入到需求、设计、编码、测试、审查、文档六个环节。每个环节 AI 的角色和人的角色完全不同我习惯用下面这个分工表来定义边界。环节AI 的角色人的角色核心产出需求理解提炼模糊点、拆任务对齐业务预期、拍板范围任务清单与验收标准技术设计生成初稿、给备选方案做取舍、定边界设计文档或接口草案编码实现补全、生成函数、写单测控制提交粒度、做逻辑复核小而清晰的 commit测试联调生成测试用例、Mock 数据补充边界值判断断言对不对可运行的测试集Code Review初筛 diff、找隐患做最终判断、维护代码风格干净可合入的代码文档沉淀生成初稿、整理注释核验真实性、补充决策背景可被别人接收的文档这张表看起来简单实际执行时最难的是后两列。AI 的角色实现起来都不难真正要盯住的是人的那列一步都不能省。我一度偷懒跳过 Review 环节结果 AI 生成的代码带了一个不大不小的事务问题上线后出了脏数据那个印象足够深。1.3 工作流设计的两条原则这套工作流能跑起来靠的不是某个工具而是两条原则。第一AI 只做可以回滚的事。生成一个函数、补一个测试、写一版文档草稿都是可以丢弃的产物错了重来损失很小。但它不能直接推代码到主干不能绕过 Code Review不能在没有验收标准的情况下宣布“需求完成”。第二每个环节都要有检查点。需求拆解后要你自己三连问“这是不是产品真正要的”AI 生成的设计稿要有人拍板AI 单测通过不代表业务正确。检查点不需要多但必须在关键位置存在否则 AI 的错误会一路滑到生产环境那时候排查成本就完全失控了。把这两条想清楚工具选型才有意义。我见过有人一口气配了五六个 AI 插件结果每个都用一个案例就吃灰原因正是没想清楚“让 AI 干什么、让 AI 干到哪一步”。2. 工具链选型不是堆工具是让每个环节有分工2.1 编码主力IDE 插件与单文件级补全编码阶段最常用的还是 IDE 里的 AI 插件。市面上选择很多Copilot、Fitten Code、Continue、通义灵码等等我用过至少四款。选择标准其实很简单补全响应速度要快上下文感知要好不要频繁打断思路。我的主力配置是主开发 IDE 装一个补全类插件用于方法级和代码块级的生成遇到复杂重构时再用独立的对话窗口把选中代码喂给大模型。之所以这么配是因为补全类插件在“你正在写一个排序逻辑”这种场景下非常强但让它跨多个文件理解业务时往往表现一般因为它看到的上下文太窄。这里有个经验同一段逻辑补全插件可能给出很自然的实现但如果你把整个文件和相关调用链都贴给对话模型质量会明显不一样。所以编码阶段我会根据任务粒度切换工具而不是迷信某一个“最强”。2.2 自动化执行CLI Agent 做“脏活累活”当任务不再是一个函数而是“把整个模块里的日志打印规范统一一下”、“给这五个接口都补上参数校验”这种批量操作时单纯靠 IDE 插件就不够了。我逐步开始用 CLI 形式的 Agent 工具比如 Aider、OpenCode 这类。这类工具的核心能力是它能看见你的 git 状态、能读整个文件树、能自动执行测试命令来验证自己的修改。我第一次实测的感受是它比“复制粘贴到对话框”强在能自己循环“改代码—跑测试—再看结果—再改”。当然CLI Agent 也不是万能。它会比较“自信”有时候一口气改十几个文件而你自己根本来不及看。我的用法是严格限制改动范围每次只给它一个明确的子任务并且要求它逐个文件列出改动原因。让它批量干活的前提是你跑的测试足够快也足够准否则它拿错误反馈去“自我修正”会越改越乱。2.3 流程串联Dify、Coze、n8n 扮演的角色只靠 IDE 和 CLIAI 参与的每个点还是散的。真正让工作流“成流”的是外部流程编排工具。我会用 Dify 或 Coze 搭一些固定流程比如需求拆解、简历筛选、周报生成用 n8n 把跨系统的动作串起来比如代码提交后自动触发一轮 AI 初筛检查。一个我反复在用的场景产品在协作平台里贴了需求文档我把它转成一个固定的“需求理解工作流”先让模型读文档产出业务目标再列出技术风险再生成任务清单。这个流程跑一次不到一分钟但比我手动梳理快得多关键是每次产出的结构一致后续对接更容易。搭这样的流程时最需要注意的是“上下文超长”。我一开始把整个几十页文档全塞给一个节点结果模型把握不住重点。后来调整成两段式第一段先让一步抽取关键词和范围第二段再基于这些重点做任务拆解信息密度高了很多输出质量也稳定。2.4 上下文基建规则库与代码检索缺一不可无论工具链多豪华AI Coding 真正拼的是“喂给模型的上下文质量”。我现在的做法是维护团队自己的规则库把常用技术规范、接口约定、错误码规范写进去让模型在生成代码时优先服从这些约定。这比每次在提示词里重复“请遵守我们团队风格”要可靠得多。代码检索也很关键。我很少把整个仓库塞进上下文窗口根本装不下也没必要。可以借助 RAG 或者仓库级别的代码检索让 AI 只看到相关实现。比如改支付回调逻辑就只需要相关的服务类、表结构、回调处理入口而不是把整个订单系统都拉进来。这个思路本质上是把“上下文”当成一种需要刻意设计的基础设施。工作流能不能稳定很多时候不取决于模型多强而取决于你有没有给它搭好“该看什么”的路径。3. 实操拆解AI 是怎么一步步进入我的开发流程的3.1 需求阶段先让 AI 问问题再让它列任务刚入组时我最大的问题是“不敢确认需求”。产品说一句“这里要支持批量导出”我脑子里全是“导入导出组件怎么写”而不是问清楚“导出多少量级、什么格式、超时怎么处理”。现在我会让 AI 先把需求“逼问”一遍。我用一个固定模板来启动需求环节你是一个中后台业务的开发工程师。下面是一条来自产品经理的需求描述。 请完成三件事 1. 列出需求中不明确的点按“影响开发方案”的优先级排序 2. 把需求拆解为可执行任务每个任务标注输入、处理逻辑、输出 3. 明确哪些任务存在技术风险或依赖外部系统。 不要写代码不要臆测需求。 需求描述粘贴这个模板的效果是“逼”我把需求文档读完整因为 AI 列出的问题我要一条条去确认。需求拆解出来的任务清单我会直接当成自己的开发待办每个任务对应一个 commit 或者一个 MR粒度非常清晰。这个过程里AI 的角色是梳理拍板的人永远是我。3.2 设计阶段让 AI 出初稿我负责打钩和打叉技术设计是最容易被跳过却最不能跳过的环节。我的做法是把需求任务清单、现状代码片段、核心表结构发给 AI让它生成接口设计或数据库设计初稿。注意是“初稿”出来的东西我至少会改掉一半。举个例子有一次要做一个“运营手工调整用户积分”的接口。AI 初稿直接给了个 PATCH 接口字段就是“用户 ID 调整值 原因”。看起来没什么问题但我们的风控要求“任何积分变动必须留审计日志、必须有幂等键、必须走异步审核”。这些约束不在它看到的上下文里所以它没设计进去。我做了两处调整增加幂等键字段调整成“提交待审核”和“审核通过后执行”两步接口。我的体会是AI 在常规 CRUD 设计上已经很像一个“合格但平庸”的工程师但业务约束和异常路径还得人来补。设计阶段的高效姿势是把 AI 生成的初稿当成一个结构化草稿省掉从空白到骨架的时间但精力要花在查漏补缺上。3.3 编码阶段小步快跑每次只放一个小任务给 AI编码阶段我犯过的最大错误是让 AI 一次性生成一个大文件。文件越长逻辑越绕AI 越容易在某个分支里自圆其说地写错。现在我严格遵循“小步快跑”一次只给一个小任务比如“实现一个方法完成订单状态从待支付到已支付的流转”。针对这个小任务我会把相关的状态定义、异常类型、表字段贴全再加上一句硬约束“只修改这个方法内部的逻辑不要改动其他函数”。这样 AI 的产出是可控的review 起来也快。AI 写单测也是同样的策略。我会要求它给刚实现的函数补一组单元测试覆盖正常路径、空值、异常分支。它生成完以后我会补几个它想不到的边界值比如时间边界、金额为负、并发重复提交。这个习惯帮我挡了不少线上问题。3.4 测试与联调阶段AI 生成 Mock 和辅助排查联调阶段AI 的价值经常被低估。我以前最怕搭测试数据几个接口之间有关联状态手工造数据要半天。现在我会把接口文档和已有的数据模型丢给 AI让它给我一段 Mock 数据的生成脚本或者一组 Python 脚本用来快速初始化数据库状态。在排查问题的时候AI 也很有用。把日志片段和代码位置贴给它请它列出异常可能的所有路径再标注最可能的两三个。注意这里不能让它直接“判断原因”因为日志只是信息不全的切片AI 很容易基于错觉给出自信但错误的结论。我会把它的输出当成排查清单顺着清单去验证而不是当成最终答案。3.5 Code Review 与文档AI 的“第二双眼睛”我自己的代码提交前会先让 AI 按“Review 视角”过一遍 diff。提示词大概是请审查下面的代码 diff按三个级别输出问题 - 严重可能导致逻辑错误、数据不一致、安全问题 - 建议代码可读性、性能隐患、未考虑的场景 - 提问信息不足需要作者补充说明。 不要夸代码写得好只看问题。 粘贴 diff这一步相当于给自己找了个不用等 review 的初筛工具。很多低级错误比如空指针、资源没关闭、魔法数乱写AI 都能一眼揪出来。但它的审查也有盲区尤其是“这个业务是不是该这么做”这种问题它判断不了只能靠人工补完。文档环节也一样。AI 生成的 README 和接口文档我会明确要求“不要虚构参数和逻辑只看代码和配置提取信息”。生成的初稿我还会亲自对着代码过一遍重点检查有没有把某个环境变量写错、有没有漏掉鉴权说明。文档里的“看似合理但其实是错的”比“没有文档”更坑人。4. 避坑实录踩过这些坑你的工作流才真的稳4.1 上下文污染AI 记性太好反而坏事工作流用久了会出现一个隐蔽问题同一会话里聊过需求 A 和需求 B再做需求 C 时AI 会把前两个需求的信息带进来生成一段“融合了 AB 风格”却不符合 C 逻辑的代码。我管这叫上下文污染。解决办法是给对话/任务建“会话隔离”。不同需求用不同会话不混在一个窗口里连续处理。尤其在用 Dify 这类工作流时也要注意每个流程节点应该只接收当前任务需要的字段不要贪方便把整堆上下文都传下去。现在我的原则是宁可让 AI 少知道一些也不要让它知道一堆无关的东西。4.2 幻觉比报错更可怕如何验证 AI 输出AI 报错不可怕大不了重新生成。它编一个不存在的函数、虚构一个不存在的字段、或者把一个方法参数名写对了但内部逻辑完全跑偏这种“自信的幻觉”才是事故来源。我的验证方法很朴素AI 写的代码我至少要对关键分支逐行读一遍AI 生成的文档必须对照代码核验AI 提到的工具或配置去官方文档看一眼不盲信。有时候我会让它“说出每个关键决策的来源”虽然它可能会编但至少会让我多留个心眼。总之把 AI 当实习生用它做完的东西你要 review 才能收。4.3 代码风格与维护AI 写得快但全队要能接手AI 生成的代码风格往往“向平均看齐”不一定符合团队现有约定。比如我们团队统一用某个日志框架AI 默认用 print我们要用枚举做状态管理AI 给你写字符串常量。这种问题不能靠事后纠偏而要在上下文里自带规范。我现在会把团队的代码规范摘要写进项目专属的规则文件里让 AI 在生成时直接遵守。如果项目已经积累了不少历史代码还可以让 AI 先“学习”现有代码风格再生成同类代码。这样产出的代码老同事 review 时违和感会少很多。4.4 安全与合规红线什么能喂给 AI什么绝对不能这是我在大厂里被反复强调、自己也最在意的点。AI Coding 再方便也不能把线上真实数据、用户隐私、密钥凭据直接丢给未经公司审批的外部 AI 服务。团队内部如果接入了统一的大模型网关或私有化部署服务才可以通过正规渠道使用。我的安全习惯有三条第一条本地开发绝不在提示词里粘贴密码、token、证书私钥需要用到的敏感配置一律用环境变量占位符代替第二条涉及用户数据的排查类任务先脱敏再提问第三条对外部工具保持警惕不要为了“功能好用”而去用一些来路不明的工具或插件合规风险比效率更重要。把这条放在避坑里是因为很多人不是不重视而是忙起来会忘。我自己就差点把一段含密钥的配置贴进对话窗口最后是“先脱敏再提问”的习惯救了回来。4.5 问题排查速查表常见问题与处理办法我把自己在实际使用中碰到的问题整理成了一张速查表方便对号入座。现象可能原因处理办法AI 生成的代码与项目风格差异大上下文缺少团队规范在流程中加入规则文件和代码风格示例多轮对话后回答质量下降上下文过长或污染切割会话只保留当前任务相关信息AI 引用了不存在的函数训练数据过时或幻觉要求 AI 给出引用位置逐条核验批量修改时改坏了无关文件任务边界不清晰限定文件范围逐个 diff 检查后再提交AI 单测全绿但业务还是出错测试断言写错了方向人工检查断言是否对应真实业务逻辑需求拆解偏离产品意图提示词缺少业务背景补充角色和目标描述让 AI 先问问题再拆解这张表不是一次总结出来的是踩坑后一点点攒的。每一行背后都是一次线上报警或者一次被人约谈的教训。5. 效果评估与后续扩展5.1 接入前后的一组个人数据说了这么多还是得看点实际变化。我拿自己独立负责的一个中台需求做对比口径是“同样是我一个人完成同类任务规模和复杂度”。指标之前纯人工接入 AI 工作流后需求拆解与模糊点确认半天到一天一到两小时接口设计与评审准备大半天半天且备选方案更全核心编码不含思考两天一天单元测试覆盖40% 左右补不动80% 以上AI 愿意写我也愿意审文档产出经常拖到下周提测前就能出初稿返工次数三次以上一两次且每次都能在更早阶段发现必须说清楚这不是“AI 一个人省下来的时间”而是“我把自己从大量机械劳动里解放出来把时间花到 review、边界思考、业务对齐上”之后的结果。同样一个功能如果闭眼让 AI 生成然后直接提交返工时间会翻倍。5.2 连续使用 AI Coding 后我对“工作流”的理解变了刚开始我理解的“AI Coding 工作流”就是一串“提示词 插件 自动化节点”。用了一段时间以后我发现真正稳定下来的其实是人自己的做事节奏需求有没有拆干净、设计有没有人拍板、代码有没有小步提交、测试有没有覆盖边界。AI 只是把这些环节里的重复劳动加速了。我现在的项目里AI 不是一个孤立工具而是嵌在从需求到上线的每个检查点里。它帮我处理理解、生成、初筛这些耗时环节而我集中精力做判断和兜底。这套协作方式让我一个校招生在经验不足的情况下也能把交付质量拉到一个相对稳定的水平。5.3 下一步让 AI 从工具变成“成员”现在我最想继续做的事情是把流程里那些已经足够稳定的环节交给 AI Agent 去自主执行。比如“接口文档初稿生成—格式自检—发起评审提醒”这套流程已经不需要我每次手动触发了可以让它按规则自动跑。还有代码提交时的规范检查也可以让 Agent 在 CI 阶段直接拦截不合规的提交。当然这需要更健全的权限控制和规则兜底。如果计划顺利未来 AI 头衔可以是“组里的半个新成员”它写代码我们 review它出文档我们核验它做初筛我们做裁判。工具会一直变但这个协作骨架大概率能延续下去。最后补一个我自己的小私心建议别一开始就追求“全流程 AI 化”先挑一个你每周都在做、且最烦的环节把 AI 嵌进去跑两周感受一下工作流到底是什么。等你在一个环节里真正用顺了再复制到下一个环节。我就是从“让 AI 帮我拆需求”这一个点开始慢慢铺成现在的全流程。