GPT88 / API Docs
ব্লগে ফিরে যান

从 9,000 星动态看紫微斗数开源排盘引擎：Renhuai123/ziwei-doushu

开发工具2026-10-3013 মিনিট পড়ুন紫微斗数开源项目TypeScriptNext.js数据集排盘引擎GitHub

本文根据 王多鱼 AI 在 X 的原帖、Renhuai123/ziwei-doushu 公开 README、目录和许可证整理。原帖发布于 2026 年 10 月 29 日，作者称项目 GitHub 星标从 8,000 增长到 9,000 用时不到三天，并提到向专业版用户发放额外额度；这部分属于原帖自述，本文不把它扩展为独立核验的产品或运营结论。项目技术、数据规模和授权边界以仓库当前公开内容为准。

Renhuai123/ziwei-doushu 开源紫微斗数排盘引擎

这条动态为什么值得拆开看

社交媒体上的“破 9,000 星”很容易把注意力集中在数字上，但这个仓库更值得看的地方，是它把一个传统术数应用拆成了几个可以独立复用的工程层：浏览器内运行的排盘内核、可下载的数据集、用于展示内核的最小前端、古籍和知识图谱，以及各自不同的授权条款。

这意味着它不只是一个在线排盘页面，也不是一个只展示截图的 Demo。你可以从算法、数据、界面和协议四个角度阅读它：

出生信息 → 时间与历法校正 → 排盘算法 → 宫位 / 星曜 / 四化 / 格局
                                      ↓
                         Demo 界面、古籍阅读器、知识图谱、数据集

项目到底开源了什么

GitHub 仓库的描述是“基于倪海厦《天纪》体系的紫微斗数开源排盘引擎”，技术栈是 Next.js 16、TypeScript、Tailwind CSS、CSS Variables、Framer Motion，以及 iztro 和 lunar-javascript。仓库当前公开的代码和数据可以分为几层：

层次仓库内容适合怎么用
排盘内核lib/ziwei/ 中的 TypeScript 模块研究排盘口径、替换为自己的 UI 或服务
Demo 前端app/、components/跑通出生信息表单、命盘格、古籍和百科
结构化知识lib/seo/、patterns.ts 等构建检索、规则展示和内容工具
数据集51.8 万样本数据集、13 维解读数据集 v4.0RAG、研究、数据分析和模型实验
古籍与讲解lib/classics/、docs/tianji-ziwei/阅读和核对传统文献、出处时间码

README 也特意写清楚：开源界面是一套最小可运行示例，线上商业版的断语库、AI prompt、后端 API、用户系统和服务端安全并不在仓库里。运行 Demo，不等于获得了线上产品的全部能力。

排盘内核的几个关键工程问题

真太阳时与时区不能被写死

true-solar-time.ts 根据出生地经度和均时差做真太阳时校正；最新说明还支持海外出生地传入固定标准时区偏移。这样做的重点不是多一个选项，而是把“出生地当地钟表时间”和“用于排盘的太阳时”分成两个可检查的步骤。

项目还将中国 1986—1991 年夏令时作为可判定的历史区间，并用 clock-adjust.ts 让用户确认后把钟表读数换成标准时间。README 明确提醒：引擎只判定，不自动替用户扣除夏令时。涉及跨日时，也不应偷偷改写用户输入。

闰月、晚子时和流派差异需要显式配置

仓库将闰月归前月、归后月、按日切分和按本月等口径做成可配置项；晚子时也允许切换换日策略。星曜亮度提供七档，并保留不同流派的对照表。

对于这类领域软件，最危险的往往不是代码报错，而是程序在没有提示的情况下替用户选择了一套口径。把分歧暴露成配置，才能让结果可复现、可解释、可回归。

规则库要与算法分层

algorithm.ts 负责完整排盘流程，sihua.ts 处理生年、大限和流年四化，patterns.ts 放置 1,100 多行格局判定规则，cities.ts 提供城市经纬度，famous.ts 保存示例命盘。这样的拆分让“排盘事实”和“解释规则”不必挤在同一个函数中，也便于为边界条件增加测试。

大数据集：可下载不等于可以随意复述

仓库 README 将 2026 年 10 月 15 日发布的 v4.0 解读数据集描述为：674,976 张命盘、13 个维度、8,774,688 段解读，解压后约 56.6 GB，按年份提供压缩文件。数据由排盘引擎和断语库确定性生成，README 声明同一输入会得到同一输出，不经过 AI。

这类数据集的工程价值很清楚：可以用作 RAG 检索源、训练或微调实验、规则变更前后的基线，或者用于统计分析。它也带来两个需要同时保留的边界：

  1. 口径边界：数据集是某个内容版本的快照，线上引擎和知识库继续更新后，新旧输出可能不同。
  2. 内容边界：解读中引用的作者原话不自动包含在数据授权里，使用者仍要按对应许可处理。

README 还说明，开源版的 db-analysis.ts 只是占位实现，真正的线上断语库没有放进仓库。因此，不应该把“数据集规模”误写成“仓库里包含了线上全部解读内容”。

从克隆到跑起来

项目提供的是常规 Node.js 开发流程：

git clone https://github.com/Renhuai123/ziwei-doushu.git
cd ziwei-doushu
npm install
cp .env.example .env.local
npm run dev

只看本地排盘时不需要 API Key。仓库说明排盘、命盘展示和合盘起盘都在浏览器里使用本地引擎；AI 解读接口需要使用者自己实现 /api/interpret 等后端能力，配置一个 Key 并不会自动补齐这些接口。

验证入口也比较直接：

npm run typecheck
npm test

README 列出的回归覆盖包括 768 张盘、紫微规则、夏令时、立春边界、红鸾天喜、时辰序号、日期合法性和同宫双四化等。对于排盘软件，这些测试比只验证页面是否能打开更有价值，因为很多错误只会在边界日期或特定口径组合中出现。

分层许可：使用前先看清楚对象

仓库不是“一份 MIT 文件”这么简单，而是分层授权：

内容许可使用要点
代码、Demo 和工程文件MIT保留许可证和版权声明
51.8 万样本数据集、v4.0 数据集CC BY 4.0商用可以，但必须保留来源标注
《骨髓赋》《紫微斗数全书》等古籍原文Public Domain仍建议保留版本和来源说明
docs/tianji-ziwei/ 中的倪师原话CC BY-NC-SA 4.0可引用和改编，但不得商用，改编需同协议

最稳妥的做法是把代码、数据、古籍和现代讲解分开存储，在产品的 About、数据集卡或文档中分别写清来源。尤其不要因为数据集采用 CC BY 4.0，就把其中的引文单独当作同一协议的内容。

适合怎样的二次开发

如果你的目标是做一个可研究、可复现的传统知识工具，可以按下面的顺序拆解：

  1. 先运行 Demo，确认出生日期、时辰和地点输入如何进入排盘流程。
  2. 阅读 lib/ziwei/，把历法校正、主星安置、四化和格局判断分别画成测试样例。
  3. 用小规模样本验证你的数据读取、缓存和检索流程，再考虑处理完整数据集。
  4. 为每一处引用附带原始出处、版本和许可证，不把“模型生成的解释”伪装成古籍原文。
  5. 如果接入 GPT88 或其他模型，只把模型用于可解释的检索、归纳和交互层，保留排盘输入、规则版本和数据集版本，方便复盘。

这也是这类项目适合接入统一大模型接口的地方：模型负责把结构化结果组织成易读说明，排盘内核负责产生可复核的结构化事实，数据层负责给出明确版本。三者分开，才不会让一次提示词改动悄悄改变底层排盘口径。

来源与边界