← 返回首页

AI写代码快了60%，但没人想到审查会崩盘|pr|上下文|代码|工作流_手机网易网网易网易号

AI写代码快了60%，但没人想到审查会崩盘

字节漫游指南

2026-05-16 03:50 ·北京

0

周三下午，一个全栈工程师刚用AI助手生成了400行新功能代码。提交PR，@同事，然后等待。4天后，第一条评论终于出现："这个函数命名不太对，另外第三块逻辑能拆一下吗？"他盯着屏幕，花了20分钟才想起自己当时为什么这么写。

这不是段子。CircleCI统计了2800万次CI工作流运行，发现工程师的代码产出同比增长约60%，功能分支吞吐量飙升59%，创下有记录以来最大增幅。但审查容量完全没动——还是一个人、一个PR、在会议和事故之间挤时间看。

打开网易新闻查看精彩图片

中位PR周期时间是4.2天。这个数字在AI加速之前就已经很难看，现在成了系统性瓶颈。

打开网易新闻查看精彩图片

停滞的代价在滚雪球

等审查不是闲着的优雅。开发者会开新任务，在制品堆积，上下文切换激增。2025-2026年的研究显示，普通开发者每天经历12到15次重大上下文切换，损失超过4.5小时的深度专注时间。

等反馈终于来了，作者的心思早飘到别处。重新加载上下文，改完，循环重启。有研究指出，开发者平均等4天才能拿到PR审查，期间往往已经切到完全不同的任务。

质量问题也在恶化。CodeRabbit的研究发现，AI生成的代码暴露的问题是人类代码的1.7倍。审查者现在不止要查正确性，还要判断必要性、架构契合度、长期可维护性——每份PR耗费的认知劳动反而增加了。

高绩效团队在改什么

这不是加个机器人就能解决的工具问题，是流程设计问题。一些团队的做法值得参考：

默认小PR。数据一致显示，超过400行后审查质量断崖下跌。堆叠式PR或原子化变更让diff保持在可读范围。

打开网易新闻查看精彩图片

固定审查时段。不搞随机打断，而是专门划出几小时集中处理。所有人的上下文切换都减少了。

AI辅助初筛。用AI过一遍lint、安全检查、常见模式，让人类审查者专注架构决策和业务逻辑等高判断类工作。Code Board这类工具提供自动化AI审查，能学习项目特定模式，减轻初筛负担。

在制品限制。如果一名开发者有3个未审查PR悬着，他同时扛着3份心理上下文，哪份都处理不好。限制WIP强制团队先清队列再生产新代码。

把审查时间当核心指标。追踪"首次审查时间"并设定团队约定（很多团队目标定在4小时内）的，表现系统性地优于不追踪的。

真正的分水岭

2026年交付最快的组织，不会是代码生成最快的那些。胜出者会是重新设计了审查流程、让高频率协作能跟上高频率产出的团队。AI改变了代码的生产速度，但代码的价值只在合并后才真正释放——这条旧规则没变。

特别声明：本文为网易自媒体平台“网易号”作者上传并发布，仅代表该作者观点。网易仅提供信息发布平台。

打开网易新闻体验更佳

热搜

热门跟贴

打开APP发贴

相关推荐

回到顶部回到首页