本文是把设计规范写成代码格式Schema-As-Code方法论的诊断层定义。承接《组件语义快照》的观察记录和《组件语义分类与模式匹配》的分类框架说明当快照积累到一定数量后如何通过三层判定模型将分散的界面证据转化为可归类的模式节点。排序阶段一 · 诊断层介于组件分类与漂移模式证据库之间。本文基于 《组件语义快照与模式诊断AI 生成界面的第一道检查》 中的概念继续展开。摘要组件语义快照提供了结构化的界面证据组件分类建立了 5 种高频语义组件的归类维度。但快照和分类本身不自动产生模式——从记录到归类之间需要一层判定机制。我定义的三层判定模型组件类型识别 → 语义缺失判定 → 视觉表达校验就是这个机制。它的设计目标不是替代人的判断而是将人的判断过程结构化、可复用、可嵌入工程流程。第一层基于交互路径规则运行第二层基于语义关键词规则运行第三层目前依赖人工标注视觉解析的自动化需要计算机视觉支持尚未纳入当前实现范围。1. 为什么需要判定模型在使用组件语义快照记录证据的过程中我遇到的具体问题是当快照数量从 10 张增加到 50 张时按产品名称或时间顺序归档已经无法满足分析需求。但即使按组件类型component_type分组后同一组内的快照仍然呈现多样性——同样是错误提示组件有的快照记录的是红色乱用有的记录的是文案模糊有的记录的是缺少行动按钮。这说明组件类型只是第一层分类同一组件类型内部还存在语义缺失类型的差异。需要第二层判定来识别这些差异。进一步即使识别了语义缺失类型如后果差异未分级还需要第三层校验来确认当前界面的视觉表达是否与语义级别匹配。一张被判定为后果差异未分级的快照其视觉表达可能是全部红色也可能是颜色对了但文案模糊——这两种情况的修复优先级不同。因此判定模型需要三层每层处理不同维度的信息逐层收敛。2. 三层判定模型的结构2.1 第一层组件类型识别Component Type Classification输入单张组件语义快照含 visual_record、context 字段判定逻辑根据界面的交互路径而非视觉形态确定其归属的组件类型。判定条件组件类型用户遭遇系统异常操作被迫中断错误提示AI 执行多步任务用户等待过程中可见过程指示系统对请求作出拒绝、终止或升级审核响应边界反馈用户主动发起触发系统状态变更操作控件系统主动推送提示用户注意风险或状态变化状态提示边界处理若单张快照同时满足多个组件类型的判定条件如操作控件触发后引发边界反馈标记为复合类型后续需叠加应用多个组件类型的语义约束。输出component_type 标签单值或复合值2.2 第二层语义缺失判定Semantic Deficiency Detection输入已标注 component_type 的快照 user_confusion 字段判定逻辑提取 user_confusion 中的语义关键词匹配预设的语义缺失模式。语义关键词特征语义缺失类型对应模式 ID“不知道多严重”“不知道该做什么”“后果不明”后果差异未分级ERR-001“不知道在干什么”“检索还是生成”“可信度不明”认知阶段未显化PRO-001“上下文还在吗”“还能继续吗”“权利不明”会话状态未区分BND-001“点了会出大事吗”“能撤销吗”“风险不明”操作风险未标注ACT-001“这个词严重程度如何”“是否忽略”“权重不明”语义权重未对齐ALR-001“不知道哪一格错了”“怎么修正”“反馈不明”校验反馈未细化FRM-001判定规则关键词匹配采用包含逻辑而非精确匹配。单张快照的 user_confusion 可能同时触发多个语义缺失类型此时按优先级排序安全类 认知类 效率类取最高优先级作为主导缺失类型其余标记为关联缺失。输出semantic_deficiency 标签主导类型 关联类型列表2.3 第三层视觉表达校验Visual Expression Validation输入已标注 component_type 和 semantic_deficiency 的快照 visual_record 字段判定逻辑对当前界面的视觉表达进行结构化校验记录与语义级别不匹配的视觉映射。校验项校验内容记录格式颜色映射颜色是否与语义级别匹配color_token: 实际值 → 预期值文案精度是否使用模糊词汇或禁止同义词text_precision: 实际文案 → 标准文案行动完整性是否提供与后果级别匹配的用户行动action_completeness: 缺失行动列表示例一张被标记为 ERR-001后果差异未分级的快照visual_record 显示限流错误使用了红色背景则记录为color_mapping_mismatch: actual: status.critical (红色) expected: status.warning (黄色) severity_level: retryable输出visual_validation_report含映射不匹配项、缺失项、冗余项3. 输出与归档诊断报告三层判定完成后系统自动生成诊断报告包含以下字段字段来源说明matched_pattern第二层输出主导模式 ID如 ERR-001confidence_score三层交叉验证基于关键词匹配度 视觉校验一致性计算missing_token模式库定义该模式对应的缺失语义维度如error_severityarchive_path系统生成该快照在模式库中的存储路径next_action规则引擎判定“补充已有模式证据” 或 “触发新模式创建”归档规则confidence_score 0.85→ 自动归档到对应模式节点0.60 confidence_score 0.85→ 标记为待人工复核confidence_score 0.60→ 标记为待归类触发新模式创建流程4. 判定模型的工程实现4.1 当前实现状态层级实现方式状态说明第一层组件类型识别规则引擎基于 context 字段的关键词匹配✅ 已实现可自动运行准确率约 90%第二层语义缺失判定规则引擎基于 user_confusion 的关键词匹配✅ 已实现可自动运行准确率约 85%第三层视觉表达校验人工标注visual_record 的人工解析 半自动颜色映射可自动识别基于像素值文案精度和行动完整性需人工复核诊断报告生成脚本自动拼接三层输出✅ 已实现生成结构化 JSON可导入模式库4.2 自动化瓶颈第三层视觉表达校验的自动化需要计算机视觉支持颜色识别可通过屏幕像素值自动提取技术成熟文案识别可通过 OCR 自动提取但语义理解仍需 NLP 支持布局结构可通过 DOM 解析或图像分割自动提取但行动完整性的判断需要理解组件间关系当前策略颜色映射已实现自动化文案精度和行动完整性由人工复核计划逐步引入视觉模型辅助。5. 与前后文的衔接5.1 上游输入组件语义快照三层判定模型的输入是组件语义快照的 6 个字段。其中context字段驱动第一层判定组件类型识别user_confusion字段驱动第二层判定语义缺失判定visual_record字段驱动第三层判定视觉表达校验快照质量直接影响判定准确率。若user_confusion字段缺失或推断不准确第二层判定可能出现偏差。5.2 下游输出模式库节点判定模型的输出是诊断报告其中matched_pattern和missing_token字段直接写入模式库节点。模式库的结构为模式库 ├── 错误提示 │ └── ERR-001 后果差异未分级 │ ├── 症状多种异常共用同一种视觉表达 │ ├── 根因缺少 error_severity 语义维度 │ ├── 快照证据SNAP-202506-001, SNAP-202506-003... │ └── 诊断报告DR-202506-001, DR-202506-002... ├── 过程指示 │ └── PRO-001 认知阶段未显化 │ ├── 症状过程标签只描述动作不描述认知阶段 │ ├── 根因缺少 process_phase 语义维度 │ ├── 快照证据SNAP-202506-002... │ └── 诊断报告DR-202506-003...每个模式节点包含 5 个标准字段症状、根因、场景示例、快照证据、诊断报告。6. 局限与边界第二层判定依赖关键词规则当前语义缺失判定基于预设关键词表若用户困惑描述使用非标准表达可能无法匹配。计划引入语义相似度模型辅助。第三层尚未完全自动化视觉表达校验的颜色映射已实现自动化但文案精度和行动完整性仍需人工复核。置信度阈值主观confidence_score 0.85的自动归档阈值基于经验设定未经过大规模样本验证。复合类型的处理复杂当快照被标记为复合类型时需要叠加多个组件类型的语义约束当前规则引擎尚未支持复杂逻辑组合。7. 衔接从诊断到模式库三层判定模型解决的是把分散的证据组织成可追踪的知识。但它本身不产生新的模式——当confidence_score 0.60时快照被标记为待归类此时需要人工介入判断是否创建新模式。下一篇文章《6 个漂移模式AI 生成界面的语义断层证据库》将展示当前已通过三层判定模型归档的 6 个模式以及每个模式对应的快照证据和诊断报告。Gap 期局限性声明##当前状态 架构推演与最小可行原型阶段。YAML 规范、校验逻辑为定义层实现尚未接入生产级 LLM API 或 CI 流水线。欢迎基于现有思路共建。关于作者##魏雯体验架构设计师。专注于AI 界面的语义治理。解决的核心问题让 LLM 生成的界面不偏离设计规范。10 年互联网设计经验。设计系统 / 体验工程 / AI 原生广州 / 深圳