20260410-anti-patterns
编译摘要
1. 浓缩
- 核心结论1: AI 编程时代最危险的协作反模式，不是让 Agent 写代码，而是把自己没有审查、没有验证、没有理解的 Agent 产物交给别人审查。
- 关键证据: Simon Willison 的判断是：别人也可以让 Agent 生成代码。如果提交者没有先确认代码能运行、PR 目标清楚、描述可信，那么他提供的不是价值，而是把真正工作转嫁给审查者。
- 核心结论2: Agent 生成 PR 的最低质量线必须比普通 PR 更显式，因为生成成本下降会把审查成本推给团队。
- 关键证据: 好 PR 至少需要四件事：代码能运行；改动足够小；提供更高层目标、issue 或规格说明；审查 Agent 生成的 PR 描述。尤其是 PR 描述本身也可能是流畅但不可靠的输出。
- 核心结论3: AI PR 的责任边界应从“我让 Agent 做了”上移到“我能证明这值得你审查”。
- 关键证据: 作者建议提供手动测试笔记、实现选择说明、截图或视频。这些证据的作用不是装饰，而是证明提交者已经支付了初审成本，让协作者不用从零开始排雷。
2. 质疑
- 关于“代码能运行”的质疑: 原文强调提交者要有信心，但没有给出可操作门槛。生产环境里应把“能运行”拆成测试通过、手动验收、回归范围、权限/数据边界、UI 截图等可验证证据。
- 关于“小 PR”的质疑: 小 PR 可以降低认知负担，但过度拆分也会隐藏整体设计错误。更好的标准不是行数，而是每个 PR 是否有单一目的、独立验证路径和清晰回滚边界。
- 关于“初审责任”的质疑: 这条规则要求开发者具备审查能力。对初级开发者或非工程角色来说，Agent 可能生成超出其理解能力的代码；此时需要 harness、模板、CI 和 reviewer 分层，而不能只靠个人自觉。
- 关于证据可靠性的质疑: 截图、视频和测试笔记也可能由 Agent 生成或选择性展示。团队应鼓励可复现命令、CI 链接、测试数据和预览环境，而不是只接受静态证明。
3. 对标
- 代码审查对标学术审稿: 作者不能把未校对稿件扔给审稿人；开发者也不能把未验证 Agent 代码扔给 reviewer。AI 降低了生成成本，但没有降低作者责任。
- PR 证据对标实验记录: 好的 Agent PR 应像实验报告一样有可复现证据：做了什么、为什么这样做、如何验证、哪里可能失败。
- 迁移到非代码工作: 这条反模式同样适用于 AI 生成报告、设计稿、数据分析和法律草案。使用者的价值不在“让 AI 产出”，而在先完成初审、校验和责任承担。
- 与 Agentic Engineering 的关系: 这篇文章给 Agentic-Engineering 补了一条伦理与流程底线：Agent 可以加速实现，但不能让人类把理解和验收责任外包给协作者。
- 可执行门槛: 可以把本文转化为 PR 模板门禁：验证命令、手动测试说明、截图/录屏、风险说明、Agent 生成描述已人工审查。这样责任不再停留在道德提醒，而变成审查前置条件，也便于团队在事后复盘哪些证据真正降低了 reviewer 成本。
关联概念