状态：系统定义与 YUDS、实现项目、产品三方职责已由用户确认，以原文保留；本页对使用方法和适用边界的细化为建议，可调整。本页引用的 D01—D05 初始设计基线由代理依用户授权采用，不是用户逐项确认。本页不表示设计资产、代码或产品已通过验收；正式组件 API、已支持环境与真实测试仍须独立证明。 更新：2026-10-18（UTC+8），文档初稿 v0.2。
系统定义（已确认原文）
YUDS（Yiplex Unified Design System）是 Yiplex 正在建设的统一设计系统，为产品、设计与开发团队提供共同的设计语言、交互规则和可复用资源，帮助团队持续构建清晰、一致、易于使用且具有可访问性的企业软件。它重点服务数据密集、业务关系复杂的工作场景，让用户更容易理解信息、作出判断并完成操作。
YUDS 将设计原则与使用指南、视觉和语义基础、设计变量（design tokens）、组件、任务模式及页面模板组织为相互衔接的体系，并通过工具、文档、版本与贡献机制支持设计到实现的持续协作。它希望统一不同产品和平台中相同概念、操作与状态的表达、关键交互行为和质量要求，同时允许布局、输入方式和系统行为作适合平台与任务的调整；统一不要求各端像素或实现完全相同。
当前资源与能力仍在建设和验证中。
三方职责（已确认原文）
- YUDS：规定共同设计语言、组件行为、业务交互模式，以及可用性与无障碍验收要求。
- 具体实现项目：将规范实现为组件代码，并维护规范与代码的对应关系。
- 产品：负责业务模型、计算规则与流程配置。
例如，表格的筛选、编辑反馈、错误提示与键盘操作由 YUDS 定义交互要求；资产估值公式由产品定义。具体实现项目按规范实现组件。本次只确认职责分工，不指定承载项目、框架或平台；具体规则和验收标准仍需逐条讨论。确认依据见 决策与讨论记录。
面向谁，解决什么
| 使用者 | 当前困难 | YUDS 应提供的帮助 | 不由 YUDS 决定 |
|---|---|---|---|
| 业务操作人员 | 多条记录、多阶段协作、反复录入与找资料 | 可发现操作、任务上下文、批量范围、明确恢复路径 | 行业审批权、财务或合同结论 |
| 分析与研究人员 | 多维表格、口径不同、版本变化 | 同屏比较、数据口径、来源与时间说明、可访问分析路径 | 指标模型、预测方法与事实真伪认证 |
| 管理及审核人员 | 摘要背后证据不足、待办缺少下一步 | 摘要到明细、风险提示、责任与阶段说明 | 替代个人授权或专业判断 |
| 产品、设计与开发团队 | 相同问题反复设计、设计与实现偏离 | 共同契约、可复用模式、测试与变更对应 | 选定所有技术栈、包管理或服务架构 |
不同角色的默认视图可以不同，不能把角色名称当权限本身。权限由产品授权系统判断，展示与执行均需遵守真实授权。
什么属于通用规则
纳入 YUDS 的候选应满足：
- 多个任务出现同一用户意图；
- 行为与信息风险可说明；
- 离开某个行业仍有意义；
- 能用独立场景验收。
只在一个产品出现的细节先在产品内验证，不因看起来像组件就立即全局抽象。
例如：金额字段的标签、单位、只读和错误呈现可通用；税率、税基和四舍五入政策由产品提供。流程步骤的状态与返回机制可通用；合同是否允许跳过审核不能由通用步进器决定。
四层内容怎样衔接
- Foundation / 基础规则：颜色用途、排版、空间、密度、内容与数值表达等共同语言；token 是这些决定的一种表达方式，不能代替行为约定。
- Component / 组件：有独立输入、输出、状态与操作约定的可复用单元。按钮、字段、选择器和数据网格均可在此定义契约，复杂度不决定归属。
- Pattern / 任务模式：围绕完整用户任务组合组件和状态，例如查询结果、批量修改、审批、导入与冲突解决。领域算法与服务端规则仍归产品。
- Page template / 页面模板：组织导航、信息层次、工作区域与模式的页面骨架。实例页面加入真实业务内容，不把领域逻辑固化进通用模板。
同一专题可以涉及多个层次。例如，表格组件负责焦点与选择事件，批量处理模式负责跨页选择范围、预览、结果与恢复。这是职责划分，不要求建立四套重复目录。
规范用语与状态
- “应／不得”表达相应规则在其采用范围内的行为要求；须同时读取决定状态，不能仅凭措辞把候选规则或设计输入称为已发布实现标准。
- “可”表示按任务决定的可选能力，不要求所有组件或产品实现。
- “候选”表示需要产品、设计和实现验证后确定的取舍；没有数据支持时不写成量化承诺。
- “已确认”限于决策记录有明确来源的方向或全文；“代理依据用户授权决定／已采用”标明 D01—D08 等有记录的普通可逆设计决定，不冒称用户逐项亲自确认；其余未采用细则仍标建议、可调整。
- “实现已验证”必须另有平台、版本、场景与实际结果。文档齐全不等于实现完成。
使用这套文档完成一次设计
- 说明用户、对象、任务起止、权限与成功条件；指出是读取信息还是改变业务状态。
- 从页面模板选择工作骨架，再选任务模式；只组合任务真正需要的组件。
- 为关键数据说明含义、状态与来源，为操作补齐范围、反馈及恢复路径。
- 用正常状态与失败、中断、权限变化等场景评审设计，再映射到具体实现与测试。
- 未覆盖情形先写产品局部例外及理由，验证通用性后贡献回 YUDS。
首批建议用三条任务检验：查询比较、编辑并提交、异常定位与恢复。这是检验建议，不是首发产品排期，见端到端任务旅程与验收案例。
SCOPE-01：采用工作稿时必须交付什么
一个任务的设计交付同时列出：
- 所用规范提交／版本；
- 适用平台与输入；
- 产品提供的对象／授权／版本规则；
- 采用的设计决定及其主档；
- 仍未决定的项目和真实验证状态。
缺少业务能力时，应将相关动作标为不可用或说明限制；不能为了填满规范样例而伪造保存、撤销、审批或查询协议。
本页内容沿用先写后展示、可修订的流程。D01 色值、D02 字体尺度、D03 八变体／六材质职责、D04 单主操作及 D05 四端设计目标已由代理依用户授权采用，见决策与讨论记录「代理初始设计基线 D01—D08」。正式组件 API、已支持环境、真实测试与生产业务事实仍须独立证明。文档规则 ID 用于定位，不是组件 API 或新公共颜色别名。
本章验收
- 评审任意规则时，可以明确它归规范、实现还是产品；无负责人时不能用“组件处理”掩盖空白。
- 一份设计同时标明所用规范版本、产品规则来源及尚未实现项。
- 不把用户授权、业务状态改变与浏览页面混为一谈。
下一章：六条设计原则。总览：YUDS 统一设计系统。