別問 Claude 能為你做什麼——Anthropic 工程師的 Vibe Coding 進 Production 心法

Anthropic 把一個 22,000 行的修改合進了他們生產環境的強化學習 codebase，而且絕大多數是 Claude 寫的。

如果你第一個反應是「哇，AI 終於可以替代工程師了」——你抓錯重點了。

這個案例的真正主角不是 Claude，是那群在 PR 合進 main 之前花了好幾天當「Claude 的 Product Manager」的人類工程師。Anthropic 工程師 Erik Schluntz 在 Code with Claude 大會上把這件事的內情講得很白：vibe coding 進 production 不是放手不管，而是一套把工程責任搬到 AI 之前的紀律。

這篇文章我想把演講精華 + 業界數據 + 真實風險案例編織起來，讓你知道：什麼時候 vibe code、什麼時候絕對不要、以及那 15 分鐘的事前準備到底在準備什麼。

vibe-coding-22000-行PR的真相

從「跟 Claude 聊天」變成「替 Claude 做 PM」

先把名詞講清楚。Vibe coding 不是「用 AI 寫程式」的同義詞。它是 OpenAI 創始成員、前 Tesla AI 總監 Andrej Karpathy 在 2025 年 2 月提出的概念——「完全沉浸在 vibe 裡，擁抱指數成長，忘記程式碼存在」。這條推文當時衝破 450 萬次瀏覽，Collins 詞典直接把它選為 2025 年度詞，連維基百科都單獨開了條目。

關鍵差別是：你打開 Cursor 或 Claude Code、看著 AI 寫一段就 review 一段、覺得不對就改——那叫 AI-assisted coding，不叫 vibe coding。Vibe coding 的精髓是你不再逐行讀程式碼，你只看「跑起來對不對」「結果合不合預期」。

Schluntz 講出整場演講最容易被忽略的金句：

「Ask not what Claude can do for you, but what you can do for Claude.」

仿甘迺迪那句名言，他想表達的是：在 vibe coding 時，你的角色是 PM，不是客戶。你不是在「使喚」Claude，你是在「設定條件讓 Claude 能成功」。

這個重新定位很重要。多數人和 AI 的互動模式是：

「幫我做這個 feature」→ AI 給一個半對的東西 → 「不對，再試一次」→ 再給一個半對 → 來回十次 → 放棄

Schluntz 說，想像一下今天有個新人來上班，第一天你只丟一句「實作這個功能」就走人，任何人類都不可能成功。新人需要 codebase 導覽、需要知道實際 requirement、需要理解約束條件。Claude 也一樣。差別只在於——這個新人不會主動問你，所以收集 context 並餵給它，是你的責任。

那關鍵的 15-20 分鐘準備時間

Schluntz 自爆他的工作流：在讓 Claude 開始寫之前，他會花 15 到 20 分鐘收集 context 進一個 prompt，然後才讓它跑。

但這 15 分鐘不是他坐著手寫 prompt。他是用另一個對話視窗跟 Claude 對話：

讓 Claude 探索 codebase、找出相關檔案
一起討論實作 plan、需要改哪些檔案、要遵循哪些既有 pattern
把整個對話的精華濃縮成一個 artifact（plan 文件 / spec 文件）
開新 context，把 artifact 餵進去，說「執行這個 plan」

這個雙窗口流程的妙處在於——研究 + 規劃 跟執行是兩個不同的認知模式，混在同一個 context 會讓兩者都變糟。Anthropic 自己的 Building Effective Agents 研究也指出，最有效的 agent 不是 prompt 寫得最聰明的那個，而是運作環境設計得最好的那個。

vibe-coding-人類PM與AI執行者

Dotzlaw Consulting 的整理把這個觀察講得很到位：「The biggest challenge in autonomous agents is designing the environment around the agent」。Vibe coding 的功夫不在 prompt，在你給 Claude 的世界。

實作 checklist：

新開一個對話做研究——不要在執行視窗裡邊開邊寫
讓 Claude 先 grep / glob / read，再讓它寫東西
規劃階段就決定 要動哪些檔案、不要動哪些
列出 既有 pattern 的範例檔案（「請參考 src/foo/bar.ts 的寫法」）
把規劃輸出成一份 plan.md，新 context 開始執行
給 Claude 一個 可執行的驗證手段（test command、stress test、output diff）

22,000 行 PR 的四個原則拆解

回到開頭那個 22,000 行案例。這是 Anthropic 內部 production 強化學習 codebase 的修改，根據 199A Consulting 的整理，原本人類工程師預估要花兩週逐行寫 + review，最後壓縮到一天內完成。

但這一天不是按一個按鈕的一天。Schluntz 列了四個原則，每個都對應一種風險控管：

原則一：集中在 Leaf Nodes（葉節點），不要動核心架構

這個策略的精神是：把可能的技術債圈在不會擴散的地方。

Codebase 結構像一棵樹。Root / 中間節點是核心架構、共用工具、抽象層——任何改動都會被千百個地方依賴，未來還要持續演進。Leaf nodes 是那些業務邏輯的末端、特定 task 的實作、不太會被別處引用的程式。

Anthropic 那個 22,000 行的 PR 大部分集中在 leaf nodes，因為這些區段「就算累積一些技術債也沒關係」——它們未來不會頻繁變動，就算之後要重寫也不會牽連別處。重要、要 extensible、會被反覆修改的部分，他們堅持做 heavy human review。

vibe-coding-葉節點與核心架構

這呼應了 SoftwareSeni 引用 DORA 2025 報告的結論：「AI is an amplifier of your development practices. Good processes get better, bad processes get worse.」AI 是放大器——好流程會被放大，壞流程也會。如果你 vibe code 的是核心抽象層，債會以指數速度爆炸；如果是葉節點，債就被框在角落。

原則二：設計人類可驗證的 Inputs / Outputs

PR 那麼大，怎麼確認對不對？答案是——不要用「讀懂程式碼」來確認。

Anthropic 團隊把整個系統設計成 inputs 和 outputs 都是人類可以一眼看懂的。這意味著：

系統邊界清楚（不是隨便插一塊邏輯到中間層）
輸入輸出有明確的 schema 和語意
可以靠黑箱測試來驗證行為，不用打開盒子看內部

這跟傳統 code review 的思維完全反過來。傳統 review 假設「我必須理解你寫的每一行才能批准」；Schluntz 的方法是「我設計一個邊界，讓我不需要讀內部就能判斷對錯」。

原則三：精心設計 Stress Tests 來保證穩定性

RL codebase 最怕的不是「跑一次對」，是「跑一萬次有沒有崩」。所以團隊先設計好壓力測試，再讓 Claude 寫實作——長時間、大量 input 的反覆驗證，遠比讀 22,000 行有效。

這個原則跟學術界對 vibe coding 的觀察方向一致——一篇 2025 年 12 月發表的 arxiv 論文在分析 flow-debt tradeoff 時指出，沒有驗證機制把關的 vibe coding 會在中期累積結構性技術債。換句話說，stress test 不只是品質保證手段，是讓 vibe code 進 production 在長期可持續的關鍵。

原則四：對重要部分做 Heavy Human Review

最後一個原則最直白：該讀的還是要讀。系統中那些「會被反覆修改、需要 extensible」的核心區塊，團隊還是逐行 review。

換句話說——這四個原則合起來形成一個選擇性審查策略（以下對照表是我整理 Schluntz 演講四原則的歸納，非原始投影片）：

區段類型	處理方式
Leaf nodes（不會頻繁變動）	Vibe code，靠驗證測試把關
Core architecture（要 extensible）	Heavy human review，逐行讀
系統邊界（I/O）	預先設計成人類可驗證
全域行為	Stress tests 跑長時間

這不是「全 vibe」也不是「全人寫」，而是根據風險動態分配審查資源。

Vibe Coding 不是給所有人的：Schluntz 的明確警告

Schluntz 在演講中講了一句很多人不愛聽的話——「我不認為完全非技術背景的人應該嘗試從零打造一個 business」。

理由很簡單：他們沒辦法問對的問題，他們做不了 Claude 的 PM，所以注定失敗。

業界的數據站在他這邊。Stack Overflow 2025 年開發者調查顯示，66% 的開發者最大的挫折是「AI 解答幾乎對但不完全對」，45% 表示 debug AI 程式比自己寫還慢，只有 16% 體驗到「巨大的生產力提升」（這個數字也被 SoftwareSeni 整理引用）。Addy Osmani 把這個現象命名為「**70% Problem **」——AI 程式看起來七成對，但要把剩下三成弄到 production-ready，常常比你自己寫還累。

而對非技術用戶來說，這 70% 是致命的。因為他們連「哪 30% 沒對」都看不出來：

2025 年 3 月的 Lovable 平台 CVE-2025-48757：根據安全研究員 Matt Palmer 的抽樣，他掃過的 1645 個 Lovable 應用裡，有 170 個（約 10.3%）存在 RLS（Row-Level Security）漏洞，未驗證攻擊者可直接讀寫資料庫。受影響欄位包括姓名、地址、債務金額、API key、付款資訊。
CVE-2025-54135（Cursor）：透過已連接的 MCP server 在開發者機器上執行任意指令。
CVE-2025-55284（Claude Code）：透過 prompt injection 經 DNS request 外洩資料。

這些漏洞不是 AI 寫程式特有的，但vibe coding 把它們大規模化——當一個開發者忽略某個安全 default，他寫一個有漏洞的 app；當一個 vibe coding 平台忽略 default，整個生態系的每個 app 都繼承這個漏洞。

所以 Schluntz 的「不適合所有人」不是菁英主義，是現實的能力門檻：

你能不能看出 Claude 提的 plan 在哪裡會破？
你能不能設計出有意義的 stress test？
你能不能判斷 leaf node 跟 core architecture 的界線？
你能不能讀懂 stack trace 並且 challenge AI 的解法？

如果上面四題你有任何一題答不出來——你還沒有準備好把 vibe code 推進 production。

別忽略指數：今天可以選擇，明年沒得選

演講的結尾，Schluntz 拋出最具殺傷力的一句：「Remember the exponential.」

METR（Model Evaluation & Threat Research）的 2025 年研究給了這句話一個量化基礎：AI agent 能獨立完成的任務長度，過去 6 年每 7 個月翻倍一次。而且 METR 在 2025 年 7 月的後續分析顯示，2024 年起這個 doubling time 還在加速到大約 每 4 個月。

vibe-coding-指數曲線警告

具象化一下這個趨勢（資料來源：AI Digest 對 METR 數據的視覺化整理）：

時間點	AI agent 能獨立完成的任務長度（50% 成功率）
2022（ChatGPT 發表）	30 秒
2025 中	約 1 小時
2026（現在）	超過 14 小時（前沿模型）
2027（線性外推）	1 個工作日（8 小時）
2028（線性外推）	1 個工作週（40 小時）
2029（線性外推）	1 個工作月（167 小時）

要先打個預防針：METR 自己也提醒，這條曲線是少數 benchmark 上的測量結果，外推到「真實工程任務」時誤差會很大，把它當成方向感而非保證值。但即便打對折——AI 一次能產出幾天的工作量，這個門檻已經夠近了。

Schluntz 的警告是這樣的：今天你還有奢侈說「我堅持每行程式都自己讀」，因為 Claude 一次能寫的還在你 review 得完的範圍。但一兩年後，當它一次產出的 diff 行數遠超你每天能讀的速度，review 工時 / 產出工時的比值會超過 1——你會變成整個團隊的瓶頸。

這不是叫你放棄 review，是叫你重新設計 review 的方式。從「逐行讀」改成「設計可驗證邊界 + stress test + 選擇性 deep review」——也就是 Anthropic 那 22,000 行 PR 的四原則。

我的實作 Checklist：把演講變成肌肉記憶

把整場演講壓縮成一張可以貼在桌上的 checklist：

動工前（5–20 分鐘）

開新對話讓 Claude 探索 codebase，不要急著寫 code
列出 要動的檔案 / 不要動的檔案
找出 2–3 個既有 pattern 範例檔案 給 Claude 模仿
寫一份 plan.md，包含 requirement、constraint、step
確認這個任務在 leaf node 還是 core architecture

執行時

新開 context，把 plan.md 餵進去
讓 Claude 跑，不要每三行就插嘴
同步準備 驗證手段（unit test、stress test、output diff）

驗收時

不靠讀程式碼就能判斷對錯——靠 I/O、靠測試、靠 stress
對 core architecture 的部分逐行 review
對 leaf node 的部分驗證行為，允許一些技術債

長期心法

別問 Claude 能為你做什麼，問你能為 Claude 做什麼
把自己當 PM，不是當客戶
記得指數曲線——你今天在練的不是 prompt，是未來幾年的工作模式

結語：vibe 的反義詞不是「嚴謹」，是「無責任」

整篇文章其實只在講一件事：vibe coding 跟工程紀律不是對立的。

被罵的 vibe coding 是那種把生意建立在「連 30% 沒對的部分都看不出來」的脆弱之上的版本。它會變成 Amplifi Labs 描述的那種累積式技術債 ——隱性架構、淺層理解、過度耦合、解釋性 debug。也會變成那 170 個 Lovable 應用——速度成功了，但用戶資料在外面飄。

而 Anthropic 22,000 行 PR 的版本是另一種——人類做 PM、leaf nodes 收斂風險、輸出設計成可驗證、stress test 把關穩定性、核心區段 heavy review。它沒有比較不 vibe，但它對得起 production 兩個字。

所以下次有人問你「vibe coding 進 prod 安不安全」，你可以反問他：

「你打算當 Claude 的 PM，還是當 Claude 的客戶？」

兩個答案決定兩種命運。

OpenRouter 2026 排行震撼解讀：為何 Kimi K2.6 取代 Claude？DeepSeek 壟斷角色扮演、Grok 攻下法律 #1 的真實原因

openrouter-llm-arena-cover

打開 OpenRouter 排行榜，我看到 2026 年 4 月的排行第一名時還是愣了一下。不是 Claude，不是 GPT，不是 Gemini——而是來自中國 Moonshot AI 的 Kimi K2.6，週吞吐量 1.36T tokens。再往下滑，前 10 名有 5 席是中國模型。GPT-5.4 連前 10 都沒擠進去。

這不是某個小眾排行的數據異常。OpenRouter 是全球最大的 LLM API 路由平台，接超過 400 個模型、60 多家供應商，每週路由 20T+ tokens——它的排行不是 benchmark 跑分，是開發者用真金白銀換來的真實使用量。

更戲劇性的是各分類前列：DeepSeek V3.2 在 Roleplay 拿下 40.2% 壟斷份額；Grok 4.1 Fast 攻下 Legal #1；Gemini 3 Flash Preview 同時稱霸 Health 與 Academia；Marketing 的 #1 是價格只有 $0.10/$0.40 的 Gemini 2.5 Flash Lite。

這篇文章會帶你看完整個排行版圖，深入解析每個分類 #1 為什麼能贏——是架構、訓練資料、定價、context window 還是別的東西讓他們勝出。文末附上一張按用例選模型的實戰建議表，2026 年該用哪個模型，看完就有答案。

OpenRouter 為何是最值得信的 LLM 排行

在開始解讀數字前，先說為什麼 OpenRouter 比 LMArena、benchmark 跑分更具參考價值。

LMArena 看的是「人類偏好」，但跑分跟真實生產用例的距離常常比想像中大。各家 benchmark 又都有過擬合風險——模型在 SWE-Bench 拿高分不代表在你的 codebase 跑得好。OpenRouter 不一樣，它的排行直接反映**「開發者願意為哪個模型持續付錢」**：使用者多用一個 token，OpenRouter 帳上多扣一塊錢，不付出真金白銀就不會出現在這份榜單上。

更重要的是，OpenRouter 的客群是真正在開發 AI 產品的人。Janitor AI（角色扮演）、Cline（編碼 agent）、OpenClaw（自動化 agent）、Roo Code、Hermes 這些被廣泛使用的工具，都在透過 OpenRouter 路由模型。你看到的排行，本質上是這些 production 產品在生產環境中真實的選擇。

OpenRouter 自己發布的 State of AI 2025 報告揭露了更深層的趨勢：總週吞吐量從 2025 年 4 月的 5T tokens 漲到 2026 年 4 月的 20T+，一年成長 4 倍；推理模型已佔全部 token 流量的 50%；平均 prompt 長度從 1.5K 翻到 6K，agent 工作流取代單次推理成為主流。這些結構性變化，正是排行榜每週都在變動的根因。

整體 Top 10：Anthropic 不再壟斷，中國模型半壁江山

openrouter-china-models-rising

來看 2026 年 4 月的整體 Top 10（週 token 使用量）：

排名	模型	提供者	週 token	關鍵特徵
1	Kimi K2.6	moonshotai 🇨🇳	1.36T	MoE 1T/32B、agent swarm
2	Claude Sonnet 4.6	anthropic 🇺🇸	1.35T	1M context、編程主力
3	DeepSeek V3.2	deepseek 🇨🇳	1.31T	DSA 稀疏注意力、極低價
4	Claude Opus 4.7	anthropic 🇺🇸	1.14T	Anthropic 旗艦
5	Gemini 3 Flash Preview	google 🇺🇸	1.06T	1M context、多模態
6	MiniMax M2.7	minimax 🇨🇳	806B	性價比之選
7	Grok 4.1 Fast	x-ai 🇺🇸	721B	2M context
8	Claude Opus 4.6	anthropic 🇺🇸	699B	上代旗艦
9	MiniMax M2.5	minimax 🇨🇳	698B
10	Step 3.5 Flash	stepfun 🇨🇳	673B	快速且廉價

有件事看完數字才會驚覺：2024 年 10 月時，中國模型在 OpenRouter 的整體佔比是 1.2%。2026 年 4 月，這個數字是 45%+，連續 5 週中國週 token 量超越美國。前 10 名有 5 席是中國模型，再加上 OpenAI 的 GPT-5.4 連榜都沒擠進去——LLM 市場的權力結構在 18 個月內被徹底改寫。

這不是「中國技術突然超車」這麼簡單的故事。背後有三條主線同時推進：價格戰（中國模型多在 $1/M tokens 以下，美國旗艦多在 $3-25/M）、開源策略（自由部署、企業可自託管）、快速迭代（Kimi 從 K2.5 到 K2.6 只花了三個月）。OpenAI 在 OpenRouter 路由通路的弱勢並不代表 GPT-5.4 整體不行——OpenAI 的真正主場在 ChatGPT 訂閱與企業合約，但這份排行確實顯示「用 OpenRouter 走多模型路由的開發者」已經把選票投給了別人。

Programming：Kimi K2.6 用 Agent Swarm 改寫遊戲規則

kimi-k2-agent-swarm

Programming 是 OpenRouter 上最大的單一類別，token 佔比已從 2025 初的 11% 飆升至 50% 以上。Anthropic 的 Claude 系列曾經長期佔 60%+ 的編程市場份額，2025 年 11 月以後跌破 60%。然後 Kimi K2.6 來了。

來看 OpenRouter Programming Collection 的 Top 10：

#	模型	提供者	週 token	佔比
1	Kimi K2.6	moonshotai	1.37T	22.3%
2	Claude Opus 4.7	anthropic	429B	7.0%
3	Step 3.5 Flash	stepfun	383B	6.2%
4	Nemotron 3 Super 120B (free)	nvidia	319B	5.2%
5	Claude Sonnet 4.6	anthropic	302B	4.9%
6	MiniMax M2.5	minimax	297B	4.8%
7	MiniMax M2.7	minimax	267B	4.3%
8	Claude Opus 4.6	anthropic	237B	3.8%
9	GPT-5.4	openai	209B	3.4%
10	Others	–	2.35T	38.1%

GPT-5.4 在 Programming 排第 9，且其上方有 4 個中國模型（Kimi、Step、MiniMax×2）——這對 18 個月前的格局來說是劇變。

Kimi K2.6 為何能贏？三個結構性優勢

第一是架構。K2.6 是 MoE（Mixture-of-Experts）架構，總參數 1T，但每個 token 只 active 32B。這個比例非常聰明——你拿到 1T 模型的能力品質，付的卻是 32B 模型的推理成本。GMI Cloud 的拆解指出，K2.6 在 INT4 量化後可以塞進 4 張 H100，企業自託管門檻被壓得很低。

第二是 agent swarm。K2.6 最大的差異化在於它是為「長期任務」設計的。Kimi 官方技術 blog 與 Microsoft Foundry 整合公告記載：300 個並行 sub-agents（K2.5 為 100 個）、長期執行 + 持續工具調用、coordinator 動態分派任務並在 sub-agent 失敗時自動重派。這個能力對應的是真實的 production 場景——不是「幫我寫一個 function」，而是「重構整個 codebase、修復所有 lint 錯誤、跑完測試」。

第三是 benchmark 領先（但有但書）。K2.6 在 SWE-Bench Pro 拿下 58.6 分，壓過 GPT-5.4 的 57.7 與 Claude Opus 4.6 的 53.4 ；HLE w/ tools 達 54.0 第一。但同一份 GMI Cloud 拆解也指出，純數學推理上 Gemini 3.1 Pro Thinking 在 LiveCodeBench v6 仍以 91.7 略勝（K2.6 為 89.6），SWE-Bench Multilingual 也是 Opus 4.6 的 77.8 略高於 K2.6 的 76.7。換句話說，K2.6 的勝出不是全面碾壓，而是在「長期任務 + 工具串接」這個維度做出顯著差距。

加上 K2.6 採用 Modified MIT License 開源、Microsoft Foundry 與 Cloudflare Workers AI 都做了 Day 0 整合、OpenRouter 上排第一名的 app（OpenClaw，週 392B token）原生綁定 K2.6——這是技術 + 商業 + 生態三線同時推進的結果。

Roleplay：DeepSeek V3.2 的 40.2% 壟斷

deepseek-roleplay-creative

如果說 Programming 還是一個有競爭的市場，Roleplay 完全是另一個故事：

#	模型	提供者	週 token	佔比
1	DeepSeek V3.2	deepseek	968B	40.2%
2	Grok 4.1 Fast	x-ai	145B	6.0%
3	GLM 4.5 Air	z-ai	141B	5.9%
4	Gemini 2.5 Flash Lite	google	112B	4.6%
5	Gemini 3 Flash Preview	google	93.6B	3.9%

DeepSeek V3.2 一個模型佔了 40% 以上。其他類別的 #1 通常在 5-25% 範圍——這個壟斷程度在 OpenRouter 上獨一無二。

為什麼是 DeepSeek？三角完美命中

DeepSeek V3.2 的架構是 MoE 671B/37B active ，最關鍵的創新是 DeepSeek Sparse Attention（DSA） ——一種細粒度稀疏注意力機制。根據 DeepSeek 官方公告，相較 V3.1-Terminus，DSA 在長 context 訓練/推理的 API 成本下降 50% 以上，benchmark 表現「on par」（基本持平）。對 Roleplay 這種「對話越聊越長」的場景，這個優化直接擊中痛點。

但更有趣的是訓練細節。Kili Technology 的拆解指出，DeepSeek 是少數明確揭露 creative writing 與 role-play 訓練流程的 frontier 級模型——他們對「非推理任務」採用 model-generated 響應 + 人工 annotator 驗證準確性的方式。換句話說，DeepSeek 在角色扮演的「人味」上做過真正的工程投入，不是訓練資料的副產品。

定價是壓死駱駝的最後一根稻草：$0.26/$0.38 per 1M tokens，比 Claude Sonnet 便宜 10 倍。對 Janitor AI 這種免費或微薄訂閱費的 character chat 平台，成本不是 nice-to-have 而是 must-have。

加上開源（MIT License）、content filter 比 Anthropic/OpenAI 寬鬆——對 Roleplay 用例來說，「不會被 safety filter 打斷的對話流」本身就是核心需求。Claude 與 GPT 在這個領域沒有任何空間切入。

OpenRouter 的 State of AI 報告還補了一刀：OSS 模型的全部使用量裡，超過 50% 都在做 Roleplay。Programming 的 38% 是第二大用途。所以「為什麼 OSS 在 Roleplay 強？」的答案不是 OSS 模型訓練得特別好，而是「商用模型因為 safety 限制無法切入這個 50% 大餅」。

Health & Academia：Gemini 3 Flash Preview 的雙冠王

Health 與 Academia 屬於 OpenRouter State of AI 報告中歸類的「Specialized Experts」象限——使用量低、cost-per-token 高、對精確性極度敏感。這兩個分類的 #1 都是 Gemini 3 Flash Preview 。

Gemini 3 Flash Preview 為什麼能在這兩個高敏感領域勝出？

維度	細節
多模態原生	text/image/audio/video/PDF 同模型，不需切換
PhD 級知識	GPQA Diamond 90.4%（物理/化學/生物 grad-level）
抗幻覺	HLE 33.7% 無工具、43.5% 有工具，Artificial Analysis 評為知識/抗幻覺最強
MMMU-Pro	81.2%（與 Pro 版同分）
醫療專項	Google 系出 Med-Gemini，MedQA 91.1% 創紀錄
Context	1.05M tokens
價格	$0.50/$3 per 1M tokens（frontier 級中段）

Health 是個極度碎片化的市場——OpenRouter 報告指出沒有單一 sub-tag 超過 25%，從醫研、心理諮商、治療指引到診斷查詢全包。在這種需求多樣的場景，**「全能 + 多模態 + 低幻覺 + 醫療專項微調」**的組合勝出是必然——病歷不只有文字、X 光與 MRI 是圖像、論文裡有圖表，模型必須一次處理。

Academia 也有類似邏輯。Gemini 3 Flash 在 AA-Omniscience 第一、Humanity's Last Exam 第二，加上 1M context 可以吞整本論文或教科書——這正是學術工作流的核心。

Legal：Grok 4.1 Fast 用 2M Context 殺出血路

grok-legal-2m-context

Legal 分類的 #1 是 Grok 4.1 Fast——這個結果第一眼讓人意外，但拆解完數字就會懂。

Grok 4.1 Fast 的法律殺招

xAI 在 2025 年 11 月發布的 Grok 4.1 Fast 把幾個關鍵指標推到極限（Better Stack 技術解析與 Oracle Cloud 文件也均做了交叉驗證）：

2M tokens context window，業界最大。可以一次吞整本案件卷宗、整份合約集，不用切片
幻覺率約 4%，xAI 與 Better Stack 報告指出較 Grok 4 大降約 65% ；Oracle 文件描述為「reduced by ~3x」
$0.20/$0.50 per 1M tokens，極便宜，可以大量並行
Berkeley Function Calling v4 達 72%，τ²-bench Telecom 100%（Artificial Analysis 驗證）
LMArena Elo 1483 #1 ，純人類偏好分數冠軍

法律工作的痛點完美對應這些特性：合約必須整份讀完、不能瞎掰一條法條、需要多次往返審閱。Gemini 3 Flash 在 Harvey BigLaw Bench 也提升 7% ，但 1M context 對 100+ 頁的契約仍然吃緊——Grok 的 2M 才是甜蜜點。

xAI 同步發布的 Agent Tools API（內建 web search、code execution、MCP 整合）讓 Grok 直接跑「法律研究 agent」，這是 Claude/GPT 還沒做到的整合度。

Marketing：Gemini 2.5 Flash Lite 的 $0.10 經濟學

Gemini 2.5 Flash Lite 拿下 Marketing #1，理由很簡單——$0.10/$0.40 per 1M tokens 是全 frontier 級模型最便宜的價格。

Marketing 雖然被 OpenRouter 歸類在「Specialized Experts」象限，但實際上的核心需求是「大量量產」：SEO 文章、廣告文案、產品描述、email 主旨。這時候模型品質的邊際效益遠不如價格——便宜 10 倍、品質掉 5%，是穩賺不賠的交易。Gemini 2.5 Flash Lite 配上 1M context（一次讀完整份品牌 guideline），組合無懈可擊。

OpenAI 的 gpt-oss-120b 因為完全免費搶下第二名，連定價都不用打就贏。

Finance：Claude Sonnet 4.6 為何仍是這個領域的標準答案

Finance 是 Claude 還站穩第一線的領域之一。Sonnet 4.6 是 OpenRouter 整體 Top 10 第二名（週 1.35T tokens），Finance 分類觀察排名 #2——這是在 Anthropic 不削價、單價是 DeepSeek 的 10 倍的前提下做到的。

為什麼 Finance 客戶願意付 $3/$15 per 1M tokens（比 DeepSeek 貴 10 倍）？因為 Finance 是「錯一次比省錢貴一萬倍」的業務。一份財報誤讀、一個風險評估幻覺、一條 ESG 條款搞錯，後果都是商業災難。Anthropic 的 Constitutional AI 訓練讓 Claude 在「承認自己不知道」這件事上做得最好，這對 Finance 來說是決定性優勢。

加上 1M context（吞 10K 級報表/招股書）、優秀的 tool use、與 Bloomberg、FactSet 等金融工具的整合——Claude 在這個領域的護城河比 Programming 深得多。

四大勝出原因總整理

整理完七個分類的 #1，為什麼某個模型能贏，本質上歸因於四個維度：

維度	代表案例	影響的分類
架構優勢	Kimi MoE 1T/32B、DeepSeek DSA Sparse Attention、Nemotron Hybrid Mamba-Transformer	Programming、Roleplay
訓練特化	Claude Constitutional AI、DeepSeek 創意寫作 RLHF、Med-Gemini、Grok 低幻覺 RL	Finance、Roleplay、Health、Legal
經濟優勢	Gemini Flash Lite $0.10/$0.40、Grok $0.20/$0.50、DeepSeek $0.26/$0.38	Marketing、Roleplay、長尾類別
規模優勢	Grok 2M、Gemini 1M、Kimi 256K、Claude 1M	Legal、Academia、長文件處理

不過這四個維度也不是「具備就贏」。MiniMax M2.7 在架構（MoE）、經濟（$0.30/$1.20）、規模（197K context）三項都不差，benchmark 也接近第一線，但在 Programming 還是排到第 7。原因是它沒做出 Kimi 那種 agent swarm 的差異化訓練，沒切到「長期任務」這個維度。OpenRouter 排行真正獎勵的是「找到一個沒被滿足的剛性需求 + 在那個維度做到極致」——而不是平均都好。

Use Case 二元化象限：你的需求落在哪裡？

usecase-quadrant-chart

OpenRouter State of AI 報告把 11 個分類按「使用量 × 成本」分成四個象限：

象限	特徵	涵蓋分類	選模型邏輯
Mass Market（高量低成本）	用量大、單 task 中等成本	Programming	選有 agent 能力的中價位（Kimi、Claude Sonnet）
Premium（高量高願付）	用量大、特殊需求	Roleplay (OSS 主導)	選便宜開源（DeepSeek、GLM）
Niche Utilities（低量低成本）	低量、低願付	Translation、Trivia	選最便宜或免費（Gemini Flash Lite、gpt-oss）
Specialized Experts（低量高成本）	低量、高 cost-per-token、高敏感	Finance、Health、Legal、Academia、Marketing	選 frontier 或專項微調（Claude、Gemini Pro、Med-Gemini、Grok）

象限分類沒有絕對——例如 Marketing 在 OpenRouter 報告裡屬 Specialized Experts，但實務上「SEO 量產」場景反而向 Mass Market 靠攏，所以 Marketing #1 才會是價格極低的 Gemini Flash Lite。用 OpenRouter 排行做選型決策時，要先確認你自己的工作流落在哪個象限，而不是直接套分類名稱。

2026 年實戰選用建議表

最後整合所有分析，給你一張按用例選模型的表：

用例	首選	次選	預算最佳
編程 / Agent	Kimi K2.6 ($0.74/$4.66)	Claude Opus 4.7 ($5/$25)	Nemotron 3 Super (free)
Roleplay / 創意寫作	DeepSeek V3.2 ($0.26/$0.38)	Grok 4.1 Fast ($0.20/$0.50)	GLM 4.5 Air (free)
醫療 / 學術	Gemini 3 Flash Preview ($0.50/$3)	Claude Sonnet 4.6 ($3/$15)	gpt-oss-120b (free)
法律合約審閱	Grok 4.1 Fast (2M context)	Gemini 3 Flash Preview	gpt-oss-120b
行銷 / SEO 量產	Gemini 2.5 Flash Lite ($0.10/$0.40)	Grok 4.1 Fast	gpt-oss-120b (free)
金融分析	Claude Sonnet 4.6	Gemini 3 Flash Preview	Kimi K2.5
翻譯	Gemini Flash Lite	DeepSeek V3.2	Gemma 4 31B (free)
通用問答	Gemini 3 Flash Preview	Claude Sonnet 4.6	DeepSeek V3.2

實戰上我自己的策略是：主力選一個 frontier 模型 + 備案選一個便宜開源模型。例如編程主力 Claude Sonnet 4.6（穩定）、便宜路由 Kimi K2.6（agent 重活）、實驗性質 Nemotron 3 Super（免費跑長 context）。透過 OpenRouter 的 fallback 機制可以一個 API 切換，不用改 client 程式碼。

結語：誰會是下一個 #1？

OpenRouter 排行每週都在變動。寫這篇文章的時候，新晉模型像 Alibaba Qwen 3.6 Plus、Xiaomi MiMo 系列、Tencent Hy3 preview 都還在快速攀升。下個月榜首會不會又換人，沒人敢打包票。

不過從整份分析看下來，有幾個方向可能比榜單本身更值得注意。中國模型的崛起更像是結構性而非短期波動——Kimi、DeepSeek、MiniMax、Qwen、Step、Xiaomi 已形成完整生態，價格 + 開源 + 快速迭代三線並進。Anthropic 用 Claude 守住企業合規、複雜推理、金融用例；Google 用 Gemini 以多模態 + 從 Flash Lite 到 Pro 的全價格帶切細分市場；OpenAI 在 OpenRouter 路由通路相對弱勢，主場其實是 ChatGPT 訂閱與企業 API 直接合約。

最值得關注的是 Agent 工作流的崛起。OpenRouter 上排第一名的 app 不是聊天機器人而是 OpenClaw 這種 agentic 工具、Programming 的 #1 是設計成跑 300 sub-agent 的 Kimi K2.6——這代表「LLM 是 agent 引擎」已從理論走進現實。下一波真正能改變排行格局的，可能不是某個 benchmark 跑得更高的模型，而是把 agent 工程做對的整套產品。

如果你正在做 AI 產品決策，我的建議是：別只看 benchmark，去 OpenRouter 跑壓力測試。用真實 prompt、真實 context size、真實併發量，比較每個模型在你的場景下的延遲、品質、成本。這份排行只是地圖，真正的答案藏在你的工作流裡。

延伸閱讀與參考資料

OpenRouter 官方來源

OpenRouter Rankings – 即時更新的 LLM 排行
OpenRouter State of AI 2025 報告 – 100T token 使用量研究
Best AI Models for Coding – Programming 完整榜單
Best AI Models for Roleplay – Roleplay 完整榜單

模型架構與技術深度

產業趨勢觀察

本文摘自一份較長的內部研究筆記，涵蓋 4 輪深度研究、各分類細部排名、模型卡 metadata 與時間 snapshot 比對。如果你對某個分類想看更原始的數據，歡迎在留言區告訴我。

本文最初發布於 HackMD @BASHCAT。

Markdown 新手完整指南 — 從零到 AI 時代，一篇就搞懂

markdown-主視覺

等一下，這是什麼？為什麼我的朋友都在用？

有沒有發生過這種事：

你打開朋友傳來的檔案，副檔名是怪怪的 .md。用 Word 打開，亂碼；用記事本打開，看到滿滿的 #、**、-，像某種密碼。你關上檔案，心想「這不是我的世界」。

但你後來又發現，GitHub 上每個專案都有個 README.md；你用 ChatGPT 或 Claude 問問題，它的回答總是整整齊齊有標題有清單；你朋友的 Obsidian 筆記軟體裡，每個檔案都是 .md。

這個神秘的東西叫 Markdown。而且老實說，它比你想像的簡單太多了，真的只要 15 分鐘就能學會。

這篇文章會帶你從零開始。沒有術語轟炸，每個概念都有例子。讀完之後，你不只會寫 Markdown，還會懂為什麼 2026 年的 AI 工具幾乎全都用它當預設輸出格式。

Markdown 是什麼？用白話解釋

想像一下，你在紙上寫筆記。你會怎麼標示「這是標題」？

大部分人會畫底線、寫大一點，或者在前面加一個圓點。這些動作背後有個邏輯：用最小的符號傳達最大的意思。

Markdown 就是把這個邏輯搬到電腦上。它是一種輕量級標記語言（lightweight markup language），由 John Gruber 和 Aaron Swartz 在 2004 年發明，核心哲學就一句話：

讓純文字看起來就像「已經被格式化過」，而且任何人不需要學習就能看懂。

舉個例子。同一段內容，三種寫法：

HTML 寫法（網頁用的）：

<h1>今天的待辦</h1>
<ul>
  <li>買牛奶</li>
  <li><strong>打電話給媽媽</strong></li>
</ul>

Word 檔：一個你打不開原始碼的二進位檔，只能用特定軟體編輯。

Markdown 寫法：

# 今天的待辦

- 買牛奶
- **打電話給媽媽**

哪個看起來比較舒服？哪個不用軟體就看得懂？

這就是 Markdown 的魔法。它是「純文字」（plain text），意思是你用任何編輯器都能打開，二十年後也不會失效。但它又透過幾個簡單符號（#、*、-）加上了「結構感」，可以被轉換成漂亮的網頁、PDF、甚至投影片。

為什麼要學？Word 不好嗎？

markdown-vs-word

我知道你在想什麼：「我已經會用 Word 了，為什麼要學新東西？」

這是個好問題。讓我直接給你三個 Word 解決不了、但 Markdown 輕鬆搞定的場景。

場景一：半年後，你打不開自己的檔案

你有沒有過這種經驗：打開三年前的 Word 檔，排版全亂掉？或者用新版 Word 開舊檔，字型跑位？

Word 的檔案格式（.docx）是二進位格式，需要特定軟體（通常還要付費）才能解讀。軟體升級、格式改變，舊檔就可能出事。

Markdown 是純文字，底層用的是 UTF-8 編碼，向後相容到 1963 年的 ASCII。你現在寫的 .md 檔案，20 年後用任何一個文字編輯器都還是打得開。

場景二：`final_v3_真的_ACTUAL_FINAL.docx`

你一定看過這種檔名吧。

Word 檔案因為是二進位格式，沒辦法用 Git 做版本控制。每次改動都是「整個檔案變了」，你無法看到「我昨天改了哪一句話」。

Markdown 是純文字，完美契合 Git。我改了一個字、加了一行、刪了一個段落，Git 都能精準顯示。ModernActuary 的技術部落格有篇文章講得很好：「用 Markdown + Git，你永遠會有一個明確的最新版本，每次改動都有紀錄，誰改的、什麼時候改的、為什麼改，都一清二楚。」

場景三：你想要的，Word 永遠給不了的自由

Word 有個本質問題：內容和樣式綁在一起。你在 Word 裡寫的東西，離開 Word 就變形。

Markdown 反過來 — 內容是內容，樣式是樣式，完全分離。同一份 .md 檔案，你可以透過工具變成：

網頁（HTML）
PDF 文件
Word 檔（需要給不會用 Markdown 的人）
投影片（reveal.js）
電子書（ePub）
靜態網站（Jekyll、Hugo、Hexo）

一份來源，多種產出。這就是專業寫作者、工程師、研究者越來越愛用 Markdown 的原因。哈佛學者 Stuart Shieber 甚至寫過一篇專文，直接叫「為什麼學者應該用 Markdown 寫論文」。

10 分鐘學會：Markdown 基本語法

好，夠多理論了。來動手吧。

你現在只需要一個地方「寫東西」。最快的方法：打開瀏覽器，到 stackedit.io 或 dillinger.io ，左邊打字，右邊即時看到結果。

準備好了嗎？接下來是你這輩子唯一需要的 Markdown 速查表。

標題：用 `#` 的數量決定大小

# 這是最大的標題（H1）
## 第二大標題（H2）
### 第三大標題（H3）
#### 第四大標題
##### 第五大標題
###### 最小的標題

新手第一個坑：# 後面一定要有空格。寫 #標題 不會變成標題，寫 # 標題 才會。

粗體、斜體、刪除線

這是 **粗體**
這是 *斜體*
這是 ***粗斜體***
這是 ~~刪除線~~

記憶法：一顆星是斜體，兩顆星是粗體。就像喊話：「特別一點！」用一層，「超級重要！」用兩層。

清單：購物清單 or 流程步驟

無序清單（項目沒先後）：

- 蘋果
- 香蕉
- 牛奶
  - 低脂
  - 全脂

有序清單（有先後順序）：

1. 起床
2. 刷牙
3. 發現手機沒電
4. 充電再睡回去

小技巧：有序清單你全部寫 1. 也沒關係，Markdown 會自動幫你編號。這讓你之後插入新項目時不用重新排。

待辦清單（大家最愛）：

- [ ] 買牛奶
- [x] 打電話給媽媽
- [ ] 寫週報

連結和圖片

兩個語法長得很像，只差一個驚嘆號：

連結：[顯示的文字](https://網址.com)
圖片：![替代文字](圖片網址或路徑.jpg)

例子：

我每天必看 [Hacker News](https://news.ycombinator.com)。

![我家的貓](./cat.jpg)

程式碼：單行和多行

行內程式碼（一個反引號）：

要安裝請執行 `npm install`

多行程式碼區塊（三個反引號，可以指定語言讓它有語法高亮）：

```python
def hello():
    print("Hello, Markdown!")
```

引用：擷取別人說的話

> 純文字是所有格式的起點和終點。
> — Wired 雜誌，論 Markdown

表格：簡單資料整理

| 工具 | 價格 | 適合誰 |
| --- | --- | --- |
| Obsidian | 免費（個人）| 重度知識管理 |
| HackMD | 免費起步 | 團隊協作 |
| VSCode | 免費 | 開發者 |

坑預警：表格的語法稍微囉嗦，但大多數編輯器（Obsidian、Typora）都有表格快捷鍵，不需要手打。

分隔線

三個減號、星號或底線都可以：

---

HTML 備案：當 Markdown 不夠用時

這招很少新手知道：Markdown 可以混寫 HTML。比如你要讓圖片置中、改變尺寸：

<img src="cat.jpg" width="300" align="center">

完全合法。Markdown 不是一個封閉系統，它和 HTML 和諧共處。

新手最常踩的 5 個坑

寫了幾年 Markdown，我見過太多人卡在同樣的地方。先把這些記下來，省你幾小時的鬱悶時間。

第一坑：# 後面忘記加空格 #標題 ❌ 不會變標題 # 標題 ✅ 正確

第二坑：換行不換行 你在 Markdown 裡按一次 Enter，有些渲染器會當作「同一個段落」，不換行。想要真正換行，按兩次 Enter（留一個空白行）。

第三坑：清單項目間不要亂空行

- 項目一

- 項目二

中間空行，有些編輯器會視為兩個獨立清單。除非你要故意分開，不然連續寫就好。

第四坑：表格對齊要用冒號

| 左對齊 | 置中 | 右對齊 |
| :--- | :---: | ---: |

分隔列的冒號位置決定對齊方向。

第五坑：Obsidian、GitHub、HackMD 的語法有細微差異 這是 Markdown 生態最大的缺點：各家有各家的「flavor（口味）」。最常見的是 GitHub Flavored Markdown (GFM)，支援表格、待辦清單、程式碼語法高亮等。遇到特殊功能不相容時，不要慌，那是正常的。想了解標準化努力，可以看 CommonMark 這個專案。

工具推薦：我該用哪一個？

markdown-工具推薦

市面上的 Markdown 編輯器多到你眼花。我幫你整理成四類場景，直接對號入座。

場景一：我要做個人知識管理（第二大腦）

首選：Obsidian

免費（個人使用）
所有筆記是本機 .md 檔，你完全擁有資料
強大的雙向連結（[[筆記名]]）打造知識網絡
1000+ 社群外掛
內建 AI 整合越來越強，2026 年成為「第二大腦」的主流選擇

我自己就是重度 Obsidian 使用者。推薦理由：20 年後這些 .md 檔你都還打得開，Obsidian 倒了也沒差。

場景二：我要和團隊即時協作

首選：HackMD

雲端即時協作，像 Google Docs 但是 Markdown 版
會議筆記、團隊文件、技術分享的神器
可以直接發布成簡報（reveal.js）
免費帳號就很夠用

場景三：我是寫程式的

首選：VSCode + Markdown 外掛

原生支援 Markdown 預覽（Ctrl/Cmd + Shift + V）
裝 Markdown All in One 外掛後體驗大升級
可以同時管理程式碼和文件

場景四：我只想要一個乾淨的寫作環境

首選：Typora（付費，一次買斷）

所見即所得（WYSIWYG）的 Markdown 編輯器
你打 **粗體** 它會直接顯示成粗體，符號自動隱藏
適合討厭看到「原始語法」的人

備用：StackEdit、Dillinger（網頁版，免費，不用安裝）

為什麼 2026 年，連 AI 都愛 Markdown？

markdown-AI第二大腦

這是這篇文章最有意思的部分。

如果你觀察 ChatGPT、Claude、Gemini 的回答，會發現它們預設都用 Markdown 格式輸出。這不是巧合，是一個根本性的技術選擇。

原因一：Token 經濟學 — Markdown 比 HTML 省 40-80%

LLM（大型語言模型）以 token 計費。token 簡單講就是「字的小單位」。格式化符號越多，花的 token 越多。

同樣一段有結構的內容，Cloudflare 實測從 HTML 轉成 Markdown，token 從 16,180 降到 3,150，省了 80%。有些複雜頁面甚至可以省 95%。

對 AI 公司來說，這是真金白銀的成本差異。

原因二：訓練資料 — LLM 早就「吃」了幾十億份 Markdown

GitHub 上幾乎每個 repo 都有 README.md。React、Kubernetes、Python 的文件站幾乎都是 Markdown 寫的。Stack Overflow、Reddit 的格式底層也是 Markdown。

結論：LLM 在訓練時讀了數十億份 Markdown 文件。對它來說，輸出 Markdown 就像「回到母語」。

原因三：「Markdown is the new API」

這是 2026 年最熱的軟體架構趨勢。

根據 The New Stack 的一篇分析，創投家 Brad Feld 用 12 個 Markdown 檔案（叫做 CompanyOS） 經營整間公司 — 每個檔案教 Claude Code 怎麼處理特定任務（寫郵件、客服、準備董事會資料）。沒有複雜的後端系統，就是 .md 檔 + Git。

更驚人的數字對比：

GitHub 官方的 MCP 伺服器：教 AI 怎麼用 GitHub，要花 50,000 個 token
一份 SKILL.md 檔：寫「用 gh CLI 執行這些操作」，只要 200 個 token

相同效果，250 倍效率。這就是為什麼越來越多開發者相信：未來的 AI 指令、工作流、公司流程，都會以 Markdown 為載體。

原因四：你的筆記 = AI 的脈絡

2025 到 2026 年，有個新的工作流在知識工作者之間爆紅：

把 Obsidian vault 當作 AI 的「持久記憶」

你平常用 Obsidian 記筆記（純 Markdown 檔）。需要 AI 幫忙時，不用每次重新解釋你的背景、專案、偏好 — AI 直接讀你的 vault，知道你是誰、在做什麼。

這個架構叫 Claude Code + MCP-Obsidian，相關工具如 smithery-ai/mcp-obsidian 在 GitHub 上星星數量快速成長。筆記 app 市場規模預計從 2023 年的 5.76 億成長到 2032 年的 22.6 億美元，年複合成長率 16.4%。

一句話總結：你用 Word 寫的東西，AI 看不懂。你用 Markdown 寫的東西，AI 天生就懂。

新手常見問題 FAQ

Q1：我的 .md 檔要用什麼打開？ 任何文字編輯器都可以（記事本、VSCode、Sublime Text）。但要看「渲染後」的樣子，用 Obsidian、Typora、VSCode（Cmd+Shift+V 預覽）、或網頁版 StackEdit。

Q2：Markdown 有辦法打出數學公式嗎？ 可以，用 LaTeX 語法包在 $...$ （行內）或 $$...$$（區塊）。但需要支援的渲染器（Obsidian、HackMD、GitHub Issues 等）。

Q3：我寫好的 Markdown 要怎麼變成 Word 檔給長輩看？ 推薦工具 Pandoc 。安裝後執行：

pandoc input.md -o output.docx

一鍵轉 Word、PDF、ePub 都行。

Q4：能不能同時用 Markdown 和 Word？ 完全可以。很多專業寫作者的工作流是：

用 Markdown 寫初稿（Obsidian 或 Typora）
用 Pandoc 轉 Word 給編輯或客戶
客戶用 Word track changes 回饋
手動把修改合回 Markdown（或直接接受 Word 版成品）

Q5：Markdown 能做複雜排版（多欄、頁碼、目錄）嗎？ 基本的可以（目錄、腳註），複雜的不行。如果需要精準排版，建議用 LaTeX 或 Typst。但老實說，90% 的人一輩子不會需要這些。

Q6：手機上能寫 Markdown 嗎？ 可以。Obsidian 有 iOS / Android app，1Writer、iA Writer 也都很棒。

Q7：Markdown 會不會過時？ Wired 雜誌的這篇文章標題叫「The Eternal Truth of Markdown」（Markdown 的永恆真理）。純文字從 1960 年代活到現在還沒死，Markdown 又站在 AI 浪潮最前線 — 短期內不用擔心這個問題。

結語：你的下一步

如果你讀到這裡，恭喜你 — 你已經知道 Markdown 的 80%。剩下的 20%，你會在實際使用中自然學會。

我給你一個具體的 30 天行動建議：

第 1 週：下載 Obsidian，用 Markdown 寫今天的日記。堅持 7 天。

第 2 週：把你腦中某個主題（興趣、工作筆記、學習紀錄）的內容用 Markdown 整理成幾個檔案。嘗試用 [[雙向連結]] 串起來。

第 3 週：開始在工作場合用 Markdown。跟團隊分享會議紀錄（HackMD）、給主管的週報（轉成 Word 給他）。

第 4 週：嘗試把你的 Markdown 筆記接上 AI。讓 Claude 或 ChatGPT 讀你的筆記，回答你的問題。感受那種「AI 理解你的脈絡」的震撼。

一個月後，你會忍不住跟朋友說：「我以前怎麼會用 Word 用這麼久？」

祝你寫作愉快。歡迎加入純文字的世界。

Sequential Thinking MCP 還需要嗎？2026 年大模型內建推理時代的完整分析

sequential-thinking-brain-transition

你還記得 2024 年底到 2025 年初那段日子嗎？每一篇「MCP 入門教學」、每一個 YouTube 上的「10 個必裝 MCP Server」影片，幾乎都會提到同一個名字——Sequential Thinking。

那時候，安裝這個 MCP server 就像新手村的第一個任務。不管你用 Claude Desktop、Cursor 還是 VS Code，大家的 config 裡都會有那段熟悉的設定：

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    }
  }
}

它的承諾很誘人：讓 AI 不要急著給答案，而是一步一步想清楚再回覆。聽起來很合理，對吧？

但現在是 2026 年 4 月。Claude 有了 Adaptive Thinking，GPT-5.4 把推理能力直接內建，DeepSeek R1 自己就會生成 <think> 區塊。那個曾經排名第三的熱門 MCP server，還有存在的必要嗎？

這篇文章不打算給你一個簡單的「要」或「不要」。我想帶你從技術原理開始，走過 Benchmark 數據、Anthropic 的官方態度轉變、社群的真實聲音，最後再回到那個實際的問題：你的 config 裡，該不該留著它？

先搞清楚：Sequential Thinking MCP 到底在做什麼？

sequential-thinking-external-vs-internal

在討論「還需不需要」之前，得先理解它的運作機制。很多人裝了它卻不太清楚它實際上幹了什麼——這本身就是個值得思考的現象。

Sequential Thinking MCP 的核心其實很簡單：它提供一個叫做 sequentialthinking 的工具（tool），讓 LLM 可以把自己的推理過程「外部化」成一系列結構化的步驟。

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]graph TD
    A[LLM 收到複雜問題] --> B[呼叫 sequentialthinking 工具]
    B --> C[Thought #1: 問題分解]
    C --> D[Thought #2: 分析方案 A]
    D --> E[Thought #3: 分析方案 B]
    E --> F{需要修正嗎?}
    F -->|是| G[Revision: 修正 Thought #2]
    F -->|否| H[Thought #4: 結論]
    G --> H
    E --> I[Branch: 探索方案 C]
    I --> H

每次呼叫這個工具，LLM 會傳入一個 JSON 物件，包含：

thought：當前的思考內容
thoughtNumber / totalThoughts：進度追蹤
nextThoughtNeeded：是否需要繼續思考
isRevision：是否修正先前的想法
branchFromThought / branchId：從哪個節點開始分支

關鍵的地方在這裡：這個工具本身不做任何計算，不呼叫任何外部 API，不存取任何資料庫。 它純粹是一個「思考記事本」，接收 LLM 的思考內容，然後回傳確認訊息。

換句話說，真正在「思考」的還是 LLM 自己。Sequential Thinking MCP 做的事情，是提供一個結構化的框架，鼓勵（或者說強迫）LLM 把推理過程分成多個明確的步驟，而不是一口氣吐出答案。

這在 2024 年很有意義——因為那時候的模型確實容易「跳步」，忽略中間推理就直接給結論。

但問題是：現在的模型還會這樣嗎？

時代變了：推理模型的崛起

sequential-thinking-evolution-timeline

2025 到 2026 年，AI 產業最重大的技術拐點不是參數量的擴張，而是一個全新能力維度的崛起——推理（Reasoning）。

傳統的大語言模型像是「快思考」系統：收到 prompt，立刻生成回應，中間沒有顯式的思考過程。而推理模型是「慢思考」系統：在回答之前，先進行可見或不可見的內部推理，逐步分析問題、驗證假設、修正錯誤。

這張表格說明了現在的局面：

模型	推理機制	發布時間	特點
Claude Opus 4.6	Adaptive Thinking	2026/02	自動判斷複雜度，動態分配思考預算
GPT-5.4	統一推理模式	2026/03	推理直接內建，不再需要獨立的 o 系列
Gemini 3.1 Pro	Deep Think	2026	內建思考模式，免費開放
o3 / o4-mini	原生推理	2025-2026	持續優化的推理專精模型
DeepSeek R1	RL 訓練 CoT	2025/01	開源，純 RL 訓練出自發推理能力
Qwen3	Thinking Mode	2025-2026	`<think>` 標籤強制推理模式

DeepLearning.AI 的分析%E6%8C%87%E5%87%BA%EF%BC%8C%E9%80%99%E6%B3%A2%E6%8E%A8%E7%90%86%E9%9D%A9%E5%91%BD%E7%9A%84%E9%97%9C%E9%8D%B5%E7%AA%81%E7%A0%B4%E4%BE%86%E8%87%AA DeepSeek R1——它證明了推理能力可以純粹透過強化學習（RL）從零訓練出來，不需要人工標註的推理範例。模型會自發產生自我驗證、反思和延伸思考鏈的行為。

這代表什麼？代表 Sequential Thinking MCP 試圖從外部賦予模型的能力——逐步推理、自我修正、分支探索——現在已經被直接「烤進」模型的權重裡了。

更直接的證據來自 SurePrompts 在 2026 年 4 月的分析：

「Let's think step by step」這類提示語在 2026 年已過時甚至有害。推理模型已自動分配思考預算，額外指示只會浪費 token 或導致模型在輸出中重複推理過程。

如果連「請你一步一步想」這句話都已經是多餘的，那一個專門用來「強制模型一步一步想」的 MCP server，處境可想而知。

Anthropic 自己怎麼看？態度轉變的時間線

這件事最有說服力的證據，其實來自 Sequential Thinking MCP 的「娘家」——Anthropic 自己。

讓我們追蹤一下官方態度的演變：

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]timeline
    title Anthropic 推理工具演進時間線
    2025-03 : Think Tool 發布
            : 外部思考工具
            : τ-Bench 提升 54%
    2025-02 : Extended Thinking 發布
            : Claude 3.7 Sonnet
            : 內建推理能力
    2025-12 : 官方更新文章
            : 建議用 Extended Thinking
            : 取代 Think Tool
    2026-02 : Adaptive Thinking
            : Claude Opus 4.6
            : 自動判斷是否需要推理

2025 年 3 月：Think Tool 的輝煌時刻

Anthropic 發布了一篇工程部落格 The "think" tool: Enabling Claude to stop and think，展示了外部思考工具在 τ-Bench 基準測試上的驚人效果：

配置	航空領域 pass¹	零售領域 pass1
基線（無工具）	0.332	0.783
Extended Thinking	0.412	0.770
Think Tool	0.404	0.812
Think Tool + 優化 Prompt	0.584	—

在航空領域（策略複雜度高），Think Tool + 優化 Prompt 比基線提升了 54%，甚至超過 Extended Thinking。這是 Sequential Thinking 類工具最強的背書。

但這裡有個關鍵細節：航空領域的策略規則極度複雜，模型需要在長串的工具呼叫中反覆查驗合規性。這是一個非常特殊的場景，不代表日常開發任務。

2025 年 12 月：官方態度翻轉

同一篇文章在 2025 年 12 月 15 日被悄悄加上了一段更新：

Extended thinking capabilities have improved since its initial release, such that we recommend using that feature instead of a dedicated think tool in most cases.

翻譯成白話就是：「我們的內建推理已經夠好了，大部分情況下不需要額外的思考工具了。」

2026 年 2 月：Adaptive Thinking 終結討論

Claude Opus 4.6 帶來了 Adaptive Thinking——模型不再需要你手動設定推理預算，它會自己判斷問題的複雜度，簡單問題跳過思考，複雜問題自動啟動深度推理。

根據 LumiChats 的完整指南，到了 2026 年底，「推理模型」作為獨立產品類別的概念可能會消失——推理將成為每個前沿模型的內建模式。

社群怎麼看？真實開發者的聲音

sequential-thinking-community-debate

理論分析是一回事，實際使用者怎麼說又是另一回事。我翻了 Reddit 上幾個相關討論串，把真實的聲音整理出來。

停用派：佔多數

Reddit r/ClaudeAI 上一個直接問「Is Sequential Thinking still relevant?」的討論串，最高票的回答相當直接：

「I stopped using it because I wasn't able to really see the benefit of using it over enabling extended thinking. I would rather not inject the sequential thinking MCP schema and would rather save tokens.」

另一位用戶更不客氣：

「massive context waste in general」

在另一個討論串裡，有人直接問 Claude Code 自己怎麼看 Sequential Thinking MCP，Claude 的回答是：

「Unnecessary. I already have TodoWrite/TodoRead tools for task planning and can naturally break down complex problems step-by-step. The sequential thinking server would add overhead without significant benefit.」

當 AI 自己都說不需要的時候，這個畫面挺有喜感的。

保留派：少數但有理

不過也有人指出了 Extended Thinking 做不到的事情：

「One advantage of sequential thinking is the thoughts become visual. You can watch it reason while still tying into the todo system, etc. Oftentimes you want to take a middle-thought and prompt from there. Something you can't when the thoughts are opaque and part of the LLM.」

這位用戶點出了一個真實的差異：可觀察性。Extended Thinking 的思考過程是「黑箱」（你只能看到摘要），而 Sequential Thinking MCP 的每一步推理都是明確的工具呼叫，完全透明。

r/mcp 上也有人給出了平衡的建議：

「Use Sequential Thinking MCP when you care about portability, auditability, and reproducible reasoning; otherwise, your host's built-in planning is usually enough.」

中間派：兩者可以並存

Nick Baumann 在 LinkedIn 上的分析最為平衡，他把兩者的差異講得很清楚：

維度	Extended Thinking	Sequential Thinking MCP
思考方式	私下深度思考，顯示摘要	公開逐步推理，全程透明
速度	快（單次推理）	慢（多次工具呼叫）
可修正性	不可介入中間過程	可在任何步驟介入修正
模型綁定	Claude 專屬	任何 MCP 相容模型
Token 成本	較低	較高（每步一次呼叫）
最佳場景	信任模型，要最終答案	需要透明度和可審計性

他還指出：兩者可以同時使用。Extended Thinking 給 Claude 更大的推理容量，Sequential Thinking MCP 把推理結構化成可見、可修正的步驟。但他也承認，大多數用戶只需要 Extended Thinking 就夠了。

它還活著嗎？4 個仍有價值的利基場景

sequential-thinking-deprecated-tools

講了這麼多「不需要」的理由，公平起見，我也要說說它仍然有用的地方。Sequential Thinking MCP 並不是完全沒有價值——只是它的價值從「通用工具」縮小到了「利基場景」。

場景一：跨模型可攜性

這是最硬的差異化優勢。Extended Thinking 是 Claude 專屬的，GPT-5.4 的推理模式是 OpenAI 專屬的，Gemini Deep Think 是 Google 專屬的。但 Sequential Thinking MCP 遵循 MCP 標準，理論上任何支持 MCP 的模型和客戶端都能用。

如果你的工作流程橫跨多個模型（比如在 Cursor 裡混用 Claude 和 GPT），或者你在開發需要支援多種後端模型的 AI 應用，Sequential Thinking MCP 提供了一個統一的推理介面。

場景二：推理可審計性

在某些企業合規場景中，你需要完整記錄 AI 的推理過程——不是摘要，是逐字逐句的完整記錄。Extended Thinking 的思考過程雖然在某些介面可以查看，但它本質上是模型內部的 token 流，不像 Sequential Thinking MCP 那樣是結構化的、可儲存的 JSON 記錄。

如果你的團隊需要對 AI 的決策過程進行事後審計（比如金融、醫療、法律領域），這個結構化的推理記錄是有實際意義的。

場景三：弱模型的外部腦補

不是每個人都用得起 Claude Opus 4.6 或 GPT-5.4。如果你在使用推理能力較弱的小模型（比如本地部署的 7B/13B 開源模型），Sequential Thinking MCP 確實能幫助它們產出更有結構的推理。

Builder.io 的 2026 MCP 指南也是這樣定位的：

「It shines as an optional 'advanced mode' alongside Task Master, Git, or your observability MCPs when you want your AI pair programmer to think more like a senior engineer.」

場景四：可中斷、可分支的推理流程

Extended Thinking 是一氣呵成的——模型想完了才給你看結果，你沒辦法在第三步的時候說「等等，換個方向」。Sequential Thinking MCP 的逐步呼叫機制天然支持人機互動：你可以在任何一步插手，要求修正方向或從某個節點開始分支。

對於需要人類在迴圈中（human-in-the-loop）的高風險決策場景，這個特性確實無可取代。

市場數據：名氣與實際使用的落差

值得一提的是，Sequential Thinking MCP 在市場上的「名聲」和實際使用之間存在微妙的落差。

名聲層面，它表現得很好：

Vibehackers 稱它為「第三大最受歡迎的 MCP server」
PulseMCP 顯示約 84,000 訪客量
母 repo（modelcontextprotocol/servers）有 82,500+ GitHub stars
持續有衍生版本被開發：MAS Sequential Thinking、Sequential Thinking Ultra、Recursive Thinking 等

但實際使用層面，信號就不那麼樂觀了：

NPM 套件的最後發布版本是 2025.12.18——已經 3 個多月沒更新
Reddit 上的活躍討論從「怎麼用」轉向了「還需要嗎」
多數深度用戶報告已停用或減少使用
衍生版本的訪客量大多只有幾千甚至幾百

我的判斷是：這些「最佳 MCP」列表存在一定的推薦慣性。早期它確實是明星工具，但列表作者不一定會回頭更新他們的推薦。就像很多「必裝 VS Code 套件」文章裡還會推薦已經內建的功能一樣。

決策指南：你該留還是刪？

sequential-thinking-decision-crossroads

說了這麼多，回到最實際的問題。根據你的使用場景，這是我的建議：

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]

B --> F[你需要推理可審計性?]
C --> F
D --> G[保留 Sequential Thinking]
E --> G

F -->|是, 合規需求| G
F -->|否, 一般開發| H[移除 Sequential Thinking]

H --> I[節省 token 和 context window]
G --> J[作為可選的進階模式使用]</div>

可以安全移除的情況

你主要使用 Claude Code + Opus 4.6（或 Sonnet）
你主要使用 GPT-5.4 或 Gemini 3.1 Pro
你的任務是日常開發：寫程式、debug、code review
你重視 token 效率和回應速度

建議保留的情況

你的工作流程跨越多個模型和 IDE
你有合規需求，需要完整的推理審計紀錄
你在使用推理能力較弱的本地開源模型
你的場景需要 human-in-the-loop 的可中斷推理

替代方案一覽

如果你決定移除 Sequential Thinking MCP，這些是內建的替代方案：

需求	Claude Code 替代方案	其他模型替代方案
逐步推理	Adaptive Thinking（自動）	各模型內建推理模式
任務規劃	TodoWrite / Plan mode	Agent 框架的規劃模組
結構化分析	Think tool（API 層級）	System prompt 引導
可觀察推理	Extended Thinking trace	推理模型的 `<think>` 輸出

從 Sequential Thinking 看 AI 工具的生命週期

這個故事其實不只是關於一個 MCP server 的存廢。它反映了 AI 工具生態的一個普遍規律：外部工具的價值會隨著模型能力的內化而被侵蝕。

回想一下：

2023 年，我們需要各種 prompt 技巧來讓模型「好好思考」——「Let's think step by step」、「Take a deep breath」
2024 年，我們需要外部框架（Sequential Thinking MCP、Tree of Thoughts）來強制模型結構化推理
2025 年，推理能力開始被訓練到模型內部（o1、DeepSeek R1）
2026 年，推理成為前沿模型的標配功能，外部工具的價值大幅縮減

這個模式還會繼續。今天你覺得不可或缺的某個 MCP server，明年可能就成為模型的內建能力。Memory MCP？模型的長期記憶會越來越好。Code execution MCP？模型可能會直接內建沙箱。

真正值得關注的不是某個工具「還能不能用」，而是它解決的問題是否已經被更好的方式解決了。

Sequential Thinking MCP 解決的問題——讓 AI 逐步推理而不是跳步——已經被解決了。不是被另一個工具解決的，而是被模型本身解決的。這是最徹底的「過時」方式，也是最健康的技術演進方式。

它沒有死。它只是完成了自己的歷史使命，退居二線。對於少數特殊場景，它仍然是最好的選擇。對於大多數開發者，是時候從 config 裡把它拿掉，把那些 token 省下來做更有價值的事了。

參考資料

Anthropic - The "think" tool: Enabling Claude to stop and think
Builder.io - The Best MCP Servers for Developers in 2026
SurePrompts - Advanced Prompt Engineering in 2026: Claude 4.6, GPT-5.4, and Gemini 2.5 Deep Think
LumiChats - AI Reasoning Models 2026: Complete Guide
Meta Intelligence - DeepSeek R1 vs OpenAI o3 vs Gemini 3: Reasoning Model Benchmarks
DeepLearning.AI - Reasoning Models Transformed the Industry
Nick Baumann - How to unlock Claude's deeper reasoning capabilities
Vibehackers - Best MCP Servers in 2026
PulseMCP - Sequential Thinking MCP Server
Reddit r/ClaudeAI - Is Sequential Thinking still relevant?
Reddit r/ClaudeAI - Claude Code's take on Sequential Thinking MCP
NPM - @modelcontextprotocol/server-sequential-thinking

本文最初發布於 HackMD @BASHCAT。

Harness Engineering 完全解析：當 AI Agent 的護城河不再是模型，而是環境

harness-engineering-hero

那個凌晨三點，AI Agent 把我的 Production 炸了

故事要從一個深夜說起。

你精心設計了一個 AI coding agent，給它最好的模型，餵它最完整的上下文，然後滿懷信心地讓它跑一整夜。隔天早上醒來，發現它不只完成了任務——它還「順便」重構了你沒讓它碰的三個模組，引入了一個循環依賴，然後在凌晨三點自信滿滿地把自己的 PR merge 了進去。

CI 亮了一排紅燈。Slack 炸了。你的 tech lead 在群組裡 @all。

這不是虛構的故事。隨著 AI Agent 在 2025 年從實驗工具進化為生產系統，類似的慘劇每天都在上演。但問題到底出在哪裡？是模型不夠聰明嗎？

OpenAI 的 Codex 團隊在一次內部實驗後給出了一個讓整個產業重新思考的答案：

"Agents aren't hard; the Harness is hard." （Agent 不難，難的是 Harness。）

這句話出自 OpenAI 工程師 Ryan Lopopolo 的文章。他帶領團隊用零行人工編寫的程式碼，完全靠 Codex Agent 建構了一個完整的軟體產品。但讓這件事成功的關鍵，不是更強大的模型——而是他們為模型建構的那個「環境」。

他們把這門新學科叫做 Harness Engineering。

2026 年的此刻，這個概念正在以驚人的速度席捲整個軟體工程界。Martin Fowler 的網站專文介紹它，Anthropic 圍繞它重新設計了 Claude Code 的架構，Stripe 靠它每週生成數千個 AI PR，Datadog 用它建構了可觀測性閉環。甚至連 Manus 都用同一個模型重寫了五次 Harness，因為他們發現——真正的技術護城河不在模型，而在環境。

這篇文章會帶你從頭到尾搞懂 Harness Engineering。不是那種泛泛而談的概念介紹，而是真的能讓你在讀完之後，回去就開始動手改善你團隊 AI 工作流的那種深度。

從 Prompt 到 Harness：AI 工程的三次範式躍遷

harness-engineering-three-paradigms

要理解 Harness Engineering 為什麼重要，得先回頭看這四年來 AI 工程實踐的演變。每一代範式的誕生，都是因為前一代撞上了天花板。

第一代：Prompt Engineering（2022-2024）

關注點：「我該怎麼說」

那是個人人都在研究 prompt 技巧的年代。Few-shot learning、Chain-of-thought、Role-playing，每個人的筆記本裡都存著幾百條精心調校的 prompt。我們相信，只要找到那個「完美的指令」，AI 就能給出完美的回答。

這個信念在簡單任務上成立。但當任務變複雜——需要多步驟推理、需要記住前面的對話、需要存取外部工具——單一 prompt 就力不從心了。你沒辦法在一條指令裡塞下整個專案的架構文檔、所有的 API 規格、再加上「記得跑測試」。

第二代：Context Engineering（2025）

關注點：「模型能看到什麼」

2025 年中，Andrej Karpathy 拋出了那個改變遊戲規則的類比：

LLM 是 CPU，context window 是 RAM，而你是負責載入正確資訊的作業系統。

這就是 Context Engineering 的核心。不再執著於怎麼「問」，而是專注於怎麼「餵」。RAG、Memory System、Tool Definition、Structured Context Injection——所有技術都圍繞著一個問題：如何在有限的上下文窗口裡，放入對當前任務最有用的資訊。

Context Engineering 是一個巨大的進步。但它有個致命的盲點：它仍然只管理單一 Agent 的視角。

當你需要多個 Agent 協作、需要在 Agent 完成工作後驗證結果、需要在 Agent 犯錯時自動回滾——Context Engineering 幫不了你。管理上下文窗口是必要的，但它只是拼圖的一塊。

第三代：Harness Engineering（2026）

關注點：「我該建什麼系統」

Harness Engineering 不是取代前兩代，而是把它們吸收為子模組。Bits Bytes NN 的分析文章用了一個精闢的比喻：

「Harness Engineering 包含 Context Engineering，Context Engineering 包含 Prompt Engineering。Prompt Engineering 沒有死——它被升職了，成為更大系統的一個子模組。」

Chad Fowler 把這個現象叫做「嚴謹性的遷移」（Relocating Rigor）：工程紀律從來沒有消失，只是不斷地搬家——從 prompt 搬到 context，從 context 搬到 harness。

讓我用一張表來說清楚三者的差異：

世代	核心問題	比喻	局限
Prompt Engineering	怎麼「說」	寫一封完美的信	無法處理多步驟、缺乏記憶
Context Engineering	模型「看」什麼	附上所有相關附件	只管單一 Agent 的視角
Harness Engineering	建什麼「系統」	設計整個郵務系統	仍在發展中（見後文）

拆解 Harness：Guides x Sensors 技術框架

harness-engineering-guides-sensors-matrix

理解了「為什麼」之後，來看「是什麼」和「怎麼做」。

2026 年 4 月，Thoughtworks 的傑出工程師 Birgitta Böckeler 在 Martin Fowler 的網站上發表了一篇文章，提供了目前最結構化的 Harness Engineering 技術框架。我認為這是目前最值得每個工程師讀的一篇文章——它不只是概念，而是一套可操作的心智模型。

兩大控制機制：前饋與回饋

Harness 的核心是兩種控制機制的組合：

Guides（引導 / 前饋控制） 在 Agent 行動之前介入。它們告訴 Agent 「好的程式碼長什麼樣」、「這個專案的架構規則是什麼」、「做完之後要怎麼測試」。

具體來說，這些是 Guides：

AGENTS.md / CLAUDE.md 檔案
架構文檔和設計規範
Skills（例如 /how-to-test）
MCP Server 提供的知識存取

Sensors（感測器 / 回饋控制） 在 Agent 行動之後介入。它們觀察 Agent 做了什麼，然後產生修正訊號。

具體來說，這些是 Sensors：

ESLint、semgrep 等 linter
TypeScript type checker
測試套件
AI Code Review

這兩者缺一不可。Böckeler 說得很直白：

只有前饋？Agent 編碼了規則但永遠不知道規則有沒有被遵守。只有回饋？Agent 不斷重複犯同樣的錯誤。

兩種執行類型：計算型與推理型

在前饋和回饋之外，還有另一個維度的分類：

Computational（計算型）——確定性的、快速的、由 CPU 執行。結果是二元的：過或不過。例子包括 type checker、linter、結構分析工具。

Inferential（推理型）——概率性的、較慢的、由 GPU/NPU 執行。結果是判斷性的：「這段程式碼可能有安全漏洞」。例子包括 AI code review、LLM-as-judge。

2x2 矩陣：完整的 Harness 地圖

把這兩個維度交叉，就得到了 Harness Engineering 的完整地圖：

	Computational（確定性）	Inferential（推理性）
Guide（前饋）	LSP、TypeScript 型別系統、架構文檔	AGENTS.md、AI 生成規劃、Skills
Sensor（回饋）	ESLint、semgrep、coverage 檢查	AI Code Review、Architecture Review

一個成熟的 Harness 需要四個象限都有覆蓋。大部分團隊的問題是只有左下角（一個 linter 加幾個測試），卻缺少右上角（系統性的前饋引導）和右下角（推理型的語義審查）。

Steering Loop：讓 Agent 自我修正的迴路

這些元素組合起來，形成了一個「轉向迴路」（Steering Loop）：

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]flowchart TD
    A[Guides 前饋控制] --> B[Agent 生成程式碼]
    B --> C[Sensors 回饋控制]
    C --> D{通過?}
    D -->|否| E[Agent 自我修正]
    E --> B
    D -->|是| F[人工審查]
    F --> G[整合合併]
    G --> H[Pipeline 再次驗證]
    H --> I{通過?}
    I -->|否| E
    I -->|是| J[部署]

OpenAI Codex 團隊有一個特別巧妙的做法：自定義 linter 的錯誤訊息裡直接包含修復指示。這是一種「正向的 prompt injection」——當 Agent 的程式碼觸發了 linter 錯誤，錯誤訊息本身就告訴 Agent 該怎麼修。這讓回饋迴路的效率倍增。

三大 Harness 模板

Böckeler 還定義了三種可複用的 Harness 模板，你可以根據需求選擇性地建構：

1. Maintainability Harness（可維護性）

目標：命名規範、檔案結構、日誌格式的一致性
工具組合：自定義 linter（計算型感測器）+ AI style review（推理型感測器）
適用：所有專案

2. Architecture Fitness Harness（架構適配性）

目標：防止架構漂移、依賴違規、API 不一致
工具組合：dep-cruiser + structural tests + AI architecture review
適用：中大型專案、多 Agent 協作場景

3. Behaviour Harness（行為正確性）

目標：確保功能符合規格書
工具組合：測試套件（回饋）+ 規格文件（前饋）+ 人工審查
適用：有明確需求規格的功能開發

模型驅動的雙重革命

harness-engineering-model-driven-comparison

讀到這裡你可能會有個疑問：這跟「模型驅動」有什麼關係？

答案是：Harness Engineering 正在開啟一種全新形態的模型驅動開發。但要理解這個「新」，得先知道「舊」。

舊世界：Model-Driven Engineering (MDE)

如果你有軟體工程的學術背景，你可能聽過 MDE——Model-Driven Engineering。這是一個起源於 2000 年代的軟體開發方法論，核心想法是：用抽象模型（UML、SysML、DSL）來驅動程式碼生成。

你畫一張 UML 類別圖，轉換引擎幫你自動生成對應的 Java 程式碼。理論上很美好：人類專注於高層設計，機器負責低層實現。

但 MDE 在實務上一直受限於轉換規則的僵硬性。真實世界的需求太複雜、太多邊角案例，導致自動生成的程式碼經常需要大量手動修改。學術界從未停止研究（光是 arXiv 上就有一篇分析 98 篇論文的系統性回顧），但產業採用率始終有限。

新世界：AI 模型驅動的 Harness Engineering

Harness Engineering 可以被視為 MDE 在 AI 時代的精神繼承者——但換了一個完全不同的「模型」。

維度	傳統 MDE	Harness Engineering
「模型」是什麼	UML/SysML 抽象圖	LLM / Foundation Model
驅動方式	模型 → 轉換引擎 → 程式碼	模型 → Agent 迴路 → 程式碼
人類角色	繪製模型圖	設計執行環境和約束
自動化程度	模板化生成	端到端自主開發
驗證方式	模型一致性檢查	Guides + Sensors 全方位驗證
知識表示	元模型、DSL	AGENTS.md、Skills、MCP Server
適應性	靜態轉換規則	動態學習 + 自我修正迴路

兩者的核心共通點驚人地一致：都追求抽象化、都靠約束確保品質、都把領域知識編碼為機器可處理的形式。

差別在於，傳統 MDE 的「模型」是人類手繪的抽象圖，而 Harness Engineering 的「模型」是能理解自然語言、能自主推理的 LLM。這意味著：

不再需要嚴格的 DSL 語法——用 Markdown 寫的 AGENTS.md 就夠了
不再受限於預定義的轉換規則——LLM 能處理前所未見的需求
不再是「生成一次就完事」——Agent 能在持續的回饋迴路中自我修正

這是一個根本性的轉變：從「模型驅動程式碼生成」進化為「AI 模型驅動軟體開發」。

學術界已經注意到這個趨勢。MDE4AI（用 MDE 方法開發 AI 系統）和 AI4MDE（用 AI 增強 MDE）兩個研究方向正在快速發展。2026 年的 MDEML 研討會和 MDE4SA 國際研討會都把 AI 與模型驅動的交叉列為核心議題。

但在產業實踐層面，Harness Engineering 已經跑在學術研究的前面了。

實戰解剖：五大企業如何建構 Harness

harness-engineering-enterprise-practice

理論講完了，來看真實世界。五家公司的實踐，五種不同的切入角度，但都指向同一個結論。

OpenAI Codex 團隊：零行人工程式碼的實驗

這是最具標誌性的案例。Ryan Lopopolo 帶領團隊從一個空的 git repository 開始，完全靠 Codex Agent 構建了一個完整軟體產品——大約 100 萬行程式碼，零行是人類手寫的。

他們怎麼做到的？

Repository Knowledge as System of Record：所有知識都編碼在代碼庫內部。一個結構化的 docs/ 目錄包含架構圖、execution plans、設計規範。Agent 不需要存取任何外部知識庫——一切都在 repo 裡。

自定義 Linter 即 Sensor：他們為專案量身打造了一系列 linter，不只檢查格式問題，更關鍵的是——linter 的錯誤訊息本身就包含修復指示。當 Agent 違反了命名規範，錯誤訊息會直接說「請將 fooBar 改為 foo_bar，因為本專案使用 snake_case」。這等於在回饋迴路裡埋入了前饋指引。

Garbage Collection Agent：排程執行的 Agent 定期掃描整個 codebase，找出文檔不一致、架構違規、技術債。發現問題就自動提交修復 PR，大部分在一分鐘內自動 merge。這是持續性的、小額的品質投資，取代了傳統的週期性大重構。

Agent 自主 PR 流程：Agent 撰寫 PR → 先請其他 Agent review → 回應 review 意見 → 持續迭代 → 所有 Agent reviewer 滿意後 → squash & merge。人類只在高層設計決策時介入。

Anthropic Claude Code：三代理 Harness 架構

Anthropic 的方法來自一個核心洞察：模型無法可靠地評估自己的工作。他們的解決方案帶有 GAN（生成對抗網路）的影子——把生成和評估拆成不同的 Agent：

Agent	角色	職責
Planner	規劃者	把產品規格分解為可執行的任務列表
Generator	生成者	一次實作一個 feature，保持增量開發
Evaluator	評估者	驗證生成結果，回饋修正指令

另一個關鍵創新是 Initializer Agent。在第一個 context window 裡，一個專門的初始化 Agent 會設定整個工作環境：建立 init.sh 腳本、創建 claude-progress.txt 進度追蹤檔案、做第一個 git commit。這樣後續的 coding agent 每次啟動時，都能從檔案系統中恢復完整的上下文。

這套架構讓 Claude Code 能處理多小時的長時間自主開發任務，而不會在中途迷失方向。

Stripe Minions：每週數千個 AI PR

Stripe 的 Minions 系統展示了 Harness Engineering 在大規模落地時的樣貌：

每週生成數千個 AI Pull Request
每個 PR 都在隔離的沙箱中執行測試
Agent 讀取測試失敗訊息 → 診斷問題 → 修復程式碼 → 重新跑測試
Harness 控制最大迭代次數（通常 3-5 次）
超過迭代上限未通過？自動升級給人類工程師

他們的經驗揭示了一個關鍵原則：Harness 需要有明確的退出條件。讓 Agent 無限制地重試只會浪費 token 和時間。設定一個上限，超過就果斷升級。

Datadog：可觀測性閉環

Datadog 的 Engineering Blog 提出了 Harness-first Engineering 概念，他們的獨特貢獻在於把生產環境的可觀測性納入 Harness 的閉環：

Agent 生成 → Harness 驗證 → 部署 → Production Telemetry 驗證
     ↑                                              │
     └──────── 回饋更新 Harness ←──────────────────┘

他們用形式化方法（Formal Methods）來表達系統不變量（Invariants），然後讓 Agent 自動生成對應的 property tests。而 production 的 metrics、logs、traces 是最終的真實來源——當模型行為和生產數據出現偏差時，回饋不只修正 Agent，更修正 Harness 本身。

Datadog 的觀點很犀利：

「沒有可觀測性，迴路就沒有閉合。」

Manus：五次重寫的啟示

Manus 的案例最簡單也最有說服力：6 個月內用相同的模型重寫了 5 次 Harness。每次重寫帶來的效能提升都比換模型大得多。

這直接證明了 Aakash Gupta 在 Medium 上的觀點：

「更好的模型讓 Harness 更重要，而不是更不重要。」

2026 年 3 月 30 日，OpenAI 甚至開源了 codex-plugin-cc——一個讓你在 Claude Code 裡直接呼叫 Codex 的官方插件。一家 AI 公司把自己的 Agent 做成了競爭對手工具的插件？因為他們想通了：**護城河在 Harness，不在模型。**與其讓使用者不用 Codex，不如讓 Codex 在任何 Harness 裡都能跑。

動手做：你的第一個 Harness

harness-engineering-hands-on

理論和案例都講完了，該你了。這一節我會給你一個可以立刻開始的漸進式路徑。

Level 1：建立你的第一個 Guide

在專案根目錄建立一個 AGENTS.md（如果你用 Claude Code 就叫 CLAUDE.md）。這是最基本的前饋控制：

# AGENTS.md

## 專案概覽
這是一個 Next.js 14 + TypeScript + Prisma 的 SaaS 應用。

## 架構規則
- 所有 API routes 放在 `src/app/api/` 下
- 業務邏輯放在 `src/services/`，不允許在 route handler 中直接寫
- 資料庫查詢必須透過 Prisma service layer
- 禁止在 client component 中直接呼叫資料庫

## 命名規範
- 檔案名：kebab-case（例：user-service.ts）
- 函式名：camelCase
- 型別名：PascalCase
- 環境變數：SCREAMING_SNAKE_CASE

## 測試要求
- 每個 service 函式必須有對應的單元測試
- 測試檔案放在同層目錄的 `__tests__/` 資料夾
- 使用 vitest 執行測試：`npm run test`

## 安全規則
- 所有 API endpoint 必須有 authentication middleware
- 使用者輸入必須用 zod 驗證
- 禁止在 client-side 暴露 API keys

這份文件不需要很長。重點是把你團隊裡「大家都知道但沒有寫下來」的規則明確化。因為 Agent 不是你的同事，它不會在茶水間聽到這些潛規則。

Level 2：添加你的第一個 Computational Sensor

有了 Guide 之後，你需要至少一個 Sensor 來驗證 Agent 是否遵守了規則。最簡單的起點是 ESLint 自定義規則：

// .eslintrc.js - 自定義規則範例
module.exports = {
  rules: {
    // 禁止在 route handler 中直接引入 prisma
    'no-restricted-imports': ['error', {
      patterns: [{
        group: ['@prisma/client'],
        // 關鍵：錯誤訊息就是修復指示
        message: '不要在 route handler 中直接引入 Prisma。' +
                 '請改用 src/services/ 中的 service layer。' +
                 '範例：import { getUserById } from "@/services/user-service"'
      }]
    }],
  },
  overrides: [
    {
      files: ['src/app/api/**/*.ts'],
      rules: {
        'no-restricted-imports': ['error', {
          patterns: [{
            group: ['@prisma/client'],
            message: '在 API route 中禁止直接使用 Prisma。請透過 service layer 操作資料庫。'
          }]
        }]
      }
    }
  ]
};

注意看那個 message 欄位——這就是 OpenAI 團隊說的「正向 prompt injection」。當 Agent 的程式碼觸發這條規則，它不只知道「哪裡錯了」，還知道「該怎麼改」。

Level 3：加入 CI Pipeline

把 Sensor 整合進 CI，讓每個 Agent PR 都自動驗證：

# .github/workflows/agent-harness.yml
name: Agent Harness Check
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  harness-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Install dependencies
        run: npm ci
      
      # Computational Sensors
      - name: Type Check
        run: npx tsc --noEmit
      
      - name: Lint Check
        run: npx eslint . --max-warnings 0
      
      - name: Unit Tests
        run: npm run test -- --coverage
      
      - name: Dependency Check
        run: npx depcheck
      
      # Architecture Fitness
      - name: Import Structure Check
        run: npx dependency-cruiser src --config .dependency-cruiser.cjs

Level 4：引入 Inferential Sensor

當 Computational Sensor 覆蓋了基本面之後，可以加入 AI 驅動的語義審查。如果你用 Claude Code，可以建立一個 code review skill：

# .claude/skills/code-review/SKILL.md

## 任務
審查最近的程式碼變更，重點關注：
1. 業務邏輯是否符合 PR 描述的意圖
2. 是否有潛在的安全漏洞（SQL injection、XSS、未驗證的輸入）
3. 是否有效能問題（N+1 查詢、不必要的重新渲染）
4. 是否遵守 AGENTS.md 中定義的架構規則

## 輸出格式
- PASS：沒有發現問題
- WARN：發現非阻塞性問題，建議改善
- FAIL：發現必須修復的問題，附帶修復建議

Level 5：建立可觀測性

最後一層是追蹤 Agent 的行為指標。你不需要 Datadog 那麼複雜的基礎設施——一個簡單的 metrics dashboard 就夠起步了：

追蹤這些指標：

Agent PR 的首次通過率（越高代表 Guides 越有效）
平均修正迭代次數（越低代表 Sensors 越精準）
Agent 生成程式碼的測試覆蓋率
人工審查駁回率（越低代表 Harness 越成熟）

當這些指標開始下降，就是你需要更新 Harness 的信號。

踩坑紀錄：Harness Engineering 的五個陷阱

harness-engineering-pitfalls

不是建了 Harness 就萬事大吉。根據各家的實踐經驗和我的觀察，這五個坑最常讓人跌進去。

陷阱一：過度約束扼殺 Agent 創造力

OpenAI 的文章裡有一句很關鍵但容易被忽略的話：

「在人類優先的工作流中，這些規則可能顯得過於死板。對 Agent 來說，它們是乘數效應。」

但「乘數效應」有個前提——約束要在正確的層級。如果你把 AGENTS.md 寫成了 200 行的微操手冊，Agent 的每一步都被限死，那你得到的只是一個很昂貴的 code template。

解法：約束架構決策（「API endpoint 必須走 service layer」），但不要約束實作細節（「變數名必須以 data 開頭」）。給 Agent 自由度去解決問題，但用護欄確保它在正確的路上。

陷阱二：Harness 本身的 bug

"Who watches the watchmen?"

你的 linter 規則可能有漏洞。你的 AI reviewer 可能有偏見。你的測試套件可能覆蓋率不足。Harness 不是完美的——它本身也需要維護和改善。

解法：Datadog 的做法值得參考——用 production telemetry 來驗證 Harness 的有效性。如果一段通過了所有 Sensor 的程式碼在生產環境出了問題，不只要修 bug，更要回頭問「為什麼 Harness 沒抓到？」然後更新 Harness。

陷阱三：只有回饋沒有前饋

我見過太多團隊的 Harness 是這樣的：讓 Agent 寫程式碼 → 跑測試 → 失敗 → Agent 改 → 跑測試 → 失敗 → Agent 改 → ……循環 5 次之後超時。

問題不在回饋不夠，而在前饋不足。如果 Agent 從一開始就不知道正確的架構長什麼樣，它就是在盲人摸象。

解法：投資前饋。寫好 AGENTS.md，提供架構文檔，建立 Skills。讓 Agent 在動手之前就知道「好的結果」長什麼樣。前饋的投資回報率遠高於回饋。

陷阱四：忽略推理型感測器

很多團隊覺得有 linter 和測試就夠了。但 Computational Sensor 只能抓到結構性問題——命名錯誤、型別不匹配、依賴違規。

語義層面的問題呢？

Agent 可能寫了一段「技術上正確但精神上錯誤」的程式碼——通過了所有測試，符合所有 lint 規則，但完全沒實現使用者真正想要的功能。這種問題只有 Inferential Sensor 才能捕捉。

解法：在你的 Harness 裡加入至少一個 AI code review 步驟。它不需要完美——即使只能抓到 60% 的語義問題，也比 0% 好。

陷阱五：把 Harness 當一次性工作

建好 AGENTS.md 和幾條 lint rule，然後就再也不更新了？

OpenAI 團隊有一個核心原則：

「當 Agent 犯錯時，把它當作信號：找出缺少什麼——工具、護欄、文檔——然後補回去。」

Harness 是活的。它需要隨著專案演進、隨著模型更新、隨著每一次 Agent 犯錯而持續改善。最好的做法是把 Harness 維護本身也自動化——就像 OpenAI 的 Garbage Collection Agent 那樣。

2026 下半場：Harness Engineering 何去何從

harness-engineering-future

最後，讓我對下半年的趨勢做幾個判斷。

趨勢一：Harness 成為真正的技術護城河

OpenAI 在 Claude Code 裡發布 Codex 插件這件事，已經說明了一切。當模型提供商自己都承認「護城河不在模型」的時候，遊戲規則已經改變了。

2026 下半年，我預期會看到更多企業把 Harness 視為核心資產——就像十年前對待 CI/CD pipeline 一樣。差別在於，Harness 的設計品質直接決定了 AI Agent 的產出品質。

趨勢二：AGENTS.md 走向標準化

目前 Claude Code 用 CLAUDE.md，Cursor 用 .cursor/rules/，Codex 用 docs/ 目錄。這種碎片化不會持續太久。AGENTS.md 正在成為事實上的跨 Harness 標準——一份文件，多個 Agent 都能讀懂。

Escape.tech 的報導提到一個有趣的做法：用 symlink 讓 CLAUDE.md 指向 AGENTS.md，這樣你只需要維護一份文件。

趨勢三：Harness 自己也會被 AI 優化

GitHub 上的 AutoAgent 專案已經在做這件事：給它一個任務和一個 benchmark，它會在一夜之間自動迭代 system prompt、tool 配置、agent 編排策略——保留得分提升的變更，捨棄降低的。

Harness Engineering 的 Harness Engineering——meta 到了極致，但完全合理。

趨勢四：QA 角色的根本重塑

Test Collab 的分析說得好：

「QA 一直走在抽象化的弧線上。手動測試讓位給自動化測試，自動化測試讓位給 AI 輔助測試。Harness Engineering 是這條弧線的下一步。」

QA 工程師的工作不再是寫測試，而是設計讓 Agent 能自主測試的環境。這意味著：設計 agent-legible 的測試環境、審查 agent 生成測試的覆蓋缺口、擁有回饋迴路的持續改善。

對不同角色的建議

如果你是...	你今天該做的第一件事
CTO / Tech Lead	選定一個主要 Harness（Claude Code 或 Codex），建立 `AGENTS.md`，要求所有 Agent PR 通過 CI + 自動化 review。設定 per-session 成本告警
軟體工程師	把你腦中「大家都知道」的規則寫進 `AGENTS.md`。為你最常見的 Agent 錯誤建立一條自定義 lint rule
QA 工程師	評估你的測試環境對 Agent 的「可讀性」。Agent 能自己啟動你的 app 嗎？能讀懂你的 log 嗎？能截圖並推理 UI 狀態嗎？
硬韌體工程師	關注 MDE4AI 方向：用 DSL + 模型驅動方法定義嵌入式 ML 任務的自動化管線

結語：建軟體的方式沒有變，變的是你在哪一層工作

Louis Bouchard 的總結我覺得說得最到位：

「Prompting 是最簡單的部分。可靠性才是真正的工作。」

Harness Engineering 告訴我們的不是「工程師要被取代了」，而是工程紀律的表現形式正在改變。

我們不再一行一行地打字寫程式碼。但我們設計 Agent 能理解的約束、我們建構驗證 Agent 產出的感測器、我們打造讓 Agent 能在其中自由但安全地工作的環境。

寫程式碼的活兒確實在被 Agent 接管。但設計那個讓 Agent 能寫出好程式碼的世界？那依然是我們的工作。而且比以前更有趣。

如果你今天只做一件事，就去你最重要的專案根目錄建一個 AGENTS.md。寫下你團隊的架構規則、命名規範、測試要求。不需要完美，不需要很長。

因為當你的 Agent 下次犯錯的時候，你不會再只是嘆氣然後手動修復。你會問自己：「Harness 缺了什麼？」然後補上它。

這才是 2026 年工程師該有的條件反射。

台灣政治與媒體利益綁定：從黨國到資本的未竟之路

政媒綁定-信任破碎

2025年，無國界記者組織（RSF）公布最新的世界新聞自由指數，台灣排名第24，在亞洲名列前茅，甚至超越許多歐洲老牌民主國家。

但同一年，路透新聞研究所的數位新聞報告這是一個非常弔詭的畫面。一個新聞「自由」排名如此靠前的國家，它的人民卻幾乎不相信自己的媒體在說真話。

問題到底出在哪裡？

答案很可能藏在一個不太好聽的詞彙裡：政媒利益綁定。也就是說，台灣的媒體不是不自由，而是這個自由早就被政治力量和商業利益層層收編，變成了一種帶有特定顏色的「自由」。

這篇文章試圖拆解這個結構。不站藍，不站綠，只站在一個想搞懂「我們的媒體到底怎麼了」的公民立場。

從黨國的喉舌到資本的附庸：七十年的媒體困局

政媒綁定-媒體演變

要理解今天的問題，得先回到起點。

1949年國民黨政府遷台後，媒體就是威權統治的重要工具。「老三台」——台視、中視、華視——分別由省政府、國民黨與軍方掌控。報紙受到嚴格的報禁管制：限證（不發新執照）、限張（限制版面數量）、限印（限制印刷地點）。在這個體制下，媒體的角色很單純：替黨國說話。

1987年解嚴、1988年報禁解除，長期被壓縮的能量突然釋放。媒體數量在幾年內暴增，有線電視頻道遍地開花。但問題是，在這個「自由爆炸」的過程中，許多民主社會應該慢慢建立的基礎價值——比如新聞倫理規範、所有權透明機制、公共問責制度——根本來不及跟上。

政治大學新聞學系助理教授李怡志在路透報告的評論中一語道破：台灣的新聞產業在「爆發的階段，有些基本的價值並沒有時間被好好發展」。

2003年是一個看似重要的里程碑。立法院通過廣電三法修正，明文規定「黨政軍退出媒體」。國民黨被迫出售中視，華視公共化，台視民營化。表面上，黨國控制媒體的時代結束了。

但真的結束了嗎？

台灣媒體觀察教育基金會的一篇深度分析文章標題已經給出答案：「從黨國到資本，台灣媒體從未獨立。」 黨政軍的股權退出了，但政治力量馬上找到了新的控制手段——透過資本、標案和派系網絡，以更隱蔽的方式重新進場。

不是單方壟斷，而是「輪替壟斷」：藍綠各有自己的媒體帝國

政媒綁定-藍綠操控

很多人討論台灣的政媒問題時，習慣只看到「另一邊」的問題。藍營的人會說三立、民視是「綠色黨媒」；綠營的人會說旺中集團是「紅色媒體」。雙方各執一詞，吵了十幾年。

但如果你願意退後一步，看整體結構，會發現一個不太舒服的事實：藍綠兩邊都在做同樣的事情。

政治大學《問題與研究》期刊上一篇具有開創性的學術論文，提出了「雙重政商關係」的分析架構。這篇研究以旺中集團和三立集團為個案，揭示了台灣媒體同時受到「在地政商關係」和「跨海峽政商關係」的雙重影響。

先看泛藍這邊。旺旺集團董事長蔡衍明2008年以204億台幣買下中時集團，一口氣擁有了《中國時報》、《工商時報》、中天電視、中國電視公司。蔡衍明的核心事業在中國大陸，他與北京的政商關係極為緊密——這一點後面會再詳談。而聯合報系、TVBS等媒體，雖然與中國的連結沒有旺中那麼直接，但長期被視為國民黨的輿論盟友。

再看泛綠這邊。三立集團創辦人林崑海自高雄發跡，與民進黨「謝系」展開合作，後來自立門戶成立「湧言會」（又稱「海派」），成為民進黨內部的重要派系。根據政大的研究，湧言會曾掌握1席中常委、4席中執委、1席中評委和4席立委。這不是什麼暗盤交易，而是公開的、制度化的政媒關係。當民進黨執政時，三立與政府的「組織關係」和「經濟/財務關係」同步強化。

自由時報的情況也值得注意。創辦人林榮三同時是聯邦銀行的大股東，這種「媒金不分離」的結構，在反媒體壟斷法的討論中屢屢被提及，但因為涉及的利益結構太複雜，始終無法被有效規範。

卓越新聞獎基金會曾引述台灣藝術大學教授王維菁的分析：「政商媒的利益共構集團是非常令人擔憂的現象。媒體大亨並不是靠媒體的本業在賺錢，而是依賴土地開發、炒地皮；地方政府也樂意配合媒體大亨的投資行為，希望藉由媒體使政績或政治人物的形象得以傳播。」

換句話說，這不是「藍色的問題」或「綠色的問題」。這是一個系統性的問題——誰執政，誰就有更大的資源分配權，而媒體就會向掌握資源的那一邊靠攏。

95億的隱形韁繩：當政府成為最大廣告主

政媒綁定-金錢流向

如果政媒關係只是「誰挺誰」的意識形態問題，那還算單純。真正讓這個結構難以撼動的，是錢。

台灣政府早已是全國最大的廣告主之一。早在2000年代初期，《天下雜誌》的調查報導就指出，中央加上地方政府的媒體購買預算「絕對超過30億」，在所有廣告主中排名前三。當時的新聞局統籌的中央部會媒體集中採購金額，一年就達10.9億。

更令人不安的是，這些預算不只是買廣告版面，還會直接買「新聞」。曾在中國電視公司服務的台藝大教授劉蕙苓曾公開揭露電視媒體的「業配」定價：一則新聞10萬，還有「買一送一」的優惠。A單必採必播，B單必採不必播，C單不採不播但要去——這套分級制度，在台灣電視台裡曾經是公開的秘密。

2011年預算法修正，禁止政府進行置入性行銷。這看起來是進步，但問題並沒有消失，只是換了一件外衣。政府改以「宣導案」、「委託服務」、「活動標案」等名義繼續下單。

到了民進黨執政時期（2016-2024），這個問題被放大檢視。根據立法院預算中心的報告及國民黨立委王鴻薇援引工程會資料的質詢，三立和民視在這9年間共取得約95億元的政府標案——民視331項標案得標55.8億，三立237項標案得標39.9億，平均每年拿走10到11億。2023年的反詐騙媒體行銷標案總計4846萬，民視一家就拿走了94%。

而且，這些標案大量採用「限制性招標」，也就是不經公開競爭，直接指定得標廠商。財政部賦稅署甚至曾經直接在標案名稱上寫明「在聯合報刊登」、「在中國時報辦理」。

不過，在批評之前，有一件事必須說清楚：這不是民進黨獨有的行為。 資深媒體人的分析指出，民視在國民黨2008年開始執政的那幾年，依然是拿到最多專案的電視台；而TVBS在新北、台北等藍營執政的地方，拿到的大型活動標案（如跨年晚會、聖誕城）金額也是九位數以上。藍綠各取勝場，只是戰場不同。

真正的問題在於結構本身：當媒體的財務命脈繫於政府標案，它還有可能獨立監督政府嗎？一個每年從政府手中接下數億元生意的電視台，要怎麼理直氣壯地做出批評執政者的深度調查報導？

這就是那條隱形的韁繩。不需要打電話到編輯台施壓，光是金錢的流向，就足以讓新聞的天秤不知不覺地傾斜。

當「報告主任」成為一則國安寓言：中國因素的獨特威脅

政媒綁定-中國因素

如果只有藍綠的內部角力，台灣的政媒問題頂多是「民主的煩惱」。但中國因素的加入，讓這個問題的性質徹底改變——它不再只是新聞品質的問題，而是國家安全的問題。

2008年12月5日，蔡衍明買下中時集團後，面見時任國台辦主任王毅。根據旺旺集團內部刊物《旺旺月刊》的報導照片，蔡衍明向王毅說明收購過程，並表示希望「借助媒體的力量，來推動兩岸關係進一步發展」。王毅當場回應：「如果集團將來有需要，國台辦定會全力支援。」

《天下》雜誌以「報告主任，我們買了中時」為標題加以報導。而蔡衍明對王毅說的那句「我們都有依照上面的指示，好好報導祖國的繁榮」，從此成為台灣政媒關係史上最令人不安的一句話。

此後，中時集團的編輯方針明顯轉向。蔡衍明要求加重中國正面新聞的比例；對六四事件、西藏、新疆等中國官方敏感議題幾乎不報導；甚至在2012年接受《華盛頓郵報》專訪時公開表示「六四天安門事件並沒有死那麼多人」、「批評中國沒人權是一種扭曲」。

2010年，台灣監察院吳豐山監察委員經過半年調查，正式確認中國政府以「置入新聞」的方式購買台灣報紙版面，並對陸委會提出糾正案。監察院掌握的合約書顯示，旺中設於北京的公司專門招攬中國政府廣告，再轉包台灣媒體，價格常為行情的兩倍以上。

但淡江大學助理教授黃兆年在「菜市場政治學」的分析中指出，北京的影響力遠不只限於旺中這類「統媒」。他將中國對台灣媒體的控制歸納為三種途徑：經濟吸納、規範擴散、假訊息輸出。

最令人意外的發現是：連被視為「台派」的媒體也曾受到影響。

民視曾在2009年婉拒播出講述疆獨精神領袖熱比婭事蹟的紀錄片《愛的十個條件》；三立在2011年將「台劇」改名為「華劇」，以利進入中國市場；2012年，三立更停播了收視率頗高的政論節目《大話新聞》，據報導與中國廣電總局的壓力有關。2009至2017年間舉辦的「海峽媒體峰會」，不只旺中、聯合報參加，三立、中央社、綠色和平電台也多次派員出席，並簽署符合中國式媒體規範的「共同建議書」。

Freedom House 的報告明確指出：「在中國有商業利益的企業集團控制了台灣媒體版圖的很大一部分，加上合理辯論與黨派鬥爭的結合，使台灣長期暴露於中國的滲透之下。」

這就是台灣的獨特困境。在其他民主國家，政媒關係是內政議題；但在台灣，它同時是外交議題和國安議題。而這個「中國因素」也經常被各政黨工具化——綠營用它來攻擊藍營「賣台」，藍營則反指綠營以國安為名打壓異見媒體。結果，真正的問題始終沒有被好好面對。

不管左轉右轉都被罵：NCC的不可能任務

政媒綁定-NCC困局

在這個政媒糾葛的叢林裡，國家通訊傳播委員會（NCC）的處境大概是全台灣最尷尬的。作為獨立機關，它理論上應該超越藍綠，依法行政。但現實是，不管它做什麼決定，都會被某一方痛罵。

2020年的中天換照案是最具指標性的事件。NCC以中天新聞台在6年執照期內違規25件、核處罰款1153萬元，認定其「未能落實新聞專業、內控與自律機制失靈」，駁回換照申請。這是台灣首次有新聞台因為新聞品質問題而被拒絕換照。

綠營拍手叫好，認為這是「依法行政」的典範。但藍營群情激憤，指控這是政治打壓。中天隨後提出行政訴訟，而令NCC難堪的是，法院在後續的15次訴訟中，NCC全數敗訴。法院與NCC的判斷南轅北轍，這到底是NCC太嚴，還是法院太寬？恐怕沒有簡單的答案。

然後是鏡電視案。2022年，這家新成立的電視台在取得執照後不到一個月，就爆發董事長政變：原董事長陳建平被指稱「干預新聞自由」，接替的李永豐上任11天就閃電辭職，前後一年內換了5任董事長。更嚴重的是，流出的錄音檔顯示府院高層疑似介入人事和財務安排，但相關案件「司法檢調機關卻辦都不敢辦、動都不敢動」。NCC在整個過程中幾乎沒有發揮監理功能。

到了2023-2024年，三立集團大股東被發現違規持有中嘉有線電視系統的27%股權，跨越了媒體壟斷的紅線。但NCC僅要求「限期改善」，與對中天的雷厲風行形成鮮明對比。

2024年底的TaiwanPlus事件更讓公共媒體的獨立性蒙上陰影。公視旗下的英語國際頻道TaiwanPlus，因為記者在報導美國大選時使用了「重罪犯」（convicted felon）形容川普——這個用語BBC也在使用——而遭到國民黨、民眾黨立委和文化部長的施壓，最終被迫下架修改報導。Taiwan Insight 的分析指出，這暴露了台灣公共媒體缺乏「堅實的防火牆」來抵禦政治干預。

到了2026年初，藍白陣營在立法院推動廣電三法修正案。媒體改造學社發出嚴正聲明，指出修法方向試圖將黨政軍退出媒體的「結構性禁止」降格為「形式規範」，同時大幅弱化新聞頻道的換照退場機制，使得「即使新聞品質長期劣化、違規紀錄累積，新聞頻道仍可持續占用公共頻道」。

NCC的困局，本質上是台灣政治極化的縮影。當每一個監管決定都被解讀為政治立場表態，當「獨立」二字在藍綠交互指控中失去意義，這個機關就陷入了一種結構性的癱瘓。

電視碎片化、手機接管一切：數位時代的新型態綁定

政媒綁定-數位轉型

如果你以為問題會隨著「年輕人不看電視」而自然解決，那恐怕太樂觀了。

根據路透2025年報告，台灣民眾使用YouTube獲取新聞的比例已從2021年的38%攀升至46%。Instagram新聞使用率14%、TikTok有10%。數位平台已經超越傳統媒體，成為台灣人的主要新聞來源。

但這個轉變帶來的不是解放，而是另一種形式的困境。

傳統電視台的收入持續萎縮。台灣有線電視的每月費率在過去20多年間不升反降——1998年全國平均588元，2022年已降至500元，但頻道數量卻從65-70個膨脹到147-150個。「越來越多頻道搶食同一塊廣告與收視費資源，越分越少。」當媒體的本業營收不斷下滑，它們對政府標案、對政治資源的依賴就更深。

與此同時，新聞的「平台化」也帶來了新的政治操作空間。各政黨都被指控經營「網軍」——民進黨的「卡神」楊蕙如事件、國民黨被質疑的網路風向操作、民眾黨的「數位行銷策略」，三大黨各有各的數位戰場。Freedom House 2024年的台灣報告指出，三個主要政黨「都各自指控對方僱用或部署網路評論員散布經過操縱的資訊」。

在這個環境下，「新聞」和「宣傳」的邊界變得更模糊。一個看起來像是獨立自媒體的YouTube頻道，背後可能有政黨的資金支持；一篇在社群平台上瘋傳的「分析文章」，可能是精心策劃的風向操作。而台灣目前的法規框架，對這些新型態的政媒綁定幾乎毫無規範能力。

出路在哪裡：從國際經驗看台灣的可能解方

政媒綁定-改革希望

看到這裡，你可能會覺得問題太大、結構太深，根本無解。但其實國際上已經有不少嘗試，值得台灣參考。

強化公共媒體的防火牆。 英國BBC的治理模式是經典範本。BBC的經費來自電視執照費（類似特許費），而非政府預算撥款，這從源頭減少了政治干預的可能。更重要的是，BBC有獨立的董事會和明確的編輯準則，政府官員無法直接介入新聞決策。台灣的公視雖然已有類似架構，但TaiwanPlus事件證明，現行的防火牆還不夠堅實。

建立新聞業永續基金。 澳洲2021年通過的《新聞媒體議價法》（News Media Bargaining Code）要求Google、Meta等數位平台與新聞機構進行商業談判，為使用新聞內容付費。這筆資金直接進入新聞機構，減少了對政府標案的依賴。加拿大也在2023年通過了類似的《線上新聞法》。台灣作為數位平台高度普及的市場（網路使用率超過85%），完全有條件推動類似的制度。

推動反媒體壟斷法。 台灣的反媒體壟斷法從2012年就開始討論，歷經多個版本，至今仍躺在立法院。這部法律的核心目標是建立明確的跨媒體所有權上限、所有權透明機制、以及媒金分離原則。不管藍綠誰執政，都沒有真正推動它通過——因為每一方都有自己不想被規範的利益。但正因如此，這部法律更需要公民社會持續施壓。

改革政府標案分配機制。 最直接的做法是大幅限制限制性招標的使用，建立公開透明的評選標準和外部監督機制。更根本的解方是降低政府標案在媒體營收中的比重——這就回到了上面提到的「永續基金」和「平台付費」的思路。

加強媒體識讀教育。 長遠來看，最根本的改變要從閱聽人開始。當民眾有能力辨識哪些「新聞」其實是置入行銷、哪些「評論」其實是政黨文宣、哪些「獨立」頻道其實有特定金主，政媒綁定的操作空間自然會縮小。芬蘭從小學就開始教媒體素養，台灣也已經在課綱中納入相關內容，但執行的深度和廣度都還遠遠不夠。

媒體的未來，就是民主的未來

回到文章開頭的那個悖論：為什麼台灣的新聞自由排名那麼高，信任度卻那麼低？

因為「自由」只是第一步。沒有被好好使用的自由，跟沒有自由，對公民來說的實際差別可能沒有想像中那麼大。當你打開電視，每一台都在為某個陣營說話；當你滑開手機，每一篇文章都可能是某個利益的載體——你當然不會信任這些媒體，即使你知道它們是「自由」的。

台灣媒體觀察教育基金會說得很好：「媒體越大，民主越小。」 當媒體被資本和政治力量收編，它就不再是監督權力的「第四權」，而是權力結構的延伸。從黨國時代的意識形態工具，到解嚴後的商業器皿，再到今天的政黨傳聲筒——形式一直在變，但媒體的獨立性始終是台灣民主最脆弱的一環。

改變不會從天上掉下來。它需要法律的改革、制度的重建、公民社會的持續監督，以及每一個閱聽人在按下遙控器或滑動螢幕之前，多問自己一句：「這條新聞，是誰付錢讓我看到的？」

這個問題聽起來很簡單。但如果每個人都認真去追問，台灣的媒體環境或許真的會開始不一樣。