1. 为什么“工作流”比“提示词”更值得花时间大多数人接触 AI 编程第一步都是去搜“最强提示词”“万能模板”。我早期也这么干过收藏夹里躺了上百条提示词真到写项目的时候能顺手用上的没几条。问题不在于提示词写得不好而在于提示词是单点的——它只解决“这一次我问什么”解决不了“这一类活我该怎么稳定地干完”。工作流不一样。工作流是把“输入、处理、验证、输出”串成一条固定管线你每次只需要把原料丢进去中间环节自动跑最后拿到的东西质量波动很小。打个比方提示词像是你临时找路人问路问一次管一次工作流像是你手机里存好的导航路线每次出发直接调用不用重新问。我后来复盘真正让我效率翻倍的不是某条神级提示词而是三个能反复套用的工作流。它们分别覆盖了日常开发里最高频的三类场景读别人的代码、写新功能、改出问题的老代码。这三个场景几乎占了普通开发者 80% 的时间把这三条管线搭好剩下的就是往里灌需求。这篇文章我会把这三个工作流完整拆开包括每一步为什么这么设计、参数怎么给、哪些地方容易翻车、以及我自己踩过的坑。你不需要任何特殊工具主流的 AI 编程助手都能跑重点是流程本身而不是某个特定产品。提示下面所有工作流的核心思路都是“先让 AI 理解上下文再让它动手”跳过理解直接让它写代码是新手最常见的翻车原因。2. 工作流一陌生代码库的“三遍阅读法”2.1 直接让 AI 解释代码为什么经常答非所问你接手一个别人的项目或者隔了三个月回头看自己写的模块第一反应往往是选中一大段代码丢给 AI“帮我解释一下这段在干嘛。”结果 AI 给你逐行翻译了一遍语法你读完还是不知道这段代码在整个系统里扮演什么角色。根本原因是AI 只看到了你选中的片段看不到它的调用方、被调用方、数据从哪来、往哪去。代码的意义有一半在上下文里脱离上下文的解释必然是浅的。我试过把整个文件丢进去好一点但文件之间的依赖关系还是断的。所以“三遍阅读法”的第一遍不是读代码而是读结构。2.2 第一遍让 AI 画出模块地图第一遍的目标只有一个搞清楚这个项目有哪些模块、模块之间怎么调用。具体操作是把项目的目录树用tree命令或者 IDE 自带的目录导出连同入口文件一起给 AI然后问一个非常具体的问题这是一个项目的目录结构和入口文件。 请回答三个问题 1. 这个项目从启动到处理一个请求大致经过哪几个模块 2. 每个模块的职责用一句话概括。 3. 哪些模块是核心哪些是工具类 不要解释具体代码只讲模块关系。注意最后那句“不要解释具体代码”这是关键。不加这句AI 很容易滑进细节里给你讲某个函数怎么实现的而你要的是地图。我实测下来加上这句约束输出的结构清晰度能提升一大截。这一遍产出的东西应该是一张你能看懂的模块关系图文字版就行。如果 AI 给的模块划分和你的直觉对不上别急着往下走先追问“模块 A 和模块 B 之间是通过什么方式通信的”把关系确认清楚。2.3 第二遍顺着一条主链路追下去有了地图第二遍挑一条最重要的业务链路从头追到尾。比如一个电商项目就追“用户下单”这条线一个后台系统就追“登录鉴权”这条线。把这条链路上涉及的文件按调用顺序喂给 AI一次喂一段让它做一件事这是下单链路中的第 2 个环节订单校验。 上游传进来的数据结构是 XXX下游需要的数据结构是 YYY。 请说明这个环节做了哪些校验哪些校验是业务必须的哪些是防御性的 如果校验失败错误是怎么往上抛的这里我特意让它区分“业务必须的校验”和“防御性校验”因为这两类代码的修改风险完全不同。业务校验动了会出 bug防御性校验动了通常没事。这个区分能帮你在后续改代码时快速判断哪些地方碰不得。第二遍是最花时间的但也是最值的。走完一条完整链路你对这个项目的理解会从“知道有哪些文件”变成“知道数据怎么流动”。2.4 第三遍只读测试和配置文件第三遍很多人会跳过但我强烈建议做。测试文件和配置文件里藏着大量“文档里不会写”的信息边界条件是什么、哪些参数不能乱改、历史上踩过什么坑。让 AI 帮你做这件事的提示可以这样写这是项目的测试文件或配置文件的注释部分。 请提取 1. 测试覆盖了哪些边界情况 2. 有没有测试用例的命名暗示了曾经的 bug 3. 配置项里哪些有“不要修改”之类的警告 用列表输出每条注明来源文件。测试用例的命名经常很直白比如test_order_amount_overflow一看就知道历史上出过金额溢出的问题。这些信息比读十遍业务代码都管用。2.5 三遍阅读法的避坑清单常见错误后果正确做法一上来就选中大段代码让 AI 解释得到逐行翻译没有全局观先给目录树和入口文件读结构一次喂太多文件AI 抓不住重点输出泛泛按调用顺序分段喂一次一个环节不问“为什么这么写”只知道是什么不知道能不能改追问设计意图和修改风险跳过测试和配置文件漏掉边界条件和历史坑专门花时间读测试命名和配置注释我自己踩过最深的坑是第二遍追链路时图快一次把五六个文件全丢进去结果 AI 把不同文件的逻辑混在一起讲我照着理解改代码直接引入了一个跨模块的 bug。后来老老实实一段一段来虽然慢但理解准确返工反而少。3. 工作流二从需求到可运行代码的“四步收敛”3.1 让 AI 直接写功能为什么总差一口气“帮我写一个用户注册接口。”这句话丢给 AI它能给你吐出一堆代码但十有八九不能直接用字段名和你项目里的对不上、错误码体系不一致、没考虑你已有的工具类、数据库操作风格也不对。你改它的代码花的时间可能比自己写还多。这不是 AI 能力不行是需求给得太粗。从“一句话需求”到“可运行代码”之间隔着好几层决策数据结构、接口约定、错误处理、边界条件。这些决策你不做AI 就替你做了而它做的决策大概率不符合你项目的既有约定。“四步收敛”就是把这几层决策拆开一步一步和 AI 对齐最后才让它写代码。3.2 第一步把需求翻译成数据结构任何功能先别想代码先想数据。用户注册这个功能输入是什么、输出是什么、中间存什么用一段话描述清楚我要做一个用户注册功能。 输入手机号、密码、验证码。 输出成功返回用户 ID 和 token失败返回错误码。 存储用户表存手机号唯一、密码哈希、注册时间。 约束手机号格式校验、密码长度 8-20 位、验证码 5 分钟有效。 请先不要写代码把上面的数据结构用表格整理出来标出每个字段的类型和约束。让它先输出数据结构表格你检查一遍。这一步能拦下大量后续返工——字段类型错了、约束漏了在这里改成本最低。3.3 第二步定接口契约数据结构确认后定接口。接口契约包括路径、方法、请求体、响应体、错误码。还是让它先输出约定不写实现基于上面的数据结构设计注册接口的契约。 要求 1. 路径和方法 2. 请求体和响应体的 JSON 结构 3. 列出所有可能的错误码及含义 4. 说明每个错误码在什么情况下返回 用表格输出不要写实现代码。错误码这块要特别较真。很多 AI 生成的代码错误处理很随意要么全返回 500要么错误信息含糊。你在这里把错误码定死后面实现阶段它就没法偷懒。3.4 第三步指定项目内的复用点这一步是让 AI 写出的代码“像你项目里的代码”的关键。你要明确告诉它项目里已经有哪些工具类、哪些约定必须遵守。实现这个接口时请遵守以下项目约定 1. 密码哈希用项目已有的 PasswordUtil.hash()不要自己实现 2. 数据库操作走 UserRepository不要直接写 SQL 3. 错误码用项目统一的 ErrorCode 枚举 4. 日志用项目封装的 Logger 如果你不确定某个工具类的用法先问我不要猜。最后那句“先问我不要猜”非常重要。AI 在不确定的时候倾向于编一个看起来合理的 API你不拦着它就会编。我遇到过它凭空造了一个PasswordUtil.encrypt()方法而项目里实际叫hash()编译直接报错。3.5 第四步分块生成逐块验证前三步对齐后才让它写代码而且不要一次写完。按“数据校验 → 业务逻辑 → 持久化 → 返回组装”分块生成每生成一块你扫一眼没问题再生成下一块。现在实现注册接口分四步输出每步输出后停下等我确认 第一步参数校验逻辑 第二步验证码校验和密码哈希 第三步写库 第四步组装返回值和错误处理 先输出第一步。分块的好处是出错时你能立刻定位是哪一块的问题而不是面对两百行代码找 bug。实测下来分块生成的整体返工率比一次性生成低很多。3.6 四步收敛的节奏把控这套流程听起来步骤多但熟练之后很快。我现在的节奏是数据结构加接口契约大概五分钟复用点说明两分钟分块生成加检查十分钟出头。比起写完再改半小时这个投入是划算的。有个细节值得说每一步的产出都存下来。数据结构表格、接口契约、复用点清单这些在后续写测试、写文档、交接时都能直接复用。我习惯把它们贴到项目的设计文档里下次做类似功能直接改改就能用。4. 工作流三老代码排错的“假设-验证”循环4.1 把报错直接丢给 AI为什么它总在瞎猜线上出了个 bug你把报错信息复制给 AI“这个错误怎么修”它给你列了五条可能原因你一条条试试到第三条发现不对回头再看前两条的修改还留在代码里忘了撤。这个流程的问题在于AI 在猜你也在猜双方都没有验证。报错信息只是症状不是病因。同一个报错可能对应十种原因不缩小范围就动手等于蒙眼修车。“假设-验证”循环的核心是让 AI 基于证据提出可验证的假设你负责验证验证结果反馈给它逐步收敛到真正的原因。4.2 第一步收集证据而不是收集猜测出 bug 时先别问“怎么修”先收集三类证据完整的报错堆栈、出问题时的输入数据、最近改动的代码。把这三样一起给 AI然后提一个不一样的问题这是报错堆栈、触发问题的输入数据、以及最近一次改动的 diff。 请先不要给修复方案。 基于这些证据列出 3 个最可能的原因按可能性排序。 每个原因说明如果是这个原因应该能在哪里观察到什么现象来验证。注意最后那句“应该能在哪里观察到什么现象来验证”。这是把 AI 从“猜答案”拉到“提假设”的关键。好的假设是可证伪的你能通过看日志、加断点、改输入来确认或排除。4.3 第二步一次只验证一个假设拿到假设列表后一次只验证一个从可能性最高的开始。验证方式通常是三种看日志、加临时断点、构造特定输入复现。验证完把结果告诉 AI我验证了假设 1在 XXX 处加了日志发现数据到这一步时 YYY 字段是 null 和假设 1 描述的“数据在传递中丢失”一致。 但假设 1 说丢失发生在 A 环节实际日志显示 A 环节数据是正常的丢失发生在 B 环节。 基于这个新证据重新评估剩下的假设。这个反馈很关键。你不仅告诉它“对/不对”还告诉它“哪里对、哪里不对”它就能修正判断。我试过只回一句“不对”AI 会重新瞎猜一轮把观察到的现象说清楚它往往能立刻锁定方向。4.4 第三步定位后先写复现测试再改代码找到根因后别急着改。先写一个能稳定复现这个 bug 的测试用例。这一步很多人嫌麻烦跳过但它有两个好处一是确认你真的理解了根因二是改完之后能立刻验证修好了、且没引入新问题。根因确认是 B 环节在数据为空时没有做兜底。 请先写一个测试用例构造出“数据为空”的场景让这个测试当前是失败的。 测试写好后先别改业务代码等我确认测试能复现问题。测试能稳定复现后再让 AI 改业务代码改完跑测试从红变绿才算修完。4.5 假设-验证循环里最容易犯的三个错第一个错是同时验证多个假设。你改了 A 又改了 Bbug 没了但你不知道是哪个改动起的作用也不知道另一个改动会不会埋下新雷。一次一个是铁律。第二个错是跳过复现测试。我早期修 bug 从不写测试改完手动点一遍觉得好了就提交结果过两天同样的问题换个入口又冒出来。有了复现测试至少能保证这个入口是堵死的。第三个错是不记录验证过程。修完 bug 就把对话关了下次遇到类似问题又从头猜。我现在会把“证据、假设、验证结果、根因、修复”整理成一小段记录存到项目的 issue 或笔记里。积累多了你会发现很多 bug 是同一类下次直接查记录就行。阶段输入输出关键约束收集证据堆栈、输入数据、diff证据包不带主观猜测提假设证据包3 个可验证假设每个假设附验证方法验证单个假设确认或排除一次只验一个复现根因失败测试用例先红后绿修复失败测试通过的测试改完必跑测试5. 三个工作流怎么串起来用5.1 按任务类型选工作流而不是按心情这三个工作流不是孤立的实际开发中经常需要切换。我的判断标准很简单当前任务的主要矛盾是什么。接手新项目、看不懂代码用工作流一要加新功能、从零写用工作流二已有功能出问题、行为不符合预期用工作流三。如果任务同时涉及多个就按“先理解、再动手、出问题再排错”的顺序走。比如你要在一个陌生项目里加功能正确顺序是先用三遍阅读法搞清楚项目结构和约定再用四步收敛写新功能写完自测发现问题再用假设-验证循环排错。跳过第一步直接写写出来的代码大概率不符合项目风格。5.2 把工作流固化成自己的检查清单工作流用熟了之后可以把它压缩成一张检查清单每次开工前扫一眼。我的清单大概长这样读代码前拿到目录树和入口文件了吗知道核心模块了吗写功能前数据结构和接口契约定了吗项目复用点列了吗排错前证据收集齐了吗假设是可验证的吗复现测试写了吗这张清单贴在显示器边上能省掉大量“想不起来该干嘛”的时间。刚开始可能觉得繁琐用两周就成肌肉记忆了。5.3 关于工具选择的一点实在话这三个工作流对工具的要求其实不高主流的 AI 编程助手都能跑。真正影响效果的是你怎么组织输入而不是你用的是哪个模型。我见过有人用着很贵的工具还是把一大坨代码丢进去问“帮我看看”效果自然一般。选工具时我建议关注两点一是能不能方便地贴入多文件上下文二是能不能保持长对话不丢上下文。这两点直接决定了工作流一和工作流三能不能顺畅跑。至于模型本身的能力现在头部几个差距没那么大够用就行。5.4 我踩过的最大一个坑最后说个我自己的教训。有段时间我迷上了“全自动”想让 AI 一口气把读代码、写功能、跑测试全干了中间不干预。结果是一次任务里它理解错了模块职责写出来的功能调用了错误的接口测试又因为环境问题没跑起来等我发现时已经改了一大堆文件回滚都费劲。后来我彻底放弃了这个念头。AI 编程的正确姿势是人在关键节点做决策AI 在执行环节提效率。数据结构、接口契约、根因判断这些决策点必须人来把关代码生成、测试编写、日志分析这些执行环节放心交给 AI。三个工作流的设计本质上就是把决策点和执行点分开让各自干各自擅长的事。这个边界感比任何提示词技巧都重要。