如今的AI大模型不仅在改变软件系统的构建方式，某种程度上也在不知不觉中改变工程文化本身。许多过去需要明确建模、严格定义的问题，如今可以在缺乏清晰specification的情况下被"解决"，至少在结果层面看起来如此。
直观上看，这是工具升级带来的效率提升，但我们难以回避更本质的问题：我们究竟依赖什么来控制系统复杂性，又是通过什么方式来判断一个系统是否值得信任？
在理工领域，我们之所以能够描述、分析并构建复杂系统，并不是靠直觉、经验或是“我寻思”，而是依赖一组明确定义的概念、抽象和不变量：数学通过定义对象和运算来建立可推理的形式系统，计算机系统通过明确模型、接口与failure假设来限定行为语义，而工程系统则需要明确的spec，才能使模块之间的组合成为可分析、可验证的架构——这些共同构成了复杂系统能够被理解和维护的前提条件。
如果这些前提不成立，很多讨论本身就无法进行。没有被界定的概念，就无法讨论正确性；没有被限定的失败模型，就无法讨论可靠性；没有稳定的接口，模块之间的组合只能依赖运气。
从这个角度看，工程系统设计长期依赖的，其实是一套相当稳定的方法论：
-
明确系统成立所依赖的假设
-
定义接口与行为边界
-
在这些约定和层次之上组合复杂结构
这些并不能够避免系统中的复杂性，但却可以把复杂性压缩到人类大脑可以处理的尺度之内。
围绕LLM的实践，则在不断强化一种新的直觉：许多过去需要显式建模的问题，似乎可以通过LLM能力直接跨越。模型在缺乏完整spec的情况下，依然能够生成（貌似）合理的输出；系统在failure model并不清晰的前提下，也可以跑起来。
这很容易让人产生一种错觉：系统复杂性正在被削弱。但从工程视角看，复杂性并没有消失，只是改变了存在方式。
LLM的特殊之处在于，它能够在没有显式概念定义的情况下，对输入进行语义补全和延展。这并不意味着spec本身不再重要，而是定义被转移到了训练数据分布和统计相关性之中，成为一组隐含假设。
与传统spec相比，这类假设有着完全不同的性质：
-
无法被彻底枚举
-
无法被形式化验证
-
不能作为稳定的推理基础
-
在数据分布以外的场景中缺乏可控性
这直接改变了系统复杂性被处理的位置。传统工程需要在设计阶段正面硬刚复杂性，通过约束、接口和验证提前消化；而在基于LLM的系统中，复杂性被推迟到运行阶段，以不可预期行为的形式出现，并且高度依赖上下文。
从模块化角度看，这种变化尤为明显。传统模块依赖清晰、稳定的语义接口，只要满足spec，底层实现就可以被替换。而LLM的接口表面上极其简化，往往只是文本输入与输出，但语义边界却高度不稳定——相同的输入在不同上下文中可能产生不同的行为，错误难以复现，也难以被系统性分类。这使得LLM更接近一种概率性推理黑盒(oracle machine?)，而不是一个可以被严格验证和替换的工程模块。
这种差异不仅是技术层面的，也逐渐演变为工程文化上的差异。在传统工程实践中，正确性、可解释性和故障模式是设计阶段必须面对的问题；而在以LLM为核心的系统中，这些问题更容易被掩盖，甚至被默许为能跑就行，出问题再修。
当系统是否可靠被理解为"多数情况下是否可用"，工程判断价值观也会随之发生偏移。
在短期内，这种方式确实能够显著提高交付效率。但这种有效性依赖于隐含前提持续成立。一旦系统面对分布外输入、极端场景或失败代价较高的决策环境，原本被隐藏的复杂性就会集中暴露，而系统却缺乏清晰的工具去判断自身处于何种状态。
这也是为什么在对不确定性和失败后果高度敏感的系统中，LLM带来的concern尤为明显。模型可以生成流畅的解释，但这并不等价于它理解了背后的物理或因果规律。当语言层面的合理性被当作系统层面的可靠性，复杂性往往会以更难处理的形式回流。
在这样的背景下，senior工程师的价值可能并不体现在是否能最快将模型接入系统，而在于是否能够对系统边界做出清晰判断：
-
哪些抽象必须显式存在，不能被统计推断替代
-
哪些不确定性需要暴露给系统下游，而不是try-catch默默吞掉
-
哪些故障模式需要被设计为可识别、可监控、可隔离
-
哪些决策不应交由概率模型完成，而是要明确定义出状态机来兜底
从这个角度看，LLM是一把非常锋利的刀，但它削的是人类的认知负担，并不是系统的本质复杂性，只是降低了绕开这些问题的门槛。
在LLM时代，当代码可以被无限生成、当实现变得廉价，人类工程师最后的护城河，是为抽象承担后果的判断——一旦缺失这种判断，就会让那些被忽略的复杂性，以更高的代价回到系统中。