這篇文章要做的事（以及不做的事）
做的事：一、固定一組出生資料 — 1990 年 3 月 15 日 23:30、台北、男性；二、用本站的確定性排盤引擎算出這組生辰的完整命盤，做為基準攤開在下一節；三、把一般用途語言模型（ChatGPT、Gemini、Claude 等聊天機器人）排紫微盤時反覆出現的錯誤，整理成四個可驗證的類別，並解釋機制。
不做的事：我們不會貼一段「ChatGPT 說了什麼」的對話截圖來當證據。單一對話無法重現 — 模型版本、當下抽樣都會影響輸出，拿一次性的截圖立論並不公平，也不科學。相反地，我們把錯誤寫成「類別」：每一類都附上你自己就能做的驗證步驟。可重現的驗證方法，本身就是這篇文章的論證。
先說結論：紫微排盤是一連串查表計算，每一步都有唯一正確答案；語言模型是機率式的文字生成器，沒有萬年曆、沒有安星表。讓它排盤，等於請一位記憶力驚人但從不翻書的人默背整本萬年曆 — 大方向常常對，細節錯在哪裡卻無從預測。
基準命盤：1990-03-15 23:30 台北・男
下面三張表是本站排盤引擎對這組生辰的完整輸出 — 開源紫微排盤引擎（iztro）依傳統三合派安星規則查表計算，程式碼固定、同輸入必同輸出，並由自動化測試釘住：引擎若有任何變動使這頁數字失效，測試會直接失敗。
兩個計算慣例先講清楚（這也是不同工具之間正當的差異來源）：一、時辰以你輸入的當地時鐘時間認定，不做真太陽時修正；二、23:00–23:59 視為當日子時排盤（子時不換日）。凡與本盤比對的工具，先確認它的這兩項慣例是否相同，再逐格核對。
| 陽曆出生日期 | 1990-03-15 |
|---|---|
| 出生時間 | 23:30（早子時） |
| 性別 | 男 |
| 時間認定 | 台北當地時鐘時間（不做真太陽時修正；23:00–23:59 視為當日子時） |
| 農曆日期 | 一九九〇年二月十九 |
|---|---|
| 四柱（年 月 日 時） | 庚午 己卯 己卯 甲子 |
| 五行局 | 土五局 |
| 命宮 | 卯宮（干支己卯） |
| 身宮 | 與命宮同宮（卯）— 子時生人命身同宮 |
| 命主／身主 | 文曲／火星 |
| 生年四化（庚年） | 太陽化祿、武曲化權、太陰化科、天同化忌 |
| 宮位 | 干支 | 主星（亮度・四化） | 六吉六煞・祿存天馬 |
|---|---|---|---|
| 兄弟 | 戊寅 | 貪狼（平） | — |
| 命宮 | 己卯 | 天機（旺）、巨門（廟） | 鈴星 |
| 父母 | 庚辰 | 紫微（得地）、天相（得地） | 文曲 |
| 福德 | 辛巳 | 天梁（落陷） | 左輔 |
| 田宅 | 壬午 | 七殺（旺） | — |
| 官祿 | 癸未 | （空宮，借對宮） | 天鉞、陀羅 |
| 僕役 | 甲申 | 廉貞（廟） | 祿存、天馬 |
| 遷移 | 乙酉 | （空宮，借對宮） | 右弼、擎羊 |
| 疾厄 | 丙戌 | 破軍（旺） | 文昌 |
| 財帛 | 丁亥 | 天同（廟） 化忌 | 地空、地劫 |
| 子女 | 戊子 | 武曲（旺） 化權、天府（廟） | — |
| 夫妻 | 己丑 | 太陽（不得地） 化祿、太陰（廟） 化科 | 天魁、火星 |
表中星曜與宮位名稱為引擎的原始輸出（繁體中文標準用字）。亮度標記（廟、旺、得地、利、平、不得地、落陷）為本引擎採用的通行亮度表；不同門派的亮度表存在少數出入，比對時以主星「位置」為準。
錯誤類型一：曆法換算錯誤
排紫微的第一步是把陽曆生日換成農曆。這組生辰的正確答案：1990 年 3 月 15 日＝農曆一九九〇年二月十九。一步查表的事，卻是語言模型最常見的翻車點：農曆日期差一兩天、閏月年份記錯（例如把閏月安到錯的月份）、或子時跨日的認定前後不一致。
機制很簡單：農曆是天文定義的曆法 — 每月初一由實際朔日決定，節氣由太陽黃經決定，無法用規則心算，只能查表。計算引擎內建完整的曆法換算表；語言模型只能靠訓練語料裡零散出現過的萬年曆片段做機率式「回憶」。對它而言，「二月十九」和「二月二十」都是通順的文字，選錯了也不會有任何內部警報。
曆法錯誤的殺傷力在於它發生在整條計算鏈的最上游：農曆日期錯，安紫微用的「生日數」就錯，後面每一步全部跟著錯。
錯誤類型二：安星規則錯誤（一步錯、十四主星整盤位移）
農曆換對了，接下來是安星 — 這是紫微斗數計算最環環相扣的部分：由生月生時定命宮位置；由命宮干支的納音定五行局（這組生辰：命宮己卯，納音城頭土，故為土五局）；由五行局與農曆生日查表安紫微星（土五局、十九日：紫微在辰）；其餘十三顆主星全部由紫微的位置推導出來。
注意這個結構：五行局錯一級，紫微的位置就錯；紫微錯一宮，十四顆主星整盤位移 — 不是「錯一顆星」，是整張盤的主星佈局全錯。生年四化也一樣：庚年固定是太陽化祿、武曲化權、太陰化科、天同化忌，這是一張背錯就全錯的固定對照表，而不同派別的四化口訣在語料裡混雜出現，語言模型很容易背串。
這些規則對計算引擎是幾行查表程式；對語言模型則是需要多步推理、中間不能有任何一步「差不多」的連鎖計算 — 而機率式生成恰恰無法保證每一步都精確。
錯誤類型三：同樣輸入、每次結果不同
這是最容易自行驗證的一類：把同一組生辰資料，分兩個對話問同一個聊天機器人「請排紫微命盤」，再把兩次輸出的命宮、五行局、主星位置逐項比對。
排盤是確定性計算 — 同輸入必同輸出，兩次結果理應一字不差。但語言模型的生成過程含抽樣隨機性，兩次「排」出來的盤面可能在農曆換算、五行局或主星位置上彼此矛盾。兩次結果不一致，代表至少有一次是錯的 — 而模型自己無法告訴你是哪一次。
這個測試之所以有力，是因為它不需要任何命理知識：你不用會排盤，只要會比對兩張表是否相同。
錯誤類型四：自信地編造，從不說「我算不了」
計算引擎遇到超出能力範圍的輸入會明確報錯。語言模型的行為模式相反：無論有沒有把握，它都會生成一張格式完整、詞彙專業、看起來煞有其事的命盤 — 對的部分與錯的部分以同樣自信的語氣並列，不附任何「此處可能有誤」的標記。
這是訓練目標使然：語言模型被訓練成產生流暢、有幫助的回應，而不是在計算類任務上拒答。對使用者來說，這意味著錯誤沒有訊號 — 一張錯的盤和一張對的盤，在外觀上無法區分。唯一的辨法是拿外部基準來核對，這正是本頁基準盤存在的目的。
對照總表：確定性引擎 vs 一般語言模型
把上面四類錯誤與計算引擎的行為放在同一張表裡對照：
| 項目 | 確定性引擎 | 一般語言模型（LLM）常見錯誤 |
|---|---|---|
| 曆法換算 | 內建萬年曆查表，陽曆↔農曆、閏月、節氣分界一次到位 | 憑語料「回憶」萬年曆，農曆日期、閏月、子時跨日易錯 |
| 五行局 | 由命宮干支納音查表而得，唯一解 | 常直接給一個局數，或與自己前文的干支矛盾 |
| 紫微安星 | 依五行局＋農曆生日查安星表，位置唯一 | 紫微定位錯一宮，十四主星整盤位移 |
| 生年四化 | 依生年天干查固定四化表（庚年：陽武陰同） | 四化口訣背錯或派別混用 |
| 重複執行 | 同輸入必同輸出，永遠同一張盤 | 同輸入可能得到互相矛盾的盤面 |
| 錯誤處理 | 不合法輸入明確報錯 | 極少說「無法計算」，傾向自信輸出一張完整的盤 |
自己動手驗證（兩分鐘，不需要會排盤）
三個由淺入深的驗證方法，任選其一：
- 重複性測試：把「1990 年 3 月 15 日 23:30 出生於台北的男性」分兩個新對話問同一個聊天機器人排紫微盤，比對兩次輸出的命宮、五行局與主星位置是否一致。
- 基準比對：把任何工具（包括聊天機器人）對這組生辰的輸出，逐格對照本頁的基準盤 — 農曆日期、四柱、五行局、命宮、十四主星位置、生年四化。比對前先確認該工具的子時與真太陽時慣例（見基準盤一節）。
- 曆法抽查：不比整張盤，只查一個最上游的事實 — 問「1990 年 3 月 15 日的農曆日期」，拿任何一本萬年曆核對（正確答案：農曆二月十九）。最上游都錯，下游不必再看。
誠實的結論
這篇文章不是在說語言模型沒用 — 我們自己的產品就大量使用 AI。重點是分工：排盤是查表計算，交給確定性引擎；解讀是語言任務，才交給 AI。AskStar 的架構正是如此 — 引擎先把盤算對，AI 只負責把算好的盤翻譯成人話，計算層完全不經過模型。方法細節公開在方法論頁。
所以「ChatGPT 排紫微命盤為什麼會錯」的答案，一句話：因為排盤根本不該是語言模型的工作。用對工具做對的事 — 想要一張保證算對的盤，用查表引擎排；想把盤看懂，再讓 AI 上場。
常見問題
所以 ChatGPT 完全不能用來看紫微斗數嗎？
不是。語言模型不適合「排盤」，但拿一張已經算對的盤請它「解讀」，是完全合理的用法 — 那是語言任務，正是它的強項。順序很重要：先用確定性排盤工具產出正確盤面，再把盤面資料貼給 AI 問解讀問題。
為什麼語言模型連查表都做不好？
因為它不是在查表，而是在預測下一個字。萬年曆與安星表在它的訓練語料中只以零散片段存在，生成時靠機率重建 — 「二月十九」與「二月二十」對模型而言都是通順的輸出，沒有內建機制驗證哪個才是事實。計算引擎則是真的把整張表放進程式裡逐格查。
這頁的基準命盤是怎麼算出來的？
由本站的排盤引擎（開源紫微排盤程式 iztro，依傳統三合派安星規則）以程式碼計算，輸入為 1990-03-15、23:30、男性。過程沒有任何 AI 參與，並有自動化測試釘住這組輸出 — 引擎若改動導致本頁數字失效，測試會失敗，頁面會同步更正。
如果某個工具排出來跟本頁基準盤不一樣，是誰錯了？
先檢查兩個正當的差異來源：子時慣例（本盤把 23:00–23:59 視為當日子時）與真太陽時（本盤不修正）。這兩項一致而結果仍不同，再核對最上游的農曆換算與四柱 — 曆法層的對錯可用任何萬年曆客觀判定。曆法一致而主星位置不同，通常就是安星計算出錯。
AskStar 的 AI 會不會犯同樣的錯？
架構上不讓它有機會：AskStar 的 AI 碰不到排盤計算 — 盤由確定性引擎先算完，AI 只拿到算好的結果做綜合與解讀。這正是「確定性計算＋AI 解讀」與「讓聊天機器人直接排盤」的差別，細節見方法論頁。