1. 为什么“工作流”比“提示词”更值得花时间很多人接触 AI 编程的第一反应是去搜集各种“神级提示词”收藏夹里躺着几百条真到写代码的时候还是一条条复制粘贴、手动改参数、来回切换窗口。我自己也经历过这个阶段后来发现真正把效率拉开差距的不是某一条提示词写得多花哨而是把重复动作串成一条可复用的工作流。这里说的 AI 编程工作流指的是把“输入信息 → AI 处理 → 结果落地”这一整条链路固定下来让它在下次遇到同类任务时能直接跑而不是每次从零开始对话。它和单次提示词的本质区别在于提示词解决的是“这一次怎么问”工作流解决的是“这一类事情以后怎么自动做”。前者是技巧后者是资产。我目前稳定在用的有三条工作流分别覆盖代码生成与审查、遗留代码理解与改造、文档与测试同步产出。它们不需要多复杂的平台用常见的对话式 AI 加一点脚本粘合就能跑起来关键是把每个环节的输入输出格式定死。下面我会把这三条拆开讲清楚包括它们各自解决什么问题、为什么这样设计、具体怎么落地以及我在实际跑的过程中踩过的坑。提示工作流的价值不在于“全自动”而在于“半自动但稳定”。追求完全无人值守往往会因为边界情况频繁翻车反而更费时间。2. 工作流一需求到代码的“三段式生成法”2.1 这条工作流到底解决什么问题日常开发里最高频的场景是拿到一个需求描述需要产出可运行的代码。直接让 AI “帮我写一个 XXX”结果往往是一坨能跑但结构混乱、命名随意、边界没处理的代码。问题不在于模型能力而在于一次性把“理解需求、设计结构、编写实现”三件事压给了一次对话模型没有足够的“思考空间”。三段式生成法的核心思路是把一次生成拆成三次每次只让 AI 专注一件事第一次只做需求拆解和接口设计第二次只写核心逻辑第三次只做边界处理和代码审查。这样每一段的输出质量都会明显高于一次性生成。2.2 三个阶段的输入输出约定我把每个阶段的输入输出格式固定成下面这样这样每次只需要替换需求内容其余部分直接复用阶段输入输出要求目的第一段拆解原始需求 技术栈约束功能点列表 函数签名 数据结构定义锁定接口避免后面反复改第二段实现第一段的输出每个函数的完整实现不含测试专注逻辑正确性第三段加固第二段的输出边界处理 异常分支 审查意见提升健壮性第一段我通常会加一句约束“只输出接口和数据结构不要写任何函数体”。这句话很关键因为模型有强烈的“把话说完整”的倾向不明确禁止就会顺手把实现也写了导致后面两段失去意义。第二段我会把第一段的输出原样贴回去然后要求“严格按照上面的签名实现不要新增或修改任何函数名”。实测下来如果不加这句模型经常会自作主张改接口导致第三段对不上。第三段的提示词里我会明确列出要检查的几类问题空输入、超长输入、类型不匹配、并发访问、资源释放。这五类是我在项目里最常出问题的地方让 AI 专门针对它们过一遍比泛泛地说“检查一下边界”有效得多。2.3 一个真实跑通的例子假设需求是“写一个函数从一段文本里提取所有邮箱地址并去重”。第一段输出大概是这样# 函数签名 def extract_emails(text: str) - list[str]: 从文本中提取所有邮箱地址去重后按首次出现顺序返回 ... # 数据结构 # 输入: str # 输出: list[str]第二段拿到这个签名后实现核心逻辑用正则匹配加有序去重。第三段则专门处理text 为 None 怎么办、text 为空字符串怎么办、超长文本比如几十 MB会不会导致正则回溯爆炸、邮箱格式的边界比如带加号、带子域名要不要覆盖。这套流程跑下来产出的代码质量比我直接一次性生成要高一个档次而且因为接口在第一段就锁死了后面替换实现或者换语言都很方便。我甚至用同一套第一段输出让 AI 分别生成了 Python 和 Go 两个版本接口完全一致。2.4 踩过的坑与调整最开始我图省事把三段合并成一段让 AI “先设计再实现再检查”。结果模型会把大量篇幅花在设计上实现部分草草了事检查部分更是敷衍。拆成三段后每段的输出长度和质量都上来了。另一个坑是第二段和第三段之间没有明确的分隔。有几次我把第二段的输出直接接上第三段的指令模型误以为还在实现阶段继续写新函数。后来我在两段之间加了一行明显的分隔标记比如--- 以下进入审查阶段 ---问题就解决了。还有一个经验第一段的输出最好人工扫一眼再往下走。因为如果接口设计本身有问题后面两段都是在错误的基础上加工返工成本更高。这一步花三十秒能省后面十分钟。3. 工作流二遗留代码的“分层理解法”3.1 面对一坨陌生代码时的正确姿势接手别人写的模块或者回头看自己半年前写的代码最痛苦的不是改而是看不懂。直接问 AI “这段代码是干嘛的”得到的回答往往是逐行翻译没有重点看完还是不知道整体在做什么。分层理解法的思路是从粗到细分三层提问每一层只关注一个粒度第一层看模块职责第二层看函数调用关系第三层看关键实现细节。这样既能快速建立整体认知又能在需要深入时精准定位。3.2 三层提问的具体话术第一层我会把整个文件或模块贴进去然后问“用不超过十句话概括这个模块的职责以及它对外暴露了哪些能力。”限制句数很重要不限制的话模型会写一大篇反而抓不住重点。第二层我会针对第一层里提到的关键函数单独问“这个函数被哪些地方调用它又调用了哪些函数画出调用关系。”这里要注意模型有时候会编造调用关系所以我会让它“只根据提供的代码回答不确定的地方明确说不确定”。第三层针对真正要改的那个函数问“逐行解释这个函数的逻辑重点说明每个条件分支在什么情况下会走到。”这一层才需要细节前面两层都是为了快速缩小范围。3.3 为什么不能一次性问完我试过把三层合并成一次提问结果是模型把大量篇幅花在逐行解释上模块职责反而一笔带过。这其实符合模型的“注意力分配”规律你给的任务越具体它在该任务上的输出质量越高任务越笼统它越倾向于平均用力。分层之后还有一个额外好处第一层的输出可以作为“索引”保存下来。下次再需要理解这个模块直接看第一层的十句话概括就够了不用重新跑一遍。我现在的习惯是每理解一个新模块就把第一层的概括存到一个笔记文件里积累下来就是一份项目地图。3.4 处理超长代码的实用技巧有些模块动辄几千行一次性贴给 AI 会超出上下文限制。我的处理方式是按函数边界切分而不是按行数切分。因为函数是天然的语义单元按行切会把一个函数劈成两半模型理解起来会断片。具体做法是先用工具把代码按顶层函数拆成多个片段每个片段单独跑第一层理解最后再让 AI 把所有片段的概括合并成一份模块级说明。这个合并步骤也很有价值因为模型在合并时会自动发现片段之间的关联有时候能指出“这两个函数其实在做同一件事”这类人工容易忽略的问题。注意切分时一定要保留函数之间的引用信息比如把被调用函数的签名一起带上否则模型无法判断调用关系。4. 工作流三代码变更后的“文档测试同步产出”4.1 为什么文档和测试总是滞后代码改完文档和测试往往被放到“下次再说”结果就是文档永远对不上代码测试覆盖率永远上不去。根本原因不是懒而是写文档和写测试是额外的认知负担需要重新理解一遍刚写完的代码。这条工作流的核心是在代码变更的同一个上下文里顺手把文档和测试一起产出。因为此时你对代码的理解最清晰AI 也还“记得”刚才的变更内容产出成本最低。4.2 变更说明、文档、测试三件套每次完成一个功能或修复一个 bug我会在同一个对话里连续做三件事第一件让 AI 根据变更内容写一段变更说明格式固定为“改了什么、为什么改、影响范围”。这段说明直接可以贴进提交信息或发布日志。第二件让 AI 更新对应的文档段落。我会把旧文档一起贴进去要求“只修改受影响的部分其余保持原样”。这样避免模型重写整篇文档导致风格不一致。第三件让 AI 针对变更生成测试用例。这里有个技巧要求它“先列出需要覆盖的场景再写测试代码”。先列场景能逼它想清楚边界而不是随手写几个 happy path 就交差。4.3 让测试真正有用的两个约束第一个约束是要求测试能失败。我会让 AI 说明“如果把这个变更回滚哪些测试会失败”。如果它说不出哪些测试会失败说明这些测试没有真正覆盖变更点只是凑数。第二个约束是要求测试独立可运行。模型生成的测试经常依赖外部状态比如数据库连接、网络请求。我会明确要求“所有外部依赖都要 mock测试必须能在没有网络的情况下跑通”。这一条能过滤掉大量看似能跑、实际一换环境就挂的测试。4.4 这套流程的实际收益坚持跑了几个月之后最明显的变化是提交信息质量上来了。以前提交信息就是“fix bug”现在至少能说清楚改了什么、为什么改。其次是回归测试的覆盖以前改完代码心里没底现在至少知道哪些场景有测试兜着。还有一个意外收获因为每次都要让 AI 说明影响范围我养成了主动思考“这个改动会不会影响别的模块”的习惯。有几次就是在这个环节发现原本以为只影响一个函数的改动实际上会波及三个调用方提前避免了线上问题。5. 三条工作流的共同底层逻辑5.1 把“一次性大任务”拆成“多次小任务”这三条工作流看起来场景不同但底层逻辑是一样的把一次性的复杂任务拆成多次的简单任务。三段式生成是把“写代码”拆成设计、实现、加固分层理解是把“读懂代码”拆成职责、关系、细节同步产出是把“改代码”拆成变更、文档、测试。这个逻辑之所以有效是因为模型在单一任务上的表现明显好于在复合任务上的表现。你让它同时做三件事它会在三件事之间平均分配注意力每件都做到七十分你让它一次只做一件事它能把这件事做到九十分。5.2 固定输入输出格式让流程可复用每条工作流我都定义了固定的输入输出格式这是它能“复用”的前提。如果每次的提问方式都不一样那就不是工作流只是随机对话。固定格式之后我甚至可以把常用的提示词存成模板下次直接填空。格式固定还有一个好处可以逐步优化。比如三段式生成法里的第三段我一开始只让它检查边界后来发现资源释放也经常出问题就把这一项加进了检查清单。每次踩坑就往清单里加一条工作流会越用越顺手。5.3 人工介入点的选择这三条工作流都不是全自动的每个环节之间都有人工确认。有人可能觉得这样不够“智能”但我的经验是人工介入点选得好整体效率反而更高。因为 AI 的输出有不确定性如果不在关键节点确认错误会一路传递下去最后返工的成本远高于中途检查。我的介入点选择原则是在“方向性决策”处介入在“执行性细节”处放手。比如三段式生成法里第一段的接口设计我会看一眼因为这是方向性的第二段的具体实现我基本不看直接进第三段第三段的审查意见我会扫一遍挑出真正重要的改。6. 落地时最容易翻车的几个地方6.1 上下文污染同一个对话里连续做太多不相关的事模型会被前面的内容干扰。我遇到过最典型的情况是在一个对话里先让它写了一个 Python 函数然后让它解释一段 JavaScript 代码结果它在解释 JS 的时候用了一堆 Python 的术语。解决办法是按任务开新对话不要在一个对话里混着做不同的事。如果确实需要保留上下文比如三段式生成法那就确保这三段是强相关的不要中间插别的内容。6.2 过度信任模型的“自信”模型在不确定的时候也会用很肯定的语气回答尤其是在解释代码调用关系的时候。我踩过好几次坑模型信誓旦旦地说某个函数被 A 调用结果一查发现是 B。后来我养成了一个习惯凡是涉及具体调用关系、具体行号的回答都要人工核对一遍。概括性的回答可以信精确性的回答要验证。6.3 提示词越写越长刚开始优化工作流的时候我倾向于把提示词写得越来越长把所有能想到的约束都加进去。结果发现提示词太长之后模型反而抓不住重点重要的约束被淹没在细节里。后来我的做法是把约束分层核心约束放在最前面用最简短的话说清楚次要约束放在后面用列表形式列出。比如三段式生成法的第一段核心约束就一句“只输出接口不写实现”其余的都是次要的。6.4 忘了保存中间产物工作流跑出来的中间产物比如第一段的接口设计、第一层的模块概括都是有价值的资产。我一开始跑完就关掉下次遇到类似任务又从头来。后来开始有意识地保存这些中间产物积累下来发现复用率很高。现在我的做法是每条工作流跑完把中间产物按“日期 任务类型”存到一个固定目录。下次遇到同类任务先翻一翻有没有可复用的有就直接拿来改没有再从零跑。7. 怎么把这套东西变成自己的这三条工作流不是标准答案只是我自己跑通的一套方案。你完全可以根据自己的技术栈和任务类型调整里面的环节和格式。关键是抓住那个底层逻辑拆任务、定格式、留介入点、存产物。我建议的起步方式是先挑一条最贴近你日常工作的跑上一周把每次的输入输出都记下来。一周之后回头看你会发现哪些环节是多余的、哪些约束是缺失的然后针对性地调整。调整两三轮之后这条工作流就基本成型了。另外提醒一句不要一上来就追求三条全上。工作流的价值在于稳定复用同时跑三条容易顾此失彼最后哪条都没跑顺。先把一条跑成肌肉记忆再考虑加第二条。我在实际使用中最大的体会是AI 编程的效率提升八成来自流程设计两成来自模型能力。同样的模型用工作流跑和随手问产出质量能差出一倍。所以与其花时间追新模型不如先把手上这条工作流打磨顺。