做紫微斗數(shù)產品費勁的從來不是畫十二宮圓盤。公歷轉農歷要處理閏月真太陽時要用出生地經度校正安星定宮、起大限、空宮借對宮串成一條鏈生年、大限、流年、宮干四化在不同時間粒度上疊加格局名稱與出處還得統(tǒng)一口徑。任何一步錯整盤作廢。而最貴的是最后一層解讀語料請人寫貴逐條調 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ù)的結構化語料層排盤算法是公開規(guī)則誰都能重寫護城河近乎為零877 萬段預計算解讀加結構化古籍才是讓 RAG 應用開箱即準的東西。這是數(shù)據(jù)飛輪做法不是工具庫做法。架構上要留神。據(jù) codewikiGemini 自動解析描述這是 Next.js TypeScript 單體領域邏輯在lib/ziwei/農歷轉換、安星定宮、四化、格局識別并標注出處另有l(wèi)ib/classics/古籍全文檢索、cities.ts經緯度校正以及構建期批量渲染 SEO 頁的路徑。只有這一個自動解析來源DeepWiki 抓取失敗沒人審過源碼做交叉驗證README 也沒有安裝章節(jié)和函數(shù)簽名。所以這里不寫“像generateChart(birth)這樣調”因為那是編的。能確認的是它是單體應用不是獨立 npm 包也沒見版本化 REST 或 JSON Schema。對外部復用者成本顯著高于 star 數(shù)暗示的水平。短期內純排盤能力的議價空間會被壓到接近零一批“排盤 LLM 解讀”長尾產品會快速出現(xiàn)。中期看若這份數(shù)據(jù)集被廣泛采納后來者會隱式繼承倪海廈體系口徑三合派、飛星派被軟性邊緣化。對作者這邊homepage 直指 metisziwei.com開源倉庫更像獲客與信任背書這是推斷但 CC BY 4.0 允許商用再分發(fā)這 877 萬段壟斷不了。接下來盯四件事是否發(fā)獨立 npm 包或版本化 RESTv4 到 v5 的節(jié)奏與規(guī)模CI 有沒有可外部核驗的排盤黃金測試向量有沒有第三方產品公開聲明采用。風險還在于204 億字幾乎必然是 LLM 批量生成質量方差會直接轉成品牌風險。給工程師的判斷想快速驗證產品形態(tài)先用它的在線站點想自建服務clone 單體倉比引依賴更現(xiàn)實需要可核驗的排盤精度時別依賴它——目前沒有任何外部校驗過的測試向量。