# 智能体工程模式 02：如今，编写代码的成本已经很低

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

原文：https://hex4c59.cc/translations/agentic-engineering-patterns-code-is-cheap/


> **译文信息**
>
> - 原文：[Writing code is cheap now](https://simonwillison.net/guides/agentic-engineering-patterns/code-is-cheap/)
> - 作者：Simon Willison
> - 中文翻译与整理：Hex4C59（AI 辅助）
> - 翻译整理：2026-10-11
>
> 本文为非官方中文译文，依据提供的原文正文翻译。正文中的「我」及成本、质量和实践方面的判断均指原作者。

采用智能体工程实践，最大的挑战是适应这样一个事实及其带来的影响：*如今，编写代码的成本已经很低*。

过去，编写代码一直很昂贵。对大多数软件开发者而言，写出几百行整洁、经过测试的代码，需要一整天，甚至更长时间。从项目规划到日常开发，我们的许多工程习惯都围绕着这一时间限制形成。

在宏观层面，我们花大量时间设计项目、估算工作量和制定计划，以确保昂贵的编码时间得到尽可能高效的利用。评估产品功能构想时，我们会考虑它们能用*这些时间换来多少价值*。一项功能带来的回报必须达到开发成本的许多倍，才值得投入！

在日常开发中，我们每天都会权衡可用时间与预期收益，做出数百个决定。如果把一个函数重构得更优雅一些，需要多花一小时写代码，我该不该做？编写文档呢？值得为这个边界情况增加一个测试吗？专门为此构建一个调试界面，能说得过去吗？

编程智能体大幅降低了编写代码的成本，也因此动摇了我们个人和组织对*许多*取舍是否合理的既有直觉。

能够并行运行多个智能体，让这些取舍更难评估：如今，一名工程师可以同时在多处实现功能、重构、测试和编写文档。

## 好代码仍然有成本

交付新代码的成本已经降到几乎为零……但交付*好*代码，仍然要付出高得多的成本。

我所说的「好代码」，指的是：

- 代码能正常工作。它能完成预定的任务，没有缺陷。
- 我们*知道代码能正常工作*。我们已经采取措施，向自己和他人确认它确实能满足用途。
- 它解决的是正确的问题。
- 它能妥善处理错误情况，而且处理方式可以预期，不能只考虑一切顺利的情况。错误信息应该足够充分，帮助未来的维护者理解哪里出了问题。
- 它简单、精简，只做必要的事情。它的写法既能让人和机器理解，也便于今后维护。
- 它有测试保护。测试既证明它现在能正常工作，也能在后续修改时检查原有功能是否仍然正常，防止问题悄悄出现；后者就是回归测试。
- 它有详略适当的文档，而且文档反映系统的当前状态。如果代码改变了已有行为，现有文档也需要同步更新。
- 它的设计为未来修改留有余地。遵守 [YAGNI（You Aren’t Gonna Need It，你不会需要它）](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)原则很重要：为了预先应对可能永远不会发生的变化而增加复杂度，往往会写出糟糕的代码。但同样重要的是，不要让未来的修改变得比本来应有的难度高得多。
- 它还满足其他相关的质量属性，例如无障碍性、可测试性、可靠性、安全性、可维护性、可观测性、可扩展性和易用性。这些都是非功能性的质量指标，需要根据所开发的软件类型来确定要求。

编程智能体工具可以帮助我们完成其中的大部分工作，但使用这些工具的开发者仍然承担着不小的责任：确保生成的代码满足当前项目所需的那些「好代码」标准。

## 我们需要养成新的习惯

我们面临的挑战，是在个人和组织层面养成新的习惯，适应智能体工程提供的能力和机会。

整个行业仍在摸索这些最佳实践，我自己也还在摸索。

目前，我认为我们能做的最好尝试，就是重新审视自己的直觉：每当本能告诉我们「别做这个，不值得花时间」时，不妨还是在一个异步智能体会话中发出提示词。最坏的结果，也不过是十分钟后回来查看，发现这次尝试不值得花那些 Token。