软件工程的第二种材料：AI 如何重塑构建方式

软件工程正在获得第二种“材料”

在纽约的一场对谈中，知名技术博主 Gergely Orosz 与 WorkOS 创始人 Michael Grinich 提出了一个颇具启发性的观点：软件工程正在获得它的“第二种材料”。长期以来，软件的唯一构建材料是确定性代码——由人类工程师逐行编写、可预测、可复现的逻辑。而如今，随着大型语言模型（LLM）的成熟，一种全新的、概率性的材料正被引入到构建者的工具箱中。

这个比喻的价值在于，它把 AI 从“又一个工具”重新定位为一种基础材料。就像建筑领域从只有木材，到引入钢筋混凝土一样，材料的增加不是简单的替换，而是从根本上改变了可以建造什么、如何建造，以及谁能参与建造。

两种材料的本质差异

确定性 vs 概率性

传统代码的核心特征是确定性：给定相同的输入，永远得到相同的输出。这种可预测性是过去几十年软件工程方法论、测试体系、质量保障流程的基石。工程师依赖这种确定性来推理系统行为、定位缺陷、保证可靠性。

而 LLM 带来的这第二种材料本质上是概率性的。它擅长处理模糊、非结构化、需要“判断”的任务，但代价是输出不再完全可预测。同样的提示可能产生略有不同的结果，同样的场景也可能出现意料之外的偏差。这不是缺陷，而是这种材料的固有属性——正如混凝土有它的抗压优势也有抗拉的短板。

LLM 的概率性源于其底层架构：模型在生成每个词（token）时，实际上是在对词汇表的概率分布进行采样，而非执行确定性的逻辑运算。温度（temperature）参数直接控制这种随机性的强度——温度越高，输出越多样；温度趋近于零时，模型行为趋近确定性。这意味着开发者可以在一定范围内"调节"概率性的程度，但无法彻底消除它。此外，即便是相同的提示词，模型版本升级、后端负载均衡或推理框架的差异，都可能悄然改变输出结果。这对依赖精确可复现性的传统软件测试体系构成了根本挑战——你无法用单元测试的方式来覆盖一个本质上是统计性的组件。

各有所长的分工

对谈中隐含的一个重要判断是：这两种材料并非相互取代，而是互补共存。确定性代码依然负责那些必须精确、必须可靠、不容出错的核心逻辑；而概率性的 AI 材料则接管那些过去用代码难以优雅解决的问题——自然语言理解、内容生成、模糊匹配、意图识别。

真正优秀的系统设计，将是懂得在什么地方用什么材料。把需要严格保证的部分交给代码，把需要灵活判断的部分交给模型，并在两者之间设计清晰的边界与校验机制。

这对构建者意味着什么

技能结构的重新定义

当工程师手上多了一种材料，他们需要掌握的能力也随之扩展。除了传统的编程与架构能力，构建者还需要理解如何“加工”这种新材料：如何设计提示、如何约束模型输出、如何评估概率性结果的质量、如何在不确定性中构建可靠的用户体验。

这类似于一个只会用木材的木匠，突然需要学习如何浇筑混凝土——底层的工程思维相通，但具体的技法、直觉与失败模式都需要重新积累。

评估概率性系统的质量，催生了一个新兴领域：LLM 评估（LLM Evaluation，简称 LLM Eval）。与传统测试不同，它通常依赖"以模型评模型"的方式，或使用人工标注的黄金数据集来衡量输出的准确性、安全性与风格一致性。Prompt 工程（Prompt Engineering）作为另一项核心技能，研究如何通过指令设计、少样本示例（few-shot examples）和思维链（Chain-of-Thought）等技术，引导模型稳定地产出符合预期的结果。这些技能目前尚未形成像软件工程那样成熟的方法论体系，大量实践知识仍以经验而非理论的形式流传，这也是为什么"如何加工新材料"在当下仍是一个开放性问题。

产品可能性的扩张

新材料最令人兴奋的地方，是它让过去“不可建造”的产品变得可行。许多依赖人类判断、语言理解或创造性生成的功能，此前要么无法实现，要么需要投入巨大的人力成本。现在，这些能力可以被直接嵌入软件之中。

这也意味着产品的竞争维度正在改变。当基础能力被 AI 材料普及化，差异化会更多来自于如何组合两种材料、如何在可靠性与灵活性之间找到恰当的平衡点。

一个值得持续观察的转变

把 AI 理解为软件的“第二种材料”，是一个比“AI 工具”或“AI 助手”更深刻的框架。它提醒构建者：我们面对的不是一次工具升级，而是一次构建范式的扩展。

对于工程团队而言，接下来的关键问题不再是“要不要用 AI”，而是“在系统的哪些部分，用哪种材料，以及如何让两种材料协同工作”。这场由 Gergely Orosz 与 Michael Grinich 展开的对谈，正是对这一转变的一次及时提示。

需要说明的是，本文基于该对谈的公开摘要展开分析，具体的技术细节与完整论述仍有待原始对谈内容进一步补充。