交付不靠嘴：用标注和组件规则让还原更稳定

交付阶段最消耗精力的不是画完一张页面，而是反复解释同一个意图。今天解释按钮为什么要这样留白，明天解释卡片阴影为什么不能换，后天解释为什么某个状态要禁用。解释次数越多，偏差越大，返工越频繁。好的交付不是让开发记住你的想法，而是把想法变成规则，让任何人都能按规则做出同样结果。

标注和组件规则就是这种规则的载体。它们不是额外工作，而是让还原稳定的基础设施。

很多标注失败是因为只标了尺寸，却没标语义和状态。一个控件需要标清它是什么，例如主按钮还是次按钮；它在哪里，例如与哪些元素对齐；它怎么变，例如不同状态下颜色、描边、透明度怎么变化。只标尺寸会让实现看起来差不多，但细节和交互会跑偏。

建议把标注拆成结构标注和行为标注。结构标注负责尺寸、间距、对齐；行为标注负责状态、交互反馈、异常提示。两者缺一不可。

逐页标注在规模化时一定会崩，因为页面太多、改动太快。更可持续的方法是用组件约束代替逐页标注：按钮组件定义内边距、最小高度、圆角、状态；输入框组件定义边界、占位文案、错误态；列表项组件定义密度、分隔线规则。页面只需要引用组件，标注工作就会从页面层转移到系统层。

组件约束越清楚，页面越不需要解释。开发看到组件名就知道用哪套样式，改动也能在组件层统一处理。

很多偏差发生在状态上：默认态看起来还行，悬停态、按下态、不可用态就开始乱。原因是交付时没有把状态当成一等公民。建议为关键控件提供完整状态说明，至少包括默认、悬停、按下、不可用、加载。并说明状态切换触发条件，例如悬停只在桌面出现，加载持续到请求完成。

状态说明不需要很长，但必须明确。越明确，越少临场发挥。临场发挥往往会变成不一致。

实现最怕的是边界条件没人说清。文字过长怎么办，图片缺失怎么办，列表为空怎么办。很多返工来自这些边界没被提前定义。建议在交付时为关键模块补充边界说明：文本最多显示几行，超出如何截断；图片加载失败显示什么；空状态文案和按钮如何呈现。边界条件越清楚，线上越稳定。

边界条件不是负担，它是你对产品负责的体现。把它写出来，开发也会更放心。

很多验收靠截图对比，结果变成像素战争。更有效的验收方式是基于规则：对齐线是否一致，间距是否来自档位，状态是否齐全，文案是否符合规范。规则验收能让讨论聚焦到原则，而不是聚焦到某个像素。

当规则明确，截图对比只是最后的确认，而不是主要沟通方式。交付就会从解释变成协作。

如果每个页面都带一份规则说明，团队会很快忽略它。建议把可复用的规则集中在一个入口，例如组件库页面或设计规范文档。页面交付只引用规则入口，并补充该页面特有的部分。这样开发不需要在多个文件里找同一条规则，更新规则时也不会到处漏改。