现在，写代码很便宜¶
原文标题：Writing code is cheap now 原文链接：https://simonwillison.net/guides/agentic-engineering-patterns/code-is-cheap/ 原文作者：Simon Willison 访问日期：2026-03-25 原文发布日期：2026-02-23 原文最后修改：2026-02-24 译文版本：v0.1
译文说明¶
本文为 Simon Willison《Agentic Engineering Patterns》系列 1.2 篇《Writing code is cheap now》的示范中文版。本文沿用本项目既定术语约定，将 Agentic Engineering 统一译为“智能体工程（Agentic Engineering）”，将 Coding Agent 统一译为“编码智能体”。本文标题中的“cheap”保留原文的冲击力，译为“便宜”，但正文语义应理解为“代码生成与编写成本显著下降”，而不是“代码质量低”。
正文¶
采纳智能体工程实践时，最大的挑战，是你得逐渐适应这样一个事实：现在，写代码很便宜。
代码一直都是昂贵的。对大多数软件开发者来说，要产出几百行干净、经过测试的代码，往往需要整整一天，甚至更久。我们许多工程习惯——无论是宏观层面还是微观层面——都是围绕这一条核心约束建立起来的。
在宏观层面，我们会花大量时间做设计、评估和规划项目，以确保那段昂贵的编码时间被尽可能高效地使用。一个产品功能值不值得做，常常要看它能否为这段投入的时间带来足够高的回报——一个功能必须反复“赚回”它的开发成本，才算值得。
在微观层面，我们每天都会基于可用时间和预期权衡，做出几百个决定。我要不要多花一个小时，把那个函数重构得更优雅一点？文档要不要写？这个边界情况值不值得补一条测试？我有没有理由专门为此做一个调试界面？
编码智能体大幅拉低了“把代码敲进电脑里”这件事的成本，这打乱了我们过去大量关于“怎样的权衡才合理”的个人直觉与组织直觉。
而并行运行多个智能体的能力，又让这件事更难判断了：现在，一个人类工程师可以同时在多个地方实现、重构、测试和编写文档。
好代码依然有成本¶
交付一段新代码的价格，已经下降到了接近零的程度……但交付一段好代码的成本，仍然远高于此。
我所说的“好代码”，是指下面这些：
- 代码能工作。它完成自己该完成的事情，而且没有 bug。
- 我们知道这段代码能工作。我们已经采取了措施，让自己和其他人都能确认它确实适用。
- 它解决的是正确的问题。
- 它能够以优雅而且可预测的方式处理错误情况：它考虑的不只是 happy path（理想执行路径）。错误信息也应该提供足够线索，帮助未来的维护者理解到底哪里出了问题。
- 它简单、克制，而且最小化——只做必要的事情，并且以一种无论人还是机器现在都能理解、未来也能维护的方式来实现。
- 它受到测试保护。测试不仅能证明它现在能工作，也能作为回归测试集，避免它在未来悄悄坏掉。
- 它有恰到好处的文档，而且文档反映的是系统当前的真实状态——如果代码改掉了已有行为，那么现有文档也应同步更新。
- 它的设计为未来变更留出了空间。保持 YAGNI 很重要——为了预判那些也许永远不会发生的未来变化而增加复杂度，通常会把代码写坏；但同样重要的是，也不要把代码写成让未来变更比应有的难度高出很多。
- 它还具备其他相关的各种 “-ility” 属性：可访问性(Accessibility)、可测试性(Testability)、可靠性(Reliability)、安全性(Security)、可维护性(Maintainability)、可观测性(Observability)、可扩展性(Scalability)、可用性(Availability)——也就是那些对当前这类软件来说真正重要的非功能性质量指标。
编码智能体工具可以在其中大多数方面提供帮助，但真正驱动这些工具的开发者，依然要承担相当重的责任：确保最终产出的代码，至少在当前项目所需要的那部分维度上，称得上是“好代码”。
我们需要建立新的习惯¶
真正的挑战，是要形成一套新的个人习惯与组织习惯，去响应智能体工程所带来的新能力与新机会。
整个行业都还在摸索这些最佳实践。我自己也还在摸索。
眼下我觉得，我们能做的最好的一件事，就是多反过来怀疑一下自己：每当你的直觉告诉你“别做了，不值得花这个时间”，不如还是先发一个 Prompt 过去，让它在一个异步智能体会话里跑起来。最糟糕的情况，也不过是十分钟后你回来一看，发现这件事确实不值得那些 Token 而已。