入职第三周我用AI改写了一段核心服务的缓存逻辑。改动本身不大AI甚至在文件里补好了注释本地单测也跑得全绿。上线后第二天凌晨线上告警突然炸了回滚之后查原因问题出在一个我从没注意过的边界假设上那段缓存逻辑的调用方在某种异常场景下会传进来一个非标准类型而AI在生成代码时非常自然地替我做了一个“正常参数”的假设。这个假设在90%的情况下都成立剩下10%直接拖垮了缓存命中率。那天之后我认真想了一件事AI Coding 到底应该以什么姿势进入日常开发是当一个帮你自动补全的插件还是把它真正接入到完整开发流程里成为需求理解、方案设计、编码、Code Review、测试、Debug 全链路的一环对于刚入职的校招生来说这个问题尤其要命。因为你对系统还不熟AI帮你写的代码越多你埋下的隐患可能就越多。这篇文章就是我搭起自己那套AI Coding工作流的全部过程包括踩过的坑、最终沉淀下来的流程节点、提示词模板以及那些文档里不会写的排查经验。1. 先从一次翻车说起AI Coding 工作流到底解决什么问题1.1 一次“看起来正确却致命”的AI改造我那次缓存逻辑的改动放到事后复盘里简直是一个标准反面教材。AI给我生成的新实现非常规整缓存key的拼接、过期时间设置、并发保护都做到了。代码风格比我自己写的还干净。可问题恰恰出在“太干净”上——它不了解这段代码在历史演进中被补了多少补丁也不知道上游某个老接口为了兼容旧数据曾经约定过“类型不对也要往下传”的潜规则。AI在生成代码时只看到了当前函数体然后自动补齐了一个最合理的类型判断。这个补齐让新代码在常规路径下表现完美却把老系统兜底容错的那条暗线给切断了。我当时漏掉了一个关键动作没有让AI告诉我“它做了哪些假设”。这件事让我想明白一个道理AI Coding 的最大风险不是它写不对代码而是它把代码写得太“合理”让review的人失去警惕。你看到它写得如此规整潜意识里就降低了检查力度。而对于一个校招生来说这种降低警惕的代价尤其高——因为你对业务上下文的理解本来就浅AI的“自信”会给你制造一种虚假的安全感。1.2 “用AI写代码”和“把AI接入完整开发流程”的差异很多人以为启用AI Coding就是装个插件、让AI自动补全、偶尔让它整段生成。这只能叫“用AI写代码”解决的是局部效率问题。而“把AI接入完整开发流程”核心是给AI在每个开发环节里定义好职责边界、交付物规范和验证标准。我把这套东西定义成自己的AI Coding工作流需求理解环节AI帮我做信息整理和遗漏点排查输出“改动范围清单”。方案设计环节AI做依赖影响分析和多方案对比输出“设计草案假设清单”。编码环节AI负责初稿生成、机械重构、单测补齐输出“可review的diff”。Code Review环节AI做第二双眼睛输出“按严重程度排序的问题列表”。测试与Debug环节AI负责日志归纳、排障路径建议输出“可验证的根因假设”。这套工作流和“偶尔让AI写个函数”最大的区别在于每个环节都有明确的输入和输出AI不是替代我做判断而是帮我放大信息处理的带宽。我自己仍然是最终决策人。校招生的视角下这套结构尤其重要——因为它把AI的不可靠性通过流程节点给拦截住了。2. 工作流设计先定节点再选工具2.1 完整开发链路里哪些节点值得接入AI我刚入组时导师给我梳理过一个典型的开发链路PRD评审 → 技术方案 → 代码定位 → 设计编码 → 自测与CR → 联调测试 → 发布上线 → 线上排查。当时我第一反应是“能不能每个环节都用AI加速”但很快发现不行。有些环节AI不仅不能加速还会添乱。比如需求评审里面涉及大量业务取舍和跨团队博弈不是AI能替你决策的。再比如发布操作大厂的发布系统对权限、审批、变更窗口有严格要求AI不该也不允许插手。我的筛选标准有三条信息密度高、重复性劳动多、验证成本低。满足这三条的环节才适合让AI进场。按这个标准筛下来值得深度接入AI的节点是代码定位、方案草稿、机械性编码、代码审查、日志分类、文档生成。不太值得硬塞AI的节点是需求拍板、接口契约谈判、发布执行。后者的共同特点是“需要人为担责”这类责任AI背不了。这条清单对校招生有个额外好处它能逼着你先把完整流程的框架画出来而不是像无头苍蝇一样被AI牵着走。先定流程再选工具顺序不能反。2.2 工具分工与选型逻辑定好节点之后工具选型就变得清晰了。我自己的分工方式是IDE内联补全类工具负责编码阶段的实时补全、单行生成、小范围重构。这类工具在写样板代码、补测试桩时效率极高。对话式大模型工具负责需求理解、方案设计、日志分析这种长上下文、带推理性质的工作。它的优势不是“码得快”而是“能一次性处理大量文本信息”。团队已有的CI/CD工具负责兜底AI生成的代码必须过编译、单测、lint、格式检查。这是工作流的最后一道硬闸门。选型逻辑上我坚持一个原则工具必须能和团队基础设施打通。你在个人编辑器里用得多爽如果它导出的代码不能顺畅过CI那它就只停留在“个人玩具”层面。我见过不少同学沉迷于某个AI工具的生成效果结果代码合入时被CI拦下十几次白白消耗了协作成本。另一个选型细节是上下文窗口。对话式工具不是窗口越大越好。窗口大了AI确实能“记住”更多东西但注意力也会被稀释。实测下来一次喂给AI的有效信息控制在它能精读的范围内比无脑堆文件效果好得多。所以我在工具选择上更看重“能否灵活指定上下文”而不是单纯比参数量。3. 全流程实操AI在每个开发环节的真实用法3.1 需求理解阶段把PRD变成改动清单大厂的需求文档通常很长动辄几十页里面还夹杂着各种产品话术和历史背景。校招生最容易犯的错是一头扎进PRD逐行读读到后面忘了前面。现在我把这个环节交给AI做第一遍粗加工。具体操作是把PRD全文贴给AI让它输出三样东西——涉及的服务和模块、可能需要修改的接口、它需要向我确认的三个关键假设。这个提示词我有一个固定模板下面是一份需求文档。请输出这个需求涉及的服务与模块清单可能需要修改的接口或数据表你在理解需求时产生的3个关键假设。 不要写代码不要提优化建议。这段输出的价值不是“正确”而是“帮我建立索引”。AI对代码库的理解再强也不如我后续拿着清单去代码里逐个核对来得准确。但它能在几分钟内帮我排除掉那些明显无关的模块让我把精力集中在真正要动的区域。实操中有个心得让AI输出“需要确认的假设”这招特别有用。它逼着AI暴露理解上的含糊点而不是把不确定藏在生成结果里。后来我每个环节的提示词里都加了这个要求翻车率直线下降。3.2 方案设计阶段让AI做预审和影响分析技术方案是我最谨慎的环节也是AI最容易被高估的环节。我见过有人让AI直接写一份完整技术方案然后拿着去评审结果被老同事连环追问“这块的历史包袱你考虑了吗”现场直接沉默。我的做法是把AI定位成“预审员”不是“方案作者”。我先自己基于改动清单拟一个大致思路然后让AI做两件具体的事第一列出这个方案可能影响到的存量行为清单第二给出2到3个备选实现路径并对比取舍。这里有个关键经验必须给AI提供足够的约束材料。光说一句“帮我设计一个缓存改造方案”AI生成的方案一定飘在空中因为它完全不知道这个项目的技术栈、历史包袱、团队规范。我会把相关模块的现有代码摘要、接口定义、甚至一段典型的调用链贴进上下文再让它基于这些约束做分析。做完分析之后我会额外要求AI输出一句“这个方案里你们项目可能需要特别注意的历史兼容性点”。这句话往往能命中我容易忽略的老接口兼容问题。同样地这只当作预审参考最终决策一定要自己拍板。3.3 编码阶段半自动模式的输入输出规范编码环节是我使用AI最频繁、也最需要纪律的地方。我的模式可以总结为“半自动”AI负责初稿我负责验收。我给自己定了几条硬性规则一次只让AI改一个文件或一个函数禁止一次生成跨多文件的大改。动手之前先让AI说清楚“这段代码的改动范围和影响面”。生成之后必须人工跑一遍diff逐行看AI改了哪些内容。所有AI生成的代码提交前必须过编译、单测和lint这没有商量余地。为什么“一次只改一个文件”因为AI在多文件协同改动时很容易出现两边代码不一致的情况——这边改了接口签名那边调用处没同步改编译器能拦住的还好拦不住的就是隐性bug。一次只改一个文件把误差限制在可控范围出了问题也能快速定位。批量改动的场景AI特别适合做机械性劳动。比如重命名一个被几十处引用的公共方法或者把某段重复逻辑抽成公共函数这类操作AI做得又快又稳。但我会在批量操作前额外做一次全量编译单测确保白名单内的机械改动没有漏网之鱼。我一直把AI当成“初稿生成器”而不是“正确代码来源”。聊天界面里生成一段代码和合入主干生产环境的代码中间差着整整一条流水线。凡是AI生成的代码最终都要经受和手写代码一样的review标准这一点必须提前想明白。3.4 代码Review和单测补齐我们的CR流程是提交后必须有一名以上同事review。刚入职时我最怕的环节就是CR因为思考不周全很容易被问住。现在AI变成了我的“预检员”。我的标准做法是自己先做一轮严肃的自审然后把改动后的代码贴给AI让它以“挑刺者”的身份输出问题列表。注意这个提示词措辞很关键。请以一个严格的代码审查者角色只寻找这个diff中的问题bug、边界条件、并发安全、与需求文档不符的地方。不要提代码风格优化不要夸代码写得好。请按严重程度从高到低排序输出。这里为什么要明确说“不要提风格优化”因为我测试过如果提示词写得很宽松AI给的建议有一半是“建议把变量名改成更有意义的词”这种不痛不痒的话真正致命的逻辑漏洞反而被淹没了。把它的任务窄化成“只找bug”效果会好很多。单测补齐也一样。我让AI生成测试用例时会专门加一句“请附上每个测试的意图”。这样做有两个好处第一review的人能一眼看出这个测试在验证什么第二能防止AI写出“顺着实现来”的同义反复用例——那种用例看着覆盖率高其实换个错误实现照样绿。这里有一个新人才容易踩的坑让AI写实现又让AI给这个实现配套写单测最后提交的是一套“自己验证自己”的测试。AI生成代码时脑子里已经有一个正确答案的状态顺着这个状态去补测试自然全绿。所以测试意图必须人工确认至少要想明白“这条测试到底能不能代表需求”而不是它能不能跑过。3.5 Debug、日志分析与发布辅助线上出了问题最着急的时候其实是信息过载的时候几百行堆栈、几十个异常关键字、前后端一堆报错人眼根本扫不过来。这种情况下我会先让AI做日志归纳。具体方法是把脱敏后的日志丢给AI让它做三件事按异常类型聚类、找出出现频率最高的错误模式、给出最可能的前三个根因假设。注意这里我又用了同一个套路——让AI先给“假设”而不是直接给“结论”。因为排障现场一旦带有预设结论很容易把排查方向带偏让AI把可能性按概率列出来我自己再逐条去验证稳妥得多。发布环节我只让AI做辅助不让它碰任何命令。比如让AI根据diff生成变更说明或者让AI根据历史回滚记录整理一份回滚建议。这些文档类工作是AI的舒适区同时又不涉及实际变更权限风险可控。真正的发布还是要走人工审批流程这是我给自己划的绝对红线。4. 工作流能跑起来的关键上下文与提示词管理4.1 项目上下文怎么“喂”给AIAI Coding工作流里有一个非常容易被忽视的地基上下文管理。同样一个AI给它喂了项目上下文和没喂上下文产出的质量能差出一个量级。我一开始犯的错是把所有相关资料一次性塞给AI觉得它窗口大、能记住结果它记住是记住了但重要信息被淹没在大量无关文本里输出质量反而更差。后来我换成了“分层喂养”的方式第一层项目规则快照。在项目根目录维护一份类似RULES.md的文件里面写清楚技术栈、目录结构、命名规范、常见的坑。这份文件相当于给AI的一份项目入职手册每次会话开始先喂它。第二层核心类型与接口定义。改动一个模块之前先把这个模块的核心类型定义、关键接口签名贴给AI。有了这些约束AI生成的代码至少能对上接口不会出现类型对不上的情况。第三层按需深入。当AI需要理解某个具体逻辑时再把那部分代码摘出来喂进去而不是带着整个文件。这样做的好处是让AI聚焦在真正关键的信息上减少干扰。这个分层思路是从一次失败的会议纪要里学到的当时把整个仓库说明文档贴给AI让它帮我梳理一个模块的调用链结果AI被大量无关模块带偏梳理结果漏洞百出。后来我改变输入方式每次只给与本次改动相关的文件摘要准确率提升了一个级别。4.2 提示词模板的沉淀方式工作流稳定之后我开始有意识地沉淀提示词模板把它们按场景存进团队文档里。目前积累下来的几类模板分别是需求分解、风险审查、代码评审、日志归纳、测试意图生成。每个模板我会保持固定的骨架角色、任务、输入格式、输出格式、禁忌事项。这里“禁忌事项”是我特别强调的而且它不是一个初始就有的字段而是从事故中长出来的。我举一个例子。代码评审模板刚用时AI经常输出一堆“可以考虑用更现代的API”这类建议把真正重要的bug淹没掉。于是我在模板里加了一条禁忌“不要提优化建议不要夸代码”。从那之后输出质量立刻改善。后来每隔一段时间我就会复盘一次翻车案例看看到底是提示词没约束住AI还是我的工作流缺了一个环节然后把发现沉淀回模板里。给校招生一个诚恳的建议不要迷信市面上流传的“万能提示词”那些模板拿去用大概率为你的项目水土不服。提示词是喂出来的不是抄出来的。最有价值的模板一定来自你自己的翻车经历因为只有你知道自己在哪一步最容易失控。5. 常见问题与排查经验实录5.1 AI代码“本地绿、线上崩”的排查思路这类问题是最让人崩溃的因为它前期表现往往非常完美。我自己那次事故就是典型。排查的逻辑链是这样走的先确认线上行为和新代码的关系通过开关回滚或灰度对比定位到具体改动然后把那段改动的diff逐行过一遍特别关注“AI替我做假设”的地方——比如类型断言、空值处理、边界值判断、异常吞掉等。最终发现AI在一个异常分支里做了一个“正常参数”的假设而这个分支恰好是历史兼容逻辑的关键路径。这类问题的工作流级解法是在上游就拦截掉。我后来强制所有AI辅助的功能改动必须输出“假设清单”并在CR时逐条核对。只要这条假设清单没被确认改动就不允许合入。这个强制规定实施之后我经手的AI改动再没有出现过“本地全绿、线上翻车”的情况。5.2 工作流失灵的几个典型场景再完善的流程也有意外。我遇到过的典型失灵场景有三个给同样踩坑的朋友做个参照。第一个是上下文污染。一个长对话会话里前面已经讨论过两轮需求改动第三轮我让AI生成新功能的代码时它还在沿用旧需求里的约束产出的代码明显偏题。解决方案是一个会话只负责一个任务换需求就开新会话不要贪图省事把多个改动塞进同一个上下文里。第二个是“工具正确但流程没跟上”。有些AI工具确实能自动扫描整个代码库给出很详细的上下文索引但我发现它经常把一堆无关文件也带进分析导致AI信息过载。后来我改用人工指定核心文件的方式反而更稳。工具能力再强你要为它设置一个明确的信息边界。第三个是团队协作层面的失灵。同事看到你提交的代码风格和他习惯的不一致会追问“这块是不是AI生成的谁审查的”这时候如果没有人替AI的产出担责协作就会卡住。我的解决方式是让AI生成代码遵循团队现有规范并且在CR描述里明确标注“AI辅助生成已人工审查”既透明又明确权责。5.3 团队协作中AI代码的落地产出路径最后说一点关于团队协作的个人观察。校招生在团队里使用AI最关键的不是展示自己“会用AI”而是让AI的产出能被团队顺畅地收编。我给自己定了三条准则第一AI能加速的部分绝不越过质量门槛该过的CI一个都不能少第二凡是AI生成的关键逻辑CR描述里必须附上“人话版”解释帮助review者快速理解改动意图第三不在团队里制造“AI速度焦虑”——我见过有人用AI十分钟写完一个模块然后在群里炫耀结果review的时候同事看得一脸茫然反而拖慢了整体节奏。真正让AI工作流在团队里落地靠的不是个人炫技而是稳定的产出质量和透明的协作方式。当同事发现你提交的代码靠谱、审查起来不费力时他们自然会对你用AI这件事保持开放态度。反过来如果你用AI产出的代码总要人返工那工具再好也是负数。我个人在跑通这套工作流之后最大的变化不是写代码变快了而是对“自己不知道什么”这件事变得敏感了。以前我依赖AI的流畅输出获得安全感和效率现在我更依赖它把我不确定的地方“晒”出来让我有机会去补上真正该补的知识。如果你也在摸索AI Coding工作流我只分享一个最小的起点从今天开始在所有的AI提示词模板里都加一句“请列出你做出的假设清单”。这句带刺的要求会逼着AI从“自信回答”切换到“诚实暴露盲区”的模式也会逼着你自己从“被动接收答案”切换成“主动判断答案”。这一步迈出去你离一套真正属于你的工作流就不远了。