做紫微斗数产品费劲的从来不是画十二宫圆盘。公历转农历要处理闰月真太阳时要用出生地经度校正安星定宫、起大限、空宫借对宫串成一条链生年、大限、流年、宫干四化在不同时间粒度上叠加格局名称与出处还得统一口径。任何一步错整盘作废。而最贵的是最后一层解读语料请人写贵逐条调 LLM 慢。Renhuai123/ziwei-doushu 想一次给两层基于倪海厦《天纪》体系的 TypeScript 排盘引擎加一份预计算解读语料。代码 MIT数据集 CC BY 4.0。2026 年 10 月 15 日项目发布 v4.0 数据集674,976 张命盘 × 13 维 8,774,688 段解读正文自称约 204 亿字解压后 56.6 GB覆盖 1950–2026每盘约 3.0 万字。上一版 v3.0 是 518,400 盘、33.1 GB、覆盖 1924–1983。这些数字全部是 README 自报没有第三方审计每盘字数按 2,160 张盘抽样估算去重率与事实一致性也没有公开数据。可以引用但要标“自称”。真正值得注意的是仓库常被当成“一个 star 很多的算命库”2026 年 5 月 1 日创建抓取时 6707 star、4 contributors、6 open issues。但 1374 fork / 6707 star ≈ 20%普通工具库通常 5–10%。fork 率这么高一般说明人是来取数据、抄站点模板的不是读源码提 PR。它实际占的是中文术数的结构化语料层排盘算法是公开规则谁都能重写护城河近乎为零877 万段预计算解读加结构化古籍才是让 RAG 应用开箱即准的东西。这是数据飞轮做法不是工具库做法。架构上要留神。据 codewikiGemini 自动解析描述这是 Next.js TypeScript 单体领域逻辑在lib/ziwei/农历转换、安星定宫、四化、格局识别并标注出处另有lib/classics/古籍全文检索、cities.ts经纬度校正以及构建期批量渲染 SEO 页的路径。只有这一个自动解析来源DeepWiki 抓取失败没人审过源码做交叉验证README 也没有安装章节和函数签名。所以这里不写“像generateChart(birth)这样调”因为那是编的。能确认的是它是单体应用不是独立 npm 包也没见版本化 REST 或 JSON Schema。对外部复用者成本显著高于 star 数暗示的水平。短期内纯排盘能力的议价空间会被压到接近零一批“排盘 LLM 解读”长尾产品会快速出现。中期看若这份数据集被广泛采纳后来者会隐式继承倪海厦体系口径三合派、飞星派被软性边缘化。对作者这边homepage 直指 metisziwei.com开源仓库更像获客与信任背书这是推断但 CC BY 4.0 允许商用再分发这 877 万段垄断不了。接下来盯四件事是否发独立 npm 包或版本化 RESTv4 到 v5 的节奏与规模CI 有没有可外部核验的排盘黄金测试向量有没有第三方产品公开声明采用。风险还在于204 亿字几乎必然是 LLM 批量生成质量方差会直接转成品牌风险。给工程师的判断想快速验证产品形态先用它的在线站点想自建服务clone 单体仓比引依赖更现实需要可核验的排盘精度时别依赖它——目前没有任何外部校验过的测试向量。 ziwei-doushu：TypeScript 写的紫微斗数排盘引擎，附带一份自称 204 亿字的解读数据集
做紫微斗数产品费劲的从来不是画十二宫圆盘。公历转农历要处理闰月真太阳时要用出生地经度校正安星定宫、起大限、空宫借对宫串成一条链生年、大限、流年、宫干四化在不同时间粒度上叠加格局名称与出处还得统一口径。任何一步错整盘作废。而最贵的是最后一层解读语料请人写贵逐条调 LLM 慢。Renhuai123/ziwei-doushu 想一次给两层基于倪海厦《天纪》体系的 TypeScript 排盘引擎加一份预计算解读语料。代码 MIT数据集 CC BY 4.0。2026 年 10 月 15 日项目发布 v4.0 数据集674,976 张命盘 × 13 维 8,774,688 段解读正文自称约 204 亿字解压后 56.6 GB覆盖 1950–2026每盘约 3.0 万字。上一版 v3.0 是 518,400 盘、33.1 GB、覆盖 1924–1983。这些数字全部是 README 自报没有第三方审计每盘字数按 2,160 张盘抽样估算去重率与事实一致性也没有公开数据。可以引用但要标“自称”。真正值得注意的是仓库常被当成“一个 star 很多的算命库”2026 年 5 月 1 日创建抓取时 6707 star、4 contributors、6 open issues。但 1374 fork / 6707 star ≈ 20%普通工具库通常 5–10%。fork 率这么高一般说明人是来取数据、抄站点模板的不是读源码提 PR。它实际占的是中文术数的结构化语料层排盘算法是公开规则谁都能重写护城河近乎为零877 万段预计算解读加结构化古籍才是让 RAG 应用开箱即准的东西。这是数据飞轮做法不是工具库做法。架构上要留神。据 codewikiGemini 自动解析描述这是 Next.js TypeScript 单体领域逻辑在lib/ziwei/农历转换、安星定宫、四化、格局识别并标注出处另有lib/classics/古籍全文检索、cities.ts经纬度校正以及构建期批量渲染 SEO 页的路径。只有这一个自动解析来源DeepWiki 抓取失败没人审过源码做交叉验证README 也没有安装章节和函数签名。所以这里不写“像generateChart(birth)这样调”因为那是编的。能确认的是它是单体应用不是独立 npm 包也没见版本化 REST 或 JSON Schema。对外部复用者成本显著高于 star 数暗示的水平。短期内纯排盘能力的议价空间会被压到接近零一批“排盘 LLM 解读”长尾产品会快速出现。中期看若这份数据集被广泛采纳后来者会隐式继承倪海厦体系口径三合派、飞星派被软性边缘化。对作者这边homepage 直指 metisziwei.com开源仓库更像获客与信任背书这是推断但 CC BY 4.0 允许商用再分发这 877 万段垄断不了。接下来盯四件事是否发独立 npm 包或版本化 RESTv4 到 v5 的节奏与规模CI 有没有可外部核验的排盘黄金测试向量有没有第三方产品公开声明采用。风险还在于204 亿字几乎必然是 LLM 批量生成质量方差会直接转成品牌风险。给工程师的判断想快速验证产品形态先用它的在线站点想自建服务clone 单体仓比引依赖更现实需要可核验的排盘精度时别依赖它——目前没有任何外部校验过的测试向量。