1
确定真源顺序
先承认冲突会发生，再规定解决顺序：`code/token` 优先，其次是 `figma variables/components`，最后才是 `spec docs/examples`。这样 agent 不会把几个来源混成一锅。
01 / 制作路径
从零散规范，到一套有真源优先级的治理机器。
制作这个 skill 的关键，不是把资料堆起来，而是把“什么可信、如何调用、怎么验收、什么时候不能用”定义清楚。
2
把规则分层
`SKILL.md` 只负责触发和编排；长规则进入 `references/`；精确事实进入 `references/contracts/*.json`；验证逻辑进入 `scripts/`；真实可复用资产才进入 `assets/`。
3
把大合同改成可查询
组件、token、图标、插画、页面模式都配套 query 脚本。日常工作只取命中的小片段，需要审查或修订时才读取完整合同。
4
加入生产自检
页面产物必须写 `production-check.json`。尤其是 `navbar/default`，校验器会读真实 HTML / 前端代码，检查是否引用 OPPO logo 与 Search / Account / Bag / Menu 资产。
5
同步到 Codex 实际读取的位置
工作区只是编辑源包，Codex 真正调用的是安装后的 skill 版本。每次治理规则变更后，都要把源包同步到运行版本并复跑校验。
SKILL.md路由、读取顺序、护栏、输出要求。
references/人读规则：设计原则、组件语法、页面模式、角色指南。
contracts/机器事实：token、组件、资产、Figma 映射。
scripts/查询、校验、diff、context budget。
assets/本地可复用字体、Logo、图标、插画。
02 / 应用场景
它接手的是“产出前的判断”和“产出后的验收”。
点击左侧场景，可以看到 skill 会怎样切换读取路径、判断标签和校验要求。
页面生产
生成账号页、商品页、结算页、搜索页、空态页等时，先找页面模式，再查 requiredComponents / allowedComponents，最后按需查 token 与资产。
01query_patterns.py 命中页面模式
02query_components.py 获取组件槽位
03query_tokens.py / query_icons.py 按需补精确值
04validate_mappings.py 校验生产自检
03 / 这个 skill 的油水在哪里
它比“只有一个 MD 的规范”多出来的，不是字数，是可执行能力。
网上很多设计规范 skill 只有一个 Markdown：能提醒 AI，但很难约束 AI。这个 skill 的价值在于把规范拆成规则、合同、资产和校验脚本，让 AI 产出后还能被检查。
01
不会只会“背规范”
只有 MD：把规则写给 AI 看，AI 可能记住，也可能忽略。 这个 skill：先判断任务类型，再按路径查规则。它把任务分成页面生产、Figma 写入、前端实现、审查、合同更新等路由。AI 不是读完一大段就开始发挥，而是先知道自己现在该按哪套流程走。
02
不会靠“看起来像”交差
只有 MD：容易做出一个视觉相似但不可复用的假组件。 这个 skill：要求说明 exact-match / rule-derived / system-gap。每个产物都要说清楚：是真的命中 OPPO 组件，还是按规则推导，还是系统没有现成能力。这样你能一眼看出可靠程度。
03
不会把上下文吃爆
只有 MD：规则越多越长，最后 agent 抓不到重点。 这个 skill：query-first，只查当前任务需要的一小段。做结算页就查结算模式和相关组件；找图标就查图标合同；要 token 才查 token。上下文轻，命中更准。
04
资产是真的资产
只有 MD：常把 Figma 链接、截图、说明文字当“资产”。 这个 skill：Logo、图标、插画、字体都落到 assets 并登记。页面里用的 OPPO logo、Search、Account、Bag、Menu 等都要有本地文件和合同记录。临时 SVG、文字 OPPO、占位 icon 不能冒充。
05
能验收真实产物
只有 MD：最后只能靠肉眼看“像不像”。 这个 skill：生产自检会读取 artifact 并跑 validator。`navbar/default` 不是在 JSON 里写命中就算数，校验器会检查真实 HTML / 前端文件里有没有引用规定资产。
06
后续能继续长大
只有 MD：越改越像大杂烩，没人知道真源在哪。 这个 skill：合同、参考文档、脚本、Codex 运行版本有固定更新顺序。新增 token、组件、页面模式、资产时，不是随手补一句话，而是先改机器合同，再同步人读规则和校验逻辑。
04 / 能力边界
它现在最值得讲清楚的，是能承诺什么，以及不能假装什么。
这比“怎么喊它”更关键：一个治理型 skill 的可信度，来自它知道哪里能自动化，哪里必须标记为缺口。
- 按页面模式、组件合同、token 和资产规则组织页面
- 用真实 OPPO logo、图标、字体、插画替代临时占位
- 对前端、Figma、审查任务输出命中等级和风险说明
- 不能保证写入 Figma 的页面全是规范组件 instance
- Figma candidate 不能直接等同于 OPPO exact-match
- 不会修改组件库 master component，也不会覆盖原稿节点
- 逐个确认 Figma componentKey、variant、slot 和状态
- 为关键组件补截图验证和示例写入结果
- 证据完整后，才把 candidate 升级为 confirmed / exact-match
最终定位
这是一个让 AI 产物更像“按 OPPO 设计系统生产出来”的约束引擎。
它最适合放在页面生成、Figma 写回、前端实现、设计审查、资产导入和规范更新这些环节里使用。它不追求把所有资料塞给 agent，而是让 agent 在每一步都知道：该查什么、能用什么、不能假装什么、最后怎么验。
当前状态：token、资产、组件/模式合同全部校验通过。
包体策略：大合同保持 query-first，避免上下文浪费。
真实运行：源包已同步到 Codex 实际读取的位置，避免“源包是新版，运行还是旧版”。