在采纳“智能体化工程实践”（Agentic Engineering Practices）的过程中，最大的挑战在于：我们必须学会接受一个事实——编写代码现在已经变得非常廉价。
长期以来，代码一直都是昂贵的资产。对于大多数软件开发人员来说，产出几百行干净、经过测试的代码通常需要一整天甚至更久。我们不论是在宏观还是微观层面的许多工程习惯，都是围绕这一核心约束而建立的。
在宏观层面： 我们投入大量时间进行设计、估算和项目规划，以确保昂贵的开发时间能被最有效地利用。产品功能的优先级评估，本质上是在衡量其产出价值是否值得投入相应的开发时间——一个功能必须能赚回其开发成本的数倍，才会被认为是值得做的。
在微观层面： 我们每天都会基于可用时间和预期的折衷方案做出数百个决策。如果重构某个函数使其更优雅需要多花一个小时，我该做吗？文档要写吗？为这个边缘案例增加测试值得吗？我有理由为这个功能开发一个调试接口吗？
编程智能体（Coding Agents）极大地降低了向计算机输入代码的成本。这颠覆了我们个人和组织对于“权衡取舍”的既有直觉。
随着并行运行多个智能体成为可能，评估成本变得更加困难。因为一名人类工程师现在可以同时在多个地方让智能体并行地实现功能、重构代码、编写测试和文档。
“好代码”依然是有成本的
交付代码的成本已降至近乎免费，但交付“好代码”的成本依然显著。
我所定义的“好代码”包含以下特质：
-
代码确实可用： 它能完成预定任务，且没有 Bug。
-
我们“确信”代码可用： 我们已采取步骤向自己和他人证明，该代码符合使用目的。
-
解决了正确的问题。
-
优雅且可预测地处理错误： 它不只考虑“理想路径”（Happy Path）。错误信息应提供足够的上下文，帮助未来的维护者理解发生了什么。
-
简单且精简： 只做必要的事，且方式易于被人类和机器理解，并方便未来维护。
-
受测试保护： 测试证明了它现在能运行，并作为回归测试套件，防止未来在无感知的情况下损坏。
-
有适当的文档： 文档反映了系统的当前状态——如果代码更改了既有行为，对应的文档也必须同步更新。
-
设计兼顾未来的灵活性： 保持 YAGNI（你不会需要它）原则很重要——为了预测未来可能永远不会发生的改变而增加复杂度，通常是坏代码；但同样重要的是，不要写出让未来改动变得举步维艰的代码。
-
其他相关的“特性”（-ilities）： 即可访问性、可测试性、可靠性、安全性、可维护性、可观测性、可扩展性、易用性——这些适用于特定软件类型的非功能性质量指标。
编程智能体工具可以辅助完成上述大部分工作，但作为驱动这些工具的开发者，依然承担着沉重的责任：你需要确保产出的代码在当前项目所需的维度上是“好代码”。
我们需要建立新的习惯
现在的挑战在于，我们需要建立全新的个人和组织习惯，以应对智能体化工程所带来的便利和机遇。
这些最佳实践在整个行业内仍处于摸索阶段，我也在摸索之中。
目前我认为最好的做法是学会质疑自己的直觉：每当你的本能反应是“别做那个，不值得花时间”时，请试着发一个 Prompt 给异步运行的智能体。最坏的情况也不过是你在十分钟后检查时，发现这几分钱的 Token 花得不值而已。
原文：Agentic Engineering Patterns by Simon Willison
关注公众号「Python之禅」，回复「1024」免费获取Python资源
