编程的隐喻正在失效：从编排到即兴

原载 2026 年 3 月 10 日，微信公众号《问题儿童与端水大师的日常》。

本文与《治理是 AI 的暗线，人类恰是瓶颈》探讨同一话题——前者是宏观视角，本文是微观视角。

过去几十年里，我们对“编程”的理解几乎是默认的。

写程序，就是把一件事情拆成一系列确定的步骤，然后交给机器去执行。每个分支、每个异常、每种情况，都尽可能在事前被考虑和定义清楚。

这件事甚至能从词源里找到痕迹。Programming，本身就意味着“预先编排”。机器负责执行，而程序员的职责，是把所有流程提前设计好。

所以经典的软件工程，一直有一种非常明确的审美：

• 系统像流水线
• 模块像齿轮
• 开发像精密编排
• 最好的程序，是尽可能消灭不确定性

这套范式曾经极其成功，也塑造了整个行业对“工程感”的认知。

若干年前，神经网络的大规模应用，悄悄动摇了这个前提。而今天，LLM 和 Agent 的成熟，正在彻底挑战这个根基——当系统的核心能力来自 大模型、Agent、工具调用、上下文工程、记忆 和 运行时推理 时，软件已经不再只是执行既定命令的机器。它开始更像一个具备判断能力的行动体。

于是，开发者第一次明显感到一种违和感：我们仍然在用过去那套“流水线式”的思维写软件——写 workflow、写规则、写状态机，甚至在系统刚开始时就定义好数据库 schema、API 结构，试图把系统未来可能发生的路径和形态都提前框定。

但与此同时，我们又越来越清楚地知道：这些 Agent，本来就可以自己判断。它们能根据上下文选择工具、尝试不同路径、根据反馈调整策略。换句话说，它们具备某种程度的“临场发挥”（Improvising）。

于是，一个违和的状态出现了：我们拥有了会思考和决策的系统，却还习惯性在用设计齿轮的方式对待它。

流水线与舞台

如果一定要打一个比方，我越来越觉得：过去的软件系统像工厂流水线，而 AI-native 的系统更像搭一个舞台做 show。

在流水线上，一切都被预先定义。每个零件负责固定动作，整个系统依靠**确定性（deterministic）**的精密编排运转。

但在舞台上，不一样。你仍然需要结构——你需要舞台、灯光、节奏、边界和主题。你需要知道什么可以发生，什么不能发生。但你不会把整支舞都写死。你要做的是：

搭好舞台
选好舞者
设定角色和故事
给他们道具和发挥空间
然后，让他们在现场完成表演

AI-native 系统，其实越来越像这样的结构。

确定性、精确性的部分并没有消失。它只是退到了更底层，成为基础设施。过去，确定性的编排本身就是作品，好比机械手表。今天，它更像是舞台、灯光、道具和规则。真正创造价值的，是在这个空间里临场发挥的智能体。它们会：

判断
尝试
失败
修正
再尝试

很多行为，并不是在代码里被完全写死的，而是在运行时逐渐形成。

这也是为什么很多人第一次写 AI-native 系统时会觉得不太适应。我们过去几十年形成的直觉是：如果一个系统的行为不是完全确定的，那一定是系统设计有问题。 但现在越来越多的系统，恰恰是有意保留了一定的不确定性。不是因为混乱，而是因为系统本身拥有判断能力。

程序员，越来越像导演

从这个角度看，软件工程的重心其实已经在悄然转移。

过去程序员的核心能力是：预先考虑一切。 你要在系统运行之前，把所有路径设计好。

而在 AI-native 系统里，开发者越来越像一个导演或编舞者。你要做的事情变成：

定义意图
提供上下文
开放能力
设计边界
建立反馈

然后让智能体在舞台上和谐共舞，系统在运行中逐渐逼近目标。

所以今天很多人谈编写 AI 应用时，仍然习惯用“自动化流程”来理解它。但这其实有点误导。真正的变化并不是自动化程度更高了，而是系统开始具备自主判断的能力。

于是软件设计的命题，也在悄悄改变。不再只是“如何把流程写清楚”，而更像是“如何搭舞台，如何赋能一个可以行动的体系”。

schema 不再是起点

这种变化，在很多看似技术细节的地方也已经出现。

例如，在传统软件工程里，我们习惯先设计数据库 schema，再开始写系统。我们假设系统的数据结构是可以、或应当在设计之初就被完整定义的。

但在很多 AI-native 系统中，情况正在发生变化。很多系统会先跑起来，通过真实运行产生数据、行为和模式，然后再逐渐沉淀出稳定的结构。换句话说：

过去我们先设计 schema，再写系统； 未来很多系统可能是先运行起来，然后 schema 从实践中慢慢浮现。

schema 不再是系统的起点，而更像是系统逐渐稳定之后的收敛点。

这并不是工程纪律的消失，而是工程纪律的位置发生了变化。

如果继续用刚才的比喻：过去的软件工程，解决的是流水线管理问题；而 AI-native 系统，更像是一个组织与协调问题。

问题不再只是：

每个零件怎么运转
系统是否严丝合缝

而是：

能力是否齐全
信息是否相关
目标是否清晰
边界是否合理
协作是否顺畅
反馈是否到位

换句话说，这更像是赋能、动员和凝聚力的问题，而不是螺丝钉和齿轮的问题。

放手反而是一种成全

当真正接受这种思路之后，一个有趣的变化会出现。程序员自身的编程压力，反而会明显变小。 因为你不再需要在系统运行之前，穷尽所有路径、预设所有结构、设计所有可能的情况。很多过去必须“提前设计”的东西，可以交给系统在运行中逐渐形成。

与此同时，系统的效果往往反而更好。因为 Agent 的判断能力，终于有空间被释放出来。

一些 AI-native 工程实践已经在验证这一点。例如 OpenClaw 采用极其简洁的系统内核，只提供最基本的能力和边界，却在实际运行中产生了远超预期的能力涌现。很多时候，系统之所以显得笨拙，并不是因为模型不够强，而是因为我们替它设计了太多本不需要存在的结构。

在这种意义上，克制设计本身就是一种设计，放手本身就是一种赋能。

也许未来某一天，我们会意识到：软件开发历史上最深刻的一次变化，并不是某个新语言、某个新框架，甚至也不是“AI 会写代码”这件事本身。真正的变化是，我们终于开始承认：软件驱动的系统不再只是机器。

它们正在变成可以被组织、被赋能、被引导的行动体或其集合。而程序员真正的工作，也不再只是写死每一步。而是：

搭好舞台，赋予能力，给出主题，然后让系统开始表演。

放手，反而是一种成全。