飞书 Wiki 资产验证规则建模

背景

今天深入研究了 quanttide-asset 项目中的飞书 Wiki 资产验证规则建模。这是一个探索性任务：如何从飞书 Wiki 的目录结构中，提炼出可验证的规范，并进一步反推出组织的业务流程。

核心问题

飞书 Wiki 的目录结构有什么规范？如何验证这些规范？更重要的是：能否通过资产目录结构，反推出组织的业务流程？

建模思路

契约驱动的本质

契约不是代码内置的逻辑，而是”蒸馏出来的声明式规范”。

契约定义（应该有什么） → 发现机制（实际有什么） → 验证模块（差异对比）

契约验证的边界：只验证结构性信息，不验证内容质量。

能验证	不能验证
节点存在性	文档内容完整性
命名格式	语义正确性
父子关系	业务逻辑
层级深度	资产价值

四步建模框架

1. 业务拆解：从数据中识别节点类型（Space/Folder/Doc）
2. 行为定义：定义每种节点的属性和关系
3. 度量设定：设定可验证的维度
4. 模型产出：输出通用模型 + YAML 验证规则

议事档案案例

目录结构

议事档案
├── 议事档案首页              # Root，depth=0
├── 议题                      # Container，depth=1
│   ├── 议事规则              # Container，depth=2
│   │   ├── 2025年第49周-议事规则1-辩论
│   │   └── ...
│   ├── 议程
│   ├── 决策
│   └── 计划

反推的业务流程

通过分析分类结构和命名模式，反推出议事决策流程：

提出议题 → 制定规则 → 安排议程 → 做出决策 → 执行计划
    ↓           ↓          ↓         ↓         ↓
  议题      议事规则     议程      决策      计划

验证规则

validation:
  rules:
    - name: 必须有根节点
      assert: node_exists(depth=0)
      level: error

    - name: 一级分类完整性
      assert: |
        has_category("议题") and
        has_category("议程") and
        has_category("决策") and
        has_category("计划")
      level: error

    - name: 叶子文档命名格式
      assert: matches(node.title, "^\\d{4}年第\\d{1,2}周-.+")
      level: warning

经验总结

1. 建模要先观察数据

不要先入为主地设计规则，要从实际数据中观察规律。

2. 区分通用规则和特定规则

• 通用规则：所有 Space 适用（结构完整性、命名非空）
• 特定规则：特定 Space 适用（议事档案的分类名、命名格式）

3. 契约的局限

契约只验证”有没有、对不对”，不验证”好不好”。内容质量需要 AI 验证层。

4. 警惕暴露资产信息

space_id 等敏感信息不要写进代码和文档。

下一步

1. AI 反推验证：让 AI 从资产结构反推流程，与实际流程对比
2. 泛化到其他 Space：为其他 Space 定义类似的规范
3. 人工交叉验证：与实际业务流程对比，确认反推结果

参考

• 验证规则建模文档