大荒九丘 · 文档分层实验：从皇极经世到 AI 上下文管理

象核摘要

• 先天卦：坤上乾下（泰卦）—— 上下交而志同
• 主爻：九二，“包荒，用冯河”—— 容人所不容，行人所难行
• 气脉：这是我个人在长期独立开发中摸索出的文档管理思路，借用了邵雍的时间层级观念，尝试用"变动频率"替代单一的模块目录来重新组织信息
• 变爻风险：不同项目规模、团队人数、技术栈差异很大，这套方法并非普适公式，仅供参考
• 关联象：皇极经世书（元会运世）→ 文档分层；三才分工（天地人）→ AI 阅读策略
• 归档预警：随项目演进持续调整，建议每季度回顾一次层级划分是否合理

---

一、问题：文档膨胀之后的迷失

在独立开发大荒九丘的过程中，我遇到一个越来越重的负担：文档的膨胀速度远超代码。

起初，我把文档按模块平铺——场景系统/、角色系统/、时间引擎/……每个文件夹里堆着设计稿、会议纪要、哲学讨论、Bug 记录、工作日志。前期尚能应付，但当 AI 开始深度参与工程后，问题爆发了：

• AI 每次读取上下文，都要在大量无关文档中翻找，还没开始思考，token 已耗尽
• 我自己也常常忘记某份架构讨论到底写在哪个子目录里，10 秒能解决的问题变成 10 分钟的翻找
• 哲学文档与施工文档混在一起，AI 时而把世界观设定当成接口契约来执行，时而把临时 Bug 记录当成长期架构来引用

我逐渐意识到，文档管理不仅是"归档"问题，更是"上下文边界"问题。当 AI 成为开发团队的一员时，文档的组织方式直接决定了它的理解精度。

---

二、思路：借用皇极经世的时间层级做文档分层

2.1 从邵雍那里得到的启发

邵雍《皇极经世》以元、会、运、世等层级理解时间。给我最大的启发是：不同尺度的时间，承载不同粒度的信息。元是数十年的大势，会是数年的节律，运是数月的流转，世是数日的当下——上层不是下层的简单叠加，而是下层的"摘要"与"统摄"。

我把这个思路借用到文档管理中，尝试按变动频率而非仅按功能模块来分层：

层级	皇极映射	变动频率	内容	谁维护	怎么读
元册	元	数月~数年	哲学总纲、世界观、核心卦象定义	人道（我）	只读摘要，按需调取
会典	会	数周一变	架构总图、模块边界、接口契约	小天道	索引匹配，精准读取 1–3 份
运志	运	数日一变	版本计划、施工步骤、Agent 任务单	小天道	增量读取，只读最新变更
世录	世	数时辰一变	Bug 记录、测试报告、工作日志	小地道	局部读取，按任务 ID 调取
归藏	—	归档冻结	已废弃文档、已完成归档	—	默认不读，解封时才调取

这里不是要用传统易学取代工程管理，而是借一层隐喻来重新框定信息的边界。如果你更熟悉"宪法/法律/规章/日记"的比喻，或者"战略/战术/执行"的框架，本质上是同一回事——只是我选择了自己更顺手的语言。

2.2 为什么叠加时间维度？

传统文档管理以模块/功能（空间）为组织主键，这在项目初期很清晰。但当文档量超过一定阈值、且 AI 需要频繁读取时，我发现仅靠空间主键不够：

• 一份"场景系统"文件夹里，可能同时存在数年不变的世界观、数周一变的接口设计、数时辰一变的 Bug 记录
• AI 如果不加区分地读取，很容易把临时问题当成长期架构，把哲学设定当成实现细节

因此，我在原有模块目录的基础上，叠加了"变动频率"这一时间维度，让不同稳定性的信息自然分层。这不是对传统文件夹管理的否定，而是在原有地基上多加一层索引。

2.3 因人而异的前提

必须声明：这套分层完全是从大荒九丘的个人实践中长出来的。

• 你的项目如果是 3 人小团队，可能"会典"和"运志"可以合并
• 如果你的项目没有 AI 参与，世录层的"局部读取"策略可能意义不大
• 如果你用 Jira/Notion 等成熟工具管理，这套手工索引可能反而是负担

没有银弹。我分享的不是标准答案，而是一个在特定上下文（独立开发 + AI 深度参与 + 长周期迭代）中验证过的思路，供你参考、拆解或否定。

---

三、三才投喂策略：给不同角色划定信息边界

基于上述分层，我给自己的 AI 协作流程设定了读取边界。核心原则是：让每种角色只接触它当下必需的信息量。

3.1 小天道（云端架构师）

输入 = 元册摘要(必带) + 会典索引匹配项 + 运志最新 diff
策略 = 先读 docs/元册/_index.json → docs/会典/_index.json → 精准调取 1-3 份会典文档
避免 = 不读世录施工细节、bug 日志、测试截图——这些会干扰架构视角

3.2 Kimi Agent 集群（施工分包）

输入 = 会典相关章节 + 运志任务单 + 前置接口契约
策略 = 按任务单 scope 调取经会典索引匹配的文档，上下文控制在 8K–16K tokens
避免 = 不读哲学讨论、跨模块未确认架构——防止施工时过度发散

3.3 小地道（本地测试）

输入 = 运志任务单 + 当前模块代码 + 测试用例模板
避免 = 不读元册哲学、会典全局架构——除非测试发现架构级冲突才上报
策略 = 发现 Bug 时按"爻变档案"格式输出，文件名自动生成

用易经的语言总结，就是**“天不读地，地不越天”**——但本质上是信息分层与权限管理。你喜欢的话，也可以把它理解为"战略层不看日报，执行层不翻宪法"。

---

四、索引机制：起卦定位

每层级配备 _index.json，作为 AI 的"目录手册"。AI 不遍历全文，而是通过 gua（卦象）+ tags（标签）+ scope（范围） 三维匹配，最多调取 3 份文档。

{
  "id": "celestial-engine",
  "title": "皇极天象引擎系统架构文档",
  "gua": "乾上离下",
  "tags": ["天象", "引擎", "天道"],
  "scope": ["celestial", "time-engine", "backend"],
  "abstract": "皇极天象引擎的完整架构：天象推导、卦象生成、与角色/场景/事件的共振接口。"
}

这里的"gua"不是玄学装饰，而是我用来快速判断"这份文档的气脉与当前任务是否相合"的高维标签。你可以替换成任何你熟悉的标识系统——比如 Stability / Volatility / Domain，或者直接用颜色标签。关键是有一层比文件名更抽象的检索维度。

---

五、象核摘要：信息压缩层

所有会典及以上文档，头部携带象核摘要（200–300 字），作为"读或不读"的第一判断依据：

## 象核摘要
- **先天卦**：坎上离下（既济）
- **主爻**：九五，东宫监位
- **气脉**：一句话概括该文档的职能边界
- **变爻风险**：哪些外部变动会触发该文档失效
- **关联象**：与其他模块的卦象呼应关系
- **归档预警**：预判何时该文档需要升级或归藏

为什么用这些词？

我尝试用易经的"象"作为文档的元数据，原因很实际：

• 技术文档常用"前端/后端/数据库"等标签，这是空间标签
• 但一份文档的真正属性是它的稳定性和影响范围——这更像"时间属性"
• 我用"先天卦"代表文档的稳定内核，"变爻风险"代表易变点，"关联象"代表依赖关系

这只是个人习惯的隐喻系统，你可以替换成任何你熟悉的标签体系。关键是有一层结构化的摘要，让 AI 和人都能在 10 秒内判断"这份文档与我当前任务是否相关"。

---

六、目前观察到的效果与局限

6.1 对 AI：上下文更聚焦了

分层 + 索引 + 摘要 = 三层漏斗：

1. 索引层：秒级定位，不调取无关文档
2. 摘要层：分钟级判断，决定是否深入
3. 正文层：需要时才读，精准投入 token

在大荒九丘的实践中，小天道拆解任务时的上下文消耗下降了约 40%，且不再出现"把哲学设定当成接口契约"的误读。

6.2 对人：定位速度提升了

我不再需要记住文件路径，只需要知道"我要找什么层级的什么主题"。

• 想查世界观 → 元册
• 想查某模块怎么设计的 → 会典
• 想查当前在做什么 → 运志
• 想查某个 Bug 怎么修的 → 世录
• 想知道以前做过什么 → 归藏

6.3 局限与代价

• 维护成本：每次文档增删改都要同步更新 _index.json，如果偷懒，索引就会失效
• 学习门槛：团队成员（或未来的我）需要理解这套隐喻系统，才能高效使用
• 规模边界：如果项目扩展到 10 人以上，这套手工索引可能不如专业工具（Notion、Jira、Confluence）高效

这套方法目前在大荒九丘（个人开发 + AI 协作 + 长周期叙事项目）中运转良好，但不保证在其他场景中同样适用。

---

七、维护纪律（供参考）

• 每次文档增删改后，同步更新对应层级的 _index.json
• 每份新会典/元册文档头部携带象核摘要
• 每份世录结尾写未竟之气和关联轨迹，方便链式回溯
• 每 2 周检视一次归藏层，确认遗留问题是否已解
• 每季度评估一次层级划分是否合理——项目变了，文档结构也要跟着变

---

结语

文档管理没有终极答案。我分享的不是"天道"，而是大荒九丘项目在特定阶段、特定约束下长出来的一种组织习惯。

如果你的项目也面临"AI 读文档比写代码还慢"“哲学讨论和施工细节混在一起”"找不到三个月前写的架构决策"这类问题，希望这套思路能给你一点启发。你可以照搬、拆解、改造，或者完全否定——只要找到适合你气脉的流转方式即可。

---

文档版本：v1.0
定稿日期：2026-05-19
作者：大荒九丘项目维护者
背景：独立开发 + AI 深度参与 + 长周期迭代
下次回顾：2026-08-19（一个季度后）