智能界面生成上线前的配置核对

智能界面生成上线前的配置核对我愿意让模型帮忙整理 Token但不会把它的输出直接塞进仓库。设计 Token 是组件间共用的接口错一个颜色值影响的可能不止一个页面。模型适合给候选映射能不能入库还是交给 Schema、类型检查和构建脚本。先把生成放在边界外关键是让失败信息能定位到具体字段而不是只报“构建失败”。例如颜色、尺寸和别名引用应当分别校验无法判断语义时宁可要求人工补充也不要猜一个默认值。npx ajv-cli validate \ -s ./schemas/design-tokens.schema.json \ -d ./tokens/generated-tokens.json --all-errors npx style-dictionary build --config ./config.json一个够用的校验入口import fs from node:fs; import Ajv from ajv; const schema JSON.parse(fs.readFileSync(./schemas/tokens.json, utf8)); const tokens JSON.parse(fs.readFileSync(./tokens/generated.json, utf8)); const validate new Ajv({ allErrors: true }).compile(schema); if (!validate(tokens)) { for (const error of validate.errors ?? []) { console.error(${error.instancePath || /}: ${error.message}); } process.exitCode 1; } else { console.log(Token 校验通过可进入编译步骤); }Schema 不必一开始追求覆盖所有业务字段。先约束value、type和引用格式再随着组件库演进补充语义层。输出 CSS 和 TypeScript 声明后再跑一次类型检查能挡住一部分错误引用。上线前我会看这几项凭证只在 CI 的密钥配置里使用不出现在 Token 文件、示例或构建日志中。生成产物带版本并可回退不要让发布任务就地覆盖唯一一份文件。失败日志只输出字段路径和规则不回显外部设计数据。对模型给出的新增命名做人工确认避免把临时文案固化成公共 API。把模型当成输入助手流程就会清楚很多它可以提高整理速度但不拥有发布权限。