为什么输入模板化、输出围栏与围栏状态机会成为新的软件基础设施
上篇文章发布后,有朋友问我为什么我这么想,什么 AI Native 软件,为什么说正在从传统的软件工程演化为一种条件触发的概率控制系统?我们深入探讨了,输入模板化、输出围栏和围栏状态机会成为新的工程基础设施,探讨AI native应用和AI coding话题。
这个问题背后,其实涉及传统软件与 LLM Inside Application 在可靠性来源上的根本差异。
软件工程中,程序员通过变量、函数、流程控制、状态管理和数据结构,把现实世界的问题转化为数学问题,这是软件的基本逻辑。
只要输入相同、代码相同、环境相同,理论上就应该得到相同结果。这构成了整个传统软件工程的基础。
软件工程一直建立在一个几乎不需要被质疑的前提之上:
可靠性来自确定性,在确定性逻辑上构建秩序。
传统软件的可靠性来自确定性
传统软件的运行逻辑可以抽象为:
可靠性的来源包括:
程序员通过明确的规则,将现实世界的问题转换为可计算的问题。
例如:
这些机制共同构成了传统软件的可靠性基础。
AI Native 软件改变的不是输入方式,而是计算方式
今天,越来越多基于 AI Coding、AI Inside Application 的智能应用,开始以大模型作为核心计算单元。
这意味着传统软件工程中的可靠性基础正在发生变化。
很多人把 AI Coding 理解为:
用自然语言代替代码。
但从系统运行角度看,AI Coding 真正改变的不是输入方式,而是计算方式。
传统软件执行的是:
确定性逻辑计算。
而 AI Native 软件引入的是:
基于大模型的概率语义计算。
LLM 系统的运行逻辑更接近:
这里天然不存在传统软件中的:
问题不在于模型不够聪明。
而在于:
传统计算机体系、操作系统、编译环境和软件运行基础设施,本质上都是围绕确定性程序设计建立的。
编译器、类型系统、流程控制和状态管理,都是为了保证代码执行的可靠性。
当大模型成为新的计算单元后,它依然运行在传统计算体系之上,但传统软件工程用于约束确定性逻辑的机制,并不能直接约束概率生成过程。
因此,AI Native 应用需要在传统软件体系之上,重新构建面向概率计算的可靠性机制。
输入模板、输出围栏与状态机:补齐概率系统缺失的工程结构
为了让 AI Native 应用能够稳定接入传统软件体系,需要重新建立三类关键控制结构。
输入模板化:重建语义类型系统
传统软件通过类型系统约束输入:
intstringobjectclassinterface
而 LLM 接收的是自然语言和上下文。
自然语言具有高度开放性。
因此需要通过输入模板化,对进入模型的意图、任务结构、上下文范围进行约束。
输入模板化本质上是在回答:
它是在概率空间中建立语义边界。
输出围栏:重建结果类型系统
传统软件通过返回类型保证输出:
而 LLM 输出的是概率生成结果。
因此,需要通过输出围栏约束模型输出:
输出围栏不是简单要求模型“按照格式回答”。
而是在模型输出进入系统执行之前,建立确定性的校验和控制机制。
它解决的问题是:
模型可以生成,但系统决定什么可以被接受。
围栏状态机:重建流程与状态系统
传统软件通过状态机和流程控制保证系统行为。
例如:
而 AI Agent 的问题在于:
模型具有推理能力,但没有天然的业务状态约束。
因此,需要通过围栏状态机定义:
围栏状态机本质上是在控制:
概率行为可以如何流动。
AI Native 软件:从 Rule-driven 到 Intelligence-driven
当这些工程结构被补齐之后,AI Native 应用才能真正运行在传统软件体系之上。
它不是替代传统软件。
而是在传统软件体系中增加一个新的智能计算层。
软件的价值越来越依赖:
交互界面和传统软件部分,更像是创造一个让人能够理解、参与和管理智能行为的运行环境。
大模型时代最大的误解,是把 AI 看成一种更高级的编程语言。
实际上,它更像一种新的计算介质:
在概率空间中构建秩序。
从软件工程到概率工程
一个新的问题出现了:
如何建立一套能够把概率能力稳定转化为生产力的条件控制系统?
谁来管理这些条件?
谁来管理上下文?
谁来管理状态机?
谁来管理工具权限?
谁来管理输出围栏?
谁来管理风险控制?
这也是我们思考 Forge(哈希泰格智能软件工厂)的起点。
Forge 并不是一个 AI Coding 工具。
它更像一个条件系统构建平台。
它试图把原本散落在:
中的条件约束,统一沉淀为可管理、可复用、可治理的软件资产。
如果说传统 IDE 管理的是代码。
那么 Forge 试图管理的是 AI Native 时代的条件系统。
输入模板化:
约束语义入口。
输出围栏:
约束语义出口。
围栏状态机:
约束概率流动路径。
它们共同构成了一种新的可靠性体系。
在这个体系里,软件不再只是代码。
而是一套持续管理概率、约束概率、利用概率的控制系统。
软件工程师正在从编排逻辑转向设计条件
过去的软件工程师主要工作是:
而 AI 工程师更重要的能力,是设计条件:
这或许才是 AI Native 软件与传统软件之间最根本的分水岭。
为什么输出围栏和状态机会成为 AI Native 基础设施?
很多人认为:
这些只是今天 Agent 工程中的临时技巧。
模型变强以后,也许就不需要了。
但事实可能恰恰相反。
模型越强,系统越需要边界。
因为:
能力越强,意味着自由度越高。
自由度越高,意味着结果分布越发散。
企业系统需要的从来不是最大的自由度。
而是:
可预测、可控制、可治理的智能。
因此,输入模板化、输出围栏和状态机,并不是模型能力不足的补丁。
它们更像现代软件中的:
不会随着模型变强而消失。
反而会随着 AI 系统复杂度提升而越来越重要。
软件可靠性的第四阶段:Constraint is Reliability
回顾软件发展历史,可靠性的来源经历了几次变化。
第一阶段:可靠性来自代码
Code is Logic
通过代码定义明确规则。
第二阶段:可靠性来自架构
Architecture is Reliability
通过架构设计控制复杂度。
第三阶段:可靠性来自工程体系
Process is Reliability
通过流程、测试、运维和治理提升稳定性。
第四阶段:可靠性来自约束
Constraint is Reliability
AI Native 时代,可靠性来自:
过去几十年,软件工程一直在解决确定性问题:
如何让代码更正确。
如何让系统更稳定。
如何让架构更可靠。
如何让流程更可控。
而 AI Native 时代开始面对另一类问题:
如何管理不确定性。
因为大模型带来的不是新的编程语言,而是一种新的计算介质。
它能够:
但它的运行基础不再只是确定性逻辑,而是概率推理。
因此:
过去的软件系统管理的是代码。
未来的软件系统不仅管理代码,也需要管理概率产生、传播和收敛的过程。
过去的软件工程师编排逻辑。
未来的 AI 工程师设计条件。
过去我们关心算法如何执行。
未来我们关心:
AI Native 软件的真正竞争力
输入模板化、输出围栏和围栏状态机,并不是某种新的开发技巧。
它们本质上是在概率空间中重建确定性。
它们不是 AI 工程的细节。
而是 AI Native 软件的基础设施。
如果说过去的软件工程是在确定性逻辑上构建秩序。
那么未来的软件工程正在学习如何在概率空间中构建秩序。
这也是 Forge 试图探索的方向:
不是帮助 AI 写更多代码。
而是帮助组织构建能够持续管理智能、约束智能和利用智能的条件系统。
因为未来真正的竞争力,未必来自谁拥有最强的模型。
而更可能来自谁能够把模型能力稳定转化为:
的生产力。
模型决定智能上限。
工程决定智能能否进入生产。
而条件系统,将成为 AI Native 时代新的软件基础设施。
发表评论