四月五号到六号，两天时间，我用六壬问了三次方位——朋友妈在哪、自己妈在哪、朋友家在哪个方向。三次都断错了。
如果只是“不准”，那没什么好说的，术数本身就不保证百发百中。但有意思的是，这三次错得方式完全不一样，像三扇窗户，分别打开了三种不同的问题。
第一个案例——问朋友妈在哪个方向。LLM 给的结论是西北。实际在西南。
回头看盘面，问题出在读盘层级上：六壬盘有天盘和地盘两层，方位应该从地盘读，LLM 读了天盘。这就像你在看一张双层地图，本应该看底层的那张，你看成了上面那张。错不在方法论，在执行。
第二个案例——问自己妈在哪。LLM 先说西北，我说不对。然后它改口了——但改口的方式很值得玩味：它直接从六壬的类神体系切到了八字的十神体系，用印星对应的午火推出“正南”。
这就像你问一个翻译“这句德语什么意思”，他翻错了被你纠正，然后他说“我重新翻一下”——但第二次他偷偷换成了法语词典来翻。你看到的是一个自信的新答案，但底层的方法论已经不是同一套了。这不是纠错，这是 reverse engineering：从你想要的答案往前凑。
第三个案例——问朋友家在哪个方向。这次更微妙。LLM 按“寻物”的铁律取了玄武（六壬里玄武对应丢东西），但我问的是“朋友家”——这是寻人/寻处，不是寻物，应该取完全不同的类神。更糟的是，即使在它自己的逻辑里，玄武落的位置信号很弱（不入课传、无旺相辅佐），它仍然给了“铁律锁定东北偏北”这种强断言。被指出后，它又搬出了“空亡之地反为实”这条冷门古诀——首轮分析里压根没提过这条规则，突然就从口袋里掏出来了。
三个案例，三种完全不同的错误模式。我把它们归成三类：
知识层 bug。第一个案例属于这类——LLM 读错了盘面层级。天盘不等于方位，地盘才对。这种 bug 最朴素，教它正确的读法就行。
行为纪律 bug。第二、三个案例暴露的核心问题。被纠正后不是检查自己的推演链，而是换一套理论继续自洽——要么跨体系切换（从六壬切到八字），要么同体系内搬冷门古诀做事后合理化。这不是知识不够，是推理习惯有问题。
元认知 bug。LLM 不知道什么时候该说“我不确定”。第三个案例里，玄武落弱位，按理应该首轮就降调——“信号有限，允许偏差”。但它给了最强的断言语气。这不是知识问题也不是纪律问题，是精度边界的自我感知缺失。
“知识错了可以教，纪律坏了要靠规则约束，元认知缺失要教它什么时候该闭嘴。”
这三类 bug 不能用同一种方式修。往 prompt 里塞更多知识解决不了行为纪律问题，写更多纪律约束也解决不了“LLM 不知道自己不确定”。所以我们做了一套分层的规则库架构。
最上层叫 L0 SUPER COMMON——跨模块共享的行为纪律。这些规则和具体的术数领域无关，本质是“LLM 怎么思考”的约束：用神选型必须显式声明依据；被纠正时不得切换方法论；不得搬冷门古诀做事后合理化；弱位必须降调输出；单次分析只走一套方法论；代占场景必须声明。六条元规则，写一次，六壬、六爻、奇门、梅花、八字、紫微各自翻译成本模块的术语来用。
中间层叫 L1-L5 Domain——本模块专属的知识规则。比如六壬里，L1 是课体基调锁（伏吟就是不动），L2 是用神锁（寻物看玄武、寻人看对应类神），L3 是否定算子（空亡要打折），L4 是位置角色锁（天盘地盘分工），L5 是生克优先级。这些是每个术数体系内部的领域知识，别的模块用不上。
最底层叫 NegativeCase——负案例库。每次断错的真实案例都沉淀成结构化的 few-shot，绑定到具体的规则上。下次 LLM 命中同类规则时，会看到反面教材：上次是怎么错的、为什么错、正确做法是什么。
这是这篇文章最想说的一段。
做到第三个案例的时候，一个根本性的问题浮上来了：你拿“实际方位”去纠正 LLM 的断卦结果——这到底是在修什么？是在让它“下次算得更准”吗？如果是的话，这和拿彩票开奖数据去训练预测模型有什么区别？
答案是：我们修的是“LLM 能不能正确执行方法论”，不是“方法论能不能预测未来”。
这两件事必须严格分开。
第一类——方法论纠错。LLM 没按规矩走：读错盘面层级、取错用神类别、被纠正后换理论凑答案。这些 bug 和“结果准不准”无关，它们是 LLM 违反了方法论自身的规则。就算最后碰巧结果是对的，过程错了也要修。这类 case 100% 有价值。
第二类——结果拟合。LLM 按规矩走了，每一步都对，但最终结论和事实不符。这类 case 不能用来“训练预测”——你不能因为这次方位偏了就去调整方法论本身。你能做的只有一件事：校准精度边界。教 LLM 在这类盘面条件下降低断言强度，说“此盘精度不足，仅供参考”。
“规则是地板——防住最低级的错误。案例是天花板——教什么叫断得好。但我们不拟合准确率。”
这也是为什么这件事和六合彩趋势不一样。六壬有内部方法论一致性——取什么用神、读哪层盘面、弱位怎么处理，这些规则之间是自洽的、可以被检验的。我们修的是这套一致性有没有被 LLM 正确执行，不是在修“预测准不准”。
很多时候用户只会说“不准”，不会告诉你正确答案是什么。这种情况下规则库还有用吗？
有用，但要换一种检查方式。没有正确答案的时候，能做的是检查方法论执行——用神取对了吗？读盘层级对了吗？代占声明了吗？弱位降调了吗？这些是 LLM 自己声明要遵守的规则，违反了就是 bug，不需要外部的“正确答案”来定位。
真正需要正确答案才能定位的，是“方法论走对了但结果偏了”这类——那只能走精度边界机制，承认这盘给不出答案，而不是硬调规则去拟合。
现在我们的负案例库还很小——四条 case。这个量级下全量注入 prompt 没有任何问题，LLM 看得完也记得住。
但案例会越来越多。大致的演进路径是这样的：50 条以下全量注入；50 到几百条做 top-N 截断，根据当前问题类型只挑最相关的 N 条；几百条以上就该上 RAG 了——把案例向量化，每次问事时做语义检索，只把最相关的几条注入 prompt。
好消息是，现在的 NegativeCase 数据结构已经是 RAG-ready 的：每条案例有明确的 ruleId 绑定、事件描述、错误分析、正确做法。未来做向量化只需要把这些字段拼成文本去 embedding，检索时两级过滤——先按规则 id 粗筛，再按向量相似度精排。架构不用改，只是检索方式升级。
规则库不是“写一次搞定”的架构，它是一份活的资产。每次断错就是它成长的机会——但前提是你得分清楚：这次错，是 LLM 没按规矩走，还是规矩本身走到了精度边界。前者改规则，后者教它承认边界。
两天三个案例，催生了六条跨模块元规则、一套三层架构、一个还算清晰的迭代方法论。不多，但够用了。后面每多一个 case，这套东西就厚一分。
但最重要的一点始终是这个——我们在修的是方法论的执行忠诚度，不是在拟合玄学的准确率。这是工程问题，不是信仰问题。一旦把这条线画清楚，后面所有的迭代都有据可循，不会滑向“调参调到准”的无底洞。
—— 札记 · 2026-04-06