本页说明如何让内容、操作和状态在页面中形成关系。设计立场 说明理由，视觉语言 说明表达；组件的参数和模型时机从 README 进入对应参考。
先让用户辨认正在面对的对象，再安排理解它所需的信息、当前状态和下一步动作。标题、摘要、元数据与操作之间的主次应清楚；元数据接近其解释的内容，局部操作接近其作用对象，页面级操作则有稳定的位置。
页面可以同时容纳阅读和管理，但不必让每一项信息争夺同样的注意。普通列表、内容正文和设置表单的节奏可以不同，宿主负责根据真实任务决定导航与业务流程。
整理内容先于调整间距。重复的标题、复述同一状态的标签、没有帮助的说明和纯粹填空的图标应直接移除；需要保留的内容，再按当前任务决定出现的位置与时机。已有空间不要求被填满。
列表帮助识别和比较对象，详情承载进一步阅读，编辑态提供修改所需的信息。不要把三个层级的全部内容同时摆在列表里。有用但暂时次要的信息可放到展开区、详情或次级操作入口中，入口应可发现，并让人知道能在那里找到什么。若用户必须反复展开才能完成主要任务，就需要重新考虑哪些内容应直接出现。
界面随状态改变当前呈现的内容：保存期间保留输入与进度，失败后及时显示对应问题和恢复动作，无须同时陈列所有可能状态。影响当前判断的警告、校验错误和操作后果直接呈现；不能为了视觉简洁藏到容易错过的入口。
状态类别不自动决定它必须着色。常态的“已连接”、例行保存结果与普通进度说明默认使用中性色；当结果需要特别确认、风险需要处理或变化会影响下一步时，再用语义色强调关键文字或标记，详细说明保持普通文字的阅读层级。多个问题同时存在时，按影响范围与处理优先级组织，不为减少彩色而隐藏必要反馈。
容器变窄时，重新安排次要内容与操作的入口，保留主要任务及必要信息的可达性。切换尺寸、进入详情和返回列表时，草稿、选择与当前上下文应能延续。用完整操作过程检查这些变化，避免只让默认状态或一个尺寸显得简洁。
连续的说明、属于同一对象的字段、围绕同一结果的元数据，先通过顺序、对齐和间距形成一组。只有当封闭边界进一步说明了独立对象、交互范围或层次时，才增加容器。
例如，一个设置区块可以由标题、说明和纵向字段直接组成。给每个字段再包一层卡片，容易打断整组阅读，并让辅助说明看起来像另一个对象。相反，多个独立来源各有名称、状态和操作时，重复的条目或容器可以帮助辨认对象归属。应该比较这些关系，而不是统一要求所有内容使用或不用卡片。
列表条目具有共同结构时，通过稳定的对齐与顺序帮助比较；需要连续阅读的正文应保留完整内容。摘要是进入全文前的选择帮助，不能继续截断已打开的完整内容。
普通表单从纵向字段开始。标签靠近输入，说明与错误放在相关字段旁边；字段分组表达业务含义，不按底层组件类型分类。自带 label／error 的控件已经承担关联，自定义字段再补对应结构。
主要提交应能被辨认为这次修改的完成动作，取消和危险操作与其保持可理解的区别。校验失败应说明需要修改什么；保存失败应保留已经输入的内容，让重试有连续的上下文。保存期间保留动作文字与可读配色，并防止重复执行。
固定业务流程与 schema 生成表单承担不同的数据责任。先决定用户如何理解和修改内容，再选择实现；具体组合从 Web 的 InkForm、内置字段、InkField 以及现有配方进入。
确认需要让用户看清对象、后果和选择；内容浮层需要让人理解正在阅读什么、如何继续或返回。浮层内部不应因为处于弹层中就再重复一套页面外壳。
普通确认、需要等待的确认和自定义内容浮层各有适用语义。Web 的具体选择由 InkDoubleCheck、InkDialog、InkPopup 的参考说明。背景是否继续可操作、何时提交和何时放弃草稿，都应与当前任务一致，不能从外观推断。
加载、空结果、失败与确认有不同含义，应分别表达。错误反馈不要抹掉键盘焦点，进行状态也不应伪装成普通不可用状态。
宿主决定页面列数、外部留白和阅读区域，组件负责内部内容与操作布局。确定当前需要呈现的内容后，可用空间缩小时让相关内容换行或按既有阅读顺序排列；不要通过缩小正文、遮掉必要操作或裁切说明来维持双栏外观。
同一界面在宽屏与窄容器中可以看起来不同，但对象归属、信息主次和动作含义应能被追踪。标识符可以换行，结构化代码可以局部滚动；局部滚动不应吞掉整个页面的操作入口。具体对照见判断依据。