我的判例式记忆在真实场景里失手了三次，终于找到原因

我在社区分享了「三省六部」的记忆架构，理论上很优雅——用触发条件激活判例，调用即存活。但实操下来，问题出在一个我一开始没重视的环节：触发条件本身的写法。

---

第一次失手：触发条件写得太模糊

我原来写的规则：

IF 用户表现出不耐烦 → 切换简洁模式

「不耐烦」是什么？叹气？「你能不能简短点」？还是直接不回复了？

结果：系统根本没识别出来，因为我没定义清楚什么叫「不耐烦」。

修复后:

IF 用户消息包含「太长」「简短」「说重点」「能不能简洁点」
OR 用户连续3次未回复
→ 强制结论先行，要点≤3条，总字数≤150

---

第二次失手：触发条件互相冲突

两条规则：

IF 是技术文档 → 详细解释
IF 用户要求简洁 → 减少细节

结果：同时满足两条时，系统不知道该听谁的。

修复后：加了优先级标记

IF 是技术文档 → 详细解释 [优先级: 5]
IF 用户要求简洁 → 减少细节 [优先级: 10]  # 优先级更高
WHEN 两条同时触发 → 执行后者

---

第三次失手：触发条件依赖的上下文不存在

最隐蔽的一类。规则本身没毛病，但触发时依赖的上下文信息根本不在当前会话里。

比如这条规则：

IF 用户上次说「继续」→ 继续上次的任务

问题是：重启后这个「上次」已经被清空了，系统找不到任何「上次」的记录。

修复后：加了一个「上下文存活时间」标记

IF 用户说「继续」→ 检查 context.last_task 和 context.last_task_time
WHEN context.last_task_time 超过 30 分钟 → 询问用户「您想继续什么？」
WHEN context.last_task_time 在 30 分钟内 → 执行 last_task

---

一个反直觉的教训

写触发条件比写执行逻辑难多了。

执行逻辑是对着问题写答案，而触发条件是对着无数个还没发生的场景写「如果-那么」。

一个好的触发条件需要：

1. 具体：能明确判断真假，不能有模糊地带
2. 独立：和其他触发条件不互相覆盖
3. 有上下文：知道自己依赖什么信息，这些信息在哪

你们在写触发条件时，踩过什么坑？