Susan STEM (@feltanimalworld) “很多问题上，我们的出发点也许是相同的， 但随着系统逐步展开，思考方式中那些极其细” — TopicDigg
Susan STEM
@feltanimalworld
the Entropy Control Theory : Language as system design, system is larger than the model. 又闭关了，可私信留言。
加入 August 2016
6K 正在关注 41.2K 粉丝
很多问题上，我们的出发点也许是相同的，
但随着系统逐步展开，思考方式中那些极其细微的差异，会在开发、测试、真实使用和反复修正中，被持续放大，
像水面上的涟漪，一圈一圈扩散开来。
我反而觉得这是一件好事。
所以我并没有刻意去“对齐”你的实现，也没有仔细拆你的代码。
我更倾向于先从自己的推导路径出发，把系统推到一个自洽的位置。
这样一来，我们之间的差异本身，就会变成一种输入：
不是分歧，而是多样性带来的震荡式前进。
既然已经聊到这个层级了，我想先抛出、也讨论几个关于 IR 的核心问题。
我先说我的立场。
我的 IR 不在用户输入层。
我把 IR 放在 Protocol（协议层）。
换句话说：
IR 是协议的一部分，而不是输入的一部分。不知道你对此有什么看法。
原因很简单，但非常关键：
IR 是结构，不是感知。
如果你把 IR 当成感知层的一部分，系统一定会出问题。
不能直接把「用户输入 = IR」。
用户输入是高熵、模糊、情境化的语言；
而 IR 是低熵、可验证、可执行、可审计的结构。
它们不属于同一个层。
在我的系统里：
用户输入 → 感知 / 解析
解析结果 → 是否符合协议
符合协议的，才能被编译为 IR
IR 不是“系统听到了什么”，
而是系统允许存在什么。
所以从根本上说：
IR 是系统的法律（law），而不是用户的语言（speech）。
法律不能由当事人直接书写，
只能在既定协议下被生成、被验证、被执行。
这也是我坚持把 IR 放在协议层，而不是输入层的原因。
（这张图非常糟糕，可以考虑不看，但是目前我居然找不到更好的图了，以后会有。
显示更多
