ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

ziwei-doushu:把排盘、四化、格局和古籍做成 TypeScript 模块,外加一份 56.6 GB 解读数据集

ziwei-doushu:把排盘、四化、格局和古籍做成 TypeScript 模块,外加一份 56.6 GB 解读数据集

要在产品里加紫微斗数排盘,第一件麻烦事不是界面,而是规则:农历转换、安星、四化(禄权科忌)、大限、空宫借对宫,散在古籍和各家讲义里,没有可直接import的实现;第二件是解读——格局怎么判、夫妻宫怎么看、《骨髓赋》原文在哪,程序检索不到,也拼不进 prompt。

Renhuai123/ziwei-doushu(2026-05-01 创建)处理这两件事:一个 TypeScript 写的紫微斗数排盘引擎与 Next.js 站点,算法体系取自倪海厦《天纪》,仓库自述包含完整排盘算法、四化系统、格局知识库和古籍原文数据;站点 metisziwei.com 开放排盘、AI 解读、命盘历史。

先看一个容易误读的信号。截至 2026-10-31 00:10 UTC 那次推送,仓库有 12,068 star、2,364 fork、4 位贡献者、16 个 open issue。fork/star ≈ 19.6%,通常开源项目远低于此——更像镜像或抓取数据集留下的痕迹,而非协作开发。热度大体由传播驱动:README 里“56.6 GB / 877 万段 / 204 亿字”的对比表,比 API 更容易被截图转发。

它把术数对象工程化:命盘(出生数据经农历转换后安星布宫)、四化、格局(可规则识别、带吉凶与出处)、空宫借对宫、合婚,以及倪海厦“三纪”和古籍三级引用结构。按一份 codewiki 自动解析(Gemini 驱动,未经源码逐行核验,只能当参考;本次 DeepWiki 抓取被 Vercel 安全检查页挡住),引擎层在lib/ziwei/,含安星布宫、大限、四化、格局、合婚、真太阳时等模块;知识层是lib/classics古籍检索与lib/nihai三纪数据;表现层是 Next.js:表单→命盘→AI 对话→合婚→SEO 页。

安装和库用法目前不能确认。README 摘录在“关于六亲判断”处截断,安装章节、依赖管理、dev server、npm 发布信息都没有;也没有函数签名或 CLI 示例,我不编。能确认的只有:主语言与语言构成均为 TypeScript,Topics 含 nextjs,属于 Next.js 应用型仓库,常规路径大概率是 clone→装依赖→起 dev server,但这只是推断。56.6 GB 数据集是独立分发的大文件,不随常规克隆拿到,获取方式摘录里没有。AI 解读应依赖某家 LLM,但 README 未指明供应商。

许可双轨:代码 MIT、数据集 CC BY 4.0(需署名)。代码放开鼓励集成,数据留署名维持溯源与品牌,实质是想做该领域的事实数据标准。位置在“传统术数知识→结构化数据→AI 应用”的中间层,向上可被命理 App、内容站、Agent 复用。

以下为推断。真正的示范意义不在命理,而在“垂直领域知识 + 大规模合成语料 + 开源引流”这套打法,可平移到中医、风水、法律、传统戏曲等知识密集却缺结构化数据的领域。对命理行业,它把竞争焦点从“谁的算法准”推向“谁的数据全、谁的可引用”;数据集若被广泛采用,小玩家差异化空间会被压缩。商业化大概率是开源引流 + 站点变现(AI 解读额度、托管、API 授权、内容 SEO),风险在支付通道、应用商店政策与广告平台合规灰区。

最关键的一层:最大的资产恰好最不可验证。2026-10-15 发布的 v4.0 数据集:674,976 张命盘 × 13 维 = 877 万段解读,正文约 204 亿字,解压 56.6 GB,覆盖 1950–2026 且只含真实日期,每盘约 3.0 万字;相对 v3.0(51.84 万盘 / 33.1 GB / 覆盖 1924–1983 / 每盘 2.1 万字)命盘 +30%、段数 +30%、体积 +71%、覆盖 +17 年、每盘字数 +44%。README 主动承认 v3.0 每盘字数是按 2,160 张盘抽样估算,其余全量统计,这点值得肯定。但 204 亿字无法人工校验,生成方式未披露,没有抽样评估或纠错机制,排盘算法也缺少与人工排盘结果对照的公开测试证据;“基于倪海厦体系”意味着结论不具跨流派普适性。治理上,4 位贡献者、16 个 issue,几乎单一主维护者,巴士因子极低;56.6 GB 分发与 CC BY 4.0 署名义务,会给商用集成带来实际麻烦。README 那段“关于六亲判断”反而是好信号:它引倪海厦原话“斗数批六亲本来就比较差一点”,附 B 站视频与时间戳(2上 · 00:25:27),把知识边界写进文档而不是当 bug 掩盖。

所以判断它值不值钱,取决于你关心命理,还是“一门非结构化传统知识怎么变成 AI 可用的数据底座”。别用 star 数衡量:去看数据集实际下载量与引用量,看排盘引擎有没有以独立 npm 包被别处依赖,看有没有人工排盘对照测试,看 AI 解读是否建立公开评估与纠错机制。当仓库同时是 GB 级数据分发渠道时,star 与 fork 的语义已经失真;如果一门手艺真被拆成了数据,204 亿字里的错由谁负责。对工程师:适合拿它做命盘生成、古籍检索和 AI 解读原型;不适合把它当可安装 npm 库或未经核验的权威数据源直接商用。

RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进