Stan Wu 吳信典

用高階模型設計 Skill，讓 GPT-4.1 穩定執行：Copilot Token 節省策略

Tue, 14 Apr 2026 00:02:00 +0800

GitHub Copilot 的 GPT-4.1 是吃到飽方案，但模型本身相對保守，遇到複雜任務容易輸出不穩定。

解法不是換模型，而是換策略：用聰明的模型把工作定義清楚，讓便宜的模型負責執行。

問題的本質

在 AI 工具的日常使用裡，有兩件事常常被混在一起：

思考這件事該怎麼做
照著計畫把事情做完

高階模型（Claude Sonnet 4.6、GPT-4o 等）在「思考」上很強，但 token 有成本。GPT-4.1 在 Copilot 裡是吃到飽，適合「執行」，但如果讓它自己思考怎麼做，品質容易漂移。

這個觀察直接指向一個架構：把思考和執行分層。

策略核心：Skill 是智力的容器

Skill 本質上是一份「執行說明書」：告訴模型這個任務的目標是什麼、輸出格式長什麼樣、遇到邊界情況怎麼處理。

當 skill 設計得夠好，GPT-4.1 的工作就從「想清楚再做」變成「照著做」。這個轉換非常關鍵，因為模型能力的差距，在格式遵循和結構輸出上遠比在自由推理上小。

高階模型（Claude Sonnet 4.6）
 → 設計 skill：定義輸出格式、邊界條件、fallback 邏輯
 → 產出：可重複使用的 skill 文件

GPT-4.1（Copilot 吃到飽）
 → 照 skill 執行：填入、套用、輸出
 → 產出：穩定、符合格式的結果

設計一次，執行百次。智力成本集中在設計端，執行端的 token 消耗幾乎是免費的。

一個具體範例

假設你需要每天做 code review 摘要，格式固定：問題分類、嚴重程度、建議改法。

讓 GPT-4.1 自己跑（沒有 skill）

輸出會長這樣——每次都不同：

這段程式碼有幾個問題需要注意。首先…（自由發揮三段）

格式不固定，無法批次處理，每次都要重新審閱。

讓 Claude 先設計 skill

## Code Review 摘要 Skill

**輸入**：一段程式碼或 diff

**輸出格式**（嚴格遵循）：
- 每個問題獨立一條
- 格式：`[嚴重度: HIGH/MED/LOW] 問題描述 → 建議改法`
- 嚴重度定義：
 - HIGH = 安全漏洞、資料遺失風險
 - MED = 邏輯錯誤、效能問題
 - LOW = 風格、可讀性
- 沒有問題時輸出：`✓ 無發現問題`
- 禁止加前言、後語、摘要段落

交給 GPT-4.1 執行

輸出變成：

[HIGH] SQL query 未參數化，存在注入風險 → 改用 prepared statement
[MED] 迴圈內重複呼叫 DB，N+1 問題 → 改用 batch query
[LOW] 變數命名不一致（camelCase vs snake_case）→ 統一為 snake_case

穩定、可解析、可自動化處理。GPT-4.1 沒有變聰明，只是工作被定義清楚了。

Skill 設計的幾個關鍵原則

一、輸出格式要「防呆」

越少解釋空間越好。與其說「用條列方式呈現」，不如直接給模板：

好的：`格式：[{嚴重度}] {問題} → {建議}`
不好的：`請條列出問題和建議`

二、把邊界條件寫進去

GPT-4.1 遇到 edge case 最容易偏離格式。與其事後修正，不如在 skill 裡預先定義：

沒有輸入時怎麼處理
遇到不確定時輸出什麼
哪些情況輸出空值而非猜測

三、明確禁止多餘輸出

語言模型天生喜歡加前言和總結。要在 skill 裡明確說：

禁止加「以下是分析結果：」之類的前言。禁止在結尾加摘要。直接輸出結果。

四、用範例而非描述

一個具體的輸出範例，比三段文字描述更有效。Claude 在設計 skill 時，可以幫你產生幾個 few-shot 範例，附在 skill 裡給 GPT-4.1 參考。

哪些任務適合這個策略

這個分層架構在格式明確、重複性高的任務上效果最好：

適合	不太適合
程式碼生成（固定模板）	開放式創意發散
文件整理、摘要	需要即時推理的除錯
結構化資料提取	高度 context-aware 的一次性任務
固定流程的 code review	需要跨多個 context 推理
批次重複作業	第一次設計 skill 本身

判斷方法很簡單：如果這件事你可以寫成 SOP，就適合做成 skill 交給 GPT-4.1。如果需要即興判斷，就留給高階模型。

如何驗證 skill 設計是否有效

Skill 設計完，讓 GPT-4.1 跑三到五次同類任務。觀察：

格式一致性：關鍵欄位每次都在嗎？
長度穩定性：輸出長度有沒有大幅波動？
邊界行為：空輸入、異常輸入有沒有按 skill 定義處理？

如果通過，skill 設計就算過關。如果 GPT-4.1 每次都在「自由發揮」，通常是 skill 留了太多解釋空間，回頭讓 Claude 再修一次。

成本結構的轉換

這個策略本質上是改變了 AI 工具的成本結構：

舊模式：每次任務都讓高階模型從頭思考 → 每次都花高階模型 token，成本線性增長

新模式：高階模型投資在 skill 設計，GPT-4.1 負責執行 → 設計成本一次性，執行成本趨近零（Copilot 吃到飽）

越是重複性高的工作，這個策略的 ROI 越高。第一次做 skill 的 token 成本，會在第十次執行時回本。

這個思路其實不算新——工程師很熟悉「框架 vs 業務邏輯」的分工。框架由架構師設計，工程師照框架寫業務邏輯。現在只是把同樣的概念，用在 AI 模型的分工上。

設計一次好的 skill，比每次讓 AI 猜你要什麼，省事得多。

從文言文到 AST：AI Agent Memory 語義壓縮的可行性分析

Tue, 14 Apr 2026 00:01:00 +0800

古代人刻竹簡、抄手稿，每個字的儲存成本都極高。這個物理限制直接塑造了文言文的語言風格——用最少的字，傳遞最密集的語意。

這不只是文化，是工程決策。

當我開始思考 AI agent 的 memory 管理問題，這個古老的邏輯突然變得非常現代。

文言文是一種有損壓縮格式

從資訊理論的角度看，文言文是一套高壓縮比、高解碼成本的編碼系統。

竹簡有重量，有體積，刻寫需要工時。這些都是實體成本。當儲存成本極高時，語言會朝向低熵方向演化：

虛詞能省則省
語境依賴極重（解碼需要大量背景知識）
歧義換取密度（讀者端承擔解壓縮負擔）

對比白話文：

	文言文	白話文
壓縮率	高	低
自解釋性	低（需訓詁）	高
儲存成本	低	高
解碼門檻	高	低

有趣的是，活版印刷大幅降低了複製成本，照理說語言應該走向白話——但文言文仍然主導書面世界數百年。因為寫作者的習慣與社會認可機制的慣性，遠比技術變革的速度慢。

白話文運動最終發生，更多是政治與教育普及的需求，而非技術成本。

這個觀察本身就是一個警示：即使最優解存在，系統切換的成本可能讓它長期無法落地。

Token 是現代的竹簡

AI agent 每次被呼叫，都需要把 memory 塞進 context window。Token 是直接成本：計費、速度、context 容量，都和 token 數量正相關。

現有的 memory 格式大多長這樣：

memory 範例：prose 格式

name: 回應風格偏好 type: feedback

使用者偏好簡潔回應，不喜歡在結尾加摘要總結。 Why: 他說他可以自己讀 diff，不需要 AI 重複說明已完成的事。 How to apply: 每次回應結尾不要加「以上是本次修改的摘要」之類的段落。

這是白話文。結構清晰，人讀得懂，但對機器來說充滿冗餘。

如果我們用文言文的邏輯重新設計：

no-trailing-summary; trigger=response_end; reason=user_reads_diff

同樣的語意，token 省了 70% 以上。

關鍵洞察：memory 的唯一讀者是 AI agent

這裡有一個根本性的問題值得釐清：

memory 是為誰而寫的？

傳統 memory 設計預設「人需要能讀懂」，所以用完整句子、加 Why 說明、保留上下文。但仔細想，memory 的實際讀者是 agent 本身。人審查 memory 是偶發需求，不是主流路徑。

這意味著：

human-readable 在大多數情境下是偽需求
壓縮的唯一硬性約束是：agent 能 100% decode
其餘的可讀性成本，都是在為一個低頻需求買單

這個邏輯和 LLM embedding 是一樣的：向量記憶體對人完全不可讀，但 agent 的 retrieve 語意還原率反而更高。文字 memory 之所以還在用，是因為人需要 audit 能力，而不是因為它對機器更好。

從 AST 借鑑結構化表示

這時候自然會想到 AST（Abstract Syntax Tree，抽象語法樹）。

在編譯器領域，AST 是把原始碼轉成**結構化中間表示（IR）**的標準手法。原始碼是給人讀的（高冗餘），AST 是給編譯器處理的（結構化、可操作）。

把這個概念移植到 memory：

flowchart TD
 A["自然語言 memory（原始碼）"] -->|encode| B["AST memory node（IR）"]
 B -->|retrieve + decode| C["agent 行為"]

具體長這樣：

{
 "type": "behavior_rule",
 "trigger": { "context": "response_end" },
 "action": { "suppress": "summary" },
 "condition": { "user_action": "reads_diff" },
 "confidence": 0.95,
 "raw": "user reads diff directly, finds summaries redundant"
}

AST 相對於 prose memory 的優勢

可 diff：兩條 rule 衝突時，agent 比較節點而非解析自然語言，衝突偵測可以程式化。

可 merge：新 observation 進來時，patch 特定節點而非整段重寫，incremental update 成本低。

可 query：trigger.context == "response_end" 精確 retrieve，不依賴語義相似度，查詢結果確定。

可繼承：子節點 override 父節點，類似 CSS cascade，可以做 context-specific 的行為覆寫。

可版本化：節點帶 schema version，memory 格式演化時可以做 migration 而非全部重寫。

這個設計的根本張力

AST 設計看起來很美，但有一個繞不開的核心問題：

張力一：固定 schema vs 表達彈性

程式語言的 AST 有嚴格 grammar，語義確定。Memory 的 schema 需要人工設計，而觀察的種類是開放的——你無法預先定義所有可能的 node type。

Fixed ontology：查詢效率高，但遇到 schema 外的觀察無處放
Emergent schema：表達彈性高，但查詢一致性差

這是一個目前沒有標準答案的開放問題。

張力二：壓縮率 vs decode 完整性

文言文的問題是「解壓縮密鑰丟失後語義崩潰」。過度壓縮的 memory：

換模型或換 session 可能 decode 失敗
Edge case 無法判斷適用性
encode 錯誤無聲無息傳播

最優解不是最大壓縮，而是「剛好能讓同等智力的讀者正確 decode 的最小表達」——這其實也是文言文的設計目標，只是它的「同等智力讀者」預設了四書五經作為共同解碼器。

AI agent 的「共同解碼器」是 pre-training，這個基礎是穩定的，但並非無限可靠。

張力三：auditability vs 壓縮上限

如果完全移除「人要能審查」的約束，理論上可以讓 agent 自己設計一套極度壓縮的內部語言，壓縮率可以趨近理論上限。但你同時失去了：

偵測 encode 錯誤的能力
理解 agent 行為的能力
手動修正錯誤 memory 的能力

auditability 的要求，決定了壓縮的上限。

Hybrid 格式：務實的折衷

考慮以上三個張力，純 AST 和純 prose 都不是最優解。Hybrid 格式更接近實際可落地的方向：

{
 "type": "behavior_rule",
 "trigger": "response_end",
 "action": "suppress_summary",
 "raw": "user reads diff directly, finds summaries redundant"
}

結構化 header 負責 routing 和 query，raw 欄位保留自然語言作為 decode 邊界情況的 fallback。

這類似文言文後來發展出的注疏傳統——正文高度壓縮，注疏提供解碼上下文，兩者合讀才是完整資訊。

Python 作為統一引擎

如果要實作這個 memory 系統，Python 是自然的選擇。

更進一步，可以設計單一引擎、雙介面的架構：

memory_engine.py
├── CLI interface ← Bash tool 直接呼叫
│ python memory_engine.py encode "..."
│ python memory_engine.py query "response_end"
│ python memory_engine.py merge <node_id>
│ python memory_engine.py audit
│
└── Skill interface ← agent 透過 prompt 觸發
 複合操作、判斷 subcommand、串接多個操作

同一份邏輯，兩個 entry point，DRY 原則。

if __name__ == "__main__":
 parser = argparse.ArgumentParser()
 parser.add_argument("command", choices=["encode","query","merge","audit"])
 parser.add_argument("input", nargs="?")
 args = parser.parse_args()
 result = globals()[args.command](args.input)
 print(json.dumps(result, ensure_ascii=False))

encode 時需要 LLM 做語義解析，這裡有一個設計選擇：由 Python 內部發 API call，還是由 agent 自己解析後把結果傳給 script？前者讓引擎更自治，後者讓引擎更確定性。這個選擇影響整個依賴架構，值得獨立討論。

可行性小結

面向	結論
基本邏輯	成立。memory 本來就是給 agent 讀的，改成更結構化、更省 token 的格式是合理方向
實作難度	可控。LLM 已經能穩定輸出 structured output，Python 也足夠處理 encode、query、merge、audit
主要風險	encode 錯誤傳播、schema 太硬、壓得太短導致 agent decode 失敗
需要取捨的地方	壓縮率、可讀性、可審查性三者不可能同時最大化
可參考方向	MemGPT、Knowledge Graph + LLM、Minimum Description Length（MDL）

核心結論：方向可行，但不適合一開始就追求極限壓縮。比較務實的做法，是先用 hybrid 格式保留必要上下文，再逐步把穩定、重複出現的 memory 壓成結構化節點。

後記

文言文撐了兩千年，不是因為它最好讀，而是因為它在當時的成本結構下是最優解。當成本結構改變（印刷術、白話文運動），語言才真正轉型。

AI memory 目前的「白話文」格式，是在 context window 相對充裕、token 成本可接受的前提下成立的。當 agent 開始大規模運作、memory 數量指數成長，成本結構會變，最優解也會跟著變。

現在思考壓縮，不是為了立刻重寫所有 memory，而是為了在成本結構改變的時候，不用從零開始想。