ziwei-doushu：TypeScript 紫微斗数排盘与13维解读数据集
给紫微斗数开发者的TypeScript排盘引擎，另附56.6GB的13维解读数据，不是完整商业站点。
GitHub Renhuai123/ziwei-doushu 更新 2026-10-24 分支 main 星标 6.9K 分叉 1.4K
TypeScript 紫微斗数 Next.js 16 数据集

🧭 决策指南

为什么现在热： 材料显示，项目在2026-10-24登上GitHub Trending daily，当日新增546星；此前于2026-10-15发布v4.0，提供674,976张命盘、877万段13维解读，压缩包仅161MB。README还强调405处古籍引证逐字校正。上述大规模新数据集、近期发布与内容校正是当前受关注的可见原因，但无法从材料确认GitHub用户关注的唯一原因。

适合，如果你

  • 你要在Next.js 16中嵌入本地排盘、命盘展示和古籍阅读器。
    README“快速开始”和“界面是一份 Demo”说明排盘、命盘展示、古籍阅读器可在浏览器运行，框架为Next.js 16。
  • 你要获取可检索的13维本命盘语料，并能接受v4.0解压后的56.6GB规模。
    README“新、13维解读数据集v4.0”列出674,976张命盘、8,774,688段解读和56.6GB解压后大小。
  • 你在做小模型微调或RAG，需要51.8万input-output配对。
    README“二、51.8万命盘样本数据集”明确列出微调小模型训练语料和AI对话RAG检索源。

不适合，如果你

  • 你需要开箱即用的AI解读或合盘AI接口，而不准备实现`/api/interpret`和`/api/heming`。
    README“快速开始”说明开源版不含后端API，这两个接口需要自行实现。
  • 你需要线上商业版的完整交互、分享卡片或AI流式解读。
    README“界面是一份Demo”明确说明线上商业版界面不在开源范围，Demo不含这些功能。
  • 你的商业产品必须直接批量使用docs/tianji-ziwei/中的倪师原话。
    README“协议”规定倪师原话采用CC BY-NC-SA 4.0，不许商用。

前置条件

  • 需要Node.js/npm环境；README给出的安装命令是`npm install`。
  • 运行Demo可执行`npm run dev`；只看排盘可跳过`.env.local`配置。
  • AI解读需要自行实现`/api/interpret`和`/api/heming`，API Key本身不会启用接口。
  • 完整下载v4.0需处理161MB压缩包、56.6GB解压数据和zstd长窗口参数`--long=27`。
  • v4.0数据按公历1950–2026年、真实日期、12时辰和男女生成。

第一步命令（README 原文）

npm install

要注意

  • v4.0的`h`是0–11时辰序号，不是钟点；出生地真太阳时校正不在数据集内。
    README“口径说明”和JSON Lines字段表。
  • 2026-10-20后默认星曜亮度改为《斗数全书》，但v4.0仍按旧默认“现代修正v2”生成。
    README“2026-10-20补充”明确说明新默认与v4.0生成口径不同。
  • Demo的`db-analysis.ts`是占位实现，不能把线上13主题断语当作已开源代码使用。
    README“界面是一份Demo”和“开源边界”。
  • 涉及六亲的父母、兄弟、子女维度，README引用《天纪》说明其分析仅供参考。
    README开头“注：关于六亲判断”。

替代方案

  • metisziwei.com：需要在线排盘、AI解读和命盘历史，而不是自建Next.js Demo时更合适。
    README“在线体验”与“快速开始”
  • v3.0样本数据集：只需要51.8万条样本、希望避开v4.0的56.6GB解压规模时更合适。
    README“二、51.8万命盘样本数据集”与v4.0规格表

材料未说明

  • README未说明支持的Node.js具体版本。
  • README未给出运行v4.0完整数据处理所需的最低内存、CPU或磁盘性能。
  • README未说明`npm run dev`启动Demo的具体端口和生产构建部署步骤。
  • README未说明线上`metisziwei.com`的AI后端实现方式和模型名称。
  • README未提供与其他排盘库在准确率或性能上的量化对比。

💡 深度解析

6
不适合 我使用 Next.js 16，想克隆仓库、配置 API Key 后直接上线 `/api/interpret` 和 `/api/heming`，不打算补写后端接口；这个项目能满足吗？
适合读者： 想克隆仓库后直接上线 AI 解读和合盘 AI 功能、使用 API Key 而不计划自行实现后端接口的 Next.js 产品开发者

不适合，因为开源仓库不包含 AI 解读和合盘 AI 的后端路由，配置 API Key 也不会自动启用这些功能。

  • README“快速开始”明确写出，/api/interpret 和 /api/heming 需要使用者自行实现；未实现时页面会直接提示“开源版不含该接口”。
  • README“开源边界”把 AI 解读 prompt、后端 API、用户系统和服务端安全都列为不开源内容。
  • db-analysis.ts 只是占位实现，Demo 能画出命盘，但不包含线上商业版的断语内容。
  • 项目提供 patterns.ts 和 heming-knowledge.ts 作为知识参考，却没有交付完整的模型调用、鉴权、限流或输出安全层。

所以它适合做前端和排盘基础，不适合“不写后端就直接上线 AI 服务”的约束。

  • README「三、快速开始」：AI 解读 `/api/interpret` 和合盘 AI `/api/heming` 需要自行实现，配置 API Key 不会变成可用
  • README「六、界面是一份 Demo」：`db-analysis.ts` 是占位实现，Demo 不包含线上断语内容
  • README「七、开源边界」：AI 解读 prompt、后端 API、用户系统、服务端安全不开源
  • README「七、开源边界」：可参考 `patterns.ts` 和 `heming-knowledge.ts` 自行构建 prompt
npm run dev
材料未说明：README 未说明推荐使用哪些 LLM、模型供应商或服务端运行时实现这些接口；README 未说明线上商业版 AI 接口的具体请求协议、提示词结构和响应格式
不适合 我想把 v4.0 解读数据和《天纪》原话一起用于商业 RAG 或模型微调，并希望统一按 CC BY 4.0 处理；这个项目满足我的授权约束吗？
适合读者： 要把 v4.0 解读数据和倪海厦《天纪》原话一起放入商业 AI 产品、并要求所有训练或检索文本都可商用的数据工程师

不适合，因为仓库明确采用分层授权，倪海厦《天纪》原话及解读中的相关引文不属于 CC BY 4.0 商用范围。

  • README“九、协议”规定，代码是 MIT、v3.0/v4.0 数据是 CC BY 4.0，但 docs/tianji-ziwei/ 原话目录使用 CC BY-NC-SA 4.0，明确“不许商用”。
  • README“二·新、13 维解读数据集 v4.0”说明数据中的部分断语包含《天纪》原话，并注明集数和时间码；数据集许可证又特别排除了这些引文。
  • 古籍原文属于公有领域，但不能据此推导出《天纪》语料也能商用。

因此，纯粹使用不含受限引文的 CC BY 数据仍可能可行，但项目没有提供已清洗的商业安全子集。你必须先确认每段文本的来源和授权，不能整体导入商业系统。

  • README「九、协议」：代码 MIT；数据 CC BY 4.0；倪师原话 CC BY-NC-SA 4.0，“不许商用”
  • README「五、倪师《天纪·紫微斗数》原话」：这一章内容单独采用 CC BY-NC-SA 4.0
  • README「二·新、13 维解读数据集 v4.0」：解读中的倪师原话注明《天纪》集数与时间码
  • 项目洞察 common_pitfalls：数据集中的倪师原话不属于 CC BY 4.0 数据授权范围
材料未说明：README 未提供已完成的逐条引文清单，无法仅凭数据集总许可判断每条文本是否含受限语料；README 未说明商业产品中缓存、向量索引和模型权重是否需要额外的授权处理
不适合 我需要用当前默认的《斗数全书》星曜亮度口径复现 v4.0 文本，并要求亮度相关解读完全一致；可以直接把当前排盘结果和 v4.0 混用吗？
适合读者： 想在项目当前默认口径下复现 v4.0 解读的紫微斗数研究者，要求 2026-10-20 之后的排盘结果与数据集亮度文字完全一致

不适合直接混用，因为 v4.0 于 2026-10-15 按旧的“现代修正 v2”生成，而网站在 2026-10-20 已把默认亮度改为《斗数全书》口径。

  • README 的补充说明明确指出，v4.0 数据集中的亮度字和少量随亮度变化的解读句，可能与当前默认排盘结果不同。
  • 当前默认口径补齐了天姚、天刑、天喜、大耗、解神、截空、副截、旬空等亮度；月德不再标亮度。
  • 项目仍保留“现代修正 v2”作为可选流派设置，因此复现 v4.0 时应使用生成数据时的旧口径，而不是当前默认值。

这意味着数据集适合独立检索，但不满足“当前默认排盘 + 旧文本完全一致”的要求。项目没有说明是否存在完整的自动迁移或重生成脚本。

  • README「2026-10-20 补充」：v4.0 按旧默认“现代修正 v2”生成，亮度字和少量相关解读可能与新默认不同
  • README「2026-10-20 补充」：当前默认改为《斗数全书》，现代修正 v2 仍可在流派设置里选
  • README「上一轮更新」：`school-data.ts`、`school-tables.generated.ts`、`school-config.ts` 提供星曜亮度流派数据与配置
材料未说明：README 未提供将 v4.0 全量文本按新默认口径重生成的命令或产物；README 未量化受星曜亮度口径变化影响的具体记录数量
适合 我的服务使用出生地经度做真太阳时校正，用户输入的是 0–11 的地支时辰序号；我还必须正确处理中国 1986–1991 夏令时，这个引擎能覆盖这些约束吗？
适合读者： 维护使用真实太阳时的中国出生地排盘服务、需要覆盖中国 1986–1991 夏令时并且输入时辰来自地支序号的 TypeScript 开发者

适合，README 明确列出了真太阳时、经度差、均时差、中国历史夏令时和 0–11 地支时辰处理，但你必须按项目字段语义接入，不能把时辰当作小时数。

  • 更新说明显示 dst-cn.ts 新增 chinaDSTSpan(year)，覆盖中国 1986–1991 夏令时起止规则。
  • true-solar-time.ts 负责经度差与均时差；cities.ts 还补充了省直辖县级单位和新疆兵团城市经度。
  • README 明确指出 hour 是时辰地支索引 0–11，子时为 0、亥时为 11，不是 0–23 的钟点。
  • 项目已有 768 张回归盘，覆盖夏令时、日期和时辰边界等场景。

因此能力范围匹配，但 README 没有保证所有城市、历史输入和流派组合都已穷尽验证。

  • README「上一轮更新」：`true-solar-time.ts` 处理经度差 + 均时差，`dst-cn.ts` 处理中国 1986–1991 夏令时
  • README「本轮更新」：`chinaDSTSpan(year)`；`cities.ts` 补全多个中国城市经度
  • README「上一轮更新」：`hour` 一直是时辰地支索引 0–11，不是 0–23 小时数
  • README「三、快速开始」：`npm test` 覆盖 768 盘及夏令时、时辰序号边界等回归
npm test
材料未说明：README 未列出每个城市经度的完整覆盖清单及经度来源精度；README 未说明真太阳时校正对极端历史日期和所有省级地区组合的误差范围
适合 我正在使用 Next.js 16 App Router 和 TypeScript，想把排盘嵌入网站，并要求基本排盘不依赖 API Key 或后端服务；这个项目适合直接作为引擎吗？
适合读者： 需要把紫微斗数排盘集成到 Next.js 16 App Router 网站、并希望浏览器端完成基本排盘而不维护后端 API 的 TypeScript 开发者

适合，因为项目已经把排盘核心放在可复用的 lib/ziwei/，并支持浏览器端完成基本排盘。

  • README“快速开始”明确说明，排盘、命盘展示和合盘起盘都在浏览器里完成，不需要任何 API Key。
  • README“排盘引擎”列出农历公历转换、闰月边界、晚子时、真太阳时、中国 1986–1991 夏令时、星曜亮度和运限上下文等处理。
  • 代码采用 MIT License，可在自定义前端中复用；但仓库界面只是最小 Demo，线上商业版 UI、用户系统和后端安全并未开源。

因此它适合作为计算层，不是开箱即用的完整产品。第一步可先启动 Demo 验证输入和配置是否符合你的页面模型。

  • README「三、快速开始」：排盘、命盘展示、合盘起盘都在浏览器里完成，不需要任何 API Key
  • README「四、排盘引擎」：排盘内核全部在 `lib/ziwei/`
  • README「六、界面是一份 Demo」：仓库界面是最小可运行示例
  • 项目数据：主语言 TypeScript；topics 包含 nextjs、typescript；许可证为 MIT
npm install
材料未说明：README 未说明将 `lib/ziwei/` 单独打包为独立 npm 库时的正式 API 稳定性和版本兼容承诺；README 未说明浏览器端在不同设备上的性能、包体积和内存占用
适合 我需要为 1950–2026 年命盘构建 RAG，但机器不能长期容纳解压后的 56.6 GB；我能否按年份接入 v4.0，而不是下载和加载全部数据？
适合读者： 准备构建紫微斗数 RAG 数据管道、只处理 1950–2026 年数据并且磁盘无法长期容纳 56.6 GB 解压文件的 AI 数据工程师

适合，v4.0 的发布格式就是按年份拆分，能够避免一次性处理全部 56.6 GB。

  • README“本轮更新”说明，674,976 张命盘、8,774,688 段解读被分成 77 个按年份文件，压缩后总计约 161 MB，可只下载需要的年份。
  • 数据覆盖 1950–2026 年真实日期、12 时辰和男女组合，每张盘包含 13 个分析维度，适合建立离线检索字段。
  • README 同时提醒，解压需要 zstd 的 --long=27；数据集还存在未按出生地做真太阳时校正的限制，不能直接视为任意地点的最终结果。

所以它适合作为年份级离线数据源，但你仍需自行设计 JSONL 索引、查询层和地点校正策略，项目没有交付现成 RAG 服务。

  • README「一、本轮更新」：按年份分 77 个文件，可以只下需要的年份；压缩后约 161 MB
  • README 顶部数据表：674,976 张命盘、8,774,688 段解读、解压后 56.6 GB、覆盖 1950–2026
  • README「二·新、13 维解读数据集 v4.0」：13 个分析维度
  • 项目洞察 common_pitfalls：解压必须带上 zstd 的 `--long=27`；v4.0 未按出生地做真太阳时校正
材料未说明：README 未给出按年份文件的具体下载命令、JSONL 字段完整定义和推荐索引实现；README 未说明单个年份文件的精确大小及建立随机查询索引所需的内存

✨ 核心亮点

  • v4.0覆盖674,976张命盘与877万段13维解读
  • 排盘内核含真太阳时、中国夏令时与闰月边界
  • 古籍引证从244处增至405处并逐字校正
  • v4.0解压需56.6GB，压缩包为161MB
  • 代码采用MIT，数据集采用CC BY 4.0

🔧 工程化

  • `lib/ziwei/`提供排盘、四化、运限与古籍数据
  • v4.0以JSON Lines提供13维本命盘解读
  • `npm test`覆盖768盘及夏令时、日期边界
  • Demo支持Next.js 16界面与14主星知识图谱

⚠️ 风险

  • v4.0解读数据解压后达56.6GB，存储门槛较高
  • 开源版没有`/api/interpret`和`/api/heming`后端
  • Demo的`db-analysis.ts`只是占位，不能提供线上断语
  • 倪师原话目录采用CC BY-NC-SA 4.0，不许商用
  • v4.0按时辰序号排盘，未按出生地校正真太阳时

👥 适合谁？

  • 需要TypeScript排盘内核或Next.js Demo的开发者
  • 做RAG或小模型微调、能处理51.8万配对数据的团队
  • 需要MIT代码与CC BY 4.0数据的商业产品团队