1. 为什么“能立刻复用”才是 AI 编程工作流的真正门槛我见过太多人收藏了几百个 AI 编程提示词真正干活的时候还是一个一个手动粘贴。问题不在于提示词写得不好而在于这些提示词没有被组织成工作流——也就是一套有固定输入、固定处理链路、固定输出格式的可重复执行流程。所谓 AI 编程工作流说白了就是把“人反复做的决策”固化下来交给一套稳定的步骤去跑。它和单次对话式使用 AI 的区别就像手写 SQL 和写一个存储过程的区别前者每次都要重新想后者一次写好、反复调用。我这次整理的三套工作流分别覆盖三个最高频的场景代码生成与审查、遗留代码理解与重构、多 AI 协作完成复杂任务。它们有一个共同特点——你今天看完今天就能套用到自己的项目里不需要额外搭建复杂基础设施不需要付费订阅一堆工具用你手头已有的 AI 编程助手就能跑起来。适合谁看如果你已经用过 AI 写代码但总觉得“效果不稳定”“每次都要重新调教”那这三套工作流就是给你准备的。如果你还没怎么用过 AI 编程也没关系我会把每一步的操作意图和参数选择逻辑讲清楚你照着搭一遍就能理解背后的思路。下面我会先讲每套工作流的整体设计思路和选型考量再拆解核心环节的具体操作最后把我踩过的坑和排查经验整理出来。全文没有花哨的概念都是能直接抄作业的东西。2. 工作流一代码生成与自审查闭环2.1 核心思路让 AI 先写再挑自己的毛病大多数人用 AI 写代码的流程是描述需求 → AI 生成 → 复制粘贴 → 自己改。这个流程最大的问题是AI 生成的第一版代码往往有隐藏问题——边界条件没处理、异常没捕获、命名不一致。而人眼审查 AI 生成的代码时容易产生“信任惯性”觉得 AI 写的应该差不多。我的做法是在工作流里强制加入一个自审查环节让 AI 生成代码后立刻用另一个独立的提示词让它以“代码审查者”的身份重新审视自己的输出。这个环节的关键在于角色切换——生成时它是“实现者”审查时它是“挑刺者”两种角色的关注点完全不同。为什么这个设计有效因为 AI 在生成模式下倾向于“把功能做出来”而在审查模式下提示词会引导它关注“哪里可能出错”。实测下来同一个模型在审查模式下能发现自己生成代码中 60% 以上的边界条件问题和命名问题。这不是因为模型变聪明了而是因为提示词改变了它的注意力分配。2.2 具体操作步骤与提示词模板整个工作流分四步我把它叫做GCRC 循环Generate生成、Critique审查、Revise修订、Confirm确认。第一步Generate——带约束的代码生成关键不是简单地说“帮我写一个函数”而是把约束条件一次性给全。我常用的模板结构是角色你是一名有 10 年经验的 [语言] 后端工程师。 任务实现 [具体功能描述]。 约束 - 输入[参数类型和含义] - 输出[返回类型和含义] - 边界条件[列出你知道的边界情况] - 错误处理[期望的异常处理方式] - 代码风格[命名规范、注释要求] - 禁止[明确不要用的库或写法] 请先输出实现思路3 行以内再输出代码。这里有个细节要求先输出思路再输出代码。这一步看似多余实际上能大幅提升代码质量。因为模型在“先想后写”的模式下逻辑连贯性明显更好。我对比过加了这一步之后生成代码的一次通过率大概能从 50% 提升到 75% 左右。第二步Critique——切换角色做审查拿到代码后不要直接改而是新开一个对话或者在同一个对话里明确切换角色用审查提示词角色你是一名严格的代码审查者你的职责是找出问题而不是赞美。 任务审查以下代码按严重程度分类列出问题。 审查维度 1. 边界条件空值、越界、并发、超时 2. 错误处理异常是否被吞掉、错误信息是否有用 3. 可读性命名、注释、函数长度 4. 性能不必要的循环、重复计算、内存泄漏风险 5. 安全性注入、越权、敏感信息泄露 输出格式用表格列出每行包含 [严重程度, 问题描述, 建议修改]。 代码 [粘贴上一步生成的代码]这个提示词的关键是审查维度要具体。如果你只说“帮我审查代码”模型大概率会给你一些泛泛而谈的建议。但当你列出五个具体维度它会逐项去检查发现的问题数量和质量都明显提升。第三步Revise——基于审查结果修订把审查表格里的问题逐条喂回去让模型修订。这里有个技巧不要一次性把所有问题都丢给它而是按严重程度分批处理。先修“严重”和“高”级别的问题确认修订结果后再处理“中”和“低”。这样做的好处是避免模型在大量修改中顾此失彼也方便你逐步验证。第四步Confirm——用测试用例做最终确认最后一步是让 AI 根据功能描述生成测试用例然后你手动跑一遍。测试用例的提示词根据以下功能描述生成 [测试框架] 的单元测试 功能描述[原始需求] 边界条件[之前列出的边界条件] 要求 - 每个边界条件至少一个测试用例 - 包含正常路径和异常路径 - 测试命名要能看出测试意图2.3 实操心得与常见坑这套工作流我用了大半年有几个经验值得分享。坑一审查环节不要用同一个对话上下文。如果你在生成代码的同一个对话里直接说“帮我审查一下”模型会倾向于维护自己刚才的输出审查力度明显下降。我的做法是复制代码新开一个对话专门做审查。如果工具支持多会话这一步成本几乎为零。坑二审查提示词里不要写“请找出所有问题”。这句话会让模型产生“必须找出点什么”的压力导致它把一些不是问题的地方也标成问题。用“按严重程度分类列出问题”更合理没有问题就输出空表格这样反而更可信。坑三修订后一定要重新审查。模型在修订时可能引入新问题尤其是当修改涉及多个函数时。我的习惯是修订后再跑一次审查但这次只关注“修订是否引入了新问题”提示词可以简化。坑四测试用例不要完全信任 AI。AI 生成的测试用例经常漏掉一些它自己没想到的边界条件。我的做法是把 AI 生成的测试用例作为起点然后自己补充 2-3 个“刁钻”的用例。实测下来AI 测试用例能覆盖 70% 左右的常见问题剩下 30% 还是得靠人。3. 工作流二遗留代码理解与渐进式重构3.1 核心思路先建地图再动刀接手一个没有文档、没有测试、原作者已经离职的项目是每个程序员都会遇到的噩梦。传统做法是硬着头皮读代码读着读着就迷失在几百行的函数里。AI 在这个场景下能帮大忙但前提是你要用对方法。我的核心思路是先让 AI 帮你建一张“代码地图”再基于地图做渐进式重构。所谓代码地图就是一份结构化的文档包含模块划分、核心数据流、关键函数清单、外部依赖、可疑代码标记。有了这张地图你就不需要一次性理解所有代码而是可以按图索骥一块一块地啃。为什么强调“渐进式”因为遗留代码最大的风险是“改一处崩三处”。在没有测试覆盖的情况下大规模重构等于赌博。渐进式重构的核心原则是每次只改一个可独立验证的小块改完立刻验证验证通过再改下一块。3.2 三步建立代码地图第一步模块级扫描把项目目录结构喂给 AI让它输出模块划分和职责推测。提示词以下是一个项目的目录结构 [粘贴 tree 命令的输出] 请分析 1. 这个项目大致分为哪几个模块每个模块的职责是什么 2. 模块之间的依赖关系是怎样的 3. 哪些模块看起来是核心业务逻辑哪些是工具类 4. 有没有看起来可疑的目录比如命名混乱、职责不清 输出格式用列表说明每个模块附上推测依据。这一步的产出是一张模块级地图。注意AI 的推测不一定准确但它的价值在于给你一个“初始假设”你带着假设去读代码效率比盲目读高得多。第二步核心文件深度解析选定 2-3 个核心文件让 AI 做逐函数解析。提示词请分析以下代码文件 [粘贴文件内容] 输出 1. 文件整体职责一句话 2. 每个函数的函数名、输入、输出、副作用、被谁调用如果能推断 3. 数据流数据从哪来经过哪些处理到哪去 4. 可疑点超长函数、重复逻辑、硬编码、缺少错误处理的地方 用表格输出函数清单用段落说明数据流和可疑点。这一步的产出是函数级地图。我通常会把这步的输出保存成一个 Markdown 文件放在项目根目录作为后续重构的参考。第三步依赖关系梳理让 AI 帮你梳理模块间的调用关系。提示词基于以下函数清单和代码片段请梳理模块间的调用关系 [粘贴上一步的输出] 输出 1. 调用关系图用文字描述比如 A 调用 B 的 x 函数B 调用 C 的 y 函数 2. 循环依赖如果有 3. 最底层的模块不依赖其他模块的 4. 最顶层的模块不被其他模块依赖的这一步的产出是依赖地图。有了它你就知道重构应该从哪个模块开始——通常从最底层、依赖最少的模块开始因为改它影响面最小。3.3 渐进式重构的具体操作有了代码地图重构就有了路线图。我的重构顺序通常是先加测试再改命名再拆函数最后调结构。加测试是第一步也是最重要的一步。没有测试的重构等于裸奔。如果项目完全没有测试我会让 AI 根据代码地图生成“特征测试”——也就是记录当前行为的测试不关心行为对不对只关心行为有没有变。提示词根据以下函数说明生成特征测试 [粘贴函数清单] 要求 - 测试当前实际行为不判断对错 - 覆盖主要输入组合 - 用 [测试框架] 编写 - 每个函数至少一个测试改命名是低风险高收益的操作。把 AI 标记的“命名不清”的函数和变量重命名改完跑一遍测试。这一步不需要理解业务逻辑纯粹是机械操作但能大幅提升后续阅读效率。拆函数是中等风险操作。把超长函数按职责拆成多个小函数每次拆一个拆完跑测试。这里有个技巧先提取再内联。也就是先把一段逻辑提取成新函数确认测试通过后再把原位置的代码替换成函数调用。这样每一步都是可验证的。调结构是高风险操作通常放在最后。比如把循环依赖解开、把模块边界重新划分。这一步我建议在测试覆盖率达到 60% 以上再做否则风险太大。3.4 实操心得与常见坑坑一不要让 AI 一次性分析整个项目。大项目的代码量远超模型上下文窗口硬塞进去只会得到一堆废话。正确做法是分层分析先目录再文件再函数逐层深入。坑二AI 的“可疑点”标记需要人工确认。AI 经常把一些正常的复杂逻辑标成“可疑”也会漏掉一些真正的坏味道。我的做法是把 AI 的标记作为“待检查清单”逐条人工确认确认一条划掉一条。坑三特征测试不要追求覆盖率。特征测试的目的是“防止行为意外改变”不是“验证行为正确”。所以不需要追求 100% 覆盖率覆盖核心路径和关键边界就够了。我通常目标定在 50%-60%剩下的靠人工 review。坑四重构提交要小而频繁。每次提交只做一件事提交信息写清楚改了什么、为什么改。这样出问题时容易回滚也方便 code review。我见过有人一次提交改了 20 个文件出了问题根本不知道是哪处改动导致的。4. 工作流三多 AI 协作完成复杂任务4.1 核心思路让不同 AI 扮演不同角色单个 AI 处理复杂任务时容易出现“顾此失彼”的问题——比如让它同时做架构设计和代码实现它可能架构设计得不错但代码写得很糙或者反过来。这是因为单个模型的注意力是有限的任务越复杂每个方面分到的注意力越少。多 AI 协作的核心思路是任务分解 角色专精。把复杂任务拆成多个子任务每个子任务交给一个“专精”的 AI 角色去处理最后把结果汇总。这就像软件开发团队的分工架构师做设计程序员写代码测试工程师写测试各司其职。为什么这个思路有效因为当 AI 的提示词聚焦在单一角色上时它的输出质量明显更高。我做过对比实验让一个 AI 同时做“设计 API 实现 API 写测试”和让三个 AI 分别做这三件事后者的综合质量高出不少。代价是调用次数增加但对于复杂任务来说这个代价是值得的。4.2 角色划分与协作流程我常用的角色划分是四个架构师、实现者、审查者、集成者。每个角色的提示词模板如下。架构师负责把需求拆成可实现的模块和接口角色你是一名系统架构师。 任务根据以下需求设计系统架构。 需求[详细需求描述] 输出 1. 模块划分每个模块的职责和对外接口 2. 数据模型核心数据结构 3. 关键流程主要业务流程的步骤 4. 技术选型建议语言、框架、存储 5. 风险点可能的技术难点和应对方案 约束不要写具体代码只做设计。实现者负责根据架构设计写代码角色你是一名 [语言] 工程师。 任务根据以下架构设计实现 [模块名] 模块。 架构设计[粘贴架构师输出的相关部分] 要求 - 严格按接口定义实现 - 包含错误处理和边界条件 - 代码风格[规范] - 每个函数附上简短注释 输出完整代码 实现说明3 行以内审查者负责审查实现者的代码角色你是一名严格的代码审查者。 任务审查以下代码是否符合架构设计和质量要求。 架构设计[粘贴架构师输出] 代码[粘贴实现者输出] 审查维度 1. 是否符合接口定义 2. 错误处理是否完整 3. 边界条件是否覆盖 4. 代码风格是否一致 5. 是否有性能或安全隐患 输出问题列表按严重程度排序 修改建议集成者负责把各模块组装起来并处理模块间的问题角色你是一名集成工程师。 任务将以下模块集成为一个完整系统。 模块清单[列出各模块及其接口] 集成要求 1. 检查模块间接口是否匹配 2. 处理模块间的数据转换 3. 编写集成测试 4. 输出集成说明文档 输出集成代码 集成测试 说明文档4.3 协作流程的编排方式四个角色不是随便调用的而是有固定的编排顺序。我的标准流程是架构师先跑输出架构设计实现者按模块并行跑每个模块一个独立对话审查者对每个模块的输出做审查实现者根据审查结果修订集成者把所有模块组装起来审查者对集成结果做最终审查这个流程的关键在于并行化。第 2 步的多个模块可以同时让不同的 AI 对话去实现互不干扰。第 3 步的审查也可以并行。这样整体耗时不会比单 AI 串行处理长太多但质量明显更高。如果你用的是支持多会话的 AI 编程工具这个流程可以手动编排。如果你用的是 API可以写一个简单的脚本自动编排。我用 Python 写过一个 50 行左右的编排脚本核心逻辑就是按顺序调用不同角色的提示词把上一步的输出作为下一步的输入。4.4 实操心得与常见坑坑一角色提示词要写清楚“不要做什么”。比如架构师提示词里要明确“不要写具体代码”否则它会忍不住把代码也写了导致实现者没有发挥空间。同理实现者提示词里要明确“不要改接口定义”否则它可能自作主张改接口导致集成时对不上。坑二模块划分粒度要适中。模块太大实现者一次处理不过来模块太小集成成本太高。我的经验是每个模块控制在 200-500 行代码左右对应 3-5 个函数。这个粒度下实现者能一次生成完整模块集成者也不至于被大量模块淹没。坑三审查者的输出要结构化。如果审查者输出一大段文字实现者很难逐条处理。我的做法是要求审查者用表格输出每行一个问题包含“严重程度、问题描述、建议修改”。实现者按表格逐条处理处理完一条标记一条。坑四集成阶段最容易出问题。各模块单独看都没问题但组装起来经常出现接口不匹配、数据格式不一致、错误处理冲突等问题。我的做法是在集成前先让审查者做一次“接口一致性检查”专门检查模块间的接口是否匹配。这一步能提前发现 80% 的集成问题。坑五不要指望一次成功。多 AI 协作的流程通常需要跑 2-3 轮才能得到满意结果。第一轮跑完把问题汇总调整提示词再跑第二轮。我通常会在第二轮之后才做人工介入前两轮让 AI 自己迭代。5. 三套工作流的通用避坑指南与工具选型建议5.1 通用避坑指南三套工作流虽然场景不同但有一些共通的坑我整理成一张速查表问题现象根本原因解决方法AI 输出质量不稳定提示词约束不够具体把约束条件列成清单逐条写清楚AI 忽略边界条件提示词没提边界在提示词里显式列出边界条件AI 审查时“放水”同一对话上下文新开对话做审查切换角色修订引入新问题一次改太多按严重程度分批修订每批验证模块间接口对不上缺少接口约定架构阶段明确定义接口集成前做一致性检查测试覆盖不足只依赖 AI 生成人工补充 2-3 个刁钻用例重构改崩了没有测试保护先加特征测试再重构上下文超长导致质量下降一次性塞太多内容分层处理逐层深入这张表里的每一条都是我实际踩过的坑。比如“AI 审查时放水”这一条我一开始没意识到后来发现同一个对话里让 AI 审查自己的代码它总是说“代码整体不错只有一些小问题”。新开对话后它立刻列出了七八个严重问题。这个差异非常明显。5.2 工具选型建议工具选型上我的原则是用你手头已有的工具不要为了工作流而换工具。三套工作流对工具的要求其实很低支持多会话用于角色切换支持长上下文用于分析大文件支持 Markdown 输出方便保存和复用如果你用的是 IDE 内置的 AI 助手通常都满足这些条件。如果你用的是网页版对话工具多开几个标签页也能实现。如果你用 API可以写脚本自动化编排。有一个工具选型的细节值得说不同模型适合不同角色。我的经验是架构设计用推理能力强的模型代码实现用代码能力强的模型审查用指令遵循能力强的模型。如果你手头有多个模型可用可以按角色分配。如果只有一个模型也没关系通过提示词切换角色同样有效只是效果略打折扣。5.3 工作流的复用与迭代这三套工作流不是一成不变的你需要根据自己的项目特点做调整。我的建议是第一周严格按模板跑熟悉流程。这个阶段不要改提示词先跑通再说。第二周开始微调提示词。比如你的项目有特殊的代码规范就加到提示词里你的项目有特殊的边界条件就补充到边界条件清单里。第三周之后形成自己的提示词库。把常用的提示词片段保存下来比如“错误处理要求”“命名规范”“测试框架模板”等用的时候拼装即可。我自己的提示词库现在有 30 多个片段按场景分类。写新提示词时大部分内容是拼装已有片段只有少部分是针对当前任务的特殊约束。这样效率很高而且质量稳定。5.4 一个容易被忽略的细节输出格式约定三套工作流都涉及大量 AI 输出如果输出格式不统一后续处理会很麻烦。我的做法是在所有提示词里都加上输出格式约定比如代码块用 语言 标注表格用 Markdown 表格问题列表用有序列表每个输出段落不超过 5 行这个约定看起来琐碎但实际用起来差别很大。格式统一的输出可以直接粘贴到文档里不需要二次整理。我见过有人 AI 输出一堆格式混乱的内容光整理格式就花了半小时完全违背了“提效”的初衷。5.5 关于“立刻复用”的最后一点经验“能立刻复用”的关键不在于工作流有多复杂而在于每一步都有明确的输入和输出。我见过很多人把工作流设计得很花哨又是自动编排又是多模型路由结果自己都记不住流程更别说复用了。我的建议是从最简单的版本开始。比如工作流一你一开始可以只做“生成 审查”两步跑顺了再加“修订”和“确认”。工作流二你可以先只做“模块级扫描”用熟了再做“函数级解析”。工作流三你可以先只分“实现者”和“审查者”两个角色跑顺了再加“架构师”和“集成者”。工作流的价值在于降低认知负担而不是增加复杂度。如果一个工作流让你觉得“每次跑都要想半天”那它就不合格。好的工作流应该是你闭着眼睛都知道下一步该做什么每一步的输入输出都是确定的跑完一遍只需要几分钟。这三套工作流我用了大半年最大的体会是AI 编程的效率提升80% 来自流程设计20% 来自模型能力。同样的模型用工作流跑和随手用产出质量差距巨大。希望这三套工作流能帮你把 AI 编程从“碰运气”变成“可复现的工程实践”。