方法与边界
计算、证据、解释、校验
这份说明写清我们的排盘与解读是怎么做的、采用哪些口径、哪些结论存在流派分歧,以及我们明确不做什么。它应当是可核对的,而不是营销文案。
四层流程
- 01Calculate
计算:排盘由算法完成
历法换算、节气时刻、时区、真太阳时校正、四柱干支、藏干、大运顺逆与起运时间,全部由确定性算法计算并写入结构化字段。语言模型不参与这一步,也不允许从出生日期直接推断四柱。
- 02Evidence
证据:结论必须能列出依据
日主强弱、十神配置、合冲刑害、调候与格局都以可逐条检查的证据项输出:哪一个月令、哪一处通根、哪个干支被触发。分数只是这些证据的内部表达,不是判断本身。
- 03Interpret
解释:AI 负责表达,不负责计算
语言模型把结构化证据转写成可读的解释,说明结论的适用条件。存在流派分歧时,我们说明分歧点与当前采用的优先级,而不是把其中一种包装成唯一正确答案。
- 04Validate
校验:输出前做一致性与边界检查
解释生成后,我们检查它能否追溯到结构化证据项,并按主题边界过滤高风险内容。一致性校验(用神、喜神、忌神、仇神两两不等)是取用层的硬约束:调候表给出的辅助五行若与「生忌神者」重合,会按功能定义重新指派,并对全部 120 组日主×月支组合做回归验证。
引擎版本与变更记录
每次会改变计算结果的算法修正,都会提升引擎版本号并记录在这里。已经算好存下来的命盘如果版本号与当前不一致,会被当作过期结果重算 —— 重算用的是当时一并存下的同一份出生信息,所以真太阳时之类的口径不会丢。极少数情况下(早期记录缺少年、月、日、时、分等必要字段)无法忠实重算,这时保留原盘,而不是猜一个给你。纯文案与样式改动不提升版本号。
变更记录
- v52026-09-25
黄历吉时判定改用黄道黑道十二神
影响范围: 黄历
此前吉时是按「当日宜的条数多于忌的条数」推断的,方向性是错的:实测 2026-09-25 会把 5 个黑道时辰列为吉时,反而把当天唯一的青龙黄道时辰(庚子)列为凶时。现改为按十二值神的黄道/黑道属性判定;引擎异常时返回 degraded 标记,页面显示「暂无数据」而不是编造吉时。同一天还把 Web 端与引擎包里逐行相同的两份黄历实现合并为一份,避免两端算出不同结果。
- v42026-09-20
年柱改以立春为界,闰月盘与平月盘分开缓存
影响范围: 八字 · 紫微斗数
年柱此前按农历正月初一切换,导致立春到春节之间出生的人年柱错误;现以立春为界。同时紫微斗数的缓存 key 加入 isLeapMonth —— 此前闰月盘与平月盘共用同一个 key,会互相污染(缓存版本因此从 v3 提到 v4)。
- v32026-09-20
时干改用五鼠遁
影响范围: 八字
部分时辰的时干存在偏移,现统一按五鼠遁由日干推时干。
- v22026-09-20
修复 computeBaziAccurate 在特定输入下崩溃
影响范围: 八字
特定出生信息组合会让排盘函数直接抛错,导致整个结果页不可用。
- v12026-09-20
引入引擎版本号(回溯起点)
影响范围: 全站
此前没有版本概念,缓存失效靠人工改字符串。v1 是补记的起点,用于让后续版本号有参照。
可复现的验证
下面这些数字可以直接复跑,命令就写在仓库里。我们把「已知的差异」也写成测试钉住 —— 一份只报告通过的测试清单没有意义,能说清哪里不一致才有意义。
- 引擎回归测试(divination-core,bun test)
- 110
- Web 与移动端测试(bun test lib apps/mobile) · 29 个文件
- 215
合计: 325 · 2026-09-29
测试钉住的具体行为
- 日柱锚点:1949-10-01 = 甲子日。旧实现输出「庚申/戊子」,且结果随宿主时区漂移。
- 所有子时的时干符合五鼠遁。旧实现因旋转数组取值错误,**每个**子时的时干都是错的(癸日子时应为壬子,旧实现给甲子)。
- 年柱以立春换年,而不是农历正月初一。
- 闰月生日必须落到闰月当天。实测 2023 闰二月二十,旧实现差 30 天,且闰月下半月宫位不同。
- **已知差异被显式钉住**:23:00 不换日柱(早/晚子时是真实流派分歧,八字取「子正换日」);节气日边界使用近似表而非精确到秒的节气时刻。这两项是已知的、被测试记录下来的行为,不是未发现的缺陷。
测试通过只说明实现与我们所声明的口径一致,不代表这套方法本身经过科学验证。
我们采用的口径
八字存在多种同样有依据的传统做法。我们的原则是固定一套、记录下来、允许核对,而不是在不同页面使用不同规则。
- 时间基准
- 默认使用填写的钟表时间。真太阳时属于可选校正:只有在启用、且提供了出生地经度时,才按经度与均时差调整,并在结果中记录校正后的时间。
- 年柱边界
- 按立春的具体时刻切换,不使用元旦,也不使用农历春节。
- 月柱边界
- 按十二节(节气)的具体时刻切换,与农历月份无关。
- 子时换日
- 晚子时算当天还是次日属于流派差异,两种做法都有使用者。我们的实现固定采用一种规则并保持一致;如果你习惯另一种,日柱与十神会整体偏移,可以据此核对差异。
- 强弱与取用
- 扶抑与调候分别计算,**两层结论都会在排盘结果里呈现**。两者指向不同方向时,我们说明分歧点、当前采用哪一层、以及为什么这样选。差异本身不是错误:扶抑问的是日主能不能担得起,调候问的是季节的寒暖燥湿 —— 两个不同的问题。
- 临界盘
- 日主强弱是把多项加减累加成一个原始分、再按 75 / 60 / 40 / 25 分档。原始分落在某个阈值 3 分以内时,我们在排盘结果里直接标出来,并分两档:跨过去会换另一套取法(五神随之变化)的、只改变等级名称的。分档不是推断 —— 取用分支已抽成可对假设等级求值的纯函数,我们在阈值两侧各算一次完整五神(用神 / 忌神 / 喜神 / 仇神 / 闲神)再逐字比对。实测约四成命盘会落在某个阈值的 3 分容差内。
我们不做什么
健康
不提供疾病诊断、身体状态判断或治疗建议。健康问题请咨询专业医疗人员。
投资与财务
不提供股票、基金、加密货币的买卖点,也不预测具体价格。财务决策请依据合规的金融信息。
法律
不提供法律意见,也不判断诉讼结果。
人身安全
不对危险、事故或寿命做断言;涉及安全的问题请寻求现实中的专业帮助。
重大人生决定
不把命理结论作为婚姻、移民、辞职等决定的唯一依据。
确定性预言
不承诺具体事件的日期与结果。命理在我们的定位里是传统文化参考框架,我们不宣称它具备现代科学的有效性。
已知限制
- 出生时间不准确时,时柱相关结论的可靠性会明显下降;接近时辰或节气边界时尤其如此。
- 流派分歧无法被「解决」,只能被说明。我们在有分歧处标注,而不是隐藏。
- 临界盘我们会标注,但**标注不等于结论变稳固**:分数贴近阈值时,换一套加权口径就可能得到相反的用神方向,这个不确定性无法被消除,只能被说清楚。「跨过去会不会改变用神」这一档是**逐盘算出来的**,不是估计 —— 但也只是当前这套口径下的答案。
- 个别调候组合的仇神标签是按功能回退确定的(经典的调候辅助五行优先保留为喜神),与严格的「生忌神者」定义略有出入;这类组合请以「取用依据」为准。
- AI 解释可能出现措辞偏差。若某条解释无法在证据层找到依据,请以排盘与证据字段为准。
- 我们接受纠错:如果你发现排盘或规则上的错误,可以通过反馈渠道提交,我们会在后续版本修正。
常见问题
AI 会不会算错八字?
排盘由确定性算法完成并写入结构化字段,可以逐项核对。AI 只负责解释层,因此排盘错误与解释偏差是两类问题,前者可复现验证,后者可以通过证据层复核。
为什么不能只靠大模型直接排盘?
历法换算、节气时刻与时区校正依赖精确规则和历史数据,语言模型无法稳定复现。把确定性计算交给算法,是减少不可复现错误的关键。
你们的结果和命理师不一样,谁对?
多数情况是口径不同,而不是算错。常见差异来自真太阳时是否启用、子时换日规则、强弱权重与取用框架。可以逐项核对;我们会在方法说明页公开采用的规则。
你们怎么处理流派差异?
说明分歧点与当前采用的优先级。扶抑与调候两层都会算出来并在结果里呈现:一致时说明结论被两条独立路径印证,不一致时说明各自取什么、当前采用哪一层、为什么这样选。
如果两层结论互相矛盾怎么办?
用神、喜神、忌神、仇神两两不等是取用层的硬约束,全部 120 组日主×月支组合都有回归覆盖;一旦出现互相等同,我们按缺陷处理并修正。
你们会把结果当作科学预测吗?
不会。命理在我们的定位里是传统文化参考框架,我们不对其科学性作断言,也不鼓励用它替代现实中的专业判断。
相关词条
方法与边界 · 2026-09-20