規格先行 AI 讓 MCP 變工作引擎

AI 兩秒能生出計畫。問題是，它常常自己跑掉。這次的重點是先寫規格，再讓工具動手。Model Context Protocol、Kiro，再加上 Reaper，把「想法」和「執行」拆開來做。

講白了，這很像先交作業草稿，再按送出。AgilityFeat 的案例很直白。AI 先寫流程，人工確認，最後才讓代理人去操作 DAW。這種做法看起來低調，但很實用。

我覺得這比單純「叫 AI 幫忙」更成熟。因為真正麻煩的，從來不是生成文字，而是把步驟做對。少一步，整個流程就歪掉。多一個檢查點，錯誤就少很多。

為什麼規格先行比直接自動化更穩

很多 AI 示範都反過來。先叫模型做事，再回頭修。這種方式很爽，但也很容易翻車。規格先行的邏輯剛好相反。先把任務寫清楚，再讓工具執行。

這件事在複雜工作特別重要。因為複雜工作不是一個動作。它是很多步驟串起來。每一步都可能出錯。你如果把意圖、上下文、執行混在一起，模型很容易亂猜。

在音樂製作裡，這個差異更明顯。Producer 要的是控制感。AI 可以幫忙建 track、上色、設 bus、準備 FX chain。可是最後的聲音判斷，還是人來做。這樣分工才合理。

• 先寫規格，再執行
• 人工先審核，工具再動作
• 適合多步驟、重複性高的工作
• 比較不會誤刪、誤改、誤送出

這種模式也很適合軟體團隊。像是建專案骨架、整理資料夾、產生測試資料、準備部署步驟。這些工作不難，但很煩。AI 不一定要很聰明。它只要夠準就行。

MCP 怎麼把意圖接到工具上

MCP 的角色很像轉接頭。它讓 AI 能用一致方式連到外部工具。讀資料、下指令、做動作，都可以走同一套介面。你可以把它想成給 agent 用的 USB-C。

在這篇案例裡，Reaper 不是靠 AI 直接「看懂」介面，而是透過一個 reaper-mcp 伺服器來接 API。這個專案來自 Twelve Take Studios。AI 透過 MCP，就能建立 tracks、調整 session、處理音軌設定。

這種設計的好處很現實。你不用把每個 app 都重做一遍。只要工具有 API，就能接進來。今天是 DAW，明天可以是 IDE、CRM、內部儀表板，甚至是資料處理管線。MCP 不會自動變聰明，但它讓 AI 有地方可以「真的做事」。

“The map is not the territory.” — Alfred Korzybski

這句話拿來講 spec-driven AI 很貼切。規格是地圖。工具才是地形。地圖寫得太糊，代理人就會迷路。地圖寫得夠清楚，執行就會穩很多。

AgilityFeat 的流程也很像工程操作。先啟動 Reaper，再載入 MCP bridge，接著開啟 Kiro 的 Power，最後測試連線。這整套沒有魔法。只有設定、權限、和步驟管理。說真的，這才像真的工程。

Kiro 在這裡扮演什麼角色

Kiro 是 AWS 的 agentic editor。它的核心想法是先產生規格，再做修改。這對會碰到真實專案的工具很重要。因為你不會想讓模型一邊亂試，一邊改 live code 或 live session。

案例裡提到的 Power 概念也很有意思。它等於幫 AI 補上領域語言。一般模型可能知道「設定 session」這幾個字，但不一定知道 Reaper 裡每個操作怎麼對應。Power 讓它先學會工具語言，再去執行。

這樣做的結果，是少一點即興，多一點一致性。對開發者來說，這點很重要。因為 agent 最怕的不是慢，而是每次都用不同方式解題。你要的是可重複，不是花招。

在這種流程裡，Kiro 像規劃師。MCP 像通道。Reaper 像執行場域。三者分工很清楚。這比叫一個大模型「幫我處理」來得可靠多了。

音樂 demo 告訴我們什麼

這個 demo 很具體。輸入一個 prompt，就能建立鼓、貝斯、synth pad、synth lead 四條 track。再下一個 prompt，能做四小節鼓段，包含 kick 和 hi-hat pattern。後面還能調音量、改顏色、準備 FX chain。每一項都不炫，但很省時間。

這裡的重點不是 AI 會不會寫歌。重點是它能不能把機械步驟先做掉。Producer 還是要聽、要判斷、要決定編曲。AI 只是把手上的雜事清掉。這樣人比較能專心在耳朵和 taste 上。

如果拿手動流程來比，差異很直接。以前你要一直點選單、加 track、調顏色、設 routing。現在你可以先寫成規格，再一次送出。對一個 session 來說，省下的可能不是 1 分鐘，是整個工作節奏。

• 建 track 從多次點擊變成一次指令
• session 設定更一致
• mix 準備可先審核再執行
• 人保留最後決策權

這套方法也很像軟體交付。你可以先寫部署 checklist，再讓 agent 執行。你可以先定好資料欄位，再讓它幫你整理 CSV。你也可以先寫客服回覆模板，再讓它去填內容。差別只在工具，邏輯是一樣的。

跟其他 AI 工具相比，差在哪

現在很多產品都在拼「更會聊」。但在工作場景裡，會聊不等於會做。你如果要的是穩定流程，重點不是模型多會寫，而是它能不能照規格執行。這就是 spec-driven workflow 的價值。

跟一般聊天式 AI 比，這種流程多了審核點。跟純 RPA 比，它又多了語意理解。RPA 很死板。LLM 很會猜。兩者合在一起，才比較像真的工作代理人。MCP 正好站在中間，把語意和工具連起來。

如果拿幾個常見方案來看，差異也很明顯：

• ChatGPT 類工具：強在生成，弱在工具整合
• RPA：強在固定流程，弱在彈性
• MCP + agent：強在工具接入與流程控制
• Kiro：強在先寫規格，再做修改

這也是為什麼我覺得這類架構會先在內部流程冒出來。像 CRM 更新、工單整理、報表生成、會議紀錄整理，這些任務都很適合。因為它們有固定格式，也有明確驗收條件。

這波工具潮的背景，其實很務實

現在大家都在談 AI agent，但很多 demo 都停在「看起來很強」。真正落地時，企業會先問三件事。能不能控權限。能不能追蹤步驟。能不能重放流程。規格先行的設計，剛好把這三件事放進去。

對台灣開發者來說，這種做法也很熟。因為我們很常做整合。不是從零造輪子，而是把 API、資料庫、內部系統串起來。MCP 其實就是把這種整合工作再標準化一次。它不神，但很實際。

另一個背景是，AI 成本還是要算。模型呼叫有 token 成本，工具操作有風險成本。你如果每次都讓 agent 自由發揮，最後可能省了人力，卻多了修 bug 的時間。先寫規格，等於先把成本邊界畫好。

所以這不是什麼神話。它比較像工程紀律回來了。先定義，再執行。先審核，再自動化。這種順序看起來保守，實際上很省事。

接下來該怎麼看這件事

我的判斷很直接。真正能把 AI 用進工作流的團隊，不會只追求最會聊天的模型。他們會先整理規格，再挑工具，再把審核點放進流程。這樣做雖然沒那麼炫，但比較不會翻車。

如果你的團隊現在還在手動做很多重複步驟，我會先問一個問題：哪些流程可以先寫成 spec？只要能寫成步驟，就有機會交給 agent。先從低風險任務開始。像整理資料、建模板、準備報表。這些最適合試水溫。

下一步很可能不是更大的模型，而是更好的工作流。你可以先找一個重複 20 次以上的任務。把它寫成規格。接 MCP。接工具。再看 agent 能不能穩定跑完。這才是比較務實的路。