AI编程工作流实战：从提示词到代码生成、调试与测试的完整落地

最近后台私信里频率最高的一个问题，就是“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. 工作流 A：AI 结对编程与代码生成

这个工作流的定位是“在已经清楚要做什么的前提下，把代码写得更快更稳”。我不建议用它做完全模糊的需求探索，那是另一个话题。这里只讲从明确需求到产出代码。

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. 工作流 B：AI 驱动的调试与 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. 工作流 C：AI 驱动的测试生成与文档整理

第三个工作流解决的是开发链路中最容易被拖到“以后再说”的部分——单元测试和文档。这块很适合交给 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 常见问题速查表

5.5 一个额外的习惯：给每次关键输出留下版本记录

我还会额外把每个工作流的有效 prompt 和关键输出重点保存下来。哪怕只是文本文件，也能在下次遇到类似任务时快速复用，不需要再从记忆里恢复当时是怎么写的。几个月下来，这个积累库比任何现成的提示词集合都顺手，因为它是完全根据你自己项目的风格和市场环境调试出来的。做这个积累不需要什么复杂工具，一个 GitHub 私有仓库或者本地目录就够了，命中率奇高。

三个工作流目前已经跑通了开发全链路的一段，它们还在不断迭代。我现在的习惯是每跑完一个任务，就把服务模板中不好使的地方改一次，真正把 AI 用成日常工具而不是偶尔的实验。最后想留一句给大家：工作流的意义是稳定下限，而不是拔高上限；它能保证你每次用 AI 都达到一个不差的结果，但真正把上限顶上去的，永远是你和项目经理的判断力以及你的业务理解。希望这份实践记录能给你的 AI 编程工作流打个样。