Rules keep AI on-style. Judgment keeps it on-task.规则让 AI 守样式， 判断让它不答错题。
The design calls — what becomes a rule, what stays a one-off — were mine; the component, AI-rule, and token-lint system scaled them.哪些沉淀为规则、哪些只是一次性——这些判断由我做；组件、AI 规则与 token-lint 这套系统，把它规模化。
01Build — components + AI rulesBuild — 组件 + AI 规则
02Check — token-lint reviewCheck — token-lint 审查
Role角色Led component adaptation, AI Skill rules, and the token-lint review workflow负责组件适配、AI Skill 规则定义与 token-lint 审查流程搭建
Rules were never the hard part — deciding what to enforce, and what to leave to judgment, was.规则从来不是难点——难的是决定：哪些该强制执行，哪些该留给判断。
The product is a teacher-facing education platform, migrating to a newer design language while most pages still ran on the legacy one. The cost showed up downstream — teachers met visibly inconsistent pages, and the team couldn't roll out the new language at speed. The rules existed; what was missing was anything that kept them executable once a page left the design file. I built the system to close that gap — but the harder calls were design judgment: which drifts to encode as rules, and which to leave to a person.这是一个面向教师的教育平台，正迁移到新版设计语言，但大量页面仍运行在旧版实现上。代价出现在下游——教师看到的是明显不一致的页面，团队也无法快速铺开新设计语言。规范本身已经存在；真正缺的，是一套能在页面离开设计稿后仍保证其被执行的机制。我搭建了一套系统来弥合这一缺口——但更难的判断在设计层面：哪些漂移应沉淀为规则，哪些应交由人来判断。
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 提高了搭建速度，但如果没有可执行约束，它无法稳定遵循新版风格和产品模式。
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 规则
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 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.这套 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构建 — 组件库The Vue3 component package — the executable base the system builds from.Vue3 组件包——系统据以生成的可执行底座。
→
Generate — rule-compliant page生成 — 合规页面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 use perceptual color difference (ΔE) to suggest the nearest token, returning an explainable value rather than a bare “violation.”生成得快还不够。审查层会扫描运行时 CSS，识别非 token 用法，把问题记录下来，而不是只靠肉眼走查。颜色检测用 ΔE 感知色差匹配最接近的标准 token，给出可解释的建议值，而非仅标记“违规”。
In this example, a 10pxpadding-bottom issue is surfaced with 8px / 12px token suggestions.这个图例中，工具识别出 padding-bottom10px，并给出 8px / 12px 的 token 建议。
4h → <1hMulti-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 every surface rule but misses the product intent entirely — the gap isn't visual polish, it's the missing pattern underneath.AI 可能生成一个处处合规、却完全错过产品意图的页面——缺的不是视觉打磨，而是底层缺了一种范式。
Case check案例判断
Answer-sheet setup needed a pattern, not a prettier page.答题卡设置要的是一种范式，而非更漂亮的页面。
After designing an exam, a teacher still has to build its answer sheet — laying out each question's answer region, setting scores, and adding the marks that make it machine-scannable. AI returned a clean, on-style page — but an information one: methods and a support matrix, with no way to configure a sheet. It passed every style rule and did the wrong job. The call wasn't to polish it, but to see the requirement needed a configuration pattern — so I designed it, and it became components and rules.老师设计完一场考试后，还要为它制作答题卡——逐题排布作答区、设置分值，并加上让它可被机器扫描的标记。AI 产出的是一个干净、合规的页面，却是一张信息页：罗列制卡方式与学科支持矩阵，无法真正配置一张卡。它通过了每一条样式规则，却做错了任务。判断不在于把它做漂亮，而在于看清需求要的是一种配置范式——于是我把它设计了出来，并沉淀为组件与规则。
AI's answerAI 的答案 A clean, on-style information page — creation methods and a support matrix — but nothing a teacher could configure a sheet on.一个干净、合规的信息页——罗列制卡方式与支持矩阵——但老师无法在上面配置一张卡。The pattern I designed我设计的范式 A layout editor with per-question answer regions, scoring, and print/scan settings.一个带逐题作答区、分值与印刷/扫描设置的排版编辑器。
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 约束和运行时审查标准。
What it can actually do, honestly: when a requirement fits within about three pages and existing components cover it, the system generates a usable interaction draft directly. Past that line — more pages, or components that don't exist yet — the output isn't a usable draft, and a designer steps in. Naming that boundary was the point: the system carries the routine, so judgment goes where it counts.它真正能做到的、坦白说：当需求在三页以内、且已有组件可覆盖时，系统能直接生成一份可用的交互稿；一旦越过这条线——页数更多，或所需组件尚不存在——产出就不再是可用的交互稿，需由设计师接手。划清这条边界本身才是关键：系统承担常规，判断去往真正重要的地方。
From one issue to a reusable rule从一次问题到一条规则
A recurring issue around transparent primary-color usage moved from manual judgment into the system: first evaluated by design semantics, then added to component guidance, and finally included in token-lint checks.主色透明度在不同场景中的复用问题，从人工经验判断进入系统：先经过设计语义评估，再补进组件规范，最后加入 token-lint 检查。
