《AI Harness 駕輕就熟》是旗標 2026 年 9 月出版的一本書,副書名叫「OpenCode 讓 Vibe Coding 更自由」。我先把結論講完:這本書要解的不是「怎麼讓 AI 寫出程式」,而是「怎麼讓 AI 在一個會長大的專案裡持續寫對」。這兩件事的難度差了一個量級,而市面上絕大多數教學只處理前者。
如果你用 Cursor、Claude Code 或任何 coding agent 做過超過三天的專案,應該很熟悉這個循環:第一天驚為天人,第三天開始重複犯同樣的錯,第七天你花在回頭解釋脈絡的時間已經比自己寫還久。AI Harness 駕輕就熟 整本書在談的,就是怎麼把這個循環切斷。
這篇文章我會拆三件事:書在談的概念到底是什麼、九個章節該怎麼讀,以及我自己在這個部落格上用同一套思路跑了一個多月之後的實際感受。文末有 momo 雙 11 單日限定 66 折 的資訊(原價 NT$820,當天 NT$541)。
合作聲明|本文為旗標科技(FLAG)贊助合作內容,書籍由出版社提供。文中的章節結構、價格與規格皆依出版社官方頁面與 momo 商品頁查核;閱讀心得與適讀判斷為我個人意見,旗標未對內容做事前審閱。文中的購書連結為合作連結。

一、Vibe Coding 爽寫半天,為什麼一擴充就崩壞
先把症狀講清楚。Vibe Coding 最舒服的階段,是專案只有十幾個檔案的時候——你描述需求,AI 產出,跑起來就對了。問題出在專案開始長大之後,而且不是一次崩掉,是慢慢爛掉的。
| 症狀 | 你實際會看到的畫面 | 真正的原因 |
|---|---|---|
| AI 失憶 | 昨天才說過「這個專案用 pnpm」,今天它又跑 npm install | 規則留在對話裡,不在專案裡 |
| 重複改同一個地方 | 修 A 壞 B,修 B 壞 A,來回三次 | 沒有人替它跑測試、看 log |
| Token 越燒越兇 | 同一個需求來回十輪,帳單是第一輪的十倍 | 所有任務都丟給最貴的模型 |
| 換模型就重來 | 想試另一個模型,發現要重新交代整個專案背景 | 脈絡綁在單一工具的 session 裡 |
| 不敢放手 | 每一步都要盯,等於自己寫還多一道 | 權限沒有分級,只能全開或全關 |
這五個症狀有個共通點:它們都不是「AI 不夠聰明」造成的。換成更強的模型,五項全部照樣發生。真正缺的是一套包在 AI 外面、規定它該讀什麼、能動什麼、做完要怎麼驗的機制——這就是 Harness(馬具)這個詞的由來。馬夠快,但沒有馬具你駕馭不了方向。
我自己在 先前那篇 AI Harness 的概念介紹 裡談過這個詞的來源與基本輪廓。這篇則是針對《AI Harness 駕輕就熟》這本書本身——它把抽象概念落成了可以照做的設定檔、指令與專案結構。
二、Prompt、Context、Harness:三層解的不是同一個問題
這本書最值得先記住的一張圖,是它對三個常被混用的詞做的切分。很多人以為自己在「調 Prompt」,其實該調的是更下面那一層。

| 層級 | 回答的問題 | 存活範圍 |
|---|---|---|
| Prompt | 這一次要做什麼 | 一次性。換個說法,結果就變 |
| Context | 現在知道什麼 | 單一 Session。關掉就消失 |
| Harness | 整個專案要怎麼持續做下去 | 跨 Session、跨模型、跨 Agent 平台 |
把這張表看懂,「玄學 Prompt」這四個字就有解釋了:當你只在最上面那層施力,結果當然像擲骰子——因為底下兩層每次都在重置。模型可以一直換,真正值得留下來的是你的 Harness。
這也是為什麼 AI Harness 駕輕就熟 把重心放在 AGENTS.md、權限設定、Subagent 分工這些聽起來不性感的東西上。它們不會讓單次產出變漂亮,但會讓第五十次產出跟第一次一樣可靠。
三、AI Harness 駕輕就熟 的六大骨架
書把 OpenCode 的能力拆成六組,每一組對應上面那張症狀表裡的一項。這是整本書的骨幹,也是我認為它跟一般「工具操作手冊」最大的差別——它是從症狀往回推工具,不是照著功能清單介紹。

1. AGENTS.md × Git:治 AI 失憶
把專案規範、環境設定、測試方式與進度交接寫進 AGENTS.md,跟程式碼一起進版控。重點不是「寫一份文件」,而是這份文件會被每個新 Session、每個新模型自動讀到。書裡另外處理了專案級與全域級該怎麼分,以及 OpenCode 自動相容 CLAUDE.md 的機制——對已經在用 Claude Code 的人,這代表舊專案可以直接接手,不用重寫規則。
2. Agent × Subagent:治一人包辦出錯
把規劃、研究、實作、測試、Code Review 拆給不同角色,各自有獨立的 Context。書裡特別示範了「用獨立 Context 建立客觀的程式碼審查員」——這點我實測很有感:同一個 Agent 自己寫完自己審,幾乎一定說沒問題;換一個沒看過實作過程的 Subagent 來審,才抓得到東西。
3. MCP × Skills:治不會自己驗
用 MCP 把瀏覽器與外部工具接進來,讓 AI 自己開網頁、看 Console、讀 Log 再回頭改;用 Skills 把重複流程封裝成 SOP。書中用的是 Chrome DevTools MCP 與 Playwright MCP,並示範把 Playwright CLI 打包成一個完整測試 Skill。想先補概念的話,我寫過 MCP 的完整解析,以及 MCP 官方規格文件 可以對照。
4. Model × Provider:治 Token 燒爆
這是我認為最容易被低估、但省錢效果最直接的一章。書裡把 OpenCode、Provider、Model 的三層關係講清楚,比較免費、訂閱與 API 三種計費方式,然後給出一個很務實的原則:依任務難度換模型,不要一個模型用到底。規劃跟重構用旗艦模型,跑測試、改錯字、整理格式交給平價模型,成本差距是倍數級的。
5. Permission × Plugin:治 AI 亂做
工具權限分級,高風險操作先問過你。書裡有個做法我覺得很聰明:把確認流程接到 Telegram Bot,人不在電腦前也能決定要不要放行。另外還有隨 Agent 狀態變化的桌面寵物 Plugin(OpenPets)——這段比較像彩蛋,但它示範的是 Plugin 機制本身能做到什麼程度。
6. Claude Code × OpenCode:治被單一工具綁死
規則、需求、Git 紀錄與交接資訊共用,所以你可以在不同 coding agent 之間延續同一個專案。這一條的價值不在今天,在明天——這個領域工具換代的速度,讓「不綁死」本身就是一種保值。
實際動手:你的第一份 AGENTS.md 該寫什麼
六大骨架裡最先該做、成本也最低的就是第一組。很多人卡在「不知道要寫什麼」,所以我把判斷標準講白:凡是你已經對 AI 解釋過兩次以上的事,就該寫進去。規則不是寫給人看的文件,是寫給下一個 Session 看的交接單。
# 專案規範
## 環境
- 套件管理一律用 pnpm,不要用 npm 或 yarn
- Node 22,不要降版
## 動手前必讀
- 改 API 前先看 docs/api-contract.md
- 資料庫 schema 變更一律走 migration,不要直接改表
## 完成的定義
- pnpm test 全綠才算做完
- 新增功能要補對應測試,不要只改實作
## 不要做的事
- 不要為了讓測試通過而放寬或刪除測試
- 不要動 .env 與任何金鑰檔
這份東西進版控之後,每一個新 Session、每一次換模型都會自動讀到,你不用再講第三次。書裡 CH2 會再往下談專案級與全域級該怎麼切、以及什麼時候該用 /init 把專案近況回寫進去。
我的經驗是:「不要做的事」那一段的投報率最高。正面規範 AI 通常猜得到,但「不准為了讓測試過而刪測試」這種事,不明寫它真的會做。
四、九個章節怎麼讀:AI Harness 駕輕就熟 的三條路線
全書九章,從安裝一路到一個完整實戰專案。但我不建議所有人都從第 1 章硬讀到第 9 章——先認自己是哪一種讀者,省下來的時間比較實在。

| 章 | 主題 | 這一章解決什麼 |
|---|---|---|
| CH1 | 認識與安裝 OpenCode | Harness 是什麼;OpenCode 與 Claude Code、Codex 的關係;三平台安裝 |
| CH2 | 快速上手:PDF 加浮水印工具 | AGENTS.md 入門、CLAUDE.md 相容、Plan/Build 權限模式、/undo 與 /init |
| CH3 | 操作全攻略與無痛切換 | 切換 Agent/模型/工作階段、管理長對話、把既有 Claude Code 專案轉過來 |
| CH4 | Agent + Subagent | 建立自己的 Subagent、多 Agent 並行、獨立 Context 的 Code Reviewer |
| CH5 | MCP 與 Skills | 兩者差在哪、Browser MCP、Playwright MCP、DeepWiki MCP、打包測試 Skill |
| CH6 | 設定檔與權限 | 看懂 opencode.json、權限與角色分工、自訂指令與快捷鍵、Plugin |
| CH7 | 模型選擇與平價方案 | Provider 生態、免費/訂閱/API 計費、依難度選模型、平價模型的隱私與限流風險 |
| CH8 | Harness 思維 | Harness 的六層控制力、平台/Agent/模型三維度配置、走偏時的反模式 |
| CH9 | 實戰:WorkDash 浮動工作資訊欄 | 從一句需求到 PRD、分工、實作、除錯、交接,把流程真正走完一次 |
我個人覺得 CH8 的反模式那一節最值得先翻。它列出「過度拆分」「迷信模型能力」「放棄理解」「無底洞除錯」幾種走偏的樣子——如果你已經在用 coding agent 一陣子,大概會在裡面認出自己。順帶一提,官方頁面那一節標題寫「五種反模式」但只列了四項,這是出版社頁面的小出入,實際內容以書為準。
五、我用自己的部落格跑了一個月的實際感受
講一點不是書裡的東西。這個部落格目前有 200 篇以上的文章,從選題、寫作、配圖到發佈後的內鏈回補,整條流程我是交給 AI agent 跑的,而且是排程自動跑。這一個多月下來,我撞到的坑跟 AI Harness 駕輕就熟 書裡列的症狀重疊度高到有點好笑。
| 我踩到的坑 | 對應書裡哪一組骨架 |
|---|---|
| 每次新 session 都要重新交代「綠燈是 81 分不是 80 分」「中文關鍵字進不了 slug」 | AGENTS.md × Git |
| 照著既有計畫表選題,結果新文章跟自己站上的舊文搶同一組關鍵字 | Agent × Subagent(要有獨立角色做事前查核) |
| 只看工具回報的成功訊息,沒實際開前台驗,結果內容根本沒生效 | MCP × Skills(讓它自己開瀏覽器驗) |
| 所有步驟都用最貴的模型,連「把表格排版整齊」都是 | Model × Provider |
最後那條我處理完之後,差距最明顯。查核、格式整理、驗證這類工作本來就不需要旗艦模型,但如果你沒有一個地方可以宣告「這種任務用哪個模型」,它預設就會一路用最貴的。這正是書裡 CH7 在談的事。
另一個我後來才學到的教訓:工具回報成功不等於事情做對了。我曾經相信 API 回 200 就代表內容更新成功,實際上前台被快取擋住、使用者看到的還是舊版。書裡 CH5 把「讓 AI 自己開瀏覽器看結果」當成標配,不是炫技,是因為少了這一步,整條自動化都建立在假設上。
哪些事值得自動化,哪些不值得
跑了一個月之後,我對「該讓 AI 接手到哪裡」的界線清楚很多,這條界線書裡 CH8 用三個維度在談,我用自己的話重講:
| 類型 | 要不要交給 Agent | 原因 |
|---|---|---|
| 有明確驗收條件的重複工作 | 交,而且該排程自動跑 | 對錯可以被程式判斷,出錯也看得出來 |
| 查核與交叉驗證 | 交給獨立的 Subagent | 同一個 Agent 不會推翻自己的結論 |
| 需要品味的取捨 | 自己來,讓 AI 列選項 | 它會給你一個合理答案,但不一定是你要的那個 |
| 不可逆的操作 | 一律先問過人 | 刪除、發佈、付款這類事情沒有復原鍵 |
最後一列就是 Permission 這一組骨架存在的理由。我自己的設定是:讀取與分析全開,寫入要在限定範圍內,刪除一律先問。這三層分完之後,我才真的敢讓它排程自己跑。
一個月下來最大的改變
不是產出變快,是我不用再重複解釋同一件事。以前每次開新對話,光是把專案背景、分數門檻、過去踩過的坑交代一遍就要十幾分鐘,而且常常漏講。現在這些東西全部寫在專案裡,新 Session 一開就有。
這也是我看完 AI Harness 駕輕就熟 之後最認同的一句話:Harness 的價值不在讓 AI 變聰明,在讓你不用每次從頭開始。對長期專案來說,後者才是真正省下來的時間。
六、這本書適合誰、不適合誰
我盡量講得具體一點,免得變成人人都適合的廢話。
| 情況 | |
|---|---|
| 很適合 | 已經在用 Cursor / Claude Code / Copilot,但專案一變大就開始失控的人 |
| 很適合 | 每月 API 帳單讓你開始猶豫要不要繼續用 AI 寫程式的人 |
| 很適合 | 想把個人用法變成團隊可複製流程的 Tech Lead |
| 還行 | 完全沒碰過 CLI agent,但願意照 CH1–CH3 把環境走一次的人 |
| 不適合 | 想找「貼上去就能用的萬用 Prompt」的人——這本書的立場剛好相反 |
| 不適合 | 完全沒寫過程式、想靠 AI 從零做出產品的人(書預設你看得懂程式碼在做什麼) |
另外提醒兩件事。第一,書是 黑白印刷,終端機截圖多,不介意的話沒差,但如果你很依賴顏色辨識就要有心理準備。第二,這個領域工具更新很快,書裡的 OpenCode 版本與某些 Provider 方案一定會變——把它當成思維框架讀,不要當成版本手冊讀,這樣保值期會長很多。
我的保留意見:這本書沒有處理的事
為了公平,講三個我覺得它沒處理或處理得比較淺的地方。
一、團隊協作的部分很少。整本書的視角是「一個人怎麼駕馭一組 Agent」,但真正的痛點往往出現在多人共用同一份 AGENTS.md 的時候——規則衝突怎麼仲裁、誰有權改、改了要不要通知其他人,這些書裡幾乎沒碰。
二、成本只談了怎麼省,沒談怎麼量。CH7 教你依任務難度換模型,方向是對的,但如果沒有一套紀錄方式,你其實不知道省了多少、哪一段最貴。這部分得自己補。
三、失敗案例太少。CH8 的反模式那一節是全書我最喜歡的段落,但它偏概念;如果能多幾個「這樣設定結果炸掉」的真實紀錄,說服力會更強。AI Harness 駕輕就熟 整體是一本偏正向示範的書,踩坑的部分需要你自己去撞。
不過這三點都不影響我的結論:以中文市場來說,目前沒有第二本把 Harness 這件事講得這麼完整的書。它把一堆散落在各家文件與部落格的做法,收斂成一條可以照著走的路線,這件事本身就值回票價。
七、書籍資訊與 momo 雙 11 單日 66 折

| 書名 | AI Harness 駕輕就熟:OpenCode 讓 Vibe Coding 更自由 |
|---|---|
| 作者 | 施威銘研究室 |
| 出版社 | 旗標科技(書號 F6742) |
| ISBN | 9789863128953 |
| 出版日期 | 2026 年 9 月 11 日 |
| 裝訂 / 色彩 | 平裝 / 黑白 |
| 定價 | NT$820 |
| 雙 11 優惠 | 11/11 單日限定 66 折,NT$541(momo 購物網,滿 1 件即享) |
優惠時間是 11 月 11 日當天一整天,過了就恢復原價,想入手的話記得當天處理掉。書籍的完整介紹與試閱可以看 旗標官方書籍頁。
八、常見問題
沒用過 OpenCode,看得懂嗎?
可以。CH1 到 CH2 就是從零安裝加一個完整小專案(PDF 加浮水印工具)。只要你看得懂程式碼在做什麼、用過終端機,就有足夠的基礎。
我已經在用 Claude Code,還需要換嗎?
不用換。CH3 與 CH6 專門處理兩者共存——OpenCode 會自動讀 CLAUDE.md,規則與交接資訊可以共用。這本書的立場不是叫你改用哪個工具,是叫你別把專案綁死在任何一個工具上。想先補 Claude 這一側的基礎,可以看我的 Claude 使用教學完整指南。
這本書跟一般的 Vibe Coding 教學差在哪?
一般教學教你怎麼把一次需求講清楚;AI Harness 駕輕就熟 教你怎麼讓第一百次需求跟第一次一樣穩。如果你想先搞懂 Vibe Coding 本身,我寫過 Vibe Coding 是什麼的完整整理,兩篇可以搭著看。
66 折優惠只有 momo 有嗎?
這次 11/11 的單日 66 折是 momo 購物網的檔期活動,原價 NT$820、折後 NT$541。其他通路與旗標官網的價格以各自頁面為準。
本文為旗標科技贊助合作內容,購書連結為合作連結。書中資訊以實體書與出版社官方頁面為準;閱讀心得為個人意見。
