ShiGraph 技术白皮书 | ECHO 内部文档

一、ShiGraph 是什么

不是存储结构，是计算投影

ShiGraph = fold(EventStream, ShiProjection)

简单理解： ShiGraph 不是数据库里的一张表，而是从事件流实时计算出来的视图。

用户调用 Skill（ECHO 内部沙箱） ↓ 沙箱执行，产生 UsageOccurred 事件 ↓ 事件追加到 Kafka 事件流 ↓> ShiGraph 引擎读取事件流（过去7天/30天） ↓ 计算三维坐标 [时间, 空间, 关系] ↓ 映射到生命状态（64卦/或技术命名） ↓ 供四权力约束引擎使用

三维编织详解

🕐 时间维度（Temporal）

定义： 资产被使用的频率和模式

数据来源： UsageOccurred 事件的时间戳

计算： 近7天使用次数 / 近30天使用次数 / 使用趋势

4档： 低活跃(0) / 中活跃(1) / 高活跃(2) / 转化期(3)

🌐 空间维度（Spatial）

定义： 资产部署和使用的平台分布

数据来源： DeploymentEvent 和 UsageOccurred 中的 sandbox_id

计算： 部署的沙箱数量 / 跨地域分布

4档： 单沙箱(0) / 少沙箱(1) / 多沙箱(2) / 跨域部署(3)

🔗 关系维度（Relational）

定义： 资产被引用和衍生的网络连接

数据来源： DerivativeCreated 和 CitationEvent

计算： 被引用次数 / 衍生作品数 / 依赖该资产的其他资产数

4档： 孤立(0) / 弱连接(1) / 中连接(2) / 强生态(3)

二、数据来源：完全内部

❌ 不需要预言机

误区："ShiGraph 需要预言机去抖音/Spotify 抓数据"

                真相： ShiGraph 的所有数据都来自 ECHO 内部事件流。使用发生在 ECHO 沙箱内，数据自然产生在 ECHO 系统内。
            

事件类型与数据来源对照

事件类型	触发场景	用于维度
`UsageOccurred`	用户在沙箱中调用 Skill	时间维度
`DeploymentEvent`	Skill 部署到新沙箱	空间维度
`DerivativeCreated`	基于 Skill 创建衍生作品	关系维度
`CitationEvent`	Skill 被其他作品引用	关系维度

❌ 外部数据方案（不需要）

去抖音抓播放量
去 Spotify 查收听次数
需要预言机网络验证
跨链获取数据

✅ ECHO 内部方案（实际采用）

沙箱执行即产生事件
Kafka 事件流存储
ShiGraph 引擎定时计算
闭环系统，自给自足

三、计算逻辑

从事件流到坐标

计算流程（每小时执行）

def calculate_shigraph(asset_id):
    # 1. 读取事件流（最近90天）
    events = event_store.query(
        asset_id=asset_id,
        since=now() - 90_days,
        types=[Usage, Deployment, Derivative, Citation]
    )
    
    # 2. 计算时间维度
    usage_7d = count(events.filter(type=Usage, since=7_days))
    usage_30d = count(events.filter(type=Usage, since=30_days))
    temporal_score = calculate_temporal(usage_7d, usage_30d, trend)
    # 输出: 0(低) | 1(中) | 2(高) | 3(转化)
    
    # 3. 计算空间维度
    sandboxes = unique(events.filter(type=Deployment).sandbox_id)
    spatial_score = calculate_spatial(len(sandboxes), geo_distribution)
    # 输出: 0(单) | 1(少) | 2(多) | 3(跨域)
    
    # 4. 计算关系维度  
    citations = count(events.filter(type=Citation))
    derivatives = count(events.filter(type=Derivative))
    dependents = count_dependent_assets(asset_id)
    relational_score = calculate_relational(citations, derivatives, dependents)
    # 输出: 0(孤立) | 1(弱) | 2(中) | 3(强)
    
    # 5. 组合三维坐标
    coordinate = [temporal_score, spatial_score, relational_score]
    # 例如: [2, 2, 3] = 高活跃 + 多沙箱 + 强生态
    
    # 6. 映射到状态（64卦或技术命名）
    state = map_coordinate_to_state(coordinate)
    # 例如: [2,2,3] → "Xian"（咸卦·大成）或 "Stage.MATURE"
    
    return {
        "coordinate": coordinate,
        "state": state,
        "metrics": {
            "usage_7d": usage_7d,
            "sandboxes": len(sandboxes),
            "derivatives": derivatives
        }
    }

坐标到状态的映射

4×4×4 = 64 种组合，可以用两种方式命名：

坐标 [时间,空间,关系]	文化命名（64卦）	技术命名	含义
`[0,0,0]`	坤卦	Stage.SEED	潜藏期：低活跃、单沙箱、无连接
`[1,1,1]`	屯卦	Stage.SPROUT	萌芽期：开始被使用，初步扩散
`[2,2,2]`	泰卦	Stage.GROWTH	成长期：活跃增长，多平台，有连接
`[2,2,3]`	咸卦	Stage.MATURE	大成期：高活跃、多平台、强生态
`[3,3,3]`	乾卦	Stage.TRANSFORM	转化期：进入新周期，准备蜕变

                命名选择：

                代码里用 Stage.SEED、Stage.MATURE 这种技术命名。\n                用户界面显示"萌芽期"、"大成期"。\n                64卦是东方文化用户的亲切感设计，不是技术必需。

四、为什么需要 ShiGraph

解决什么问题

🎯 问题 1：静态定价

场景： 创作者拍脑袋定价 100 ECHO，不知道是否合理

解决： 根据生命状态计算参考价系数

价格 = 基础价 × 状态系数
SEED: 0.5  |  GROWTH: 1.0
MATURE: 2.0 | TRANSFORM: 1.5

🎯 问题 2：权限滥用

场景： 新作品就设置完全开放，结果被滥用

解决： 状态约束四权力配置

SEED 期: 衍 ≤ 1, 扩 ≤ 1
MATURE 期: 衍 ≥ 3, 扩 ≥ 3

🎯 问题 3：发现困难

场景： 按标签分类，优质作品被淹没

解决： 按"生命状态"匹配

"找处于成长期、
 跨平台部署的 Skill"
→ 推荐 [2,2,x] 状态的作品

🎯 问题 4：治理主观

场景： 平台人工审核，标准不透明

解决： 状态跃迁自动触发规则

进入 MATURE 期自动：
- 检查衍生权限
- 建议解锁收益
- 通知创作者

五、对比简单方案

为什么不用静态字段？

维度	简单方案	ShiGraph
数据结构	静态字段：`status: "active"`	动态计算：从事件流投影
状态流转	人工定义：草稿→发布→下架	数据涌现：从使用模式中生长
维度	单一：用没用过	三维：时间×空间×关系
定价	固定值或创作者设定	根据状态系数动态调整
约束	无或硬编码	基于状态的动态约束
可解释性	"系统设定的"	"基于过去7天使用数据计算"

关键区别：简单方案记录"状态是什么"，ShiGraph 理解"状态为什么是这样"。

具体场景对比

❌ 简单方案

场景： 两首都被用了1000次的歌

A：1000次都在1个平台，1周内爆发

B：1000次分布在10个平台，3个月内均匀

结果： 系统认为一样"active"

✅ ShiGraph

场景： 同样两首歌

A：时间=3(转化期), 空间=1(少), 关系=1(弱)

B：时间=2(高活跃), 空间=3(跨域), 关系=2(中)

结果： 完全不同的状态和策略

六、技术实现要点

MVP 可以先简化

完整版是三维，但MVP可以只做一维：

// MVP 简化版
function calculate_stage_mvp(asset_id) {
    // 只算时间维度：近7天使用次数
    usage_7d = query_usage_last_7_days(asset_id);
    
    if (usage_7d < 10) return Stage.SEED;
    if (usage_7d < 100) return Stage.SPROUT;
    if (usage_7d < 500) return Stage.GROWTH;
    return Stage.MATURE;
}

// V1.5 完整版
function calculate_stage_full(asset_id) {
    temporal = calculate_temporal_score(asset_id);  // 时间
    spatial = calculate_spatial_score(asset_id);    // 空间  
    relational = calculate_relational_score(asset_id); // 关系
    
    coordinate = [temporal, spatial, relational];
    return map_to_stage(coordinate); // 64种组合
}

存储架构

Kafka 事件流（真相来源） ↓ PostgreSQL（事件持久化） ↓ ShiGraph 计算引擎（每小时） ↓ Redis 缓存（当前状态） ↓ 四权力约束引擎（实时查询）

                可重建设计：

                Redis 里的状态丢了没关系，从 Kafka 事件流重新计算即可。\n                ShiGraph 是"投影"，不是"源数据"。

七、一句话总结

ShiGraph 不是去外部抓数据的预言机，\n
是从内部事件流理解使用数据意义的计算引擎。\n

它回答：\n
"这个资产现在处于什么生命阶段？\n
应该适用什么规则？"

数据来源

ECHO 内部沙箱的事件流，不需要预言机

计算方式

从事件流实时计算三维坐标，每小时更新

输出用途

定价系数、权限约束、发现推荐、治理规则

命名选择

代码用技术命名（Stage.MATURE），界面用文化命名（大成期）