結論

當底層 engine（search engine、LLM、DB、compiler、framework）沒開放某能力的客製 API、不該硬改 engine 內部、改在 engine 的輸入層 / 外層做 transformation：

核心原則：engine 不開放 = 不要硬改 engine、改改你給 engine 的輸入。

為什麼移到外層是合理 escape

直覺反應遇到 engine 限制是「fork engine」「升級到能調的 engine」「換 engine」 — 但這三條都成本爆炸：

• Fork engine：維護 fork 成本（merge upstream changes、bug fix back-port）
• 升級：可能需要等好幾版、可能 breaking change、可能根本沒得升
• 換 engine：data migration、API 重寫、config 重學

外層 transformation 跳過這三條：

• 不動 engine 內部
• 用 engine 既有的合法 API（input、metadata、wrapper）
• 升級 engine 時 transformation 通常仍兼容
• 換 engine 時也常能直接搬

代價：

• 多一層 indirection
• 需要維護 transformation 邏輯
• 可能有 leak（transformation 不完美、edge case 露出 engine 限制）

通常代價遠小於三條「動 engine」路線。

五個跨領域實例

1. Search：suffix token injection

Pagefind / 多數 build-time search engine 只 prefix match。要支援 substring，build-time emit 額外 hidden tokens：

1<!-- 原文 -->
2<p>backpressure handling</p>
3<!-- transformation 後 -->
4<p>backpressure handling</p>
5<span hidden>pressure handling</span>

grep "pre" → matches pressure prefix → finds page。

2. LLM：prompt-level chain-of-thought

LLM 不會自動 CoT。在 prompt 層加：

1請先列出已知資訊、然後推理步驟、最後給出結論。

Engine 沒變、輸入變了、行為變了。

3. DB：denormalized columns

PostgreSQL JSON column query 慢、但:

1ALTER TABLE events ADD COLUMN user_id_extracted UUID
2  GENERATED ALWAYS AS (data->>'user_id') STORED;
3CREATE INDEX ON events(user_id_extracted);

Engine 沒變、schema 加了 generated column、query 走 index、變快。

4. Compiler：source-level macros

C 語言沒泛型、用 #define macro 模擬：

1#define SWAP(a, b, T) do { T tmp = a; a = b; b = tmp; } while(0)

Compiler 沒變、source 經 preprocessor transformation、行為變了。

5. Framework：wrapper component

React 沒 onAttach lifecycle、用 wrapper:

1function withMount(Component) {
2  return (props) => {
3    useEffect(() => { props.onMount?.(); }, []);
4    return <Component {...props} />;
5  };
6}

React 沒變、加一層 wrapper、行為加上了。

Input 跟 Output transformation 是不同 pattern

外層 transformation 不是單一 pattern、要區分 input transformation（改 engine 看到的）跟 output transformation（改 engine 給出的）：

例對照

Search：

• Input：build-time 加 suffix tokens（engine 索引時看到 hidden “pressure”）
• Output：result 出來後 client-side substring scan（engine 結果照常、額外加 fallback）

LLM：

• Input：prompt 加 “請逐步推理”（engine 看到不同 prompt）
• Output：parse output 後 extract structured data（engine 輸出照常、後處理）

DB：

• Input：generated column（engine 索引時看到 denormalized column）
• Output：query 結果後處理 / aggregation（engine 結果照常、應用層加工）

何時選哪個

多數實作 case 兩者疊加：input 解 80%（更徹底）、output 補剩下 20%（catch input 漏的）。

何時不該用外層 transformation

五類共通：transformation 的成本 / 風險 > 動 engine 的成本。其他情境外層 transformation 是首選。

跟 #45 外部組件合作四層的關係

#45 講「離公共介面越近越穩」、本卡是這條原則的具體展開：

外層 transformation 是邊界層的具體技法 — 在 engine 公共介面外、做 input / output transformation。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：Engine 限制不等於 capability 限制 — engine 沒開放的能力、通常可在 engine 的輸入 / 輸出層做 transformation 補上。「engine 不支援」是表象、「我沒思考外層解」是根因。