契约只承载结构，个性留给扩展层

# 契约只承载结构，个性留给扩展层

结论

你在四套完全不同的系统上划的是同一条线：中间那层契约只管「结构 / 中立逻辑」， 所有「个性、格式、视觉、业务规则」都往下推到扩展层。 违反它的症状也统一 —— 契约被某一端的特殊性污染，于是别端全部跟着变形。

四处证据

旁证：引擎不做建模器 —— 引擎是「切与渲染」的执行层，建模这一「个性生产」环节整体外推给 Blender； 多源更新按维度取真源 —— 契约（协议字段）与内容（skill 正文）分属不同真源，不能整体选一边。

综合判断

1. 「承载什么」比「放在哪」更关键。 四处都做了分层，但真正的分界线是同一条： 契约层只描述「有哪些结构位置 / 哪些中立步骤」，不描述「长什么样、谁来填、业务怎么判」。 一旦契约层开始表达个性（视觉、格式、业务规则），它就从「共用底座」变成了「某一端的私有实现」。

2. 越界的方向总是「向上污染」。 具体的一端把自己的特殊要求写进共用层，代价由所有端承担； 反过来把中立逻辑下放到某一端，代价只由那一端承担。所以越界检查只需问： 「这条规则是只有一端需要，还是所有端都需要？」

3. 可迁移的动作：设计任何共享层（协议 / schema / 通用脚本 / 平台）时，逐条过一遍其中的规则， 问 「这一条是在描述结构，还是在描述某个使用者的个性？」 属于后者的一律外推。 配套：契约要能被 validator 读（见 分层要落到运行时才有效），否则外推的边界没人守。

与既有 synthesis 的关系

• 可复用物与不可复用物分开 —— 讲怎么分层（按寿命/复用性）；本条讲层与层之间怎么切（结构 vs 个性）。
• 分层要落到运行时才有效 —— 讲分层之后怎么才算数；本条是它前面的设计动作。 三条串起来即：先按寿命分层 → 层间按「结构/个性」切界 → 最后让边界被运行时执行。

为什么这是 synthesis

单看每一页，都是某个系统里的一次架构决定（模板渲染、AI 协议、hook 脚本、评测平台）。 并排之后才看得出它们是同一条架构原则的四个实例，且越界的代价结构完全一致。 这条原则独立于任何技术栈，可以直接带走。

相关

• 分层要落到运行时才有效 —— 本条定边界，那条负责让边界被运行时执行
• 可复用物与不可复用物分开 —— 先按寿命分层，再按「结构/个性」切界
• 引擎不做建模器 / 多源更新按维度取真源 / 通用脚本要靠工具适配器接入