把开发拆成 why 和 action：一个用判断引擎重做 Runtime 的设想

今天参加活动，我得了一个让我想马上记下来的灵感。

2026 年出现了一个叫 jev 的新引擎，按现场的说法，它属于「判断引擎」。如果「判断」这件事可以交给引擎，那我们能不能借此重新组织和规划 IT 开发的流程？下面这些，是我顺着这个念头，把一天的讨论梳理出来的一条思路。

开发可以抽象成两件事

先把开发这件事做一次彻底的抽象。在我看来，它无非是一个动作——一个在电脑上跑的 action。那为什么要开发？因为我们有一个 why、一个 reason：这个 action 为什么存在。

把这两件事放在一起，它天然就是一对 key-value：why 是 key，action 是 value，也就是「为什么」完了要执行「哪个 action」。真正抽干净之后，开发可能就只剩这两件事。

让判断引擎来决定「现在该做什么」

既然有了判断引擎，就可以大胆设想一种新的形式：电脑，或者说 IT 硬件，先去判断 now——当前是什么状态。它不是去凭空推理，而是接收、吸收 input，也就是当前这个状态；然后把这个状态交给 jev 的判断模型，再去查我们已经登录好的 key-value，也就是那套 why-action 数据库。最后得到两个输出：

1. 在当前这个 now 的情况下，优先该执行哪些 why-action；
2. 这些 why-action 该按什么顺序执行。

然后让这些 why-action 自动执行。到这里，一个「状态 → 判断 → 决策 → 执行」的闭环就成形了。

把循环闭上：用 reaction 触发下一个 Y

今天和 Syama、Eva 讨论的时候，Syama 给了一个特别好的点子，正好补上了这个循环缺的那一环：通过 jev 登录的 Y 决策出该做什么 action 之后，这个 action 做完会引发出一个 feedback。

他举的是游戏里的例子：让小人、小兵去打仗，结果被对方的大炮把血打没了；这个小兵在 action 之后的状态，比如他叫了一声、比较悲伤地叫了一声——这就是一个 reaction。我们把这个「被消耗、被互动时的状态」也注册成一个 action，让它去触发另一个 Y。这样一来，循环不就自动转起来了吗？这是今天得到的一个很好的思路。

action 可以有三种形态，执行环境仍是开放问题

接下来要回答的是：action 到底以什么形式存在，又在哪里执行？

目前可以这样定义 action：

• 直接就是 code，一段代码或程序；
• 或者定成一个 skill；
• 或者就是一个 prompt。

如果真要落实成一个新型的 runtime，执行环境这一层还需要想清楚：action 是直接执行 code 吗？如果 action 是一个 skill，是不是要给它一个 harness engineering 的环境，让它去做 harness engineering 的操作、执行那个 skill，从而把那段 program 跑起来？如果 action 是一个 prompt，是不是也由它去动态生成一段东西，变成一个动作，最终变成一个程序化的流程？

now 从哪里来：像 browser use 一样盯着屏幕

前端这一侧的「now 的判断」也有一个具体的设想。以电脑为例，能不能做一个类似 browser use 的东西，去监听你的显示器，然后不断地、重复地判断当前状态？如果能，这不就构建出了一个新型的 runtime 吗？

回到人：需要一个 interview 入口

runtime 有了，再往深处想，就要结合人类社会。

对人来说，面对一件事，他得去想 why——我为什么要做这个；还得想我能做什么 action；甚至还要再动一次脑子，把我这个 action 和这个 why 怎么联系上。这些目前都得靠人自己想。

而人跟人是不一样的：有些人善于思考这些，很多人则觉得这件事本身就非常难。所以，要尽快把 runtime 真正用起来，我们还得先解决人的问题：提供一种 interface 去 interview 这个人，通过这个 interview 应用或系统，帮他生成对他有用的 key-value，也就是属于他自己的 why-action 数据库。再把它放到这套 runtime 上跑，不就行了吗？

这一块其实衍生出一个哲学上的想法，两个人性：

• human like to：人愿意做的事，是接受 interview，把自己的这些东西说出来；
• human want：人喜欢得到的结果，是得到一个能帮我做事的一套东西。

而所谓的 interview 系统、或者叫资质转换系统，做的事情就是把他的 why 和 action 之间的关联性——这个 graph——重新构建出来。它是一个中间系统。

缩小范围：先做一个「帮你找工作」的小实例

基于这些想法，一下做一个大型系统会比较难。所以我想，这周和下周的题目可不可以缩小范围，先做一个小的实例：帮你找工作。

我用刚才说的方法把它拆成三步。

第一步，一个 interview 的小应用。 它的功能是：一，让人说；二，引导人说。引导他说出自己能做什么、想要什么、为什么做这个判断等信息，尽可能地多引导他，让他把这些都说出来。他说出来之后，interview system 在后台处理，最终产出就是那张 key-value 表，也就是 why-action 表。这是 interview system 最终要落到的那一个点。

第二步，把 action 和软件关联起来。 action 本身是一种可以和软件关联的动作，所以可以给它定一个 service type：type 是基础的 software 执行，或者 command line interface 的执行，也就是可以直接变成程序的执行；也可以把他想做的 action 封装成一个 skill，再用例如一个 harness engineering 的 CLI 去把它跑起来；还可以把它包成一个 prompt。把这些 action 都登录上，再把对应的 Y 也登录上。

第三步，启动那个全新的 Runtime。 runtime 启动时得有一个初始的 action，比如「我要找工作」；然后让 why-action 循环跑起来，比如放任它循环一个多长时间。或者用刚才说的那个设计：在 action 之后再给 action 附一个判断——检验 action 执行之后的状态，也就是 reaction；判断这个 reaction，再把 reaction 作为新的输入，扔回给 browser use，交给 jev 判 Y、判 action。

最后想看看，它能不能真的帮这个人找到一个他心仪的、适合他的、他也愿意做的工作。可以尝试一下。