在最近的一个企业软件项目中，我们使用了一个 Figma 文件，该文件需要同时支持传统的开发人员交接和 AI 辅助开发。仅其中一个部分就包含了数十个屏幕，用于记录产品的单个组件。
每个画面单独来看都说得通，难点在于理解它们如何组合在一起。
对于参与该项目数月的设计师和开发人员来说，很多背景信息早已耳熟能详。我们知道哪些屏幕代表初始状态，哪些操作会导致每次变化，哪些状态是备选方案，以及哪些细节仍在讨论中。
面对这份文件，编码代理完全不了解这些背景信息。单个屏幕提供的上下文不足以解释完整的行为，而整个画布又引入了太多无关信息。我们需要一种方法，围绕单个交互组织相关的框架、状态和决策，以便在人工智能辅助开发中更有效地理解和使用它们。正是这种需求催生了我们的 Box 设计系统。
Box 设计系统是我们用于将复杂的产品行为组织成 Figma 画布上界限分明的区域的方法。每个区域都包含理解产品某个部分所需的屏幕、状态、转换、注释和实现上下文。这使得文件更易于浏览，同时也为 AI 辅助开发做好了结构准备。
在我们设计的企业平台中，仅导航一项就包含了多种相互关联的行为。用户可以与浮动导航栏交互、选择资源、直接浏览地图或在层级结构中移动。所有这些操作都在同一个界面中完成，但它们并不属于同一流程。
将所有屏幕放在一个大的序列中，虽然会让文件看起来很完整，但却会造成逻辑上的歧义。因此，我们将相关的状态分组到不同的框中，例如“浮动栏”、“选择资源”、“直接地图探索”和“层级结构”。每个框代表体验的一个连贯部分。
最初，这样做是为了简化复杂的界面，方便用户浏览。随着人工智能代理融入开发流程，这些方框又有了新的用途：它们为实施过程创建了更清晰的上下文单元。
以下是塑造该体系的四大原则。
页面是一个视觉容器，它并非总是有效的开发边界。
一个页面可能包含多个独立的交互。单个交互也可能跨越面板、叠加层、菜单和多个屏幕状态。
在我们的项目中，选择资产和浏览地图的操作都在同一个主界面中完成。从视觉上看，这两个屏幕的结构基本相同。然而，从功能上看，它们代表了不同的操作行为。
如果将它们视为同一组，则需要开发人员或代理来区分哪些更改属于资源选择，哪些属于地图探索。团队对此区别很清楚，因为我们已经反复讨论过。但这种区别未必能从像素层面体现出来。
因此，我们按照层级结构组织这些盒子，而不是将每个盒子视为平等的单元。该系统分为三个层级：
这种结构允许开发人员从整体功能入手，逐步细化到具体的流程，最终实现到具体的屏幕行为，而不会丢失它们之间的关联。这也意味着，实现任务的范围可以围绕团队需要构建的行为来界定，而不是页面上所有可见的元素。
一个实用的盒子不应该需要设计它的设计师亲自讲解才能使用。
打开文件的人应该能够理解交互的作用、交互的开始位置以及用户在交互过程中发生的变化。
这并不意味着要把产品文档的每一部分都复制到 Figma 里。而是要包含足够的上下文信息，以消除最主要的歧义。
根据功能的不同，一个盒子可能包含：
这种自包含的结构对人类团队至关重要，尤其是在成员后期加入项目或几周后重新参与某个功能开发的情况下。对于编码代理来说，这一点更为重要。
代理程序无法记住讨论交互的研讨会内容。它不知道是哪条 Slack 消息改变了需求，也不知道哪个视觉差异是故意设计的。它只能根据给定的上下文进行操作。
如果关键信息位于画布上的其他位置，或者隐藏在评论串中，或者只存在于团队的记忆中，那么代理必须推断出缺失的信息。
而推理正是可避免的错误开始的地方。
各个屏幕显示不同的界面状态，但并不总是解释用户如何在这些状态之间切换。
在我们的设计文件中，我们使用简单的箭头来连接交互及其产生的屏幕或状态。例如，如果点击按钮会打开侧边栏，我们会将该操作与设计的侧边栏状态连接起来。如果交互会将用户引导到另一个屏幕，箭头会准确地指示他们将到达的位置。
并非所有交互都需要这种处理方式。为简单或显而易见的操作添加箭头可能会造成不必要的视觉干扰。当一个屏幕包含多个可能的交互，每个交互都指向不同的状态或流程阶段时，箭头就显得尤为重要。
对于已经参与产品开发数月的人来说，这些关联可能早已显而易见。但开发者和人工智能代理未必了解这些关联。如果没有这种明显的联系，代理可能识别出所有屏幕，但仍然无法理解哪个操作会产生哪个结果。
结合层级式方框，这些连接使得用户体验的结构和顺序更容易理解。方框显示了哪些屏幕属于同一功能和流程，而箭头则解释了用户如何在它们之间移动。这是一种简单的做法，但它减少了开发人员和客服人员需要从设计中推断的信息量。
AI 编码工具现在能够访问的信息远不止屏幕截图。通过Figma MCP 服务器等工具连接后，代理可以从文件的选定部分检索结构化设计信息、视觉参考、变量、组件和布局数据。然而，在 AI 辅助开发中，获取更多信息并不会自动带来对需要构建内容的更深入理解。
孤立的框架可能会忽略理解某种行为所需的周围状态。而另一个极端是，大页面或全屏显示可能会引入不相关的屏幕、未解决的概念，以及同一功能的多个版本。“盒式设计系统”在这两种极端之间创建了一个实用的中间层。
开发者无需要求智能体“构建此页面”，而是可以引导它进行包含相关状态、转换和上下文信息的有限交互。这样，智能体就获得了足够的信息来理解预期行为，而无需解读整个产品。
盒子的边界不必与单个代码组件完全匹配。有些盒子可能对应一个组件，而有些盒子可能涉及多个组件和应用程序状态。盒子的作用是定义正在实现的产品行为，而不是决定最终的代码架构。
生成的代码质量仍然取决于代码库、提示信息、设计系统实现以及代理对现有组件的访问权限。Figma 还建议使用语义命名、变量、自动布局、可重用组件、注释和代码连接来提高一致性。这些框通过将这些元素组织成代理可以理解并执行的连贯的产品行为，来完善这一基础架构。
干净的 Figma 画布无法弥补未定义的产品。
如果团队尚未决定交互方式，将屏幕置于方框内并不能消除根本的不确定性，而只会让这种不确定性更加显而易见。
那仍然很有价值。
当相关状态放在一起时，不一致之处会更加明显。团队可能会发现同一行为的两个相互竞争的版本、没有恢复路径的异常，或者讨论过但从未设计过的状态。
方框并不会取代平台的设计系统。虽然主设计文件使用方框来组织屏幕、流程和产品行为，但设计系统则位于一个单独的 Figma 文件中，其中包含这些设计中使用的共享组件、变体和变量。
设计系统无需遵循盒式设计层级结构，但其结构应足够清晰且足够详细，以便智能体能够准确理解自身需求以及在文件中找到所需内容的位置。清晰的命名、逻辑分组和一致的组件结构有助于开发者和人工智能智能体找到并重用正确的元素。如果没有这种结构和相应的代码，智能体即使理解了预期行为，仍然可能选择错误的组件或创建不必要的临时元素。
框架定义了范围和行为。设计系统定义了界面的构建方式。代码库定义了它在生产环境中的运行方式。
多年来，设计文件的整理通常被视为内部事务。整洁的文件更易于查找、更便于交接，也更方便下一位设计师使用。
这已经不是全部真相了。
随着设计文件成为人工智能辅助开发的直接输入，它们的结构开始影响智能体理解的内容、忽略的内容以及必须推断的内容。
画布不再仅仅是团队展示最终界面的地方，它正在成为软件构建系统的一部分。
我们基于模块的方案源于一个实际需求：让复杂的企业级产品更容易理解。当同样的结构帮助将产品拆分成更清晰的单元，便于实施和审查时，它的价值就得到了提升。
盒子本身并非创新之处，创新之处在于它们带来的清晰性。
组件定义了界面的构成。框架捕捉各个瞬间。方框解释了这些瞬间如何相互关联，以及团队试图构建什么。
在与人工智能代理日益共享的开发过程中，这种背景信息不再是可有可无的文档。
它是产品的一部分
