如何在收到Pull Request时尽早防范AI Workslop问题？

背景 #

AI Workslop是企业开发团队中日益凸显的问题：部分开发者过度依赖AI生成代码，却不对产出做充分自检，把代码验证的工作全部推给Pull Request（PR）评审人员。

带来的影响 #

• PR评审人员被迫耗费大量时间，替同事完成本该由他们自己承担的代码检查工作
• 若这类未验证PR的提交频率过高，评审人员可能会因疲惫而放弃认真评审，开始快速批准PR
• 更棘手的情况是开发者阶段性懈怠：仅部分AI生成代码未做检查，导致应用中部分模块存在缺陷，其余模块却正常运行
  最终结果是团队成员间的信任被破坏，所有人都要额外增加检查他人工作的负担，或者干脆也放弃检查，引发更多代码质量隐患

防范实践方案 #

作为同级协作的开发团队，可从以下几个方向入手防范AI Workslop：

1. PR前置自动化检测 #

通过工具提前拦截有明显问题的PR：

• 配置CI/CD流水线，自动检查PR中是否包含与当前任务无关的文件变更，比如修改了不属于需求范围内的模块代码
• 引入代码质量扫描工具，检测AI生成代码常见的问题，比如逻辑漏洞、冗余代码、不符合团队编码规范的内容
• 强制要求PR关联对应的需求/任务ID，确保提交的代码都有明确的业务背景，避免无意义的AI生成内容混入

2. 明确测试用例提交要求 #

要求开发者在PR中附带手动编写的核心测试用例：

• 针对AI生成的核心业务逻辑，必须提交手动设计的测试场景（而非AI生成的通用测试用例），验证代码是否符合业务需求
• 团队可约定：没有对应有效测试用例的PR，评审人员直接打回，不进入正式评审流程
• 定期抽查测试用例的有效性，避免开发者敷衍提交无效内容

3. 其他补充措施 #

• 建立代码归属机制：每个模块明确负责人，PR涉及对应模块时，负责人需重点校验代码逻辑的合理性，避免评审流于形式
• 团队规范对齐：定期召开会议，针对出现的AI Workslop案例公开讨论，明确AI工具的使用规范——比如AI生成的代码必须经过本地调试、自测后才能提交PR
• 强化Pull Master职责：如果团队设有Pull Master角色，可让其承担PR前置校验职责，先过滤掉明显未自检的PR，再进入正式评审环节
• 轮换评审人员：定期轮换PR评审人员，避免固定评审者因疲劳放松标准，同时也能提升团队整体的代码质量把控能力

内容的提问来源于stack exchange，提问作者Marc Le Bihan