🌏 Read this article in English
一個熟悉的場景
某連鎖餐飲品牌的會議室。
「我們要自建訂餐平臺。第一步，先研究 Uber Eats 和 foodpanda，整理一份完整的功能規格書。」
這是大多數團隊的標準起手式，邏輯清晰、步驟明確。
但資深的專案負責人通常會多問一句：這套流程的前提條件，在這個專案中成立嗎？
Spec-driven：一套成熟的方法論
先說清楚，Spec-driven 不是壞方法。
它的流程大家都熟悉：需求訪談 → 競品研究 → PRD → 技術規格 → 開發 → 測試 → 上線。
這套方法有它的優勢：
- 降低溝通成本：規格文件是跨部門的共同語言
- 便於估算資源：有明確範疇才能估時程、抓預算
- 責任歸屬清晰：誰負責什麼，白紙黑字
在需求穩定的專案中，這套流程非常有效。
但它有一個隱藏的前提：寫規格的人，已經掌握了足夠的市場訊號。
問題是——創新專案的市場訊號，往往要等產品碰到用戶才會浮現。
這不是誰的能力問題，而是資訊在時間軸上的分布問題。
Key Insight: Spec-driven 的前提是「市場訊號已經足夠清晰」。但在創新專案中，訊號往往要等產品碰到用戶才會浮現。
資深 PM 都熟悉一個現象：專案初期的假設，有七成會在上線後被調整。這不是執行力的問題，這是資訊揭露的時間差。
這帶出一個值得思考的問題：有沒有辦法在投入大量資源之前，先用較低成本驗證這些假設？
工程師角色的演進
這裡先岔開一下，聊聊 Spec-driven 流程中工程師的定位。
在高度結構化的開發流程中，工程師的專業在於「精準實現」——把需求規格轉化為穩定可靠的系統。這是紮實的技術功底，也是產品品質的基石。
有趣的是，當 AI 工具開始能協助處理部分實現工作，工程師的價值正在往新的方向延伸。
這個話題，後面會再展開。
Intent-driven：先驗證方向，再投入資源
使用 Claude Code 一段時間後，我發現自己的開發方式有了根本性的轉變。
以前：先想清楚要做什麼 → 寫詳細規格 → 開始實作
現在：先描述想達成的目標 → 快速產出原型 → 驗證方向 → 再決定要不要投入
這就是 Intent-driven Development：從「告訴機器怎麼做」變成「告訴機器我想達成什麼」。
核心差異不在於寫程式的速度變快了，而在於驗證假設的成本大幅降低。
案例：某連鎖餐飲的訂餐平臺
回到開頭那個場景。
那個專案原本規劃用標準流程走：研究期 4 週、規劃期 4 週、然後進入開發。光是前期就要 8 週以上。
我們決定在前期加入一個「方向驗證」階段：
| 階段 | 工作內容 | 時間 |
|---|---|---|
| 定義意圖 | 「讓顧客在 30 秒內完成點餐」 | 2 天 |
| 快速原型 | 用 Claude Code 產出 3 種不同方案的 prototype | 5 天 |
| 用戶驗證 | 找 20 位真實顧客測試、收集回饋 | 5 天 |
| 方向確認 | 根據回饋決定開發方向 | 2 天 |
| 合計 | 2 週 |
這兩週不是要取代後續的完整開發，而是在大量投入之前，先確認方向值得投入。
結果，我們有了三個重要發現。
三層發現
第一層：確認產業標配
用戶測試中，我們確認了哪些功能是「基本期待」：線上付款、訂單追蹤、歷史紀錄。
這些功能不用重新發明，參考現有做法就好。這是「致敬」該做的地方。
第二層：識別假需求
原本規劃中有很多「客製化」功能——讓顧客調整配料、設定偏好。
但測試發現：八成的用戶只會重複點自己常點的兩三樣東西。
複雜的客製化功能，對多數用戶來說是幹擾，不是價值。這個發現讓我們省下了約兩個月的開發時間。
第三層：發現市場缺口
最意外的發現是：用戶最大的痛點不在「點餐」，而在「取餐」。
「App 做得再漂亮，到了現場還是要等、還是會拿錯。」
這是一個 Uber Eats 和 foodpanda 都沒有解決好的問題——因為他們的場景是外送，不是到店取餐。
這才是差異化的真正機會。
Key Insight: 「致敬競品還是走自己的路」是假議題。真正的問題是：你的用戶實際上在乎什麼？
工程師價值的延伸
回到前面的話題：當 AI 能協助處理更多實現層的工作，工程師的專業正在往哪裡延伸？
觀察下來，答案是：從「精準實現」延伸到「參與定義」。
在 Intent-driven 的流程裡，工程師不只是接收需求的人，也是參與探索「我們到底要解決什麼問題」的人。
這意味著能力組合的擴展：
- 把模糊的商業目標轉化為可驗證的技術假設
- 快速建構原型來測試想法
- 根據回饋迭代調整方向
這是技術專業的自然延伸，也是工程師影響力擴大的機會。
Key Insight: 當 AI 能協助實現層的工作，工程師的價值正在延伸——從「精準實現」到「參與定義我們要解決什麼問題」。
這不是非黑即白
講到這裡，要澄清一個常見的誤解。
Intent-driven 不是要取代 Spec-driven，而是在對的時機用對的方法。
| 情境 | 建議方法 |
|---|---|
| 需求明確、變動小 | Spec-driven |
| 法規合規要求高 | Spec-driven |
| 多團隊協作需要契約 | Spec-driven |
| 需求模糊、需要探索 | Intent-driven |
| 市場訊號不確定 | Intent-driven |
| 需要快速驗證假設 | Intent-driven |
最好的做法是：先用 Intent-driven 驗證方向，確認後再用 Spec-driven 規模化開發。
兩種方法是接力，不是對立。
團隊導入的節奏
如果你認同這套方法，想在團隊裡嘗試，建議怎麼做？
關鍵是：用成果建立信任。
多數組織在評估新方法時，會優先考量「可預期性」——有明確時程、有完整規格、有可衡量的產出。這是專業管理的基本要求。
所以導入新方法時，順著這個脈絡走，更容易獲得支援。
三步導入法：
1. 試點先行
選一個小型專案當試點。讓團隊在可控範圍內體驗新流程，累積第一手經驗。
2. 成果說話
試點完成後，用具體成果分享：縮短了多少驗證時間、提前發現了哪些洞察、做了哪些有價值的調整。
數字和案例是最好的溝通語言。
3. 自然擴散
當同事開始好奇「你們那個專案怎麼這麼順？」——這就是最好的分享時機。
順勢而為，水到渠成。
Key Insight: 新方法的導入，最好的推廣是讓成果自己說話。
寫在最後
從 Spec-driven 到 Intent-driven，表面上是工具的進化，實際上是思維的轉變。
過去我們假設：人類比機器更懂細節，所以先想清楚再動手。
現在這個假設正在被挑戰：當 AI 能快速產出原型，「想清楚」和「動手試」可以同步進行。
這不是讓我們更快寫程式。
這是讓我們在投入大量資源之前，先確認方向是對的。
在不確定性越來越高的市場環境裡，這個能力會越來越值錢。
Sources
- Anthropic. “Claude Code Documentation.” 2025.
- 作者實務專案經驗