AI 时代的软件进化论

在今天的许多企业中，大部分决策、执行、验证和改进都在软件系统上进行。客户触点、定价和合同变更、供应和库存调整、日志收集和分析，以及内部运营工作流——所有这些都深度依赖软件。这不再是IT仅仅被引入的阶段；业务本身的运作与软件状态紧密相连，更新软件的能力已等同于更新业务的能力。

这种情况不限于特定行业。跨越各个行业和企业规模，以一定速度和复杂度运营的企业已无法在没有软件作为核心的情况下运作。随着外部条件变化越来越快，决策—执行周期的频率不断增加，变化的能力本身成为了竞争因素。当客户价值、服务条件、运营约束、监管要求和成本结构的变化叠加时，无法更新软件的企业就无法将决策转化为行动，无法进行修正，最终陷入停滞。

在这种环境下，可以观察到许多软件更新成为业务决策和政策变更瓶颈的案例。决策可能已经做出，但执行所需的结构性变更无法及时完成，缩小了可以实际测试的举措范围。

软件更新所需时间越长，决策与执行之间的距离就越大。在这段延迟期间，环境条件持续变化。结果，越来越多的决策未被执行，业务的运营范围逐渐收缩。

当我们审视长期使用的软件时，很少发现系统仍保持其原始状态。功能被添加，配置被更改，运营被调整，软件演变为与初始设计截然不同的形态。早期规范或设计文档在数年后仍能完全匹配实现和运营现实的情况并不常见。这并不意味着原始设计毫无意义；相反，它反映了一个观察——初始时假定的条件在长期运营中难以保持。

随着软件持续使用，最初未预料到的任务和决策成为日常运营的一部分。用户行为发生变化，数据的数量和含义不断演变，与周围系统的关系也在转变。额外的处理、重组、替换和变通方案不断积累。最初看起来像是小例外的东西最终成为常态，这些常态向内部结构施加外推力。随着时间推移，曾经简单明了的设计在吸收现实世界需求后变得更加复杂。

同一批人在系统整个生命周期中始终保持负责也并不常见。开发者和运维人员更替，组织结构演变，角色重新分配。即使文档仍在，过去决策背后的上下文假设也未被完全共享。丢失的不是信息量，而是早期决策成立的一组条件。当这些假设消退时，相同的文本不再导向相同的结论。变更变得更加谨慎，局部变通方案增多，整体一致性逐渐恶化。

这些变化并非源于特定故障或异常情况。类似的模式在不同组织、行业和技术领域中反复出现。它们共同的特点是，软件在长期使用的同时，周围条件持续变化。尽管这些变化的性质因环境而异，但变化持续存在这一事实是共通的。

假设中的微小差异随时间累积。曾经可以通过常规运营吸收的调整最终需要结构性重新考虑。在那个节点，变化的权重和范围增加。随着影响范围扩大，验证成本上升，回滚变得更加困难，决策制定放缓。当决策放缓时，企业无法再测试他们想尝试的东西。这种状态不是质量低下，而是学习受阻——环境变化越快，这种损害就越大。

许多开发工作传统上遵循这样一种模式：在实施开始之前尽可能地确定设计。这种方法对于建立共识、实现分工和大规模项目管理是有效的。在实施成本高、实验昂贵的环境中，尽早固化设计是务实的选择，设计起到了预先降低复杂性的作用。

然而，这种方法有固有的时间结构约束。从设计完成的那一刻起，它所假设的条件就开始变化。设计完成和实施之间的间隔越长，假设与现实之间的偏差就越大。当条件快速变化时，到系统完成时这种偏差可能变得很大。发生变化的往往不是次要的规格细节，而是基本优先事项、运营约束或数据的含义。

这并不意味着设计是错误的。在很多情况下，它是当时最好的决策。问题在于没有考虑到假设会随时间推移而变化这一事实。如果完成后的调整没有被内建在内，系统在完成的那一刻就变得难以更新。当完成被视为终点时，后续变更被作为例外处理，作为事后补充而累积。随着时间推移，更新以局部修复的形式堆积，结构硬化，业务的学习速度下降。

这种开发方法的出现有明确的原因。高实施成本和沉重的实验负担使得早期规划至关重要。评估条件、组织依赖关系和预先定义完整系统的能力在此类环境中发挥了关键作用。建立共识、风险前置和结构化分工是实际的必要条件。

随着条件变化，价值的位置也随之变化。过去的判断、失败和调整不会变得无效。相反，它们被以不同方式引用和应用。从设计评审中获得的经验不再用于完美预测未来，而是用于识别系统在变化下可能在哪里断裂。运营教训告知哪些基础应保持固定，哪些领域应保持灵活。过去的经验不是被丢弃的；它是被重新使用的。

随着这种重用变得可能，经验的价值往往增加而非减少。在快速变化的环境中，错误的判断会迅速放大。更低的实验成本意味着更多的尝试——包括错误的尝试。因此，优先排序和方向判断的质量对结果的影响更大。

近年来，开发条件出现了明显变化。实施和实验的成本已经下降，将假设转化为可测试形式所需的时间已经缩短。这种转变部分由直接支持代码生成和修改的AI软件的广泛采用所驱动。这些工具降低了验证实现的初始成本，使得尝试、废弃和重构设计变得可行。

这里重要的不是AI是否被采用，而是条件已经改变。当条件改变时，在其下有效运作的结构也会改变。

重要的是，这不是将AI驱动的开发与人类驱动的开发对立起来的问题。正在发生的是人类判断——如优先排序、结构决策和上下文理解——与AI辅助代码生成和修改的融合。人类决定尝试什么和在哪里改变；AI降低实施这些决策的成本。通过这种协作，以前不切实际的速度进行实验和学习已成为可能。

因此，持续更新软件以配合业务变化的开发方式首次成为现实选择。

在这些条件下，允许事后调整的结构比试图预先固定一切的结构更易管理。随着规模增长和需求演变，重新审视和修改结构的能力成为先决条件。这并不意味着放弃设计。它意味着缩小固定基础，清晰定义什么应该保持灵活，并在明确优先级的情况下保持渐进重组结构的能力。基础设计变得更加重要，而非更不重要。

随着系统扩展，基础设施不可避免地被替换。曾经足够的配置需要冗余、分区、分布、可观测性和恢复机制。持续运营带来重组和功能扩展的需求。在实际环境中，升级、降级、回滚、分阶段迁移、并行运行和部分替换是常规活动——而非异常事件。无法前后移动的结构在每次变更时增加风险和成本，最终完全停止更新。

因此，软件结构必须支持可逆性和可替换性。当边界不清晰且系统向单一方向增长时，变更广泛传播，验证变得粗糙，回滚变得困难。清晰定义的边界和模块化的替换单元允许学习通过变化继续进行。

这些决策不能仅靠个人才智。确定什么保持固定、什么保持灵活以及哪些变更是可接受的，必须被作为共享假设来对待。这需要的不仅仅是工具选择或编码标准；它需要共同的战术理解。在缺乏此类共享判断的地方，更新变得依赖个人，速度下降，学习停止。

每次条件变化时，新的约束被添加到软件和业务中。虽然过去的设计和实现可能不再直接适用，但这并不否定它们背后的经验。

通过之前的变化形成的判断——理解系统在哪里会断裂、瓶颈在哪里出现、变化传播多远——在条件再次变化时继续被使用。即使形式变化，这些判断在决定下一步尝试什么和在哪里介入时重新浮现。

在现代开发环境中，人类情境判断和AI辅助实现的结合使得此类经验可以在更短的间隔内被应用。积累的知识仍然嵌入在判断质量中，并直接流入后续的实现和验证。

因此，系统不是在每次变化时从头重建，也不是僵化地保留过去的形式。相反，经验随着条件变化被重用，软件据此进化。

变化将继续。新技术和约束将出现。但积累的经验不会丢失。随着经验可以被重用的速度和频率增加，其价值更直接、更一致地反映在结果中。