核心观点：在 AI 编程趋势下，权限管理正从”静态规则”向”动态上下文感知”演进，Casbin 的 PERM 元模型为这一演进提供了坚实基础。

一、权限管理的范式演进：从 ACL 到 AI-Native

1.1 访问控制模型的四代演进

权限管理的发展历程，本质上是对”谁在什么条件下能做什么”这一问题的持续精细化表达：

Casbin 的独特之处在于，它通过 PERM (Policy, Effect, Request, Matchers) 元模型统一了前三代模型的表达能力，同时为第四代演进预留了扩展空间。

1.2 PERM 元模型：一种通用的权限描述语言

PERM 模型将任何访问控制场景抽象为四个核心组件：

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

[effect]
e = some(where (p.eft == allow))

这种声明式的设计带来了关键优势：策略与实现解耦。架构师可以在不修改代码的情况下，通过调整配置文件切换 ACL、RBAC、ABAC 甚至自定义模型。

二、Casbin Go 实现：源码级架构解析

2.1 核心类型体系：从 Enforcer 到执行链

Casbin Go 的实现采用了清晰的分层架构：

┌─────────────────────────────────────────┐
│           Enforcer 接口层                │
│  (Enforcer, CachedEnforcer,             │
│   SyncedEnforcer, DistributedEnforcer)  │
├─────────────────────────────────────────┤
│           核心引擎层                     │
│  (Model, Policy, RoleManager)           │
├─────────────────────────────────────────┤
│           适配器层                       │
│  (FileAdapter, DBAdapter, RedisAdapter) │
├─────────────────────────────────────────┤
│           持久化层                       │
│  (CSV, MySQL, PostgreSQL, etcd)         │
└─────────────────────────────────────────┘

Enforcer 类型选择决策树：

• 单线程应用 → Enforcer（最轻量，无锁开销）
• 多线程高并发 → SyncedEnforcer（读写锁保护）
• 读多写少 → CachedEnforcer（内存缓存结果）
• 高并发 + 缓存 → SyncedCachedEnforcer（组合优势）
• 分布式部署 → DistributedEnforcer（配合 Dispatcher）

2.2 策略加载机制：从配置到内存模型

Casbin 的策略加载流程体现了延迟加载 + 增量更新的设计哲学：

// 1. 创建 Enforcer 时加载模型和策略
e, _ := casbin.NewEnforcer("model.conf", "policy.csv")

// 2. 内部执行流程
//    a. 解析 model.conf → 构建语法树
//    b. 调用 adapter.LoadPolicy() → 加载策略规则
//    c. 构建角色继承图（RBAC 场景）
//    d. 准备就绪

// 3. 权限检查
ok, _ := e.Enforce("alice", "data1", "read")

关键源码洞察：

// Enforcer 核心结构
type Enforcer struct {
    model        model.Model      // 解析后的模型定义
    fm           model.FunctionMap // 内置函数映射
    eft          effect.Effector   // 效果器（allow/deny逻辑）
    rm           rbac.RoleManager  // 角色管理器
    adapter      persist.Adapter   // 持久化适配器
    watcher      persist.Watcher   // 变更监听器
    dispatcher   persist.Dispatcher // 分布式协调器
}

2.3 匹配算法：表达式引擎与性能优化

Casbin 使用 govaluate 表达式引擎执行 matchers 中的逻辑：

[matchers]
m = g(r.sub, p.sub) && keyMatch(r.obj, p.obj) && r.act == p.act

内置匹配函数及其适用场景：

性能优化策略：

1. 缓存策略：CachedEnforcer 使用 sync.Map 存储执行结果，避免重复计算
2. 过滤加载：LoadFilteredPolicy() 只加载需要的策略子集，降低内存占用
3. 角色继承深度限制：默认 10 层，防止循环继承导致的性能问题
4. 禁用 JSON 解析：如不需要 ABAC 的 JSON 支持，保持禁用可减少 1.1-1.5x 开销

2.4 RBAC 实现：角色继承与域隔离

Casbin 的 RBAC 实现支持传递性继承和多域隔离：

[role_definition]
g = _, _      # 基本角色继承
g2 = _, _     # 资源角色（可选）

角色继承的数学特性：

• 传递性：A → B → C 则 A 拥有 C 的权限
• 无界性：继承深度可配置（默认 10）
• 非对称性：A 继承 B 不意味着 B 继承 A

多租户场景（RBAC with Domains）：

[request_definition]
r = sub, dom, obj, act

[role_definition]
g = _, _, _   # 第三个字段是 domain

[matchers]
m = g(r.sub, p.sub, r.dom) && r.dom == p.dom && ...

这种设计使得同一用户在不同租户可以拥有完全不同的角色权限，是 SaaS 应用的基础能力。

三、Go 生态权限工具对比：选型决策矩阵

3.1 主流方案架构对比

3.2 场景化选型建议

选择 Casbin 的场景：

• 需要嵌入到现有 Go 服务中
• 权限模型可能频繁调整
• 需要支持多种访问控制模型
• 对延迟敏感（内存执行）

选择 OPA 的场景：

• 需要跨服务统一策略管理
• 策略逻辑复杂（需要完整编程语言）
• 云原生环境（Kubernetes 集成）
• 可以接受 Sidecar 架构

选择 SpiceDB 的场景：

• 需要 Google Zanzibar 级别的细粒度权限
• 大规模分布式系统
• 需要实时权限变更传播
• 预算充足（托管服务成本）

选择 Keto 的场景：

• 使用 Ory 生态（Kratos、Hydra）
• 需要云原生权限服务
• 偏好声明式配置

3.3 生产环境考量

四、AI 时代的权限架构：从静态规则到上下文感知

4.1 LLM 数据访问的权限挑战

AI 系统引入了传统权限管理无法覆盖的新场景：

┌─────────────────────────────────────────────────────────┐
│                    AI 系统权限边界                        │
├─────────────────────────────────────────────────────────┤
│  输入层  │ Prompt 注入检测、敏感信息过滤（PII/机密数据）    │
├─────────────────────────────────────────────────────────┤
│  处理层  │ 模型访问控制、训练数据隔离、RAG 检索权限         │
├─────────────────────────────────────────────────────────┤
│  输出层  │ 生成内容审查、幻觉检测、合规性检查               │
├─────────────────────────────────────────────────────────┤
│  执行层  │ Agent 动作授权、工具调用权限、代码执行沙箱       │
└─────────────────────────────────────────────────────────┘

OWASP LLM Top 10 中的权限相关风险：

4.2 AI Agent 权限架构设计

AI Agent 的自主性带来了动态权限需求：

// 传统权限检查：静态规则
ok, _ := e.Enforce("alice", "data1", "read")

// AI Agent 权限检查：上下文感知
ok, _ := e.Enforce(
    agent.ID,                    // 主体
    resource.ID,                 // 客体
    action,                      // 动作
    context{                     // 上下文（ABAC）
        UserIntent:    intent,   // 用户意图
        DataSensitivity: level,  // 数据敏感度
        SessionRisk:   score,    // 会话风险评分
        TimeOfDay:     now,      // 时间上下文
    },
)

Casbin 在 AI 场景中的增强模式：

[request_definition]
r = sub, obj, act, ctx

[policy_definition]
p = sub, obj, act, rule

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act && \
    eval(p.rule)

# 策略中可以存储表达式
# p, agent_001, database, read, ctx.DataSensitivity <= 3 && ctx.SessionRisk < 0.8

4.3 代码生成安全的权限边界

AI 生成代码的执行需要分层沙箱策略：

// 定义代码执行权限策略
const model = `
[request_definition]
r = code, resource, action, env

[policy_definition]
p = code_hash, resource, action, env_constraint

[matchers]
m = r.code == p.code_hash && r.resource == p.resource && 
    r.action == p.action && matchEnv(r.env, p.env_constraint)
`

// 执行前检查
func executeAIGeneratedCode(code string, env ExecutionEnv) error {
    hash := sha256(code)
    ok, _ := enforcer.Enforce(hash, "filesystem", "write", env)
    if !ok {
        return fmt.Errorf("代码执行权限被拒绝")
    }
    // 在沙箱中执行...
}

关键策略维度：

4.4 未来演进：向 AI-Native 权限管理迈进

Casbin 在 AI 时代的演进方向：

1. 动态策略生成
   • 使用 LLM 辅助生成策略规则
   • 自然语言转 PERM 模型
   • 策略冲突检测与修复
2. 可解释性增强
   • 每次权限决策附带理由
   • 满足 AI 合规审计要求
   • 支持”为什么被拒绝”的查询
3. 自适应权限
   • 基于行为模式动态调整权限
   • 异常检测与自动降级
   • 风险评分驱动的访问控制
4. 多模态策略
   • 支持图像、音频等非文本资源的权限控制
   • 适应多模态 AI 应用场景

五、工程实践：生产环境部署指南

5.1 高可用架构设计

┌─────────────────────────────────────────────────────┐
│                  API Gateway                        │
│         (认证 + 限流 + 日志)                         │
└─────────────────────────────────────────────────────┘
                         │
         ┌───────────────┼───────────────┐
         ▼               ▼               ▼
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  Service A  │  │  Service B  │  │  Service C  │
│  (Casbin)   │  │  (Casbin)   │  │  (Casbin)   │
└─────────────┘  └─────────────┘  └─────────────┘
         │               │               │
         └───────────────┼───────────────┘
                         ▼
              ┌─────────────────────┐
              │   Redis Cluster     │
              │  (策略缓存 + Watcher) │
              └─────────────────────┘
                         │
                         ▼
              ┌─────────────────────┐
              │   PostgreSQL        │
              │   (策略持久化)       │
              └─────────────────────┘

5.2 性能优化 checklist

• 使用 CachedEnforcer 缓存热点权限检查结果
• 配置合理的角色继承深度（根据实际业务调整）
• 使用 LoadFilteredPolicy() 按需加载策略
• 禁用不需要的 ABAC JSON 解析
• 启用自动策略重载时设置合理的轮询间隔
• 监控 Enforce() 延迟，设置告警阈值

5.3 安全最佳实践

1. 策略即代码：将策略文件纳入版本控制，实施代码审查
2. 最小权限：默认拒绝，显式允许
3. 定期审计：使用 GetPolicy() 导出策略进行人工审查
4. 变更追踪：记录所有策略变更的审计日志
5. 测试覆盖：编写权限规则的单元测试

六、结论与展望

Casbin 通过其优雅的 PERM 元模型，为 Go 生态提供了一个统一、灵活、高性能的权限管理解决方案。在 AI 编程趋势下，权限管理正面临从”静态规则”到”动态上下文感知”的范式转变。

关键洞察：

1. 模型统一性：PERM 模型能够表达 ACL、RBAC、ABAC 乃至更复杂的权限逻辑，降低了架构演进成本
2. 性能与灵活性的平衡：通过 Enforcer 类型体系和缓存机制，Casbin 在灵活性和性能之间找到了最佳平衡点
3. AI 就绪性：Casbin 的 ABAC 能力和表达式引擎为 AI 场景的上下文感知权限控制奠定了基础

选型建议：

• 中小型项目：直接使用 Casbin 嵌入式库
• 大型分布式系统：Casbin + Redis Watcher + 分布式 Enforcer
• 云原生环境：评估 OPA Sidecar 方案，或 Casbin 服务化部署
• AI 应用：Casbin ABAC + 自定义上下文属性

未来展望：

随着 AI Agent 和自动化编程的普及，权限管理将不再是”配置即遗忘”的基础设施，而是需要持续学习、动态适应的智能系统。Casbin 的扩展性设计使其有能力适应这一演进，但社区也需要在 AI-Native 权限管理领域建立新的最佳实践和标准。

参考资料

• Casbin 官方文档：https://casbin.org/docs/overview
• Casbin GitHub：https://github.com/casbin/casbin
• OWASP LLM Top 10：https://owasp.org/www-project-top-10-for-large-language-model-applications/
• NIST AI Risk Management Framework：https://www.nist.gov/itl/ai-risk-management-framework
• OPA 官方文档：https://www.openpolicyagent.org/docs/latest/
• SpiceDB 文档：https://authzed.com/docs

本文基于 Casbin v2.x 版本和 Go 1.22+ 环境撰写，部分代码示例经过简化以便阅读。

核心洞察：成都平原没有石头，所以每块石头都成了神。

一、一个反直觉的问题

成都平原，沃野千里。

这里土地肥沃、河网密布，是天府之国的核心。但如果你在这片平原上寻找天然巨石——抱歉，一块也找不到。

然而，当你翻开成都地图，满眼都是”石”：

• 支矶石街——与宽窄巷子一墙之隔
• 天涯石街——老东门的心脏地带
• 石笋街——宽窄巷子北面
• 五块石——火车北站附近
• 石羊场——成都南大门
• 石室中学——中国最早的官办学校
• 石经寺——龙泉驿的千年古刹

一座没有石头的城市，为何被石头命名？

这些石头从哪来？它们为何成为地标？又承载着怎样的文化记忆？

答案藏在三个层次的”石头叙事”里。

二、第一幕：神性的起源——石头是”天外来客”

支矶石：织女织机的垫脚石

西晋张华《博物志》记载了一个浪漫的故事。

汉代张骞出使大夏（今阿富汗北部）归来，从黄河源头带回一块石头，请教成都的严君平。严君平观后大惊：

“去年八月有客星犯牛郎、织女星，此石是天上织女的支矶石！”

原来，张骞在黄河源头见一女子织布、一男子放牛。女子说此地非人间，将垫在织机下的石头放入张骞船中，让他找严君平解惑。严君平夜观星象后确认——张骞竟到达了天河之畔。

这块石头，是织女织机下的垫脚石。

唐代岑参在《严君平卜肆》中追问：

“不知支机石，还在人间否？”

洞察：古人用神话解释一个事实——这块石头不属于这里。它的”外来性”本身就是神性的证明。

天涯石：女娲补天的遗落物

老成都流传着歌谣：

“清早起来不新鲜，心想成都耍几天。一出东门天涯石……”

这块粗红砂石，与支矶石并称古蜀文明”大石崇拜”的两大遗留物。

关于它的来历，有三个版本的传说：

1. 女娲补天说——遗落的五彩石
2. 天庭坠落说——玉皇大帝宫殿围栏上掉下的神石
3. 镇海眼说——古时这里有深洞每年涌水淹没城区，上天降巨石堵住

地质学家会告诉你：这是一块普通的粗红砂石，来自龙门山脉。

但古人选择相信神话。因为这块石头的”不可能存在”，本身就是奇迹。

三、第二幕：权力的密码——石头是”王者的墓碑”

石笋街：杜甫诗中的”双高蹲”

公元760年，杜甫在成都写下《石笋行》：

“君不见益州城西门，陌上石笋双高蹲。”

这证明至少在唐代，成都西门口竖立着一对形似石笋的高大石头。

但这对石笋在南宋时期悄然消失。

它们去哪了？为什么消失？没人知道。

但街名沿用至今，成为“看不见的地标”。

考古学的揭秘：大石崇拜与古蜀王墓

《华阳国志·蜀志》明确记载：

“蜀人以石笋为墓志。”

现代考古发现，古蜀人源于氐羌，而氐羌民族有悠久的“石棺葬”传统。在岷江上游，考古学家发现了大量先秦时期的石棺墓——用整块石板搭建的永恒居所。

成都平原的大石，或许是这种”大石崇拜”的延续。

• 天涯石、五块石、石笋——可能是古蜀王的墓前标志
• “五”在传统典籍中表示”无限”与”至尊”
• 巨石被赋予神圣意义，成为连接天地的象征

洞察：石头，是古蜀王与天地对话的媒介，是他们权力的纪念碑。

四、第三幕：文明的传承——石头是”不朽的誓言”

石室中学：中国最早的”石头学校”

公元前143-141年，蜀郡太守文翁创建”石室精舍”。

这是中国历史上第一所地方政府创办的高等学堂，文翁被誉为”中国历史上第一位校长”。

校舍主要由石头建造，故名”石室”。

班固《汉书》记载：

“蜀地学于京师者比齐鲁焉。”

杨慎赞曰：

“蜀学比于齐鲁”——把四川比作孔孟之乡。

司马相如、扬雄、郭沫若、李劼人……皆出自石室系统。

一块石头，撑起了一座城市的文脉。

后蜀石经：133万字刻于石上

五代后蜀广政七年（944年），宰相毋昭裔主持刊刻儒家经典于文翁石室。

历时200余年，贯穿后蜀、北宋、南宋、宋徽宗四朝，刻成”十三经”。

这是中国唯一带注文的石经——经文外镌刻双行注文，方便阅读理解。

这也是首次结集”十三经”——奠定中国儒学经典体系基本格局。

石逾千块，字数133万字以上。

学者誉为：

“冠天下而垂无穷”的壮举。

1938年，在文翁石室遗址发现残石，现仅存7块，四川博物院藏6块，被称为“一级文物中的一级”。

洞察：当石头从”神物”变为”教材”，成都人完成了一次文明的跃迁——把对永恒的崇拜，转化为对知识的信仰。

五、尾声：石头里的人文情怀

今天的成都人，或许已经不知道支矶石的故事。

但他们依然会在石室中学门口拍照打卡，会在宽窄巷子寻找那块被玻璃罩保护的”神石”，会在石经寺为家人祈福。

石头会风化，传说会淡忘，但那种对”永恒”的向往、对”知识”的敬畏，已经刻进了这座城市的基因。

正如岑参的那句追问：

“不知支机石，还在人间否？”

答案是：还在。

它不在文化公园的玻璃罩里，而在每一个成都人的文化记忆中——

在那条叫”支矶石街”的老巷里，在那所叫”石室中学”的校园里，在那座叫”石经寺”的古刹中。

成都平原没有石头，所以每块石头都成了神。

而这，就是成都。

附录：成都”石头地图”

参考资料：《华阳国志·蜀志》《博物志》《汉书》《成都城坊古迹考》

历史文献中的“态度”

近期在针对二十四史进行语料库建设，在训练词向量的过程中，发现针对同一个词，不同的文献训练出的相似词带有明显的情感 倾向，比较有意思，记录如下。

一、 文本整理与词向量训练

本文中训练词向量采用的是python的gensim包，针对二十四史分别与公共新闻文本库混合进行训练。这样可以既可以满足训练所需要的 大文本要求，又能避免不同历史文献同名词汇的相互干扰。训练过程采用了skip-gram 算法，窗口宽度为10，100维向量空间。词向量的 概念此处不予详细解说，可参考 word2vec 。

二、 不通文献对人物的态度 汉代的历史人物，其人物事迹、历史形象为人们广为熟知，我尝试选取《汉书》、《后汉书》、《三国志》、《史记》四本书，对比研究几个主要 历史人物的前100个近似词，以期能够看出不同文本在叙述同一历史人物时在书写上的倾向性。

1、刘邦

《汉书》

原始链接

《后汉书》

原始链接

《三国志》

原始链接

《史记》

原始链接

以上针对“刘邦”的词向量比对，可以看出不同历史文本在叙事描述上的主观倾向性。

其中成书于东汉的《汉书》中，与“刘邦”关系最近的词汇中， 褒义词和正面描述词汇极多，其中关系最近的词汇是“高祖”，其次“行赏”、“重建”、“崛起”、“盛名”、“神庙”等词汇近似度极高。 且词汇所表现的历史事件多集中在汉朝建立前。

从《后汉书》的分析结果来看，与“刘邦”一词关系接近的词汇和《汉书》基本一致，表明在叙事上面并没有大的改变，但是词汇中出现了更多 的明显表现汉帝国成立以后的叙事词汇。

《三国志》中反映出来的相关词汇则显示了大量的贬义、负面情绪的词汇，展示了作者叙事情绪对比两汉书时的反转。

成书最早的《史记》则表现出了最客观的态度，强相关词汇以关键地名和名词为主，从相关词中能够基本了解到刘邦政治生涯中的关键事件和关键地点。

类似的情绪倾向可以参考比对其他关键词进行思考，可以提示一些有意思的看法。如 “项羽”、“韩信”。

其中“韩信”一次，可以从词向量亲疏关系中明显看出，在两汉书中，韩信的故事叙述主要和同时期同等地位的人相提并论，而《史记》中则主要放到与两大 政治集团首领：刘邦、项羽的叙事故事中进行描述， 在《三国志》中，与“韩信”关系极近的词，由人名变成了地名和大量的描写心理的词汇，如“疑惑” 、“羞愧”、“稳重”、“迟疑”、“无能为力”、“随机应变”等，暗示着在三国志中提到“韩信”时，韩信已不再作为故事主人翁被讲述，而是用于比较参考的一个对象。 回到原书中进行比较阅读，确实如此。

词向量的查询工具已经发布到 史前，可以拿自己感兴趣的词进行尝试。后续会逐步完成全部二十四史的词向量模型。

历史文献与知识图谱 1

知识图谱（Knowledge Graph），在图书情报界称为知识域可视化或知识领域映射地图，是显示知识发展进程与结构关系的一系列各种不同的图形，用可视化技术描述知识资源及其载体，挖掘、分析、构建、绘制和显示知识及它们之间的相互联系。

  历史文献研究也是文本研究，基于自然语言处理的文本分析技术理所当然有用武地。作为尝试，作者在进行自然语言学习的过程中，尝试以《二十四史》为文本材料，进行知识图谱自动构建，并以自动构建的结果加以人工分析和校正。

  系统首先通过神经网络模型（该模型的构建另文介绍），对翻译成现代白话文的《二十四史》文本进行检索，逐句进行分析，从单句中抽取简单的实体及关系，形成知识图谱三元组。自动抽取出的知识图谱三元组会存放在数据库中，等待进一步的人工审核。

  需要改进的地方：

• 知识图谱的三元组抽取是个硬核算法，需要提升的空间很多，比如跨句联系上下文进行关系抽取、需要更高效更准确的进行命名实体识别、需要更丰富的自定义词典。。。；
• 知识图谱的UI呈现；
• 知识图谱和搜索引擎的配合工作；

  目前配合着这个系统，我准备在2020年开始逐本通读《二十四史》，以校验知识图谱为目标，作为坚持阅读的动力。。。

开始接触React。从 Antd 入手，了解react机制，了解typescript，同时在学习CocosCreator中熟悉typescript语法。

从scikit-learning到tensorflow

在使用Sencha(ExtJS6)的过程中遇到一个诡异的问题。

往TabPanel中添加一个Panel，添加的时候设置Panel的itemId，为了省事，直接用uuid生成的编号作为itemId的值。

诡异的事情发生了。 浏览器报错 ：　Ext.Component.constructor(): Invalid component “itemId”: “7490b8ce-a0c7-11e6-9eea-b8ca3a7c240a”

这个错误并不是每次必报，偶尔发生。刚开始怀疑是某些资源没有清理，但又找不到具体的问题。把itemId改为id，故障依然。最后跟踪代码，找到抛出异常的这段代码：

        //<debug>
        if (!me.validIdRe.test(me.id)) {
            Ext.raise('Invalid component "id": "' + me.id + '"');
        }
        if (!me.validIdRe.test(me.itemId)) {
            Ext.raise('Invalid component "itemId": "' + me.itemId + '"');
        }
        //</debug>

跟着查看了一下me.validIdRe的值：

        /^[a-z_][a-z0-9\-_]*$/i

明白了，itemId和id只能是字母或下划线开头。为itemId加个字母前缀，问题解决！

卡方检验

列联表数据中，行变量和列变量之间的独立性检验: chisq.test()

t检验

连续型变量的组间比较（假设服从正态分布），对均值相等的检验

独立样本的t检验 t.test(x~y)

非独立样本的t检验 t.test(x~y, paired=TRUE)

多于两组的比较 -> ANOVA（一元方差分析）

SAE -> NGROK

  sae不靠谱，免费用户说关闭就关闭了。还好有NGROK神器，帮我把网站从内网映射了出来。

这次担当主力的计算设备是树莓派3，担当数据总管任务的是一张32GTF卡。200块大洋的设备使我能够在家里边看资料，边录入数据。效率可能不高，原因在于私网穿透的低效率和设备计算处理能力的低下。

没关系，能用就好。 JUMP TO PREHISTORY

  经过断断续续一段时间的敲打，“史前”工具基本上已经完成了数据管理相关的功能。能够放心的在线编辑和管理一些重要的数据了。

在豆瓣上看到一则评论，笑死我了。

  国家养研究生，盖同宋代养冗兵之意。养一百七十万研究生，则社会少一百七十万无业游民。且现在多是自费，国家不花分毫，仅一纸文凭，而买得海晏河清。这种制度设计，还有考研的人舍己为人的情怀真是令人激赞。

什么也别说，祖国知道我。

  在考古类型学研究中，器物纹饰是一种重要类型判别指标，大量的论文和报告在做类型学分析时，都会考虑单列纹饰，在划定相对年代关系时，将不同时期纹饰的差异作为重要的划分因素。
  但是我们往往忽略了一个问题，即纹饰首先是陶制器物的一个属性，其次才是具有独立特征的一种__样式__， 如果离开陶器这个载体，纹饰将不复存在。那么纹饰在类型学研究中是否应该具有和陶器型制相同的地位呢？或者是纹饰研究应该在型制研究的基础上进行？要回答这个问题需要首先检验一个假设，假如陶器的纹饰和型制没有相关性，那么在类型学研究中，纹饰和型制应该具有相同的研究价值，如果陶器的纹饰和型制具有显著的相关性，那么纹饰的数量关系应该从属于型制的数量关系，换句话讲，型制的数量关系揭示出文化的差异性后，才能在纹饰基础上展开更微观的差异性研究。更直白一点的讲，如果陶器的类型和纹饰有显著型的相关关系，那么纹饰的数量关系会收到田野发掘中采集到的陶器类型的强烈影响，类型学研究应该首先针对陶器类型进行，在此基础上在对统一类型的陶器做纹饰差异性研究。
  否则，混淆一团的类型学研究不会有统计意义，不会有说服力，永远都是充斥着各种意见。hey

2015元旦快到了，希望能确立方向，顺利开题！