Design System / GovernanceAI 工作流 · 治理

Build ⇄ Check

Build rules.
Check output.
设计系统:立规则,查产出。

Standards become components and AI rules; token-lint checks the output — a build-and-check loop.规范落成组件与 AI 规则,再用 token-lint 审查产出——一个搭建 + 审查的闭环。

01Build — components + AI rulesBuild — 组件 + AI 规则
Code-side component library
02Check — token-lint reviewCheck — token-lint 审查
token-lint runtime review
Role角色Led component adaptation, AI Skill rules, and the token-lint review workflow负责组件适配、AI Skill 规则定义与 token-lint 审查流程搭建
Product产品Teacher-facing education platform面向教师的教育平台
Users用户Designers, frontend engineers, AI-assisted builders设计师、前端工程师和 AI 辅助搭建者
Output产出Executable rules, component documentation, automated review workflow可执行规则、组件文档和自动审查流程
01 — The Brief01 — 项目命题Legacy + new system新旧系统并存

The challenge was not writing rules, but keeping them executable after handoff.问题不是没有规范,而是规范离开文档后还能不能被执行。

The product is a teacher-facing education platform moving toward a newer design language while still carrying legacy implementation. Component coverage was limited, AI-generated pages could not reliably follow the updated style, and some development work bypassed shared components, making design QA expensive. That gap became a workflow connecting components, AI rules, and review checks. 这是一个面向教师的教育平台,正在迁移到新版设计语言,但大量页面仍运行在旧版实现上。新版组件覆盖有限,AI 生成页面难以稳定遵循新版风格,部分开发实现也没有复用组件,导致设计走查成本很高。我把这个问题拆成三件事:组件如何复用、AI 如何按规则生成、产物如何被检查。

New and legacy systems coexisted.新旧系统并存。

New features needed to follow the updated design language while still living inside legacy product and code structures.新需求要遵循新版设计语言,但仍运行在旧版产品与代码结构中。

Code drifts.实现会偏离规范。

A page could ship with approximate colors, off-token spacing, or inconsistent component usage even when the design system was clear.即使设计系统清楚,页面仍可能出现近似色、非 token 间距或组件用法不一致。

AI can match the surface, not the rules.AI 会模仿形,不一定守规则。

Generation made speed easier, but without executable constraints, it could not reliably follow the updated style or product patterns.AI 提高了搭建速度,但如果没有可执行约束,它无法稳定遵循新版风格和产品模式。

02 — Governance Loop02 — 治理闭环Build + check, two layers搭建 + 审查,双层闭环

A closed loop for building with rules and checking the output.一套从规则落地到结果审查的闭环。

The workflow worked in two layers: one helped pages get built from rules; the other checked the output and fed issues back into the system. 这套流程分为两层:执行层负责按规则生成页面,审查层负责检查产物是否仍然符合规则,并把问题回流到系统中。

It also exposes missing components or token gaps before development starts. 它也能在开发前暴露缺失组件和 token 规则缺口。

01

Standards规范

Design tokens, component patterns, and interaction rules.设计 token、组件模式与交互规则。

02

Build搭建

Vue3 components turn standards into reusable execution.Vue3 组件承接规范,让页面搭建可以复用。

03

Generate生成

AI Skill rules guide page structure and component choice.AI Skill 约束页面结构与组件选择。

04

Review审查

token-lint checks runtime output and exports issues.token-lint 检查运行结果并导出问题。

Feedback updates tokens, components, and AI rules问题回流到 token、组件和 AI 规则
03 — Execution Layer03 — 执行层52 Vue3 components52 个 Vue3 组件

Make rules executable before generation starts.在生成开始前,先让规则可执行。

This was not about redrawing components. I adapted legacy Vue2 assets into Vue3, documented component behavior, defined AI Skill rules, and built token-lint checks. 这不是重新画一套组件库,而是把旧版 Vue2 组件资产适配到 Vue3,并补充组件行为文档、AI Skill 规则和 token-lint 检查。

Code-side library代码侧组件库

Components became the execution layer.组件成为规范的执行层。

Connected the codebase, component package, AI generation, and runtime review into one shared rule system.连接代码仓、组件包、AI 生成和运行时审查,让各方基于同一套规则工作。

AI constraintsAI 约束

Rules moved from tacit knowledge into generation.把依赖经验记忆的规则,写进 AI 生成过程。

The ~1,400-line Skill encodes rules that once lived in memory and were lost at handoff — two-decimal precision on ratios, domain-correct counting units, red (not green) for a rising rank, and a single navigation component.约 1400 行的 Skill 把过去依赖记忆传递、易随人员变动流失的规则,固化成生成前的可执行约束——例如比率保留两位小数、计量单位用“题”而非“道”、排名上升用红色而非绿色、导航采用 SecondRouter。

Token rulesToken 规则

Runtime checks made quality review repeatable.运行时检查让质量走查可复用。

Token rules turned colors, spacing, type, and states into values that could be checked after generation.Token 规则把颜色、间距、字号和状态转化为生成后可检查的数值。

Build — component library构建 — 组件库 Code-side component library: navigation and component examples
The Vue3 component package — the executable base the system builds from.Vue3 组件包——系统据以生成的可执行底座。
Generate — rule-compliant page生成 — 合规页面 AI-generated exam-report list page following the design system rules
An exam-report list requirement, generated into a page using the system’s component, spacing, color, and state rules.考试报告列表需求,按系统的组件、间距、配色和状态规则生成为页面。
Source-confirmed coverage源码确认的规则覆盖 Verified against production source — AI Skill rules (component choice, structure, spacing, typography, data semantics, trend colors, navigation) and runtime-checkable token standards.对照生产源码核对——AI Skill 规则(组件选择、结构、间距、排版、数据语义、趋势色、导航)与可在运行时检查的 token 标准。
04 — Review Layer04 — 审查层4h → <1h4h → <1h

After generation, token-lint made rule drift visible.页面生成后,用 token-lint 暴露规则偏差。

Fast generation was not enough. The review layer scans runtime CSS values, flags off-token usage, and turns issues into review records instead of relying on visual guesswork. Color checks don’t rely on string matching; they use perceptual ΔE difference to find the nearest standard token (#333 → gray-9, ΔE 1.8), returning an explainable suggestion rather than a bare “violation.” 生成得快还不够。审查层会扫描运行时 CSS,识别非 token 用法,把问题记录下来,而不是只靠肉眼走查。颜色检测不做字符串比对,而是用 ΔE 感知色差匹配最接近的标准 token(如 #333 → gray-9,ΔE 1.8),给出可解释的建议值,而非仅标记“违规”。

token-lint runtime scan showing violations and token suggestions
In this example, a 10px padding-bottom issue is surfaced with 8px / 12px token suggestions. 这个图例中,工具识别出 padding-bottom 10px,并给出 8px / 12px 的 token 建议。
4h → <1h Multi-page token-compliance review多页面 token 合规走查 Estimated against prior manual review — not formally measured.对比过去人工走查的估算,非正式统计。

Violations export as handoff records for engineers — the review produces a fix list, not just a verdict. 违规项导出为开发可处理的交接记录——走查产出的是一份修复清单,而不只是一句结论。

token-lint answers one question — is this value in the token set? It doesn’t judge fidelity, check margins or gaps, read component semantics, or cover interaction states (third-party defaults and inherited styles need a human call, with per-item ignore as a fallback). The tool stops here; design judgment takes over. token-lint 只回答一个问题——“这个值是否在 token 集内”;它不判断还原度,不检查 margin/gap,不识别组件语义,也不覆盖交互状态(第三方默认色与继承样式需人工判断,并提供逐条忽略兜底)。工具止步于此,其后是设计判断。

05 — Human Judgment05 — 人的判断Bug / gap / system rule实现偏差 / 组件缺口 / 系统规则

Not every issue should become a rule.不是每个问题都应该变成规则。

token-lint can expose drift, but design judgment decides whether it is an implementation bug, a component gap, or a system-level update. token-lint 能暴露偏差,但设计判断决定它是单次实现问题、组件缺口,还是需要沉淀为系统规则。

01Value数值

The system can flag token drift.系统可以发现 token 偏离。

Color, spacing, type size, radius, shadow, and line-height can be checked against runtime values. The design decision is whether the drift is a one-off implementation bug or a missing rule in the token system.颜色、间距、字号、圆角、阴影和行高可以通过运行时数值检查。设计判断在于:这是一次性的实现偏差,还是 token 体系中缺失的规则。

02Component组件

A component can be used and still be wrong.用了组件,也可能不适合任务。

The review can expose inconsistent component usage. The designer still needs to judge whether the component semantics fit the workflow, or whether a business-specific pattern should be added.审查可以暴露组件使用不一致,但设计师仍需要判断组件语义是否匹配当前流程,或是否需要补充业务场景组件。

03Intent意图

A compliant page can solve the wrong task.样式合规,也可能答错题。

AI may generate a page that follows surface rules but misses the product intent. For answer-sheet setup, the gap was not visual polish; it was the absence of the right configuration pattern.AI 可能生成一个表层合规的页面,却没有解决正确的产品任务。答题卡设置的问题不在视觉质量,而在缺少正确的配置模式。

Case check案例判断

Answer-sheet setup exposed a missing configuration pattern.答题卡设置暴露出缺失的配置模式。

The useful review moment was not simply finding a bad screen. It was deciding whether the issue belonged to implementation, component semantics, or the design system itself. 有价值的审查并不是简单找出一个错误页面,而是判断问题属于实现偏差、组件语义,还是设计系统本身需要补规则。

Another successful AI-generated page following design system rules
Matched intent意图匹配
A teaching-supervision requirement mapped clearly to existing data-display components, states, and layout rules. 教学监管需求可以清晰映射到已有的数据展示组件、状态和布局规则。
AI-generated page with compliant style but wrong intent
Missing pattern模式缺口
The answer-sheet setup requirement needed a dedicated configuration pattern, not a generic information page. 答题卡设置需要专门的配置模式,而不是一个普通信息页。
06 — Outcome06 — 结果信号From issue to rule从一次问题到一条规则

The outcome was a reusable quality workflow, not a static component library.最终产物不是静态组件库,而是一套可复用的质量流程。

The value was not a static component library. It was a workflow where design rules became implementation, AI constraints, and runtime review criteria. 这个项目的价值不在于静态组件库,而在于设计规则被转化为实现方式、AI 约束和运行时审查标准。

Built构建

52 Vue3 components, documented52 个 Vue3 组件,建档

Components and interaction rules became the executable base.组件与交互规则成为系统的可执行基础。

Constrained约束

AI Skill rules at generation time生成时的 AI Skill 规则

Page structure, component choice, spacing, and data semantics — before output.产出前的页面结构、组件选择、间距与数据语义。

Checked审查

token-lint runtime reviewtoken-lint 运行时审查

Implementation checked against tokens; issues exported as handoff records.对照 token 检查实现,问题导出为可交接记录。