大荒九丘观测台：基于象数体系的AI叙事珠子凝练架构实践

---

一、项目背景

大荒九丘是一个AI驱动的时空叙事引擎。核心挑战：LLM上下文窗口有限，如何长期保存叙事记忆并高效召回？

我们的方案：象数凝练——将叙事文本转化为卦象、五行、纳甲等结构化符号，实现信息压缩与层级聚合。

---

二、系统架构

[玩家对话] → [象数计算引擎] → [辰级珠子] → [日级凝练] → [更高级聚合]
                ↓
         [Prompt注入] ← [观测台调试]

• 前端：HTML/CSS观测台（对话区、实时珠串、观测面板）
• 后端：Node.js + MongoDB，珠子Schema支持多层级嵌套
• AI层：DeepSeek/Kimi API，Prompt动态注入象数约束
• 象数层：自定义卦象推导、五行衰旺计算、纳甲六亲映射

---

三、观测台功能模块

3.1 实时珠串

按时间层级（辰/日/半日/1日/2日）过滤，展示珠子流：

每颗珠子包含：

• beadId：唯一标识
• type：dialogue / move / event_trigger / celestial_change
• participants：参与者数组
• hexagram：卦象标签（坎为水、天泽履等）
• timestamp：游戏内时间戳

3.2 象数面板

单颗珠子展开后展示完整象数数据：

• 六爻图：阴阳爻可视化
• 五行条：木火土金水能量值
• 纳甲表：爻位-干支-六亲-世应-爻辞
• 命星共振：角色与当前时空的契合度

3.3 凝练溯源

日级珠子的父子关系树：

{
  "dayBead": "Y1-M1-D1",
  "sourceBeads": [
    {"hour": "H8", "hexagram": "坎为水", "type": "dialogue"},
    {"hour": "H9", "hexagram": "坎为水", "type": "dialogue"},
    {"hour": "H11", "hexagram": "坎为水", "type": "dialogue"}
  ],
  "totalNodes": 4,
  "maxDepth": 1
}

3.4 天象引擎

世界级珠子（celestial_change）记录天象变化：

• 天象变化：乾→坎（2时）
• 五层分解：年象·震卦、月象·复卦、日象·解卦、辰象·震卦
• 气场参数：冲击度、情、缘、身、势、物六维（待接入）

---

四、Prompt工程示例

象数如何转化为叙事约束？以坎为水为例：

陆苍雪，坎为水。
两阴夹一阳，阳被夹封住。八纯卦，坎气极盛，
角色的"阳陷阴中"特质被放大到纯粹——
"冷"不是态度，是热力学结构——热量只能走缝隙。

下方按爻位拆解身体部位、时空背景、心相、形相，供AI生成时参考。

---

五、当前进展与TODO

模块	状态
对话生成 + 象数注入	✅
实时珠串可视化	✅
辰→日凝练	✅
凝练溯源	✅
天象引擎接入	✅
珠子召回逻辑	🔄 开发中
月级/年级凝练	📋 规划中
前端架构升级	📋 草案阶段

---

六、技术选型

层级	技术
前端	HTML/CSS/JS（计划迁移至现代框架）
后端	Node.js + Express + MongoDB/Mongoose
AI API	DeepSeek / Kimi / Silicon Flow
象数计算	自定义算法（基于皇极经世时空模型）
部署	本地开发 + 辅助服务器（Win10改造）

---

七、开源计划

目前为个人项目，代码尚未开源。预计召回逻辑跑通后，会考虑开源核心框架（不含商业内容）。

欢迎技术交流，特别期待对以下方向的讨论：

• LLM长期记忆架构设计
• 符号系统（象数/占星/塔罗）的Prompt工程化
• AI叙事游戏的成本控制（Token优化策略）

---

项目：大荒九丘 · 时空叙事引擎
作者：雷

---

时间：2026年5月