1. 为什么“工作流”比“提示词”更值得花时间大多数人接触 AI 编程第一步都是去搜“最强提示词”“万能模板”。我一开始也这样收藏夹里躺了上百条提示词真到写代码的时候能直接用的不到三条。问题不在于提示词写得不好而在于提示词是单点的——它只解决“这一次我问什么”解决不了“这一类活我该怎么干”。工作流不一样。工作流是把一个反复出现的任务拆成固定的几个环节每个环节交给 AI 做它最擅长的那部分中间用明确的输入输出串起来。打个比方提示词像是你临时找路人问路工作流像是你手机里存好的导航路线——下次去同一个地方直接点开始就行。我统计过自己过去半年的编码时间分布真正“想算法”的时间大概占三成剩下七成全是重复劳动写样板代码、补单元测试、改命名、写提交信息、查报错、翻文档。这七成里至少有六成可以固化进工作流。这就是为什么我后来越来越少折腾提示词转而把精力放在搭工作流上。下面这三个工作流是我从日常开发里沉淀下来、几乎每天都会用到的。它们不依赖某个特定工具你用网页版对话、用编辑器插件、用命令行工具都能跑。我会把每个工作流的触发场景、环节拆解、每步的输入输出、以及我踩过的坑都讲清楚你照着改一改就能用。提示工作流的核心不是“让 AI 一次做完”而是“让 AI 在正确的环节做正确的事”。环节越清晰结果越稳定。2. 工作流一从一句需求到可运行代码的“三段式生成”2.1 这个工作流解决的是什么问题最常见的场景产品或者你自己脑子里冒出一句话需求比如“做一个能读取 CSV 并统计每列缺失率的脚本”。直接把这句丢给 AI它大概率会给你一段能跑但很粗糙的代码——没有参数校验、没有异常处理、列名硬编码、输出格式随缘。我试过直接生成然后手动改改的时间比写的时间还长。后来我把这个过程拆成三段每段让 AI 只做一件事质量立刻上来了。2.2 三段的具体拆法第一段需求澄清与边界确认。不要一上来就要代码。先把需求原话丢给 AI让它反问你三个问题输入是什么格式、输出要什么形式、有没有边界条件空文件、超大文件、编码问题。这一步的目的是把模糊需求逼成明确规格。我常用的开场是我有个需求原话。 先别写代码。请你列出这个需求里最容易被忽略的 3 个边界条件 并针对每个条件问我一个问题。第二段接口与结构设计。拿到澄清结果后让 AI 输出函数签名和模块划分不写实现。比如“给我三个函数名、每个函数的入参出参、以及它们之间的调用顺序”。这一步能提前暴露设计问题——很多时候你会发现 AI 设计的接口比你自己想的更合理或者反过来你能一眼看出它理解偏了。第三段逐函数实现。按第二段定好的签名一个一个函数让 AI 填实现。每次只给一个函数的上下文不要把所有代码一次性丢过去。这样做的好处是每个函数的实现都短、聚焦出错率低而且你随时可以叫停调整。2.3 为什么这样拆有效从信息论的角度看一次性生成整段代码AI 需要在一次输出里同时兼顾命名、结构、逻辑、边界、风格五个维度任何一个维度出问题都会污染整体。拆成三段后每一段只聚焦一到两个维度AI 的“注意力预算”集中了输出质量自然高。我做过对比同一个需求一次性生成平均要改 4 到 5 处才能跑通三段式生成平均改 1 到 2 处。多花的两分钟澄清时间省下了十分钟的调试时间。2.4 实操中的两个坑第一个坑是澄清阶段问太多。有次我让 AI 列边界条件它一口气列了十二条我光回答就花了十分钟。后来我固定让它只列三条够用就行。边界条件是无穷的抓大放小。第二个坑是第三段忘了给上下文。逐函数实现时如果只给函数签名不给数据结构定义AI 会自己臆造字段名。我的做法是在每次实现请求里固定带上“数据结构定义”和“已实现函数的签名列表”这两块作为公共上下文。3. 工作流二让 AI 当“第二双眼睛”的代码审查回路3.1 审查工作流的触发时机代码写完、自己跑通之后别急着提交。这时候是 AI 审查的最佳时机——你对代码还热乎AI 也能看到完整上下文。我一般在这三个节点触发审查功能刚跑通、准备提交前、以及接手别人代码要改之前。很多人用 AI 审查就是一句“帮我看看这段代码有没有问题”然后得到一堆“建议添加注释”“变量名可以更清晰”的废话。问题出在没有给审查设定角色和检查清单。3.2 给审查工作流装上“检查清单”我的做法是维护一份固定的审查清单每次审查时把清单和代码一起给 AI让它逐条对照。清单不长就五条但覆盖了我踩过的大部分坑检查项具体问法为什么重要边界处理空输入、超长输入、非法输入分别会怎样线上事故八成来自边界资源释放文件、连接、锁有没有在所有路径上释放泄漏问题最难查错误传播异常是被吞了还是往上抛了吞异常等于埋雷命名一致性同一概念在不同地方叫法是否统一影响后续维护隐藏耦合有没有依赖外部可变状态测试难写的根源把这张表连同代码一起发过去AI 的输出立刻从“泛泛而谈”变成“逐条定位”。它会告诉你“第 12 行的文件打开没有对应的关闭路径”“第 30 行的异常被 except 后只打印了日志没有重新抛出”。3.3 审查结果怎么用AI 审查出来的问题不要照单全收。我的处理原则是边界和资源类问题必改命名和风格类问题看情况架构类建议先记下来。因为 AI 有时候会过度设计把一个简单脚本建议改成三层架构那就本末倒置了。我一般会让 AI 把问题按“必须改 / 建议改 / 可选”三档分类然后我只处理“必须改”这一档。这样既拿到了价值又不会被建议淹没。3.4 一个真实的审查案例有次我写了个批量重命名文件的脚本自己测了几个文件都正常。丢给 AI 按清单审查它指出如果目标文件名已存在我的脚本会直接覆盖没有确认。这个问题我自己测的时候完全没遇到因为测试目录是空的。后来加了一行存在性检查避免了一次潜在的数据丢失。这件事让我意识到AI 审查最大的价值不是它比你聪明而是它没有你的思维惯性。你测的时候会下意识避开自己知道的坑AI 不会。4. 工作流三把“查报错”变成一次性的知识沉淀4.1 报错处理的常见误区遇到报错大多数人的流程是复制报错信息、粘贴到搜索框或对话框、拿到一个可能的修复、试一下、不行再换一个。这个流程的问题在于每次都是从零开始同一个报错下次遇到还要再走一遍。我统计过我遇到的报错里有相当一部分是重复的——同一个库的同一个坑隔几周又踩一次。所以我把报错处理也做成了工作流核心目标是让每次排查都留下可复用的产物。4.2 报错工作流的四个环节环节一完整采集现场。不要只复制最后一行报错。把完整的堆栈、触发操作、环境信息语言版本、依赖版本、操作系统一起收集。我习惯用一个固定模板记录操作我做了什么 报错完整堆栈 环境版本信息 已尝试我试过什么结果如何环节二让 AI 先解释再修复。关键顺序不能反。先让 AI 解释这个报错在说什么、通常由什么引起再让它给修复方案。如果直接要修复AI 容易给一个“碰巧能跑”的补丁你学不到东西。先解释后修复你下次能自己判断。环节三验证修复并记录根因。修复跑通后让 AI 用一句话总结根因格式固定为“因为 X导致 Y表现为 Z”。这句话就是这次排查的沉淀产物。环节四归档。我把这些根因总结按技术栈分类存进一个本地文件下次遇到类似报错先搜这个文件。半年下来攒了几十条命中率相当高。4.3 为什么“先解释后修复”这么重要因为报错信息本身往往指向的是症状不是病因。比如“空指针异常”症状是某个变量为空病因可能是上游数据没校验、可能是初始化顺序错了、可能是并发竞争。如果直接要修复AI 会针对症状打补丁先要解释AI 会帮你把可能的病因列出来你再结合现场判断。我踩过这个坑一个并发问题AI 直接给我加了个判空跑通了。结果上线后偶发数据不一致回头查才发现根因是初始化顺序判空只是掩盖了症状。从那以后我坚持先解释后修复。4.4 归档文件的组织方式我的归档文件按“技术栈 / 报错关键词 / 根因一句话 / 修复要点”四列组织用纯文本存方便搜索。举两个真实条目的样子Python /KeyError/ 因为配置字典用了.get()但默认值类型不对导致后续运算报错 / 检查默认值类型数据库 / 连接超时 / 因为连接池大小小于并发数导致请求排队超时 / 调大池子或加超时重试这个文件不需要多精致关键是每次排查完花三十秒记一条。积累的价值远超单次排查。5. 三个工作流怎么串起来用5.1 一条完整的日常开发链路单独看这三个工作流各管一段。串起来用就是一条完整的日常链路接到需求走工作流一三段式生成初版代码。自己跑通后走工作流二按清单审查一遍改掉必须改的问题。提交前如果遇到报错走工作流三解释、修复、归档。归档的根因总结反过来又能补充工作流二的审查清单——比如某个坑踩了两次就把它加进清单。这条链路跑顺之后我发现自己花在“重复劳动”上的时间明显下降花在“真正需要判断”的事情上的时间变多了。这才是用 AI 编程的正确姿势——不是让 AI 替你思考而是让 AI 替你干那些不需要思考的活。5.2 工具选择上的取舍这三个工作流不绑定任何特定工具。我试过几种组合组合方式适合场景我的实际体验网页对话 本地编辑器需求澄清、审查、报错解释灵活上下文好控制适合前两个工作流编辑器内 AI 插件逐函数实现、快速补全省去复制粘贴适合工作流一第三段命令行工具批量任务、脚本化适合把归档、清单检查做成自动化我的日常是混合用澄清和审查用网页对话上下文长、方便来回改实现用编辑器插件不用切窗口归档用命令行脚本自动按格式追加。工具是次要的环节拆解才是核心。5.3 一个容易被忽略的点上下文长度工作流一和二的很多环节需要把代码、清单、历史对话一起给 AI这对上下文长度有要求。我的经验是每个环节的上下文尽量控制在“刚好够用”。给太多无关代码AI 反而会抓错重点。比如审查时我只给要审查的那个文件不给整个项目澄清时只给需求原话不给现有代码库。如果确实需要跨文件理解我会先让 AI 读一遍相关文件让它自己总结出“这个模块对外暴露了什么”然后后续环节只带这份总结不带原始文件。这样上下文占用小信息密度高。6. 把工作流变成肌肉记忆的两个练习6.1 练习一强制走完三段式一周如果你平时习惯直接要代码建议强制自己走一周的三段式。具体做法每次要代码前先花两分钟做需求澄清再花一分钟定接口最后才实现。一开始会觉得麻烦但一周后你会发现改代码的时间明显缩短。我当初就是这么逼自己的。前三天特别不适应总想跳过澄清直接要代码。坚持到第五天我发现自己已经能预判 AI 会在哪里出问题澄清阶段问的问题越来越准。这就是肌肉记忆的形成过程。6.2 练习二给每个报错写一句根因第二个练习更简单每次解决报错后用“因为 X导致 Y表现为 Z”的格式写一句话存进归档文件。不用管写得好不好关键是写。写满二十条之后你会发现自己对报错的敏感度明显提升很多问题看一眼堆栈就能猜到方向。这两个练习的共同点是把隐性的经验显性化。工作流本身只是骨架真正让它产生价值的是你在每个环节里积累的判断力。骨架可以照抄判断力只能靠练。6.3 关于“复用”的一点个人体会标题里说“能立刻复用”我想补充一句立刻复用指的是骨架可以立刻用但每个工作流里的具体问法、清单条目、归档格式都需要你根据自己的技术栈和习惯调整。我给的这三套是我调过的版本你拿去用的时候第一周先照搬第二周开始按自己的痛点改。改着改着它就变成你自己的了。我见过太多人收藏了一堆工作流模板从来不用因为那些模板是别人的不是自己的。工作流这东西用起来比看起来重要得多。挑一个今天就能用上的先跑起来比什么都强。