项目案例 · 个人实践图册

玄枢 · 多体系命理交叉验证

不抹平冲突,只呈现证据。

15 套命理体系各自独立排盘,压到同一坐标系里交叉验证:哪条断言、出自哪本典籍、置信度多少,全部可查。这是一个学习与研究项目,不作预测服务。

问题

命理体系之间没有共同语言:八字说「日主壬水,食伤泄秀」,星盘说「水星刑火星」,塔罗说「恋人逆位」。格式、术语、语义完全不同——直接放在一起投票毫无意义,所谓"交叉"只是把不相干的话排在一起。

这个行业"看起来很准"的秘诀,是把算出来的、猜出来的和编出来的混在一起说。这个项目做相反的约定——

"计算层错了就是 BUG;解释层永远不能冒充事实;对拍不过 ground truth 的算法,如实标注未验证,不硬凑。"

三层纪律

每一条输出都能回答一个问题:你属于哪一层,凭什么这么说。

  1. 计算层

    排盘、行星位置、起卦、数字根——确定性运算,可独立对拍验证,错了就是 BUG。

  2. 映射层

    传统术语翻译成七个现代维度(事业、财运、感情、健康、人际、心智、时机)——解释性判断,置信度显式压低。

  3. 解释层

    自然语言阐述由模型生成,必须标注来源,永不进入验证层——不参与任何一致性计算。

已接入的 15 套体系

可靠性上限是防误用设计:塔罗的置信度再高也不会超过 0.2——这不是自谦,是防止弱证据在加权时被当成强证据。

15 套体系、实现来源与判断依据(典籍出处)
体系 实现来源 可靠性 判断依据
紫微斗数iztro(Node 子进程)0.65《紫微全书》《太微赋》
八字 · 四柱lunar-python0.60《子平真诠》《滴天髓》
西方本命星盘ephem0.55—(整宫制,无典籍)
太乙神数手写,72 局表对拍0.45《太乙金镜式经》《太乙淘金歌》
月相 · 日月角距ephem0.50—(几何量)
易经 · 梅花易数时间起卦算法0.35《梅花易数》
奇门遁甲手写(转盘 · 拆补)0.35《烟波钓叟歌》
大六壬手写(九宗门)0.35《六壬大全》
六爻 · 纳甲筮法手写(京房八宫)0.30《增删卜易》
玄空飞星 · 阳宅手写(下卦盘)0.30《沈氏玄空学》
八宅命卦 · 三元九运农历年命卦0.30《八宅明镜》
生命灵数数字根0.25—(纯象征编码)
塔罗 · 三张牌阵随机(seed 可复现)0.20—(无预测能力)
占星骰子随机(seed 可复现)0.20—(无预测能力)
卢恩符文随机(seed 可复现)0.20—(无预测能力)

冲突就是输出

体系打架时不做加权平均和稀泥。八字依《子平真诠》说顺遂、塔罗抽出高塔说阻碍——这个矛盾本身就是最重要的信息:它可能意味着该维度确实处于变动中,也可能意味着某个体系的输入有问题。两种可能都值得知道,抹平它是一种欺骗。

同样,每个体系在每个维度上先内部聚合成一票再跨体系比较——否则星盘动辄几十条断言,会靠数量压过只有几条断言的八字。那不是交叉验证,是嗓门比赛。

验证记录

以下是有日期的对拍与测试记录。验证的是排盘算法的正确性,不是命理本身的有效性。

2026-09-22 验证记录(工程检查,非实时数据)
日期 项目 结果 说明与限制
2026-09-22 跨引擎四柱对拍 一致 八字走 lunar-python、紫微走 iztro,两套完全独立的历法实现排出同一组四柱——这是对「输入数据正确」的强验证。
2026-09-22 太乙 72 局表对拍 太乙宫 / 文昌 12/12 以《武经总要》72 局表为 ground truth;计神 / 始击 12 局拟合(标 REVIEW)。
2026-09-22 太乙主算 / 客算 未验证(最高 3/12) 暴力搜索无法复现局表,相关断言已压低置信度,仅作参考——对拍不过就如实标注,不硬凑。
2026-09-22 玄空飞星结构性事实 通过 数学恒等式验证:逆飞必使当运星归本宫;下卦盘只有旺山旺向与上山下水两种结局(与元运无关),测试遍历八宫确认。
2026-09-22 QC 测试 4 套 全部通过 太乙对拍、玄空结构、质检机制自证(合成坏数据必须报警)、15 引擎全链路冒烟(0 BLOCKER)。
2026-09-22 15 引擎全链路推演 0 BLOCKER · 0 冲突 本人命盘样本:七维度共识全部生成,一致性 0.75–0.99。单次样本,不构成统计结论。

本页为静态记录,不是实时仪表盘;数据不会随时间自动更新。

边界与已知限制

  • 「传统术语 → 现代生活维度」是解释而非事实。命理讲财官印食,不是事业财运感情;映射规则是本项目的判断,不是古人原意。
  • 塔罗、占星骰子、卢恩为随机象征系统,无预测能力,如实标注、权重最低,不参与主导结论。
  • 太乙主算 / 客算未能对拍 72 局表,相关结论(迫、关、囚、杜塞)置信度已压低,仅作参考。
  • 玄空飞星需实地坐向与建成年份,远程不占;峦头(外部形貌)不可远程,结论上限已声明。
  • 所有输出不构成医疗、法律、投资建议;本项目是学习与交叉验证方法的练习,不作预测服务。
  • 排盘引擎为本地项目,代码不随本站分发;本页是方法与验证记录的公开说明。

我的角色

"我负责需求定义、体系取舍、验证标准与结果验收;排盘引擎由 AI 编程工具按典籍口径实现,问题通过对拍与独立检查发现与修正。"

看看另一次实践

同样的纪律,用在 AI 协作上:把任务、依赖与验收写清楚。