给跨 3+ 产品面跑设计系统的产品设计师。颜色原则、字号 scale、组件理由作为卡片，agent 在提任何改动之前先读。
你按钮用了 sentence case。8 个月后你记不清为什么。新设计师建议 title case。没有理由记录，每个季度从零再决定一遍。
移动用 sentence case，web 用 title case，邮件模板用 ALL CAPS。没人发现直到品牌审计。每个面各自演化，没看其他面。
你跟 Claude 说"链接用 semantic-blue 不用 brand-blue，因为可访问性对比"。3 周后新对话，Claude 又建议 brand-blue 链接。
c-03 decision: 链接用 semantic-blue 不用 brand-blue + c-04 observation: brand-blue 在 warm-paper 背景下 WCAG AA 不过作为 →supports 证据。两个永远可引。
你写一个跟 web 原则冲突的移动原则。Draftlize 的 conflict_detect 标成 gap_kind=conflict 卡，两边同时显示，发版前。
新对话："设计一个新的错误态。"agent 读 c-03（链接色）、c-08（sentence case 原则）、c-15（错误语调指南）作为 ambient context。建议出来就已经跟系统对齐。
打开 Draftlize，agent 浮现 3 张被标 stale 的卡（你昨天改了颜色原则）。5 分钟更新受影响的组件 spec。
新 gap_kind=conflict：移动选了 sentence case，邮件模板提议 title case。决定哪个对（sentence case 赢），更新邮件原则卡。
agent 读你所有设计原则卡，生成 `design-doc` 视图过滤到你今天 review 的组件。10 分钟 review，没有先例上的意外。
"5 秒内捕到跨 3 个面的 sentence case 违规。以前每次设计 review 前要花 30 分钟手动检。"— Diego，金融科技 staff 产品设计师（Draftlize dogfood）
30-60 分钟把现有设计原则种进 Draftlize。第三次 review 时，agent 已经在不需要你重新解释的情况下把建议跟你系统对齐。
用 $5 免费开始