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