用一份真实文件落地 DFC Bridge

不要从重命名整个存档或重建组件库开始。先在一份工作页面或一个新区块上进行小规模试点，并测量交付是否变得更清晰。

先看选择边界：模态框可在内部解析，但 /workshop 路由需要在外部查找。此例因该 Deferred 依赖而为 Partial。区块检查并非总是 Partial，也不证明旧宿主合规或运行时集成正确。 查看原图。

图解入门展示 Figma 中的准备步骤。下面的试点用于衡量：完成这些步骤后，接收者是否更容易理解真实文件。

试点需要回答什么

• 其他人能否找到页面和宽度？
• 能否理解动作、状态和内容规则？
• 后续提问是否减少？
• 准备成本是否值得重复？

选择有用的范围

选择包含真实内容、至少一个响应式决定和一个重要动作的页面。不要使用没有状态和变化数据的干净演示文件。

如果新区块位于现有产品中，请标记所选根图层，不要编造页面元数据：

checkout-summary [section=checkout-summary]

第一次试点不要覆盖宿主页面。需要集成细节时，参见选定区块契约。

指定三个角色

角色	责任
设计师	准备所选范围，并在交付测试中不做口头解释。
开发或审核人员	阅读文件、记录问题并运行可用检查。
流程负责人	预先设定成功标准，并决定是否继续。

一个人可以承担多个角色，但交付测试需要作者之外的人参加。

五个步骤进行试点

1. 记录起点

在修改前请接收者独立阅读文件。记录时间、问题和假设。

2. 只补充缺失含义

按照设计师快速起步操作。不要重写存档，也不要重复 Figma 已有的属性。

3. 检查声明范围

整页运行 Check page，明确选中的区块根运行 Check selected section。修正相关问题后重新检查，并为未解决的依赖指定负责人。报告只是决策依据之一，不代表所有产品问题都已解决。

4. 重复交付

再次在没有会议的情况下交付文件。询问相同问题，记录相同指标。

5. 决定是否重复

只保留减少猜测的改动。将剩余事项分为阻塞项、有负责人的待解决问题、有意偏差或流程改进。

实用的成功标准

• 接收者能在五分钟内回答核心问题；
• 声明范围内没有阻塞问题；
• 每个待解决问题都有负责人和下一次检查日期；
• 记录改动前后的时间和问题数量。

不要把试点变成迁移

• 在第一次测量前不要重命名整个库；
• 不要把每个警告都当成阻塞项；
• 不要为了让示例整齐而隐藏真实状态和数据；
• 不要把一个就绪区块说成宿主页面就绪。

试点证明有价值后，再使用设计师清单、完整检查和路线图。