1. 为什么“能立刻复用”比“功能强大”更重要我见过太多人收藏了几百个AI编程工具从代码补全到全自动Agent硬盘里塞满了各种教程和配置文件结果日常写代码时还是一个Tab一个Tab地敲。问题不在于工具不够好而在于那些工作流要么配置太复杂要么跟自己的实际开发习惯拧着来用两次就放弃了。“能立刻复用”这四个字是我筛选AI编程工作流的第一道门槛。一个工作流如果不能在五分钟内跑通、不能适配你现有的项目结构、不能在你最常写的代码类型上稳定输出那它再先进也跟你没关系。我自己的工作台上长期只保留三个AI编程工作流分别覆盖代码生成与补全、代码审查与重构、测试用例自动生成这三个最高频的场景。它们不需要复杂的Agent编排不需要外接向量数据库甚至不需要离开你的IDE。这篇文章就把这三个工作流完整拆开从设计思路到具体配置从提示词模板到踩坑记录全部摊开讲。不管你是刚接触AI编程辅助的新手还是已经用过Copilot、Cursor、通义灵码等工具的开发者都能从中找到可以直接抄走的部分。每个工作流我都会给出最小可用配置和进阶调优方案两个版本你可以根据自己的项目类型和团队规范灵活选择。先说一个我反复验证过的结论AI编程工作流的效率瓶颈从来不在模型能力而在上下文组织方式。同一个模型提示词里给不给项目目录结构、给不给相关模块的接口定义、给不给具体的代码风格示例输出质量能差出三倍以上。所以下面每个工作流我都会重点讲清楚“喂什么上下文”和“怎么喂”。2. 工作流一结构化代码生成与补全2.1 核心思路把“写代码”拆成“填模板”大多数人用AI写代码的方式是打开对话框输入“帮我写一个用户登录接口”然后等着模型吐出一大段代码再手动复制到项目里改。这种方式的问题很明显——模型不知道你的项目用什么框架、什么ORM、什么参数校验库、什么返回格式生成的代码跟你的项目风格完全不搭改起来比自己写还费劲。我的做法是把代码生成拆成两步先让AI理解项目上下文再让AI按照固定模板填充。具体来说我会在项目根目录放一个.ai-context.md文件里面写清楚项目的基本信息。这个文件不需要很长但必须包含几个关键信息项目使用的语言和框架版本比如Python 3.11 FastAPI 0.104数据库和ORM比如PostgreSQL 15 SQLAlchemy 2.0参数校验方式比如Pydantic v2统一的返回结构比如{code, message, data}代码风格要点比如“所有函数必须写类型注解”“禁止使用裸except”这个文件的作用相当于给AI一份“项目说明书”。每次让AI生成代码时我会把相关模块的接口定义和这个文件一起贴进上下文。实测下来这样生成的代码首次可用率能从30%提升到70%以上基本只需要微调业务逻辑不用大改结构。2.2 最小可用配置三步搭建你的代码生成模板如果你不想搞太复杂可以先用下面这个最小配置跑起来。我把它叫做“三件套”工作流第一步准备一个提示词模板文件。在项目里建一个prompts/codegen.md内容如下你是一个资深后端开发工程师正在为以下项目编写代码。 ## 项目上下文 - 语言框架{framework} - 数据库ORM{orm} - 参数校验{validation} - 返回结构{response_format} ## 代码风格要求 - 所有函数必须有类型注解 - 使用项目统一的异常处理类 - 日志使用项目封装的logger - 禁止在业务逻辑中直接写SQL ## 当前任务 {task_description} ## 相关接口定义 {interface_definitions} 请生成完整可运行的代码包含必要的导入语句。第二步每次生成时填充变量。比如你要写一个“根据用户ID查询订单列表”的接口就把task_description填成具体需求把interface_definitions填成User和Order模型的字段定义。第三步生成后立即做一次“风格校验”。我习惯在IDE里开两个窗口左边是AI生成的代码右边是项目里一个风格标准的参考文件逐项对比类型注解有没有、异常处理是不是用的项目统一类、日志调用方式对不对。这个校验过程大概花30秒但能省掉后面大量的返工。注意不要一次性让AI生成超过200行的代码。超过这个长度模型很容易在中后段“忘记”前面的约束条件开始自由发挥。如果任务确实复杂拆成多个小任务分次生成。2.3 进阶调优用“示例驱动”替代“描述驱动”最小配置跑通之后你会发现有些场景下AI还是get不到你的意图。比如你要求“写一个分页查询”但AI不知道你的分页参数命名习惯是page_size还是per_page不知道返回结构里分页信息放在顶层还是嵌套在data里。这时候就需要示例驱动。具体做法是在提示词里直接给一个“参考实现”让AI照着这个例子的风格来写新代码。比如## 参考实现请严格模仿此风格 以下是项目中已有的一个标准列表查询接口 [粘贴一段你项目里写得最规范的列表查询代码] ## 当前任务 请按照上述参考实现的风格编写“根据状态筛选订单”的接口。这个方法的原理很简单代码风格这种东西给例子比给描述有效十倍。模型看到具体代码后会自动模仿其中的命名习惯、异常处理方式、日志格式、甚至注释风格。我试过在同一个项目里用描述驱动和示例驱动分别生成十个接口示例驱动的版本几乎不需要修改就能通过代码审查描述驱动的版本平均要改三到五处。还有一个进阶技巧是建立“代码片段库”。我会把项目里最常用的几种代码模式比如CRUD接口、分页查询、事务处理、缓存读写各挑一个标准实现存到一个prompts/snippets/目录下。每次生成新代码时根据任务类型选择对应的片段作为参考。这个习惯坚持一个月后我发现自己手写代码的时间减少了大概40%而且生成的代码质量越来越稳定。2.4 实操心得什么时候不该用AI生成代码这个工作流虽然好用但有几种情况我建议你手动写涉及复杂业务规则的代码比如订单状态机流转、优惠券叠加计算这些逻辑的边界条件太多AI很容易漏掉某个分支。我一般会让AI生成一个“骨架”然后自己把业务规则一条条填进去。性能敏感的代码比如高频交易路径上的函数、大数据量下的查询优化。AI生成的代码通常是“正确但不够快”需要你自己做索引优化、缓存策略、批量处理。安全相关的代码比如权限校验、加密解密、SQL拼接。这些地方我坚持手写或者至少逐行审查AI生成的每一行。3. 工作流二AI辅助代码审查与重构3.1 核心思路让AI当“第一轮审查员”代码审查是每个团队都头疼的事。Reviewer时间有限经常只能扫一眼就点通过很多问题要到测试阶段甚至上线后才暴露。我的做法是在提交代码之前先让AI做一轮自动审查把明显的问题过滤掉这样人工Reviewer只需要关注业务逻辑和架构设计这些AI不擅长的部分。这个工作流的关键在于审查规则要具体、可执行不能是“检查代码质量”这种空话。我会把团队的代码规范拆成一条条具体的检查项比如所有数据库查询是否都走了索引异常处理是否覆盖了所有可能的分支日志是否包含了足够的排查信息请求ID、用户ID、关键参数是否存在N1查询问题是否有硬编码的配置项然后把这些检查项写成一个审查提示词模板每次提交前跑一遍。3.2 最小可用配置提交前的三分钟审查我自己的习惯是在git commit之前把改动过的文件内容贴给AI用下面这个提示词跑一遍请以资深代码审查者的身份审查以下代码改动。 ## 审查重点 1. 是否存在空指针/未定义变量风险 2. 异常处理是否完整是否有吞异常的情况 3. 数据库查询是否存在N1问题 4. 是否有硬编码的敏感信息或配置 5. 日志是否包含足够的排查上下文 6. 是否有明显的性能问题循环内查询、大数组拷贝等 ## 代码改动 [粘贴git diff内容] 请按以下格式输出 - 严重问题必须修改 - 建议修改可以后续优化 - 做得好的地方值得保留这个提示词我用了大半年发现它最有效的地方是**“做得好的地方”这一项**。一开始我觉得这是多余的后来发现让AI指出代码中的亮点能帮助我形成正向反馈知道自己哪些写法是值得保持的。而且有时候AI指出的“亮点”会让我意识到某个自己没注意到的设计模式可以推广到其他模块。3.3 进阶调优建立“审查规则库”并持续迭代最小配置跑一段时间后你会积累一批“AI经常发现的问题类型”。比如你可能会发现AI反复指出你的代码里“异常处理太宽泛”“日志缺少请求ID”“循环内有数据库查询”。这时候就可以把这些高频问题固化成更具体的审查规则。我的做法是建一个review-rules.md文件按严重程度分级级别规则示例P0安全漏洞SQL拼接、硬编码密钥、越权风险P1数据一致性缺少事务、并发更新未加锁P2性能隐患N1查询、循环内IO、大对象拷贝P3可维护性魔法数字、过长函数、重复代码P4风格问题命名不规范、注释缺失每次审查时把这份规则库和代码一起给AI让它按级别输出问题。这样审查结果就有了优先级你可以先处理P0和P1P3和P4可以排期后续优化。还有一个很实用的技巧是让AI对比两个版本的代码。比如你重构了一个函数可以把重构前后的代码都贴给AI让它分析“重构后的版本是否真的更好”。我试过几次AI有时候会指出重构后引入的新问题比如“虽然函数变短了但增加了额外的参数传递调用方需要修改的地方更多了”。这种视角是人工审查时容易忽略的。3.4 实操心得AI审查的边界在哪里用了这么久我总结出AI代码审查的几个能力边界AI擅长的语法层面的问题、常见的反模式、日志和异常处理的完整性、命名规范、明显的性能隐患。这些是“模式匹配”类的问题AI见过大量代码后能快速识别。AI不擅长的业务逻辑的正确性、架构设计的合理性、模块间耦合度的判断、技术选型的权衡。这些需要理解业务背景和团队历史AI没有这些信息。所以我的做法是AI审查负责“下限”人工审查负责“上限”。AI确保代码没有明显的坑人工Reviewer专注于业务逻辑和架构设计。这样分工之后我们团队的代码审查效率大概提升了一倍Reviewer的负担明显减轻。4. 工作流三测试用例自动生成与维护4.1 核心思路从“函数签名”反推测试场景写测试用例是很多开发者的痛点——知道应该写但总觉得浪费时间。我的做法是让AI根据函数签名和文档字符串自动生成测试用例然后我只需要补充边界条件和业务特定的场景。这个工作流的核心逻辑是函数的类型注解和参数命名本身就包含了大量信息。比如一个函数签名是def transfer_funds(from_account: str, to_account: str, amount: Decimal) - TransferResultAI就能推断出需要测试的场景正常转账、余额不足、账户不存在、金额为负、金额为零、金额超过限额、并发转账等。4.2 最小可用配置一键生成测试骨架我通常会在写完一个模块后把模块代码贴给AI用这个提示词请为以下代码生成pytest测试用例。 ## 要求 1. 使用pytest风格测试函数命名清晰 2. 覆盖正常路径和异常路径 3. 使用参数化测试覆盖多个输入组合 4. Mock所有外部依赖数据库、HTTP调用等 5. 每个测试用例只验证一个行为 ## 代码 [粘贴模块代码] 请输出完整的测试文件包含必要的import和fixture。生成之后我会做三件事第一检查Mock是否合理有没有把不该Mock的东西也Mock了第二补充业务特定的测试场景比如“VIP用户转账免手续费”这种AI不知道的业务规则第三运行测试看覆盖率报告针对未覆盖的分支手动补充用例。4.3 进阶调优让测试用例跟着代码一起演进测试用例最大的问题是“写完就过时”。代码改了测试没改跑起来一堆失败最后大家干脆不跑了。我的解决方案是把测试用例的维护也纳入AI工作流。具体做法是每次修改函数逻辑后把修改前后的代码和现有的测试用例一起贴给AI让它做三件事判断哪些现有测试用例需要修改生成新的测试用例覆盖新增的逻辑分支标记出可能已经失效的测试用例这个流程我称之为“测试同步”。实测下来它能把测试维护的时间减少60%以上。以前改一个函数要花十几分钟调整测试现在AI几秒钟就能给出修改建议我只需要确认和微调。还有一个很实用的技巧是用AI生成测试数据。比如你需要测试一个订单系统需要构造各种状态的订单数据。可以让AI生成一批符合业务规则的测试数据包括边界值、异常值、特殊字符等。这比手动造数据快得多而且覆盖更全面。4.4 实操心得测试用例的质量比数量重要我见过很多团队追求“覆盖率100%”但测试用例本身写得很烂——一个测试函数里塞了十几个断言失败了根本不知道是哪个环节出的问题。AI生成测试用例时也有这个倾向它喜欢把所有场景塞进一个函数里。我的做法是强制要求一个测试函数只验证一个行为。如果AI生成的测试函数里有多个断言我会让它拆开。虽然这样测试文件会变长但排查问题时效率高得多。一个测试失败你立刻就知道是哪个行为出了问题不用在一堆断言里找。另外不要盲目相信AI生成的Mock。AI有时候会把被测函数内部的逻辑也Mock掉导致测试实际上什么都没验证。我一般会检查每个Mock的必要性这个依赖是外部服务吗是的话可以Mock如果是同一个模块内的函数尽量用真实实现。5. 三个工作流的组合使用与工具选型5.1 组合使用的节奏这三个工作流不是孤立的它们可以串成一条完整的开发流水线写代码前用工作流一的提示词模板让AI生成符合项目风格的代码骨架写代码后用工作流三生成测试用例跑通测试提交代码前用工作流二做一轮自动审查修掉明显问题提交代码后人工Reviewer专注于业务逻辑和架构设计这个流水线跑顺之后我自己的开发节奏大概是这样的一个中等复杂度的接口包含参数校验、数据库操作、业务逻辑、异常处理从开始写到最后提交大概20到30分钟。其中AI生成代码占5分钟手动调整业务逻辑占10分钟生成和调整测试占5分钟审查和修复占5分钟。相比纯手写效率提升大概在两到三倍。5.2 工具选型不追新只选顺手的市面上AI编程工具很多我的选型原则很简单能在我现有的IDE里用、能理解项目上下文、能自定义提示词。具体来说我主要用三类工具第一类是IDE内置的补全工具比如各类代码补全插件。这类工具适合写代码时的实时补全优点是响应快、不打断思路缺点是无法处理复杂任务。我一般用它来补全函数调用、循环结构、简单的CRUD代码。第二类是对话式编程助手可以贴代码、贴上下文、给复杂指令。这类工具适合工作流一和工作流二因为需要传入项目上下文和审查规则。我一般用它来生成模块代码、做代码审查、分析重构方案。第三类是测试生成工具有些工具专门针对测试场景做了优化能自动识别需要Mock的依赖、生成参数化测试。这类工具适合工作流三但通用性不如前两类我一般只在写单元测试时用。提示不要同时用太多工具。我试过在同一个项目里混用四五个AI工具结果提示词格式不统一、上下文重复粘贴、生成风格不一致反而增加了认知负担。最后精简到两三个效率反而更高。5.3 团队协作中的注意事项如果你想把这三个工作流推广到团队有几个坑需要提前避开第一提示词模板要统一。如果每个人用的提示词不一样生成的代码风格就会五花八门代码审查时全是风格问题。我的做法是把提示词模板放到项目仓库里作为团队规范的一部分新人入职时直接参考。第二审查规则要共同维护。工作流二的审查规则库不能只由一个人维护否则会偏离团队的实际需求。我们团队的做法是每个季度回顾一次审查规则把反复出现的问题加进去把已经形成习惯的规则降级或移除。第三测试标准要明确。工作流三生成的测试用例不同人可能对“覆盖充分”的理解不一样。我们团队定了一个最低标准每个公开函数至少有一个正常路径测试和一个异常路径测试核心业务函数需要覆盖所有分支。AI生成的测试用例按这个标准检查不达标的补充。6. 常见问题与排查技巧实录6.1 AI生成的代码跑不起来怎么办这是最常见的问题。我的排查顺序是这样的第一步检查导入语句。AI经常忘记导入某些模块或者导入路径写错。特别是相对导入和绝对导入混用时AI很容易搞混。我一般会先看报错信息里的ImportError把缺失的导入补上。第二步检查类型不匹配。比如AI把字符串传给了需要整数的参数或者把列表传给了需要元组的地方。这类问题在动态语言里不会立即报错但运行到某一行就会崩。我的做法是让AI生成代码时强制写类型注解这样至少能在静态检查阶段发现一部分问题。第三步检查依赖版本。AI的训练数据可能包含旧版本的API生成的代码用了已经废弃的方法。比如某些库的新版本改了函数签名AI还在用旧写法。这时候需要查一下官方文档手动更新。第四步检查环境差异。有时候代码在AI的“想象环境”里能跑在你的实际环境里跑不了。比如AI假设你用的是SQLite但你实际用的是PostgreSQL某些SQL语法就不兼容。这时候需要在提示词里明确写清楚环境信息。6.2 AI审查漏掉了明显问题怎么办AI审查不是万能的它有时候会漏掉一些人类一眼就能看出的问题。我遇到过几次AI审查通过、但人工Reviewer指出严重问题的情况。分析下来主要有几个原因原因一上下文不完整。AI只看到了改动的代码没看到被调用的函数实现。比如改动代码里调用了一个函数但这个函数内部有性能问题AI看不到所以没发现。解决办法是把相关函数的实现也贴进上下文。原因二审查规则不够具体。比如规则写的是“检查性能问题”但AI不知道你的项目里“循环内查询数据库”算性能问题。解决办法是把规则写得更具体最好带上示例。原因三AI的“宽容度”太高。有时候AI觉得某个写法“可以接受”但你的团队规范不允许。解决办法是在提示词里明确写“严格按照以下规则不要自行判断是否可接受”。6.3 测试用例生成后跑失败怎么办AI生成的测试用例跑失败通常有三种情况情况一Mock配置不对。AI可能Mock了错误的路径或者Mock的返回值不符合实际。比如它Mock了一个返回字典的函数但实际函数返回的是对象。解决办法是检查Mock的return_value是否和实际返回类型一致。情况二测试数据不符合业务规则。AI生成的测试数据可能违反了数据库约束或业务规则。比如它生成了一个金额为负数的订单但你的系统不允许负数金额。解决办法是在提示词里说明业务规则或者手动调整测试数据。情况三测试之间相互影响。AI生成的测试用例可能共享了状态导致执行顺序不同结果不同。比如一个测试修改了全局变量另一个测试依赖这个变量的初始值。解决办法是确保每个测试用例独立使用fixture来管理共享状态。6.4 常见问题速查表问题现象可能原因排查方法解决技巧生成的代码缺少导入AI上下文不完整检查报错信息中的ImportError在提示词中要求“包含所有必要导入”代码风格与项目不一致缺少风格示例对比项目标准文件使用示例驱动贴一段参考代码审查漏掉性能问题审查规则太笼统检查规则是否具体把规则拆成可执行的检查项测试用例Mock错误Mock路径或返回值不对检查Mock的target和return_value用真实对象替代不必要的Mock测试之间相互干扰共享状态未隔离单独运行每个测试使用fixture管理共享状态AI反复犯同一个错误提示词缺少约束回顾历史生成记录把该约束加到提示词模板中6.5 我踩过的最大的坑最后分享一个我踩过的最大的坑过度依赖AI生成代码导致自己逐渐丧失了手写代码的能力。有一段时间我几乎所有代码都让AI生成自己只做审查和调整。结果有一次遇到一个AI怎么也生成不对的复杂逻辑我发现自己居然不知道该怎么手写了——脑子里全是“让AI试试这个提示词”“换个模型再生成一次”而不是“这个逻辑应该怎么拆解”。从那以后我给自己定了一个规矩每天至少手写一个完整的函数不借助任何AI辅助。这个习惯帮我保持了代码手感也让我在AI生成效果不好的时候能够自己顶上。AI是工具不是替代品。工作流的意义是让你把精力集中在更有价值的事情上而不是让你变成只会点“生成”按钮的人。这三个工作流我用了大半年中间迭代了无数次提示词和规则库现在基本稳定下来了。它们不是什么高深的技术核心就是把重复性的编码工作标准化、模板化然后交给AI执行。你不需要一次全部用上可以先从工作流一开始跑顺了再加第二个。关键是找到适合自己项目节奏的那一套然后持续优化。