自然语言描述需可被验证
别名: 自然语言编程 · 对话式规则创建 · NL 自动化
概念解释
第三条表达路线：让用户用日常语言说出规则——「我到家而且天黑了，就开廊灯」——由系统解析成可执行的规则。大语言模型成熟后这条路重新流行，因为它正面绕开语法门槛：用户不需要学任何形式构造。
但这条路线的成败不在理解而在验证。自然语言是模糊的，规则引擎要求无歧义，解析过程必然替用户做了一连串默认决策；如果用户无法确认「系统理解的规则」就是「我说的规则」，门槛只是从「写不出」转移成了「查不出」——而后者更隐蔽。
机制
解析的每一个默认决策都是一次用户未参与的决策：「天黑」被解释成日落后十五分钟还是光照度阈值？「我到家」以手机 GPS 还是门锁开合为准？「还有人在时别关灯」里的「人」包括猫吗？单条规则里这样的分叉点常有数个，每个分叉的解释都在用户看不见的地方完成。
错误的性质因此改变。条件语句时代，用户写不出规则，失败是显性的、当场的、自己知道的；自然语言时代，规则总能被「创建成功」，但可能悄悄偏离意图——错误从语法层转移到语义层，从「当场报错」变成「安静地跑错」。一条错误规则在后台持续触发数周而不被察觉，是这个模式下最典型的失效。
所以验证机制不是附加的确认对话框，而是这条路线唯一的纠错通路：结构化回读、历史回放、首次触发提醒，三者都是把「系统理解的规则」重新呈现给用户比对的手段。没有这一层，自然语言入口的可用性是虚假的——用户说得出，但不知道自己得到了什么。
怎么研究
对自然语言规则创建的研究（从早期的受限语言接口到近年的大模型解析）有一个一致的发现：用户与系统的理解差距极少在输入环节暴露，几乎总是在确认环节才显形——用户看到解析结果的结构化呈现或第一次错误触发时，才发现「不是这个意思」。触发-动作编程研究里语义封装描述显著提升理解正确率的结论同样适用于回读层：呈现形式决定用户能不能发现解析偏差。
常用方法：收集用户的自然语言规则，将其解析结果回呈给原作者，测量「这就是我的意思吗」的认可率；再以错误注入法——故意呈现轻微偏移的解析——测量用户的检出率，检出率是验证机制有效性的直接量度。
方法论注意点：认可率会被「看起来对」欺骗。轻微偏移（时间差十分钟、范围少一个房间）的检出率远低于明显偏移，评估必须用偏移幅度分层的注入设计，只测明显错误会高估验证层的可靠性。
边界
- 简单规则上验证充分，复杂逻辑上不够。 单触发单动作的规则，回读一眼可比对；带否定、例外、时序的组合（「除了周末，到家就开灯，但如果家人先到了就别开」）回读本身就难读，验证退化为形式。
- 自然语言表达不出用户没想清楚的量。 冷却时间、优先级、生效时段——这些参数不是语言问题，是决策问题；对话式追问可以逼出决策，但也把交互成本还给了用户。
- 验证强度应与后果分级。 开灯类规则回读即可；涉及门锁、支付、向他人发通知的规则，回读不够，需要预演或生效前二次确认。
怎么落地
- 解析结果永远结构化回读：触发、条件、动作分列呈现，用户自己的词标注在旁边；在解析做了默认决策的地方显式标出「“天黑”按日落前后 30 分钟计」。
- 歧义处显式追问而非静默取默认值——追问的成本一次性，静默偏差的成本持续到被发现为止。
- 提供回顾式验证：「这条规则按上周的情况会触发 4 次，最近一次是周二 18:40」——用历史数据让用户检查规则的实际覆盖面。
- 首次触发时现场提醒并附纠正入口，把验证摊到真实使用的第一次机会上。
- 验证办法：以轻微偏移注入测检出率（见研究段）；上线后监控「创建后 48 小时内被编辑或删除」的规则比例——解析不靠谱的最强信号是用户立刻反悔。