做紫微斗數(shù)產(chǎn)品費勁的從來不是畫十二宮圓盤。公歷轉(zhuǎn)農(nóng)歷要處理閏月真太陽時要用出生地經(jīng)度校正安星定宮、起大限、空宮借對宮串成一條鏈生年、大限、流年、宮干四化在不同時間粒度上疊加格局名稱與出處還得統(tǒng)一口徑。任何一步錯整盤作廢。而最貴的是最后一層解讀語料請人寫貴逐條調(diào) LLM 慢。Renhuai123/ziwei-doushu 想一次給兩層基于倪海廈《天紀》體系的 TypeScript 排盤引擎加一份預計算解讀語料。代碼 MIT數(shù)據(jù)集 CC BY 4.0。2026 年 10 月 15 日項目發(fā)布 v4.0 數(shù)據(jù)集674,976 張命盤 × 13 維 8,774,688 段解讀正文自稱約 204 億字解壓后 56.6 GB覆蓋 1950–2026每盤約 3.0 萬字。上一版 v3.0 是 518,400 盤、33.1 GB、覆蓋 1924–1983。這些數(shù)字全部是 README 自報沒有第三方審計每盤字數(shù)按 2,160 張盤抽樣估算去重率與事實一致性也沒有公開數(shù)據(jù)?？梢砸玫獦恕白苑Q”。真正值得注意的是倉庫常被當成“一個 star 很多的算命庫”2026 年 5 月 1 日創(chuàng)建抓取時 6707 star、4 contributors、6 open issues。但 1374 fork / 6707 star ≈ 20%普通工具庫通常 5–10%。fork 率這么高一般說明人是來取數(shù)據(jù)、抄站點模板的不是讀源碼提 PR。它實際占的是中文術(shù)數(shù)的結(jié)構(gòu)化語料層排盤算法是公開規(guī)則誰都能重寫護城河近乎為零877 萬段預計算解讀加結(jié)構(gòu)化古籍才是讓 RAG 應用開箱即準的東西。這是數(shù)據(jù)飛輪做法不是工具庫做法。架構(gòu)上要留神。據(jù) codewikiGemini 自動解析描述這是 Next.js TypeScript 單體領(lǐng)域邏輯在lib/ziwei/農(nóng)歷轉(zhuǎn)換、安星定宮、四化、格局識別并標注出處另有l(wèi)ib/classics/古籍全文檢索、cities.ts經(jīng)緯度校正以及構(gòu)建期批量渲染 SEO 頁的路徑。只有這一個自動解析來源DeepWiki 抓取失敗沒人審過源碼做交叉驗證README 也沒有安裝章節(jié)和函數(shù)簽名。所以這里不寫“像generateChart(birth)這樣調(diào)”因為那是編的。能確認的是它是單體應用不是獨立 npm 包也沒見版本化 REST 或 JSON Schema。對外部復用者成本顯著高于 star 數(shù)暗示的水平。短期內(nèi)純排盤能力的議價空間會被壓到接近零一批“排盤 LLM 解讀”長尾產(chǎn)品會快速出現(xiàn)。中期看若這份數(shù)據(jù)集被廣泛采納后來者會隱式繼承倪海廈體系口徑三合派、飛星派被軟性邊緣化。對作者這邊homepage 直指 metisziwei.com開源倉庫更像獲客與信任背書這是推斷但 CC BY 4.0 允許商用再分發(fā)這 877 萬段壟斷不了。接下來盯四件事是否發(fā)獨立 npm 包或版本化 RESTv4 到 v5 的節(jié)奏與規(guī)模CI 有沒有可外部核驗的排盤黃金測試向量有沒有第三方產(chǎn)品公開聲明采用。風險還在于204 億字幾乎必然是 LLM 批量生成質(zhì)量方差會直接轉(zhuǎn)成品牌風險。給工程師的判斷想快速驗證產(chǎn)品形態(tài)先用它的在線站點想自建服務clone 單體倉比引依賴更現(xiàn)實需要可核驗的排盤精度時別依賴它——目前沒有任何外部校驗過的測試向量。