# HBS 2.0：拓撲坍塌與全量投影協議

**Holographic Buffered Synthesis 2.0: Topological Collapse & Full-Projection Protocol**

---

| 欄位 | 內容 |
|------|------|
| 作者 | Neo.K（許筌崴），EveMissLab |
| 產品代號 | God's Seal（神之印） |
| 文件版本 | v0.1（概念形式化草稿，實作前） |
| 狀態 | 概念形式化完成 — 待 Open WebUI 魔改 Demo 驗證後升版 |
| 升版觸發條件 | APE 渲染實作可展示 + 隱藏緩衝機制驗證通過 |

---

## 摘要

現有大型語言模型（LLM）介面普遍採用**流式線性暴露**（Streaming Linear Exposure, SLE）範式：以接近即時的 token 串流向用戶模擬線性輸出行為。本文主張，SLE 作為工程型任務的輸出範式存在結構性缺陷，其根本問題不在速度，而在**暴露結構的選擇錯誤**。

HBS 2.0 提出以**原子投影事件**（Atomic Projection Event, APE）作為替代的輸出原語：在後端完成全量生成與品質驗證後，由渲染層在單一幀內完成全量投影，用戶所觀察到的輸出呈現為離散的頓現事件而非連續串流。

核心理論主張為：**認知計算時間（T_proc）與用戶感知暴露時間（T_exp）可以且應當被徹底解耦**。這一解耦不要求任何模型層面的改變，僅需重新設計介面協議層的緩衝、結晶與投影三個環節。

---

## 一、問題定義：流式線性暴露的結構性缺陷

### 1.1 SLE 範式的形式定義

設 AI 系統針對用戶指令 Q 所生成的完整結果集為 R，R 包含 n 個語義單元（token、行、組件）。在 SLE 範式下，R 被分解為有序序列 {c₁, c₂, ..., cₙ}，以近似恆定速率 r（token/s）依序傳輸至用戶端。

用戶在時刻 t 所觀察到的部分結果為：

```
S(t) = { cᵢ | tᵢ ≤ t },  其中 tᵢ = t₀ + i/r
```

即**用戶體驗是時間的連續函數**，且在任何中間時刻 t < T_final 均處於「部分完整」狀態。T_final = t₀ + n/r 為全量輸出完成時刻。

### 1.2 三重結構性代價

#### 代價一：線性焦慮（Linear Anxiety）

由於 S(t) 在 t < T_final 時始終為不完整狀態，用戶無法得知最終 R 是否滿足需求，被迫持續監視串流進度。認知負荷隨輸出長度 n 線性增長。

更嚴重的是：若錯誤發生於生成序列的第 k 個單元，用戶已投入的觀察時間 t_k 被完全浪費，且無法在觀察過程中觸發有效的中斷補救機制。這種不確定性滲透整個輸出窗口，稱為**線性焦慮**。

#### 代價二：錯誤可見性（Error Visibility）

SLE 架構下，任何生成錯誤（邏輯矛盾、語法錯誤、架構偏差、幻覺內容）在被生成的同一時刻即對用戶可見。這造成兩個連鎖問題：

1. **信任侵蝕**：用戶直接觀察到 AI 的「思考失誤」，即使最終被修正，也已破壞對系統可靠性的心理預期。
2. **品質控制盲區**：由於輸出在生成中即已暴露，任何後端透明的品質控制機制（重試、自動修正）均無法在不破壞 UX 連貫性的前提下執行。

#### 代價三：認知中斷（Cognitive Interruption）

逐字暴露迫使用戶以「接收速度」跟蹤輸出，而非以「理解速度」整合輸出。當輸出超過臨界長度 L_threshold（工程型任務估計約 200 行代碼），用戶無法在閱讀過程中維持對整體結構的認知。

結果是：理解時間被強制分裂為「即時跟蹤」（低理解深度）與「事後整合」（重新閱讀完整輸出）兩個階段。SLE 宣稱提供了「即時反饋」，實際上製造了一次多餘的不完整閱讀行程。

### 1.3 根本矛盾：錯誤的優化目標

現有介面選擇「首 token 延遲最小化」（First Token Latency, FTL）作為核心 UX 指標。這繼承了對話式語言介面的設計哲學——模擬人類的即時回應行為。

對於對話式問答，FTL 優先是合理的。**但對於以代碼、文檔、架構圖為輸出單元的工程型任務，FTL 優先是錯誤的優化目標。**

正確的優化目標應為：**完整結果的感知頓現最小化**（Perceived Full-Result Latency, PFRL）。FTL 與 PFRL 不是同一個指標，且在大多數工程型任務場景中存在張力。

---

## 二、核心理論：原子投影事件

### 2.1 APE 的形式定義

**原子投影事件**（Atomic Projection Event, APE）定義為：完整結果集 R 在用戶端以**單一離散事件**的形式顯現，且 R 的所有組件在同一渲染幀內完成投影。

設 T_proc 為後端完成全量生成並通過品質驗證的時刻，T_display 為前端觸發渲染的時刻，則 APE 的形式約束為：

```
APE 約束集：
  (1) 完整性約束：T_display ≥ T_proc
      — 渲染觸發必須且僅在完整結果就緒後執行
  (2) 原子性約束：∀ Cᵢ ∈ R，Cᵢ 在 T_display 至 T_display + Δt_frame 內完成投影
      — Δt_frame ≤ 16ms（單渲染幀），R 的所有組件同幀顯現
  (3) 隔離性約束：∀ t ∈ [0, T_display)，用戶觀察到的輸出信號集為 ∅
      — 中間態對用戶完全不可見，僅提供進度指示符
```

### 2.2 SLE 與 APE 的形式對比

| 性質 | SLE | APE |
|------|-----|-----|
| 用戶觀察函數 | 連續函數 S(t) | 階躍函數 H(t − T_display) · R |
| 中間態可見性 | 完全可見 | 完全隔離（約束 3） |
| 錯誤可見性 | 生成即暴露 | 品質驗證後方暴露（後端透明） |
| 首感知延遲（FTL） | 最短（≈ 1s） | 等於 T_proc |
| 全量感知延遲（PFRL） | T_proc + 串流傳輸時間 | T_proc + Δt_frame（≈ T_proc） |
| 品質控制窗口 | 無（已暴露） | [0, T_display) 全窗口可用 |

**關鍵觀察**：APE 的 FTL 劣於 SLE，但 PFRL 近似等於 T_proc，與 SLE 相同甚至更優（消除了串流傳輸的累積延遲）。在工程型任務場景中，用戶真正關心的是 PFRL，而非 FTL。

### 2.3 感知時間解耦定理

**定理（T_proc 與 T_display 解耦）：** 在 APE 架構下，後端計算時間 T_proc 的優化與前端感知暴露時間 T_display 的優化是獨立問題，可分別進行而互不干擾。

**推論 A（後端獨立優化）：** T_proc 可通過模型加速、輸出緩存、Prompt 工程等後端手段壓縮，無需修改前端任何邏輯。

**推論 B（前端獨立優化）：** 在 T_proc 固定的情況下，T_display 至實際像素顯現的時間差 Δt_render 可通過 Canvas/WebGL 並行渲染壓縮至單幀（16ms），與 T_proc 的絕對值無關。

**推論 C（心理補償空間）：** 用戶的主觀等待體驗由加載動畫的心理設計調控，而非由 T_proc 直接決定。加載動畫作為認知佔位符，在 [0, T_display) 區間內維持用戶的注意力與期待張力，使 T_proc 的客觀長度對主觀體驗的影響被大幅壓縮。

**這是 HBS 2.0 的核心工程洞見：生成速度的物理限制不等於體驗速度的感知限制。**

---

## 三、四階段相變引擎

HBS 2.0 的處理流程由四個語義階段構成，對應從混沌輸入到結晶輸出的狀態轉變序列。

### Phase I：奇點認知閉環（Singularity Loop）

**系統狀態：** 混沌態（Chaos）

後端接收用戶指令 Q 後，啟動 LLM 的完整生成過程。本階段的核心約束定義了 HBS 2.0 與 SLE 的根本分叉點：

**隱藏緩衝區（Hidden Buffer）協議：**
- 所有 token 生成流入後端緩衝區，前端不接收任何輸出信號
- 強制結構化輸出：要求 LLM 以預定義 JSON Schema 格式輸出，而非自由文本流
  - Schema 至少包含：`{ "components": [...], "metadata": {...} }`
  - 各組件附帶 MSSP 層級標籤（FMS / SMS / TMS）
- 品質驗證循環：若輸出不符合 Schema 或未通過語義驗證，後端透明觸發重試（最多 N 次），對用戶完全不可見

**Phase I 的輸出：** 符合 Schema 的完整結構化 JSON，存儲於 Hidden Buffer，等待 Phase II 處理。

### Phase II：邏輯結晶化（Logical Crystallization）

**系統狀態：** 固化態（Solidification）

接收 Phase I 完整輸出後，執行結構化解析與 MSSP 分層：

1. **Schema 解析**：提取各輸出組件 {C₁, C₂, ..., Cₖ}
2. **MSSP 分層**：根據組件的層級標籤分類至 FMS（全局敘述）/ SMS（核心模組）/ TMS（功能子集）
3. **依賴圖構建**：解析組件間的引用關係，生成有向依賴圖 G = (V, E)，用於 Phase III 的拓撲構建

**Phase II 的輸出：** 結構化組件集合 {Cᵢ, layer_i, position_hint_i}，以二進制格式（MessagePack）傳輸至前端。

### Phase III：語義拓撲構建（Semantic Topologization）

**系統狀態：** 結構態（Structuring）

前端接收 Phase II 輸出後，在客戶端本地執行輕量拓撲構建：

1. **代碼組件**：使用 Tree-sitter（或等效 AST 解析器）生成語法樹，提取模組依賴關係
2. **架構組件**：根據 MSSP 分層標籤生成 Mermaid 圖表聲明，確定圖節點布局
3. **空間布局計算**：預先計算所有文字、圖形組件在畫布上的 (x, y) 坐標及尺寸

現代瀏覽器 / 本地應用在 500-1000 行代碼規模下，Phase III 可在 <5ms 內完成。

**Phase III 的輸出：** 全量渲染指令集，包含每個像素操作的預計算坐標，等待 Phase IV 的單幀執行。

### Phase IV：瞬間坍塌與全量投影（Atomic Collapse & Full Projection）

**系統狀態：** 現實態（Reality）

當 Phase III 完成後，在下一個渲染幀觸發全量投影：

- 使用 Canvas 2D API（Lite 版）或 WebGL Shader（完整版）執行並行像素寫入
- 所有組件坐標已在 Phase III 預計算完成，此步驟為純並行繪製操作，無任何動態計算開銷
- 畫布在單一幀（≤ 16ms）內從「加載動畫」狀態原子性切換至「完整輸出」狀態

**對用戶的可見效果：** 沒有游標移動，沒有逐行顯示，沒有漸進填充。畫布在一幀內完成 APE，呈現完整的代碼、架構圖與文檔的同時顯現。

**APE 約束的滿足驗證：**
- 完整性約束 ✓：Phase IV 僅在 Phase I-III 全部完成後觸發
- 原子性約束 ✓：所有組件在同一 drawFrame 調用中完成
- 隔離性約束 ✓：[0, T_display) 期間前端僅顯示加載動畫

---

## 四、技術架構規範

### 4.1 Lite 版架構（當前可實作路徑）

```
[用戶輸入 Q]
      │
      │  前端：加載動畫啟動
      │
      ↓  WebSocket 長連接（零握手延遲）
[後端：Phase I]
  LLM API 調用
  Hidden CoT（CoT 令牌不傳輸至前端）
  強制 JSON Schema 輸出
  品質驗證 + 自動重試（N ≤ 3）
      │
      ↓  MessagePack 二進制傳輸（完整 JSON 數據包）
[前端：Phase II]
  JSON 解析
  MSSP 分層（FMS / SMS / TMS 標籤解析）
  組件集合構建
      │
      ↓  本地計算（< 5ms）
[前端：Phase III]
  AST 解析（Tree-sitter）
  Mermaid 圖表聲明生成
  畫布空間布局預計算
      │
      ↓  requestAnimationFrame 觸發
[前端：Phase IV]
  Canvas 2D 全量並行繪製
  單幀 APE（≤ 16ms）
      │
      ↓
[用戶觀察：Atomic Projection Event]
```

#### 核心技術選型

| 層 | 技術方案 | 選型理由 |
|----|----------|----------|
| 網路傳輸 | WebSocket + MessagePack | 長連接零握手；二進制格式解析速度 ≈ JSON × 10 |
| 推理後端 | Claude / GPT-4 API + Hidden CoT | 無需重新訓練，利用現有模型能力 |
| 輸出格式強制 | JSON Schema + 驗證循環 | 確保 Phase II 解析零歧義 |
| AST 解析 | Tree-sitter（WebAssembly 版） | 多語言支持，瀏覽器端可運行 |
| 圖表生成 | Mermaid.js（聲明式） | 聲明式語法，與 MSSP 分層標籤直接對應 |
| 渲染引擎（Lite） | Canvas 2D | 繞過 DOM reflow，直接像素操作 |
| 渲染引擎（標準） | WebGL + Pixi.js | WebGL 並行繪製，幀率更穩定 |
| 打包方案 | Web 原型 → Tauri（Rust 後端） | Web 開發速度 + 原生應用性能；Rust 後端處理 Phase I-II 重計算 |

#### 為何拒絕 DOM 渲染

標準 HTML DOM 渲染（`<div>`、語法高亮庫）在 APE 架構下存在結構性障礙：DOM 操作會觸發 Layout 計算與 Paint，這是瀏覽器的**同步阻塞**操作。大量代碼的 DOM 插入會導致可見的回流（Reflow）延遲，直接破壞原子性約束。Canvas / WebGL 操作繞過 DOM 管道，直接寫入像素緩衝區，是 APE 的必要渲染基礎。

### 4.2 Full 版架構（願景，依賴 Nova 生態）

Full 版與 Lite 版共享同一 APE 理論內核，差異集中於推理引擎與渲染引擎的實作深度：

| 層 | Lite 版 | Full 版 |
|----|---------|---------|
| 推理機制 | LLM API + Hidden CoT | Neo.K Auditor G-P-R 高頻循環（生成-投影-修正） |
| 中間態表示 | JSON 記憶體緩衝 | 張量化語義拓撲圖（VRAM 常駐） |
| AST 層級 | 語法樹（Tree-sitter） | 語義拓撲圖（Nova 張量原生 AST） |
| 渲染引擎 | Canvas 2D / WebGL + Pixi.js | CUDA Kernel 布局 + SDF Shader |
| APE 幀時間 | 16-30ms（幀級顯現） | 3-5ms（物理層顯現） |
| 核心依賴 | 現有 Web 技術棧 | Nova 張量語言架構（EveMissLab，待開發） |

Full 版的核心技術依賴為 **Nova**——EveMissLab 的張量原生語言架構，尚在理論開發階段。Full 版不是當前工程優先項，而是 Lite 版驗證後的長期演化目標。

### 4.3 Open WebUI 魔改路徑

HBS 2.0 的首個可驗證實作以 Open WebUI 為改造基礎：

- **替換串流渲染管道**：攔截 Open WebUI 的 token 串流輸出，插入 Hidden Buffer 層，token 在後端緩衝完整後方觸發前端渲染
- **強制 Prompt 模板注入**：系統 Prompt 層注入結構化輸出指令，要求 LLM 輸出符合 HBS Schema 的 JSON
- **替換代碼渲染器**：以 Canvas 2D 渲染器替換現有的 DOM 高亮方案，實現 APE
- **加載動畫設計**：開發「神之印」旋轉動畫作為認知佔位符，覆蓋 T_proc 窗口

目標：作為 EveMissLab 工具鏈的本地端核心介面，魔改版達到 Demo 可展示狀態後，連同本白皮書同步開源。

---

## 五、差異化邊界分析

### 5.1 與隱藏 CoT 方案的邊界

現有系統（如 OpenAI o1 系列）已採用隱藏思維鏈，後端推理過程對用戶不可見。HBS 2.0 的差異不在「隱藏生成過程」本身，而在以下三點的**聯立**：

1. **結構化交付保證（MSSP 約束）**：輸出組件必須符合 FMS/SMS/TMS 分層架構，而非任意自然語言文本。這保證了輸出在 Phase IV 投影後是可導航的工程結構，而非平鋪的文本塊。
2. **渲染層的原子性（APE 硬性約束）**：APE 是架構規範，而非可選 UX 風格。任何繞過原子性約束的漸進顯示均不構成 HBS 2.0 的兼容實作。
3. **工具鏈閉環**：Hidden Buffer 的輸出直接進入 FPL 編譯器（結構化代碼生成）和 STDPL 意圖記錄（CoT 意圖提取），形成 EveMissLab 工具鏈的閉環連接。

### 5.2 與 Canvas 渲染方案的邊界

Canvas 代碼渲染技術本身在多個代碼編輯器中存在。HBS 2.0 的渲染層創新在於：

1. **APE 觸發時機的嚴格約束**：Canvas 繪製操作僅在完整結果準備就緒、Phase I-III 全部完成後觸發。增量 Canvas 渲染（逐塊繪入）違反原子性約束，不構成 APE。
2. **多組件同步投影**：代碼、架構圖、文檔在同一渲染幀內完成。分組件的順序顯現（即使每個組件內部是瞬間的）仍屬於受限的 SLE，而非 APE。

### 5.3 HBS 2.0 的可防禦差異化定義

HBS 2.0 的最小可防禦差異化邊界由以下三個約束的**完整聯立**定義：

```
HBS 2.0 ≡
  完整性約束（T_display ≥ T_proc）
  ∧ 原子性約束（∀ Cᵢ，同幀投影）
  ∧ 結構性約束（R 的分解由 MSSP 架構定義）
```

滿足其中一個或兩個約束的系統，僅構成 HBS 2.0 的**部分近似**，而非等效實作。

---

## 六、開放問題與後續發展

### 6.1 技術待解問題

**問題 A：延遲感知閾值**
T_proc 超過多少秒時，加載動畫的心理補償效果開始衰減，用戶的主觀等待感知顯著上升？此閾值因任務類型與用戶期望而異，需要 UX 實驗數據確定。當前假設：對於代碼生成任務，閾值約 8-12 秒。

**問題 B：超大輸出的原子性邊界**
當 R 的視覺尺寸超過單屏顯示容量（如 5000 行代碼跨越多個畫面），APE 的原子性定義需要擴展。候選方案：定義「分頁原子性」——每個視口單元（viewport unit）在切換時滿足 APE 約束，而非要求整個 R 在首屏可見。

**問題 C：品質驗證失敗的降級策略**
若 Phase I 重試 N 次後仍無法生成符合 Schema 的輸出，APE 應如何優雅降級？候選方案：降級至受限 SLE（顯示單一代碼組件的串流），但在 UI 層明確標示為「降級模式」。

### 6.2 EveMissLab 理論整合路線

**EML 1.5 整合**：螺旋迴圈、演化迴圈的執行狀態可作為 HBS 2.0 的即時視覺化對象。APE 框架下，迴圈的相變狀態（螺旋→演化、收斂事件）以組件形式納入 Phase II 的結晶化輸出，在 Phase IV 同步投影。

**STDPL 整合**：Phase I 的 Hidden CoT 是天然的意圖提取來源。Phase I 完成後，後端可同步調用 stdpl-gen，從 LLM 的推理鏈中提取結構化意圖記錄，與輸出代碼同步存儲。這實現了「生成即記錄」的零額外成本意圖捕捉。

**Phase-LM 整合**：若 Phase-LM 的相共振小參數架構達到可用狀態，可作為 Phase I 的本地推理引擎替代方案，消除對商業 API 的依賴，同時保持 Hidden Buffer 協議不變。

**FDRS / PCFT 可視化**：若理論框架需要可視化介面，HBS 2.0 的多組件 APE 投影機制天然支持複雜拓撲圖形的同步顯現，可作為 EveMissLab 理論視覺化的統一呈現層。

### 6.3 開源發布路線

```
當前：v0.1（概念形式化，無代碼）
  ↓ Open WebUI 魔改 Demo 完成
v1.0（Lite 版實作驗證，代碼 + 白皮書同步開源）
  ↓ Tauri 打包完成，多平台支持
v1.5（桌面 App 版，包含「神之印」UI 完整實作）
  ↓ MSSP / STDPL / EML 工具鏈整合
v2.0（完整 EveMissLab 工具鏈介面層）
  ↓ Nova 張量架構就緒
v3.0（Full 版，God's Seal 完整實作）
```

---

## 附錄 A：EveMissLab 生態定位

HBS 2.0 在 EveMissLab 工具鏈中的定位為**介面層**，連接用戶指令與底層理論工具的執行輸出：

```
MSSP（認知架構層）
  ↓ 提供輸出的 FMS/SMS/TMS 分層標準
HBS 2.0（介面投影層）
  ↓ 以 APE 呈現工具鏈的結晶化輸出
FPL（結構生成層）
  ← HBS 2.0 Phase II 的結晶化結果輸入至 FPL 編譯器
STDPL（意圖記錄層）
  ← HBS 2.0 Phase I 的 Hidden CoT 輸入至 STDPL 意圖提取
EML 1.5（執行語義層）
  ← HBS 2.0 Phase IV 可視化 EML 迴圈的執行狀態
```

HBS 2.0 不是獨立工具，而是 EveMissLab 工具鏈對外的**感知界面**：工具鏈的所有輸出，最終通過 HBS 2.0 以 APE 形式顯現給用戶。

---

## 附錄 B：關鍵術語表

| 術語 | 縮寫 | 定義 |
|------|------|------|
| 流式線性暴露 | SLE | token 串流依序暴露給用戶的輸出範式 |
| 原子投影事件 | APE | 完整結果在單一渲染幀內全量顯現的輸出原語 |
| 隱藏緩衝區 | Hidden Buffer | 後端生成到前端顯示之間的完整隔離緩衝層 |
| 首 token 延遲 | FTL | 從用戶提交指令到用戶看到第一個輸出字符的時間 |
| 全量感知延遲 | PFRL | 從用戶提交指令到用戶看到完整輸出的感知時間 |
| 結構化交付 | — | 輸出組件依 MSSP 架構分層的強制約束 |
| 認知佔位符 | — | 加載動畫在 [0, T_display) 期間替代輸出的心理補償機制 |

---

*文件版本：v0.1 — 概念形式化草稿*
*下一版本觸發條件：Open WebUI 魔改 Demo 可展示（APE 渲染實作 + Hidden Buffer 驗證）*
*作者：Neo.K（許筌崴），EveMissLab*