展开本页目录
开始前准备什么
- Node.js与npm已可运行；练习只需本地文本文件和官方@google/design.md CLI，不需要Stitch账号或付费生成。
- 固定当前CLI版本并保留版本号；DESIGN.md仍为alpha格式，升级前先在练习副本复核。
- 本课给出作者自制规则文件和预期，不把预期JSON冒充已执行的官方CLI返回。
- 保存不可变的旧版本
- 只修改用途说明
- 制造一次真正token变化
- 运行两次diff
- 检查tokens分类
- 审阅findings差额
- 合并人工批准的变更
1. 保存不可变的旧版本
把基线规则存为DESIGN-v1.md，记录primary与button-primary的引用。
另存副本再修改，不在原文件上覆盖后声称还能回看旧版。
2. 只修改用途说明
在prose版本中把主色说明从“按钮和导航”改为“只用于主要操作”。
所有YAML token保持相同，先用这个版本确认文本变化不等于色值变化。
3. 制造一次真正token变化
在v2中改primary并新增一个指向不存在颜色的悬浮按钮。
保留修改清单，只让这两个变化参与第二轮比较。
官方界面与功能位置
以下为官方文档配图，具体版本与账号入口以当前产品为准。本课练习输入与验收对照见相邻步骤。
4. 运行两次diff
分别比较v1到prose、v1到v2，保存两份原始JSON。
命令的before与after顺序不能反过来，否则新增和移除会颠倒。
5. 检查tokens分类
查看colors的modified和components的added，不用整段JSON长度推断变化大小。
如果说明修改影响了其他结构，回查是否误动了YAML围栏。
6. 审阅findings差额
核对before、after和delta，确认新增坏引用如何影响regression。
diff用新增error或warning判断回归，颜色不同本身并不自动等于失败。
7. 合并人工批准的变更
修复坏引用后再做一次diff，把主色批准理由与真实渲染截图关联。
保留说明版本和最终版本，避免下次把未经批准的色值当既有基线。
下载本课材料并开始操作
练习包包含本课的具体输入、可编辑数据、正反样例与七步说明。index.html 可离线查看原件和验收参考，actual-results.csv 用于记录你实际操作后的结果。
怎样确认已经完成
- before/after顺序与版本文件一致。
- 颜色和组件差异可定位，说明-only版本不冒充色值变化。
- 新增问题修复后重跑，报告与批准理由对应。
常见问题
DESIGN.md diff显示modified，就一定是回归吗？
把只改用途说明和真正改颜色分别保存为两版，对基线运行两次 diff，再独立 lint 新版本。区分语义说明、token 数值与新增引用错误，diff 输出不代替完整规范校验。
能不能只保存diff，不保留两份原文件？
不建议。没有原文件就不能重跑，也无法查看用途说明或CLI版本变化；应保存v1、v2、diff与批准理由，且标明实际运行版本。