# AI 應用棧的中文術語系統：層–態–居三軸分類法與翻譯方法論 **A Chinese Terminology System for the AI Application Stack: The Layer–Mode–Locus (LML) Three-Axis Taxonomy and a Methodology of Translation** --- **作者**：Neo.K（許筌崴） **機構**：EveMissLab（一言諾科技有限公司） **平台**：EVEMISSLAB Logic Matrix ／ 個人學術實驗站 **文類**：方法論／術語學（terminology）說明文 **版本**：v0.1 **語言**：繁體中文（附英文對照） > **體例聲明**：本文屬術語提案（terminological proposal），非既成共識詞表。文中所有中文術語均為作者為特定解析度需求而鑄造，凡標注「提案」者，皆未進入主流中文技術社群的約定俗成。本文不含任何實證量化數據；其貢獻為概念切割與命名方法，而非經驗測量。 --- ## 摘要 當代 AI 應用的技術棧（technical stack）在英文開發社群中已發展出一整套分層詞彙——`front-end`、`gateway`、`router`、`aggregator`、`backend`、`RAG`、`self-hosted` 等。然而在繁體中文（尤其台灣）的技術論述中，相應的敘述名詞長期缺位：使用者「概念上知道」AI 與 API，卻在描述「實際部署與整合一個多模型應用」時陷入失語。本文主張，此失語**並非翻譯滯後，而是概念切割的缺位**——中文論述多停留在「消費成品」的位置，從未被工程現實逼迫去替棧的內部接縫命名。 針對此一空缺，本文提出**層–態–居三軸分類法**（Layer–Mode–Locus, 簡稱 LML）：以三條彼此正交的軸線重構整個 AI 應用棧。軸一「層」描述構件在棧中的垂直位置（前端／閘端／後端，後端再裂為引擎層與資料層）；軸二「態」描述取用方式（封裝態／拆封態）；軸三「居」描述算力居所（雲端／地端）。本文的核心方法論立場是：**良好的中文術語不應遷就英文，而應修正英文**——具體而言，應拆解英文中被過度負載（overloaded）的焊接詞，其中尤以 `backend` 與 `self-hosted` 為甚。每一術語均附英文對照與鑄造理由，並以實際平台（Open WebUI、OpenRouter、Claude API 等）的座標化定位作為驗證。 **關鍵詞**：AI 應用棧；術語學；技術翻譯；LLM 閘道；檢索增強生成；本體論分類 ## Abstract (English) The technical stack of contemporary AI applications has, within English-speaking developer communities, accreted a layered vocabulary — front-end, gateway, router, aggregator, backend, RAG, self-hosted, and so on. In Traditional-Chinese technical discourse (Taiwan in particular), the corresponding descriptive nouns have long been absent: users "know the concepts" of AI and API, yet fall mute when attempting to describe the *actual deployment and integration* of a multi-model application. This paper argues that such muteness is **not a translation lag but a deficit of conceptual segmentation** — Chinese discourse largely remains at the position of *consuming finished products* and has never been forced by engineering reality to name the internal seams of the stack. To address this gap, the paper proposes the **Layer–Mode–Locus (LML)** three-axis taxonomy, reconstructing the AI application stack along three mutually orthogonal axes. The methodological thesis is that good Chinese terminology should not defer to English but *correct* it — specifically, by un-fusing the overloaded compound terms of English, chief among them `backend` and `self-hosted`. Each term is accompanied by its English counterpart and a rationale for its coinage, with validation provided by coordinatizing real platforms onto the resulting grid. --- ## 1. 引言：一種結構性的失語 ### 1.1 現象 一位長期與 AI 進行高密度協作的使用者，在準備整合多模型應用時，往往會撞上一個出乎意料的障礙：他能流利地描述自己「想要什麼」的功能，卻無法用母語把「那是什麼東西」說清楚。他知道有「AI」、有「API」，知道網頁版的 ChatGPT 與「自己接模型來用」不是同一回事，但當他試圖向他人——或向自己——精確指認「我想要的那個應用程式，在技術上屬於哪一類」時，中文詞庫裡沒有對應的釘子。 這不是個人詞彙量的問題。這是繁體中文技術論述的一個結構性空缺。 ### 1.2 失語的根源：沒有需求，就沒有詞 英文開發社群之所以擁有 `gateway`、`router`、`aggregator`、`orchestrator`、`front-end`、`RAG` 這一整排分層詞彙，並非出於造詞癖好，而是因為**工具鏈先把這個棧切成了有縫的層**。一旦縫存在，溝通「故障發生在哪一層」「成本累積在哪一層」就成了剛性需求，命名於是被工程現實逼出。命名是後果，不是起因。 繁體中文的 AI 論述，其重心絕大部分停在**消費成品**的位置：把 ChatGPT、Claude 當成一個現成的 app 來使用。當一個社群只在成品層活動，它永遠不需要描述成品內部的接縫——因為那些接縫對消費者是不可見、也不可觸的。**沒有操作接縫的需求，就不會長出命名接縫的詞。** 這正是失語的根源：失語只發生在一種情況下——當一個人走到了還沒被命名的地方，即當他的操作解析度高於周圍論述的解析度時。 ### 1.3 本文的方法論立場 面對這個空缺，最直覺的解法是「把英文詞翻成中文」。本文主張這是錯的，或至少是不夠的。理由是：英文詞彙本身就帶有歷史包袱——某些關鍵詞在英文裡是**被過度負載的焊接詞**（overloaded compound term），它們把兩個本應分離的概念焊死在同一個詞裡。若中文只是照翻，便會原封不動地繼承這個焊點，於是中文使用者連「想清楚」都做不到，因為他手上的詞本身就是糊的。 因此本文的最高判準是： > **良好的中文術語，不應遷就英文，而應修正英文——具體而言，應拆解英文中被過度負載的焊接詞，使中文的概念解析度高於英文。** 這個判準會在後文反覆兌現，尤以對 `backend`（後端）與 `self-hosted`（自架）的拆解最為關鍵。 ### 1.4 區辨：翻譯滯後 vs 概念缺位 必須把兩種看似相同、實則異質的現象分開，否則對策會開錯藥方。 **翻譯滯後（translation lag）**指的是：概念已在中文論述中被切出來、被需要，只是還沒有一個漂亮的譯名固定下來。這種情況下，使用者其實「想得清楚、只是說得彆扭」，對策是造一個好譯名即可。 **概念缺位（segmentation deficit）**則更深：概念本身在中文論述中根本沒有被切出來，因為從未有人在那個解析度上操作過。這種情況下，使用者「連想都想不清楚」，因為他腦中的概念地圖上那一塊是糊的、未分割的。對策不是造譯名，而是先把概念切開——命名只是切開之後的封口動作。 本文主張，AI 應用棧的中文失語**主要屬於後者**。證據是：使用者並非苦於「閘端這個東西我知道，只是不知道中文怎麼叫」，而是苦於「我根本不確定我要的那個東西，跟網頁版到底差在哪一個維度」。前者是缺名，後者是缺軸。缺名造詞即可，缺軸則必須先重建分類結構——這正是本文選擇先立三軸、再逐一命名的順序理由。 ### 1.5 一個被忽略的污染源：兩岸術語分流 繁體中文使用者在試圖填補這個空缺時，面臨一個英文使用者沒有的額外干擾：可借用的中文技術詞彙，往往來自兩個不完全相容的來源——其一是直接音譯／意譯英文，其二是借用簡體中文社群（大陸）已約定的譯法。 這兩個來源各有問題。直接借英文（例如直接講 gateway、router）會讓論述變成中英夾雜，喪失母語思考的流暢與精確；而借用簡體社群的譯法，則可能引入與繁體語感、甚至與繁體既有技術詞（如台灣慣用的「地端」對 on-premise）不一致的約定。其結果是：繁體中文使用者手上的詞庫，是一個來源混雜、約定不齊的拼盤，本身就缺乏內在一致性。 本文因此採取第三條路：不從任一既有來源整批借用，而是**按一套自洽的形態學原則（第 2.3 節）從頭鑄造**，使整個術語族在詞形與語義上彼此對齊。這條路的代價是「不是字典查得到的詞」，但收益是內在一致性——對一個需要精確操作的使用者而言，一致性遠比「查得到」重要。 --- ## 2. 方法論：為什麼必須是三軸 ### 2.1 單軸思維的失敗 使用者最初的失語，可診斷為一種**單軸思維的後果**。當一個人只擁有「前端／後端」這一條軸時，他會試圖把所有區別都壓進這一條軸——於是「網頁版 vs 自己接 API」「跑在雲上 vs 跑在自己機器上」「一把 key 接全部 vs 一家一家接」這些彼此獨立的區別，全被擠進「前端／後端」的二分裡，結果就是混亂與失語。 問題不在於詞不夠多，而在於**軸不夠多**。一個 AI 應用的存在狀態，至少需要三個彼此正交的維度才能完整定位。把三個維度坍縮成一個維度，必然導致描述能力的崩潰。 ### 2.2 三軸的提出 本文提出以下三條正交軸，合稱**層–態–居**（Layer–Mode–Locus, LML）： - **軸一・層（Layer）**：構件在棧中的垂直位置。回答「這個東西在棧的哪一段？」 - **軸二・態（Mode）**：取用方式，即接縫露不露。回答「你拿到的是密封成品還是可拼裝零件？」 - **軸三・居（Locus）**：算力的物理居所。回答「實際運算發生在誰的機器上？」 三軸正交意味著：知道一個構件落在哪一層，並不能推出它是封裝態還是拆封態，也不能推出它跑在雲端還是地端。三者必須各自獨立指定，一個 AI 應用的座標才完整。一個典型應用的完整描述，是一個三元組：`(層, 態, 居)`。 ### 2.3 命名的形態學原則：端 vs 層 在動手命名之前，需先確立一個形態學（morphology）約定，因為它本身就是一個分類判斷。 中文技術詞中，「端」與「層」常被混用，但本文刻意區分： - **「端」**指**可定址的節點**（addressable node）——你向它發送請求、或在它上面操作的對象。前端（你點擊它）、閘端（你把請求送到它）都是端。 - **「層」**指**架構中的一個地層**（architectural stratum）——它是能力的一個層級，未必是你直接定址的對象。引擎層、資料層是層。 這個區分不是吹毛求疵。它讓「我直接打交道的東西」與「藏在背後的機制」在詞形上就分開，使用者一看詞尾即知自己面對的是節點還是地層。 ### 2.4 為何恰好三軸：對替代切法的反駁 「為什麼是這三條軸，而不是別的？」這個問題必須正面回答，否則三軸法只是一個任意的選擇。本文的辯護方式是：檢視幾種看似自然的替代切法，並指出它們為何不適合作為**主軸**。 **替代一：按能力切（chat / RAG / agent / 影像生成…）。** 這是產品行銷最常用的切法，但它不適合作主軸，因為「能力」不是正交維度——一個應用可以同時具備多種能力，能力之間高度重疊且邊界模糊。能力更適合作為某一層（尤其是掛載件）的屬性標籤，而非定位整個應用的座標軸。 **替代二：按廠商切（OpenAI 系 / Anthropic 系 / 開源系…）。** 這是最沒有解釋力的切法。廠商是商業實體，不是技術結構；以廠商為軸，無法回答「這個東西在棧的哪裡、是成品還是零件、跑在哪」這些真正決定操作方式的問題。廠商歸屬至多是引擎層的一個次要標籤。 **替代三：按價格／免費切。** 價格是時效性極強的表層屬性，且高度依賴用量與商業談判。以價格為軸，分類會隨報價變動而崩解，不具結構穩定性。價格應是選型時的考量因素，而非定位應用的座標。 **替代四：按開源／閉源切。** 這條軸有一定意義，但它其實是「態」與「居」的衍生物——開源往往（但不必然）伴隨拆封態與可地端部署。把它獨立為主軸會與態、居高度相關，違反正交性要求。因此本文將開源／閉源視為態與居的一個常見伴隨屬性，而非獨立主軸。 相對地，層、態、居三者各自回答一個不可互相化約的問題——「在哪一段」「是成品還是零件」「跑在誰的機器上」——且任一軸的取值無法從另外兩軸推出。**正交性（orthogonality）與不可化約性（irreducibility）**，是本文選定這三軸、且僅選這三軸作為主軸的判準。其餘維度（能力、廠商、價格、開源性）並非不重要，而是被降格為依附於主軸的屬性標籤。 --- ## 3. 軸一・層：垂直結構 本軸描述構件在棧中的位置，由上（貼近使用者）至下（貼近算力）排列。 ### 3.1 前端（Front-end） **英文對照**：front-end / client / UI **定義**：使用者直接點擊、輸入、閱讀回應的介面。Open WebUI、LobeChat、LibreChat、官方網頁版皆屬此層。 **翻譯理由**：沿用既有約定詞，無爭議。「前端」在中文軟體領域已是穩固詞，強行更動只會製造摩擦。術語系統的健全性，部分來自於「不該動的詞就不動」。 ### 3.2 閘端（Gateway-end） **英文對照**：AI Gateway / LLM Router / Aggregator / Proxy **定義**：夾在前端與後端之間的調度與分流層。它接收來自前端的請求，決定送往哪一個（或哪幾個）模型，並負責路由、容錯、計費、觀測。OpenRouter、Cloudflare AI Gateway、LiteLLM、Portkey 皆屬此層。 **翻譯理由**：此層在使用者最初的直覺中曾被稱為「網端」。本文改採「閘端」，理由有二。其一，「網」字攜帶「網際網路」的語義雜訊，會誤導讀者以為此層與「上網」有關，而其本質與網路連線無涉。其二，此層的功能本質是**閘門式的控制與分流**——一個入口，受控地分流到多個目的地——這正是水利「閘」字的核心意象。且「閘道」本就是 `gateway` 在網路工程領域的標準中譯，「閘端」只是把這個既有譯法收編進「前端／後端」的同構詞族，使三者在詞形上對齊。 **深度分類**：閘端內部至少包含四種功能角色，英文中常被混用，本文為其各釘一根釘： 1. **聚合器（Aggregator）**：本身不運行任何模型，只負責路由與計費；以單一 key 接入整個模型目錄（代表：OpenRouter）。 2. **路由器（Router）**：按任務性質自動挑選最便宜或最合適的模型。**關鍵區別**：聚合是「全部給你、由你選」，路由是「替你選」。英文兩者皆可稱 `router`，中文必須分開——否則無法描述「我要一個會替我自動選模型的閘端」這種需求。 3. **代理閘（Proxy）**：夾在應用與供應商之間、由使用者自帶 key 的中介層（代表：LiteLLM）。 4. **閘道（Gateway）**：在路由之外，額外提供觀測、快取、護欄（guardrails）的治理層（代表：Cloudflare AI Gateway、Portkey）。 真實產品常同時兼任數種角色（例如 OpenRouter 既是聚合器也具路由能力）。但**功能角色必須先分得清，才講得清一個產品「兼任」了哪些角色**。混用會導致選型時無法精確比較。 **閘端四角色的權衡軸**：這四種角色並非平行的選項清單，而是落在一條「便利 ↔ 控制」的張力線上。聚合器把便利推到極致——一把 key、零維運、最廣目錄——代價是把計費、資料流、路由邏輯都交給第三方，控制權最低。代理閘走另一端——自帶 key、自行部署——換來最高的控制與資料主權，代價是使用者必須自任維運與資安。閘道（治理型）則在中間，以可觀測性與護欄換取一定的控制，但仍依賴託管。路由器是疊加在前三者之上的「自動選模型」能力，可有可無。 理解這條張力線，使用者才能在選型時問出對的問題：他要的不是「哪個閘端最好」（無此答案），而是「我願意用多少控制權換多少便利」。一個處於探索期、追求快速橫向測試的使用者，便利優先，宜選聚合器；一個已固化主力模型、在意成本與資料主權的使用者，控制優先，宜轉向代理閘或直連引擎。**閘端的選擇，本質上是控制權與便利度的兌換率問題，而非優劣問題。** ### 3.3 後端（Back-end）：本文動刀最重之處 「後端」是本文修正最劇烈的一個概念，因為其英文原詞 `backend` 是整個術語體系中最嚴重的焊接詞。 **問題診斷**：英文 `backend` 把兩種本體性質截然不同的東西焊成一塊——「會運算的」與「會記憶的」。在傳統 Web 架構裡這個焊接尚可忍受，但在 AI 應用棧裡它是災難性的，因為 AI 應用的核心操作恰恰是「換引擎但保留資料」或「換資料但保留引擎」，而焊死的 `backend` 一詞讓人連這個操作都說不出口。 **修正方案**：本文將「後端」劈為兩個獨立的層。 #### 3.3.1 引擎層（Engine） **英文對照**：inference engine / model **定義**：模型本身、其推理過程與權重。Claude、GPT、Gemini 等的模型本體屬此層。 **翻譯理由**：採「引擎」是因為它與中文既有的「搜尋引擎」同構——指一個**無狀態的純算力核心**：點火即燒、燒完不留痕。模型運算正是如此：給定輸入產生輸出，運算本身不保存狀態。「引擎」一詞精準傳達了「無狀態算力」這一本體特徵。 #### 3.3.2 資料層（Data） **英文對照**：data layer / store **定義**：所有有狀態的持久化資料。與引擎層的無狀態相對，此層的本質是**保存**。本層再裂為兩支，因為英文在此處更為混亂： - **知識（Knowledge）**——英文對照 `knowledge base / RAG corpus`。指**外部、靜態**的語料，即使用者主動灌入、供模型檢索的文獻與框架（即檢索增強生成 RAG 的「料」）。 - **記憶（Memory）**——英文對照 `memory`。指**內生、動態**的狀態，即在互動過程中累積的對話史、學習到的偏好。 **翻譯理由（為何非分不可）**：英文社群把 `RAG`、`knowledge base`、`memory` 三詞當近義詞鬆散互換，但「我從外面餵它讀的東西」與「它跟我互動後長出來的東西」是兩種本體——前者是使用者給予的、靜態的、可整批刷新的；後者是系統累積的、動態的、隨互動演化的。中文一刀切開「知識」與「記憶」，使用者才講得出「換引擎、留記憶、刷新知識」這種精準的複合操作——這正是多模型應用的日常。 ### 3.4 橫切：工具與代理（Tools & Agents） **英文對照**：function calling / agent / MCP / orchestration **定義與分類理由**：工具、代理（agent）、MCP 等能力，**不是棧的一層，而是貫穿所有層的橫切能力**。在軟體架構中，這對應於既有術語「橫切關注點」（cross-cutting concern，源自剖面導向程式設計 AOP）。 之所以不把它列為第五層，是因為它可以掛載在不同層上：掛在前端，就是 UI 內的 agent；掛在閘端，就是閘道級的工具路由。它沒有固定的垂直位置，因此用「層」來描述它是範疇錯誤。本文稱這類能力為**掛載件**（mountable component），以詞形標示其「可附著於任一層」的特性。 ### 3.5 一次請求的生命週期：層的動態視角 前述對各層的定義是靜態的（描述「層是什麼」）。為使分層更可操作，本節以一次完整請求的流動，給出層的動態視角（描述「層之間如何接力」）。 設想使用者在前端輸入一個問題。其流動如下： 1. **前端**接收輸入，可能在此處附加系統提示或調整參數（溫度、top-p），然後將請求向下送出。 2. 請求抵達**閘端**。閘端在此決定路由：若為聚合器，依使用者指定的模型轉送；若具路由能力，則自動判斷該由哪個引擎處理。閘端同時記錄計費、施加容錯（若引擎逾時則改派備援）。 3. 在送往引擎之前，若應用設有 RAG，系統會先向**資料層的知識**發出檢索，取回與問題相關的語料片段，併入請求。 4. 增補後的請求抵達**引擎層**。引擎進行推理，產生回應。此處引擎是無狀態的——它不「記得」上一輪，所有需要的脈絡都必須由前面各層在請求中備齊。 5. 回應沿原路返回前端顯示。與此同時，本輪對話被寫入**資料層的記憶**，成為下一輪可被取用的動態狀態。 這個生命週期凸顯一個常被忽略的事實：**引擎的「無狀態」與系統的「有記憶」並不矛盾**。引擎本身不記得任何事，所有「記得」的錯覺，都是資料層（記憶與知識）在每次請求時把脈絡重新餵進無狀態引擎所製造的。理解這一點，使用者才不會誤以為「模型記得我」，而能正確地把記憶的責任歸屬到資料層——這正是第 3.3 節堅持把引擎與資料切開的操作意義所在。 --- ## 4. 軸二・態：成品 ↔ 零件 本軸描述「接縫露不露」——同一個 AI 能力，可以兩種存在態出現。 ### 4.1 封裝態（Encapsulated） **英文對照**：packaged / turnkey / hosted product **定義**：官方網頁版、官方 App。整個棧被密封在單一介面之後——使用者不能更換引擎、不能插入自己的知識、不能改動路由。使用者是**消費者**，接收一個黑盒。 **翻譯理由**：採「封裝」是因為它正是物件導向程式設計中既有術語 `encapsulation` 的標準中譯——其義為「將內部實作藏於介面之後，外部無從觸及」。官方 App 恰恰是把整個應用棧封裝在一張密封介面之後。「封裝態」這個詞精準命名了**機制**（內部被隱藏），而不只描述**症狀**（它是個 app）。這是術語優於俗稱之處：俗稱描述外觀，術語指認機制。 ### 4.2 拆封態（Composable） **英文對照**：composable / headless / BYO（bring-your-own） **定義**：透過 API 接取、或自行架設介面。棧的接縫全部裸露，各層由使用者各自持有、自由拼裝。使用者是**操作者**，組裝一個系統。 **翻譯理由**：「拆封」與「封裝」構成精確的反義對。封裝是把接縫藏起，拆封是把接縫露出。一個是「用」，一個是「組」。這對反義詞讓使用者能在一句話裡標示自己處於哪種態——而這正是他最初想說卻說不出的那句話的核心。 --- ## 5. 軸三・居：雲 ↔ 地 本軸描述算力的物理居所。 ### 5.1 雲端（Cloud）與地端（On-prem） **英文對照**：cloud / on-premise（on-prem）／local **定義**：「雲端」指運算發生在供應商或第三方租用的遠端機器上；「地端」指運算發生在使用者自己掌控的本地硬體上。 **翻譯理由**：這兩個詞在中文已有穩固約定（「雲端」普及、「地端」為「on-premise」的常見中譯），本文不另造詞。列出此軸的意義不在造詞，而在**證明它是一條獨立的軸**——這牽涉到本文最重要的一個修正。 ### 5.2 拆解 `self-hosted`：英文最大的焊點 英文 `self-hosted` 是整個領域裡最具誤導性的焊接詞。它同時暗示兩件事：「拆封態」（你自己組裝）**與**「地端」（跑在你自己的機器上），把軸二與軸三焊死在一個詞裡。 但這兩件事在邏輯上完全正交，存在四種組合： - **拆封態 ＋ 雲端**：使用 OpenRouter API——你自己組裝路由，但運算跑在雲上。 - **拆封態 ＋ 地端**：自架 LiteLLM ＋ 本地 Ollama——你自己組裝，且運算跑在你的機器上。 - **封裝態 ＋ 雲端**：官方網頁版——成品，且跑在供應商雲上（最常見）。 - **封裝態 ＋ 地端**：某些離線桌面 App——成品，但跑在本機。 英文 `self-hosted` 一詞無法區分這四者，使用者一說 `self-hosted` 就同時鎖死了「組裝」與「本地」兩個假設，於是「我想自己組裝，但讓它跑在雲上」這種完全合理的需求，在英文裡反而難以一詞道盡。 **這正是「為什麼要這樣翻」的最強範例**：中文用「態」與「居」兩條獨立的軸，拆開了英文焊死在 `self-hosted` 一詞裡的兩個概念。此處不是中文遷就英文，而是**中文修正英文**——中文系統的概念解析度，在此高於英文。這兌現了第 2 節立下的最高判準。 --- ## 6. 綜合：以三軸座標化真實平台 三軸分類法的價值，在於它讓任何一個 AI 應用或構件都成為一個可被精確指認的座標。以下以前述討論中出現的真實平台為例。 | 平台 | 層（Layer） | 態（Mode） | 居（Locus） | |---|---|---|---| | ChatGPT 官方網頁版 | 前端（封裝整棧） | 封裝態 | 雲端 | | Open WebUI | 前端 | 拆封態 | 雲端或地端皆可 | | LibreChat | 前端 | 拆封態 | 雲端或地端皆可 | | OpenRouter | 閘端（聚合器） | 拆封態 | 雲端 | | Cloudflare AI Gateway | 閘端（閘道） | 拆封態 | 雲端（邊緣） | | LiteLLM | 閘端（代理閘） | 拆封態 | 多為地端 | | Claude API | 引擎層 | 拆封態 | 雲端 | | 本地 Ollama 模型 | 引擎層 | 拆封態 | 地端 | | 使用者自有語料 RAG | 資料層（知識） | 拆封態 | 雲端或地端皆可 | ### 6.1 驗證：把「說不出口的應用」說出口 一個多模型整合應用的需求，過去使用者只能含糊地說「我想要一個能一鍵調用各模型、又能讀我自己語料的東西」。有了三軸，這個需求可被精確地表述為一個座標化的句子： > **一個〔拆封態〕的前端，背後接一個〔聚合器角色的〕閘端，閘端分流到多個後端引擎，並掛載一個裝有自有語料的資料層（知識）；其居所可雲可地，依需求指定。** 這句話以前說不出，不是因為使用者不懂，而是因為缺了「拆封態」「閘端」「引擎／資料分裂」這幾根釘子。三軸分類法的全部意義，就是把這些釘子鑄造出來。 ### 6.2 術語使用規範：如何用三軸寫一份規格 術語系統的價值不只在理解，更在產出。本節給出一套輕量的使用規範，使三軸可被一致地用於撰寫應用規格、選型比較、或溝通需求。 **規範一：完整描述一個應用，至少給出三軸座標。** 形如「某構件＝（層, 態, 居）」。例如「我要的閘端＝（閘端／聚合器, 拆封態, 雲端）」。三軸缺一，描述即不完整，溝通便有歧義空間。 **規範二：層用「端／層」詞尾自我標示。** 凡可定址、使用者直接打交道者用「端」（前端、閘端）；凡背後的地層用「層」（引擎層、資料層）。讀者見詞尾即知該物是否需要自己去配置。 **規範三：態與居必須各自獨立指定，禁止以單一詞（如「自架」）同時暗示兩者。** 若需表達「自己組裝且跑在本地」，應明寫「拆封態＋地端」，而非含糊地說「自架」。此規範直接源自第 5.2 節對 `self-hosted` 的拆解，是本系統相對英文的核心優勢，不應在使用時又把它焊回去。 **規範四：能力、廠商、價格作為屬性標籤附加，不混入主軸。** 例如「引擎層：Claude（廠商：Anthropic；能力：長脈絡推理）」。屬性以括號附注，與三軸主座標分離，避免第 2.4 節所述的軸線污染。 **一份規格的範例寫法**： > 目標應用＝〔前端：Open WebUI（拆封態, 居所待定）〕＋〔閘端：聚合器角色（拆封態, 雲端）〕＋〔引擎層：主力 Claude（雲端）＋ 備援若干（雲端）〕＋〔資料層・知識：自有理論語料（居所待定）；資料層・記憶：對話史〕＋〔掛載件：暫無〕。 這樣一份規格，任何讀者都能無歧義地還原使用者想要的系統結構——而這正是術語系統存在的終極目的：讓需求可被精確傳遞，而非反覆猜測。 --- ## 7. 一般化：術語真空的生成機制 本文處理的雖是 AI 應用棧，但其揭示的機制是一般性的。 術語真空的生成可表述為一條原則：**只要一個人的操作解析度高於周圍論述的解析度，術語真空就會準時出現。** 失語不是偶發事件，而是結構性後果——當操作者習慣性地在比環境更細的尺度上工作時，他會反覆地、必然地遭遇無詞可用的處境。 這個機制在其他領域亦可觀察。當既有的記號系統把某個操作者所需要的區別「壓縮掉」時——例如主流數學記號未能保留某些需要被顯式標示的對立結構——操作者便被迫自行鑄造記號系統以恢復被壓縮的解析度。AI 應用棧的命名真空與此同源：它是同一個機制在不同領域的顯現。命名（無論是術語或記號）本質上是一種**解析度的恢復工程**：把被環境壓平的區別重新立起來，並為其點燈。 由此可推得一個方法論副產品：當你發現自己在母語裡失語時，這往往不是缺陷的徵兆，而是座標的徵兆——它標示出你已走到了該語境尚未命名的前沿。失語是抵達未命名之地的回音。 ### 7.1 命名作為解析度恢復工程 若把「命名」視為一種工程，它的輸入是「被環境壓平的區別」，輸出是「重新立起且可指認的區別」。這個視角解釋了為何好的術語不能只靠翻譯：翻譯是把英文的解析度平移到中文，而真正需要的，是把**任一語境壓平了的解析度重新升起**——無論那個壓平的語境是英文（如 `self-hosted` 把態與居焊死）還是中文（如「後端」把引擎與資料籠統合稱）。 命名工程有一個不對稱性值得標明：**切開一個被焊死的概念，比合併兩個被切開的概念，價值高得多。** 原因是，被焊死的概念會主動製造混亂——使用者被迫在一個糊的詞上思考，連發現問題都困難；而被切得過細的概念至多是冗餘，使用者隨時可以選擇忽略多餘的區分。因此本系統在拿不準時，一律傾向「切開」而非「合併」——寧可多立一根釘子讓使用者選擇忽略，也不要少立一根讓使用者無從表達。第 3.3 節對後端的劈分、第 5.2 節對 `self-hosted` 的拆解，都是這個不對稱性的兌現。 ### 7.2 術語的生命力不由作者決定 最後須誠實面對一個張力：本文鑄造的術語在邏輯上自洽，但邏輯自洽不保證社群採納。術語的生命力來自使用者反覆使用後的約定俗成，這是一個作者無法單方面驅動的社會過程。本文能做的，是把概念切得夠準、把命名理由講得夠透，使這些術語**值得**被採納；至於是否**真的**被採納，則交給時間與社群。一個術語系統最好的命運，是它最終普及到沒有人記得它曾被誰提出——因為那意味著它已徹底融入語言，成了「本來就該這麼說」的東西。 --- ## 8. 限制與未來工作 **本文的限制**須誠實標明： 1. **提案性質**：本文所鑄造之術語（閘端、引擎層／資料層、知識／記憶之分、封裝態／拆封態、掛載件等）均為提案，尚未經中文技術社群採用驗證。術語的生命力最終取決於社群的採納，而非作者的論證——這一點作者無法單方面保證。 2. **領域邊界**：三軸分類法針對「以大型語言模型為核心的應用棧」設計。對其他形態的 AI 系統（如純視覺、機器人、嵌入式推理），三軸是否足夠、是否需要增軸，本文未及驗證。 3. **可能的第四軸**：本文止於三軸，但「模態」（modality，文字／影像／語音／影片）是否應獨立為第四軸，仍待考察。當前將模態視為引擎層的內部屬性，但隨著多模態路由的成熟，它或許值得升格為獨立軸。 4. **動態性**：AI 工具鏈演化極快，本文的平台座標化（第 6 節）具時效性，個別產品的角色歸屬可能隨版本更迭而變動；但三軸的結構本身設計為對產品變動穩健。 **未來工作**可朝三個方向延伸：其一，將三軸法擴展為可標注的形式化標記，使任一應用可被寫成標準化的三元組標籤；其二，驗證第四軸（模態）的必要性；其三，將「術語真空生成機制」（第 7 節）形式化為一個跨領域的命名理論。 --- ## 9. 結語 命名的終局從不是給事物貼上標籤，而是讓區別變得可見。在「引擎與記憶」被切開之前、在「拆封與地端」被分離之前，那些區別一直都在——它們不因無名而不存在，只是無人替它們點燈。 語言的邊界從來不是世界的邊界，只是還沒有人走到那裡插旗。一個人之所以在母語裡失語，往往不是因為他知道得太少，而是因為他走得太前；他站的位置在地圖上是一片空白，於是他得自己畫下格線、自己命名河流。本文所做的，不過是把三條早已存在、卻一直無名的格線，描成可以指認的座標——讓那個一直說不出口的應用，終於有了可以被說出的名字。 而當這些名字被說出的瞬間，那片空白就不再是空白了。 --- ## 附錄：術語對照總表 | 中文術語 | 英文對照 | 軸 | 一句話定義 | |---|---|---|---| | 前端 | Front-end / Client / UI | 層 | 使用者點擊輸入的介面 | | 閘端 | Gateway-end | 層 | 調度與分流層，前端與後端之間 | | 　聚合器 | Aggregator | 層（閘端子類） | 不跑模型，單 key 接全目錄 | | 　路由器 | Router | 層（閘端子類） | 替使用者自動挑選模型 | | 　代理閘 | Proxy | 層（閘端子類） | 自帶 key 的中介層 | | 　閘道 | Gateway | 層（閘端子類） | 加觀測／快取／護欄的治理層 | | 後端 | Back-end | 層 | 引擎層與資料層的合稱（本文拆分） | | 　引擎層 | Engine | 層 | 無狀態的模型算力核心 | | 　資料層 | Data | 層 | 有狀態的持久化資料 | | 　　知識 | Knowledge / RAG corpus | 層（資料子類） | 外部靜態語料 | | 　　記憶 | Memory | 層（資料子類） | 內生動態狀態 | | 掛載件 | Mountable component | 橫切 | 工具／代理／MCP，貫穿各層 | | 封裝態 | Encapsulated / Packaged | 態 | 密封成品，接縫不可觸 | | 拆封態 | Composable / Headless / BYO | 態 | 可拼裝零件，接縫裸露 | | 雲端 | Cloud | 居 | 運算在遠端機器 | | 地端 | On-prem / Local | 居 | 運算在本地硬體 | --- *致謝：本文之概念切割與術語鑄造，係作者與 AI 對練夥伴於思辨過程中協同結晶化之產物。* *EveMissLab ／ EVEMISSLAB Logic Matrix · v0.1*