1. 从校招入职到把 AI 塞进日常开发我的完整工作流拆解刚入职那阵子我最大的感受不是代码写不出来而是“写代码之外的事情太多了”。需求评审完要拆任务、建分支、写实现、补测试、跑 CI、改 review 意见、更新文档、同步进度一天下来真正敲键盘的时间可能不到一半。后来我开始有意识地把 AI Coding 能力往这条链路的每个环节里塞目标很朴素让机器干重复劳动我干判断和决策。这套工作流我用了大半年从最初只会“选中代码让 AI 改”到现在形成了一套相对稳定的接入方式中间踩的坑不少今天完整拆一遍。先明确这套工作流适合谁。如果你是把 AI 当搜索引擎用、问一句复制一句的开发者这套东西能帮你把效率再提一个台阶如果你是刚接触 AI Coding、还在纠结用哪个工具的新人这里会讲清楚每个环节该用什么、为什么这么选如果你已经有一套自己的流程也可以对照看看哪些环节还能再压缩。核心思路只有一句话AI 不是替代你写代码而是嵌入到开发流程的每个节点里承担信息整理、初稿生成、重复校验这三类工作。整套流程我按开发的时间线拆成五块需求理解与任务拆解、编码实现、测试与校验、代码评审与提交、文档与知识沉淀。每一块都有对应的 AI 介入方式和工具选择下面逐个展开。1.1 为什么是“接入流程”而不是“接入编辑器”很多人对 AI Coding 的理解停留在“IDE 里装个插件写代码时自动补全”。这个用法没错但只发挥了它两成的能力。补全解决的是“这一行怎么写”而开发流程里真正耗时的往往是“这个需求要拆成哪几个任务”“这个改动会影响哪些模块”“这段逻辑的边界条件我漏了没有”。我试过两种极端一种是只在编辑器里用补全结果发现省下的时间很有限因为思考成本没降另一种是把整个需求丢给 AI 让它直接产出完整功能结果产出的代码结构跟我项目的约定完全对不上改起来比自己写还累。真正有效的做法是按环节分配需要发散和整理的环节交给 AI 做初稿需要精确判断的环节我自己来需要重复校验的环节让 AI 兜底。这个分配逻辑背后有个判断标准如果一个环节的产出是“可验证的”就适合交给 AI。比如生成单元测试测试跑不跑得过是客观的AI 生成完我跑一遍就知道对不对比如拆任务拆得合不合理我自己一眼能判断。反过来涉及架构决策、跨团队约定、历史包袱权衡的部分AI 给的建议往往“看起来对但落地有问题”这部分必须自己扛。1.2 工具选型命令行 Agent 和 IDE 插件怎么分工工具这块我最后稳定在两类命令行形态的 Coding Agent和IDE 内的补全/对话插件。两者不是替代关系是分工关系。命令行 Agent 的优势在于它能拿到整个仓库的上下文可以自己读文件、跑命令、改多个文件适合处理“跨文件的改动”和“需要执行验证的任务”。比如“把这个模块的错误处理统一成新的异常类型”这种涉及十几个文件的改动命令行 Agent 一次能搞定IDE 插件就得你一个个文件点过去。IDE 插件的优势在于低延迟和就地修改。你正在写的这个函数选中一段让它重构或者光标处让它补全这种即时反馈是命令行给不了的。我日常的比例大概是跨文件改动和批量任务用命令行 Agent占三成就地补全、小范围重构、解释代码用 IDE 插件占七成。提示不要试图用一个工具覆盖所有场景。我早期强行只用一种结果要么是频繁切换上下文累得慌要么是让插件去干它不擅长的跨文件任务产出质量很差。1.3 一个容易被忽略的前提让 AI 真正“看懂”你的项目不管用哪种工具效果好坏的分水岭在于AI 能不能拿到足够的项目上下文。我见过太多人抱怨“AI 生成的代码跟项目风格完全不搭”一问才知道他从来没给 AI 提供过项目的约定信息。我的做法是在仓库根目录维护一份给 AI 看的说明文件内容包括项目用什么语言和框架、目录结构约定、命名规范、错误处理约定、测试框架和写法、常用的工具函数在哪。这份文件不需要多长一两百行足够但效果立竿见影。命令行 Agent 每次启动会自动读它IDE 插件在对话时也能引用。这份文件我建议跟着项目演进持续更新。每次发现 AI 反复犯同一个错比如总是用错日志库、总是忘记加某个必填参数就把这条约定补进去。用不了多久AI 的产出就会越来越贴合你的项目。2. 需求理解与任务拆解把模糊需求变成可执行清单开发流程的起点不是写代码是搞清楚要写什么。这一步做不好后面全是返工。AI 在这个环节的价值是帮你把模糊的自然语言需求翻译成结构化的任务清单和验收标准。2.1 用 AI 做需求的第一轮“翻译”拿到一个需求文档或者一段口头描述我通常先做一件事把它丢给 AI让它用“一个不了解背景的开发者”的视角复述一遍并列出它不确定的点。这一步的目的是暴露需求里的模糊地带。举个例子需求说“优化首页加载速度”。AI 复述时会问优化到什么程度算达标是首屏时间还是完全加载时间有没有现成的性能基线这些问题往往就是需求评审时该问但没问清楚的。我拿着这份问题清单去跟产品对齐比空手去问高效得多。这一步的关键是让 AI 提问而不是让它给方案。很多人一上来就让 AI 出技术方案结果方案建立在错误的理解上白忙一场。先对齐理解再谈方案。2.2 任务拆解的颗粒度控制理解对齐之后我让 AI 把需求拆成任务清单。这里有个颗粒度的问题拆得太粗一个任务还是不知道从哪下手拆得太细任务列表长得没法看。我的经验是按“一次提交能完成”来拆。一个任务对应一次代码提交能独立跑通测试能独立 review。AI 拆完之后我会手动调整把明显该合并的合并、该拆开的拆开。调整的过程其实也是我自己理清思路的过程。拆解时我会让 AI 顺便标注每个任务的依赖关系和风险点。依赖关系决定执行顺序风险点决定哪些任务需要多留时间。这两样东西 AI 经常能提醒到我忽略的地方比如“这个改动会影响缓存层需要同步更新缓存失效逻辑”这种跨模块的关联自己容易漏。2.3 验收标准的提前定义任务拆完之后我会让 AI 为每个任务生成验收标准。这一步很多人跳过但它直接决定了后面测试环节能不能自动化。验收标准要写成可验证的形式。比如“接口返回正确”这种就没法验证得写成“给定输入 A接口返回 B状态码 200”。AI 生成的标准我通常会改把模糊的表述替换成具体的输入输出。改完之后这些标准可以直接变成测试用例的骨架后面写测试时省一大截事。注意AI 生成的任务清单和验收标准都只是初稿。我踩过的坑是直接照着 AI 的清单干活结果发现它漏了一个关键的边界场景导致后期返工。现在我固定会做一遍人工 review重点看“有没有漏掉异常路径”和“有没有假设了不成立的前提”。3. 编码实现让 AI 写初稿我做决策到了真正写代码的环节我的原则是AI 负责产出可运行的初稿我负责判断和修正。这个定位很重要它决定了你不会陷入“AI 写什么我用什么”的被动状态。3.1 从任务清单到代码骨架每个任务开始前我会把任务描述、验收标准、相关的项目约定一起给 AI让它先生成代码骨架。骨架包括需要新增或修改哪些文件、每个文件的职责、函数签名、数据结构定义。这一步不写具体实现只搭结构。为什么先搭骨架因为结构错了实现写得再漂亮也是白费。骨架阶段我 review 得最仔细重点看模块划分是否合理、接口设计是否清晰、有没有引入不必要的依赖。骨架确认之后再让 AI 填充实现返工成本就低很多。3.2 实现阶段的“小步快跑”填充实现时我不让 AI 一次性写完整个任务而是按函数或按逻辑块分批生成。每生成一块我跑一次测试确认没问题再继续下一块。这么做有两个好处。一是问题定位快哪一块出错一目了然二是 AI 的上下文不会太长生成质量更稳定。我试过让 AI 一次生成几百行结果中间某处逻辑错了排查起来非常痛苦还不如分批来。分批的粒度我一般控制在单个函数或单个逻辑分支。生成完一块我会快速扫一遍重点看边界条件处理了没有、错误处理符合项目约定没有、有没有硬编码的魔法值。这三样是 AI 最容易出问题的地方。3.3 让 AI 解释它自己的代码AI 生成的代码尤其是涉及复杂逻辑的部分我有个习惯让它自己解释一遍。不是让它复述代码在做什么而是让它说明“为什么这么写”“有没有其他写法”“这么写的假设是什么”。这个习惯帮我抓到过不少隐藏问题。有一次 AI 生成了一段缓存逻辑解释的时候说“假设缓存不会过期”但这个假设在我的场景里不成立缓存是会过期的。如果我不问这个 bug 可能要到线上才暴露。解释的过程也是我学习的过程。AI 有时会用一些我不熟悉的写法或库函数让它解释清楚相当于顺手补了个知识点。3.4 代码风格的一致性维护AI 生成的代码风格跟项目不一致是最常见的问题。我的解决办法是在项目约定文件里写清楚风格要求同时在生成时明确指定“参照某个已有文件的风格”。如果发现 AI 反复在某个风格点上出错比如总是用双引号而项目用单引号我会在约定文件里加一条明确的规则。积累一段时间后风格问题基本就消失了。实操心得我一般会在生成实现之前先让 AI 读一遍同模块下已有的一个文件告诉它“照着这个文件的风格来”。这个简单的动作能显著提升风格一致性比事后改省事得多。4. 测试与校验把 AI 变成你的第一道防线测试是我认为 AI 介入收益最高的环节。原因很简单测试的产出是可验证的跑一遍就知道对不对不需要太多主观判断。而且写测试本身重复性高正好适合 AI。4.1 单元测试的批量生成每完成一个函数或模块我会让 AI 基于验收标准生成单元测试。生成时我会明确要求覆盖正常路径、边界条件、异常路径三类。AI 生成的测试我通常会补充两类用例一是项目特有的场景比如某个业务规则下的特殊输入二是历史上出过 bug 的场景防止回归。这两类 AI 不一定想得到但对项目价值最大。生成完跑一遍失败的用例逐个看。失败原因分两种一种是测试本身写错了改测试一种是实现有 bug改实现。这个过程经常能发现实现阶段漏掉的问题。4.2 用 AI 做代码的静态检查补充除了跑测试我还会让 AI 做一轮“代码审查式”的检查。具体做法是把改动 diff 给它让它从几个固定角度找问题空指针风险、资源泄漏、并发问题、边界溢出、错误处理缺失。这个检查不能替代正式的 code review但能在我提交之前先过滤掉一批低级问题减少 review 时的来回。我统计过这一步平均能提前发现三到五个问题省下的 review 轮次很可观。4.3 集成测试和端到端验证单元测试过了之后涉及跨模块的改动我会让 AI 帮忙生成集成测试的骨架。集成测试比单元测试复杂AI 生成的骨架需要我补充不少项目特有的配置但骨架本身能省掉搭结构的时间。端到端验证这块 AI 能帮的有限主要是生成测试数据和构造请求。真正跑起来还是得靠项目的测试环境。不过让 AI 生成测试数据这一步挺实用尤其是需要构造大量边界数据的时候。4.4 性能相关的校验如果改动涉及性能敏感的部分我会让 AI 帮忙分析时间复杂度并生成基准测试的代码。AI 对常见算法复杂度的判断基本靠谱能快速指出“这个循环嵌套可能导致 O(n²)”这类问题。基准测试的代码 AI 生成得也不错我通常只需要调整一下测试数据的规模。跑出来的结果如果跟预期差距大再回头优化实现。测试类型AI 介入程度我的主要工作单元测试高可生成大部分补充项目特有场景和回归用例静态检查中提供问题清单判断哪些是真问题哪些是误报集成测试中生成骨架补充配置和项目特有逻辑端到端低生成测试数据在真实环境执行和验证性能测试中生成基准代码调整数据规模分析结果5. 代码评审与提交让 AI 先过一遍提交之前的最后一道关是自我 review。这一步我让 AI 扮演“挑刺的 reviewer”先把明显问题挑出来我再提交给同事 review。5.1 提交前的自查清单我固定让 AI 按一份清单检查改动有没有调试代码残留、有没有注释掉的死代码、提交信息是否清晰、改动是否聚焦有没有夹带无关修改、有没有更新相关文档。这份清单是踩坑踩出来的。有一次我提交时夹带了一个调试用的日志级别修改review 时被同事指出来挺尴尬的。从那以后我就把“检查有没有夹带无关改动”加进了清单。5.2 提交信息的生成提交信息我让 AI 根据 diff 生成初稿然后自己改。AI 生成的信息通常能准确概括改了什么但“为什么改”往往写得不够。我会补上背景和动机让提交历史更有价值。提交信息的格式我遵循项目的约定一般是“类型: 简短描述”加详细说明。AI 对格式的遵循度不错只要在约定文件里写清楚就行。5.3 应对 review 意见收到 review 意见后我会把意见和对应的代码一起给 AI让它生成修改方案。这一步能加快响应速度尤其是意见比较多的时候。但有个原则每条意见我都自己判断一遍再改。reviewer 的意见有时基于他不了解的背景直接照改可能引入新问题。AI 生成的修改方案我会看逻辑对不对不对就跟 reviewer 沟通而不是闷头改。5.4 合并前的最终校验合并前我会让 AI 再跑一遍完整检查测试是否全过、有没有冲突、目标分支是否正确、CI 状态是否正常。这一步主要是防止手滑比如合错分支这种低级错误。注意AI 的自查不能替代人工 review。我见过有人完全依赖 AI 检查就提交结果漏掉了业务逻辑层面的问题这种问题 AI 很难发现因为它不理解业务背景。AI 负责过滤低级问题业务正确性还得靠人。6. 文档与知识沉淀把一次性经验变成可复用资产开发流程的最后一块是文档。这块最容易被忽略但长期看收益最大。AI 在这里的价值是降低写文档的门槛让“懒得写”不再是借口。6.1 代码注释的自动补全函数和模块的注释我让 AI 根据实现生成初稿然后自己调整。AI 生成的注释通常能说清“做了什么”但“为什么这么做”需要我补充。我会重点补上那些“看起来奇怪但其实有原因”的地方这些是后来者最容易困惑的点。注释的详细程度我控制在“能看懂意图”就行不追求逐行解释。过度注释反而增加维护负担代码改了注释没改更误导人。6.2 接口文档和变更记录涉及接口改动时我让 AI 根据代码生成接口文档初稿包括请求参数、响应结构、错误码。这部分 AI 做得很好因为接口定义本身就是结构化的。变更记录我让 AI 根据提交历史整理按功能、修复、重构分类。整理完自己过一遍确保重要变更没漏。6.3 把踩过的坑沉淀成团队知识每次解决一个非平凡的问题我会让 AI 帮忙整理成一篇简短的知识条目问题现象、排查过程、根因、解决方案、如何避免。整理完放进团队的知识库。这件事的价值在于把个人经验变成团队资产。我踩过的坑同事不用再踩一遍。积累多了新人上手也快很多。6.4 工作流本身的迭代最后说一个容易被忽略的点这套工作流本身也需要迭代。我每个月会回顾一次看看哪些环节 AI 介入效果好、哪些效果差、有没有新的工具值得试。回顾的方法很简单记录每个环节花的时间和返工次数对比上个月。哪个环节时间在涨或者返工在增多就说明当前的 AI 介入方式有问题需要调整。我个人的体会是AI Coding 的收益不是线性的而是在流程打通之后才显现出来。单独用某个环节提升有限把整条链路串起来每个环节省一点累积起来就很可观。而且这套东西没有标准答案得根据自己的项目特点和工作习惯慢慢调。我现在的版本也是改了十几轮才稳定下来的你完全可以从一两个环节开始试跑顺了再扩展。最后分享一个小技巧给 AI 的指令里明确说清楚“不要做什么”往往比“要做什么”更重要。比如“不要引入新依赖”“不要改公共接口”“不要动测试文件”这些约束能避免 AI 自作主张带来的意外改动。我早期没注意这点被 AI 顺手改了一堆无关文件排查起来很费劲。