产品经理让Claude帮忙写好代码，为什么工程师反而觉得更累了？

产品经理愿意自己动手把想法变成可审查的代码改动，本来是件值得欢迎的事；工程师担心的是，省事和干活没发生在同一个人身上——如果交代码的人省掉了写清需求和自己验证的工夫，审代码的人就得从一堆 AI 生成的改动里倒推“这到底想解决什么问题”。

北京时间 10 月 28 日，Reddit 的 r/ClaudeAI 社区里一位开发者发帖讲了刚碰上的事：团队里的产品经理把需求交给 Claude，生成了一份 pull request（提交给团队审查的一份代码改动），随后又让 Claude 审了一遍，得到一句“没问题”，接着这份改动按规定流转到了人工审查环节。帖子很快冲上当日热门，攒下 461 个赞和 225 条回复。发帖人后来专门补了一句，发出来只是记录这桩事，没打算号召大家围攻这位产品经理。

审代码本来就是流程，多出来的是猜谜和挑废料的工时

在这家公司，所有 AI 生成的改动本来就有一套标准流程：先由 Claude 机器人扫一轮，再交给人工审查。以前开发者交代码走这套流程，如今产品经理和其他非技术岗位也开始交代码，走的暂时还是同一套流程，改动没有直接上线。既然人工审查本来就在那儿，审代码也是工程师的本职工作，为什么讨论里还是有这么多人担心隐形的审查工时转移？

把两笔时间账摆在一起算，别扭的地方就出来了。以前产品经理动嘴提需求，工程师从头写代码，前期沟通固然费劲，但写代码的人清楚每一处改动是冲着哪个目标去的。现在换成了直接交一份现成的改动上来，一旦提交人没把前因后果交代明白，审代码就成了猜谜——按讨论区里那句“half the review is guessing that”的苦水来说，碰上没写清要解决什么问题的改动，审代码时感觉有一半精力都耗在了猜意图上。

比猜意图更费眼睛的，是替模型删戏。一位有编程背景的产品经理在讨论里说，自己下场用模型，日常总得花力气拦住的也是复杂化：本来是个小改动，模型一发力就能长出一大堆代码和测试；要是提交前不先动手削减，审代码的人就得花时间看懂这些多余内容。更麻烦的是你只让模型做 X，它却顺手加上了 Y，塞进一堆事先没商量过的行为。就连多出来的测试也是笔糊涂账，发帖人自己倒不反对 AI 多写测试，可算过维护账的人心里清楚，不同测试的信息价值和后续维护成本差得老远。模型多生出一堆代码很轻松，连眉头都不用皱一下，可人类看懂它还得靠肉眼一行行扫。要是加出来的东西压根不服务于这次需求，提交人又不管削减，看懂它和替它兜底的工时就全挪到了审代码那一方的账上。

一刀切拦在门外，反而会把真能省事的原型挡掉

顺着这笔工时账看，也就能理解为什么反对派会觉得不痛快：在没有共同商量好的情况下，直接跨进别的岗位职责交代码，看起来就像把验收的麻烦往别人桌上一推；务实一点的质疑则把讨论拉回结果本身，追问“How was the change itself though?”（改动本身到底怎么样），以及这位产品经理交上来之前到底测没测过。

原帖正文没有交代这份具体改动的质量究竟如何，可要是顺着这股不满走到另一个极端，干脆把非技术岗位的提交权限一刀切封死，又会把真能省事的协作方式一并砍掉。在欢迎甚至已经适应这种新分工的团队里，这套模式有的已经跑了好几个月，连审代码这一环都会拿 Claude 搭把手。撑起这种顺畅协作的，是团队提前铺好的验证条件：项目里测试和贡献说明齐备时，产品经理和开发者一样能用 Claude 改完代码，并把应用在本地跑起来；团队建好部署测试流程后，产品经理也清楚要去哪里点、验证什么结果。在这种前提下，不写代码的架构岗位可以先搭出原型交由开发者打磨，也有团队靠非技术同事先做出可运行的原型，顺手清掉了那些常年排不上优先级的边角小改动。

同样是跨岗位交 AI 代码，顺畅的团队拿它清掉了陈年积压，发愁的团队却担心要替别人收拾残局。分水岭就卡在交活的那一刻，看递过来的是一份自己跑过、点过、能演示的改动，还是一份只靠 AI 拍胸脯说“没问题”的生代码。

交代码的人把意图和验证交代清楚，审代码的人只把风险关

当团队里交代码的人不再只是工程师，原有的审查流程面对的是背景各异的同事，“怎样才算交完活”的标准就得摆到明面上重定一回。

指望产品经理把每一行底层代码怎么运作讲得清清楚楚，既不现实，也没必要——真能做到那一步，直接转岗写代码就完了，犯不着多此一举。但放开提交入口的前提，是交代码的人得替自己的改动做第一道验收，至少在提交时把三件事交代明白：第一，这次改动到底要解决什么具体问题，别让审代码的人先猜半天需求；第二，改动跑起来是什么效果，自己已经在本地或部署测试流程里点过哪些地方、验证了什么结果；第三，模型顺手多塞进来的额外行为和多余代码，提交前先削减干净，只留服务于这次需求的部分。

把这三样东西交齐了，工程师再去接手审查，工时才是花在刀刃上：用 AI 辅助通读代码，集中精力看住关键风险、核对改动范围，检查会不会把原来好好的功能碰坏。产品经理带着自己验证过、能跑通的改动来提申请，确实能帮团队省掉来回对齐口头需求的工夫，顺手把排不上队的小修小补解决掉；要是连改了什么、验没验过都指望工程师在审代码时从头摸索，那省下的就只是提交人自己的时间，还不如老老实实写一份清楚的需求文档。