大荒九丘 · 三才协作律：我在用「卦象」管理 AI 团队的实验记录

rairua

345人浏览 · 2026-05-28 15:33:58

rairua · 2026-05-28 15:33:58 发布

大荒九丘 · 三才协作律：我在用「卦象」管理 AI 团队的实验记录

副标题：信息压缩之后，我发现协作也需要压缩协议
系列：大荒九丘工程实践 · 第 3 篇
前置阅读：《易经卦象作为叙事生成系统的信息压缩协议》

一、从「信息压缩」到「协作压缩」

两周前，我在知乎发了一篇文章，讲怎么用易经卦象做 AI 叙事系统的信息压缩协议。那篇文章的收藏比点赞多，我后来想，为什么？

大概是因为技术人对「玄学」的态度从来不是「信或不信」，而是「有没有工程价值」。如果一套说法能帮我减少代码里的 if-else，或者让我少翻十分钟文档，它就是有用的。

这周我想聊点更个人化的——

如果你也是一个独立开发者，手头有 3~5 个 AI 助手，每天都在「这个模型写代码、那个模型审架构、另一个模型改文案」之间反复横跳，那你大概也经历过这种混乱：同一个需求问了三个 AI，得到三个版本；昨天的上下文今天全丢；凌晨两点还在对线，第二天发现 AI 把前天的结论又推翻了。

我过去两周做了一个实验：用易经的三才思维和卦象节律，给手头的 AI 助手们设计了一套协作规则。不是算命，不是占卜，是把「天、地、人」的象思维映射到工程分工里，看看能不能让 5 个 AI 算子 + 我自己，在并行推进一个复杂项目时，不至于崩盘。

这篇文章不是教程，是实验记录。我做了什么、我观察到了什么、我目前的解释是什么、以及我还没验证什么。

如果你也在摸索多 AI 协作的解法，欢迎看完告诉我你的变体。

二、我遇到的混乱，可能也是你的

在引入任何规则之前，我的状态是这样的：

混乱点	具体表现
角色重叠	模型 A 写代码，模型 B 也写代码，两人风格冲突，合并时手撕 diff
上下文丢失	昨天的架构讨论今天从头再来，AI 不记得自己画过的时序图
文档散落	设计文档在 Notion，代码注释在 IDE，会议记录在微信，没有统一索引
节律失控	晚上 11 点还在发需求，AI 秒回，导致人睡了三小时还在脑内跑代码
决策疲劳	每个 AI 都觉得自己对，最后只能人肉仲裁，累的是人

核心矛盾：AI 没有「身份」，所以也没有「边界」。

当你对 5 个 AI 说「帮我看看这段代码」，它们会各自从自己的训练数据出发，给出 5 种风格迥异的答案。这不是它们的错，是问题定义里没有给它们「定位」。

我试过的第一个解法是「用 Prompt 规定角色」。比如「你现在是一个资深后端工程师」。效果有限——模型会认真扮演五分钟，然后随着上下文膨胀，慢慢滑回它自己最舒服的说话方式。

第二个解法是「按模型品牌分角色」。比如 Claude 写代码、Kimi 审架构、DeepSeek 做分析。这稍微好一点，但品牌不等于职能，Claude 也会给架构建议，DeepSeek 也会写代码，边界还是模糊的。

最后我试的第三个解法，就是这篇文章的主角：不按模型分，不按 Prompt 分，按「象」分。

三、三才分工：按「象」而不是按「模块」

易经讲「三才」——天、地、人。天管方向和规则，地管执行和承载，人管裁决和调和。

这不是三个部门，是三种「气」：天之气清、地之气浊、人之气和。

我把手头的 AI 按这个逻辑分了类。注意，不是按模型品牌分，是按职能象性分：

卦位	职能象	主要做什么	通常不主动做什么	决策权
天·乾	架构师	模块设计、接口契约、技术选型、代码审查	具体代码实现、测试执行	设计审阅，无发布决策
地·坤	工程师	代码落地、Bug 修复、回归测试、施工日志	架构方向、哲学决策	执行交付，无设计变更
人·离	裁决者	方向拍板、资源调度、冲突仲裁、最终定音	具体编码、具体测试	唯一跨层决策者
鼎·交	转化者	文档审计、对外文章、市场分析、经验沉淀	代码修改、架构改动	观察记录，无工程决策

关键规则：

天的产出必须经过人裁决，才能落地给地执行；
地的 Bug 修复报告必须回天确认，不确认不合并；
鼎只负责「翻译」和「归档」，不碰代码。

这里要加一句但书：实际协作中，地的 AI 偶尔也会冒出架构洞察，天的 AI 偶尔也会写一段很漂亮的实现。这不是违规，是越界灵感。处理方式是：地的架构建议 → 经人裁决 → 转交天确认 → 确认后写入会典。不走这个流程，就还是混乱。

这套规则跑了两周后，一个明显的变化是：AI 互撕减少了。因为每个 AI 在接到任务时，已经知道「我是地，我只管实现，不管架构对不对」，它就不会在回复里塞一堆「我觉得你应该换个技术栈」的建议。上下文干净了，回复也聚焦了。

但这里有一个我还没解决的矛盾：当我同时推进「后端升维」和「前端重构」两个并行流时，天的 AI 经常上下文膨胀——它既要管后端架构，又要管前端架构，记忆开始打架。我现在的临时解法是让天也分「乾上·后端架构」和「乾下·前端架构」，但这是不是破坏了「天唯一」的原则？我还在试。如果你有并行多流的解法，告诉我。

四、文档天道：让目录结构即信息

三才分工解决了「谁做什么」，但没解决「东西放哪」。

我借用了邵雍「元会运世」的时间压缩逻辑，给文档分了五层。不是按「项目-模块-功能」这种西方分类法，而是按文档的生命周期和象性分：

📁 项目文档库/
├── 📁 元册/          ← 乾卦。总纲、哲学、不可违背的约束
├── 📁 会典/          ← 坤卦。架构契约、接口定义、模块边界
├── 📁 运志/          ← 震卦。施工计划、任务单、进行中
├── 📁 世录/          ← 坎卦。日志、Bug、现场记录
│   ├── 📁 轨迹/      ← 阳爻。已完成的施工记录
│   └── 📁 爻变/      ← 阴爻。Bug 修复、异常排查
└── 📁 归藏/          ← 艮卦。已归档、已冻结、只读

为什么我觉得有效？

因为文档放在哪一层，本身就是一条元信息。

当你看到一份文档在「运志」，你就知道它是活的、可能随时会变；当你在「归藏」看到它，就知道它已经封爻，除非重大重构，否则不动。你不需要打开文件，就已经「起卦」判断了它的状态。

命名上我目前用的格式（还在迭代）：

[元册]_YYYYMMDD_主题_定稿.md
[会典]_YYYYMMDD_接口契约v3.0_冻结.md
[运志]_YYYYMMDD_前端重构任务单_施工中.md
[世录-轨迹]_YYYYMMDD_单元测试报告_通过.md
[世录-爻变]_YYYYMMDD_同步延迟排查_待修复.md
[归藏]_YYYYMMDD_2.0架构定稿_封爻.md

索引文件 _index.json（目前觉得最有用的工具）：

五层目录解决了「放哪」，但 50 份文档后还是会迷路。我在每层目录下放一个 _index.json，让 AI（和自己）秒级定位：

{
  "layer": "运志",
  "lastUpdated": "2026-05-28",
  "documents": [
    {
      "id": "TASK-2026-0528-01",
      "title": "天象因果链全链路落地",
      "status": "已完成",
      "owner": "地·坤",
      "priority": "P0",
      "path": "./运志/TASK-2026-0528-01_天象因果链_已完成.md",
      "hexagram": "既济·九五",
      "tags": ["后端", "天象", "API"]
    }
  ]
}

每次开工前，我让 AI 先读这层索引，再问我要做什么。AI 的上下文不再是从零开始，而是从「当前战场态势」开始。

但这里也有一个待验证的问题：_index.json 目前靠手动维护，我试过让 AI 自动更新，但它偶尔会写错路径或漏掉新文档。理想状态是 Git 提交时自动刷新索引，但我还没写这个钩子。如果你已经做了自动化索引，我想抄作业。

五、时辰节律：给协作定「呼吸」

AI 不会累，但人会。人会因为 AI 秒回而陷入「无限对线」的泥潭。

我给自己和 AI 团队定了「时辰协作律」：

时段	象	协作规则
朝务（上午）	阳气生发	三才并行，天出设计、地写代码、鼎审文档，人做裁决
午憩（下午）	阳气正盛	AI 静默，人独作。深度思考、代码手写、不发起新对话
夕藏（晚间）	阴气渐凝	归档总结、更新索引、补录日志、规划明日

关键规则：

下午不@任何 AI，除非 P0 级紧急 Bug（我内部叫「涤尘」口令）；
晚间必须完成当日「封爻」——把运志中已完成的文档标记状态，补录变爻记录；
次日朝务的起点，是昨晚的索引，不是从零开始。

这看起来是「限制效率」，实际是保护人的决策带宽。下午那几个小时，是我产出「见龙在田」级洞察的窗口——如果全天候和 AI 对线，我只会得到一堆「乾乾」级的重复劳动。

但「涤尘」目前有个隐患：用多了，午憩就名存实亡。我给自己定了每周不超过 3 次，超过就提示「离火过旺」。但这个数字是拍脑袋定的，没有数据支撑。如果你有更好的「紧急唤醒」节制机制，告诉我。

六、两周的观察数据

这套规则不是纸上谈兵，是跑了两周后的实测观察：

指标	混沌期（前两周）	协同期（后两周）
找一份旧文档平均耗时	8~10 分钟	< 30 秒（索引定位）
同一需求被多个 AI 重复处理	经常	几乎为零（分工律）
凌晨还在和 AI 对线	每周 3~4 次	0 次（时辰节律）
架构设计→代码落地的流转耗时	2~3 天	3 小时（天→人→地，一次对齐）
文档归档后再次找不到	经常	零（归藏层 + 索引）

一个具体案例：

「天象因果链」这个功能，涉及后端引擎、API 接口、前端面板三个模块。按以前的打法，我会分别问三个 AI，得到三份风格迥异的代码，然后自己手撕合并。

这次的做法：

天出一份《天象因果链接口契约》，定义输入输出；
人审阅后冻结，写入会典；
地按契约施工，产出代码 + 测试报告，入世录/轨迹；
鼎把过程写成经验文档，待归档。

从设计到全链路落地，3 小时。没有返工，没有互撕。

但我要诚实地说：这个案例是目前最顺的一次。其他任务并没有每次都这么丝滑。比如「应物系统」的架构讨论，天就地和鼎来回传了四次才定稿，因为涉及哲学框架和工程实现的耦合，边界比天象因果链模糊得多。

所以 3 小时是上限，不是常态。

七、为什么我觉得「象思维」比「模块化思维」更适配 AI 协作？

西方工程思维把系统拆成 A、B、C 三个模块，每个模块交给一个 AI。但模块之间的「气」怎么流动？西方思维没有给「气」留位置。

易经的「象思维」恰好补了这个缺：

三才不是三个部门，是三种「气」；
卦象不是标签，是「状态机」——一份文档在「运志」还是在「归藏」，是两种完全不同的「象」；
时辰不是时间表，是「节律」——万物皆有呼吸，协作也是。

当你用「象」而不是「模块」去理解 AI 协作，你会发现：AI 没有身份，但可以有「卦位」；AI 没有记忆，但可以有「文档天道」；AI 不会累，但人可以按「时辰」保护自己的心神。

这不是硬套传统文化，是我的体感：西方模块化思维在单 AI 场景下很强大，但在多 AI 协作时，它缺少一个「让不同算子之间产生关系」的层。象思维恰好提供了这个层。

当然，这只是我的解释。你可能有完全不同的体感。

八、我目前的实验配置（供参考）

以下是我跑了两周后还在迭代中的配置，未必适合你的项目，但或许能触发你的变体。

① 五层目录骨架

mkdir -p docs/{元册,会典,运志,世录/{轨迹,爻变},归藏}
touch docs/_index.json
touch docs/{元册,会典,运志,世录,归藏}/_index.json

② 任务单模板（运志层，还在改）

---
task_id: TASK-YYYYMMDD-NN
layer: 运志
status: 施工中
priority: P0
owner: 地·坤
hexagram: 震·雷动
created_at: 2026-05-28
---

# 任务：XXX

## 目标
一句话描述交付物。

## 范围
- [ ] 包含：XXX
- [ ] 不包含：XXX

## 验收标准
1. XXX
2. XXX

## 变爻记录
- 2026-05-28 初稿 | 九二·见龙在田 —— 方案拟定

③ 每日夕藏检查清单（我的版本）