# 智能体工程模式 05：反模式——应该避免的做法

作者：Hex4C59 · 发布于 2026-10-11

原文：https://hex4c59.cc/translations/agentic-engineering-patterns-anti-patterns/


> **译文信息**
>
> - 原文：[Anti-patterns: things to avoid](https://simonwillison.net/guides/agentic-engineering-patterns/anti-patterns/)
> - 作者：Simon Willison
> - 中文翻译与整理：Hex4C59（AI 辅助）
> - 翻译整理：2026-10-11
>
> 本文为非官方中文译文，依据提供的原文正文翻译。正文中的「我」及相关判断和建议均指原作者。

智能体工程是个陌生而奇特的新领域，其中有些做法应该避免，通常称为「反模式」。

## 把未经审查的代码丢给协作者 {#inflicting-unreviewed-code-on-collaborators}

这种反模式很常见，也非常令人恼火。

**不要提交包含你自己尚未审查过的代码的拉取请求（Pull Request，PR）。**

如果你提交的 PR 包含智能体生成的几百行甚至几千行代码，而你自己没有花功夫确认它能正常工作，你就是把真正需要做的工作推给了别人。

他们完全可以自己给智能体发提示词。那你到底提供了什么价值？

把代码交给别人审查之前，你需要有把握：这份代码已经准备好，值得别人花时间审查。第一轮审查是你的责任，不应该甩给其他人。

一个好的智能体工程 PR 应该具备以下特点：

- 代码能正常工作，而且你对此有把握。[你的工作是交付能够正常工作的代码](https://simonwillison.net/2025/Dec/18/code-proven-to-work/)。
- 改动足够小，审查者不必花太多时间理解它，就能高效完成审查。几个小 PR 优于一个大 PR。有编程智能体帮你处理 Git 操作，把代码拆成几个独立提交也很容易。
- PR 提供了额外的背景，帮助别人理解改动。这项改动服务于什么更大的目标？附上相关问题（issue）或规格说明的链接，会很有帮助。
- 智能体会写出看起来很有说服力的 PR 说明，你也需要审查这些文字！让别人阅读你自己都没读过、没核实过的文字，是不尊重人的做法。

把未经审查的代码丢给别人实在太容易了，因此我建议附上一些证据，表明你已经亲自审查和验证过代码。手动测试的记录、对具体实现选择的说明，甚至功能运行时的截图和视频，都能*很有效地*让审查者相信：花时间深入了解这些细节，不会是白费功夫。