框架設計背景本文是 Schema-As-Code 證據(jù)鏈 的框架設計站屬于主題行的第一個關鍵設計——語義令牌表Semantic Token Table。在前序章節(jié)中階段一 Guard 結構化診斷通過組件語義快照與三層判定模型發(fā)現(xiàn)了6 個漂移模式語義域建立了組件是空容器語義由場景定義的覆蓋層模型。但語義要能被機器識別、校驗與生成必須先解決一個編碼問題如何把語義概念變成機器可運算的離散值本文要建立的正是 Schema-As-Code 的語義編碼層——當語義規(guī)范體系需要被寫入YAML 契約時語義必須以離散令牌的形式存在而非自然語言描述。1. 問題語義是感覺還是可運算的值行業(yè)現(xiàn)狀中語義以自然語言或視覺樣式存在設計師說這個要用紅色前端看到 #EF4444AI 生成工具看到 color: red。但紅色在不同場景下含義完全不同——在語義域的 transactional 域它是阻斷確認在 observational 域它可能是非法綁定跨層禁止。當語義以顏色值、文案詞或感覺的形式流動時機器無法區(qū)分同一個紅色在不同場景下是否合法。6 個漂移模式中的 ERR-001錯誤狀態(tài)后果差異未分級根因正是如此致命錯誤、網(wǎng)絡抖動、限流、降級四種完全不同的后果共用同一種紅色——因為機器看到的只是 color: #EF4444而不是 error_severity.fatal 與 error_severity.retryable 的語義區(qū)別。沒有離散令牌就沒有機器可執(zhí)行的判定依據(jù)。2. 為什么自然語言守不住語義不可運算設計規(guī)范文檔用自然語言描述語義“致命錯誤用紅色脈沖限流用黃色時鐘”。但自然語言對機器是不可運算的●AI 生成工具讀不懂致命錯誤與限流的區(qū)別它的訓練語料里只有 red 和 yellow●前端工程師看到的是 Design Token color-danger 和 color-warning但 danger 與 warning 的語義邊界沒有機器定義AI 可以把 color-danger 用在成功狀態(tài)●驗收走查依賴人的主觀判斷感覺不對無法轉化為可復現(xiàn)的校驗規(guī)則。組件語義快照的 6 字段記錄法已經(jīng)證明觀察界面時需要記錄 component_type、visual、copy、interaction、context 等維度。但這些字段的值如果是自由文本如 color: “red”仍然不可運算。語義令牌表的作用就是把紅色編碼為 status.critical把限流編碼為 error_severity.retryable——讓語義成為機器可查詢、可校驗、可攔截的離散值。3. 設計思路把語義概念編碼成離散枚舉本文的設計思路是三個遞進命題●語義概念 → 離散令牌error_severity 不是文檔里的段落而是包含 fatal、transient、retryable、degraded 四個枚舉值的令牌表每個枚舉值綁定唯一的視覺映射status.critical → 紅色脈沖與行動約束必須提供恢復路徑●令牌 → 字典注冊所有語義令牌在語義字典中注冊成為組織級唯一信源。契約YAML不定義令牌只引用令牌●令牌 → 可執(zhí)行規(guī)則編譯管線將令牌表編譯為 Prompt 前綴注入 AI 上下文、JSON Schema組件 Props 校驗、CI 規(guī)則流水線攔截——同一組離散值在不同工具鏈中以不同格式執(zhí)行同一語義。這與語義規(guī)范體系的關系語義規(guī)范體系定義有哪些語義維度語義令牌表定義每個維度下有哪些離散值。沒有令牌表規(guī)范體系只是分類框架沒有規(guī)范體系令牌表只是孤立枚舉。3.1 把意思變成編號機器看不懂紅色代表很危險機器看得懂 status.critical。把連續(xù)的自然語言描述變成離散的編號枚舉值。Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境里的例子不說紅色、很緊急、要刷新 → 說 status.critical不說黃色、等一等、能恢復 → 說 status.warning不說灰色、加載中、不用管 → 說 status.neutral為什么這樣做自然語言有同義詞“嚴重≈Critical≈危急”機器會搞混。編號沒有同義詞一個編號只對應一個意思。3.2 一個編號只綁定一套視覺status.critical 只能是紅色脈沖 八邊形圖標不能今天是紅色明天變成橙色。編號和視覺參數(shù)是鎖死的一對一映射。Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境里的例子編號顏色動畫圖標按鈕樣式status.critical紅色脈沖八邊形必須二次確認status.warning黃色靜態(tài)三角顯示恢復時間status.info藍色靜態(tài)信息可自動消失status.neutral灰色旋轉加載無為什么這樣做以前設計規(guī)范寫錯誤用紅色但不同前端可能用不同紅。編號鎖死后機器查表就知道唯一答案。3.3 同一個編號能翻譯成三種格式設計師寫了一份 status.critical 的定義機器自動把它變成三種東西給三種不同的人用。Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境里的三種格式給誰用格式內(nèi)容給 AI 寫界面的工程師Prompt 前綴“生成致命錯誤時必須用紅色脈沖…”給校驗代碼的機器JSON Schema{“color_token”: “status.critical”, “motion_token”: “pulse.red.urgent”}給 CI 流水線阻斷規(guī)則“如果在 observational 域用 critical阻斷合并”為什么這樣做設計師只寫一次三種消費方自動拿到自己需要的東西。不用設計師給工程師寫一遍、給運維寫一遍、給測試寫一遍。3.4 同一個顏色不同編號代表不同意思機器看到 #EF4444紅色不知道這是系統(tǒng)故障還是刪除按鈕。必須看編號才知道。Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境里的對比編號都是紅色但意思完全不同場景status.critical紅色系統(tǒng)故障對話可能丟了錯誤狀態(tài)action.destructive紅色刪除賬戶數(shù)據(jù)永久沒了操作按鈕為什么這樣做以前設計規(guī)范只規(guī)定紅色用在危險場景但機器不知道危險有 10 種。編號把哪種危險說清楚了。3.5 編號不能跨層亂用status.critical紅色脈沖只能在錯誤狀態(tài)里用不能拿到提示信息里用?？鐚邮褂脮粰C器自動阻斷。Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境里的例子合法status.critical 用在消息流中斷系統(tǒng)故障非法status.critical 用在限流提示只是等一等不是故障機器攔截如果 AI 把限流提示做成紅色脈沖CI 直接阻斷代碼合不進去為什么這樣做防止紅色濫用。以前所有錯誤都用紅色用戶分不清多嚴重?，F(xiàn)在每個編號有指定的使用范圍超范圍就報錯。4. 本文的核心命題把語義編碼成離散令牌必須翻譯成可驗證的框架設計。本文回答三個命題命題驗證標準語義可被離散編碼error_severity 的四級后果差異能被編碼為四個互斥枚舉值而非自然語言描述令牌綁定唯一視覺映射每個令牌如 retryable綁定且僅綁定一組視覺參數(shù)status.warning 時鐘圖標 倒計時不可被自由替換令牌可被機器消費同一組令牌能被編譯為 Prompt 前綴、JSON Schema、CI 規(guī)則三種格式在不同工具鏈中執(zhí)行同一語義判定一、調(diào)整前四個角色的真實反饋在沒有語義令牌之前各角色在界面層看到的世界用他們自己的話說?前端與 AI 工程師的真實反饋“致命錯誤和限流提示被渲染成了同一種紅色背景條?！盇I 生成工具里只有 Design Token——color.danger: { value: “#EF4444” }。紅色是一個色值不附帶任何場景含義。同一款 AI 對話產(chǎn)品中對話可能已丟失的致命錯誤與請求太頻繁請等 30 秒的限流提示長得一模一樣色板合規(guī)、對比度達標視覺走查挑不出任何毛病但用戶從界面上讀不到兩者的區(qū)別。?設計師與產(chǎn)品經(jīng)理的真實反饋“同一個 alert三個人三種理解每個人都沒錯?！苯M件庫里的 Alert 只是視覺組件——圓角、圖標位、關閉按鈕。它不知道自己在交易確認場景里是阻斷性語義在信息展示場景里是旁觀性語義。前端理解為彈窗設計師指的是頂部通知條兩個人都對因為沒有任何注冊表裁定。?前端與 AI 工程師的另一條真實反饋“LLM 把 Critical 降級為’嚴重’代碼里查不出來?！痹?LLM 的詞匯表里“Critical和嚴重是近義詞。AI 生成告警時把 “Critical” 替換為嚴重”、把 “Data Loss Risk” 替換為請稍后重試——情緒權重在概率性輸出中被隨機降級而沒有任何機制判定這是違規(guī)。?DesignOps 與設計系統(tǒng)負責人的真實反饋“規(guī)范寫在文檔平臺里人可能看漏AI 工具完全不可見?！卞e誤狀態(tài)分四級供人閱讀機器查詢不了更校驗不了。匯總成一張表工具 / 環(huán)節(jié)界面層呈現(xiàn)狀態(tài)缺失什么AI 生成工具只有色值與樣式語義靠概率猜這個紅代表什么的機器可讀定義組件庫組件只有視覺屬性組件在不同場景下的語義身份文案生成同義詞自由替換關鍵術語的權重錨定規(guī)范文檔供人閱讀機器可查詢、可校驗的注冊表這四條反饋指向同一個根因語義沒有被編碼成機器可讀的東西。紅色只是色值組件只是容器術語只是字符串——機器拿不到語義就只能靠概率猜。二、把語義編碼為離散令牌不是自創(chuàng)概念2003年Eric Evans 在《Domain-Driven Design》中提出 Bounded Context限界上下文——同一個術語在不同業(yè)務邊界內(nèi)有不同含義域內(nèi)唯一定義互不污染。這與我的語義域設計是同一邏輯同一個 Alert 在 transactional 域是阻斷確認在 observational 域是旁觀通知條——域內(nèi)唯一定義域間含義不同。同期Evans 定義了 Anti-Corruption Layer防腐層——邊界之間做翻譯與隔離非法引用被拒絕。這與我的跨層禁止規(guī)則設計對應status.critical 不可用于 observational 域非法綁定在編譯前置校驗時直接阻斷。域邊界靠機器規(guī)則維護。工業(yè)界也在做。Microsoft Azure 將 ACL 作為官方架構模式收錄W3C DTCG 已定義 Semantic Token 層。我的設計在其之上擴展了行為約束與跨域規(guī)則。但行業(yè)也有反面的聲音。許多設計系統(tǒng)的語義令牌只是換名color-red-500 改叫 color-danger沒有場景定義組件分類模型在 AI 生成時代系統(tǒng)性失效 自帶語義導致升級時語義跟著重寫。這恰恰反證了我為什么要設計覆蓋層模型——語義必須外賦于組件空容器由域邊界統(tǒng)一定義可被機器校驗。參考鏈接●Eric Evans · DDD Reference 2015https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf●Microsoft Azure · Anti-Corruption Layer Patternhttps://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer●W3C DTCG · Design Tokens Format Module 2025.10https://www.designtokens.org/TR/2025.10/format/●W3C · Design Tokens Community Grouphttps://www.w3.org/community/design-tokens/三、關鍵設計語義令牌表3.1 四大命名空間碼本原子集語義令牌按回答的問題分為四個命名空間每個令牌是離散索引編譯管線查表后展開為連續(xù)約束status._ —— 這件事有多嚴重令牌含義視覺映射示例status.critical致命系統(tǒng)故障、數(shù)據(jù)丟失紅色脈沖 八邊形警告status.warning警告限流、降級、可恢復錯誤黃色提示 時鐘圖標status.info信息提示、說明、部分可用藍色靜態(tài) 信息圖標status.success成功保存完成、操作成功綠色靜態(tài) 對勾圖標status.neutral中性加載中、等待中灰色動畫 旋轉圖標【Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境status._ 命名空間令牌卡片】對應 HTML 演示環(huán)境位置頁面中status._標簽頁下的五個彩色令牌卡片critical 紅脈沖 / warning 黃時鐘 / info 藍信息 / success 綠對勾 / neutral 灰旋轉每張卡片展示令牌名、含義、視覺映射顏色動畫圖標按鈕樣式。phase._ —— AI 處于什么階段用戶在等什么令牌含義視覺映射示例phase.research檢索搜索信息、查找來源藍色 放大鏡圖標 來源計數(shù)phase.analysis綜合對比多源、識別分歧黃色 大腦圖標 共識度phase.check驗證核對鏈接、驗證事實綠色 盾牌圖標 驗證狀態(tài)phase.output生成生成答案、輸出結果紫色 文檔圖標 引用索引boundary._ —— 系統(tǒng)拒絕用戶時權利邊界在哪里令牌含義視覺映射示例boundary.soft軟性拒絕拒絕請求但保留會話黃色提示條 保留輸入框boundary.hard強制終止終止會話清空上下文紅色退出面板 數(shù)據(jù)政策說明boundary.review升級審核提交人工審核藍色提示 預計審核時間action._ —— 用戶點擊后后果是什么令牌含義視覺映射示例action.destructive破壞性刪除、清空、不可逆紅色空心 二次確認 輸入驗證action.constructive建設性保存、提交、創(chuàng)建藍色實心 成功反饋action.neutral中性取消、關閉、返回灰色描邊 無后果3.2 字典注冊的 6 個語義綁定v1.0.0語義字典v1.0.0 注冊的 6 個語義綁定構成組織級語義碼本的最小可行原子集語義綁定含義核心約束注入跨層禁止示例status.critical阻斷性、可能不可恢復紅色脈沖、八邊形圖標必須二次確認文案必須說明后果不可用于 observational 域限流提示禁用致命紅status.warning需注意、可恢復黃色靜態(tài)、三角圖標必須顯示恢復時間必須提供操作步驟—status.info中性信息告知藍色靜態(tài)、信息圖標可自動消失禁止附加操作說明—status.success操作成功確認綠色靜態(tài)、對勾圖標可自動消失禁止附加操作說明—action.destructive不可逆操作紅色空心描邊、危險圖標必須二次確認必須說明不可恢復禁止使用普通主按鈕樣式action.primary場景主行動品牌色實心、箭頭圖標點擊后跳轉顯示下一步預覽—3.3 令牌如何展開為連續(xù)約束每個令牌在契約中展開為一組連續(xù)約束。以 status.critical 應用于致命錯誤ERR-001 · fatal 級別為例一個離散索引status.critical→ 展開為視覺方向紅色脈沖 八邊形圖標 行為約束恢復路徑、二次確認 文案約束必須說明后果 機器防線跨層禁止block。這就是碼本解碼的完整形態(tài)。碼本解碼演示status.critical → 展開為連續(xù)約束【演示環(huán)境碼本解碼演示區(qū)塊】頁面中碼本解碼演示區(qū)塊包含離散索引status.critical、視覺方向紅色脈沖 八邊形圖標、行為約束必須二次確認 恢復路徑、文案約束必須說明后果、機器防線·跨層禁止observational/navigational/conversational 域下非法五欄展開。同一令牌編譯為三種消費格式【演示環(huán)境三種消費格式并排】頁面中同一令牌編譯為三種消費格式區(qū)塊三欄并排展示 Prompt 前綴 / JSON Schema / CI 規(guī)則。Prompt 前綴在生成致命錯誤界面時 - 必須使用紅色脈沖視覺 - 必須包含八邊形警告圖標 - 必須提供恢復路徑按鈕 - 文案必須說明后果嚴重性 - 禁止在 observational 域使用JSON Schema{color_token:status.critical,motion_token:pulse.red.urgent,icon_token:alert.octagon,required_actions:[refresh,export],forbidden_domains:[observational]}CI 規(guī)則rules:critical-token-usage:token:status.criticalforbidden_in:[observational]required_visual:pulse.red.urgentviolation:block3.4 對比演示同一個紅色在不同令牌下的不同含義【演示環(huán)境同一個紅色對比卡片】頁面中對比演示同一個紅色在不同令牌下的不同含義區(qū)塊左右兩張卡片對比展示 status.critical系統(tǒng)故障與 action.destructive刪除賬戶。status.criticalaction.destructive都是紅色系統(tǒng)故障對話上下文可能丟失不可逆操作數(shù)據(jù)將永久刪除覆蓋層transactionaltransactional行為必須二次確認 恢復路徑必須二次確認 輸入驗證樣式紅色脈沖 八邊形紅色空心描邊非實心跨層observational 域非法—沒有令牌時機器只看到 #EF4444有令牌時機器知道這是 status.critical 還是 action.destructive?！狙菔经h(huán)境跨層禁止演示CI 阻斷日志】頁面中跨層禁止區(qū)塊展示 CI 阻斷日志“[CI 阻斷] error-severity-cross-layer / Token: status.critical / Used in: observational domain / Expected: status.warning / Action: BLOCK”。3.5 五條思路的依賴關系第1條把意思變成編號離散編碼 ↓ 第2條編號鎖死一套視覺一對一映射 ↓ 第4條不同編號可以同顏色但不同意思區(qū)分場景 ↓ 第5條編號不能跨層亂用使用范圍限制 ↓ 第3條編號自動翻譯成三種格式一次定義多方消費四、架構層概念設計背景碼本而非術語表。術語表供人查閱碼本供機器解碼每個令牌是離散索引編譯管線查表后展開為連續(xù)約束視覺方向 行為約束 文案語氣。這決定了令牌的讀者不只是設計師更是編譯管線與 AI 工具。令牌層與呈現(xiàn)層分離。color_token 是語義標識color 是實際色值同一個 status.critical 在不同設計系統(tǒng)里可映射到不同色值Tailwind #EF4444 / Ant Design #F5222D / DevUI #FF4D4F。語義令牌不關心具體色值只關心語義映射關系——設計系統(tǒng)更新時改映射表契約不變。語義覆蓋層Semantic Overlay。組件庫是底層Underlay只負責渲染——它提供圓角、色值、圖標位這些空容器語義覆蓋層在組件之上加蓋業(yè)務語義把空容器翻譯為業(yè)務語義組件。令牌是覆蓋層加蓋語義時使用的印泥。術語雙軌。面向不同讀者群時三層結構有兩套叫法語義域 ≈ 覆蓋層目錄語義令牌 ≈ 語義重綁定場景映射 ≈ 約束注入。兩套術語指向同一份注冊表。五、這些坑怎么被解掉場景與角色對照回到開頭那些真實反饋看令牌就位后它們各自怎么閉環(huán)。踩過的坑 1“這個紅到底代表什么走查時誰也說不清”● 癥狀AI 生成限流提示時Before 形態(tài)下選 color-danger 無可指責——紅色本身沒錯視覺走查也合規(guī)但用戶看到紅色以為賬戶出了問題實際只是需要等 30 秒。合規(guī)但錯誤。● 根因Token 只定義顏色沒定義場景語義機器拿不到限流 ≠ 致命這條信息?！?關聯(lián)機制①語義令牌與字典《Token 層差異》● 解法路徑有了令牌后限流語義級別是 retryable黃色時鐘 倒計時AI 若選 status.critical直接違反跨層規(guī)則CI 阻斷PR 無法合入。錯誤在生成階段就無法成立。● 驗證方式前端與 AI 工程師的驗收爭議從感覺不對變成違反了哪條綁定——爭議可引用、可定位、可裁決。踩過的坑 2“LLM 把 Critical 降級為’嚴重’代碼里查不出來”● 癥狀AI 生成告警時把 “Critical” 替換為嚴重、把 “Data Loss Risk” 替換為請稍后重試——情緒權重被概率性輸出隨機降級Schema 校驗通過語義卻是錯的。● 根因文案層沒有術語錨定同義詞自由替換沒有任何機制判定違規(guī)?！?關聯(lián)機制①語義令牌與字典B3 字典 synonym_firewall 同義詞防火墻 6 個漂移模式證據(jù)庫ALR-001● 解法路徑YAML 定義禁止詞并編譯進 Prompt 前綴synonym_firewall 約束下關鍵術語替換即違規(guī)生成階段被校驗規(guī)則命中?！?驗證方式設計師與產(chǎn)品經(jīng)理精心設計的語義權重不再被概率性輸出隨機抹平——“Critical” 在所有產(chǎn)出中保持錨定替換即被校驗規(guī)則命中。六、調(diào)整后工具界面層的呈現(xiàn)狀態(tài)同一批工具在語義令牌就位之后工具 / 環(huán)節(jié)調(diào)整前調(diào)整后AI 生成工具只有色值限流與致命錯誤同紅Prompt 前綴注入令牌約束后致命錯誤 紅色脈沖 八邊形圖標 恢復路徑限流提示 黃色時鐘 倒計時.同模型同任務產(chǎn)出語義分級文案生成“Critical” 被隨機替換為嚴重synonym_firewall 錨定關鍵術語替換即被校驗規(guī)則命中驗收環(huán)節(jié)走查結論停留在感覺不對Checklist 逐項核對語義分級 / 文案 / 紅線違反紅線即阻斷結論注明契約版本號【推演條件】從演示環(huán)境進入生產(chǎn)環(huán)境語義令牌表需要以下組織條件誰來維護令牌建議由語義翻譯設計師角色 4擔任令牌管理員負責定義和更新語義令牌DesignOps角色 3負責版本發(fā)布與廣播。令牌不是公共文檔而是組織的語義憲法修改權限必須集中。變更如何不擊穿下游令牌升級如新增 status.degraded 級別必須自動同步到所有消費面設計師的 Checklist、前端的 Prompt 前綴、CI 的攔截規(guī)則。組織需要建立字典變更 → 契約重編譯 → 消費格式換版 → 角色通知的閉環(huán)避免上游改了下游還在用舊定義。誰來證明有效每次令牌升級后需通過語義分級器抽檢一定數(shù)量的 AI 生成文案驗證新規(guī)則確實攔截了目標錯誤。驗證結果應沉淀到模式卡片中作為該模式置信度持續(xù)遞增的證據(jù)。邊界聲明語義令牌表不解決視覺值的一致性那是 Design Token 層的職責不定義具體場景的約束實例那是YAML 契約的職責也約束不了有沒有人查它消費紀律在角色側見角色專題 ①設計師與產(chǎn)品經(jīng)理。當前量化收益均為數(shù)據(jù)模型推演待生產(chǎn)數(shù)據(jù)驗證。一句話總結給不同角色給設計師“你以前寫’錯誤用紅色’前端可能理解錯?，F(xiàn)在你寫 status.critical機器查表就知道必須是紅色脈沖 八邊形 二次確認不會跑偏。”給前端“你不需要猜設計師的意思查 status.critical 的表就知道顏色、動畫、圖標、按鈕樣式全部鎖死?！苯o AI 工具開發(fā)者“你不需要自己判斷用什么顏色輸入場景編號查表輸出 Prompt 前綴AI 按規(guī)矩生成?！苯o DesignOps“你改一次編號定義Prompt 前綴、JSON Schema、CI 規(guī)則三處自動更新不用發(fā)三遍文檔?！? ① 語義令牌表：把語義概念編碼成離散枚舉
框架設計背景本文是 Schema-As-Code 證據(jù)鏈 的框架設計站屬于主題行的第一個關鍵設計——語義令牌表Semantic Token Table。在前序章節(jié)中階段一 Guard 結構化診斷通過組件語義快照與三層判定模型發(fā)現(xiàn)了6 個漂移模式語義域建立了組件是空容器語義由場景定義的覆蓋層模型。但語義要能被機器識別、校驗與生成必須先解決一個編碼問題如何把語義概念變成機器可運算的離散值本文要建立的正是 Schema-As-Code 的語義編碼層——當語義規(guī)范體系需要被寫入YAML 契約時語義必須以離散令牌的形式存在而非自然語言描述。1. 問題語義是感覺還是可運算的值行業(yè)現(xiàn)狀中語義以自然語言或視覺樣式存在設計師說這個要用紅色前端看到 #EF4444AI 生成工具看到 color: red。但紅色在不同場景下含義完全不同——在語義域的 transactional 域它是阻斷確認在 observational 域它可能是非法綁定跨層禁止。當語義以顏色值、文案詞或感覺的形式流動時機器無法區(qū)分同一個紅色在不同場景下是否合法。6 個漂移模式中的 ERR-001錯誤狀態(tài)后果差異未分級根因正是如此致命錯誤、網(wǎng)絡抖動、限流、降級四種完全不同的后果共用同一種紅色——因為機器看到的只是 color: #EF4444而不是 error_severity.fatal 與 error_severity.retryable 的語義區(qū)別。沒有離散令牌就沒有機器可執(zhí)行的判定依據(jù)。2. 為什么自然語言守不住語義不可運算設計規(guī)范文檔用自然語言描述語義“致命錯誤用紅色脈沖限流用黃色時鐘”。但自然語言對機器是不可運算的●AI 生成工具讀不懂致命錯誤與限流的區(qū)別它的訓練語料里只有 red 和 yellow●前端工程師看到的是 Design Token color-danger 和 color-warning但 danger 與 warning 的語義邊界沒有機器定義AI 可以把 color-danger 用在成功狀態(tài)●驗收走查依賴人的主觀判斷感覺不對無法轉化為可復現(xiàn)的校驗規(guī)則。組件語義快照的 6 字段記錄法已經(jīng)證明觀察界面時需要記錄 component_type、visual、copy、interaction、context 等維度。但這些字段的值如果是自由文本如 color: “red”仍然不可運算。語義令牌表的作用就是把紅色編碼為 status.critical把限流編碼為 error_severity.retryable——讓語義成為機器可查詢、可校驗、可攔截的離散值。3. 設計思路把語義概念編碼成離散枚舉本文的設計思路是三個遞進命題●語義概念 → 離散令牌error_severity 不是文檔里的段落而是包含 fatal、transient、retryable、degraded 四個枚舉值的令牌表每個枚舉值綁定唯一的視覺映射status.critical → 紅色脈沖與行動約束必須提供恢復路徑●令牌 → 字典注冊所有語義令牌在語義字典中注冊成為組織級唯一信源。契約YAML不定義令牌只引用令牌●令牌 → 可執(zhí)行規(guī)則編譯管線將令牌表編譯為 Prompt 前綴注入 AI 上下文、JSON Schema組件 Props 校驗、CI 規(guī)則流水線攔截——同一組離散值在不同工具鏈中以不同格式執(zhí)行同一語義。這與語義規(guī)范體系的關系語義規(guī)范體系定義有哪些語義維度語義令牌表定義每個維度下有哪些離散值。沒有令牌表規(guī)范體系只是分類框架沒有規(guī)范體系令牌表只是孤立枚舉。3.1 把意思變成編號機器看不懂紅色代表很危險機器看得懂 status.critical。把連續(xù)的自然語言描述變成離散的編號枚舉值。Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境里的例子不說紅色、很緊急、要刷新 → 說 status.critical不說黃色、等一等、能恢復 → 說 status.warning不說灰色、加載中、不用管 → 說 status.neutral為什么這樣做自然語言有同義詞“嚴重≈Critical≈危急”機器會搞混。編號沒有同義詞一個編號只對應一個意思。3.2 一個編號只綁定一套視覺status.critical 只能是紅色脈沖 八邊形圖標不能今天是紅色明天變成橙色。編號和視覺參數(shù)是鎖死的一對一映射。Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境里的例子編號顏色動畫圖標按鈕樣式status.critical紅色脈沖八邊形必須二次確認status.warning黃色靜態(tài)三角顯示恢復時間status.info藍色靜態(tài)信息可自動消失status.neutral灰色旋轉加載無為什么這樣做以前設計規(guī)范寫錯誤用紅色但不同前端可能用不同紅。編號鎖死后機器查表就知道唯一答案。3.3 同一個編號能翻譯成三種格式設計師寫了一份 status.critical 的定義機器自動把它變成三種東西給三種不同的人用。Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境里的三種格式給誰用格式內(nèi)容給 AI 寫界面的工程師Prompt 前綴“生成致命錯誤時必須用紅色脈沖…”給校驗代碼的機器JSON Schema{“color_token”: “status.critical”, “motion_token”: “pulse.red.urgent”}給 CI 流水線阻斷規(guī)則“如果在 observational 域用 critical阻斷合并”為什么這樣做設計師只寫一次三種消費方自動拿到自己需要的東西。不用設計師給工程師寫一遍、給運維寫一遍、給測試寫一遍。3.4 同一個顏色不同編號代表不同意思機器看到 #EF4444紅色不知道這是系統(tǒng)故障還是刪除按鈕。必須看編號才知道。Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境里的對比編號都是紅色但意思完全不同場景status.critical紅色系統(tǒng)故障對話可能丟了錯誤狀態(tài)action.destructive紅色刪除賬戶數(shù)據(jù)永久沒了操作按鈕為什么這樣做以前設計規(guī)范只規(guī)定紅色用在危險場景但機器不知道危險有 10 種。編號把哪種危險說清楚了。3.5 編號不能跨層亂用status.critical紅色脈沖只能在錯誤狀態(tài)里用不能拿到提示信息里用?？鐚邮褂脮粰C器自動阻斷。Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境里的例子合法status.critical 用在消息流中斷系統(tǒng)故障非法status.critical 用在限流提示只是等一等不是故障機器攔截如果 AI 把限流提示做成紅色脈沖CI 直接阻斷代碼合不進去為什么這樣做防止紅色濫用。以前所有錯誤都用紅色用戶分不清多嚴重?，F(xiàn)在每個編號有指定的使用范圍超范圍就報錯。4. 本文的核心命題把語義編碼成離散令牌必須翻譯成可驗證的框架設計。本文回答三個命題命題驗證標準語義可被離散編碼error_severity 的四級后果差異能被編碼為四個互斥枚舉值而非自然語言描述令牌綁定唯一視覺映射每個令牌如 retryable綁定且僅綁定一組視覺參數(shù)status.warning 時鐘圖標 倒計時不可被自由替換令牌可被機器消費同一組令牌能被編譯為 Prompt 前綴、JSON Schema、CI 規(guī)則三種格式在不同工具鏈中執(zhí)行同一語義判定一、調(diào)整前四個角色的真實反饋在沒有語義令牌之前各角色在界面層看到的世界用他們自己的話說?前端與 AI 工程師的真實反饋“致命錯誤和限流提示被渲染成了同一種紅色背景條?！盇I 生成工具里只有 Design Token——color.danger: { value: “#EF4444” }。紅色是一個色值不附帶任何場景含義。同一款 AI 對話產(chǎn)品中對話可能已丟失的致命錯誤與請求太頻繁請等 30 秒的限流提示長得一模一樣色板合規(guī)、對比度達標視覺走查挑不出任何毛病但用戶從界面上讀不到兩者的區(qū)別。?設計師與產(chǎn)品經(jīng)理的真實反饋“同一個 alert三個人三種理解每個人都沒錯?！苯M件庫里的 Alert 只是視覺組件——圓角、圖標位、關閉按鈕。它不知道自己在交易確認場景里是阻斷性語義在信息展示場景里是旁觀性語義。前端理解為彈窗設計師指的是頂部通知條兩個人都對因為沒有任何注冊表裁定。?前端與 AI 工程師的另一條真實反饋“LLM 把 Critical 降級為’嚴重’代碼里查不出來?！痹?LLM 的詞匯表里“Critical和嚴重是近義詞。AI 生成告警時把 “Critical” 替換為嚴重”、把 “Data Loss Risk” 替換為請稍后重試——情緒權重在概率性輸出中被隨機降級而沒有任何機制判定這是違規(guī)。?DesignOps 與設計系統(tǒng)負責人的真實反饋“規(guī)范寫在文檔平臺里人可能看漏AI 工具完全不可見?！卞e誤狀態(tài)分四級供人閱讀機器查詢不了更校驗不了。匯總成一張表工具 / 環(huán)節(jié)界面層呈現(xiàn)狀態(tài)缺失什么AI 生成工具只有色值與樣式語義靠概率猜這個紅代表什么的機器可讀定義組件庫組件只有視覺屬性組件在不同場景下的語義身份文案生成同義詞自由替換關鍵術語的權重錨定規(guī)范文檔供人閱讀機器可查詢、可校驗的注冊表這四條反饋指向同一個根因語義沒有被編碼成機器可讀的東西。紅色只是色值組件只是容器術語只是字符串——機器拿不到語義就只能靠概率猜。二、把語義編碼為離散令牌不是自創(chuàng)概念2003年Eric Evans 在《Domain-Driven Design》中提出 Bounded Context限界上下文——同一個術語在不同業(yè)務邊界內(nèi)有不同含義域內(nèi)唯一定義互不污染。這與我的語義域設計是同一邏輯同一個 Alert 在 transactional 域是阻斷確認在 observational 域是旁觀通知條——域內(nèi)唯一定義域間含義不同。同期Evans 定義了 Anti-Corruption Layer防腐層——邊界之間做翻譯與隔離非法引用被拒絕。這與我的跨層禁止規(guī)則設計對應status.critical 不可用于 observational 域非法綁定在編譯前置校驗時直接阻斷。域邊界靠機器規(guī)則維護。工業(yè)界也在做。Microsoft Azure 將 ACL 作為官方架構模式收錄W3C DTCG 已定義 Semantic Token 層。我的設計在其之上擴展了行為約束與跨域規(guī)則。但行業(yè)也有反面的聲音。許多設計系統(tǒng)的語義令牌只是換名color-red-500 改叫 color-danger沒有場景定義組件分類模型在 AI 生成時代系統(tǒng)性失效 自帶語義導致升級時語義跟著重寫。這恰恰反證了我為什么要設計覆蓋層模型——語義必須外賦于組件空容器由域邊界統(tǒng)一定義可被機器校驗。參考鏈接●Eric Evans · DDD Reference 2015https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf●Microsoft Azure · Anti-Corruption Layer Patternhttps://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer●W3C DTCG · Design Tokens Format Module 2025.10https://www.designtokens.org/TR/2025.10/format/●W3C · Design Tokens Community Grouphttps://www.w3.org/community/design-tokens/三、關鍵設計語義令牌表3.1 四大命名空間碼本原子集語義令牌按回答的問題分為四個命名空間每個令牌是離散索引編譯管線查表后展開為連續(xù)約束status._ —— 這件事有多嚴重令牌含義視覺映射示例status.critical致命系統(tǒng)故障、數(shù)據(jù)丟失紅色脈沖 八邊形警告status.warning警告限流、降級、可恢復錯誤黃色提示 時鐘圖標status.info信息提示、說明、部分可用藍色靜態(tài) 信息圖標status.success成功保存完成、操作成功綠色靜態(tài) 對勾圖標status.neutral中性加載中、等待中灰色動畫 旋轉圖標【Schema-As-Code 語義編碼層 · ① 語義令牌表演示環(huán)境status._ 命名空間令牌卡片】對應 HTML 演示環(huán)境位置頁面中status._標簽頁下的五個彩色令牌卡片critical 紅脈沖 / warning 黃時鐘 / info 藍信息 / success 綠對勾 / neutral 灰旋轉每張卡片展示令牌名、含義、視覺映射顏色動畫圖標按鈕樣式。phase._ —— AI 處于什么階段用戶在等什么令牌含義視覺映射示例phase.research檢索搜索信息、查找來源藍色 放大鏡圖標 來源計數(shù)phase.analysis綜合對比多源、識別分歧黃色 大腦圖標 共識度phase.check驗證核對鏈接、驗證事實綠色 盾牌圖標 驗證狀態(tài)phase.output生成生成答案、輸出結果紫色 文檔圖標 引用索引boundary._ —— 系統(tǒng)拒絕用戶時權利邊界在哪里令牌含義視覺映射示例boundary.soft軟性拒絕拒絕請求但保留會話黃色提示條 保留輸入框boundary.hard強制終止終止會話清空上下文紅色退出面板 數(shù)據(jù)政策說明boundary.review升級審核提交人工審核藍色提示 預計審核時間action._ —— 用戶點擊后后果是什么令牌含義視覺映射示例action.destructive破壞性刪除、清空、不可逆紅色空心 二次確認 輸入驗證action.constructive建設性保存、提交、創(chuàng)建藍色實心 成功反饋action.neutral中性取消、關閉、返回灰色描邊 無后果3.2 字典注冊的 6 個語義綁定v1.0.0語義字典v1.0.0 注冊的 6 個語義綁定構成組織級語義碼本的最小可行原子集語義綁定含義核心約束注入跨層禁止示例status.critical阻斷性、可能不可恢復紅色脈沖、八邊形圖標必須二次確認文案必須說明后果不可用于 observational 域限流提示禁用致命紅status.warning需注意、可恢復黃色靜態(tài)、三角圖標必須顯示恢復時間必須提供操作步驟—status.info中性信息告知藍色靜態(tài)、信息圖標可自動消失禁止附加操作說明—status.success操作成功確認綠色靜態(tài)、對勾圖標可自動消失禁止附加操作說明—action.destructive不可逆操作紅色空心描邊、危險圖標必須二次確認必須說明不可恢復禁止使用普通主按鈕樣式action.primary場景主行動品牌色實心、箭頭圖標點擊后跳轉顯示下一步預覽—3.3 令牌如何展開為連續(xù)約束每個令牌在契約中展開為一組連續(xù)約束。以 status.critical 應用于致命錯誤ERR-001 · fatal 級別為例一個離散索引status.critical→ 展開為視覺方向紅色脈沖 八邊形圖標 行為約束恢復路徑、二次確認 文案約束必須說明后果 機器防線跨層禁止block。這就是碼本解碼的完整形態(tài)。碼本解碼演示status.critical → 展開為連續(xù)約束【演示環(huán)境碼本解碼演示區(qū)塊】頁面中碼本解碼演示區(qū)塊包含離散索引status.critical、視覺方向紅色脈沖 八邊形圖標、行為約束必須二次確認 恢復路徑、文案約束必須說明后果、機器防線·跨層禁止observational/navigational/conversational 域下非法五欄展開。同一令牌編譯為三種消費格式【演示環(huán)境三種消費格式并排】頁面中同一令牌編譯為三種消費格式區(qū)塊三欄并排展示 Prompt 前綴 / JSON Schema / CI 規(guī)則。Prompt 前綴在生成致命錯誤界面時 - 必須使用紅色脈沖視覺 - 必須包含八邊形警告圖標 - 必須提供恢復路徑按鈕 - 文案必須說明后果嚴重性 - 禁止在 observational 域使用JSON Schema{color_token:status.critical,motion_token:pulse.red.urgent,icon_token:alert.octagon,required_actions:[refresh,export],forbidden_domains:[observational]}CI 規(guī)則rules:critical-token-usage:token:status.criticalforbidden_in:[observational]required_visual:pulse.red.urgentviolation:block3.4 對比演示同一個紅色在不同令牌下的不同含義【演示環(huán)境同一個紅色對比卡片】頁面中對比演示同一個紅色在不同令牌下的不同含義區(qū)塊左右兩張卡片對比展示 status.critical系統(tǒng)故障與 action.destructive刪除賬戶。status.criticalaction.destructive都是紅色系統(tǒng)故障對話上下文可能丟失不可逆操作數(shù)據(jù)將永久刪除覆蓋層transactionaltransactional行為必須二次確認 恢復路徑必須二次確認 輸入驗證樣式紅色脈沖 八邊形紅色空心描邊非實心跨層observational 域非法—沒有令牌時機器只看到 #EF4444有令牌時機器知道這是 status.critical 還是 action.destructive?！狙菔经h(huán)境跨層禁止演示CI 阻斷日志】頁面中跨層禁止區(qū)塊展示 CI 阻斷日志“[CI 阻斷] error-severity-cross-layer / Token: status.critical / Used in: observational domain / Expected: status.warning / Action: BLOCK”。3.5 五條思路的依賴關系第1條把意思變成編號離散編碼 ↓ 第2條編號鎖死一套視覺一對一映射 ↓ 第4條不同編號可以同顏色但不同意思區(qū)分場景 ↓ 第5條編號不能跨層亂用使用范圍限制 ↓ 第3條編號自動翻譯成三種格式一次定義多方消費四、架構層概念設計背景碼本而非術語表。術語表供人查閱碼本供機器解碼每個令牌是離散索引編譯管線查表后展開為連續(xù)約束視覺方向 行為約束 文案語氣。這決定了令牌的讀者不只是設計師更是編譯管線與 AI 工具。令牌層與呈現(xiàn)層分離。color_token 是語義標識color 是實際色值同一個 status.critical 在不同設計系統(tǒng)里可映射到不同色值Tailwind #EF4444 / Ant Design #F5222D / DevUI #FF4D4F。語義令牌不關心具體色值只關心語義映射關系——設計系統(tǒng)更新時改映射表契約不變。語義覆蓋層Semantic Overlay。組件庫是底層Underlay只負責渲染——它提供圓角、色值、圖標位這些空容器語義覆蓋層在組件之上加蓋業(yè)務語義把空容器翻譯為業(yè)務語義組件。令牌是覆蓋層加蓋語義時使用的印泥。術語雙軌。面向不同讀者群時三層結構有兩套叫法語義域 ≈ 覆蓋層目錄語義令牌 ≈ 語義重綁定場景映射 ≈ 約束注入。兩套術語指向同一份注冊表。五、這些坑怎么被解掉場景與角色對照回到開頭那些真實反饋看令牌就位后它們各自怎么閉環(huán)。踩過的坑 1“這個紅到底代表什么走查時誰也說不清”● 癥狀AI 生成限流提示時Before 形態(tài)下選 color-danger 無可指責——紅色本身沒錯視覺走查也合規(guī)但用戶看到紅色以為賬戶出了問題實際只是需要等 30 秒。合規(guī)但錯誤。● 根因Token 只定義顏色沒定義場景語義機器拿不到限流 ≠ 致命這條信息?！?關聯(lián)機制①語義令牌與字典《Token 層差異》● 解法路徑有了令牌后限流語義級別是 retryable黃色時鐘 倒計時AI 若選 status.critical直接違反跨層規(guī)則CI 阻斷PR 無法合入。錯誤在生成階段就無法成立。● 驗證方式前端與 AI 工程師的驗收爭議從感覺不對變成違反了哪條綁定——爭議可引用、可定位、可裁決。踩過的坑 2“LLM 把 Critical 降級為’嚴重’代碼里查不出來”● 癥狀AI 生成告警時把 “Critical” 替換為嚴重、把 “Data Loss Risk” 替換為請稍后重試——情緒權重被概率性輸出隨機降級Schema 校驗通過語義卻是錯的。● 根因文案層沒有術語錨定同義詞自由替換沒有任何機制判定違規(guī)?！?關聯(lián)機制①語義令牌與字典B3 字典 synonym_firewall 同義詞防火墻 6 個漂移模式證據(jù)庫ALR-001● 解法路徑YAML 定義禁止詞并編譯進 Prompt 前綴synonym_firewall 約束下關鍵術語替換即違規(guī)生成階段被校驗規(guī)則命中?！?驗證方式設計師與產(chǎn)品經(jīng)理精心設計的語義權重不再被概率性輸出隨機抹平——“Critical” 在所有產(chǎn)出中保持錨定替換即被校驗規(guī)則命中。六、調(diào)整后工具界面層的呈現(xiàn)狀態(tài)同一批工具在語義令牌就位之后工具 / 環(huán)節(jié)調(diào)整前調(diào)整后AI 生成工具只有色值限流與致命錯誤同紅Prompt 前綴注入令牌約束后致命錯誤 紅色脈沖 八邊形圖標 恢復路徑限流提示 黃色時鐘 倒計時.同模型同任務產(chǎn)出語義分級文案生成“Critical” 被隨機替換為嚴重synonym_firewall 錨定關鍵術語替換即被校驗規(guī)則命中驗收環(huán)節(jié)走查結論停留在感覺不對Checklist 逐項核對語義分級 / 文案 / 紅線違反紅線即阻斷結論注明契約版本號【推演條件】從演示環(huán)境進入生產(chǎn)環(huán)境語義令牌表需要以下組織條件誰來維護令牌建議由語義翻譯設計師角色 4擔任令牌管理員負責定義和更新語義令牌DesignOps角色 3負責版本發(fā)布與廣播。令牌不是公共文檔而是組織的語義憲法修改權限必須集中。變更如何不擊穿下游令牌升級如新增 status.degraded 級別必須自動同步到所有消費面設計師的 Checklist、前端的 Prompt 前綴、CI 的攔截規(guī)則。組織需要建立字典變更 → 契約重編譯 → 消費格式換版 → 角色通知的閉環(huán)避免上游改了下游還在用舊定義。誰來證明有效每次令牌升級后需通過語義分級器抽檢一定數(shù)量的 AI 生成文案驗證新規(guī)則確實攔截了目標錯誤。驗證結果應沉淀到模式卡片中作為該模式置信度持續(xù)遞增的證據(jù)。邊界聲明語義令牌表不解決視覺值的一致性那是 Design Token 層的職責不定義具體場景的約束實例那是YAML 契約的職責也約束不了有沒有人查它消費紀律在角色側見角色專題 ①設計師與產(chǎn)品經(jīng)理。當前量化收益均為數(shù)據(jù)模型推演待生產(chǎn)數(shù)據(jù)驗證。一句話總結給不同角色給設計師“你以前寫’錯誤用紅色’前端可能理解錯?，F(xiàn)在你寫 status.critical機器查表就知道必須是紅色脈沖 八邊形 二次確認不會跑偏。”給前端“你不需要猜設計師的意思查 status.critical 的表就知道顏色、動畫、圖標、按鈕樣式全部鎖死?！苯o AI 工具開發(fā)者“你不需要自己判斷用什么顏色輸入場景編號查表輸出 Prompt 前綴AI 按規(guī)矩生成?！苯o DesignOps“你改一次編號定義Prompt 前綴、JSON Schema、CI 規(guī)則三處自動更新不用發(fā)三遍文檔?！?