最近后台私信里频率最高的一个问题就是“AI 编程到底怎么落地”。大家普遍的感觉是让大模型写个简单函数挺快的但一放到真实项目里就变味了——要么上下文太长要么生成的代码风格和项目完全对不上要么改三遍还带着同一个 bug。我自己在公司内部项目和几个开源项目里折腾了三个多月最大的体会是问题不在于 AI 本身而在于使用方式。单次提问是点状行为攒不出积累效应真正能持续产生价值的是把 AI 嵌进一条固定的可复用链路里形成一套 AI 编程工作流。今天就把我沉淀下来的三个工作流完整拆开分别对应“写代码、调 bug、补测试和文档”这三个最高频的开发场景。每一个都是我刚验证过、能直接抄走的版本适合同步在开发一线、想拿 AI 提效但已经受够了“一次性提示词”的同事和同行。1. 设计思路先想清楚工作流要解决什么三个工作流不是随手拼出来的是我在复盘“哪些环节浪费了我最多时间”之后按投入产出比挑出来的。先说痛点再讲方案你才知道每一步为什么要这么设计。1.1 单点提问的最大问题每次都在重新造轮子给 AI 提一个“帮我写个函数”这种请求本质上是把上下文、约束、验收标准全部写在聊天窗口里交付质量完全取决于你当前这个 prompt 写得有多完整。换个任务之前对话里沉淀的东西基本作废下一轮又是从零开始。大量重复劳动浪费在“交代背景”上而不是浪费在“思考方案”上。工作流解决的就是这个浪费。它把“需求澄清、上下文准备、约束传入、结果验收”这几个环节固化下来让每类任务有固定的执行路径。一开始搭工作流确实要花点时间但同一类任务跑第二次、第三次的时候你会发现边际成本被摊得很薄。这也是我复用的核心逻辑先沉淀流程再谈生成质量。1.2 三个工作流的整体分工我给它们定义了三个非常清晰的边界尽量避免场景重叠工作流 A代码生成与结对编程。解决“知道要做什么但写起来慢”的问题覆盖新功能开发、接口实现、重构改写。工作流 B调试与问题排查。解决“代码报错或逻辑不对但肉眼查不出来”的问题覆盖运行时异常、数据不一致、回归测试失败。工作流 C测试生成与文档整理。解决“代码能跑但测试覆盖率和文档质量拖后腿”的问题覆盖单测补写、用例扩展、接口文档同步。前两个工作流可以在一次开发任务里串联使用先用工作流 A 生成代码跑起来出了问题再把现场信息喂给工作流 B。第三个工作流更像是开发收尾阶段的一次性投入。这样设计还有一个隐藏的好处每个工作流的提示词模板是固定的你可以把它存成自己的 skill、snippet 或者团队文档什么时候用都不慌。1.3 前置条件与适用场景要说清楚这些工作流依赖稳定的多轮对话能力所以建议选用支持长上下文和代码文件读取的主流 AI 助手比如 Claude Code、GitHub Copilot、Cursor 或者类似的国产工具。我用过一段时间 Cursor 和 Claude Code后面所有模板都是在这类工具上验证过的。如果你平时只在浏览器网页版里手动贴代码也能用但效率会打折。适用人群上我觉得中高级开发者是收益最大的。因为工作流里面有大量“验证 AI 输出”的环节你水平越强越能快速判断哪些代码是幻觉、哪些方案行不通。初级开发者更需要的反而是先把基础功打牢不能指望靠 AI 跳过调试能力。这个心态摆正了下面三个工作流才拧得动。2. 工作流 AAI 结对编程与代码生成这个工作流的定位是“在已经清楚要做什么的前提下把代码写得更快更稳”。我不建议用它做完全模糊的需求探索那是另一个话题。这里只讲从明确需求到产出代码。2.1 固定模板把该交代的全部交代掉我踩过最大的坑就是上来只说一句“帮我写一个配置文件合并脚本”然后拿到一坨能跑但完全没有错误处理的代码。后来我把提示词模板固定成五个部分任务、背景、约束、输出格式、验收标准。每次写任务都按这个结构来代码质量明显稳定了一个档次。下面这个模板是我最常用的可以复制直接改【任务】写一个 Python 脚本合并多个 JSON 配置文件后面的文件覆盖前面的同名 key。 【背景】项目在 Python 3.9 环境运行配置文件里存在嵌套对象需要递归合并 已有工具类 config_loader.load(path)可以直接复用。 【约束】合并后的结果保持键的顺序稳定需要处理文件不存在或 JSON 解析失败的情况 禁止修改原始文件不引入第三方依赖只用标准库。 【输出格式】先给出主函数代码再给出 100 字以内的使用说明。 【验收】合并行为符合“后来者覆盖”“递归深合并” 异常路径不崩溃而是打印明确的错误信息并跳过坏文件 代码通过一个我提供的单元测试样例。为什么要写这么长因为 AI 模型的注意力分布受 prompt 结构影响很大。“任务”和“约束”分开写能避免模型为了满足“写代码”这个动作丢掉“错误处理”这类隐性要求。它不知道你的项目里有没有现成的 loader所以必须在“背景”里主动告诉它。“验收”则是给模型一个停止条件它知道这个任务怎么样才算干完就不会自己给自己加戏。2.2 家庭作业第一步从“生成”变成“改补查”如果任务稍微复杂一点比如改动现有代码里的一个模块我会在模板后面追加一个步骤不加在主生成提示词里而是让 AI 先输出一个“改动影响面”清单。先不要写代码。告诉我这个模块目前有哪些依赖文件改完后文件之间的调用关系是什么 影响面分析完再给出具体修改方案。这个“先分析再动手”的节奏非常关键。有一次我需要在一个订单状态机里增加一种“取消后重新激活”的状态。如果直接让 AI 改它很可能只在 switch 分支里加一个 case但漏掉了持久化层、消息通知层和日志埋点这些关联点。先让 AI 列影响面再逐一确认相当于让它在动手前先做了一次代码走查。拿到确认后的方案我会继续用同一个会话让它分步实施按你上面确认的影响面分三步改代码。第一步先改状态机定义 第二步改持久化层第三步改消息处理。 每改完一步就停下来等我放行再继续下一步。这种方式有两个好处。一是避免单次生成一大坨代码后肉眼 review 不过来二是每步之间我可以插入新的上下文比如“我发现持久化层那个映射表还有个字段忘了提”不用推倒重来。2.3 结伴工作中的关键动作坚持人工复核即使有了模板和分步机制我也不会直接合入 AI 生成的代码。人工复核这一步绝对不能省因为模型在具体任务上仍然会产生两种典型问题。第一种是“幻觉接口”AI 会擅自使用一个跟需求相近但不存在的库函数。比如在处理嵌套 JSON 时它可能编一个deep_merge_dict的标准库函数名实际上 Python 标准库里根本没这个函数。第二种是“过度泛化”它会把一个简单任务变成半框架式的设计生成一堆你根本用不上的抽象层。这些问题不是靠更好的提示词就能 100% 消除的只能靠人工在 merge 前去读代码、去跑测试。我个人的复核习惯是先看改了哪些文件再重点检查 AI 生成代码里的错误处理分支和边界条件最后跑一遍全量单测。这三步走完生成的东西才敢往主干上合。说到底AI 编程工作流的最终验收人是开发者自己AI 只是把“写代码”这个体力活加速了判断力还是得留在自己手里。3. 工作流 BAI 驱动的调试与 Bug 排查这个工作流是我认为最有价值的。因为调试环节吃经验而 AI 恰恰可以做模式匹配把曾经要摸索半小时的排查过程压缩到几分钟。它解决的核心问题不是“修代码”而是“定位根因”。3.1 正确的提问姿势从“帮我修”变成“帮我分析”很多人遇到报错的第一反应是直接把整个堆栈贴给 AI然后问一句“帮我修复”。你会得到一个看似合理的修复但很多时候是治标不治本的重试或绕路代码。我尝试过几次之后把提问姿势调整成了下面这套流程。第一步喂给 AI 的信息按“症状、现场、假设、期望”四段来组织【症状】脚本运行到一半抛 IndexError说 list index out of range。 【现场】Python 版本 3.9文件是 config_loader.py完整堆栈如下 粘贴堆栈 原始配置文件 15 行左右。 【假设】我怀疑是最后一个文件里缺少某个字段导致索引错位。 【期望】帮我定位在哪个位置抛出的异常根因是数据问题还是代码问题 先讲结论和证据不要直接给修复代码。注意最后一句“先讲结论和证据不要直接给修复代码”。这很重要。先让 AI 做根因分析你不至于被一个没头没尾的补丁带偏思路。等它给出结论你认可了再让它顺着结论写修复补丁。这样 AI 的修复是有依据的而不是根据报错猜测的。第二步让 AI 帮你缩小排查范围。如果问题不是崩溃型而是“输出结果不对”我的做法是把正常情况下的输入输出、以及异常情况下的输出同时贴上去然后要求它做二分定位。同一份输入数据昨天跑结果正常今天改了一行配置就少了一个 key。 帮我比对这两份输出和输入指出差异最可疑的位置。 不需要写修复代码先给我一条可以验证的假设。AI 做这种差异化对比非常快尤其当数据量大时它比人眼盯着控制台输出高效得多。我至少有两三次是拿这种对比法找到时间格式和时区转换 bug 的——数据在表面上看都一样差的是某个字段的时区偏移让人肉眼核对几乎不可能。3.2 我的调试工作流全流程记录拿一个真实场景举例批量检查 IP 白名单的脚本原来跑得好好的加了几个新 IP 之后突然少处理了一条记录。我的实际排查流程如下。我先见 log 文件注意到发现漏掉的那条记录刚好是最后一个 IP。这种“最后一个元素消失”的模式十有八九是遍历时长中有两个入口同时迁移了同样的数据或者切片大小差一。把相关代码段和输入数据贴给 AI同时标注“最后一条记录没处理结果少了固定数量就等于遍历边界问题”。AI 用前一条假设直接给出结论代码里有个while i len(ips) - 1的缩进问题加 IP 之前这个条件只是巧合覆盖了唯一一条旧记录加了之后边界就露出来了。它甚至给出了一个单行修复但我没有立刻合入而是让它补了一个带边界数据的测试用例先跑通测试再说。整个流程从发现问题到修复完成用了不到二十分钟。如果没有 AI可能得在 IDE 里打断点、来回检查循环逻辑估计接近一小时。这不是说 AI 更聪明而是它能把“在已知代码里找差异”的时间压缩到极小而人可以把精力集中在“这个修复会不会引入新问题”这种判断性工作上。3.3 用断言和复现脚本建立调试闭环这套流程能跑通的前提是你有一个稳定可复现的环境。所以我强烈建议但凡喂给 AI 的 bug都要附带一个最小复现脚本而不是直接贴一堆生产日志。最小复现脚本说白了就是能把问题稳定触发出来的几行代码或者一个独立函数。我之前处理过一个并发写入的 bug生产上偶发死锁。直接贴生产日志出来的话AI 根本没法做随机性的分析。后来我写了一个几十行的故障复现脚本循环模拟并发写入把复现率压到了 100%。拿到稳定复现之后AI 才能精准地指出是对一个共享连接没加锁导致的。这再一次说明AI 调 bug 的能力上限取决于你给它的“现场”质量。你给的现场越干净AI 给的根因越准。4. 工作流 CAI 驱动的测试生成与文档整理第三个工作流解决的是开发链路中最容易被拖到“以后再说”的部分——单元测试和文档。这块很适合交给 AI因为它的产出可以结构化校验而且不依赖临时创造力。4.1 从接口文档梳理到测试用例生成给一个接口补测试我常用的方法是让 AI 先读接口定义然后输出一张测试用例清单。清单只列出场景和期望结果不写实现。等清单确认之后再让它生成具体代码。下面是模块 function.py 里 generate_report(start, end, fmt) 的函数签名和两段历史代码。 基于这个函数帮我列一份 pytest 用例清单覆盖 正常区间、跨年区间、开始时间晚于结束时间、fmt 参数非法、缺参、超大日期区间。 每个用例写清楚输入、期望行为、是否期望抛异常。 先把这份清单输出给我我确认后再写完整测试代码。这个流程的核心好处是提前把“测什么”和“怎么测”分开。如果让 AI 直接从零生成测试代码它可能只写三个 happy path 用例而先让 AI 列场景清单它的覆盖面会更广泛而且你能在写法上反馈“这个场景我们项目里不需要”之类的要求等清单对准了再写代码出来的测试和项目口味就对齐了。实操中我会让 AI 把测试代码写成参数化的而不是一个函数一个场景。这样对代码覆盖率更友好而且如果需求变化直接往参数列表里加一组值就行。比如上面那个报告生成函数参数化之后非法 fmt 那组参数就能独立跑一个用例不用复制粘贴。4.2 让 AI 保持文档和代码同步续文档这块我主要让 AI 做两件事生成 docstring 和更新 README 的使用示例。跟自动写代码的套路类似提示词里要明确“只允许改注释不许动逻辑代码”否则模型很容易顺手重构。针对当前文件的所有公开函数生成符合 pep257 格式的 Docstring。 要求第一行说明函数用途第二行开始写参数、返回值、异常 示例代码保持简单。 不许改动任何业务逻辑代码只添加注释。用完这个设置在几个文件上试得到的 docstring 质量很均衡没有出现“这个函数是做什么的”这种废话。至于 README我一般会把变更后的函数签名和一条使用示例一起丢给 AI让它重写对应的 README 片段再人工检查真例即可。4.3 允许“参考式”生成用 review 保证质量很多人担心 AI 生成的测试测试测试出来的都是“为了通过而通过”的无效用例。这个担心是对的。所以我给这个工作流加了一个硬性规则AI 生成的每个测试用例必须验证一个明确的业务行为而不只是“断言函数不报错”。比如“断言函数不报错”和“断言函数返回的数据里包含了 expected_report_id”这两件事前者只能说明没有异常后者才能真正防回归。我通常在生成测试的提示词结尾加上这么一句测试用例必须断言具体的返回值或副作用不允许只断言“不抛异常”。模型对这句约束的执行度很高因为这是显式输出约束。加了这句话之后生成的测试基本能从“能跑”升级到“有点用”。当然认真地 review 测试代码还是少不了只是从“谁都不愿意写”变成了“边角修改更快”。5. 常见问题与避坑实录这几个坑我必须说出来上面三个工作流是正面路线实际操作时还会有很多边角问题下面挑几个最常见、最容易误导人的用一段一段讲清楚。5.1 AI 自发补全不存在的依赖这个坑我前文提过但值得单独再讲。有一次让 AI 生成一个处理 Markdown 文件的工作流脚本它给我用了一个md2pdf的库名我顺手一搜发现那个库版本早就停止维护而且在项目环境里根本装不上。后来我在模板的“约束”里增加一条固定的话所有依赖必须先确认存在且版本兼容未经确认不得使用第三方库。这句约束写进去后AI 生成代码时明显更慎重了遇到需要依赖的会主动询问而不是擅自假设。5.2 长上下文导致“注意力漂移”超过一两个文件的项目里AI 很容易在后面的步骤里忘掉前面提到的关键约束。比如前面说了不要改某个接口签名后面生成的代码却还是把它改了。这种“注意力漂移”不是模型变笨了而是往上下文里塞了太多内容。应对方法是在关键约束上加重复强调句或者在每个分步任务的开头补一句简短的约束回顾。我自己用的笨办法就是增加一步“确认”比如“开始之前先重复一遍你记住的关键约束我再继续”。这招又简单又有效。5.3 越改越歪环境重构战役的时刻该停手还有一类常见场景是你发现代码风格不好于是让 AI“顺手重构几十行”结果模型连着把周边没要求改的代码也调整了产生一堆非预期的 diff。我现在的做法是如果改动范围超过一个文件起码别在一个会话里同时要求“重构”和“新增功能”两件事拆成两个工作流跑。新增功能时用工作流 A 的一般模板重构时另开一个会话专门只讲重构目标和风格规范。这样摘开之后冲突明显减少review 成本也低多了。5.4 常见问题速查表现象根因分析解决办法生成代码依赖无效库模型基于训练数据猜测接口约束里禁止未确认依赖生成后检查 imports多次修改后行为不对上下文太长约束被遗忘分步任务前让 AI 复述关键约束重构顺带修改了无关代码模型默认扩大改动范围将重构和新增功能拆成不同会话测试用例全是 happy path缺少场景列表设计环节先让 AI 输出用例清单确认再写代码报错修了但根因没动提问方式偏向“修复”而非“分析”先用“先分析后动手”模板定位根因文档和代码声明不一致单次生成提示词没限制改动范围提示词中明确“只允许改动注释和文档”5.5 一个额外的习惯给每次关键输出留下版本记录我还会额外把每个工作流的有效 prompt 和关键输出重点保存下来。哪怕只是文本文件也能在下次遇到类似任务时快速复用不需要再从记忆里恢复当时是怎么写的。几个月下来这个积累库比任何现成的提示词集合都顺手因为它是完全根据你自己项目的风格和市场环境调试出来的。做这个积累不需要什么复杂工具一个 GitHub 私有仓库或者本地目录就够了命中率奇高。三个工作流目前已经跑通了开发全链路的一段它们还在不断迭代。我现在的习惯是每跑完一个任务就把服务模板中不好使的地方改一次真正把 AI 用成日常工具而不是偶尔的实验。最后想留一句给大家工作流的意义是稳定下限而不是拔高上限它能保证你每次用 AI 都达到一个不差的结果但真正把上限顶上去的永远是你和项目经理的判断力以及你的业务理解。希望这份实践记录能给你的 AI 编程工作流打个样。