方法與邊界
計算、證據、解釋、驗證
這份說明寫清我們的排盤與解讀是怎麼做的、採用哪些口徑、哪些結論存在流派分歧,以及我們明確不做什麼。它應當是可核對的,而不是行銷文案。
四層流程
- 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