AI Coding频繁返工，问题出在哪？抗返工开发流程改造实录-北京尧图网络

这个函数我昨天刚让AI写过一遍怎么今天跑测试就报错了——类似的话这两年我在团队里听到的频率越来越高。身边几乎所有重度使用AI编码工具的朋友都有过完全相同的体验明明AI写代码的速度快到惊人但真正把功能交付出去却发现总要在联调、测试、Code Review阶段反复打回重做。AI Coding是不是真的省时间为什么越是依赖AI返工率反而越高今天我认真把这笔账算了一遍。1. 先别谈体验用一组真实数据看返工的代价有人喜欢说以前写这个需求要一天现在让AI半小时搞定。这话只说对了一半。我自己的感受是生成速度确实快了但后面跟着的返工链条一点都不快。1.1 一次典型返工从生成到联调绕了一大圈拿我去年经手的一个模拟项目X举例。项目是一个垂直领域的交易后台前端大概三千行业务代码其中三分之二是用AI编码工具辅助生成的。开发阶段一切顺利表面上页面渲染、按钮点击都对当时我还跟同伴感慨以后真不用自己写前端了。结果到了联调阶段问题集中爆发有三个列表页在特定数据状态下直接白屏两个表单在提交时丢失了某个字段还有一组权限判断在角色切换后出现混乱。事后逐条排查原因都很戏剧化。比如列表页白屏是因为AI生成的接口调用和我后端定义的数据结构差了一个层级——它按照平铺对象去取值可实际返回的是一个嵌套结构。每个单函数单独看都没毛病单元测试也能过但只要数据真实跑起来字符串、对象、数组互相错位整个渲染链路就断了。那一次联调前前后后拖了四天。代码写出来只花了大概半天另外三天半全耗在定位和修整上。1.2 返工的真实账本省下的时间一半以上又还了回去那之后我专门统计过自己一个月的开发节奏结论非常扎心功能开发周期确实缩短了大概25%但Bug修复和联调的时间同比增加了四成左右最终净节省下来的时间可能只有十几个小时。也就是说AI Coding帮我省下的时间有一半以上在返工环节里又还了回去。这还只是代码层面的返工如果算上团队成员之间因为信息不对齐产生的沟通成本实际损耗还要再高。1.3 返工不是一种形态而是三种形态我后来把这些返工问题归类发现它远不是代码写错了这么简单逻辑型返工算法算错了、边界条件没处理、并发场景下数据状态不一致。这类返工最友好因为报错信息通常很明确顺着堆栈就能找到问题AI还能帮你快速修。契约型返工接口参数、返回结构、字段类型、命令约定出了问题。AI对接口契约做出了错误假设单测往往覆盖不到一旦数据真正流动起来就会暴露。我遇到过的大部分返工都属于这一类。规范型返工团队代码规范、命名习惯、分层职责、错误码规划AI完全不了解。它生成的代码能跑但风格和现有代码库格格不入Review时被要求整体重写。第一种返工其实还好后面两种才是真正消耗团队精力的黑洞。2. 返工的核心根源三个结构性错位既然返工不是偶然事件那它背后一定有系统性原因。我思来想去问题不在工具不够好而在于我们在用大语言模型做一件它天然不擅长的事情——把生成稳定文本的模型用来处理必须绝对正确的工程制品。这里有三个结构性错位是所有AI编码返工的底层逻辑。2.1 错位一AI擅长局部正确做不到全局一致这是我对AI编码工具最深的体会。模型在生成每一行代码时其实是根据已经生成的前缀逐个预测下一个最合理的Token。它不是在按图施工而是在续写一段看起来通顺的文字。这意味着它在生成一个函数时根本不知道你的项目里还有哪些模块、哪些接口、哪些约定。所以最典型的症状出现了单个文件看起来完美无缺跨文件调用的时候问题毕现。AI会按照自己训练数据里最常见的命名习惯给状态常量取名可你项目里其他模块用的是另一套名称。AI会按照通用场景设计接口的入参出参可你的后端契约是另一套结构。它不是故意写错是它压根看不到其他模块里已经确立的事实。我把这种问题称为局部的正确性幻觉。你要是让AI单独写一个函数它几乎次次都能产出语法正确、逻辑通顺的代码。但你要是让它把一个完整业务链路上的关联模块都串好它就只能靠猜了。猜的次数多了自然就有猜错的时候。2.2 错位二AI能理解字面需求理解不了隐性约束第二个错位更隐蔽。很多人给AI提需求时觉得一句话就够了给用户列表加一个删除按钮。真要在项目里落地这个功能背后至少还跟着这些问题删除是物理删除还是软删除权限怎么控制谁能删谁不能删删除前需要不需要二次确认删除之后列表要不要刷新回当前页有没有关联数据需要同步处理审计日志要不要记录操作人AI在训练时见过无数个删除功能它会按照统计上的最常见做法来生成。可你的项目有自己独特的业务约束比如某个核心删除操作必须联动另一个清洗服务失败时整个事务要回滚。这些隐性约束没写进提示词AI当然不会主动替你考虑。它给你产出一个干净但肤浅的实现逻辑简单、结构漂亮但放到真实业务场景里恰好差最关键的那一环。这一条是我认为AI返工里最让人头疼的部分。因为字面需求它都满足了你也挑不出它哪不对但它就是对业务无感。最后往往是回归测试阶段被某个业务专家指着代码问如果这里数据删除了一半服务挂了怎么办——这才意识到隐性需求在生成阶段就已经丢掉了。2.3 错位三模型的知识有保质期但它表现得太过自信还有一个大家不愿意承认但不得不面对的原因模型的知识边界切在训练那天。它学的所有API、框架习惯、技术栈写法都停留在那个时点。如果你的项目用的是比较新的版本或者团队内部封装了一套私有SDK和框架那么AI之前学到的经验全都作废。更糟糕的是当上下文不足以支撑准确生成时模型会一本正经地编造一个不存在的API或用法出来。这在业内叫幻觉但在实际开发里它呈现出来的方式非常迷惑人——AI给出的代码看起来很合理参数名像那么回事注释也写得很有道理唯独那个函数名在文档里根本搜不到。有一次我在做某跨平台系统的迁移AI推荐了一个听起来非常合理的生命周期函数名我当时以为是自己参数写错了翻文档翻了十几分钟最后才确认这个函数压根不存在。这不能全怪AI它在概率分布里推断出这里应该有个这样的函数当它见过太多代码文本后概率推理的结果就是生造出一个。但它不懂的是工程代码里每一个符号都必须指向一个真实存在的实体不能靠感觉合理来凑。3. 最贵的不是改代码是每轮返工背后的认知税如果说前两部分讲的是返工从哪里来那我想再花一节专门聊一个很少有人算清楚的东西认知税。返工的成本绝不仅仅是把那段错代码改对的时间还有更多隐性消耗。3.1 阅读AI代码比阅读人类代码更费脑我后来发现一个规律review AI代码所花的时间通常比review人类同事代码要多得多。原因很简单你自己写的代码脑海里已经跑过一遍需求场景你知道每段逻辑为什么会在这但AI写的代码不同它只是看起来对。你为了判断它到底对不对被迫做一次完整的心智还原——它为什么这样拆函数这个变量为什么存在这段条件判断是不是在兜一个前面就写错了的窟窿这种代码考古非常消耗精力。团队里曾经有过一次统计AI写100行代码人工review大约需要50到80分钟还是在逻辑不复杂、没有隐藏规则的情况下。而一个老工程师review新人的100行代码往往十几分钟就能扫完——因为新人至少是带着需求上下文写的老工程师看一眼就能猜到他的意图可面对AI的代码你得先建立一套它对这个问题是如何理解的模型然后才能验证它理解得对不对。3.2 连续返工只会不断透支对AI的信任认知税的第二块是信任损耗。当连续三次AI给的方案都要推倒重来时人最大的变化不是觉得AI没用而是开始默认AI生成的每一段代码都需要重写。带着这种心态哪怕AI真的完美处理了一个小任务你也仍然会花大量精力去验证最终得出一个结论与其花这么多时间去验证不如干脆自己写算了。这也是我身边很多同事最终放弃AI编码的真实原因——不是工具不够强而是验证成本太高。当验证成本的期望值超过自己动手的成本时理性的人一定会选择自己动手。这背后还有一个心理效应每返工一次你对工具的信任值就掉一档而信任恢复的速度远比掉的要慢得多。3.3 上下文重载是被反复忽视的隐藏开销认知税还有一个结构性问题叫断点续传。上午你让AI写了一个核心模块下午你转头改另一个需求。等到傍晚再想让AI看看之前那个模块时模型已经完全不记得上下文了。你需要重新把项目背景、目录结构、接口文档、本轮需求全部投喂一遍。每次投喂、生成、验证、返工的循环都在不断重复这个上下文再加载的过程。更隐蔽的是它会直接影响代码的连贯性。你在一个分支上让AI写了方案A另一个分支上让AI写了方案B。等合并主分支时你发现两个方案在抽象层级、命名风格、接口签名上完全对不上。那会儿你要做的不是合并代码而是先做协调两套设计思路的工作成本一下子又上去了。4. 我把流程改造成抗返工结构返工率降了六成讲了这么多问题如果只是抱怨那就跟网上那些AI Coding也不省心的牢骚帖没什么区别。真正有价值的是怎么把流程改造成能够系统性抵抗返工的结构。在过去半年里我们团队做了几个关键调整返工率下降差不多六成更重要的是整个过程不再内耗。说几个我认为最有效的改动。4.1 给AI写边界而不是写愿望很多人用AI编码时随口就一句帮我写一个用户注册接口。这种模糊指令是返工率最高的发源地。我现在的做法是给AI的提示词至少包含六个部分目标接口的行为描述和目标场景已知的输入参数类型和约束规则涉及的领域对象及它们之间的关系显式声明不要做的事比如不要改配置文件、不要引入额外依赖、不要动公共库请求返回的结构和异常处理的契约一小段本项目的风格示例代码。最后一条是最关键的。模型对代码风格的感知主要来自上下文中的示例。你给它看一段现有代码的风格它大概率能延续这种风格你只丢给它一句描述它就会采用训练数据里统计上最常见的风格这通常和你的团队风格没有半点关系。同样的逻辑也适用于命名、错误处理、日志格式都是一样的道理。4.2 把大任务拆成可验证的小零件AI适合做单点任务不适合做端到端的大改造。所以我现在一律把需求拆到很小的粒度一个文件、一个函数、一个接口、一个状态节点然后每个零件在生成之后立刻做独立验证。小步快跑反而能把AI的优势发挥到最大同时规避它最大的短板。比如说一次完整的后端需求我会这样拆先让AI生成DTO定义和类型转换函数再让它生成参数校验工具和错误码映射接着让它生成服务层调度逻辑每一步都立刻写对应的单元测试跑完绿了才进入下一步。这个流程彻底规避了一整块巨石代码集成时崩掉的噩梦。返工的范围被限制在某一个零件里哪怕要重写也只重写那一个小环节不会连累上下游。4.3 测试当裁判让返工前置到生成阶段AI在生成代码时本来就有能力自己写测试但很多团队把它当附带福利看都不看。我的做法反过来了AI生成的代码必须附带对应的测试用例。我拿到手之后不是先读业务逻辑而是先把测试跑一遍看它是红还是绿。绿了再人工审查断言质量红了直接把报错喂回去让AI自己修。这里有一个非常值得警惕的细节AI生成的测试通常很仁慈它倾向于给自己写能过的测试。所以我会挑一部分关键断言手动改得更严格——把数组非空改成数组长度恰好等于3把字段存在改成字段的值精确等于X。这一步改动能精准地暴露出AI代码里的逻辑坍缩点很多平时隐藏得很好的返工问题就是被这样逼出来的。4.4 建立团队的AI编码契约明确哪些绝对不能碰我们在团队内部维护了一份文档叫AI编码契约列清楚哪些任务可以直接交给AI哪些绝对不能让它碰。这比任何提示词都重要。目前明确可以交给AI的任务包括独立组件生成、DTO和类型定义、单元测试辅助、文档生成、简单算法辅助、Bug定位辅助。明确绝不让AI碰的任务包括数据库迁移、跨模块重构、涉及金额和权限的核心流程、需要审计日志的操作、系统部署脚本。这个划分不是拍脑袋定的是在整个团队实践了几个月之后统计出来的规律凡是直接让AI动核心资金流、权限链路返工率都奇高而且出了问题极难排查。无论模型能力提升到哪个阶段我们目前都坚持守住这条线。这不是保守这是对成本和风险的理性控制。同时我也会给AI提供一份风格规范的小段落粘在提示词里错误码命名规则、日志格式、注释规范、参数校验方式。有了明确的规范输入风格返工明显少了一大截。4.5 人审意图、机做实现三轮循环定节奏最后我自己习惯的工作节奏是三轮走第一轮让AI初次生成只求跑通最小用例场景第二轮把测试结果反馈给它让它修复已知边界和异常处理第三轮由人来review判断业务语义和整体架构是否对齐。这个节奏背后的核心思想很简单人负责意图AI负责执行细节但意图验证永远不能被跳过。很多返工其实从头到尾漏的就是意图验证这一步。可能在第一步生成的时候需求本身就理解歪了但没人在那个节点拦住它一直到集成测试时才发现整个链路推倒重来。三轮节奏的好处就是逼着每个节点都做一次快速检查把问题拦截在最小范围内。5. 回到标题的问题AI Coding频繁返工到底问题出在哪写到这里我的核心看法已经很清楚了AI Coding的返工本质不是AI的能力缺陷也不是使用者的水平不够而是我们常常把错误的协作模型套在了这个工具头上。我们下意识地希望AI像外包的程序员一样直接交付成品催一催就能看到产出不满意就打回重做。但AI的实际角色更像一个动作很快、底子很厚、但完全不熟悉项目背景的高水平实习生。它不了解你们接口设计的历史原因不知道团队命名背后的妥协更不懂业务规则的潜台词。你如果只顾着下达指令不去交代上下文不设置验收关卡不在关键环节保留人的判断力那返工就是必然的系统性结果。我个人的应对心得是把AI当成协作对象而不是替代对象。强调人给意图AI给实现测试当裁判。这个组合看起来朴素但确实是我目前见过最稳定、返工率最低的工作模式。还有一个很有意思的观察。之前我很羡慕那种AI生成一次就能跑通的同事后来发现他们都有一个共同点他们几乎从不让AI做没有上下文的任务每当需要新东西时第一件事永远是写清楚需求和约束然后才让工具干活。这个习惯本身才是对抗返工最有效的方法。如果你正在被AI Coding的反反复复困扰我建议先别急着换新工具、加新提示词而是回头审视一下你和你正在用的工具之间到底是怎么分工、怎么协作的。再顺手分享一个小的个人经验无论提示词写得多完整AI生成的代码永远要以需要review为前提去对待。你要做的不是在代码层面逐行校对而是先把关键用例在脑子里跑一遍再用测试验证一遍最后才轮到看细节。把这三步做成肌肉记忆之后AI编码带来的额外返工至少能压掉一大半。

AI Coding频繁返工，问题出在哪？抗返工开发流程改造实录

相关推荐

数据资产智能清查：清查指令与核验模板实战指南

荣耀MagicOS 10自定义唤醒词与方言识别调优实战

AI数据脱敏实战：从敏感数据发现到分级合规落地

更多资讯

智能化小区网络规划全解析：从拓扑选型到落地避坑指南

上下文模式实战：多端多状态系统的动态行为调度策略

微表情识别中的自适应关键帧提取方法

产品EMC设计与风险评估：从原理图到量产的全流程实战

基于深度学习与PyQt的湿滑路面自适应制动决策系统设计与实现

WSL下STM32固件烧录实战：从编译到烧录的完整指南

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？