写代码变便宜了，智能体工程怎么玩

采用智能体工程（Agentic Engineering）实践的最大挑战，是适应一个事实带来的后果：写代码现在变便宜了。

代码一直很贵。大多数软件开发者要花一整天甚至更久，才能产出几百行干净、测试过的代码。我们的工程习惯，无论宏观还是微观层面，都建立在这个核心约束之上。

宏观上，我们花大量时间设计、评估和规划项目，确保宝贵的编码时间用得尽可能高效。产品功能点子会按「投入时间能换回多少价值」来评估——一个功能必须数倍赚回开发成本才值得做。

微观上，我们每天做几百个决策，都基于可用时间和预期权衡：重构这个函数让它更优雅，但要多花一小时编码时间，值吗？写文档呢？给这个边界情况加测试值得吗？为这个功能建个调试界面能说得过去吗？

编码智能体（Coding Agent）大幅降低了往电脑里敲代码的成本，这颠覆了我们个人和组织层面关于「哪些取舍合理」的现有直觉。

并行运行多个智能体的能力让评估更难，因为一个人类工程师现在可以同时在多个地方实现、重构、测试和编写文档。

好代码依然有成本

交付新代码的价格几乎降到免费……但交付好代码的成本依然远高于此。

我说的「好代码」指：

代码能工作。它做该做的事，没有 bug。
我们知道代码能工作。我们采取措施向自己和他人确认代码适合其用途。
它解决了正确的问题。
它优雅且可预测地处理错误情况：不只考虑理想路径。错误应提供足够信息，帮助未来的维护者理解哪里出了问题。
它简单且最小化——只做需要的事，以人类和机器都能理解、未来可维护的方式。
它有测试保护。测试证明它现在能工作，并作为回归测试套件，防止它未来悄悄坏掉。
它有适当层级的文档，且文档反映系统当前状态——如果代码改变了现有行为，现有文档需要相应更新。
设计允许未来变更。保持 YAGNI 很重要——为预期可能永不发生的未来变更增加复杂性的代码通常是坏代码——但同样重要的是，不要写出让未来变更变得异常困难的代码。
所有其他相关的「能力」——可访问性、可测试性、可靠性、安全性、可维护性、可观测性、可扩展性、可用性——适合所开发软件类别的非功能性质量指标。

编码智能体工具能帮助实现其中大部分，但驱动这些工具的开发者仍有相当负担，要确保产出的代码对当前项目所需的好代码子集而言是好的。

挑战在于发展新的个人和组织习惯，以响应智能体工程带来的可能性和机会。

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

目前我认为我们能做的最好方式是质疑自己：每当直觉说「别建那个，不值得花时间」时，无论如何发个提示（Prompt），在一个异步智能体会话中，最坏情况不过是十分钟后检查发现不值得花那些 token。