1. 别再跟 AI“要代码”了先盘点随手提问为什么会翻车前阵子团队里一个同事很沮丧地跟我抱怨他让 AI 写了三段业务代码结果没有一段能直接用改 bug 花的时间比自己手写还要久。我让他把当时的对话记录贴出来他发来一句话——“帮我写一个用户注册接口”。就这一句没了。我当时就笑了。这不叫用 AI 写代码这叫抽奖。这不是人的问题也不是模型能力的问题而是流程的问题。一个正常的软件开发流程在传统团队里本来就包含需求评审、技术方案、开发、测试、验收这么一长串环节。但到了 AI 辅助开发这里很多人把中间流程全部砍掉把一个大任务压在一句 prompt 上指望大模型自己在一个黑盒里完成整套瀑布式开发。翻车几乎是必然的。1.1 随口问的三个致命问题输入、上下文、验收全部缺失我把随手提问翻车的案例拆开来看问题基本集中在三个方面。第一需求输入端是模糊的。“帮我写一个用户注册接口”这句话放到真实业务里至少缺了这些信息用什么语言和框架接口是 REST 还是 GraphQL用户名注册还是手机号注册要不要验证码密码是明文存储还是哈希加密有没有防重复提交要不要做登录态接口返回格式是什么日志和埋点要不要并发量多高这些信息一个都不给AI 只能靠猜。猜对了是你的运气猜错了就是同事遇到的那种“拆盲盒式开发”。第二上下文是缺失的。AI 写出一个接口很容易但它不知道你这个项目里的公共返回结构长什么样不知道你们团队习惯用哪种分层方式不知道数据库连接池怎么配的不知道错误码体系怎么定义的。它产出的代码是“在真空里正确”的代码拿到你的项目里就会跟现有代码的风格、规范、基建体系格格不入。第三验收标准是缺失的。随手提问的人往往只关注“代码生成出来没有”而不是“这段代码能不能通过测试、能不能应对异常输入、能不能在真实环境里运行”。没有验收标准AI 给出的代码你就只能全凭感觉接收。而代码这个东西看着像对的和真的对的中间隔着十万八千里。1.2 一个真实翻车案例三小时改了个寂寞具体说说我同事那个案例挺有代表性。他让 AI 写注册接口AI 确实很丝滑地给了一段 Spring Boot 代码带 Controller、Service、Mapper看起来有模有样。但从贴到项目里的那一刻开始就状况不断项目用的是 MyBatis-PlusAI 给的是 JdbcTemplate 写法团队要求所有接口返回统一封装ResultTAI 直接返回了裸对象密码存储要求用 BCryptAI 用的是 MD5 加盐接口要求做幂等校验AI 完全没做最离谱的是AI 把手机号正则写错了导致 13 和 19 开头的号段直接被拒。这五处问题每一处单看都不算大但合在一起就意味着这段代码从架构风格到安全规范全部不达标。同事花了三个小时逐条跟 AI 解释“我们的项目是这样的你需要改这个”改完一轮又发现新问题最后干脆自己重写了。这不是 AI 不聪明是他把 AI 当成了“许愿机”用一句模糊的话换回了一段需要海量背景知识才能落地的代码。1.3 随手问和流水线的成本对照我后来做了一张简单的对照表每次想“算了直接问一句得了”的时候就拿出来看看对比维度随口问流水线方式投入时间5 秒提问3 小时改错15 分钟澄清需求30 分钟拆解任务代码可用率大约三成能用其余靠猜九成以上一次通过剩余靠评审修订返工成本高且不可预期低每个阶段有明确的检查点知识沉淀无对话结束知识就丢了提示词模板、需求文档、验收清单全部沉淀可复用性每个需求从零开始流水线一键重跑换需求只换输入这张表说服了我自己与其跟 AI 拼“谁更能猜”不如把开发这件事本身变成一条可编排的流水线让每一道工序都有明确的输入、输出和验收标准。接下来我详细拆一下这条流水线到底怎么搭。2. 流水线的整体骨架需求从进到出经过哪五道工序我设计的这条流水线核心思路是把一个完整的软件开发流程“翻译”成 AI 可以逐步执行的工序。传统瀑布式开发有需求、设计、开发、测试、运维五个阶段我把它精简成五道可编排的工序每一道工序对应一个独立的提示词模板上游的输出就是下游的输入。2.1 五道工序和各自的输入输出工序一需求澄清。输入是用户一句原始描述比如“我要一个用户注册功能”输出是一份结构化的需求说明包含功能边界、角色权限、异常场景、非功能需求。工序二任务拆解。输入是需求说明输出是一组可独立验收的开发任务每个任务带验收标准。这一步模仿了敏捷开发里的用户故事拆分把一个模糊大目标拆成能一个一个验收的小单元。工序三方案设计与技术选型。输入是任务清单输出是技术方案包括接口设计、数据模型、目录结构、关键依赖、风险点。注意这一道工序只出文档不出代码目的是防止 AI 跳过设计直接瞎写。工序四代码生成与评审闭环。输入是技术方案和任务清单输出是通过评审的代码。这一步不是一次生成完事而是“生成—自检—修改—人工评审”的循环我会在后面的章节展开讲。工序五测试、文档与复盘。输入是评审通过的代码输出是测试用例、运行结果、使用文档和复盘结论。这一步保证了代码不是“看起来对了”而是“真的能跑且后面的人能接手”。2.2 为什么必须是这个顺序顺序这件事我一开始也没想通最早我也试过“让 AI 直接写写完再补文档”结果发现两个问题一是代码和文档经常对不上二是改代码的时候根本没有依据评审像在开盲盒。后来我想明白了一个逻辑AI 写代码的能力已经远远超过 AI 理解需求的能力。你让它写一个冒泡排序它闭着眼都能写对你让它写一个“根据用户等级和优惠券叠加规则计算最终价格”的功能它即使写出了代码你也很难判断它写对没有因为需求本身没有先被定义清楚。所以工序的顺序必须是从“消除模糊”开始的。需求不清后面全是空中楼阁设计不定代码生成就是无序碰撞。先让 AI 把需求掰碎了说清楚再让 AI 把方案写出来最后才轮得到代码。2.3 轻量版和重量版两套配置流水线跑了一段时间之后我发现不同场景需要的配置不一样所以现在维护了两个版本。轻量版是给个人开发者和中小需求用的五道工序可以压缩为三道需求澄清合并了需求和拆解、方案与代码合并了设计和生成、验证与复盘合并了测试和文档。整个流程靠几个提示词模板加一个脚本就能跑起来成本很低。重量版是给团队项目用的五道工序完整走而且每一步都要求 AI 输出结构化文档进入知识库代码评审要有专门的评审人和记录。重量版的好处是每个环节都能追溯坏处是慢一个简单需求可能要花一整天才走完全程。我的建议是先跑轻量版跑通感觉再逐步加重。不要一上来就上重量版否则你很快会因为流程太重而放弃整条流水线。3. 前置工序需求澄清与任务拆解把模糊想法变成可验收单元流水线的第一站也是整个流程里最关键的一站。我见过太多人在这里省时间结果省出了后面所有的时间。需求澄清这一关本质上做的是“翻译”工作把用户脑子里的模糊想法翻译成 AI 和程序员都能看懂的、无歧义的规格说明。3.1 需求澄清的提示词模板让 AI 反过来提问最早我尝试自己写一份很长的提示词把需求背景、功能点、边界条件全部描述清楚再扔给 AI。但很快我发现一个问题如果需求本身就不清楚你写再长的提示词也是在“把不清不楚的东西说得更详细”。后来我换了个思路——先不让 AI 写代码而是让 AI 反过来做需求分析师向我提问。我用的需求澄清提示词大概是这样的你是一名资深业务分析师。下面是我对一个功能的原始描述 【原始描述】 我想给系统加一个用户注册功能支持手机号注册完成注册后可以登录。 请你先不要写任何代码。你的任务是 1. 针对这个需求列出至少 10 个你觉得必须澄清的问题按照“功能逻辑、边界条件、异常处理、非功能要求”四类分组 2. 对每个问题给出你默认的处理方案并标注“这是假设需要用户确认” 3. 最后输出一份需求确认清单包含功能目标、用户角色、典型流程、异常场景、验收要点。这个模板跑出来效果很好。AI 会问诸如“手机号是否需要校验真实存在性”“验证码是短信验证码还是图形验证码”“注册成功后是否自动登录”“密码强度要求是什么”“是否需要处理手机号已注册的情况”“接口限流和风控是否需要”等问题。这些问题我甚至不用全部回答因为很多默认方案是可以直接采纳的我只需要逐条确认。这一步的耗时大约 10 到 20 分钟但它解决的是整个开发过程中最贵的成本——方向错误。3.2 把确认后的需求转成验收标准需求确认完下一步是把需求转成可验收的标准。这一步我强烈建议输出“Given-When-Then”格式的验收用例这是从 BDD行为驱动开发里借来的招数。举个我实际跑过的例子场景用户使用未注册的手机号完成注册 Given系统处于可注册状态用户输入手机号 13800138000 When用户提交注册表单输入正确验证码和密码 Then系统创建新用户返回成功消息同时生成登录态凭证 场景用户使用已注册的手机号重复注册 Given数据库中已存在手机号 13800138000 的用户 When用户再次提交同手机号的注册请求 Then系统返回“手机号已注册”的错误提示不创建新用户不覆盖原数据为什么一定要到这个颗粒度因为我实测发现AI 写代码时最大的问题不是语法而是对场景覆盖的理解。你告诉它“做注册功能”它能写你告诉它“注册成功返回什么、重复注册返回什么、手机号格式错误返回什么、服务端异常返回什么”它写出来的东西才有验收依据。验收标准本身就是给 AI 的“需求说明书”也是后面生成测试用例的基础。3.3 任务拆解一个需求拆成几个可以单独交差的单元需求澄清完之后我一般会把需求交给 AI 做一次任务拆解。提示词很简单请把下面的需求按“可独立开发、可独立验收”的标准拆解成开发任务。 每个任务必须包含 - 任务编号和名称 - 功能描述一句话 - 依赖的接口或模块 - 验收标准至少 3 条写成 Given-When-Then 格式 - 预估工时S/M/L 三档 不要拆分到“写一个工具函数”这种过细的粒度也不要拆成“整个功能全部完成”这种过粗的粒度。拆解的原则是“每个任务做完系统是一个稳定可运行的状态”。比如注册功能我会拆成“注册接口与手机号校验”“验证码生成与校验”“注册事务与异常处理”“注册接口单元测试”这几个任务而不是拆成“写 Controller”“写 Service”“写 Mapper”这种纯技术视角的拆法。因为按技术层拆你没法在中间任何一个节点验收按功能单元拆每完成一个任务系统都能跑、能测、能验收。4. 核心工序方案设计、代码生成与评审闭环有了需求说明、验收标准和任务清单就到了整条流水线的核心区。这一部分我在实践中迭代了好几版最后稳定下来的节奏是先出方案再生成代码最后走评审闭环。每一步都别省。4.1 先要方案后要代码为什么设计文档能挡住一半的坑很多人到这一步会着急觉得“需求都清楚了直接让 AI 写代码不就行了”。我理解这种心情但我要说一个我在实践中反复验证过的结论如果你直接让 AI 写代码它会把技术选型、数据结构、接口设计这些决定用“默认值”替你做了而这些默认值大概率不符合你的项目。比如同样是“记录用户登录日志”这个需求AI 默认会给你建一张login_log表字段是id, user_id, login_time。但你们项目里可能已经有了一套基于消息队列的日志系统或者你们要求登录日志必须包含 IP、设备指纹、登录结果。如果让 AI 直接写代码它不会问你它会直接建表——等你发现时表结构已经错了数据模型已经定了返工成本极高。所以我在工序三固定一个方案设计提示词请基于下面的任务清单和验收标准输出一份技术方案文档。 方案必须包含 1. 接口定义路径、方法、请求参数、响应结构遵循 ResultT 统一封装 2. 数据模型涉及的表结构、字段类型、索引设计、数据保留策略 3. 目录结构新增/修改的文件路径遵循现有分层规范 4. 关键依赖需要引入的库或中间件以及引入理由 5. 异常处理所有可能出现的异常分支及对应错误码 6. 风险点你识别出的实现风险或需要人工确认的问题。 注意方案文档中不要出现任何业务代码但可以在接口和数据模型部分使用定义式描述。这一步通常耗时 10 到 15 分钟但产出是一份可以拿去评审的文档。我自己的习惯是让 AI 出两版方案一版“标准实现”一版“简化实现”然后根据项目的实际情况选一个这样比只有一个方案的时候多了取舍空间。4.2 代码生成的上下文注入比提示词技巧重要得多方案定了之后代码生成这一关的关键反而不是提示词写得多花哨而是上下文给得够不够。AI 写代码跑偏十次里有八次是因为它不知道项目的既有约定。我实测下来最有效的做法是给 AI 喂一个“项目上下文包”包含以下内容项目的整体结构和分层规范Controller 层做什么、Service 层做什么、Mapper 层做什么统一返回结构ResultT的代码片段项目里已有的一个相似功能的完整代码当作风格参考异常和错误码的定义方式数据库访问层的约定用的是 MyBatis-Plus 还是 JPA日志打印规范。然后用这样的提示词把上下文和任务串起来以下是本项目的基本规范 【项目规范】 - Spring Boot 3.x MyBatis-PlusController 不写业务逻辑 - 所有接口返回 ResultT格式参考 { code: 0, message: success, data: {} } - 错误码使用 ErrorCode 枚举业务异常抛 BizException - 日志使用 Slf4j统一用 log.info/log.error禁止 System.out - 数据库表统一使用 snake_case 命名主键用 BIGINT 雪花 ID。 以下是需求上下文 【任务清单】 T1实现手机号注册接口包含手机号格式校验、验证码校验、密码 BCrypt 加密、事务处理。 【验收标准】 - 注册成功返回 Result 且 code0data 包含 userId - 手机号已注册返回 code11001message“手机号已注册” - 验证码错误返回 code11002 - 手机号格式非法返回 code11003不落库。 请严格遵循以上规范生成代码不要自己定义新的返回结构或异常体系。我特别强调最后一句“不要自己定义新的返回结构”因为 AI 最喜欢干的事就是你给它一个ResultT它转身自己又造了一个ApiResponse。它下意识觉得“统一结构的意思是不是让我设计一个统一结构”经常出现这种画蛇添足。4.3 评审闭环让 AI 自检 人工复审至少两轮代码生成之后不能直接进测试必须先走一轮评审。我的做法是两轮第一轮AI 自检。让 AI 以资深 Code Reviewer 的身份检查自己刚生成的代码提示词是请以资深代码评审员的身份检查下面这段代码。 检查维度 1. 是否满足验收标准中的每一个场景 2. 是否符合项目规范返回结构、异常、日志、命名 3. 是否存在并发/事务/空指针等隐患 4. 是否存在安全风险SQL 注入、越权、敏感信息泄露 5. 是否存在明显的性能问题。 对每个发现的问题按 P0必须修复/P1建议修复/P2可以忽略分级。这段自检非常有用。AI 的自我纠错能力虽然不算强但至少能把它的“自信满满”版本修成“勉强能用”版本能挡掉差不多一半的低级错误。我实测最常见的自检结果是它自己发现“验证码校验逻辑放在了事务内部会无谓地占用事务时间”“密码字段没有加 JsonIgnore 会泄露到响应里”这类问题。第二轮人工复审。这一步不能省AI 自检解决不了“业务理解是否正确”的问题。人工复审时重点不是一行行读代码而是带着验收标准过场景需求里的三个 Given-When-Then 场景代码里是不是都有对应的处理分支如果都有再扫一眼明显的风格问题和安全问题。整个复审我一般控制在 10 分钟以内因为前面需求、方案、验收都过过了代码本身的意外空间已经被压得很小。5. 后置工序测试验证、文档沉淀与复盘更新把代码评审通过只是“写完了”不等于“做完了”。我见过太多 AI 辅助开发的项目死在最后一公里代码看着没问题一跑就崩或者代码没问题但三个月后没人看得懂当时为什么这么写。所以流水线的第五道工序是让结果可验证、可继承。5.1 先写测试用例再跑实现测试是给 AI 的“紧箍咒”正常情况下测试应该在开发之后写。但我在流水线里把顺序反过来了在代码生成之前就要求 AI 先生成测试用例。这一招我从 TDD测试驱动开发里借来的实际操作下来效果奇好。理由很简单如果你先让 AI 写代码再写测试AI 写的测试极大概率是围着它自己的实现逻辑打转最终结果是“实现是对的测试也通过了但需求里的一个场景漏了”。而如果先根据验收标准生成测试用例测试就成了开发行为的一副“紧箍咒”——代码必须穿过测试这关才算数而不是自己给自己开卷考试。测试用例生成提示词请根据下面的验收标准生成单元测试和接口测试用例。 要求 1. 每个 Given-When-Then 场景至少对应一个用例 2. 覆盖异常路径参数非法、数据不存在、外部服务异常、并发冲突 3. 不依赖真实数据库使用 Mock 对象 4. 测试代码同样遵循项目规范。注意“不依赖真实数据库”这条。如果让 AI 生成依赖数据库的测试它往往会假设表已经存在、数据已经准备好最后测试没法直接跑。用 Mock 对象可以让测试在流水线里立刻执行不用先搭环境。5.2 运行、调试、再循环把“一次性生成”改成“迭代交付”在整条流水线的运行层面最颠覆我认知的一个转变是不要期待 AI 一次写对而是接受“生成—运行—报错—修复”的循环是常态。AI 生成的代码第一次能在不报错的情况下跑通的概率在我实际项目中大约六成。剩下四成会遇到编译错误、类型不匹配、依赖缺失、字段名写错这种问题。我把这个循环固定成了一个指令模板用来把报错信息交回给 AI下面是我运行你生成的代码后得到的报错信息和相关上下文。 请你 1. 分析报错的根因不要只给“表面修复” 2. 列出修改方案说明修改涉及的文件和原因 3. 直接输出修改后的完整代码不要只给片段 4. 修改后检查是否引入了新的问题。 【报错信息】 粘贴报错堆栈 【相关上下文】 粘贴关键文件或配置片段这个模板里最重要的一条是“不要只给表面修复”。比如编译报错说“找不到符号”AI 最常见的修复是删掉那行代码而不是去找为什么符号不存在。如果给它强调“分析根因”它能挖到“引用的实体类字段名和数据库列名不一致”“依赖包里根本没有这个类是引入坐标写错了”这类深层原因。5.3 文档沉淀让这次开发的经验成为下次的输入流水线和随手提问最本质的区别在于知识能不能积累。随口问的对话记录关掉窗口就消失了流水线每一步的产出都可以沉淀成可复用的资产。我在每条需求走完之后会让 AI 生成三份文档一份接口使用说明给前端或对接方看一份开发备忘记录这次实现的关键决策和坑点一份流水线复盘评估哪道工序最耗时、提示词哪里需要调整。这三份中文档会进入项目的知识库下次跑流水线时作为参考上下文注入相当于让 AI“记得”这个项目的历史。文档生成提示词我简化为这样请根据本次需求的需求说明、技术方案、代码和测试结果生成 1. 接口文档请求/响应示例、错误码表、调用注意事项 2. 开发备忘本次实现涉及的关键决策、踩过的坑、遗留问题 3. 复盘摘要哪个环节返工最多原因是什么。 要求语言简洁直接可用不要写“本次指南”之类的开场白。这个环节不要省。我后来反复体会到AI 辅助开发的项目最大的风险是“人看不懂AI 也忘了”最后代码变成一团既没人敢动、也没人能动的历史包袱。文档沉淀本质上是在对抗这种熵增。6. 编排落地的选型实践Agent 框架、编排平台与提示词模板管理前面讲的都是流程和提示词层面的设计但这条流水线真正“可复用、可编排”还需要一套承载它的工具和管线。这一章聊聊我实际用过的选型以及每种方案适用什么场景。6.1 编排能力需要满足哪三件事我把流水线对工具的要求归结为三件事第一工序可串行可分支。需求澄清完可能要人工确认确认完了才往下走方案设计完可能要对方案做人工审批。工具至少要能表达这种“人机协作”的流程而不是一股脑全自动跑完。第二上下文可传递。上游产出的需求说明、验收标准、技术方案要能自动传递到下游提示词里而不是每次重新粘贴。这一步直接决定整条流水线的效率。第三产物可沉淀。每一步的产出需求文档、方案、代码、测试报告要落库成为后续需求的参考上下文。6.2 我用过的四类编排方案对比方案代表工具优点缺点适合场景低代码编排平台Dify、Coze可视化编排、节点可复用、知识库集成方便重度业务代码落地受限灵活度一般团队协作、知识库流水线、非程序员也能改流程通用自动化编排n8n、Zapier节点丰富能串 API 和消息通知对代码生成这类“长文本任务”支持不够精细和团队 IM、工单系统联动做流程自动化代码级编排LangChain、LangGraph、自研脚本灵活度最高能精确控制每一步的输入输出和分支逻辑需要写代码维护入门成本高个人开发者、追求深度定制的场景IDE 内置 AgentCursor、Codex CLI、补全插件和编辑器深度集成修改代码体验顺滑流程编排能力弱适合单任务不适合整流程轻量版流水线单步任务执行我自己的主力组合是核心流水线用自研脚本做代码级编排团队知识库和文档沉淀用 Dify 搭一条知识库流水线日常单点开发直接用 IDE 内置 Agent。三套工具各管一段。自研脚本管“五道工序的严格顺序”Dify 管“文档入库和检索”IDE Agent 管“临时性的小改动”。6.3 提示词模板如何版本化管理前面说的所有提示词模板光有内容还不够还得管起来。我身边很多朋友把提示词直接放在一个备忘录里改一版没一版这不行。提示词模板就是流水线的源代码它需要版本管理。我的做法比较简单直接在项目仓库里建一个prompts/目录每个工序一个 Markdown 文件文件名带版本号比如01-requirement-clarify-v3.md。每次修改后用 git 提交提交信息写明改了什么、为什么改。跑流水线时脚本读取当前版本的模板填充上下文。还有一个非常重要的细节提示词模板不要写得“太满”。一开始我追求把每个细节都写进模板结果发现模板越长AI 越容易抓不住重点甚至会在不相关的约束上反复纠结。后来我把模板精简为角色定义一两句话、任务目标一两句话、输出格式列表式、验收要求优先级清单。剩下的细节全部作为变量注入而不写死在模板里。6.4 一个轻量版编排的完整示例为了让“编排”这件事不那么抽象我贴一个我在轻量版流水线里实际在用的简化脚本逻辑。它本质上是一个按顺序调用各工序提示词的流程控制每个工序都有结构化的输入输出。#!/bin/bash # 轻量版 AI 开发流水线 REQ_DESC$1 # 传入原始需求描述 TASK_ID$2 # 任务编号用于命名产物 # 工序一需求澄清 echo 工序 1/4需求澄清 requirement_text$(call_ai --role 业务分析师 \ --template prompts/01-requirement-clarify-v3.md \ --input $REQ_DESC) # 人工确认这个环节必须停下等人确认 echo $requirement_text artifacts/${TASK_ID}-requirement.md read -p 需求文档已生成确认无误后按回车继续需要修改请输入 n: confirm # 工序二任务拆解与方案设计 echo 工序 2/4任务拆解与技术方案 task_list$(call_ai --role 架构师 \ --template prompts/02-task-and-design-v2.md \ --input $requirement_text) echo $task_list artifacts/${TASK_ID}-design.md # 工序三代码生成按任务清单逐项生成 echo 工序 3/4代码生成 for task in $(parse_tasks $task_list); do generate_code --context artifacts/${TASK_ID}-design.md \ --task $task \ --output src/${TASK_ID}/${task}.java done # 工序四测试与文档 echo 工序 4/4测试用例与文档生成 generate_tests --based-on artifacts/${TASK_ID}-requirement.md generate_docs --from artifacts/${TASK_ID}-requirement.md这里的call_ai函数可以是对接任意模型 API 的封装重点是整个流程的输入输出是文件化的每一步的产物都被保存下来既方便人审核也方便后续作为上下文复用。我特别强调“工序一之后必须有人工确认”这一步不要省略。需求澄清的结果如果不经过人确认AI 自己确认自己的猜测那跟随手提问没有任何区别。7. 这条流水线跑了大半年的实测体会与踩坑记录最后这部分聊聊流水线跑了大半年之后我的真实体感和踩过的坑。这些经验如果没人说你可能要自己交几个月学费才能换到。7.1 我最常踩的五个坑坑一把流水线当成全自动工具。流水线解决的是“流程结构”的问题不是“完全不用人”的问题。我最早设计流水线时想着“人只需要输入需求剩下的 AI 全包”结果发现需求输入之后需求澄清阶段 AI 问出的问题一多半我根本答不上来得去问业务方。这时候我才意识到流水线把原本藏在开发过程中的模糊性提前暴露了这不是坏事但你必须预留人来处理这些模糊性的时间。坑二验收标准写得太泛。我最早写的验收标准是“注册功能正常可用”后来发现 AI 生成的测试用例也是“正常可用”级别的等于没有验收。改成 Given-When-Then 格式之后质量立刻上了一个台阶。这件事我强烈建议不要图省事。坑三一次性把全部代码交给 AI 生成。我试过在工序三里让 AI 一口气生成整个任务清单下所有任务的代码结果输出经常截断或者前面任务的代码和后面任务的设计不一致。后来改成“一个任务一次生成”每次生成一个独立的代码文件质量稳定得多。坑四忽略了“代码风格统一性”的校验。让 AI 生成多个文件的代码时它每次生成都会重新理解项目规范导致两个文件对同一个业务对象的命名可能不同一个用userId一个用uid。我在流水线里加了一道“风格一致性检查”工序后这类问题才基本消失。坑五复盘环节流于形式。我承认文案类的复盘摘要 AI 写得很好但它经常会把“我这次最大的问题是需求没问清楚”这种烂账重复三遍却没有提炼出具体的改进动作。后来我改成让 AI 输出“下一步要修改哪个提示词的哪一行”复盘才真正对流水线有反哺作用。7.2 实测数据效率和质量到底提升了多少我知道没数据大家不信我大概统计过这半年跑流水线的账。从时间上看一个中等复杂度的需求比如一个带权限控制的报表查询功能现在从接到需求到交付压缩到半天到一天。而同样的需求过去同事自己写的交付周期是两三天。省下来的时间主要花在需求澄清和方案设计上的那半小时因为这两步做扎实了后面几乎不返工。从质量上看代码评审中发现的 P0 级问题会导致线上事故或数据错误的问题数量明显下降。过去 AI 直接写的代码P0 问题大概每三次就出现一次流水线跑出来的代码P0 问题集中在需求环节的遗漏上代码层面的问题很少。这说明流水线没有把 AI 变成更好的程序员而是把它变成了一个更有纪律的执行者。7.3 什么样的人适合直接抄这条流水线最后说说适用范围。如果你属于以下任何一种情况我建议你直接照着我这套流程复制一版跑起来你是个人开发者经常用 AI 写代码但总觉得效果不稳定翻车率高于五成你的团队正在把 AI 引入日常开发但还没有一套统一的协作方式每个人都在用不同的姿势问 AI你维护的项目有一堆历史代码和项目规范每次交给 AI 时都要重复粘贴一堆上下文觉得特别繁琐。如果你觉得五道工序太重那就从轻量版的三道工序开始。我自己最想传达的一个体会是跟 AI 协作开发真正的杠杆不在模型选择也不在提示词技巧而在你愿不愿意把开发流程本身当成一个需要编排和管理的产品。流程理顺了AI 的能力才不会被损耗在无休止的猜测和返工里。还有一个小技巧我最后分享一下吧给流水线的每一步都设定一个最大迭代次数比如代码评审最多两轮超过两轮就让人直接接管。这个规则逼着你去重视前置工序因为你心里清楚后端不长眼睛的兜底在那里等着你。我加了这个限制之后需求澄清和方案设计的质量瞬间上去了因为你知道后面没有无限次重来的机会。 
长河君 · 2026/10/27 15:24:09 · 阅读 1.2k AI辅助开发流水线：从模糊提问到工程化落地
1. 别再跟 AI“要代码”了先盘点随手提问为什么会翻车前阵子团队里一个同事很沮丧地跟我抱怨他让 AI 写了三段业务代码结果没有一段能直接用改 bug 花的时间比自己手写还要久。我让他把当时的对话记录贴出来他发来一句话——“帮我写一个用户注册接口”。就这一句没了。我当时就笑了。这不叫用 AI 写代码这叫抽奖。这不是人的问题也不是模型能力的问题而是流程的问题。一个正常的软件开发流程在传统团队里本来就包含需求评审、技术方案、开发、测试、验收这么一长串环节。但到了 AI 辅助开发这里很多人把中间流程全部砍掉把一个大任务压在一句 prompt 上指望大模型自己在一个黑盒里完成整套瀑布式开发。翻车几乎是必然的。1.1 随口问的三个致命问题输入、上下文、验收全部缺失我把随手提问翻车的案例拆开来看问题基本集中在三个方面。第一需求输入端是模糊的。“帮我写一个用户注册接口”这句话放到真实业务里至少缺了这些信息用什么语言和框架接口是 REST 还是 GraphQL用户名注册还是手机号注册要不要验证码密码是明文存储还是哈希加密有没有防重复提交要不要做登录态接口返回格式是什么日志和埋点要不要并发量多高这些信息一个都不给AI 只能靠猜。猜对了是你的运气猜错了就是同事遇到的那种“拆盲盒式开发”。第二上下文是缺失的。AI 写出一个接口很容易但它不知道你这个项目里的公共返回结构长什么样不知道你们团队习惯用哪种分层方式不知道数据库连接池怎么配的不知道错误码体系怎么定义的。它产出的代码是“在真空里正确”的代码拿到你的项目里就会跟现有代码的风格、规范、基建体系格格不入。第三验收标准是缺失的。随手提问的人往往只关注“代码生成出来没有”而不是“这段代码能不能通过测试、能不能应对异常输入、能不能在真实环境里运行”。没有验收标准AI 给出的代码你就只能全凭感觉接收。而代码这个东西看着像对的和真的对的中间隔着十万八千里。1.2 一个真实翻车案例三小时改了个寂寞具体说说我同事那个案例挺有代表性。他让 AI 写注册接口AI 确实很丝滑地给了一段 Spring Boot 代码带 Controller、Service、Mapper看起来有模有样。但从贴到项目里的那一刻开始就状况不断项目用的是 MyBatis-PlusAI 给的是 JdbcTemplate 写法团队要求所有接口返回统一封装ResultTAI 直接返回了裸对象密码存储要求用 BCryptAI 用的是 MD5 加盐接口要求做幂等校验AI 完全没做最离谱的是AI 把手机号正则写错了导致 13 和 19 开头的号段直接被拒。这五处问题每一处单看都不算大但合在一起就意味着这段代码从架构风格到安全规范全部不达标。同事花了三个小时逐条跟 AI 解释“我们的项目是这样的你需要改这个”改完一轮又发现新问题最后干脆自己重写了。这不是 AI 不聪明是他把 AI 当成了“许愿机”用一句模糊的话换回了一段需要海量背景知识才能落地的代码。1.3 随手问和流水线的成本对照我后来做了一张简单的对照表每次想“算了直接问一句得了”的时候就拿出来看看对比维度随口问流水线方式投入时间5 秒提问3 小时改错15 分钟澄清需求30 分钟拆解任务代码可用率大约三成能用其余靠猜九成以上一次通过剩余靠评审修订返工成本高且不可预期低每个阶段有明确的检查点知识沉淀无对话结束知识就丢了提示词模板、需求文档、验收清单全部沉淀可复用性每个需求从零开始流水线一键重跑换需求只换输入这张表说服了我自己与其跟 AI 拼“谁更能猜”不如把开发这件事本身变成一条可编排的流水线让每一道工序都有明确的输入、输出和验收标准。接下来我详细拆一下这条流水线到底怎么搭。2. 流水线的整体骨架需求从进到出经过哪五道工序我设计的这条流水线核心思路是把一个完整的软件开发流程“翻译”成 AI 可以逐步执行的工序。传统瀑布式开发有需求、设计、开发、测试、运维五个阶段我把它精简成五道可编排的工序每一道工序对应一个独立的提示词模板上游的输出就是下游的输入。2.1 五道工序和各自的输入输出工序一需求澄清。输入是用户一句原始描述比如“我要一个用户注册功能”输出是一份结构化的需求说明包含功能边界、角色权限、异常场景、非功能需求。工序二任务拆解。输入是需求说明输出是一组可独立验收的开发任务每个任务带验收标准。这一步模仿了敏捷开发里的用户故事拆分把一个模糊大目标拆成能一个一个验收的小单元。工序三方案设计与技术选型。输入是任务清单输出是技术方案包括接口设计、数据模型、目录结构、关键依赖、风险点。注意这一道工序只出文档不出代码目的是防止 AI 跳过设计直接瞎写。工序四代码生成与评审闭环。输入是技术方案和任务清单输出是通过评审的代码。这一步不是一次生成完事而是“生成—自检—修改—人工评审”的循环我会在后面的章节展开讲。工序五测试、文档与复盘。输入是评审通过的代码输出是测试用例、运行结果、使用文档和复盘结论。这一步保证了代码不是“看起来对了”而是“真的能跑且后面的人能接手”。2.2 为什么必须是这个顺序顺序这件事我一开始也没想通最早我也试过“让 AI 直接写写完再补文档”结果发现两个问题一是代码和文档经常对不上二是改代码的时候根本没有依据评审像在开盲盒。后来我想明白了一个逻辑AI 写代码的能力已经远远超过 AI 理解需求的能力。你让它写一个冒泡排序它闭着眼都能写对你让它写一个“根据用户等级和优惠券叠加规则计算最终价格”的功能它即使写出了代码你也很难判断它写对没有因为需求本身没有先被定义清楚。所以工序的顺序必须是从“消除模糊”开始的。需求不清后面全是空中楼阁设计不定代码生成就是无序碰撞。先让 AI 把需求掰碎了说清楚再让 AI 把方案写出来最后才轮得到代码。2.3 轻量版和重量版两套配置流水线跑了一段时间之后我发现不同场景需要的配置不一样所以现在维护了两个版本。轻量版是给个人开发者和中小需求用的五道工序可以压缩为三道需求澄清合并了需求和拆解、方案与代码合并了设计和生成、验证与复盘合并了测试和文档。整个流程靠几个提示词模板加一个脚本就能跑起来成本很低。重量版是给团队项目用的五道工序完整走而且每一步都要求 AI 输出结构化文档进入知识库代码评审要有专门的评审人和记录。重量版的好处是每个环节都能追溯坏处是慢一个简单需求可能要花一整天才走完全程。我的建议是先跑轻量版跑通感觉再逐步加重。不要一上来就上重量版否则你很快会因为流程太重而放弃整条流水线。3. 前置工序需求澄清与任务拆解把模糊想法变成可验收单元流水线的第一站也是整个流程里最关键的一站。我见过太多人在这里省时间结果省出了后面所有的时间。需求澄清这一关本质上做的是“翻译”工作把用户脑子里的模糊想法翻译成 AI 和程序员都能看懂的、无歧义的规格说明。3.1 需求澄清的提示词模板让 AI 反过来提问最早我尝试自己写一份很长的提示词把需求背景、功能点、边界条件全部描述清楚再扔给 AI。但很快我发现一个问题如果需求本身就不清楚你写再长的提示词也是在“把不清不楚的东西说得更详细”。后来我换了个思路——先不让 AI 写代码而是让 AI 反过来做需求分析师向我提问。我用的需求澄清提示词大概是这样的你是一名资深业务分析师。下面是我对一个功能的原始描述 【原始描述】 我想给系统加一个用户注册功能支持手机号注册完成注册后可以登录。 请你先不要写任何代码。你的任务是 1. 针对这个需求列出至少 10 个你觉得必须澄清的问题按照“功能逻辑、边界条件、异常处理、非功能要求”四类分组 2. 对每个问题给出你默认的处理方案并标注“这是假设需要用户确认” 3. 最后输出一份需求确认清单包含功能目标、用户角色、典型流程、异常场景、验收要点。这个模板跑出来效果很好。AI 会问诸如“手机号是否需要校验真实存在性”“验证码是短信验证码还是图形验证码”“注册成功后是否自动登录”“密码强度要求是什么”“是否需要处理手机号已注册的情况”“接口限流和风控是否需要”等问题。这些问题我甚至不用全部回答因为很多默认方案是可以直接采纳的我只需要逐条确认。这一步的耗时大约 10 到 20 分钟但它解决的是整个开发过程中最贵的成本——方向错误。3.2 把确认后的需求转成验收标准需求确认完下一步是把需求转成可验收的标准。这一步我强烈建议输出“Given-When-Then”格式的验收用例这是从 BDD行为驱动开发里借来的招数。举个我实际跑过的例子场景用户使用未注册的手机号完成注册 Given系统处于可注册状态用户输入手机号 13800138000 When用户提交注册表单输入正确验证码和密码 Then系统创建新用户返回成功消息同时生成登录态凭证 场景用户使用已注册的手机号重复注册 Given数据库中已存在手机号 13800138000 的用户 When用户再次提交同手机号的注册请求 Then系统返回“手机号已注册”的错误提示不创建新用户不覆盖原数据为什么一定要到这个颗粒度因为我实测发现AI 写代码时最大的问题不是语法而是对场景覆盖的理解。你告诉它“做注册功能”它能写你告诉它“注册成功返回什么、重复注册返回什么、手机号格式错误返回什么、服务端异常返回什么”它写出来的东西才有验收依据。验收标准本身就是给 AI 的“需求说明书”也是后面生成测试用例的基础。3.3 任务拆解一个需求拆成几个可以单独交差的单元需求澄清完之后我一般会把需求交给 AI 做一次任务拆解。提示词很简单请把下面的需求按“可独立开发、可独立验收”的标准拆解成开发任务。 每个任务必须包含 - 任务编号和名称 - 功能描述一句话 - 依赖的接口或模块 - 验收标准至少 3 条写成 Given-When-Then 格式 - 预估工时S/M/L 三档 不要拆分到“写一个工具函数”这种过细的粒度也不要拆成“整个功能全部完成”这种过粗的粒度。拆解的原则是“每个任务做完系统是一个稳定可运行的状态”。比如注册功能我会拆成“注册接口与手机号校验”“验证码生成与校验”“注册事务与异常处理”“注册接口单元测试”这几个任务而不是拆成“写 Controller”“写 Service”“写 Mapper”这种纯技术视角的拆法。因为按技术层拆你没法在中间任何一个节点验收按功能单元拆每完成一个任务系统都能跑、能测、能验收。4. 核心工序方案设计、代码生成与评审闭环有了需求说明、验收标准和任务清单就到了整条流水线的核心区。这一部分我在实践中迭代了好几版最后稳定下来的节奏是先出方案再生成代码最后走评审闭环。每一步都别省。4.1 先要方案后要代码为什么设计文档能挡住一半的坑很多人到这一步会着急觉得“需求都清楚了直接让 AI 写代码不就行了”。我理解这种心情但我要说一个我在实践中反复验证过的结论如果你直接让 AI 写代码它会把技术选型、数据结构、接口设计这些决定用“默认值”替你做了而这些默认值大概率不符合你的项目。比如同样是“记录用户登录日志”这个需求AI 默认会给你建一张login_log表字段是id, user_id, login_time。但你们项目里可能已经有了一套基于消息队列的日志系统或者你们要求登录日志必须包含 IP、设备指纹、登录结果。如果让 AI 直接写代码它不会问你它会直接建表——等你发现时表结构已经错了数据模型已经定了返工成本极高。所以我在工序三固定一个方案设计提示词请基于下面的任务清单和验收标准输出一份技术方案文档。 方案必须包含 1. 接口定义路径、方法、请求参数、响应结构遵循 ResultT 统一封装 2. 数据模型涉及的表结构、字段类型、索引设计、数据保留策略 3. 目录结构新增/修改的文件路径遵循现有分层规范 4. 关键依赖需要引入的库或中间件以及引入理由 5. 异常处理所有可能出现的异常分支及对应错误码 6. 风险点你识别出的实现风险或需要人工确认的问题。 注意方案文档中不要出现任何业务代码但可以在接口和数据模型部分使用定义式描述。这一步通常耗时 10 到 15 分钟但产出是一份可以拿去评审的文档。我自己的习惯是让 AI 出两版方案一版“标准实现”一版“简化实现”然后根据项目的实际情况选一个这样比只有一个方案的时候多了取舍空间。4.2 代码生成的上下文注入比提示词技巧重要得多方案定了之后代码生成这一关的关键反而不是提示词写得多花哨而是上下文给得够不够。AI 写代码跑偏十次里有八次是因为它不知道项目的既有约定。我实测下来最有效的做法是给 AI 喂一个“项目上下文包”包含以下内容项目的整体结构和分层规范Controller 层做什么、Service 层做什么、Mapper 层做什么统一返回结构ResultT的代码片段项目里已有的一个相似功能的完整代码当作风格参考异常和错误码的定义方式数据库访问层的约定用的是 MyBatis-Plus 还是 JPA日志打印规范。然后用这样的提示词把上下文和任务串起来以下是本项目的基本规范 【项目规范】 - Spring Boot 3.x MyBatis-PlusController 不写业务逻辑 - 所有接口返回 ResultT格式参考 { code: 0, message: success, data: {} } - 错误码使用 ErrorCode 枚举业务异常抛 BizException - 日志使用 Slf4j统一用 log.info/log.error禁止 System.out - 数据库表统一使用 snake_case 命名主键用 BIGINT 雪花 ID。 以下是需求上下文 【任务清单】 T1实现手机号注册接口包含手机号格式校验、验证码校验、密码 BCrypt 加密、事务处理。 【验收标准】 - 注册成功返回 Result 且 code0data 包含 userId - 手机号已注册返回 code11001message“手机号已注册” - 验证码错误返回 code11002 - 手机号格式非法返回 code11003不落库。 请严格遵循以上规范生成代码不要自己定义新的返回结构或异常体系。我特别强调最后一句“不要自己定义新的返回结构”因为 AI 最喜欢干的事就是你给它一个ResultT它转身自己又造了一个ApiResponse。它下意识觉得“统一结构的意思是不是让我设计一个统一结构”经常出现这种画蛇添足。4.3 评审闭环让 AI 自检 人工复审至少两轮代码生成之后不能直接进测试必须先走一轮评审。我的做法是两轮第一轮AI 自检。让 AI 以资深 Code Reviewer 的身份检查自己刚生成的代码提示词是请以资深代码评审员的身份检查下面这段代码。 检查维度 1. 是否满足验收标准中的每一个场景 2. 是否符合项目规范返回结构、异常、日志、命名 3. 是否存在并发/事务/空指针等隐患 4. 是否存在安全风险SQL 注入、越权、敏感信息泄露 5. 是否存在明显的性能问题。 对每个发现的问题按 P0必须修复/P1建议修复/P2可以忽略分级。这段自检非常有用。AI 的自我纠错能力虽然不算强但至少能把它的“自信满满”版本修成“勉强能用”版本能挡掉差不多一半的低级错误。我实测最常见的自检结果是它自己发现“验证码校验逻辑放在了事务内部会无谓地占用事务时间”“密码字段没有加 JsonIgnore 会泄露到响应里”这类问题。第二轮人工复审。这一步不能省AI 自检解决不了“业务理解是否正确”的问题。人工复审时重点不是一行行读代码而是带着验收标准过场景需求里的三个 Given-When-Then 场景代码里是不是都有对应的处理分支如果都有再扫一眼明显的风格问题和安全问题。整个复审我一般控制在 10 分钟以内因为前面需求、方案、验收都过过了代码本身的意外空间已经被压得很小。5. 后置工序测试验证、文档沉淀与复盘更新把代码评审通过只是“写完了”不等于“做完了”。我见过太多 AI 辅助开发的项目死在最后一公里代码看着没问题一跑就崩或者代码没问题但三个月后没人看得懂当时为什么这么写。所以流水线的第五道工序是让结果可验证、可继承。5.1 先写测试用例再跑实现测试是给 AI 的“紧箍咒”正常情况下测试应该在开发之后写。但我在流水线里把顺序反过来了在代码生成之前就要求 AI 先生成测试用例。这一招我从 TDD测试驱动开发里借来的实际操作下来效果奇好。理由很简单如果你先让 AI 写代码再写测试AI 写的测试极大概率是围着它自己的实现逻辑打转最终结果是“实现是对的测试也通过了但需求里的一个场景漏了”。而如果先根据验收标准生成测试用例测试就成了开发行为的一副“紧箍咒”——代码必须穿过测试这关才算数而不是自己给自己开卷考试。测试用例生成提示词请根据下面的验收标准生成单元测试和接口测试用例。 要求 1. 每个 Given-When-Then 场景至少对应一个用例 2. 覆盖异常路径参数非法、数据不存在、外部服务异常、并发冲突 3. 不依赖真实数据库使用 Mock 对象 4. 测试代码同样遵循项目规范。注意“不依赖真实数据库”这条。如果让 AI 生成依赖数据库的测试它往往会假设表已经存在、数据已经准备好最后测试没法直接跑。用 Mock 对象可以让测试在流水线里立刻执行不用先搭环境。5.2 运行、调试、再循环把“一次性生成”改成“迭代交付”在整条流水线的运行层面最颠覆我认知的一个转变是不要期待 AI 一次写对而是接受“生成—运行—报错—修复”的循环是常态。AI 生成的代码第一次能在不报错的情况下跑通的概率在我实际项目中大约六成。剩下四成会遇到编译错误、类型不匹配、依赖缺失、字段名写错这种问题。我把这个循环固定成了一个指令模板用来把报错信息交回给 AI下面是我运行你生成的代码后得到的报错信息和相关上下文。 请你 1. 分析报错的根因不要只给“表面修复” 2. 列出修改方案说明修改涉及的文件和原因 3. 直接输出修改后的完整代码不要只给片段 4. 修改后检查是否引入了新的问题。 【报错信息】 粘贴报错堆栈 【相关上下文】 粘贴关键文件或配置片段这个模板里最重要的一条是“不要只给表面修复”。比如编译报错说“找不到符号”AI 最常见的修复是删掉那行代码而不是去找为什么符号不存在。如果给它强调“分析根因”它能挖到“引用的实体类字段名和数据库列名不一致”“依赖包里根本没有这个类是引入坐标写错了”这类深层原因。5.3 文档沉淀让这次开发的经验成为下次的输入流水线和随手提问最本质的区别在于知识能不能积累。随口问的对话记录关掉窗口就消失了流水线每一步的产出都可以沉淀成可复用的资产。我在每条需求走完之后会让 AI 生成三份文档一份接口使用说明给前端或对接方看一份开发备忘记录这次实现的关键决策和坑点一份流水线复盘评估哪道工序最耗时、提示词哪里需要调整。这三份中文档会进入项目的知识库下次跑流水线时作为参考上下文注入相当于让 AI“记得”这个项目的历史。文档生成提示词我简化为这样请根据本次需求的需求说明、技术方案、代码和测试结果生成 1. 接口文档请求/响应示例、错误码表、调用注意事项 2. 开发备忘本次实现涉及的关键决策、踩过的坑、遗留问题 3. 复盘摘要哪个环节返工最多原因是什么。 要求语言简洁直接可用不要写“本次指南”之类的开场白。这个环节不要省。我后来反复体会到AI 辅助开发的项目最大的风险是“人看不懂AI 也忘了”最后代码变成一团既没人敢动、也没人能动的历史包袱。文档沉淀本质上是在对抗这种熵增。6. 编排落地的选型实践Agent 框架、编排平台与提示词模板管理前面讲的都是流程和提示词层面的设计但这条流水线真正“可复用、可编排”还需要一套承载它的工具和管线。这一章聊聊我实际用过的选型以及每种方案适用什么场景。6.1 编排能力需要满足哪三件事我把流水线对工具的要求归结为三件事第一工序可串行可分支。需求澄清完可能要人工确认确认完了才往下走方案设计完可能要对方案做人工审批。工具至少要能表达这种“人机协作”的流程而不是一股脑全自动跑完。第二上下文可传递。上游产出的需求说明、验收标准、技术方案要能自动传递到下游提示词里而不是每次重新粘贴。这一步直接决定整条流水线的效率。第三产物可沉淀。每一步的产出需求文档、方案、代码、测试报告要落库成为后续需求的参考上下文。6.2 我用过的四类编排方案对比方案代表工具优点缺点适合场景低代码编排平台Dify、Coze可视化编排、节点可复用、知识库集成方便重度业务代码落地受限灵活度一般团队协作、知识库流水线、非程序员也能改流程通用自动化编排n8n、Zapier节点丰富能串 API 和消息通知对代码生成这类“长文本任务”支持不够精细和团队 IM、工单系统联动做流程自动化代码级编排LangChain、LangGraph、自研脚本灵活度最高能精确控制每一步的输入输出和分支逻辑需要写代码维护入门成本高个人开发者、追求深度定制的场景IDE 内置 AgentCursor、Codex CLI、补全插件和编辑器深度集成修改代码体验顺滑流程编排能力弱适合单任务不适合整流程轻量版流水线单步任务执行我自己的主力组合是核心流水线用自研脚本做代码级编排团队知识库和文档沉淀用 Dify 搭一条知识库流水线日常单点开发直接用 IDE 内置 Agent。三套工具各管一段。自研脚本管“五道工序的严格顺序”Dify 管“文档入库和检索”IDE Agent 管“临时性的小改动”。6.3 提示词模板如何版本化管理前面说的所有提示词模板光有内容还不够还得管起来。我身边很多朋友把提示词直接放在一个备忘录里改一版没一版这不行。提示词模板就是流水线的源代码它需要版本管理。我的做法比较简单直接在项目仓库里建一个prompts/目录每个工序一个 Markdown 文件文件名带版本号比如01-requirement-clarify-v3.md。每次修改后用 git 提交提交信息写明改了什么、为什么改。跑流水线时脚本读取当前版本的模板填充上下文。还有一个非常重要的细节提示词模板不要写得“太满”。一开始我追求把每个细节都写进模板结果发现模板越长AI 越容易抓不住重点甚至会在不相关的约束上反复纠结。后来我把模板精简为角色定义一两句话、任务目标一两句话、输出格式列表式、验收要求优先级清单。剩下的细节全部作为变量注入而不写死在模板里。6.4 一个轻量版编排的完整示例为了让“编排”这件事不那么抽象我贴一个我在轻量版流水线里实际在用的简化脚本逻辑。它本质上是一个按顺序调用各工序提示词的流程控制每个工序都有结构化的输入输出。#!/bin/bash # 轻量版 AI 开发流水线 REQ_DESC$1 # 传入原始需求描述 TASK_ID$2 # 任务编号用于命名产物 # 工序一需求澄清 echo 工序 1/4需求澄清 requirement_text$(call_ai --role 业务分析师 \ --template prompts/01-requirement-clarify-v3.md \ --input $REQ_DESC) # 人工确认这个环节必须停下等人确认 echo $requirement_text artifacts/${TASK_ID}-requirement.md read -p 需求文档已生成确认无误后按回车继续需要修改请输入 n: confirm # 工序二任务拆解与方案设计 echo 工序 2/4任务拆解与技术方案 task_list$(call_ai --role 架构师 \ --template prompts/02-task-and-design-v2.md \ --input $requirement_text) echo $task_list artifacts/${TASK_ID}-design.md # 工序三代码生成按任务清单逐项生成 echo 工序 3/4代码生成 for task in $(parse_tasks $task_list); do generate_code --context artifacts/${TASK_ID}-design.md \ --task $task \ --output src/${TASK_ID}/${task}.java done # 工序四测试与文档 echo 工序 4/4测试用例与文档生成 generate_tests --based-on artifacts/${TASK_ID}-requirement.md generate_docs --from artifacts/${TASK_ID}-requirement.md这里的call_ai函数可以是对接任意模型 API 的封装重点是整个流程的输入输出是文件化的每一步的产物都被保存下来既方便人审核也方便后续作为上下文复用。我特别强调“工序一之后必须有人工确认”这一步不要省略。需求澄清的结果如果不经过人确认AI 自己确认自己的猜测那跟随手提问没有任何区别。7. 这条流水线跑了大半年的实测体会与踩坑记录最后这部分聊聊流水线跑了大半年之后我的真实体感和踩过的坑。这些经验如果没人说你可能要自己交几个月学费才能换到。7.1 我最常踩的五个坑坑一把流水线当成全自动工具。流水线解决的是“流程结构”的问题不是“完全不用人”的问题。我最早设计流水线时想着“人只需要输入需求剩下的 AI 全包”结果发现需求输入之后需求澄清阶段 AI 问出的问题一多半我根本答不上来得去问业务方。这时候我才意识到流水线把原本藏在开发过程中的模糊性提前暴露了这不是坏事但你必须预留人来处理这些模糊性的时间。坑二验收标准写得太泛。我最早写的验收标准是“注册功能正常可用”后来发现 AI 生成的测试用例也是“正常可用”级别的等于没有验收。改成 Given-When-Then 格式之后质量立刻上了一个台阶。这件事我强烈建议不要图省事。坑三一次性把全部代码交给 AI 生成。我试过在工序三里让 AI 一口气生成整个任务清单下所有任务的代码结果输出经常截断或者前面任务的代码和后面任务的设计不一致。后来改成“一个任务一次生成”每次生成一个独立的代码文件质量稳定得多。坑四忽略了“代码风格统一性”的校验。让 AI 生成多个文件的代码时它每次生成都会重新理解项目规范导致两个文件对同一个业务对象的命名可能不同一个用userId一个用uid。我在流水线里加了一道“风格一致性检查”工序后这类问题才基本消失。坑五复盘环节流于形式。我承认文案类的复盘摘要 AI 写得很好但它经常会把“我这次最大的问题是需求没问清楚”这种烂账重复三遍却没有提炼出具体的改进动作。后来我改成让 AI 输出“下一步要修改哪个提示词的哪一行”复盘才真正对流水线有反哺作用。7.2 实测数据效率和质量到底提升了多少我知道没数据大家不信我大概统计过这半年跑流水线的账。从时间上看一个中等复杂度的需求比如一个带权限控制的报表查询功能现在从接到需求到交付压缩到半天到一天。而同样的需求过去同事自己写的交付周期是两三天。省下来的时间主要花在需求澄清和方案设计上的那半小时因为这两步做扎实了后面几乎不返工。从质量上看代码评审中发现的 P0 级问题会导致线上事故或数据错误的问题数量明显下降。过去 AI 直接写的代码P0 问题大概每三次就出现一次流水线跑出来的代码P0 问题集中在需求环节的遗漏上代码层面的问题很少。这说明流水线没有把 AI 变成更好的程序员而是把它变成了一个更有纪律的执行者。7.3 什么样的人适合直接抄这条流水线最后说说适用范围。如果你属于以下任何一种情况我建议你直接照着我这套流程复制一版跑起来你是个人开发者经常用 AI 写代码但总觉得效果不稳定翻车率高于五成你的团队正在把 AI 引入日常开发但还没有一套统一的协作方式每个人都在用不同的姿势问 AI你维护的项目有一堆历史代码和项目规范每次交给 AI 时都要重复粘贴一堆上下文觉得特别繁琐。如果你觉得五道工序太重那就从轻量版的三道工序开始。我自己最想传达的一个体会是跟 AI 协作开发真正的杠杆不在模型选择也不在提示词技巧而在你愿不愿意把开发流程本身当成一个需要编排和管理的产品。流程理顺了AI 的能力才不会被损耗在无休止的猜测和返工里。还有一个小技巧我最后分享一下吧给流水线的每一步都设定一个最大迭代次数比如代码评审最多两轮超过两轮就让人直接接管。这个规则逼着你去重视前置工序因为你心里清楚后端不长眼睛的兜底在那里等着你。我加了这个限制之后需求澄清和方案设计的质量瞬间上去了因为你知道后面没有无限次重来的机会。