FateShow 为何先算星盘再让 AI 解读：证据与生成的解耦之道

大多数 AI 占星产品的逻辑是：用户提交出生数据、地点和问题，模型一口气完成排盘、判断和撰写报告。FateShow 反其道而行——先用确定性引擎算出星盘，把结果压缩成结构化证据，模型只负责解读这份证据。如果解读与星盘不符，页面直接返回已经计算好的规则解读。

提示词优先的生成方式错在哪里

语言模型不应该被要求计算历法或行星位置。同样的输入可能产出不同的四柱、宫位或爻值，而流畅的文字恰好掩盖了这种偏差。重新生成一次报告，底层结论可能已经悄悄改变。

FateShow 在自己的流水线中观察到一个真实案例：英文报告路径上，星盘包含四个宫位，但模型有时只返回两个宫位的解读。如果此时让模型"补全"，就等于为它跳过的宫位凭空编造星曜。FateShow 的做法是从规则解读中按原索引回填缺失的宫位——宫位集合保持计算时的原样，不添加任何一颗星。

另一类错误完全出在计算层。转换农历日期需要显式的闰月标志。丢掉这个标志，一个闰五月就会被当成普通五月处理，月柱出错，其后的每一柱都跟着错。这种问题不该交给模型去"抹平"。

真太阳时是将钟表时间换算为太阳实际过中天的时间。地球绕日轨道为椭圆且自转轴倾斜，导致同一时区内不同经度的地点，太阳到达正午的时刻并不一致。出生地在时区西侧，真太阳时通常比民用时晚；东侧则偏早。在中国，东西横跨约五个时区宽度却统一使用北京时间，这一差值可能达到一至两小时，足以改变时辰边界甚至日界归属，从而影响四柱或紫微命宫。是否启用该开关因此是一项需要显式记录在星盘上的输入参数，而非可以交给模型随意推断的细节。

闰月是阴阳合历为协调朔望月与回归年长度差而设置的补偿月份。农历一个朔望月约 29.53 天，十二个月仅约 354 天，与回归年相差约 11 天，数年后季节就会漂移。置闰规则大致为十九年七闰，具体哪一个月为闰月由节气位置决定。闰月在其月份名前加“闰”字，如闰五月，是独立于普通五月的月份。排盘时必须显式携带闰月标志，否则月柱及其后各柱都会连锁出错。

计算在前：一条严格的生产流水线

紫微斗数的解读按以下顺序执行：

1. 校验出生数据、历法、时区、真太阳时开关、日界与所问之事。
2. 运行确定性排盘引擎。
3. 将星盘压缩为证据：宫位、主星、辅星、四化，以及已经带有 id 的规则判定。
4. 只把这份证据包交给模型。提示词中声明证据行数，要求宫位名称原样照抄，并将时间性论断限制在已有规则范围内。
5. 校验 JSON。丢弃不在输入中的宫位，丢弃不属于该宫位星曜列表的事实，丢弃规则层未输出的规则 id。按原始索引从规则解读回填缺失宫位。若摘要、证据或行动建议为空，直接拒绝。
6. 一旦拒绝、超时或供应商报错，返回规则解读并释放预留的额度。同一输入命中三十分钟缓存，重试不会悄悄替换措辞。简体中文与繁体中文永不共享缓存键。

六爻则更早冻结事实：服务器在起卦时就把六爻的爻值存下来，重新加载这个 id 不会重新起卦。解读环节拿到的是一张已完成的纳甲盘。模型必须引用至少两段出现在卦辞文本中的字符串。如果引用不匹配、调用超时或未配置密钥，页面依然展示规则解读。

核心逻辑可以简化成这样：

async function readChart(input) {
  const chart = await createChart(input);          // 确定性引擎
  const packet = toEvidence(chart);                // 只保留可引用的事实
  try {
    const raw = await model.explain(packet);
    const report = normalize(raw, packet);          // 宫位、星曜、规则 id 必须匹配
    return { report, source: 'ai' };
  } catch {
    return { report: ruleReport(packet), source: 'rules' };
  }
}

八字也按同样的方式组装：共享的出生模型先还原民用时间，在开关开启时应用真太阳时，构建四柱，然后在同一张盘上运行分析层。

四化是紫微斗数中由生年天干决定的一组星曜能量转化规则，具体表现为化禄、化权、化科、化忌四种标记，分别附加在特定主星上，改变其性质与作用方向。由于四化完全由生年天干推导，属于确定性计算，一旦天干确定，四化组合即固定。

纳甲是六爻占卜中将天干地支配入六十四卦各爻的方法，使每一爻都带有五行属性与干支坐标，从而可以按五行生克关系判断吉凶。纳甲盘是起卦完成后一次性生成的完整结构，爻值与干支对应关系在起卦瞬间就已冻结，后续解读只是对这一既成事实的文字说明。

真太阳时开关与日界是八字排盘中的两个独立边界参数。日界决定一天从 23:00 还是 00:00 起算，直接影响日柱归属；真太阳时开关决定是否对民用时间做经度修正。二者都会使同一出生数据落入不同的柱或宫位，因此必须作为星盘的显式字段存储，便于分歧时先比对参数再比对文字。

拆分引擎与解读层带来的实际收益

星盘事实是可复现的。立春决定的年界、23:00 或 00:00 决定的日界、两小时一个的时辰，以及真太阳时开关，共同决定了四柱。这些开关保留在星盘上。当两张盘出现分歧时，先比较开关，再比较文字描述。

调试因此有了清晰的接缝。星曜错了，是引擎或历法的 bug；句子空洞、宫位对不上、规则 id 从未被输出，则是解读层的 bug。重试模型不会让一根柱、一个宫位或一个爻值移动分毫。

测试也按同样的方式拆分。星盘测试针对固定输入断言字段；解读测试使用固定的证据包，检查多余星曜是否被剥离、缺失宫位是否被回填、空摘要是否被拒绝。

模型是可替换的。DeepSeek^广告 或其他供应商拿到的是同一份证据。如果供应商超时，用户看到的仍然是这张盘的规则解读。

多套系统，不共享计算器

FateShow 覆盖八字、紫微斗数、西洋占星、吠陀占星、人类图、数字学、六爻、梅花易数、奇门遁甲和雷诺曼。它们共享输入校验、时区解析，以及"证据进、文字出"的报告契约，但不共享计算模型。

共享层是出生记录、历史时区与夏令时、节气、天干地支和真太阳时。八字、紫微和西洋占星并列排布，一个领域不会调用另一个领域。当需要合并解读时，由上层把两张已完成的盘拼接起来。

各系统的差异如下：

系统	时间如何使用	引擎输出什么
八字	立春、节气月、日界、可选真太阳时	四柱、十神、藏干、旺衰与格局
紫微	年界与闰月决定命宫；真太阳时可能移动宫位	十二宫、星曜、四化、大限
西洋/吠陀/人类图	民用时间还原为世界时；不用真太阳时	行星与宫位、恒星位置与大运，或闸门与类型
数字学	仅使用公历日期	数字层级
六爻/梅花/奇门	提问时刻，提交时冻结；不是出生时间	爻值与纳甲、体用，或值符值使

数字学不该要求出生地，西洋盘不该继承中式 23:00 的日界，六爻的月日来自提问那一刻。把这一切塞进一个通用的星盘 JSON，会留下在某些系统中毫无意义的字段，而模型会用另一个系统的词汇去填充它们。

人类图（Human Design）综合了西洋占星的行星位置、易经六十四卦、卡巴拉生命之树与脉轮系统，由出生时刻的行星黄经映射为“闸门”与“爻”，构成能量中心与通道网络。其时间处理方式接近西洋占星，需要将民用时间还原为世界时后计算行星位置，不涉及真太阳时或农历闰月。

吠陀占星使用恒星黄道（Sidereal Zodiac），与西洋占星的热带黄道相差约 24 度的岁差，因此同一时刻的行星落宫可能不同。其大运系统（Vimshottari Dasha）按行星周期分段，时间尺度可精确到年、月、日。

奇门遁甲以提问时刻的干支构建九宫盘，包含值符、值使等动态符号，属于时间敏感型占卜，与出生时间无关。雷诺曼则使用固定牌组与牌阵位置，时间参与度更低。各系统对时间的依赖方式差异巨大，共用一套时间模型必然引入错误。

三次失败换来的修正

引擎与分析层没有共享同一套键名。 八字引擎输出英文键，分析层读中文键。两边看起来都实现了，结果每个分析字段都是空的。修法是在组装层做一次形状转换，让两层读同一张盘。

中文字数预算被套用到了英文上。 摘要上限约 500 字符，而 100 个英文单词接近 600 字符，句子被从中间截断。上限被提高到足以容纳一个完整英文句子，中英文的长度规则分开编写。

宫位名称按精确匹配处理。 输入写的是 soul，模型返回 Soul 或另一种译法，整行证据就消失了。现在的匹配忽略大小写，并通过术语表把译法映射回来。回填使用原始索引，事实不会被按名称二次配对。

六爻 demo 还有一条独立约束：纳甲库的许可证不适合放进主站打包，而内存中的起卦会在进程重启后消失。站点保持同一原则——冻结爻值，再做解释——并在自己的层面集成这一步。

这套思路能迁移到哪里

当生成文字必须与某个来源绑定时，先完成来源、存储来源，再只把模型允许引用的证据交给它。校验失败时返回来源本身，不要让模型去补窟窿。

同样的约束出现在金融、法律检索、健康信息和教育场景中。模型的工作是说清事实已经是什么，而计算、检索与规则才是让事实站得住脚的东西。FateShow 在命盘、合盘与占卜中采用的就是这个顺序。