学习如何通过提示使用设计令牌与组件规则，在 React 应用中实现一致的 UI，使 AI 生成的界面在间距、排版和表单上保持统一。
UI 不一致通常体现在那些随着操作而感觉“怪怪的”小细节上。一页有宽松的内边距，另一页显得拥挤。标题在大小上跳变，按钮形状与颜色发生变化，相同的输入在不同页面表现不同。
大多数时候，漂移源于几项基础决策的不一致：
当屏幕由不同提示生成时，这种情况很常见。每个提示实际上都是一次全新的开始，模型会去猜测缺失的决策。即便只是说“使用现代样式”，仍要做出数百个微小选择：8px 还是 12px 的间隙，正文 14px 还是 16px，何时显示错误，主按钮应如何呈现。
你可以手动修两三页，但这无法扩展。你会一直追着补一次性 CSS、在文件间复制样式并反复修复表单。规则存在于你的脑中，而不是项目里。
想象今天生成一个登录页，明天生成一个个人资料页。如果一个页面只在提交时显示错误，而另一个在失去焦点时就显示，用户会注意到。如果主按钮在不同页面高度不同，整个应用就像被拼凑出来的一样。
当每个页面遵循相同的共享系统时——设计令牌（间距、排版、颜色）加上一小套组件与表单规则——一致性就成为默认行为。
设计令牌是你在界面中重复使用的简单命名值。不必在每个屏幕都写“舒适的内边距”，可以使用像 space-4 这样的令牌。即便之后你更改了具体数值，名字仍然稳定。
令牌就是你希望每个页面共享的一组决策。它们去除了“品味”和猜测，而这些正是生成或构建新页面时导致漂移的原因。
典型的令牌涵盖间距、排版、颜色、形状和少量层次。好处很实际：页眉总是用相同大小，卡片总是用相同内边距，主按钮保持相同的颜色和圆角。
把会影响产品整体感觉的东西令牌化：间距刻度、字号与行高、核心颜色（文本、背景、主色、危险色、边框）以及一小组边角半径。
把内容驱动的选择保持灵活，例如文案长度、使用哪个图标，或某个区块是否需要两张或三张卡片。
当你生成屏幕（包括使用像 Koder.ai 这样的工具）时，事先提供一小套令牌可以减少猜测，使输出明显更一致。
令牌集只是允许值的一个短菜单。越小越好，因为随机选择的余地更小，但它仍需覆盖那些让页面看起来不协调的基本项。
从间距开始。选一个刻度并在所有地方使用它来做内边距、间隙和布局。一组如 4、8、12、16、24、32 覆盖了大多数 UI。如果设计需要 10px 或 18px，记得向最近的令牌取整而不是引入新数字。
然后定义排版默认，让标题和正文不再漂移。你不需要庞大的字体系统，但需要明确、可重复的步骤。
一个紧凑且实用的集合示例：
无障碍也属于系统范畴。定义一个焦点轮廓样式（颜色、粗细、偏移），让键盘用户获得一致的焦点状态。设定最小触控目标（如 44x44）用于移动端。把文本颜色限制在一小组可信的颜色中，以保持对比度可预测。
如果按钮有时显得拥挤，往往是因为一个页面用了 10 的内边距，另一个用了 12。有了令牌，你可以规定：“按钮使用 paddingY=8、paddingX=16、radius=12、焦点轮廓令牌、最小高度 44。”一旦这些数字固定，生成器就不会再随意发挥。
令牌决定数值。组件规则决定习惯。
挑一小套核心组件并把它们作为页面的唯一构建模块。保持它们朴素且可复用：Button、Input、Select、Checkbox、Card。你可以添加 TextArea 和 Modal，但它们应遵循相同的系统（标签、间距、状态）。
接着，限制变体并定义允许出现的情形。例如：Button 有 primary、secondary 和 danger。Primary 用于页面中的主要操作（通常只有一个）。Secondary 用于取消或低优先级操作。Danger 仅用于删除等破坏性操作。如果变体无法被证明必要，则默认使用 secondary。
间距规则可以防止细微漂移。在组件内部定义默认值：按钮内边距、输入高度、标签与字段间隙、堆叠字段间的标准间距。再加几条布局规则：卡片使用固定内边距和一致的标题/主体间距；模态框使用相同宽度步进和页脚对齐方式。
最后，让状态不可协商，因为 UI 常在此处开始显得随意：
当你生成像“创建项目”这样的表单密集页面时，这些规则能防止混合按钮尺寸、标签位置跳动或仅在某页出现的一次性“特殊”卡片。
即便视觉稳定，许多“感觉怪”的投诉也来自表单行为。如果每个页面对标签、错误和焦点的处理不同，用户会觉得不一致。
选择一个表单模式并在所有地方使用：标签、可选/必填标记、辅助文本，然后错误文本。文案也要一致（例如，标签使用句式大小写，辅助文本简短，错误信息以动词开头）。
能防止大多数漂移的规则：
锁定尺寸和布局，避免页面“呼吸”得不同。定义一个输入高度、一个按钮高度和默认字段宽度。在桌面端，把字段对齐到一致的网格并将标签堆叠在输入之上。在移动端，让字段占满宽度，除非确有必要，否则避免两栏表单。
一个简单示例：一个“创建项目”页面可能有 Name、Region 和 Description。即便 Region 是一个 select，也把它当作普通字段：相同高度、相同标签位置、相同错误行。如果用户在提交时 Name 为空，焦点移动到 Name，错误在其下方显示，布局保持稳定。
如果你在 Koder.ai 里生成屏幕，把这些表单规则放在提示里并跨功能复用，让每个新表单都遵循同样的行为，无需反复清理。
把提示当成一份小型的 UI 合约。保持简短、明确且可复用，让每个新页面都按同样的间距、排版、组件和行为落位。
一个实用的做法是在请求顶部粘贴一段精简的 UI 规范，然后用通俗语言描述屏幕。
UI SPEC (apply to every screen)
Tokens:
- Spacing: 4, 8, 12, 16, 24, 32
- Radius: 8
- Typography: H1 24/32, H2 18/26, Body 14/20
- Colors: text, muted, bg, primary, danger (no custom hex)
Components (must use): PageShell, Section, Card, Button, Input, Select, TextArea, FormRow, HelperText, Toast
Layout rules:
- Page padding: 24 desktop, 16 mobile
- Section spacing: 24
- Card padding: 16
- Grid: 12 cols desktop, 4 cols mobile, gap 16
Do:
- Reuse components and tokens only
- Keep labels above inputs, helper text below
Do not:
- Invent new spacing values, font sizes, or one-off CSS
- Mix different button heights or input styles
If a new component is needed:
- Extend an existing component pattern and document it in the output
- Do not create new visual styles outside tokens
在规范之后，添加一些验收检查以早期捕捉漂移：
如果你在使用基于对话的生成器，请在请求间保持此规范稳定。每次都改变规范会破坏初衷。
在生成任何内容前先写好 UI 合约：一小套令牌（间距、类型、颜色、圆角、阴影）加上一段短组件清单（Button、Input、Select、Card、Modal、Table、Toast）。如果缺少令牌或组件，模型会自己创造，导致 UI 漂移。
然后创建一个参考屏幕来检验规则。表单密集页是个好基准，因为它包含标题、辅助文本、校验错误、主/次按钮和成功提示。把这个屏幕当作基线。
之后，通过组合已有定义来构建新屏幕。不要要求“重新设计样式”，而是要求相同的 Card、相同的间距刻度、相同的排版步骤和相同的字段模式。
一个简单的工作流：
如果“搜索用户”页面的间距比参考页面更紧，不要手动修外边距。更新间距令牌或 Card 内边距规则，再重新生成。
如果你在 Koder.ai 工作，快照与回滚能在这里提供帮助：锁定基线，安全试验，如果某次修改引入漂移则快速回退。
失去一致性的最快方式就是把令牌和规则当成建议。小幅例外会在新页面中乘数增长。
一个常见陷阱是在项目中间更改间距刻度。早期页面使用 8、16、24。新页面因为“看起来更合适”而引入 10 和 18。现在漂移被允许，旧页面也不会被更新。
另一个漂移来源是让生成器创造新的组件样式。如果你不说明“只存在这些按钮变体”，它可能在某个页面创建新的圆角或不同的输入内边距。
状态也是常被忽视的点。加载、空和错误状态常在后期被临时拼凑，通常会产生与其余部分不匹配的模式。
还要留意模糊的指示语：“做得现代一些，带柔和阴影”很模糊，而像“错误显示在字段下方”、“禁用按钮保持焦点样式”和“Enter 仅在最后一个字段提交”这样的行为规则则具体且可重复。
如果你想要一个轻量级的提示守则块用于粘贴，保持简短：
在合并生成屏幕前做两分钟扫描。
从间距开始。查找像 13px 那样的随机值或为“让它合适”而加的一次性外边距。如果你使用令牌，每一个间隙都应该来自批准的集合，包括 gutter、卡片内边距和表单字段间距。
然后检查排版是否符合你的类型刻度。标题应按可预测的步骤递减。相似区块之间正文不应切换字号。行高也很重要，尤其是在设置页这类信息密集的界面上。
接着扫描按钮。变体和尺寸应遵循你的规则：主操作用 primary，次操作用 secondary，只有真正删除时才用 danger。按钮高度、图标位置和标签样式都应一致。
对于表单，一致性主要体现在结构上。标签保持在同一位置，必填指示遵循统一规则，辅助文本和错误不互相竞争，错误出现在一致的位置。
一个简短的检查表：
最后，做一次移动端检查。缩小宽度，确认布局在不引入新字号或新间距的情况下自适应。
想象一个简单的引导流程：三个屏（Profile、Preferences、Confirm），之后还有一个 Settings 页面。你希望每个屏看起来像同一位设计师出的，即便它们是分开生成的。
在生成任何东西之前，提供一小套令牌和一些组件规则：
TOKENS
- spacing: xs=4, sm=8, md=12, lg=16, xl=24
- radius: sm=8, md=12
- type: body=14/20, title=20/28, label=12/16
- layout: pageMax=960, sectionGap=24, fieldGap=12
COMPONENT RULES
- Page: max width=pageMax, padding=xl, sectionGap between blocks
- Card: padding=lg, radius=md
- Field: label above, helper below, fieldGap between fields
- Button row: primary on right, gap=sm
- Errors: shown under field, same copy style, no alerts
现在分别生成“Profile”和“Preferences”。因为两个屏都必须使用 Page、Card、Field 和 Button row，它们会获得相同的边距、标签间距和按钮位置。Confirm 步骤虽然包含更多只读文本，但仍然契合整体风格。
表单行为是漂移常出现的地方，所以一次性定义并复用它：提交前禁用直到校验通过，仅在 blur 或 submit 后显示内联错误，Enter 仅在最后一步提交，Back 按钮不清空已填内容。
当你需要新的 UI 组件时，不要让模型即兴发挥。添加一条规则，然后带着复用的目的重新生成：
把令牌和规则转成一份你会实际使用的可复用规范。如果它太长以至于无法粘贴，它就不会被遵循。
一份实用规范通常包括：你的令牌表（间距、排版、圆角、颜色）、一小段组件规则（按钮、输入、卡片、标题）、表单行为规则（校验时机、错误、禁用/加载）、布局默认（页面内边距、最大宽度、区块间距），以及一段“永远不要做”的短清单（随机外边距、一次性字号）。
然后养成一个习惯：先更新规范，而不是修补单个像素。
如果你在使用 Koder.ai (koder.ai)，planning mode 是在生成前重申并确认规范的好地方。当你想尝试变体时，snapshots 和 rollback 帮助你在不破坏稳定基线的情况下探索。
因为每次请求屏幕都是一个新的起点。如果你不提供共享系统，生成器会自己填补缺失的细节——间距、字体大小、按钮内边距、阴影和表单行为——于是小差异就会在页面间累积。
设计令牌是命名且可复用的值，用于间距、字号、颜色和圆角等。\n\n你不再说“舒适的内边距”，而是使用像 space-md 的名字。名称保持稳定，每个屏幕重复使用同样的决策，UI 就不再漂移。
从小处着手，覆盖那些会带来可见漂移的项目：\n\n- 间距： 4、8、12、16、24、32\n- 排版： 1 个正文大小 + 2 个标题大小 + 固定行高\n- 颜色： text、muted、bg、surface、border、primary、danger\n- 圆角： 两个值（例如 8 和 12）\n- 阴影/层次： none、small、medium\n\n如果需要新的值，尽量向最近的令牌取整，而不是引入 10px 或 18px。
把一段精简的 UI 规范块 放在每次请求的顶部，把它当成合同：\n\n- 列出令牌（间距/排版/颜色/圆角）\n- 列出允许使用的组件（Button、Input、Card 等）\n- 添加强制规则（不使用新间距值、不写一次性 CSS）\n\n然后在其下方描述屏幕。关键是让规范在各次请求中保持不变。
令牌定义数值；组件规则定义习惯。常见有用规则包括：\n\n- 按钮：固定高度、内边距，且只有少数变体（primary/secondary/danger）\n- 输入：统一高度、标签间距、边框/聚焦样式\n- 卡片：固定内边距且标题/主体间距可预期\n- 布局：标准页面内边距和区块间距\n\n默认规则：如果无法证明某个变体的必要性，就回退到标准样式。
选择一个模式并在所有地方使用它：\n\n- 标签始终在字段上方（不要用 placeholder 做标签）\n- 辅助文本始终在字段下方（不要用来显示错误）\n- 每个字段正下方只有一行错误提示\n- 错误展示时机：在 blur 或 submit 后显示，并在 change 时清除或更新\n\n这能避免“一个屏幕在 blur 验证，另一个只在提交时验证”的常见不一致。
定义几条不可妥协的状态规则：\n\n- 加载（Loading）： 禁用控件，显示 spinner，保持宽度不变\n- 禁用（Disabled）： 降低对比度，但保留焦点行为\n- 空状态（Empty）： 简短提示 + 一个明确操作\n- 错误（Errors）： 内联显示在字段下方；避免大范围布局位移\n\n如果不指定状态，屏幕往往会各自创造自己的模式。
不要让它随意即兴样式。把新组件作为现有模式的文档化扩展：\n\n- 基于当前令牌和熟悉的容器（通常是 Card）\n- 使用现有令牌定义尺寸、间距和状态\n- 把它添加到批准的组件列表中供未来使用\n\n如果无法用令牌描述它，通常说明它过于定制，会导致漂移。
先创建一个“参考”屏幕来检验系统（表单密集页是个好压力测试），然后为每个新屏幕复用相同规范。\n\n在 Koder.ai 中，你可以使用 planning mode 在生成前重申并确认规范，使用 snapshots and rollback 在试验时保持稳定基线。
合并生成屏幕前的快速检查清单：\n\n- 间距只使用令牌值（没有随机数字）\n- 排版符合尺度（包括行高）\n- 按钮遵循相同的变体和尺寸规则\n- 表单采用统一的标签/辅助/错误结构\n- 存在各状态：hover、focus、disabled、loading、empty\n\n如果有问题，更新规范/令牌后重新生成，而不是修补一次性边距。