1. 校招入职第一周我发现组里没人“纯手写”代码了刚入职那会儿我脑子里对“大厂开发”的想象还停留在学生时代的模式打开 IDE从零开始敲每一个函数遇到不会的就去搜搜完复制粘贴再改改。结果入职第三天导师丢给我一个内部仓库的链接说“你先把这个模块的测试补一下用你顺手的工具就行”。我打开仓库一看旁边工位的同事屏幕上代码像流水一样往外冒——不是他手速快是他在跟一个对话框来回聊聊几句就往编辑器里贴一段再跑一下测试不对就继续聊。我当时的第一反应是这不就是高级版的代码补全吗但观察了一周之后我发现事情没那么简单。他们不是在“用 AI 补全代码”而是在用 AI 跑完整个开发流程的每一个环节需求理解、方案设计、编码、测试、调试、Code Review、文档撰写甚至包括提交信息commit message的生成。AI 不是一个插件而是一个贯穿始终的协作方。这篇文章想聊的就是我这几个月摸出来的一套AI Coding 工作流。它不是某个具体工具的教程而是一套把 AI 接入完整开发流程的方法论。适合谁看如果你是刚入行的校招生、转行的开发者或者已经工作几年但还没系统性地把 AI 用起来的人这套东西应该能帮你少走不少弯路。我不会只告诉你“用哪个工具”而是会讲清楚每个环节为什么这么设计、我踩过哪些坑、以及哪些地方 AI 其实帮不上忙。先说一个反直觉的结论AI Coding 的核心竞争力不在于你用的模型有多强而在于你喂给它的上下文Context有多准。这句话是我在连续三天被 AI 生成的“看起来对但跑不通”的代码折磨之后才真正理解的。后面会展开讲。2. 先搞清楚 AI 在开发流程里到底能干什么、不能干什么在聊具体工作流之前有必要先把边界划清楚。我见过两种极端一种是把 AI 当万能神什么都让它干结果被幻觉坑得死去活来另一种是觉得 AI 写的代码“不靠谱”干脆不用继续纯手写。这两种都走了弯路。2.1 我实测下来AI 真正擅长的四类任务经过这几个月的反复验证我把 AI 在开发流程中的能力分成四档从“几乎不会出错”到“需要高度警惕”能力档位典型任务我的信任度说明第一档放心用生成样板代码、写单元测试、解释陌生代码、生成正则表达式、写文档注释90%以上这些任务有明确的输入输出AI 出错概率低改改就能用第二档辅助用实现独立的小函数、写 SQL 查询、做数据转换逻辑、生成 mock 数据70%左右需要你审查逻辑但基本框架是对的第三档谨慎用涉及业务规则的复杂逻辑、多模块交互的改动、性能敏感代码40%左右必须逐行审查AI 经常忽略边界条件第四档别用架构设计决策、安全相关代码、涉及资金/权限的核心逻辑极低这些地方 AI 的“自信”最危险它不知道它不知道什么这个分档不是绝对的跟你的领域知识深度有关。你对某个模块越熟就越能判断 AI 给的东西靠不靠谱。反过来如果你对某个技术栈完全陌生AI 生成的代码你根本没法判断对错这时候用它反而危险。2.2 为什么“让 AI 写整个功能”几乎总是翻车我刚开始的时候试过一种很自然的用法把需求描述一大段丢给 AI说“帮我实现这个功能”。结果十次有八次翻车。翻车的方式还很有规律幻觉 APIAI 会编造一些看起来合理但根本不存在的函数名或参数。比如它会给一个 HTTP 客户端库编一个setRetryPolicyWithBackoff()的方法实际上这个库根本没这个 API。忽略边界你让它写一个分页查询它写出来的代码在“最后一页刚好取完”的情况下会多查一次或者空结果时抛异常。过度设计你只要一个简单的字符串处理它给你整出一个抽象工厂加策略模式代码量是你预期的五倍。上下文丢失它不知道你项目里已经有一个工具类能干这事又给你重新造了一个轮子。这些问题的根源是同一个AI 没有你项目的完整上下文。它不知道你的代码规范、不知道你已有的工具函数、不知道你的业务约束、不知道你的技术栈版本。它只能根据你给的那点信息去“猜”猜错了就产生幻觉。所以整套工作流的核心思路就一句话不要指望 AI 一次做对而是把大任务拆成小任务每个小任务都给足上下文让 AI 在受控的范围内发挥。2.3 Context Engineering比 Prompt Engineering 更重要的能力现在到处都在讲 Prompt Engineering提示词工程但我实际用下来Context Engineering上下文工程才是更关键的能力。区别在哪Prompt Engineering 关注的是“怎么把话说清楚”比如加角色设定、加输出格式要求、加 few-shot 示例。这些有用但解决不了根本问题——AI 不知道你的项目长什么样。Context Engineering 关注的是“怎么把正确的信息喂给 AI”。具体包括代码上下文相关的文件、函数签名、类型定义、已有的工具类规范上下文代码风格、命名约定、错误处理模式、日志规范业务上下文这个模块的业务规则、边界条件、历史踩坑记录技术栈上下文语言版本、框架版本、依赖库版本我举个例子你就明白了。同样是“写一个用户查询接口”如果你只给 AI 一句话需求它给你的代码大概率不能直接用。但如果你给它项目使用 Spring Boot 3.2 MyBatis-Plus 用户表结构如下贴建表语句 已有的统一返回体是 ResultT定义在 com.xxx.common.Result 已有的分页工具是 PageUtils用法参考 UserService.listUsers() 错误码规范参考 ErrorCode 枚举 请按照以上规范实现 UserController.queryUser()这样它生成的东西基本框架就是对的你只需要改改细节。这就是 Context Engineering 的价值。3. 我的完整工作流从接到需求到提交代码的七个环节下面进入正题。我把整个开发流程拆成七个环节每个环节说清楚 AI 怎么介入、我用什么工具、以及具体的操作细节。这套流程不是死的你可以根据自己的习惯调整但核心逻辑是通用的。3.1 环节一需求理解——让 AI 当你的“翻译官”刚拿到需求的时候最怕的是“以为自己懂了”。产品经理写的一段话可能藏着好几个歧义点。我现在的习惯是拿到需求先不急着写代码而是把需求描述丢给 AI让它帮我做三件事拆解需求点把一段话拆成一条条具体的功能点列出歧义和待确认项哪些地方描述不清、哪些边界没定义提出技术方案建议大概需要改哪些模块、涉及哪些接口比如需求是“用户可以按标签筛选文章筛选结果要支持分页”AI 会帮我列出标签筛选是单标签还是多标签多标签是 AND 还是 OR分页参数默认值是多少最大页大小限制筛选结果按什么排序发布时间还是相关度标签不存在时返回空列表还是报错这些问题我自己看需求的时候经常漏掉但 AI 会一股脑列出来。然后我拿着这个清单去跟产品确认效率比来回猜高多了。注意AI 列出的问题不一定都对有些是它自己“想多了”。你要用自己的业务判断过滤一遍只保留真正需要确认的。这个环节我一般用对话式 AI比如网页版的通用大模型不需要接进 IDE。因为这时候还没开始写代码重点是理清思路。3.2 环节二方案设计——AI 是参谋不是决策者需求理清之后进入方案设计。这个环节我的原则是AI 可以提建议但决策必须自己做。因为架构决策涉及太多 AI 不知道的因素——团队的技术栈偏好、历史债务、上线时间压力、运维成本等等。我通常会让 AI 做这几件事列出多种实现方案比如“这个功能可以用定时任务、消息队列、或者数据库轮询实现各自的优缺点是什么”评估影响范围改动这个模块可能影响哪些上下游生成接口定义草案根据需求先草拟出 API 的入参出参但最终的方案选择我会结合自己对项目的理解来定。AI 给的方案经常“理论上最优但实际不可行”比如它可能建议你引入一个新的中间件但你团队根本没运维能力维护它。这个环节有个小技巧把 AI 当成一个刚入职的聪明新人。它知识面广、学习能力强但不了解你公司的具体情况。你会怎么跟一个新人讨论方案你会给它背景信息听它的想法然后自己拍板。跟 AI 协作也是这个逻辑。3.3 环节三编码——把大任务切成 AI 能消化的小块这是最核心的环节也是坑最多的环节。我摸索出来的方法是按“函数级”或“文件级”切分任务每次只让 AI 处理一个明确的、有边界的子任务。具体怎么切我一般按这个顺序先写类型定义和接口签名让 AI 根据方案生成数据结构、函数签名、接口定义。这部分 AI 很擅长而且它是后续编码的基础。再写核心逻辑一个函数一个函数地让 AI 实现每次给它足够的上下文相关的类型定义、已有的工具函数、错误处理规范。最后写胶水代码把各个函数串起来处理参数校验、异常捕获、日志记录这些。为什么不一次性让 AI 写完整个文件因为文件越大AI 越容易在后面“忘记”前面的约定产生不一致。而且一旦出错你很难定位是哪一段的问题。切成小块之后每块都能单独验证出错了好排查。在工具选择上我目前主要用两类IDE 内置的 AI 助手比如各种代码编辑器的 AI 插件适合行内补全、小范围修改、快速问答。优点是上下文自动带入不用手动贴代码。Coding Agent 类工具适合跨文件的任务比如“把这个函数从 A 文件移到 B 文件并更新所有引用”。它能自己读文件、改文件、跑命令但需要你给它明确的指令和边界。我的经验不要同时开太多 AI 工具。我试过 IDE 插件 网页对话 Agent 三管齐下结果上下文在三个地方来回倒反而更乱。现在固定用“IDE 插件为主网页对话为辅Agent 处理批量任务”的组合。3.4 环节四测试——AI 写测试比我写得快但我要告诉它测什么写单元测试这件事AI 是真的强。你给它一个函数它能很快生成一堆测试用例覆盖正常路径、边界条件、异常情况。但这里有个陷阱AI 写的测试经常是在“验证代码做了什么”而不是“验证代码应该做什么”。什么意思如果你先让 AI 写了实现代码再让它根据实现代码写测试它会顺着实现的逻辑写测试实现里的 bug 它测不出来。正确的顺序是先让 AI 根据需求写测试用例再让它写实现最后跑测试。这就是测试驱动开发TDD的思路用 AI 来执行反而更顺。我现在的做法是把函数的需求描述给 AI让它列出所有应该覆盖的测试场景正常、边界、异常我审查这个场景列表补充 AI 没想到的通常是对业务规则的理解让 AI 根据确认后的场景列表生成测试代码再让 AI 写实现跑测试不过就继续调这样写出来的测试才是真正有价值的测试。而且这个过程里AI 帮我省掉了大量“写测试模板”的时间我只需要聚焦在“测什么”这个更有价值的思考上。3.5 环节五调试——把报错信息完整喂给 AI别自己先“翻译”调试环节AI 能帮大忙但很多人用错了方式。最常见的错误是遇到报错自己先理解一遍然后用自己的话描述给 AI。比如报错是NullPointerException at UserService.java:42他描述成“我的用户服务报了个空指针”。这样 AI 能给你的帮助很有限。正确的做法是把完整的报错堆栈、相关的代码片段、你的操作步骤原封不动地贴给 AI。信息越完整AI 定位问题越准。我通常会这样组织报错信息完整堆栈 相关代码出错的函数完整代码 复现步骤我做了什么操作触发的 我已经尝试过我改了什么但没用这样 AI 往往能直接指出问题所在或者给出几个可能的排查方向。即使它没直接找到根因它列出的排查方向也能帮我少走弯路。还有一个技巧让 AI 帮你写调试代码。比如“在这个函数里加几行日志打印出所有入参和中间变量”AI 生成的调试代码又快又全比我自己一行行加效率高多了。3.6 环节六Code Review——AI 当第一道筛子我做最终判断提交代码之前我会先让 AI 过一遍。它主要能帮我抓这几类问题明显的 bug空指针、数组越界、资源未关闭代码规范问题命名不一致、魔法数字、重复代码潜在的性能问题循环里的数据库查询、不必要的对象创建安全问题SQL 注入风险、敏感信息硬编码但 AI 的 Code Review 有几个盲区你必须自己补上业务逻辑正确性AI 不知道你的业务规则它只能判断代码“自洽”不能判断代码“正确”架构一致性AI 不知道你项目的分层规范可能觉得某个写法没问题但实际上违反了架构约定团队约定比如你们团队规定所有外部调用必须加超时和重试AI 不一定知道所以我的流程是AI 先过一遍把它发现的问题改掉然后我自己再过一遍重点看业务逻辑和架构一致性最后如果有条件再找同事做人工 Review。3.7 环节七提交与文档——让 AI 处理那些“不想写但必须写”的东西Commit message、PR 描述、接口文档、变更说明——这些东西技术含量不高但特别耗时间。我现在全部交给 AI 生成初稿自己改改就用。比如 commit message我会把这次改动的 diff 贴给 AI让它按团队的规范格式生成。PR 描述也是把改动的背景、方案、测试情况告诉 AI它生成的描述比我手写的还清楚。接口文档更是 AI 的强项。你给它接口定义和示例请求响应它能生成格式规范的文档包括参数说明、错误码、示例代码。我只需要检查一下有没有遗漏。这个环节省下来的时间我会用来做更有价值的事——比如多写几个测试用例或者把代码再优化一下。4. 工具选型我用过和放弃的那些方案聊完流程说说工具。这块我不做具体产品推荐因为工具迭代太快今天推荐的明天可能就过时了。我聊的是选型思路和我踩过的坑你可以根据这些思路去选适合自己的工具。4.1 IDE 内置助手 vs 独立对话工具什么时候用哪个这两类工具我都在用但场景分得很清楚场景用 IDE 内置助手用独立对话工具行内补全、小范围修改是否快速问答、解释代码是是跨文件重构看情况是需求分析、方案设计否是生成大段代码否是调试排查是能直接看代码是能贴完整上下文IDE 内置助手的优势是上下文自动带入它知道你当前打开的文件、光标位置、选中的代码不用你手动贴。缺点是对话能力通常弱一些处理复杂任务不如独立工具。独立对话工具的优势是上下文可以手动构造你能把多个文件、报错信息、需求描述一起贴进去让它做更复杂的分析。缺点是你得手动维护上下文容易漏掉关键信息。我的组合是日常编码用 IDE 助手遇到需要深度思考的任务切到独立工具。两者不冲突关键是别在同一个任务上反复横跳。4.2 Coding Agent 类工具什么时候值得用什么时候是负担Coding Agent 是最近很火的一类工具它能自己读文件、改文件、跑命令、看结果然后继续改。听起来很美好但我实际用下来它的适用场景比宣传的要窄。它真正好用的场景批量重命名或重构比如把一个函数名在所有文件里改掉它能自己找到所有引用点生成重复性代码比如根据数据库表生成一堆 CRUD 接口跨文件的机械性修改比如给所有 API 调用加上超时参数它不好用的场景需要业务判断的改动它不知道你的业务规则改出来的东西可能逻辑不对涉及多个模块的复杂改动它容易改着改着就“迷路”把不相关的地方也改了需要频繁验证的改动它跑命令看结果的能力有限很多时候还是得你自己跑我用 Agent 的原则是任务越机械、越重复、越有明确规则越适合用 Agent。任务越需要判断、越涉及业务逻辑越应该自己来或者用对话式工具。一个血泪教训有一次我让 Agent 帮我“优化一下这个模块的性能”结果它把好几个函数的实现都改了虽然测试通过了但代码可读性下降了很多Review 的时候被导师说了一顿。后来我改成“把这个循环里的数据库查询改成批量查询”它就只改了这一处效果很好。给 Agent 的指令要具体到“改什么、怎么改”而不是“优化一下”。4.3 关于“AI 会不会让我的代码能力退化”这件事这个问题我被问过好几次自己也想过。我的结论是取决于你把 AI 用在哪个环节。如果你把 AI 用在“替我想”的环节——需求分析、方案设计、架构决策——那你的思考能力确实可能退化。因为这些环节的价值就在于思考本身你让 AI 替你想你就失去了成长的机会。但如果你把 AI 用在“替我做”的环节——写样板代码、生成测试、写文档、格式化——那你的能力不会退化反而会提升。因为你省下了这些机械劳动的时间可以把精力放在更有价值的思考上。我自己的做法是凡是能让我学到东西的环节我都自己先想一遍再让 AI 补充凡是纯机械的环节直接交给 AI。这样既享受了效率提升又保证了能力成长。5. 踩坑实录那些让我半夜加班的 AI Coding 陷阱这部分是我最想写的因为网上讲 AI Coding 的文章大多在讲“怎么用”很少有人讲“怎么用会出事”。下面这几个坑都是我真实踩过的每一个都让我付出了代价。5.1 坑一AI 生成的代码“看起来对”但跑起来全是边界问题这是最常见的坑也是最危险的。AI 生成的代码正常路径通常没问题但边界条件经常翻车。我遇到过的具体案例分页查询在“总数刚好是页大小整数倍”时多返回一页空数据字符串处理在输入为空字符串时抛异常时间计算在跨天、跨月、跨年时结果错误并发场景下没有考虑竞态条件这些问题的共同点是正常测试发现不了上线后遇到真实数据才暴露。我现在的应对方法是让 AI 写实现的同时强制它列出“这个函数的所有边界条件”然后针对每个边界条件写测试。如果 AI 列不全我自己补。这个习惯帮我挡掉了至少三次潜在的生产事故。5.2 坑二上下文给太多AI 反而“抓不住重点”刚开始用 AI 的时候我有个误区觉得给的信息越多越好。有一次我让 AI 帮我改一个函数把整个文件两千多行都贴进去了结果它改出来的东西完全跑偏——它关注了一些不相关的细节反而忽略了我真正想改的地方。后来我明白了AI 的注意力是有限的你给的信息越多它越容易“分心”。正确的做法是只给跟当前任务相关的上下文把无关的部分删掉。比如改一个函数就只贴这个函数和它直接依赖的类型定义不用贴整个文件。这个原则在 Context Engineering 里叫“最小必要上下文”。我现在每次给 AI 贴代码之前都会问自己这段信息跟当前任务有关吗无关就删掉。5.3 坑三过度依赖 AI 的“自信”放弃了独立思考AI 有个特点它不知道自己不知道什么。它给出的答案语气总是很确定即使内容是错的。我有一段时间就被这种“自信”带偏了AI 说什么我就信什么结果在一个技术选型上吃了亏。那次是选一个数据处理库AI 推荐了一个它“认为”很成熟的方案列了一堆优点。我因为赶时间没做深入调研就用了。结果那个库的社区活跃度很低遇到问题搜不到解决方案最后不得不换回原来的方案白白浪费了两天。从那以后我给自己定了个规矩AI 给的技术建议必须交叉验证。怎么验证去官方文档确认 API 是否存在去社区看有没有人踩过类似的坑去 GitHub 看 issue 的活跃度。AI 可以帮你快速了解一个领域但不能替代你自己的判断。5.4 坑四把 AI 当“搜索引擎”用问的问题太宽泛“怎么优化数据库查询性能”——这种问题 AI 给你的答案大概率是网上随处可见的通用建议加索引、避免全表扫描、用连接池。这些没错但对你解决具体问题帮助不大。有效的问法是带上你的具体场景和约束。比如“我有一张一千万行的订单表查询条件是用户 ID 时间范围 状态目前走的是用户 ID 索引但状态过滤后数据量还是很大有什么优化思路”这样 AI 才能给出有针对性的建议。我现在的习惯是问 AI 之前先花一分钟把问题描述清楚——背景是什么、我试过什么、卡在哪里、有什么约束。这一分钟的投资能换来质量高得多的回答。6. 让 AI 真正融入日常我的习惯和心法聊完流程、工具和坑最后说说习惯。工具和流程都是外在的真正决定效率的是你怎么把 AI 变成日常的一部分。6.1 建立自己的“上下文素材库”前面反复强调 Context Engineering 的重要性但每次手动构造上下文很费时间。我的做法是维护一个自己的上下文素材库把常用的信息整理好用的时候直接复制。我的素材库包括项目技术栈说明语言版本、框架版本、关键依赖一段话描述清楚代码规范摘要命名约定、错误处理模式、日志规范浓缩成几条常用工具类清单项目里已有的工具函数避免 AI 重复造轮子业务术语表项目里的专有名词和它们的含义这个素材库我放在一个 Markdown 文件里每次开新任务的时候把相关的部分复制到对话开头。花十分钟维护这个库能省下每次构造上下文的半小时。6.2 把 AI 当“结对编程伙伴”而不是“代码生成器”结对编程Pair Programming是敏捷开发里的一个实践两个人一起写代码一个人写一个人看随时交流。我觉得跟 AI 协作的最佳模式就是这种“结对”模式。具体来说你主导方向你决定写什么、怎么设计AI 负责实现细节随时交流不要憋着一个大任务让 AI 一次做完而是边做边聊小步快跑互相审查AI 写的代码你审查你写的代码也可以让 AI 审查共同成长AI 从你的反馈里学习你的偏好你从 AI 的建议里学习新的思路这种模式下AI 不是一个“工具”而是一个“伙伴”。你不会把整个任务丢给伙伴然后消失而是跟它一起把任务完成。6.3 定期复盘哪些环节 AI 帮上忙了哪些没有我每个月会花半小时做一次复盘回顾这个月用 AI 的情况哪些任务用 AI 效率提升明显哪些任务用 AI 反而更慢哪些坑是重复踩的有没有新的用法值得尝试这个复盘帮我不断优化自己的工作流。比如我发现自己有段时间在“调试”环节用 AI 效率不高原因是我不习惯贴完整堆栈。后来我强制自己每次都贴完整信息效率就上来了。6.4 一个反直觉的建议有时候关掉 AI 反而更快最后说一个可能有点反直觉的建议不是所有任务都适合用 AI。有些任务你自己写比跟 AI 来回沟通更快。比如你非常熟悉的、简单的改动改个变量名、调个参数自己动手三秒钟跟 AI 描述要三十秒需要高度专注的复杂逻辑跟 AI 来回对话会打断你的思路不如自己一口气写完涉及敏感信息的代码有些代码不适合贴给外部工具自己写更稳妥我现在的判断标准是如果这个任务我自己能在五分钟内搞定就不用 AI。超过五分钟的才考虑用 AI 来加速。这个简单的规则帮我省下了不少“为了用 AI 而用 AI”的时间。7. 写在最后AI Coding 的本质是放大你的能力用了这几个月我最大的体会是AI 不会让你变成一个更好的工程师它只会放大你本来的能力。如果你本来就有扎实的基础、清晰的思路、良好的工程习惯AI 能让你快上加快。如果你本来基础不牢、思路混乱AI 只会让你更快地写出更多有问题的代码。所以别把精力都花在“研究哪个 AI 工具更强”上。工具会迭代模型会升级但底层的能力——需求分析、方案设计、代码审查、调试排查——这些才是你真正的护城河。AI 是来帮你把这些能力发挥到极致的不是来替代它们的。我现在的工作流说白了就是一句话把机械的活交给 AI把思考的活留给自己然后用 AI 来放大思考的成果。这个原则比任何具体的工具和技巧都重要。如果你刚开始用 AI 辅助开发我的建议是从最小的场景开始比如让它帮你写单元测试或者解释一段看不懂的代码。等你对它的能力边界有了感觉再逐步扩大使用范围。别一上来就让它写整个模块那样大概率会翻车然后你就再也不想用它了。慢慢来找到适合自己的节奏。这套工作流不是一天建成的我到现在还在调整。关键是开始用然后在用的过程中不断优化。