技术解读
Liki：把命理拆成可测试、可引用、可复现的工程问题
项目背景与痛点
命理类软件一直处于两个极端。一端是查表式 App：排盘算法粗糙，闰月处理随意，节气边界含糊，紫微安星照抄错误版本的歌诀；另一端是大模型时代的懒惰做法——直接把“帮我算算八字”扔进 prompt，让 LLM 生成干支。结果显而易见：模型连六十甲子都会算错，更不用说真太阳时修正和奇门布局。
命理行业真正的门槛不在“说几句漂亮话”，而在两件很工程化的事：排盘必须是可复现的确定性计算；断语必须有文献依据、能被同行复核。Liki 这个项目的价值主张，恰恰是把这两件事拆开做——计算归计算，解释归解释。
核心技术揭秘
最关键的架构决策，是确定性计算与生成式解释的彻底分离。命理计算中有大量对精度极度敏感的环节：八字月柱以节气交接时刻为界，而非农历初一；紫微斗数安星依赖农历日期与时辰；奇门遁甲还牵涉超神接气、拆补与置闰的流派之争。这些都不可能交给 LLM 的“浮点直觉”。
Liki 所述的“天文历算引擎”，意味着排盘层走的是真实历法/星历算法，而非近似查表：公历与农历互转、节气精确时刻、真太阳时与经度时区修正，这些都能做成独立可单测的纯函数模块。这一层产出的是结构化命盘数据——四柱、藏干、十神、大运、流年、星曜、局数——而不是一段文字。
第二层是知识层。所谓“断语附经典出处”，本质是把《渊海子平》《三命通会》《滴天髓》《紫微斗数全书》《增删卜易》这类典籍内容，整理成带元数据的结构化知识条目，检索时连同出处一起取出，让模型只承担“翻译成人话”的职责，而不是自由发挥。这既是防幻觉的手段，也是行业信誉的底线。
第三层是 Skill 化封装。以 Skill 形态发布，说明它的服务对象是 Agent 调用：输入自然语言，输出应当是带引用的结构化结论，中间经过意图路由、确定性计算、知识检索、生成与校验。
图中最后的校验环节值得单独说一句：“结论可验证”是这类项目最容易喊空话的地方。真要落地，要么靠规则约束（生成内容必须引用知识库条目 ID），要么靠回测（用历史命例统计断语命中率）。前者是工程，后者是科研，都很贵。
功能亮点与差异
边界划得清。 大多数竞品把“排盘”和“解读”混在同一条链路里，Liki 明显把前者做成了可独立调用、可单独测试的引擎。这是它敢谈“可验证”的底气所在，也是从工程视角看最大的差异点。
溯源意识。 断语带出处，等于给生成内容装了引用锚点。用户可以顺着去读原典，而不是被一句“大师说”糊弄过去。
一套底座、多个盘种。 八字、紫微、六爻、奇门、择日、风水、起名七个模块看似杂，但底层共享同一套历法引擎与知识溯源机制。扩展新盘种的边际成本被压得很低——这是模块化设计带来的实际收益。
应用场景与落地建议
适合：C 端产品的排盘与解读能力、命理师的辅助工具（快速排盘与引用检索）、Agent 平台的付费技能。不适合：对精度要求极低、只想“玄学娱乐”的轻量场景，那类需求用纯 LLM 编造反而更便宜。
落地时有几点需要注意：
- 版本化排盘结果。 历法算法会迭代，尤其节气时刻与真太阳时口径。同一个人两次排盘出现差异是致命事故，务必在输出中带上算法版本号并做结果缓存。
- 把流派做成开关。 早子时还是晚子时、是否用真太阳时、奇门走拆补还是置闰，命理圈本就没有统一答案。硬编码一个值会得罪一半用户。
- 校验层不能省。 至少做“引用条目是否存在”和“断语要素与盘面是否一致”两项检查，避免模型输出命盘里根本不存在的十神。
- 合规定位。 国内对命理内容的监管边界敏感，“文化参考/娱乐”定位与免责声明是产品化的前置条件，不是可选项。
综合评价
优点：架构分工正确——算的归算，说的归说；溯源机制有真实的行业价值；Skill 形态契合 Agent 生态；底座复用度高。
缺点：知识库覆盖深度是长期工程，短期内容易退化成少数几本常引书的浅层映射；七个盘种一次性铺开，每个方向的精细度必然被摊薄；如果“可验证”没有回测数据支撑，终究只是宣传语。
一句话总结：Liki 真正的价值不在于“会算命”，而在于它把命理这件事拆成了可测试、可引用、可复现的工程问题——这比任何一句玄妙的断语都更难做到。
相关仓库
为什么几个 token 能搞定却要用很多 token。一个爆火的技能 + 编码代理的代理，像穴居人那样说话，可削减 65% 的 token。
RAGFlow 是一款领先的开源检索增强生成（RAG）引擎，将前沿 RAG 与 Agent 能力融合，为 LLM 构建卓越的上下文层
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?v=4)
评论