反模式——应该避免的做法

译文信息

• 原文：Anti-patterns: things to avoid
• 作者：Simon Willison
• 中文翻译与整理：Hex4C59（AI 辅助）
• 翻译整理：2026-10-11

本文为非官方中文译文，依据提供的原文正文翻译。正文中的「我」及相关判断和建议均指原作者。

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

把未经审查的代码丢给协作者 #

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

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

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

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

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

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

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

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