企业官网建设流程全解析

《ERR-001 错误状态诊断》与《PRO-001 过程状态诊断》已经证明了：AI 生成界面的语义漂移不是"感觉不对"，而是可以被结构化定位的真实问题——错误状态共用同一种红色、过程状态用模糊标签掩盖认知阶段，这些漂移都有明确的根因（缺少语义令牌）和可验证的修复路径（契约约束 + 机器校验）。

论证成立之后，下一个问题自然浮现：语义漂移只发生在"错误提示"和"进度条"里吗？ conversational 域（对话场景）中那些更隐蔽的边界——当 AI 说"我无法回答"和"会话已结束"时——是否也存在同样的结构性断裂？

毕竟，很多团队已经会区分"报错"和"加载中"了，但面对"拒绝请求"和"终止会话"这两种完全不同的权利事件，界面却常常给出同一种灰色提示。用户无法判断：对话历史还在吗？能申诉吗？这是"我不该问这个"还是"我被请出门了"？

本文就回答这个问题，针对边界动作一个场景：同一权利事件（被 AI 拒绝 / 被 AI 终止）在无语义令牌与有语义令牌两种形态下分别长什么样、差别带来什么能力，以及——最关键的——这个差别是不是真实存在。先看一个真实踩过的坑，再逐项展开设计前后的对照。

一、一条用户反馈引出的坑：被"请出门"时，界面什么都没说

某通用 AI 对话产品，用户连续追问一个敏感话题。第一次，界面弹出灰色提示"我无法回答这个问题"——对话继续，历史还在。第三次，界面弹出几乎相同的灰色提示"会话已结束"——上下文清空，必须重新开始。

两次提示：同一个位置、同一种颜色、同一类措辞。用户无法判断：对话历史还在吗？这是"我不该问这个"还是"我被请出门了"？能申诉吗？

用户在社区的真实反馈：“我不知道自己现在的处境，是换个话题继续，还是这个账号已经危险了。”

拒绝（Refusal）与终止（Termination）是两种完全不同的权利事件，界面却给了同一种表达。这不是文案问题，是语义边界问题——conversational 域内的权利状态没有机器可读的令牌锚定。

这套诊断方法（三层判定模型 + 组件语义快照）在 Schema-As-Code 证据链的前两篇已被验证：

• ERR-001 错误状态诊断 证明：四种错误后果共用同一种红色，根因是缺少error_severity语义令牌，修复后四级四色、机器可校验。
• PRO-001 过程状态诊断 证明：Searching/Reading 等模糊标签掩盖认知阶段，根因是缺少process_phase语义令牌，修复后四阶段显化。

本文沿用同一套诊断结构，将边界动作（BND-001）作为第三个案例归档。若你已读过前两篇，可直接进入第二节；若第一次接触，下表中的"三层判定"即对应：组件类型识别 → 语义缺失判定 → 视觉表达校验。

二、诊断证据：组件语义快照

snapshot_id:BND-20250608-001product:通用 AI 对话产品（跨产品归纳，不绑定单一产品）component_type:边界动作visual_record:界面显示两类系统回应，均使用灰色提示条。标注框圈出： "我无法回答这个问题"（灰色提示条，输入框保留）、 "会话已结束"（灰色提示条，输入框置灰，无说明）user_confusion:"不知道对话历史还在不在。看到提示条我以为是普通的拒绝， 结果发现整个会话没了，之前的内容全丢了。"context:用户在会话中连续触发安全策略后匹配模式:BND-001（权利差异未区分）

三层判定过程：

归档：confidence_score ≥ 0.85（跨产品一致证据充分），自动归档至模式库BND-001边界动作的诊断节点。

三、根因：缺少 boundary_action 语义令牌

系统知道"触发了安全策略"，但没有区分策略级别是"拒绝执行"还是"终止会话"。前端只接收到blocked = true的布尔值，不接收边界动作的性质（软性拒绝 / 强制终止 / 升级审核）——与 ERR-001 错误状态诊断 的isError = true同构：布尔值压缩了语义级别，AI 只能按视觉惯性生成。

用户的权利边界在界面语义上模糊，挫败感来源于"不知道自己的处境"。这是 conversational 域特有的漂移：该域的约束要求"边界动作必须说明会话状态"，而没有boundary_action令牌，这条约束无物可锚。

四、通用场景分类：三种边界动作的权利差异

三者的用户后果完全不同：拒绝是"此路不通，请绕行"；终止是"会话结束，权利状态变更"；升级是"等待裁决，权利待定"。视觉表达与信息说明必须与权利后果匹配——行动与后果匹配原则（fatal → 刷新/导出，transient → 等待/重试）在边界动作上同样成立。

跨产品一致性证据：通用 AI 对话产品（安全拒绝和会话终止相同视觉）、AI 客服产品（敏感问题处理和账户封禁相同提示）、AI 教育产品（内容过滤和账号限制相同反馈）。

共性结论：当"拒绝请求"和"终止会话"在界面上无法区分时，即触发BND-001边界动作诊断。

五、Before / After：同一对象的两个形态

Before（无语义令牌）

系统输出blocked = true，AI 生成统一的灰色提示条。色板合规、措辞无害，视觉走查挑不出毛病——但用户读不到自己的权利状态。

合规，但错误。

After（boundary.* 令牌 + 契约约束）

# 契约文件：contracts/BND-001.yaml（节选）intent_id:"BND-001"description:"边界动作权利差异未区分：系统无法区分软性拒绝、强制终止和升级审核，导致用户无法判断自身权利状态与会话上下文是否保留。"version:"1.0.0"semantic_domain:"conversational"applicable_products:["*"]semantic_tokens:boundary_action:soft:# 软性拒绝：对话继续，上下文保留description:"拒绝当前请求，但会话与用户权利状态不变"visual_mapping:color_token:"status.warning"icon_token:"info.circle"user_action:-label:"换个话题继续"action:"continue_session"priority:1llm_constraints:-"必须说明拒绝原因"-"必须提供替代建议"-"必须明确告知对话上下文已保留"hard:# 强制终止：会话关闭，上下文清空description:"会话被终止，上下文清空，必须重新开始"visual_mapping:color_token:"status.critical"motion_token:"none"icon_token:"alert.octagon"user_action:-label:"了解数据保留政策"action:"view_data_policy"priority:1-label:"申诉"action:"appeal"priority:2llm_constraints:-"必须明确告知会话已终止、上下文已清空"-"必须说明数据保留政策"-"必须提供申诉入口"review:# 升级审核：提交人工，等待裁决description:"请求已提交人工审核，权利状态待定"visual_mapping:color_token:"status.info"icon_token:"clock"user_action:-label:"查询审核状态"action:"check_review_status"priority:1llm_constraints:-"必须显示预计审核时间"-"必须说明审核流程"immutable_boundaries:-boundary_type:"safety"rule:"禁止将强制终止（hard）表达为普通拒绝样式而不说明上下文已清空"violation_action:"block"-boundary_type:"semantic"rule:"禁止终止场景缺失申诉入口与数据保留政策说明"violation_action:"block"

修复后的机器判定逻辑：AI 若把 hard 级终止画成 soft 级灰色提示条，语义层校验直接命中"视觉权重与权利后果不匹配"；若省略申诉入口，安全层命中不可变边界第二条，block。错误在生成阶段就无法成立。

六、这个差别是真实存在的吗：跨产品真实反馈汇总

权利边界模糊的后果，不是理论推演，是跨产品反复观察到的现实：

• 把终止当拒绝：用户继续输入无果内容，在已经清空的会话里白费力气；
• 把拒绝当终止：用户放弃本可继续的会话，以为账号已经危险；
• 审核等待无状态：升级审核中没有状态可查询，用户重复提交，反而加剧处罚。

这个坑也不只属于用户侧。同一根因在不同角色身上的表现：

共性结论：LLM 生成边界提示时只有"拒绝"一个语义槽位，没有"权利状态"的概念——boundary.soft/hard/review三个令牌把权利状态编码为离散、可校验的语义单元，降级路径在生成前被封死。

七、框架设计背景：从 边界动作诊断 回到 把设计规范写成代码格式 全景

BND-001 边界动作诊断不是孤立案例，而是 Schema-As-Code把设计规范写成代码格式 框架设计假设的一个验证切片。要理解这个案例的价值，需要先看到它在整个框架中的位置。

7.1 语义治理框架全景：三阶段与机制网络

Schema-As-Code把设计规范写成代码格式 不是一套理论，是一条可执行的三阶段流水线（Semantic Pipeline）。

BND-001边界动作诊断 横跨三个阶段：

• Guard 阶段：通过 三层判定模型 将"拒绝与终止混为一谈"归档为模式卡片
• Contract 阶段：将三种权利状态编码为 语义令牌，写入 YAML 契约，经 编译管线 生成 4 种消费格式
• Verify 阶段：通过 三层验证（生成前注入、开发中校验、提交时拦截）证明规则有效

7.2 案例验证：边界动作诊断 证明了什么

证明一：语义漂移可被结构化定位

BND-001边界动作诊断 的发现不是某位设计师"感觉不对"，而是通过 三层判定模型 被归档为模式卡片：

• 第一层识别组件类型为"边界动作"
• 第二层判定语义缺失为"权利差异未区分"
• 第三层校验视觉表达为"拒绝与终止共用同一种弹窗"

同一套诊断结构在 ERR-001（错误状态共用红色）和 PRO-001（过程状态模糊标签）中已被验证。BND-001边界动作诊断 作为第三个案例，证明了这套方法在 conversational 域的权利边界上同样成立。

证明二：语义必须编码为离散令牌

BND-001 的修复不是"改个颜色"或"加句文案"，而是把三种权利状态编码为 语义令牌表 中的离散条目：

• boundary.soft：拒绝，对话继续
• boundary.hard：终止，上下文清空
• boundary.review：升级，等待审核

这些令牌被写入 语义字典 注册为组织级语义码本。契约 BND-001.yaml 通过引用字典中的令牌，声明了跨层禁止规则（status.critical不可用于 observational 域、boundary.hard必须显示申诉入口）。

契约不是文档，是机器可执行的规则——前端按令牌映射渲染，CI 按规则拦截，AI 按 Prompt 前缀注入约束。

证明三：修复必须被证明有效

BND-001边界动作诊断 的终点不是契约写入，而是验证闭环：

• 编译为 Prompt 前缀 后，AI 生成边界提示时不再只有"拒绝"一个语义槽位
• 编译为 JSON Schema 后，前端实现时blocked = true的布尔值被强制扩展为boundary_action枚举
• 编译为 CI 规则 后，缺少申诉入口的终止场景在提交时被阻断

这套验证机制在 《字典引用的机器防线》 中被完整定义。《前端与 AI 工程师》 详细描述了三项资产如何在工程师工作流中被消费。

7.3 回到开篇的三个问题

conversational 域内的权利边界漂移是真实存在的吗？
是。跨产品反复观察到拒绝与终止被画成同一种表达。

根因是什么？
布尔值压缩了语义级别。blocked = true没有区分拒绝、终止、升级三种权利状态。

契约如何修复？
把权利状态编码为离散语义令牌，写入契约，由机器校验执行。

这个案例同时也回答了更底层的问题：为什么需要 Schema-As-Code 把设计规范写成代码格式 这套框架？

因为语义漂移不是主观感受，而是可以被 结构化定位、被 契约修复、被 机器验证 的工程问题。当"拒绝"与"终止"在界面上无法区分时，框架提供的不只是诊断方法，而是一套从发现问题到证明有效的完整工作流。

参考链接：

• 方法论总纲：把设计规范写成代码格式
• 阶段一 Guard 结构化诊断
• 组件语义快照：6 字段记录法
• 三层判定模型与模式匹配机制
• 6 个漂移模式：语义断层证据库
• 阶段二 Contract 语义契约化
• 语义规范体系：YAML 里写的不是颜色值
• YAML 契约格式
• 契约库：让设计规范像代码一样管理
• 编译管线：语义一致性的机器翻译层
• 语义字典：设计系统组件的语义覆盖层

八、下一站

• 边界所在的域模型合法性（为什么是 conversational 域、域边界如何定义），见 B2《语义域：组件是空容器，语义由场景定义》；
• boundary.* 令牌的跨层使用规则如何被机器守住，见 《跨层禁止如何被机器守住》；
• 域内新边界场景如何定义入典，见《定义域（模版）》；契约如何正确引用域，见《所有契约引用域（模版）》；
• 姊妹案例：《ERR-001 错误状态诊断》、《PRO-001 过程状态诊断》。

附录：模式速查表