反模式：有些事要避免¶

原文标题：Anti-patterns: things to avoid 原文链接：https://simonwillison.net/guides/agentic-engineering-patterns/anti-patterns/ 原文作者：Simon Willison 访问日期：2026-03-25 原文发布日期：2026-03-04 原文最后修改：2026-03-04 译文版本：v0.1

译文说明¶

本文为 Simon Willison《Agentic Engineering Patterns》系列 1.5 篇《Anti-patterns: things to avoid》的示范中文版。本文沿用本项目既定术语约定，将 Agentic Engineering 统一译为“智能体工程（Agentic Engineering）”，将 Coding Agent 统一译为“编码智能体”，将 anti-pattern 统一处理为“反模式”。标题中的 things to avoid 译为“有些事要避免”，保留原文那种明确提醒读者“这些做法不要碰”的警示语气。

正文¶

所属主题：核心原则上一篇：AI 应该帮助我们产出更好的代码下一篇：编码智能体如何工作

在这个多少有点古怪的智能体工程新世界里，有些行为就是典型的反模式。

把未经审查的代码硬塞给协作者¶

这种反模式很常见，而且非常让人抓狂。

不要提交那些你自己都还没审查过的 Pull Request。

如果你开了一个 PR，里面有几百行、甚至几千行由智能体替你产出的代码，而你自己并没有先确认这些代码真的能工作，那你其实是在把真正的工作甩给别人。

别人自己也可以去 Prompt 一个智能体。那你到底提供了什么价值？

如果你把代码挂出来让别人审查，你就应该有把握：这份代码已经准备好了，值得别人花时间来看。第一轮审查是你的责任，不是你应该外包给别人的事情。

一份好的智能体工程 Pull Request，应当具备下面这些特征：

代码是能工作的，而且你自己对这一点有把握。你的职责是交付能工作的代码。
变更要足够小，审查起来才会高效，不至于额外把太多认知负担压到审查者身上。与其来一个巨大的 PR，不如拆成几个小 PR；而有了编码智能体，要让它替你处理那些 Git 层面的细碎操作，把代码拆成多个 commit，其实很容易。
PR 里要补充额外上下文，帮助别人理解这次变更。它服务的更高层目标是什么？这里如果能链接相关 issue 或 specification，会很有帮助。
智能体很会写那种看起来挺像回事的 Pull Request 描述。但这些文字你也得自己审！指望别人去读一段你自己都没读过、没验证过的说明，是很不礼貌的。

考虑到如今把未经审查的代码一股脑丢给别人实在太容易了，我建议你最好附上一些证据，证明你自己确实多做了那一步。比如写下你是怎么手动测试它的，解释若干具体实现选择，甚至直接附上这个功能正常工作的截图和视频。这些材料都非常能说明问题：它们能让审查者相信，自己花的时间不会白费，不需要再从最底层细节开始替你兜底。