★ FEATURED ARTICLE 1. 当代码不再是瓶颈产研协作的底层逻辑正在被重写这两年跟不少做产品的、做研发的朋友聊天大家都有一个共同的感受以前一个需求从提出到上线最耗时的环节往往是“写代码”本身。产品经理写清楚需求文档设计师出完稿研发同学开始吭哧吭哧敲键盘中间还要经历联调、改bug、回归测试一套流程走下来小需求一周大需求按月算。但现在情况变了优秀的大模型工具在代码生成、补全、重构甚至调试环节的表现已经让“写代码”这件事的耗时占比急剧下降。我实测过几个主流工具一个中等复杂度的接口以前从零写大概要半天现在把接口文档和数据结构喂进去几分钟就能拿到可运行的初版剩下的时间主要花在验证和边界处理上。这个变化带来的直接后果是研发环节的“产能”被释放了但产研协作的流程并没有同步调整。以前研发是瓶颈产品经理和设计师会相对耐心地等待排期现在研发说“我这边代码已经差不多了”产品经理反而会懵——需求评审还没走完设计稿还在改第三版测试用例还没开始写怎么研发就说快好了这种节奏错位正在成为很多团队新的摩擦点。这篇文章想聊的就是当大模型工具把“写代码”这件事的门槛和耗时都大幅降低之后产研协作到底该怎么调才能让整个链条真正跑顺而不是让研发单方面加速、其他环节被拖着走。适合读这篇内容的人包括正在使用或准备引入大模型编码工具的产品经理、技术负责人、研发工程师以及任何关心产研协作效率的人。我不会讲太多工具本身的用法重点放在协作流程的重构、角色边界的重新划分以及我踩过的一些坑。2. 为什么“写代码”被替代后协作反而更容易出问题2.1 研发产能释放带来的“节奏错位”以前研发是瓶颈这个瓶颈虽然让人着急但它有一个隐性好处它给其他角色留出了缓冲时间。产品经理知道研发排期紧所以会尽量把需求想清楚再提设计师知道研发要等稿所以会尽量按时交付测试知道研发写完还要自测所以会提前准备用例。整个链条虽然慢但每个环节都有相对充裕的时间去打磨自己的部分。大模型工具把研发环节压缩之后这个缓冲带消失了。研发可能半天就把一个模块的代码生成并自测完毕然后转头问产品“需求确认了吗设计稿定了吗测试用例有了吗”这时候产品经理可能还在跟业务方对齐口径设计师还在纠结两个方案的视觉细节测试还没开始写用例。研发的“快”反而变成了对其他环节的“催”而这种催促往往带着一种“我这边都好了你们怎么还没好”的情绪很容易引发协作摩擦。我见过一个团队研发同学用大模型工具把某个功能的代码生成后自己觉得没问题就直接提交了合并请求结果产品经理一看发现交互逻辑跟最初讨论的完全不一样——因为研发在生成代码时根据工具的建议“顺手”优化了一些流程但这些优化并没有跟产品确认。这就是典型的工具加速了执行但没有加速对齐。2.2 代码生成质量的不确定性对评审的挑战大模型生成的代码有一个特点它看起来往往很合理但细节上可能藏着坑。比如边界条件处理、异常捕获、并发安全、资源释放这些地方工具生成的代码有时候会“想当然”而人工评审如果只看主流程很容易漏掉这些问题。以前研发自己写的代码评审时大家会习惯性地追问“这里为什么这么写”“那个异常怎么处理的”因为知道是人写的人可能会犯错。但现在面对工具生成的代码评审者容易产生一种“工具应该不会错吧”的松懈心理反而让一些低级问题溜过去。更麻烦的是当研发说“这段代码是工具生成的”评审者有时候会不知道该怎么提意见——提了吧好像是在质疑工具不提吧又觉得不放心。这种心理上的微妙变化会让代码评审的质量打折扣。我个人的做法是不管代码是人写的还是工具生成的评审标准完全一致甚至对工具生成的代码要更严格因为工具不会像人一样在提交前反复自检它只是给出了一个“看起来对”的答案。2.3 需求理解偏差被工具“放大”的风险以前研发在写代码的过程中会不断遇到“这里到底要做什么”的疑问然后去问产品经理一来一回之间需求理解偏差会被逐步修正。但现在工具生成代码的速度太快研发可能还没来得及产生疑问代码就已经写完了。如果研发对需求的理解本身就有偏差工具会把这个偏差快速固化到代码里等到产品经理看到成品时已经是一个“跑偏但能跑”的东西返工成本反而更高。我印象很深的一次是产品经理说“用户下单后要有一个确认环节”研发理解成“弹窗确认”工具很快生成了弹窗组件和对应的逻辑。但产品经理实际想要的是“订单进入待确认状态由客服在后台确认”这两个理解差异巨大但因为代码生成太快研发没有在过程中跟产品确认直接做完了才被发现。这种问题在以前研发手写代码的时代反而更容易在早期被发现因为写得慢思考的时间就多。3. 产研协作流程需要做哪些具体调整3.1 需求对齐阶段把“写代码”的时间前移到“写清楚”既然写代码的时间被压缩了那省下来的时间应该花在哪里我的答案是花在需求对齐上。以前研发花三天写代码现在可能半天就搞定了那多出来的两天半应该有一部分用于跟产品经理、设计师把需求边界、异常流程、数据口径这些东西彻底聊清楚。具体怎么做我建议在需求评审之后增加一个“技术预研需求反述”的环节研发拿到需求后不急着让工具生成代码而是先用自己的话把需求复述一遍包括正常流程、异常流程、边界条件然后跟产品经理确认。这个过程可能只需要半小时但能避免后面大量的返工。另外产品经理在写需求文档时也要适应这种变化。以前需求文档可以写得相对粗一点因为研发会在实现过程中来问。现在研发可能直接拿着文档去喂工具文档里模糊的地方工具会“猜”而猜的结果不一定对。所以需求文档里的验收标准、异常处理、数据校验规则这些要写得比以前更细。我甚至见过一些团队产品经理开始用结构化的格式写需求比如用表格列出每个字段的校验规则、每个状态的流转条件这样研发直接把这个表格喂给工具生成的代码准确率会高很多。3.2 设计交付阶段从“静态稿”转向“可交互原型标注”设计师这边的影响也很大。以前设计师交付静态稿和标注研发照着实现中间有疑问再沟通。现在研发用工具生成UI代码的速度也很快但前提是设计稿要足够规范、足够结构化。如果设计稿里有很多“这里大概这样”“那里看着办”的地方工具生成的代码就会很随意最后还是要人工大改。我的建议是设计师尽量交付可交互的高保真原型并且把组件状态、响应式规则、动效参数这些标注清楚。比如一个按钮正常态、悬停态、点击态、禁用态分别是什么样式这些如果标注清楚工具生成的代码基本可以直接用。如果设计师只给一张静态图研发就要花大量时间去猜各种状态反而抵消了工具带来的效率提升。还有一个容易被忽略的点设计师和研发要提前对齐组件库和设计规范。如果团队有统一的组件库研发可以把组件库的文档和示例代码一起喂给工具这样生成的代码会直接引用现有组件而不是重新造轮子。我见过一个团队因为设计稿里用了一些自定义组件但研发用工具生成时工具不知道有这些组件结果生成了一堆重复代码后来人工替换成组件库的组件花的时间比手写还多。3.3 开发实现阶段工具生成人工精修的工作流研发这边的工作流需要重新定义。我的经验是不要让工具从头到尾生成整个模块而是让它生成“骨架”和“重复性代码”人工负责“核心逻辑”和“边界处理”。比如一个CRUD接口工具可以快速生成Controller、Service、DAO层的模板代码包括基本的参数校验和返回结构但具体的业务规则、事务边界、并发控制这些还是要人工来写。这样既能享受工具的速度又能保证关键部分的可靠性。具体操作上我习惯把任务拆成几个层次第一层是数据结构和接口定义这部分让工具根据需求文档生成人工审核第二层是主流程逻辑工具生成初版人工逐行检查并补充异常处理第三层是边界条件和特殊场景这部分基本人工手写因为工具往往考虑不全。每完成一层就跟产品经理同步一次确保方向没跑偏。这样虽然看起来步骤多了但因为每层都很快总体时间反而比一次性生成再大改要短。还有一个实操技巧给工具提供足够的上下文。比如把相关的实体类、工具类、配置文件一起放进对话里让工具知道项目里已经有哪些东西可以用这样生成的代码会更贴合项目实际而不是引入一堆新的依赖。我试过只给工具一个方法名让它生成结果它引入了一个项目里根本没用的第三方库后来把pom文件也喂进去它就老老实实用现有的工具类了。3.4 测试验证阶段测试左移与自动化用例生成测试环节是很多团队容易忽略的。研发用工具快速生成代码后如果测试还按以前的节奏来就会变成新的瓶颈。我的做法是让测试尽早介入甚至在需求评审阶段就开始写测试用例。因为需求文档写细了之后测试用例其实可以跟需求文档同步产出。研发代码生成后测试用例也差不多准备好了可以直接跑。另外大模型工具本身也可以用来生成单元测试和集成测试的代码。我经常让工具根据业务代码生成对应的测试用例包括正常场景、异常场景、边界场景然后人工补充一些工具没想到的场景。这样测试覆盖率能快速提升而且测试代码的维护成本也降低了。不过要注意工具生成的测试用例有时候会“为了通过而通过”比如把断言写得很宽松或者漏掉一些关键校验所以人工审核测试代码同样重要。还有一个坑如果研发和测试对“完成”的定义不一致很容易出现研发说“我这边工具生成完自测通过了”测试说“我这边用例还没跑完”。所以团队要统一“完成”的标准比如代码评审通过、单元测试覆盖率达标、集成测试通过、产品经理验收通过才算真正完成。这个标准要在每个需求开始前就对齐避免后期扯皮。4. 角色边界与能力要求的重新定义4.1 研发从“写代码的人”变成“代码质量守门人”研发的核心能力正在从“能写代码”转向“能判断代码好不好”。以前衡量一个研发的水平很大程度看他写代码的速度和代码质量。现在写代码的速度被工具拉平了判断代码质量的能力反而成了分水岭。同样一段工具生成的代码有的研发能一眼看出里面的并发问题、资源泄漏、边界遗漏有的研发觉得“能跑就行”这两种人的产出质量差距会越来越大。所以研发需要刻意训练自己的代码评审能力、调试能力和架构设计能力。具体来说我建议研发在拿到工具生成的代码后至少做三件事第一逐行读一遍理解每一行的意图不理解的就去查第二构造一些边界输入看代码的行为是否符合预期第三检查异常处理和资源释放确保没有遗漏。这三件事花不了太多时间但能拦住大部分低级问题。另外研发对业务的理解也要比以前更深。因为工具不懂业务它只能根据你给的信息生成代码如果你对业务的理解有偏差工具就会把偏差放大。所以研发要主动参与需求讨论多问“为什么做这个”“用户会怎么用”而不是只关心“怎么做”。4.2 产品经理从“写文档的人”变成“逻辑闭环设计者”产品经理的挑战可能更大。以前产品经理写需求文档可以留一些模糊地带让研发在实现时自己判断。现在研发拿着文档去喂工具模糊地带会被工具“猜”猜错了就是返工。所以产品经理要把需求想得更透把每个流程的每个分支都考虑到把每个字段的每个校验规则都写清楚。这其实对产品经理的逻辑能力提出了更高要求。我认识一个产品经理以前写需求文档就是几段文字加几张图现在她开始用流程图和状态机来描述需求每个状态之间的流转条件、每个操作的输入输出、每个异常的处理方式都列得清清楚楚。她说这样虽然写文档的时间变长了但后面跟研发扯皮的时间大大减少总体反而更省时间。而且她发现用这种结构化的方式写需求自己也能更容易发现逻辑漏洞。另外产品经理要更主动地参与验收。以前研发写完代码产品经理可能等测试跑完再验收。现在研发代码生成得快产品经理可以在研发自测阶段就介入看看做出来的东西是不是自己想要的有问题尽早提避免等到测试阶段才发现方向错了。4.3 设计师从“画图的人”变成“交互规则制定者”设计师的角色也在变化。以前设计师的核心产出是视觉稿现在视觉稿的价值在下降因为工具可以根据设计规范快速生成UI代码。设计师的价值更多体现在交互规则的定义和设计系统的维护上。比如一个复杂的表单设计师要定义清楚每个字段的输入类型、校验规则、错误提示方式、联动逻辑这些规则定义得越清楚工具生成的代码就越准确。我建议设计师多花时间在设计系统的建设上把常用的组件、颜色、字体、间距、动效都标准化并且提供对应的代码示例。这样研发用工具生成UI时可以直接引用设计系统里的组件保证视觉一致性。另外设计师也要学一点前端知识至少能看懂生成的代码是不是符合设计意图这样跟研发沟通时会更顺畅。4.4 测试从“找bug的人”变成“质量策略设计者”测试的角色也在升级。以前测试的主要工作是手动点页面、写测试用例、跑回归。现在研发代码生成快了测试如果还靠手动根本跟不上节奏。所以测试要更多地把精力放在质量策略的设计上哪些场景必须自动化、哪些场景需要人工探索、哪些指标可以衡量质量、如何用工具生成测试用例、如何分析测试结果。这些工作比手动点页面更有价值也更难被工具替代。我见过一个测试同学她开始用工具根据需求文档生成测试用例然后人工补充一些工具没想到的异常场景再用工具生成自动化测试脚本。这样她的测试覆盖率比以前高了很多而且回归测试的时间从一天缩短到一小时。她说现在她的核心工作不是“找bug”而是“设计能发现bug的测试策略”。5. 实操中遇到的典型问题与排查技巧5.1 工具生成的代码“看起来对但跑不通”怎么办这是最常见的问题。工具生成的代码往往在语法上没问题但运行时可能报错原因通常是依赖的类或方法不存在、配置项没设置、数据库表结构不匹配、环境变量缺失等。我的排查思路是先看报错信息定位到具体的类和行号然后检查这个类或方法在项目里是否存在、签名是否一致、依赖是否注入。如果工具引入了一个项目里没有的第三方库要么手动替换成现有的工具类要么评估是否值得引入这个库。还有一个技巧在让工具生成代码之前先把项目的依赖清单、配置文件、核心工具类一起喂给它让它知道项目里有什么。这样生成的代码会更贴合项目实际减少“跑不通”的情况。我试过把pom文件和几个核心工具类的代码一起放进对话工具生成的代码直接就能编译通过省了很多排查时间。5.2 多人协作时工具生成代码风格不一致如果团队里多个人都在用工具生成代码很容易出现风格不一致的问题有人用工具生成的代码用了A方案有人用了B方案最后合并时冲突不断。解决这个问题的关键是统一工具的使用规范和代码风格。比如团队可以约定工具生成的代码必须经过统一的格式化工具处理、必须遵循项目的命名规范、必须使用项目已有的工具类和组件库。还可以把项目的代码规范文档和示例代码作为工具的系统提示让工具按照统一风格生成。另外代码评审时要特别关注风格一致性。如果发现有人提交的代码风格跟项目不一致要及时指出并修正避免风格问题积累。我见过一个团队因为前期没注意这个问题后来代码库里出现了三种不同的HTTP请求写法维护起来非常头疼。5.3 需求变更时工具生成的代码如何快速调整需求变更是常态工具生成的代码在需求变更时调整起来有时候比手写代码还麻烦因为工具生成的代码可能结构比较固定改起来牵一发而动全身。我的经验是在让工具生成代码时尽量把可变的部分抽成配置或参数把不变的部分写成通用逻辑。这样需求变更时只需要改配置或参数不用动核心代码。比如一个列表查询接口工具生成的代码可能把查询条件硬编码在方法里。我会让工具把查询条件抽成一个DTO然后在Service层根据DTO动态组装查询条件。这样需求变更时只需要改DTO的字段和组装逻辑不用重写整个方法。另外如果需求变更比较大与其在工具生成的代码上修修补补不如重新生成一版然后对比两版代码取长补短。有时候重新生成比修改更快。5.4 常见问题速查表问题现象可能原因排查思路预防措施代码编译不通过依赖缺失、签名不一致检查报错行涉及的类和依赖生成前提供项目依赖清单运行时空指针工具未处理边界条件检查入参校验和空值处理人工补充边界处理逻辑性能不达标工具生成的算法效率低分析慢查询或循环嵌套核心逻辑人工重写风格不一致多人使用不同提示词对比代码格式和命名统一工具使用规范需求理解偏差需求文档模糊对照验收标准逐条检查需求反述早期验收测试覆盖不足工具生成的测试太宽松检查断言和场景覆盖人工补充异常场景6. 我踩过的坑和总结出的几条实操心得第一个坑是过度依赖工具生成完整模块。我曾经让工具根据需求文档直接生成一个完整的订单模块包括实体、DAO、Service、Controller生成出来的代码看起来结构很完整但实际跑起来发现事务边界不对、并发场景下会超卖、异常处理几乎为零。后来我改成只让工具生成实体和基础CRUD核心的下单逻辑、库存扣减、事务控制全部人工写问题就少了很多。所以我的心得是工具适合生成“结构”不适合生成“逻辑”逻辑部分一定要人工把关。第二个坑是忽略了工具生成代码的评审。有一次团队里一个研发用工具生成了一个工具类直接提交了合并请求评审时大家看代码不长又是工具生成的就草草通过了。结果上线后发现这个工具类在处理特殊字符时会抛异常导致一个边缘功能不可用。后来我们定了个规矩不管代码是谁写的、怎么来的评审标准一视同仁工具生成的代码要重点看边界和异常。第三个坑是没有及时同步进度。研发用工具快速生成代码后如果没有及时跟产品经理和测试同步他们可能还在按原来的节奏工作导致最后集成时发现方向不对。我的做法是每完成一个可验证的小模块就在群里同步一下附上截图或录屏让产品经理和测试知道进展有问题尽早提。这个习惯看起来简单但能避免很多后期返工。第四个坑是工具生成的代码没有注释。工具生成的代码往往缺少注释尤其是业务逻辑部分过一段时间连作者自己都看不懂为什么这么写。所以我现在要求团队工具生成的代码必须补充关键注释说明业务意图和边界条件否则不予合并。注释不用多但关键的地方一定要有。最后分享一个小技巧把常用的提示词模板化。比如“根据以下需求生成Java接口代码要求使用项目现有的Result包装类、参数校验用注解、异常统一抛出自定义异常、补充Swagger注解”这样的提示词模板可以复用保证每次生成的代码风格一致。团队可以维护一个提示词库新人直接拿来用减少风格差异。产研协作这件事工具变了流程就得跟着变。工具把写代码的速度提上来了省下来的时间不能浪费在等待和扯皮上而要花在对齐、评审和验证上。谁先适应这个变化谁就能在同样的时间里做出更靠谱的东西。
阅读完成 · 觉得有帮助？
