上周本应该把这几篇文章写完，奈何 Pokopia 太好玩了，最近沉迷开荒，这周抽空慢慢写吧。
最近，我一直在思考一类新型软件，但总觉得“软件”这个词已经不太够用了。
先举个例子。
你告诉一个系统：“帮我规划五天的旅行，预算适中，把热门景点都安排进去。”它能理解这句话，拆解任务，搜索信息，最后给你一份完整的行程。你再告诉另一个系统：“整理这周的会议纪要，给每个人分配待办。”它也能完成。
这已经不是普通的软件行为了。
我把这类系统叫做 Intentware，暂且译作“意件”。这篇文章想解释这个词是什么意思，以及为什么我觉得它值得单独讨论。
一、传统软件是怎么工作的
传统软件的工作流程，大致是这样的：
-
人先想清楚要做什么
-
人把目标拆成步骤
-
人把步骤转换成系统能接受的输入
-
系统执行，并返回结果
系统真正负责的，其实只是最后一步。前面三步，主要都由人来完成。
这也是为什么，软件虽然提高了执行效率，却没有真正减少用户的认知负担。你还是要先规划，先判断，先组织，系统才知道该怎么动起来。
二、Intentware 多做了哪一步
Intentware 和传统软件的区别，就在于它开始接手上面的前三步。
你不再需要打开特定模块在特定 Form 输入特定界限的字段。
具体来说，它至少要理解三件事：
目标：你真正想完成什么。“规划旅行”是目标，“订机票”是指令，这两者不是一回事。
语境：同样是旅行，有人想省钱，有人想省力，有人更在乎节奏，有人更在乎改签灵活性。没有语境，就很难判断什么方案更合适。
约束：预算、时间、权限、风险偏好，这些都不是附加信息，而是任务本身的一部分。
理解之后，它还要把这些信息转化成行动路径。调用哪些工具，按什么顺序推进，什么时候需要回来问人，什么时候可以继续自动完成，这些都属于它要处理的部分。
这就是我说的“意图承接”。
三、指令和意图不是一回事
这里有一个很重要的区分：指令 和 意图 不是一回事。
指令 往往是直接的，可以立刻执行。像是“给劝退师发邮件”/“把文档翻译成英文”/“订周五晚上机票”。
意图 则更模糊，也更接近真实世界里的需求。比如“帮我安排一次轻松一点的出差”。这里的“轻松一点”，就不是明确规则，而是需要解释的。
过去，把意图翻译成指令的工作，几乎都由人自己承担。人先想清楚，再去操作软件。
Intentware 的出现，意味着这层翻译工作开始被系统承担。它要先理解“你到底想要什么”，再把它转成一条可以执行的路径。
四、什么不算 Intentware
有三类东西，很容易和 Intentware 混在一起，但我觉得不应该算。
第一类，只是换了个交互界面的旧系统。
原来是点按钮，现在变成说话输入，但底层逻辑没有变，用户还是要自己想清楚所有步骤。这不算 Intentware，只是更自然的 UI。
第二类，只会说、不会做的对话系统。
它可以总结，可以建议，也可以回答问题，但不能把理解转化成执行。这种系统更接近对话系统，而不是行动系统。
第三类，没有边界、什么都想自动完成的全权代理。
Intentware 必须有边界。它需要知道：哪些事情可以代办，哪些事情必须回来问人，哪些情况下应该立刻停下来。
一个没有边界的全权代理，不是 Intentware，更像是一个设计不合格的系统。
五、为什么这个概念重要
本文大概思路形成于前阵子我做软件研发申报，发现要做的许多事情在以前的申报单里很难找到合适的选项…因此找了这么个词来解释当前要做产品新形态，但如果所有带 AI 的产品都叫 Intentware，那这个词很快就没有意义了。
但如果我们继续只用“软件”这个词，又会低估眼前正在发生的变化。
这轮变化真正新的地方，不是 AI 更会聊天了，而是机器开始接管一部分原本由人负责的规划和编排工作。它介入的已经不只是执行层，而是部分过程层(甚至决策层)。
这会带来一连串很现实的问题：系统可以替人做多少决定？边界怎么划？出了问题谁负责？人在哪些环节必须保留最终决定权？
这些问题，如果继续放在旧的“软件”框架里面讨论，其实不太容易说清楚。
六、小结
如果用一句话来概括：
Intentware 是位于人与工具之间的一层系统。它接收目标，理解语境和约束，把它们翻译成可执行路径，并在授权边界内推动事情完成。
它比传统软件多做了一件事：不只是执行指令，还把“要做什么”转换成“该怎么做”。
这也是为什么，我觉得它值得有一个专属名字。
等我把第四个图开完，再继续写下一篇…
评论