1. 为什么“AI编程工作流”值得单独拿出来聊我平时带团队做交付也自己接一些外包项目最近一年最大的感受就是会用AI写代码的人越来越多但真正能把AI用成“稳定生产力”的人依然很少。大部分人停留在“打开对话框贴一段报错复制粘贴结果”的阶段这种用法在写小脚本时还行一旦进入真实项目立刻暴露三个问题上下文丢失、结果不可复现、质量无法兜底。所以我一直认为AI编程的核心不是模型有多强而是工作流有多稳。这篇文章要拆的就是三个我自己反复打磨、可以直接抄作业的AI编程工作流。它们分别覆盖三个高频场景新功能从需求到代码的落地、存量代码的理解与重构、以及测试与缺陷排查。这三个场景基本覆盖了一个开发者日常80%的时间消耗。每个工作流我都会讲清楚它解决什么问题、为什么这么设计、具体怎么操作、以及我踩过哪些坑。不管你是刚接触AI辅助编程的新手还是已经用了一段时间但觉得“时灵时不灵”的老手都能从中拿到能立刻复用的东西。需要先说明一点下面所有工作流都不依赖某个特定厂商的模型你用常见的对话式大模型、IDE内置助手、命令行Agent都能落地。工具会变工作流的骨架不会变。这也是我坚持把“流程”而不是“工具”作为核心来讲的原因。2. 工作流一需求到代码的“三段式收敛法”2.1 这个工作流解决什么问题新手最容易犯的错是把一句模糊的需求直接丢给AI然后期待它吐出一整块能用的代码。比如“帮我写一个用户登录功能”AI会给你一个看起来能跑、实际上漏洞百出的版本密码明文存储、没有防暴力破解、token过期逻辑缺失、异常处理全靠print。这不是模型不行是你给的信息量根本不足以让它做出正确决策。三段式收敛法的核心思路是把“一次性大提问”拆成“三次逐步收敛的小提问”让AI在每一步都只聚焦一个维度从而把模糊需求逐步逼成精确规格。这三段分别是意图澄清、接口契约、实现落地。2.2 第一段意图澄清先别让它写代码第一段的目标不是产出代码而是产出一份双方都认可的需求边界。我通常会用这样的提示词结构我要实现一个[功能名称]背景是[一句话业务场景]。 在动手写代码之前请你先不要给实现而是帮我做三件事 1. 列出这个功能必须处理的输入和输出 2. 列出你认为我可能没说清楚、但会影响实现的关键决策点 3. 针对每个决策点给出2到3个可选方案和各自取舍。这一步的价值在于AI会主动帮你把“隐藏假设”翻出来。比如你只说“用户登录”它会问你是账号密码还是手机验证码是否需要记住登录状态失败几次锁定这些恰恰是你脑子里默认存在、但没写出来的东西。我实测下来这一步能提前消灭掉大概六成的返工。提示这一步千万不要让AI写代码。一旦它开始写你的注意力就会被具体实现带偏反而忽略了需求本身的漏洞。2.3 第二段接口契约把边界钉死需求边界确认后第二段让AI产出接口定义而不是完整实现。所谓接口契约包括函数签名、入参出参结构、错误码、以及关键的前置后置条件。以登录为例我会要求它输出类似这样的东西def login(username: str, password: str, remember_me: bool False) - LoginResult: 前置条件username 和 password 均非空 后置条件成功返回带 token 的 LoginResult失败抛出 AuthError 错误码 - USER_NOT_FOUND - PASSWORD_MISMATCH - ACCOUNT_LOCKED 为什么这一步单独拎出来因为接口是人和AI之间的“合同”。合同定死了后面无论谁来写实现、用哪个模型写只要遵守合同结果就是可替换、可测试的。我见过太多项目AI生成的代码彼此之间接口对不上最后人工缝合的时间比手写还长根子就在跳过了契约这一步。2.4 第三段实现落地分块生成加自检到了第三段才让AI真正写实现。但即便是写实现也不要一次性要全部代码。我的做法是按契约里的函数逐个生成每生成一个就让它自己补一段单元测试。提示词可以这样组织基于上面的接口契约请实现 login 函数。 要求 1. 只实现这一个函数不要写调用方 2. 密码校验使用项目已有的 hash 工具假设为 verify_hash 3. 同时给出对应的单元测试覆盖成功、密码错误、账号锁定三种情况 4. 实现完成后逐条对照契约里的错误码确认没有遗漏。最后那句“逐条对照确认”很关键。它相当于让AI自己做一次回归检查实测能显著降低漏掉边界情况的概率。三段走完你拿到的不是一段“看起来能用”的代码而是一份有边界、有契约、有测试的可交付物。2.5 实操心得与常见坑这个工作流我用了大半年总结几条经验。第一第一段和第二段绝对不要省省了这两步第三段产出的代码质量会断崖式下跌而且你很难定位问题出在哪。第二如果项目已有代码规范在第二段就把规范样例贴给AI比如“参考项目里现有的 service 层写法”它生成的风格会立刻对齐。第三遇到AI在第三段“自作主张”扩展功能时直接打断它重申“只实现契约内的内容”。AI有很强的“补全冲动”你不约束它就会给你加一堆你没要的东西。3. 工作流二存量代码的“逆向理解与安全重构”3.1 接手老代码时的真实困境第二个工作流针对的是另一个高频痛点接手一坨没有文档、没有注释、原作者已经离职的存量代码。传统做法是自己一行行读读一周才敢改。AI在这里能帮上大忙但前提是你要用对方法。直接问“这段代码是干嘛的”AI经常给你一个似是而非的概括因为它看到的上下文太少了。我的做法叫逆向理解与安全重构分四步切片、追问、画图、小步改。核心原则是先理解到能画出数据流再动手改且每次只改一个关注点。3.2 切片把大文件拆成可消化的单元第一步是把目标文件按函数或类切成小块逐个喂给AI。不要一次性丢一个两千行的文件进去那样AI的注意力会被稀释总结质量很差。切片的标准是每个单元有明确的输入输出最好不超过一百行。切完之后对每个单元问三个问题这个单元接收什么、返回什么、可能抛什么异常它依赖了哪些外部状态全局变量、数据库、其他模块如果它出问题最可能的失败模式是什么这三个问题逼着AI从“描述代码”转向“分析行为”产出的信息密度完全不一样。3.3 追问用“为什么”逼近真实意图切片理解之后我会针对可疑的地方追问。比如看到一段奇怪的兼容逻辑我会问“这段判断if version 3的分支可能是为了兼容什么历史情况如果去掉会有什么风险”AI不一定知道真实历史但它能基于代码结构给出合理的推测而这些推测往往能帮你回忆起或推断出当年的设计约束。注意AI的推测只是线索不是结论。凡是涉及删除代码的判断必须自己再验证一遍或者找到测试用例兜底。3.4 画图用文字描述数据流我不用任何图形工具而是让AI用文字把数据流串起来“请用文字描述从入口函数到数据库写入的完整调用链标出每一步的数据形态变化。”文字版的数据流有个好处可以直接贴进代码注释或文档里而且强迫AI把隐式的东西显式化。当你发现某一步“数据形态说不清楚”时那里往往就是隐藏bug的温床。3.5 小步改一次只动一个关注点理解到位后开始重构。这里的铁律是一次提交只解决一个问题。想改命名就只改命名想抽函数就只抽函数想加日志就只加日志。每改完一步让AI帮你检查“这次改动是否引入了行为变化”。提示词可以是“以下是我对某函数的改动请对比改动前后列出所有可能影响运行时行为的差异。”这一步相当于给重构上了保险实测能拦住不少“以为只是改名、其实改了逻辑”的低级错误。3.6 重构中的避坑清单我整理了一份自己常用的检查表重构前逐条过一遍检查项为什么重要我的做法是否有测试覆盖没测试的重构等于裸奔先补关键路径测试再改是否改动公共接口影响面可能超出预期全局搜索调用方再决定是否涉及并发AI很难推理时序问题并发部分人工复核是否改动序列化格式可能破坏存量数据加版本号或兼容分支是否删除“看不懂”的代码可能是历史补丁先注释保留观察一版再删这张表看着朴素但每一条都是我或同事真实踩过的坑换来的。尤其是最后一条我见过有人删掉一段“看起来没用”的代码结果线上某个边缘场景直接崩了回滚都来不及。4. 工作流三测试与缺陷排查的“假设驱动闭环”4.1 为什么测试环节最需要工作流写测试和查bug是两件特别容易被AI“糊弄”的事。你让它写测试它给你一堆断言恒为真的废测试你让它查bug它给你一堆“可能的原因”但没一个能验证。问题在于这两件事本质上都是假设-验证的过程而AI天然倾向于给结论、不给验证路径。所以这个工作流的核心是强制AI跟着“假设驱动”的闭环走。4.2 写测试从行为清单到用例矩阵写测试的第一步不是写代码是列行为清单。我会让AI先输出“这个函数在所有输入组合下的预期行为表”包括正常路径、边界值、异常路径。然后基于这张表生成用例矩阵最后才写测试代码。提示词示例针对函数 parse_config请先列出它的完整行为清单 - 正常输入下的返回 - 空输入、超长输入、非法字符输入下的行为 - 依赖的外部资源缺失时的行为 列完之后为每一行生成一个测试用例并标注优先级。这样产出的测试是有结构的而不是零散凑数。我特别看重“标注优先级”这一步因为真实项目里测试永远写不完你得知道哪些是必须覆盖的。4.3 查bug先列假设再设计验证查bug时我严禁AI直接说“问题可能是X”。我会要求它先列出至少五个可能原因然后针对每个原因给出“如何验证”的具体方法。比如“如果是缓存未失效导致的那么清空缓存后重试应该恢复正常验证方法是……”。这一步把AI从“算命先生”变成了“实验设计者”。然后我按验证成本从低到高排序逐个排除。很多时候第一个假设就被证伪了但这个过程本身会快速缩小范围。我实测下来用这种方式查一个中等复杂度的bug平均比盲目读代码快三到五倍。4.4 复现把偶发问题变成必现问题最难查的是偶发bug。这时候我会让AI帮我设计复现策略“这个bug大约每百次请求出现一次请列出所有可能导致‘偶发’的因素以及如何构造一个能稳定触发它的测试环境。”常见的方向包括并发时序、资源竞争、超时边界、随机数种子等。把偶发变成必现问题就解决了一半。4.5 排查速查表下面这张表是我平时查bug时的快速索引配合AI使用效果最好现象优先怀疑快速验证手段改了代码没生效缓存/构建产物清缓存重新构建本地好线上坏环境差异/配置对比两边配置项偶发失败并发/超时/资源加日志压测复现数据对不上序列化/精度打印原始字节内存持续增长泄漏/未释放抓快照对比这张表的价值在于它把“经验”变成了“可执行的检查顺序”。新手照着走也能少走很多弯路。5. 三个工作流如何组合成日常节奏单独看这三个工作流各自解决一个场景。但真正让我效率提升的是把它们串成一天的节奏。我的典型一天是这样的上午接到新需求走工作流一把需求收敛成契约和实现下午如果有存量代码要动走工作流二先理解再小步改临近提测或线上出问题走工作流三用假设驱动快速定位。三个工作流共享同一个底层习惯先让AI帮我想清楚再让它动手。这个习惯说起来简单做起来反人性。因为人天生想快点看到代码想快点看到结果。但我踩过的坑告诉我在AI编程这件事上“慢就是快”。你在澄清和契约上多花的十分钟能省下后面两小时的返工。你在假设和验证上多花的五分钟能省下盲目试错的一下午。最后分享一个我自己的小技巧我会把这三个工作流的提示词模板存成一个文件每次用的时候直接改括号里的内容。模板化之后调用成本几乎为零你才可能真正坚持用下去。工具会更新模型会换代但“先收敛、再理解、后验证”这套骨架我估计还能用很久。