title: "智能驗證缺口：從形式可接受性到語義等價、意圖保真與 AI 中介形式驗證" subtitle: "意圖語言時代的人機驗證重構" author: "Neo.K / EVEMISSLAB" date: "2026-07-14" version: "v1.0" status: "理論草稿／方法論論文" language: "zh-TW"

智能驗證缺口：從形式可接受性到語義等價、意圖保真與 AI 中介形式驗證

摘要

現代數位系統雖已廣泛引入大型語言模型、AI Agent、自然語言介面與自動化工作流，但其底層驗證機制仍大量沿用前 AI 時代的形式驗證邏輯：輸入若不符合指定字串、型別、欄位、格式、schema、語法、路徑或參數，即被判定為無效、未同意、未授權或任務失敗。此類機制在機器內部可能保持一致，卻常在人類使用層產生一種高度荒謬的現象：使用者的意思已經成立，任務目標也已足夠清楚，但機器仍因表示形式不完全相符而宣告「不是」。

本文將此現象稱為「智能驗證缺口」：系統具備或接入了智能理解能力，卻仍以非智能的形式成員資格判定作為唯一真值入口。本文區分形式可接受性、語義成立性、任務充分性、授權有效性與後果安全性，指出它們彼此相關但不可互相取代。本文提出「語義性假陰性」概念，用以描述某一輸入在形式驗證器中被拒絕，但在具體上下文與任務目標下其語義已充分成立的情況；並進一步提出「AI 中介形式驗證」架構，使 AI 負責語義理解、上下文補全、等價判定、無損正規化與修復候選生成，形式驗證器則保留型別、不變量、權限、安全與可執行性檢查。

本文並提出智能語義驗證層、意圖保真條件、語義修復證書、風險分層驗證、後果敏感式消歧與六態驗證結果，主張未來人機系統不應再將「不符合唯一指定表示」直接等同於「沒有意義」「沒有同意」或「沒有意圖」。意圖語言時代的真正進步，不是取消形式化，而是將形式化從使用者負擔轉化為智能系統內部的責任，使人類主要操作意義、目的與限制，而讓 AI 與形式驗證器共同完成語義—形式之間的保真轉換。

關鍵詞： 智能驗證、形式驗證、語義等價、語義性假陰性、意圖保真、AI Agent、意圖語言、AI 中介形式驗證、自然語言計算、權限確認

一、問題的提出

1.1 「明明就是，但機器卻說不是」

人類與現代數位系統互動時，經常遭遇一類看似微小、實際上極具結構性的失敗：

使用者輸入了正確日期，但格式不是系統要求的唯一格式；
使用者已明確表示同意，但沒有使用系統規定的關鍵字；
使用者要求修改目前專案中的某個檔案，系統卻要求完整絕對路徑；
使用者提供的名稱、地址、檔案或識別資訊已可唯一定位，系統仍以欄位不完整為由拒絕；
某段內容在語義上等價，但因大小寫、空格、標點、命名風格或資料型別不同而被判定失敗；
Agent 已能理解任務，但外圍驗證器仍將非標準表達視為無效輸入；
使用者在上下文中已完成授權，系統卻因缺乏單一形式化確認句而判定「未同意」。

對傳統機器而言，這些結果可能完全符合規格。對使用者而言，它們卻是典型的「白痴事件」：

事情在意義上已經成立，但機器只因表示方式不同，就拒絕承認它成立。

這類事件並非單純的使用者體驗問題，而是一個關於驗證本體、語義層級與智能系統架構的基礎問題。

1.2 現代智能介面與傳統驗證核心的錯位

當前許多系統形成以下混合結構：

上層：
自然語言、AI 助手、Agent、語義理解、上下文推理

下層：
固定欄位、精確字串、傳統 parser、schema、布林驗證器

上層系統可以理解：

「明天下午」；
「那個原本的資料夾」；
「幫我照前面的方式繼續」；
「可以，直接做」；
「這些其實是同一個東西」。

但下層系統只接受：

2026-07-15T15:00:00+08:00
/path/to/exact/folder
CONFIRM_ACTION=true
resource_id=...

於是產生一種結構性矛盾：

\text{系統具有語義理解能力}

但同時：

\text{系統不允許語義理解影響驗證結果}

本文將此矛盾稱為：

智能驗證缺口

其核心定義為：

一個系統具備、接入或可取得語義理解能力，但其有效性判定仍主要依賴非智能的形式成員資格檢查，因而無法辨識語義已成立但形式未完全對齊的輸入。

二、形式驗證究竟驗證了什麼

2.1 形式語言中的接受與拒絕

傳統驗證器可抽象為：

V_F:X\rightarrow\{0,1\}

其中：

V_F(x)=1

表示輸入 $x$ 屬於系統允許的形式集合 $L_F$ ：

x\in L_F

反之：

V_F(x)=0 \iff x\notin L_F

這個結論本身通常沒有錯。

問題在於，系統往往將：

x\notin L_F

錯誤地擴張為：

\operatorname{Meaningless}(x)

或：

\operatorname{NoIntent}(x)

甚至：

\operatorname{NoConsent}(x)

然而，形式驗證器真正能證明的通常只有：

這個表示不屬於目前定義的形式接受集合。

它不能由此推出：

使用者沒有意思；
使用者沒有完成表達；
使用者沒有授權；
事情在實際任務中不能成立；
沒有其他等價表示可以通過驗證。

因此：

V_F(x)=0 \not\Rightarrow \operatorname{InvalidMeaning}(x)

這是本文最基本的邏輯起點。

2.2 形式不相等不等於語義不等價

設 $x$ 與 $y$ 是兩個不同表示：

x\neq y

這只表示它們在字串、結構、型別或符號層不完全相同。

但仍可能有：

\operatorname{Meaning}(x,C) \simeq \operatorname{Meaning}(y,C)

其中 $C$ 為上下文。

例如：

true
True
YES
同意
可以
照做

在特定語境下可能都對應同一個確認意圖。

因此，傳統驗證器實際上可能只接受一個規範代表元：

x^\ast\in[x]_{\sim}

而拒絕同一語義等價類中的其他表示：

y\in[x]_{\sim}, \quad y\neq x^\ast

人類在操作語義等價類，傳統機器卻只接受等價類中的單一代表元。這正是大量「明明就是」事件的根源。

三、五種不可混淆的成立性

未來智能系統若要避免荒謬驗證，至少必須區分五種不同層次的成立性。

3.1 表示成立性

輸入是否符合字串、型別、schema 或語法規格：

F_{\mathrm{repr}}(x)

例如：

日期是否為 ISO 8601；
布林值是否為 true 或 false；
路徑是否為絕對路徑；
JSON 是否符合指定 schema。

3.2 語義成立性

輸入是否在當前上下文中表達了可辨識的意義：

F_{\mathrm{sem}}(x\mid C)

例如：

「明天下午。」

單獨看不完整，但在提醒任務上下文中已具有明確功能。

3.3 任務成立性

輸入是否已足以讓系統完成當前任務：

F_{\mathrm{task}}(x\mid C,G)

其中 $G$ 是任務目標。

有些輸入不是完整描述，但對目前任務已經足夠。例如在唯一開啟的專案中說：

「把 README 修一下。」

即使沒有絕對路徑，仍可能足以完成任務。

3.4 授權成立性

輸入是否構成特定行動的有效授權：

F_{\mathrm{auth}}(x,a\mid C,P)

其中：

$a$ ：候選行動；
$P$ ：既有權限與先前授權。

語義理解正確不等於授權成立：

F_{\mathrm{sem}}=1 \not\Rightarrow F_{\mathrm{auth}}=1

3.5 後果成立性

即使語義與授權都成立，實際行動是否仍在安全、可逆與合理後果範圍內：

F_{\mathrm{conseq}}(a\mid W,R)

其中：

$W$ ：當前世界狀態；
$R$ ：風險與不可逆性。

完整的智能驗證不應將這五層壓縮成單一布林值。

四、語義性假陰性

4.1 定義

本文將以下情況定義為「語義性假陰性」：

V_F(x)=0

但存在某個形式合法表示 $y$ ，使得：

y\in L_F

且：

\operatorname{Meaning}(y,C,G) \simeq \operatorname{Meaning}(x,C,G)

則稱 $x$ 對目前驗證系統構成語義性假陰性。

形式化為：

\operatorname{SFN}(x) \iff \left[ V_F(x)=0 \right] \land \left[ \exists y\in L_F: y\simeq_{C,G}x \right]

其中 SFN 代表 Semantic False Negative。

4.2 三種主要類型

表示性假陰性

語義相同，只因表示不同被拒絕。

例如：

yes
YES
Yes
true
1
同意

上下文性假陰性

單獨看不完整，但上下文已足以補全。

例如：

「放回原本那裡。」

若當前任務只有一個明確來源位置，「原本那裡」可能已足以唯一解析。

實用性假陰性

輸入沒有完整符合原始規格，但已足以完成使用者目的。

例如地址少了一個行政層級，但郵遞區號與街道已能唯一定位。此時「格式不完整」不等於「任務不可完成」。

五、傳統形式驗證不是錯，而是被放錯了位置

本文並不主張取消形式驗證。

形式驗證在以下領域仍然不可替代：

型別安全；
記憶體安全；
密碼學；
財務交易；
權限邊界；
核心狀態不變量；
航太與工業控制；
不可逆資料操作；
法律與身份認證；
關鍵基礎設施。

真正的問題不是形式驗證太嚴格，而是：

形式驗證被錯誤地當成了人類意圖的第一層也是唯一一層判定器。

傳統結構為：

人類輸入
→ 形式驗證
→ 通過／失敗

智能化結構應為：

人類輸入
→ 語義理解
→ 上下文補全
→ 等價判定
→ 無損正規化
→ 授權判定
→ 形式驗證
→ 後果檢查
→ 執行

形式驗證仍保留最終精確性，但不再直接負責理解自然語言。

六、智能語義驗證層

6.1 定義

本文提出「智能語義驗證層」：

Intelligent Semantic Validation Layer

縮寫：

\mathrm{ISVL}

其位置位於人類表達與傳統形式驗證器之間。

完整流程為：

Human Expression
→ Semantic Parsing
→ Context Retrieval
→ Semantic Envelope
→ ISVL
→ Intent–Authorization Mediation
→ Formal Validator
→ Runtime
→ Consequence Validator
→ Human-Visible Feedback

6.2 輸入

ISVL 的輸入可表示為：

\mathcal I_t = (x_t,C_t,G_t,M_t,W_t)

其中：

$x_t$ ：當前使用者輸入；
$C_t$ ：對話與任務上下文；
$G_t$ ：任務目標；
$M_t$ ：長短期記憶；
$W_t$ ：目前世界與系統狀態。

6.3 輸出

ISVL 不應只輸出成功或失敗，而應輸出：

\mathcal O_t = (y_t,E_t,A_t,Q_t,R_t)

其中：

$y_t$ ：規範化候選；
$E_t$ ：語義等價說明；
$A_t$ ：採用的假設；
$Q_t$ ：置信度；
$R_t$ ：風險與可逆性評估。

七、AI 中介形式驗證

7.1 核心概念

本文提出「AI 中介形式驗證」：

AI-Mediated Formal Validation

其基本結構為：

\boxed{ \text{人類語義表達} \rightarrow \text{AI 語義理解} \rightarrow \text{規範化候選} \rightarrow \text{語義保真檢查} \rightarrow \text{形式驗證} \rightarrow \text{風險控制} }

AI 並不直接取代形式驗證器，而是負責人類語義空間與機器形式空間之間的轉換。

7.2 正規化算子

設：

N(x,C,G)=y

其中 $N$ 是智能正規化算子。

系統僅在以下條件成立時自動接受：

V_F(y)=1

d_{\mathrm{sem}}(x,y\mid C,G)\leq\varepsilon

R(y)\leq\rho

其中：

$d_{\mathrm{sem}}$ ：語義距離；
$\varepsilon$ ：最大允許語義偏差；
$R(y)$ ：行動風險；
$\rho$ ：自動處理風險閾值。

因此智能驗證器可表示為：

V_I(x,C,G) = V_F(N(x,C,G)) \land \left[ d_{\mathrm{sem}} \left( x,N(x,C,G) \mid C,G \right) \leq\varepsilon \right]

7.3 不取消精確性

AI 中介形式驗證的目的不是：

AI 覺得差不多，就直接算通過。

而是：

AI 先找到與使用者意圖保真的合法表示，再交由形式系統進行精確驗證。

分工如下：

AI：
理解、補全、消歧、正規化、建立候選、解釋假設。

形式驗證器：
檢查型別、範圍、schema、不變量、權限、安全與可執行性。

Runtime：
執行、記錄、回滾、監測後果。

人類：
設定目的、限制、風險偏好與最終高風險決策。

八、意圖保真條件

8.1 為何需要保真

正規化本身可能改變意義。

例如：

「明天下午提醒我。」

系統將其正規化為：

2026-07-15 15:00 Asia/Taipei

這看似合理，但實際加入了至少兩個假設：

「下午」預設為 15:00；
使用者時區為 Asia/Taipei。

因此智能驗證不能只檢查形式合法，還必須檢查轉換是否保存使用者意圖。

8.2 保真函數

定義：

\operatorname{Fidelity}(x,y\mid C,G)\in[0,1]

只有當：

\operatorname{Fidelity}(x,y\mid C,G)\geq\tau

系統才可將 $y$ 視為 $x$ 的可接受正規化。

其中 $\tau$ 為保真門檻。

8.3 保真維度

意圖保真至少包含：

\mathcal F = ( F_{\mathrm{goal}}, F_{\mathrm{scope}}, F_{\mathrm{object}}, F_{\mathrm{time}}, F_{\mathrm{method}}, F_{\mathrm{risk}} )

即：

目標是否保存；
作用範圍是否保存；
操作對象是否保存；
時間條件是否保存；
方法限制是否保存；
風險邊界是否保存。

即使目標一致，若作用範圍被擴大，仍不能視為完全保真。

九、語義修復證書

為避免 AI 正規化成為不可見黑箱，本文提出「語義修復證書」。

其最小格式可為：

original_input: "明天下午"
normalized_value: "2026-07-15T15:00:00+08:00"

context_used:
  timezone: "Asia/Taipei"
  current_date: "2026-07-14"

assumptions:
  afternoon_default: "15:00"

semantic_operations:
  - resolve_relative_date
  - resolve_daypart
  - attach_timezone

fidelity:
  goal: 1.00
  time: 0.92
  scope: 1.00

confidence: 0.96
risk: low
reversible: true
formal_validation: passed

語義修復證書的功能包括：

讓人類看見 AI 做了哪些補全；
讓系統能追溯錯誤來源；
讓高風險操作可進一步審查；
讓不同 Agent 可承接同一判定；
讓形式驗證與語義推理之間具有可稽核接口。

十、六態驗證模型

傳統驗證通常只有：

\{\text{Pass},\text{Fail}\}

本文主張智能驗證至少應有六種狀態。

10.1 精確通過

原輸入已符合形式與語義規格。

D_1=\text{Exact Pass}

10.2 等價正規化後通過

原輸入形式不符，但可無損轉換。

D_2=\text{Normalized Pass}

10.3 上下文補全後通過

缺失資訊可由上下文唯一或高置信補全。

D_3=\text{Contextual Pass}

10.4 限定範圍後通過

整體意圖成立，但只能在最小安全範圍內執行。

D_4=\text{Scoped Pass}

10.5 需要最小化澄清

存在多個後果差異顯著的合理解讀。

D_5=\text{Clarification Required}

10.6 真正拒絕

無法合理正規化、明確越權、風險過高或違反政策。

D_6=\text{Reject}

此六態模型能把大量本應屬於「可修復」的輸入，從錯誤失敗中分離出來。

十一、後果敏感式消歧

11.1 不應對所有模糊都詢問

自然語言幾乎永遠存在模糊性。

如果系統要求所有模糊都被完全消除，則人類必須替機器完成全部形式化，意圖語言將失去意義。

因此，系統不應問：

這句話是否存在任何模糊？

而應問：

不同合理解讀是否會造成顯著不同後果？

11.2 候選分歧

設語義候選集合為：

\mathcal M(x) = \{m_1,m_2,\dots,m_n\}

每個候選對應行動：

a_i=\pi(m_i)

若：

\operatorname{Divergence}(a_i,a_j)\leq\theta

則不同理解的實際後果近似，可以直接採取最小風險方案。

只有當：

\operatorname{Divergence}(a_i,a_j)>\theta

才需要澄清。

這稱為：

後果敏感式消歧

它反對的是「語法潔癖式消歧」：只因表達不完美就中斷任務。

十二、驗證與權限不可混為一談

即使系統正確理解使用者的意思，仍不代表已取得完整操作授權。

因此：

\operatorname{SemanticMatch}(x,a) \not\Rightarrow \operatorname{Authorized}(a)

相反地，形式表達不完整也不等於沒有授權：

\neg\operatorname{FormalComplete}(x) \not\Rightarrow \neg\operatorname{Authorized}(a)

完整架構需要兩個不同中介層：

ISVL：
判斷「這是不是那個意思」。

IAML：
判斷「這個意思是否授權這個行動」。

其順序為：

\text{Expression} \rightarrow \mathrm{ISVL} \rightarrow \mathrm{IAML} \rightarrow \mathrm{FormalValidator} \rightarrow \mathrm{Runtime}

十三、風險分層與智能驗證

13.1 驗證嚴格度不應固定

不同任務應使用不同驗證強度。

定義錯誤執行損失：

L_{\mathrm{wrong}} = p_{\mathrm{misinterpret}} \cdot I_{\mathrm{impact}} \cdot (1-R_{\mathrm{reversible}})

其中：

$p_{\mathrm{misinterpret}}$ ：誤解機率；
$I_{\mathrm{impact}}$ ：影響程度；
$R_{\mathrm{reversible}}$ ：可逆性。

再定義打斷成本：

C_{\mathrm{interrupt}}

當：

L_{\mathrm{wrong}} > C_{\mathrm{interrupt}}

系統才應要求確認。

13.2 低風險任務

例如：

搜尋；
摘要；
建立草稿；
產生預覽；
可回滾的局部修改。

應允許較高程度的智能補全。

13.3 中風險任務

例如：

修改專案；
建立外部可見內容；
更新設定；
大量搬移資料。

應採：

顯示 Diff；
限定作用範圍；
保留回滾；
記錄假設。

13.4 高風險任務

例如：

刪除資料；
發送外部訊息；
正式部署；
財務交易；
法律承諾；
身份與權限變更。

應保留明確形式確認，不得僅依語義近似。

因此，智能化不是全面放寬，而是：

在低風險處減少無意義阻斷，在高風險處保留精確、可追溯的形式邊界。

十四、典型案例

14.1 布林同意

使用者輸入：

可以。

傳統驗證器要求：

CONFIRM=true

智能系統應先判斷：

當前是否正在等待確認；
「可以」是否指向該行動；
是否存在其他候選對象；
行動風險級別為何。

若是低風險且上下文唯一，可轉換為：

CONFIRM=true

若是高風險刪除，則仍應顯示：

你正在確認永久刪除 327 個檔案。

14.2 日期時間

使用者輸入：

明天下午提醒我。

智能正規化：

date: 2026-07-15
time: 15:00
timezone: Asia/Taipei

若系統認為「下午」預設存在不確定性，可採可逆提醒並顯示假設，而非直接失敗。

14.3 路徑與工作區

使用者輸入：

把 README 改成剛才那個版本。

若：

當前工作區唯一；
README 唯一；
「剛才那個版本」在上下文中唯一；
修改可回滾；

則系統應直接生成 Patch 並顯示 Diff，而不是要求完整路徑與版本 ID。

14.4 格式差異

系統要求：

report_final.md

使用者提供：

Report Final.MD

系統應根據檔案系統大小寫規則、專案命名規約與現有檔案狀態判斷是否為同一目標，而不是直接宣告不存在。

14.5 地址與識別資訊

若使用者提供的資料已能唯一定位，額外欄位缺失應標記為「形式不完整但任務充分」，而非必然拒絕。

十五、智能驗證缺口命題

本文提出以下核心命題。

命題一：形式拒絕非語義拒絕

V_F(x)=0

只能推出：

x\notin L_F

不能直接推出：

\operatorname{InvalidIntent}(x)

命題二：語義等價類擴張接受域

若存在：

y\in L_F

且：

y\simeq_{C,G}x

則 $x$ 應進入智能修復程序，而非直接失敗。

命題三：智能驗證應最小化雙重錯誤

系統同時面臨：

E_{\mathrm{false\ accept}}

與：

E_{\mathrm{false\ reject}}

成熟系統應最小化：

\boxed{ E_{\mathrm{false\ accept}} + E_{\mathrm{false\ reject}} + C_{\mathrm{interrupt}} }

命題四：高風險不等於高模糊

某些高風險操作即使語義非常清楚，也仍需明確確認。

因此驗證嚴格度應主要由後果、不可逆性與授權要求決定，而非只由語句模糊度決定。

命題五：智能化驗證不取消形式化

智能驗證最終仍需回到形式合法表示：

x \xrightarrow{\mathrm{ISVL}} y \xrightarrow{V_F} \{0,1\}

其革新在於形式化不再完全由使用者手工完成。

十六、與意圖語言時代的關係

如果未來系統仍要求人類：

記住每一個 enum；
輸入完全一致的關鍵字；
手動填滿所有 schema；
重複提供上下文；
指定完整絕對路徑；
自行把自然語言轉成 API 參數；
為每個低風險步驟重新確認；

那麼這不是真正的意圖語言系統。

它只是：

傳統形式系統外面包了一個聊天介面。

真正的意圖語言架構應分工為：

\boxed{ \text{Human} : \text{Meaning, Goal, Constraint, Value} }

\boxed{ \text{AI} : \text{Interpretation, Completion, Alignment, Normalization} }

\boxed{ \text{Formal Machine} : \text{Proof, Type, Invariant, Permission, Safety} }

\boxed{ \text{Runtime} : \text{Execution, Trace, Recovery, Consequence} }

意圖語言時代不是形式化消失，而是形式化責任從使用者身上部分移交給智能中介層。

十七、與 Agent 系統的關係

Agent 若沒有智能驗證層，就會出現兩種極端。

17.1 過度執行

Agent 認為：

我理解你的意思，因此我可以執行所有相關操作。

這會產生錯誤授權。

17.2 過度拒絕

Agent 認為：

你的表達沒有完全符合形式，因此你沒有意圖、沒有授權或沒有完成要求。

這會產生語義性假陰性。

成熟 Agent 必須同時避免：

\text{False Authorization}

以及：

\text{False Non-Authorization}

因此完整 Agent 決策鏈應為：

I_H \rightarrow \mathcal S_I \rightarrow \mathrm{ISVL} \rightarrow \mathrm{IAML} \rightarrow A_{\mathrm{IR}} \rightarrow \mathcal R \rightarrow \mathcal V_F \rightarrow \mathcal E \rightarrow \Delta W

其中：

$I_H$ ：人類輸入；
$\mathcal S_I$ ：語義包絡；
$\mathrm{ISVL}$ ：智能語義驗證；
$\mathrm{IAML}$ ：意圖授權調和；
$A_{\mathrm{IR}}$ ：候選行動表示；
$\mathcal R$ ：風險判定；
$\mathcal V_F$ ：形式驗證；
$\mathcal E$ ：執行；
$\Delta W$ ：世界狀態變化。

十八、工程實作建議

18.1 驗證器應回傳結構化結果

不應只回傳：

{
  "valid": false
}

應改為：

{
  "status": "repairable",
  "formal_error": "invalid_datetime_format",
  "semantic_interpretation": "2026-07-15T15:00:00+08:00",
  "assumptions": [
    "timezone=Asia/Taipei",
    "afternoon=15:00"
  ],
  "confidence": 0.96,
  "risk": "low",
  "recommended_action": "normalize_and_continue"
}

18.2 驗證流程分層

Layer 1：字串與語法檢查
Layer 2：資料型別與 schema
Layer 3：語義等價與上下文補全
Layer 4：任務充分性
Layer 5：授權範圍
Layer 6：後果與風險
Layer 7：Runtime 不變量
Layer 8：執行後驗證

18.3 保留傳統驗證器作為可信底座

AI 層不可直接繞過：

型別；
權限；
不變量；
資料庫約束；
安全政策；
交易一致性；
不可逆操作確認。

AI 的責任是提出合法候選，不是任意關閉驗證。

18.4 建立可回滾的自動修復

對低風險操作，系統可採：

理解
→ 正規化
→ 模擬
→ 驗證
→ 執行
→ 記錄
→ 可回滾

18.5 驗證假設必須可見

所有由 AI 加入的關鍵假設應：

可顯示；
可追蹤；
可撤回；
可修正；
可供後續 Agent 使用。

十九、評估框架

智能驗證系統不能只用「通過率」評估。

至少應包含以下指標。

19.1 語義假陰性率

\operatorname{SFNR} = \frac{ \text{語義成立但形式拒絕的案例數} }{ \text{全部語義成立案例數} }

19.2 錯誤接受率

\operatorname{FAR} = \frac{ \text{語義或授權不成立但被接受的案例數} }{ \text{全部不應接受案例數} }

19.3 語義保真率

\operatorname{FidelityRate} = \mathbb E[ \operatorname{Fidelity}(x,N(x)) ]

19.4 不必要澄清率

\operatorname{UCR} = \frac{ \text{其實可安全自動處理但要求澄清的案例} }{ \text{全部澄清案例} }

19.5 任務完成率

比較：

純形式驗證；
AI 中介形式驗證；
AI 無形式底座；
分層混合驗證。

19.6 風險加權效用

U = S_{\mathrm{task}} - \lambda_1 E_{\mathrm{false\ accept}} - \lambda_2 E_{\mathrm{false\ reject}} - \lambda_3 C_{\mathrm{interrupt}}

其中：

$S_{\mathrm{task}}$ ：任務成功收益；
$\lambda_i$ ：風險權重。

二十、限制與反對意見

20.1 AI 可能誤判語義

是。因此 AI 不應直接取代形式驗證，而應提供：

候選；
假設；
置信度；
保真評估；
風險分級；
可回滾路徑。

20.2 語義等價並不總能形式證明

是。本文提出的並非所有語義等價都能被完全證明，而是建立一個可稽核、可限制、可回退的工程中介層。

20.3 智能驗證可能增加複雜度

是。但目前系統已將複雜度轉嫁給使用者。智能驗證只是把這些隱性成本重新放回系統內部。

20.4 高風險領域不應依賴語義推定

部分正確。高風險領域仍需要明確授權與嚴格形式化，但即使在高風險領域，AI 仍可協助：

正規化輸入；
發現缺漏；
解釋差異；
準備確認內容；
減少無意義格式錯誤。

20.5 是否會讓使用者過度依賴 AI

有可能。因此系統必須顯示假設與關鍵轉換，不能讓智能正規化完全不可見。

二十一、結論

本文主張，現代人機系統最荒謬的一類失敗，不是機器算錯，而是機器驗證錯了層級。

當使用者的意圖在語義上已成立、任務上已充分、上下文中已可補全時，系統卻仍因形式表示不完全一致而宣告失敗，這不是單純的格式問題，而是「智能驗證缺口」。

本文提出：

形式拒絕不等於語義拒絕；
語義等價類不應被單一形式代表元壟斷；
應區分表示、語義、任務、授權與後果五種成立性；
應識別語義性假陰性；
應建立智能語義驗證層；
應採用 AI 中介形式驗證；
應以意圖保真限制智能正規化；
應將驗證結果由二元改為六態；
應以後果敏感而非語法潔癖決定是否澄清；
應保留形式驗證作為安全與精確性的底座。

因此，未來驗證系統的目標不應只是：

判斷輸入是否符合既定格式。

而應升級為：

判斷使用者的意義是否已充分成立，是否可以在保真、授權與安全條件下轉換成可執行形式。

意圖語言時代真正需要的，不是讓人類更擅長迎合機器格式，而是讓智能系統終於有能力承認：

即使表示不完全一樣，事情有時候確實已經是了。

附錄 A：核心定義表

概念	定義
智能驗證缺口	系統具備語義理解能力，但有效性判定仍只依賴傳統形式成員資格
語義性假陰性	形式驗證拒絕，但存在語義等價且形式合法的表示
智能語義驗證層	位於自然語言輸入與形式驗證器之間的語義補全、等價判定與正規化層
AI 中介形式驗證	AI 生成保真的合法候選，再由形式系統進行精確驗證
意圖保真	正規化結果是否保存原始目標、範圍、對象、時間、方法與風險限制
語義修復證書	記錄原始輸入、正規化結果、假設、語義操作、置信度與風險的可稽核資料
後果敏感式消歧	只有不同合理解讀會造成顯著不同後果時才要求澄清

附錄 B：最小參考架構

┌─────────────────────────────────────────────┐
│ Human Meaning / Goal / Constraint           │
├─────────────────────────────────────────────┤
│ Context & Memory Retrieval                  │
├─────────────────────────────────────────────┤
│ Semantic Envelope                           │
├─────────────────────────────────────────────┤
│ ISVL: Intelligent Semantic Validation       │
├─────────────────────────────────────────────┤
│ Intent Fidelity & Repair Certificate        │
├─────────────────────────────────────────────┤
│ IAML: Intent–Authorization Mediation        │
├─────────────────────────────────────────────┤
│ Formal Validator / Type / Schema / Policy   │
├─────────────────────────────────────────────┤
│ Risk / Consequence / Reversibility          │
├─────────────────────────────────────────────┤
│ Runtime / Execution / Trace / Rollback      │
├─────────────────────────────────────────────┤
│ Human-Visible State & Explanation           │
└─────────────────────────────────────────────┘

附錄 C：後續可延伸論文

《語義意圖與操作授權之間：AI Agent 的模糊性、部分同意與後果敏感驗證機制》
《意圖保真理論：自然語言到可執行中間表示的語義保存條件》
《AI 中介形式系統：從 parser、schema 到語義修復證書》
《語義性假陰性的測量：智能表單、Agent 工具與工作流驗證基準》
《後果敏感式消歧：自然語言 Agent 中的最小澄清原理》

智能驗證缺口_從形式可接受性到語義等價與AI中介形式驗證_v1.0

title: "智能驗證缺口：從形式可接受性到語義等價、意圖保真與 AI 中介形式驗證" subtitle: "意圖語言時代的人機驗證重構" author: "Neo.K / EVEMISSLAB" date: "2026-07-14" version: "v1.0" status: "理論草稿／方法論論文" language: "zh-TW"

智能驗證缺口：從形式可接受性到語義等價、意圖保真與 AI 中介形式驗證

摘要

一、問題的提出

1.1 「明明就是，但機器卻說不是」

1.2 現代智能介面與傳統驗證核心的錯位

智能驗證缺口

二、形式驗證究竟驗證了什麼

2.1 形式語言中的接受與拒絕

2.2 形式不相等不等於語義不等價

三、五種不可混淆的成立性

3.1 表示成立性

3.2 語義成立性

3.3 任務成立性

3.4 授權成立性

3.5 後果成立性

四、語義性假陰性

4.1 定義

4.2 三種主要類型

表示性假陰性

上下文性假陰性

實用性假陰性

五、傳統形式驗證不是錯，而是被放錯了位置

六、智能語義驗證層

6.1 定義

Intelligent Semantic Validation Layer

6.2 輸入

6.3 輸出

七、AI 中介形式驗證

7.1 核心概念

AI-Mediated Formal Validation

7.2 正規化算子

7.3 不取消精確性

八、意圖保真條件

8.1 為何需要保真

8.2 保真函數

8.3 保真維度

九、語義修復證書

十、六態驗證模型

10.1 精確通過

10.2 等價正規化後通過

10.3 上下文補全後通過

10.4 限定範圍後通過

10.5 需要最小化澄清

10.6 真正拒絕

十一、後果敏感式消歧

11.1 不應對所有模糊都詢問

11.2 候選分歧

後果敏感式消歧

十二、驗證與權限不可混為一談

十三、風險分層與智能驗證

13.1 驗證嚴格度不應固定

13.2 低風險任務

13.3 中風險任務

13.4 高風險任務

十四、典型案例

14.1 布林同意

14.2 日期時間

14.3 路徑與工作區

14.4 格式差異

14.5 地址與識別資訊

十五、智能驗證缺口命題

命題一：形式拒絕非語義拒絕

命題二：語義等價類擴張接受域

命題三：智能驗證應最小化雙重錯誤

命題四：高風險不等於高模糊

命題五：智能化驗證不取消形式化

十六、與意圖語言時代的關係

十七、與 Agent 系統的關係

17.1 過度執行

17.2 過度拒絕

十八、工程實作建議

18.1 驗證器應回傳結構化結果

18.2 驗證流程分層

18.3 保留傳統驗證器作為可信底座

18.4 建立可回滾的自動修復

18.5 驗證假設必須可見

十九、評估框架

19.1 語義假陰性率