AI编程工作流实战：三段式起稿、遗留代码改造与批量生成

1. 为什么“能立刻复用”比“功能强大”更重要

我见过太多人收藏了几百个AI编程工具，从代码补全到全自动Agent，硬盘里塞满了各种配置文件，结果日常写代码时还是一个Tab一个Tab地敲。问题不在于工具不好，而在于那些工作流要么配置太复杂，要么跟自己的实际开发习惯拧着来，用两次就放弃了。

“能立刻复用”这四个字，才是AI编程工作流真正的门槛。一个工作流如果不能在五分钟内跑通、不能在你现有的项目结构里直接落地、不能在你最常写的代码类型上稳定输出，那它再先进也跟你没关系。我自己的标准很简单：打开编辑器到产出第一段可用代码，不超过三分钟；一周内至少自然触发五次以上；不需要额外维护一套独立的配置体系。

这篇文章要聊的三个工作流，都是我在实际项目里反复打磨过的。它们分别覆盖了日常开发中最消耗时间的三个场景：新功能快速起稿、遗留代码理解与改造、重复性代码批量生成。每个工作流都基于通用的AI编程能力，不绑定特定平台，你用什么编辑器、什么模型都能跑。适合已经有一定编程基础、想用AI真正提升效率而不是玩票的开发者。如果你还在纠结“AI写的代码能不能用”，那这三个工作流会让你重新理解“人机协作”的边界在哪里。

2. 工作流一：从需求描述到可运行代码的“三段式起稿法”

2.1 为什么直接让AI写完整功能总是翻车

大部分人用AI编程的第一步，就是把需求一股脑丢给AI：“帮我写一个用户登录功能，要支持邮箱验证码和密码登录，还要有记住我功能。”然后AI吐出来两百行代码，你复制到项目里，发现import路径不对、数据库连接方式不匹配、错误处理逻辑跟现有代码风格完全两回事。改起来比自己写还累。

这个问题的根源在于：AI没有你的项目上下文。它不知道你用的是哪个ORM、错误处理是抛异常还是返回Result对象、日志用的是winston还是pino。你给的信息越笼统，AI的“自由发挥”空间就越大，跟你的项目就越不兼容。

我试过很多次之后，总结出一个“三段式起稿法”，核心思路是把一次大生成拆成三次小生成，每次只让AI做一件事，并且每次都给足上下文。实测下来，第一段代码的可用率从不到30%提升到了80%以上。

2.2 第一段：让AI先写“接口契约”而不是实现

第一步不是让AI写代码，而是让它写接口定义。具体操作是：把你现有的项目结构、相关模块的代码片段、以及你要实现的功能描述一起发给AI，让它只输出函数签名、类型定义和注释，不要写具体实现。

举个例子，你要在现有的Express项目里加一个用户注册接口。你可以这样构造提示词：

我有一个Express + TypeScript项目，现有路由文件结构如下： - src/routes/user.ts 中已有 getUser、updateUser 两个接口 - 错误处理统一使用 AppError 类，通过 next(new AppError(...)) 传递 - 数据库操作使用 Prisma，User 模型已有 email、passwordHash、createdAt 字段 现在需要新增一个用户注册接口 POST /api/users/register。 请只输出： 1. 路由处理函数的签名和类型定义 2. 请求体和响应体的 TypeScript 接口 3. 每个步骤的中文注释（不需要具体代码） 不要输出任何实现代码。

这一步的价值在于：你可以在不写一行实现的情况下，检查AI是否理解了你的项目结构。如果它输出的类型定义里用了你项目里不存在的字段，或者错误处理方式跟你的AppError不匹配，你立刻就能发现，调整提示词重新生成。这个过程通常只需要一两轮，比改两百行实现代码快得多。

2.3 第二段：基于契约填充实现，限定“只写这一个函数”

拿到满意的接口契约后，第二步是让AI基于这个契约写实现。关键操作是：把上一步的输出作为输入的一部分，并且明确限定“只写这一个函数的实现”。

提示词可以这样构造：

基于以下接口定义，实现 registerUser 函数的具体逻辑： [粘贴上一步生成的接口定义] 约束条件： - 使用 Prisma 的 user.create 方法 - 密码哈希使用项目已有的 hashPassword 工具函数（从 src/utils/crypto 导入） - 邮箱重复时抛出 AppError，状态码 409 - 验证码校验暂时留空，用 TODO 注释标记 - 不要修改任何其他文件，只输出这一个函数的完整代码

这一步的产出通常可以直接粘贴到项目里运行。因为AI已经知道了你的类型定义、你的工具函数位置、你的错误处理方式，它写出来的代码跟你的项目是“咬合”的。我统计过，用这种方式生成的代码，首次运行通过率在70%左右，剩下的30%通常只是小的语法调整或import路径修正。

2.4 第三段：让AI自己写测试用例并验证边界

代码能跑不等于代码正确。第三步是让AI为刚才生成的函数写测试用例，并且故意让它覆盖边界情况。这一步很多人会跳过，但恰恰是AI编程最能体现价值的地方——AI写测试用例的速度比人快得多，而且它不会“不好意思”去测那些奇怪的输入。

提示词示例：

为上面的 registerUser 函数写 Jest 测试用例，要求覆盖： 1. 正常注册流程 2. 邮箱已存在的情况 3. 密码强度不足的情况（假设密码要求至少8位含大小写） 4. 请求体缺少必填字段的情况 5. 数据库连接失败的情况（mock Prisma 抛出异常） 每个用例都要有清晰的 describe 和 it 描述。

生成测试用例后，你运行一遍，如果发现有用例失败，把失败信息贴回给AI让它修复。这个“生成-运行-修复”的循环通常两三轮就能收敛。最终你得到的是一个有测试覆盖的、跟项目风格一致的、可以直接提交的代码模块。

注意：三段式起稿法的核心是“每次只做一件事”。不要试图在一个提示词里让AI既写接口又写实现又写测试，那样只会得到一堆需要大改的代码。把AI当成一个需要明确指令的初级开发者，而不是一个能读心的高级架构师。

2.5 实操心得：怎么让AI“记住”你的项目风格

三段式起稿法有一个前提：你得让AI知道你的项目长什么样。我的做法是维护一个项目上下文文件，放在项目根目录下，命名为AI_CONTEXT.md。这个文件里记录了：

• 项目使用的技术栈和版本
• 目录结构说明
• 错误处理规范
• 日志规范
• 数据库操作规范
• 常用的工具函数列表

每次跟AI对话时，把这个文件的内容贴在提示词最前面。这样AI就不需要你反复解释“我们项目用AppError”“我们日志用pino”这些基础信息。这个文件不需要写得很正式，就是给自己看的备忘录，但有了它，AI生成代码的准确率会有质的提升。

3. 工作流二：遗留代码的“逆向理解与安全改造”

3.1 接手老项目时，AI能帮你做什么

每个开发者都会遇到这种情况：接手一个三年前的项目，原作者已经离职，代码里没有任何注释，变量名全是a、b、c、temp1、temp2，业务逻辑绕来绕去。你想改一个bug，但看不懂这段代码到底在干什么。

传统做法是硬着头皮读，一行一行加console.log，花两三天才能理清一个模块。用AI辅助的话，这个过程可以压缩到几个小时。核心思路是：让AI帮你做“代码翻译”和“影响面分析”，而不是让它直接改代码。

3.2 第一步：让AI把“天书代码”翻译成自然语言

拿到一段看不懂的代码，不要直接问“这段代码有什么问题”。先让AI做纯粹的翻译工作：

请逐行解释以下代码的业务逻辑，用自然语言描述每个步骤在做什么。 不要评价代码质量，不要提出改进建议，只做翻译。 [粘贴代码]

AI会输出一段类似“首先从数据库查询用户记录，然后判断用户状态是否为active，如果不是则抛出异常，如果是则继续检查用户的订阅是否过期……”的描述。这个过程能帮你快速建立对代码的整体认知。

但要注意：AI可能会“脑补”一些代码里没有的逻辑。所以翻译完之后，你要对照代码快速扫一遍，确认AI的描述跟代码实际行为一致。如果发现AI理解错了，把错误的地方指出来，让它重新翻译那一段。

3.3 第二步：用“影响面分析”确定改动边界

理解代码之后，下一步是确定“我要改的这个功能，会影响哪些地方”。传统做法是全局搜索函数名，但很多时候函数名太通用（比如process、handle），搜出来几百个结果根本看不过来。

AI的做法是：让它根据调用关系画出依赖图。你可以这样问：

以下是一个模块的代码。请分析： 1. 这个模块导出了哪些函数和变量 2. 这些导出项分别被哪些其他模块引用（根据import语句推断） 3. 如果我要修改 processData 函数的返回值类型，哪些地方会受到影响 [粘贴模块代码和相关的import语句]

AI会输出一个依赖关系列表。虽然它不能像IDE那样精确分析整个项目，但基于你提供的代码片段，它能给出一个合理的推断。这个推断可以帮你快速定位到需要重点检查的文件，而不是盲目全局搜索。

3.4 第三步：小步改造，每步都让AI检查兼容性

遗留代码改造最怕的就是“改一处崩三处”。我的做法是把大改造拆成一系列小改动，每次只改一个函数或一个逻辑分支，改完立刻让AI检查兼容性。

具体操作流程：

1. 选中要修改的函数，让AI生成修改后的版本
2. 把修改前后的代码一起发给AI，问：“这个修改是否改变了函数的输入输出契约？是否可能影响调用方？”
3. AI会分析参数类型、返回值、副作用（比如是否修改了全局变量、是否抛出了新的异常类型）
4. 根据AI的分析，决定是否需要同步修改调用方

这个流程看起来繁琐，但比“改完跑测试发现一堆报错再回头查”要高效得多。我实测过一个两千行的遗留模块，用这种方式改造，整体耗时比传统方式少了大约40%，而且引入新bug的概率明显降低。

3.5 避坑指南：AI改造遗留代码的三个禁忌

禁忌一：不要让AI一次性重写整个模块。哪怕AI说“我可以帮你重构”，也不要答应。遗留代码里往往藏着很多“看起来没用但删了就会出问题”的逻辑，一次性重写等于把所有隐藏依赖都暴露出来，风险极高。

禁忌二：不要相信AI对“未使用代码”的判断。AI可能会说“这个函数没有被调用，可以删除”。但JavaScript的动态特性意味着函数可能通过字符串拼接、反射、或者配置文件被调用。删除之前一定要全局搜索函数名的字符串形式。

禁忌三：不要跳过测试。遗留代码通常没有测试，但改造之前至少要手动跑一遍核心流程，记录下当前的输出结果。改造之后再跑一遍，对比输出是否一致。这个“黄金输出”对比法是最可靠的回退保障。

4. 工作流三：重复性代码的“模板+变量”批量生成

4.1 哪些代码适合批量生成

日常开发中有大量“结构相同、只是字段不同”的代码。比如：

• 为十个数据模型分别写CRUD接口
• 为二十个API端点分别写前端请求函数
• 为一组枚举值分别写类型守卫和转换函数
• 为多个表单分别写验证规则

这些代码手写起来枯燥且容易出错，但直接让AI“帮我写十个CRUD”又往往因为上下文太长导致质量下降。我的解决方案是**“模板+变量”法**：先让AI生成一个高质量的模板，然后你自己替换变量批量生成。

4.2 第一步：用“最复杂的一个”生成模板

不要随便挑一个模型让AI写模板。挑字段最多、关系最复杂、校验规则最繁琐的那个。因为复杂模型生成的模板会包含更多的边界处理逻辑，简单模型只需要删减即可，反过来则要补很多东西。

提示词示例：

我有一个Prisma模型如下： model Order { id String @id @default(cuid()) userId String items OrderItem[] totalAmount Decimal status OrderStatus createdAt DateTime @default(now()) updatedAt DateTime @updatedAt } enum OrderStatus { PENDING PAID SHIPPED COMPLETED CANCELLED } 请为这个模型生成一套完整的CRUD接口代码，包括： 1. 路由定义（Express Router） 2. 控制器函数（create、read、update、delete、list） 3. 每个函数的参数校验逻辑 4. 错误处理 要求代码风格与以下现有代码一致： [粘贴一段现有代码作为风格参考]

AI生成的这套代码就是你的“黄金模板”。检查一遍，确保它符合你的项目规范，然后把它保存下来。

4.3 第二步：提取变量，制作生成脚本

模板有了，接下来是提取“变量”。以上面的Order模型为例，变量包括：

• 模型名称：Order
• 路由路径：/api/orders
• 字段列表：id、userId、items、totalAmount、status、createdAt、updatedAt
• 枚举类型：OrderStatus
• 关联关系：items关联OrderItem

然后写一个简单的脚本（Python或Node都行），用字符串替换的方式批量生成。比如：

template = open('order_crud_template.ts').read() models = [ {'name': 'Product', 'route': 'products', 'fields': ['id', 'name', 'price', 'stock']}, {'name': 'Category', 'route': 'categories', 'fields': ['id', 'name', 'parentId']}, # ... 更多模型 ] for model in models: output = template.replace('Order', model['name']) output = output.replace('/api/orders', f"/api/{model['route']}") # ... 其他替换 open(f"{model['name'].lower()}_crud.ts", 'w').write(output)

这个脚本本身也可以让AI帮你写。你只需要把模板和变量列表发给AI，让它生成替换脚本。

4.4 第三步：批量生成后的“抽样验证”策略

批量生成五十个文件之后，不要一个一个打开检查。用抽样验证：随机挑三个文件，分别做三件事：

1. 语法检查：用TypeScript编译器或ESLint跑一遍，看有没有语法错误
2. 逻辑检查：手动读一遍，确认字段替换正确、路由路径正确
3. 运行检查：启动服务，用curl或Postman调一下接口，确认能正常响应

如果抽样三个都通过，那批量生成的质量基本可信。如果有一个失败，把失败信息发给AI，让它分析是模板的问题还是替换脚本的问题，修复后重新生成。

提示：批量生成最适合的场景是“项目初期搭建骨架”。一旦项目进入迭代期，手写代码的灵活性和可维护性反而更高。不要为了用AI而用AI，批量生成只适合那些“结构高度一致、未来改动频率低”的代码。

4.5 进阶技巧：用AI生成“代码生成器”而不是“代码”

如果你经常需要批量生成某类代码，比如每个月都有新的数据模型要加CRUD，那更高效的做法是让AI帮你写一个代码生成器。这个生成器读取你的Prisma schema文件，自动为每个模型生成CRUD代码。

提示词可以这样构造：

我有一个Prisma schema文件，里面定义了多个模型。 请写一个Node.js脚本，要求： 1. 解析schema文件，提取每个模型的名称、字段、枚举 2. 为每个模型生成一套CRUD路由和控制器代码 3. 生成的代码风格参考以下模板：[粘贴模板] 4. 输出到 src/generated/ 目录下 使用 @prisma/internals 的 getDMMF 方法来解析schema。

这个生成器写一次，以后每次加模型只需要跑一遍脚本。这才是“能立刻复用”的终极形态——把重复劳动变成一次性的工具建设。

5. 三个工作流的组合使用与常见问题排查

5.1 什么时候用哪个工作流：一张决策表

这张表是我自己总结的，不一定适用于所有人，但可以作为一个起点。核心原则是：越复杂的任务，越要拆成小步骤；越紧急的任务，越要让AI解释它做了什么。

5.2 常见问题速查：AI编程工作流中的十个坑

问题一：AI生成的代码import路径总是错的。原因：AI不知道你的项目目录结构。解决：在提示词里明确写出“工具函数在src/utils/，类型定义在src/types/，数据库客户端在src/lib/prisma.ts”。

问题二：AI写的代码风格跟项目不一致。原因：没有给风格参考。解决：每次提示词里粘贴一段现有代码作为风格示例，并明确说“保持相同的命名习惯和错误处理方式”。

问题三：AI生成的测试用例跑不起来。原因：测试框架配置不匹配。解决：把jest.config或vitest.config的内容也发给AI，让它知道你的测试环境。

问题四：AI改了一处代码，导致其他文件报错。原因：没有做影响面分析。解决：改之前先让AI分析“这个函数的调用方有哪些”，改完之后让AI检查“调用方是否需要同步修改”。

问题五：AI生成的代码有安全漏洞。原因：AI默认不会考虑SQL注入、XSS等安全问题。解决：在提示词里明确要求“使用参数化查询”“对用户输入进行转义”“不要拼接SQL字符串”。

问题六：AI不理解业务术语。原因：AI没有你的领域知识。解决：在项目上下文文件里加一个“术语表”，解释你项目里的专有名词。

问题七：AI生成的代码太长，超出上下文限制。原因：一次性要求太多。解决：拆成多个小任务，每次只生成一个函数或一个文件。

问题八：AI反复生成同样的错误代码。原因：提示词里有歧义，或者AI陷入了某种模式。解决：换一种表达方式重新描述需求，或者把错误信息贴回去让它针对性修复。

问题九：AI生成的代码能跑但性能很差。原因：AI优先考虑正确性而非性能。解决：在提示词里加一句“注意时间复杂度，避免在循环里查数据库”。

问题十：不知道AI改了什么，不敢提交。原因：没有做diff对比。解决：每次AI生成代码后，用git diff查看改动，确认每一处修改都是你想要的。

5.3 我个人的“AI编程检查清单”

每次AI生成代码后，我会快速过一遍这个清单：

• [ ] import路径是否正确
• [ ] 错误处理是否跟项目一致
• [ ] 是否有硬编码的敏感信息（密钥、密码）
• [ ] 数据库查询是否有N+1问题
• [ ] 是否有未处理的Promise rejection
• [ ] 类型定义是否完整（TypeScript项目）
• [ ] 是否有console.log残留
• [ ] 函数命名是否符合项目规范

这个清单花不了两分钟，但能拦住大部分低级问题。时间长了之后，你会形成条件反射，扫一眼就知道哪里可能有问题。

5.4 关于“AI编程提示词”的一点个人体会

网上有很多“万能提示词模板”，我试过不少，大部分效果一般。真正好用的提示词往往是很具体的，具体到你的项目、你的代码风格、你的业务逻辑。通用模板只能帮你写出“能跑的代码”，但写不出“能提交的代码”。

我的建议是：花一个小时，认真写一份自己的项目上下文文件。把技术栈、目录结构、代码规范、常用工具函数都写进去。以后每次跟AI对话，把这个文件贴在前面。这一个小时的投资，会在接下来几个月里持续回报你。

另外，不要迷信“一次生成完美代码”。AI编程的本质是迭代：生成、检查、反馈、再生成。接受这个循环，把它变成你的工作习惯，效率自然就上来了。我见过太多人因为第一次生成结果不理想就放弃AI编程，挺可惜的。其实只要多给一轮反馈，结果就会好很多。

5.5 后续可以怎么扩展这三个工作流

这三个工作流目前主要覆盖了“写代码”这个环节。如果你已经用顺了，可以往两个方向扩展：

方向一：往上游走，接入需求分析。把产品需求文档丢给AI，让它先输出技术方案和接口设计，然后再进入三段式起稿法。这样从需求到代码的链路就完整了。

方向二：往下游走，接入代码审查。代码写完之后，让AI扮演审查者角色，检查潜在bug、性能问题、安全漏洞。我试过让AI审查自己写的代码，它确实能发现一些我忽略的问题，尤其是边界条件处理。

这两个方向我都在实践中，等跑顺了再单独写一篇。目前这三个工作流已经能覆盖我日常80%的编码场景，剩下的20%是调试和架构设计，那些更需要人的判断，AI暂时还替代不了。