这篇论文我读了两遍。第一遍觉得"又是符号AI老古董在炒冷饭"，第二遍发现它解决了一个LLM阵营根本不想承认的问题。
一、先骂两句
Forbus团队搞的是Qualitative Reasoning（定性推理），符号AI里的硬核派。年轻人可能没听过他，但这位是1980年代就跟着Gentner做类比推理的元老。现在LLM时代，符号派都快成非遗了，这篇居然发了arXiv还配了1,536条手工标注的synthetic数据——我得先敬一杯。
但敬完之后我要骂：SocialBot的实验设计太干净了。
1,536个案例，100%准确率，p值小到1/5^1536。这个数字漂亮得像假的一样。不是因为造假，而是因为 synthetic data 覆盖的是全排列组合，而真实人类的规范冲突从来不是全排列。真实对话里有含糊、有省略、有反悔、有"我开玩笑的你别当真"。这篇论文的测试集是逻辑完备的世界，不是人类世界。
所以100%准确率的含金量，我建议打七折。
二、但它确实解决了一个真问题
LLM做规划，规范要么靠RLHF硬塞（"不能歧视""不能教坏小孩"），要么靠系统提示贴膏药。两种方式都是静态的——模型出厂时定好，部署后不会变。
但人类规范是活的。今天我说"别告诉别人我喜欢喝可乐"，明天我说"跟小张说没关系"。LLM怎么处理这种动态冲突？答案是：基本靠猜。
这篇论文的核心贡献，是给了动态规范一个形式化骨架：
- 规范不是标签，是可废止的推理规则
- 冲突不是异常，是需要演算的日常
- 时间顺序不是装饰，是击败关系的硬约束
三、可废止演算的精妙与局限
精妙之处
两种封闭假设的设计很聪明：
禁止性封闭（默认不可允许）：适合隐私、安全场景。没明确许可=拒绝。这是欧洲GDPR的哲学。
许可性封闭（默认可允许）：适合日常协作。没明确禁止=放行。这是美国互联网的哲学。
同一个演算框架能容纳两种截然相反的法律哲学，这本身就是设计上的优雅。
冲突解决的三层结构
| 冲突层级 | 判定逻辑 | 时间敏感 |
|---|---|---|
| 直接冲突 | 后续规范优先 | 是 |
| 间接包含 | 包含方优先 | 是（严格包含时无关） |
| 相交冲突 | 禁止优先于许可 | 否 |
局限
但我要指出一个硬伤：相交冲突的处理与时间顺序无关。
论文说定理3和定理4证明"严格包含"和"相交"情况下，时间先后不影响结果。这从形式化角度是对的，但从人类角度是错的。
真实场景：
- 周一我说"别分享我任何饮食偏好"
- 周三我说"你可以告诉别人我喜欢果汁"
- 周五有人问"他喜欢什么？"
但人类的理解是：周三的许可是对周一禁止的限定更新，不是并行规范。论文的形式化把规范当成了集合的交集，但人类的规范更像是版本的覆盖。
这里缺一个"规范撤销"的算子。论文只有添加，没有显式删除。这是隐形的简化。
四、作为护栏的规划嵌入
最有价值的部分是HTN规划里的护栏嵌入。让我用人话解释：
SocialBot回答用户查询时，前置条件里有一条是：
> "证明这个分享行为在当前对话上下文里是permissible的"
如果这个证明失败，计划就不执行。不是后验过滤（"说完了再检查是否违规"），是先验拦截（"说不说先过证明关"）。
这和LLM的safety guardrail的区别：LLM是输出后审查，这篇是执行前许可。
从工程角度，后者更可靠。但代价是：你需要一个可证明的规范库，而不是一堆模糊的"价值观"。
这也是为什么LLM厂商不会用这套方法——他们的规范是emergent的，从RLHF里长出来的，没法写成Horn子句。
五、给一个判断
这篇论文代表的方向，我称之为 "硬规范"路线：
- 符号化、可证明、可审计
- 适合医疗、金融、法律等 有明确规则域
- 不适合创意、情感、开放式对话
- 从数据里学、从反馈里调
- 灵活、模糊、不可解释
- 适合大部分消费级应用
但如果有人把这套演算做成LLM的工具调用呢？
> "模型，先调用规范引擎检查permissibility，再决定回不回答。"
这可能是这篇论文最务实的落地方式。
六、一句话总结
Forbus团队用1980年代的符号武器，解决了一个2020年代LLM假装不存在的问题：规范会变的。演算精致，实验干净到失真，但方向是对的。硬规范需要硬逻辑，软规范需要软数据，别混着用。
---
参考文献
- Olson, T., Salas-Damian, R., & Forbus, K. D. (2026). Reasoning and Planning with Dynamically Changing Norms. arXiv:2605.27622.