一次性系统的架构
本文信息来源：tuananh
随着软件的生产成本不断降低（得益于编码代理），以及质量预期的变化，我们正目睹一次性软件的兴起：这种代码被生成、使用，然后丢弃，而不是无限期地维护下去。
传统模式
传统软件遵循一种早已确立的模式：一次性构建，长期维护，并通过高额的前期资本投入和长期维护成本来买单。这种经济逻辑之所以成立，是因为重写的成本非常高。我们接受在一个项目生命周期中将 80% 的时间花在维护上，因为另一种选择（从头开始）往往难以承受（直到产品到达其 EOL）。
这催生了一种谨慎的工程文化：整洁的代码、周密的架构，以及通过重构来降低技术债务。我们为长期而优化，因为长期是不可避免的。我们必须与之共存。
一次性化的转变
但如果一个代理只需 5 分钟就能根据提示重新生成一个可用的替代品，会发生什么？“清理技术债务”或“为了长期进行重构”的动机将不复存在。如果代码现在能用，而且以后还能重新生成，为什么要追求完美？
我们已经看到 “氛围编码” 的兴起：构建只解决当下问题的工具。需要一个特定的数据解析器？生成它。需要一个用于会议的一次性仪表盘？生成它。用完即可，如果坏了或过时了，就删除再生成一个。只要输出正确，你并不在乎代码是否“干净”。
这不是懒惰，而是软件开发经济学的根本性转变。当生成变得廉价，维护就成了昂贵的选择。
一次性系统的架构
如果我们正走向一次性软件时代，如何架构能够在这种转变中生存的系统？答案在于一个三层模型：
核心层（持久层）
事实来源 。这是系统中经过加固、由人类编写、变化缓慢的基础。它包含关键的业务逻辑、数据模型和核心算法。之所以构建这一层以长期存在，是因为它代表了系统的根本价值。
连接层（API）
不可变契约 。这些是定义组件如何通信的接口。它们必须做到尽善尽美，因为可丢弃的部分可以是不完美的。只要你的 API 契约足够稳固，就可以在不破坏系统的情况下替换底层实现。
可丢弃层
由 AI 生成的“胶水”代码、数据解析器、UI 组件和集成脚本。这里是氛围式编码发生的地方。生成它、使用它，在需要时再重新生成。只要它遵循连接器层所定义的契约，内部实现再凌乱也无关紧要。
契约优先设计
让这一切得以实现的关键在于契约优先设计 。我们不再围绕具体实现进行编码，而是严格遵循模式进行编码：OpenAPI、gRPC、Smithy，或任何适合你所在领域的标准。将该模式作为约束提供给代理，只要输入和输出符合契约，我们并不在意盒子内部的逻辑有多么混乱。
关键原则 ：不可变的契约。契约必须足够完美，才能容许一次性组件的不完美。
这种方法使你能够：
- 在不破坏系统的情况下重新生成组件
- 独立于实现来测试契约
- 在保持核心稳定的同时演进一次性层
- 接受质量较低的生成代码，因为它受到高质量契约的约束
未来
我们还没有走到那一步，但发展轨迹已经十分清晰。随着编程代理不断进步、代码生成成本持续下降，越来越多的软件将变成一次性的。能够存活下来的系统，将是那些拥有持久核心、不可变契约以及可弃用外设的架构。
问题不在于这种转变是否会发生，而在于你的架构是否已经为此做好准备。
