Agile 時代的雙軌道(Dual Track Agile)是過去十年產品開發的主流模型:Discovery 找出「對的」產品,Delivery「正確地」把產品做出來。這個模型建立在一個核心假設之上 — Delivery 很貴、很慢,所以 Discovery 必須做對,用便宜的方式避免昂貴的浪費。

但 AI Coding 工具(Copilot、Cursor、Claude Code、各種 vibe coding agent)正在快速改變這個假設。當寫程式變得便宜十倍,雙軌道模型開始失靈。本文整理當前業界三大主流派別的觀點:SVPG / Marty Cagan 的產品學派、CIO 雜誌的工程學派、以及 Triple Track Agile 的流程學派,並嘗試從中找出可以實際採用的調整建議。

一、核心差異:成本結構翻轉

AI 把寫程式變便宜了,但其他環節沒有等比例下降。這是理解整個議題的起點。

Agile 時代的成本分布

Discovery 是中等成本(訪談、原型、MVP),Delivery 是高成本(寫程式、測試、上線),驗證 / 維護則被吸收在 Delivery 內,沒被特別獨立出來討論。

AI Coding 時代的成本分布

Delivery 端因為 AI 的加速,成本大幅下降。但驗證(code review、整合測試、用戶驗收)和維護(理解、debug、安全稽核)的成本沒有等比例下降,反而變成新瓶頸。

結論 瓶頸從「寫程式」轉移到「驗證 + 決策 + 維護」。整個流程的設計需要重新思考。

二、AI Coding 帶來的五大挑戰

成本結構翻轉之後,雙軌道模型開始在五個地方失靈。

挑戰 1    邊界模糊

AI 做的「原型」70% 已經是可用程式碼。團隊容易跳過 Discovery,直接把原型推上生產。Discovery 與 Delivery 的界線,從清楚的兩個階段變成模糊的灰色地帶。

挑戰 2    驗證跟不上

AI 一天寫完一週的程式碼,但 code review、整合測試、回歸驗證沒有等比例縮短;用戶驗收的時間更是完全沒變。結果是大量「沒被驗證過」的程式碼上線,品質債務以前所未有的速度堆積。

挑戰 3    節奏失衡

PM 還在做用戶訪談的時候,工程師已經用 AI 做出三個版本在等回饋。Discovery 反而變成跟不上 Delivery 的那一方,Delivery 在沒有方向指引的情況下空轉。

挑戰 4    理解權流失

程式碼能跑,但寫的人不一定真的懂。當問題出現,沒人能快速 debug;當需求變更,沒人知道改哪裡安全。「能交付」和「能維護」開始脫鉤。

挑戰 5    速度錯覺

可以產出十倍的功能,但如果沒人用、沒人要、沒人能維護,就是十倍的浪費。產出量(velocity)與價值產出(value)之間的差距被拉得更大。

三、業界三派觀點

這個問題沒有單一答案。當前業界有三派主流的看法,各自從不同角度切入,給出不同的解法。下面逐一介紹。

構面	SVPG / Marty Cagan	CIO 雙軌工程	Triple Track Agile
學派類型	產品學派 · 最主流	工程學派 · 安全治理	流程學派 · 較少採用
聚焦	重定義產品開發	重新定義工程紀律	重新定義開發流程
核心主張	Build to Learn vs Build to Earn	vibe 探索 vs. 嚴謹生產	加上第三條軌道
關鍵概念	Discovery 才是真瓶頸 PM 角色明顯分化 團隊變小、變精	Track 1 沙箱探索 Track 2 嚴謹生產 原型不可進生產	加 Operational(維運) 加 Strategy(策略) 加 Understanding(理解)

派別一:SVPG / Marty Cagan(產品學派)

「失敗應在 Discovery 中發生,而不是讓爛點子暴露給付費客戶。」

這派在主張什麼?

Marty Cagan 與 Teresa Torres 領導的 SVPG(Silicon Valley Product Group)是當前最主流的觀點。他們的核心論點很簡單:交付成本下降後,真正的瓶頸已經不是「實作功能」,而是「找到值得做的解法」。AI 並沒有讓 Discovery 變得不重要,反而讓它變得更關鍵。

換句話說,當寫程式變便宜,你會看到一堆團隊變成「加速版的 feature factory」 — 比過去更快做出更多沒人要的產品。要避免這個陷阱,Discovery 必須變得更精準、更高頻率,而不是被跳過。

誰來做?Discovery Trio 三人組

這派強調 Discovery 不是 PM 一個人的事,而是「Discovery Trio」三個角色共同負責的活動。Trio 由以下三人組成,在同一個跨功能小團隊裡合作:

• PM 「問題定義者」  — 負責定義要解什麼問題、驗收標準是什麼、如何驗證
• 設計師 「原型製作者」  — 負責把想法變成可互動的原型,通常一週做 5-10 個
• 工程師 「可行性把關」  — 每天花 10-15 分鐘檢視原型,回報技術可行性風險

Trio 不是只在 Discovery 階段合作。Delivery 階段工程師主導實作,但設計師繼續支援,PM 持續收集回饋,三人始終在同一個小團隊裡。SVPG 預測未來 3-10 年,典型產品團隊會從 8 人(6 工程師 + PM + 設計)縮到 3 人 — 這正是 Trio。

怎麼做?具體節奏(Cadence)

Marty Cagan 在 SVPG workshops 中明確給出 Discovery 的執行節奏。這些數字是判斷一個團隊有沒有真的在做 Continuous Discovery 的 benchmark:

• 10-30 次 Discovery 迭代 / 每週 — 一次迭代可以是原型小調整、加新工作流、或測試一個新假設
• 10-15 分鐘 prototype review / 每天 — 工程師檢視當天設計師做的原型,當場回報可行性顧慮
• 至少 1 場用戶訪談 / 每週 — 三人都參加(Cagan 強調),不是只有 PM 去聽

一週的循環長什麼樣?

典型的一週節奏大致如下,雖然細節會因團隊而異:

• 週一: Trio 一起規劃這週要驗證的假設
• 週二到週四: 設計師做 5-10 個原型;工程師每天 15 分鐘檢視
• 週四: PM 帶 Trio 進行用戶訪談 1 場
• 週五: Trio 共同決定下週方向 — 哪些假設驗證了、哪些丟掉、下一輪要做什麼

Discovery 與 Delivery 怎麼互動?

這是這派最容易被誤解的地方。Discovery 與 Delivery 不是兩個前後階段,而是「持續同時並行」的兩種活動:

• Discovery → Delivery: 通過驗證的假設,變成 Delivery 的 ticket。設計師的可互動原型本身就是給工程師的「規格」,不需要寫 PRD。
• Delivery → Discovery: 上線後產生的真實使用數據,回饋給 Discovery 啟動下一輪假設驗證。Teresa Torres 的話:「Discovery feeds delivery, and delivery feeds discovery.」

關鍵互動機制

具體在團隊文化中需要建立的三件事:

• 原型即規格 — PM 不寫 PRD,設計師做的可互動原型,直接是給工程師看的規格。可互動原型已經足夠。
• 風險共擔 — Trio 一起做 risk assessment(通常是 5 分鐘的對話),不是 PM 一個人決定要不要做。工程師可以說「這個技術風險太高」,設計師可以說「這個體驗有問題」。
• 客戶共同參與 — Cagan 反覆強調:三人都要參加用戶訪談,不能只有 PM 去聽然後回來轉述。設計師需要看到用戶怎麼操作原型,工程師需要聽到用戶遇到的真實問題。

這派的精髓 不要新增軌道,而是讓 Discovery 變得更精準、更小團隊、更高頻率。

派別二:CIO 雙軌工程策略(工程學派)

「我們不能禁止 AI,但也不能讓機率性的 vibe coding 主導生產系統的架構。」

這派在主張什麼?

CIO 雜誌在 2026 年初發表的「The vibe coding crisis」一文,提出一套針對 AI Coding 的工程治理方案。這派的關注點不是產品開發流程,而是「程式碼品質、安全、可維護性」這些工程層面的問題。

他們的觀察是:AI 生成的程式碼速度很快,但有「cardboard muffins」現象 — 表面看起來測試覆蓋率 100%,實際上 AI 寫的單元測試根本沒驗證真正的業務邏輯。再加上 AI 經常推薦不存在的套件(hallucinated packages),引入安全漏洞。把 vibe coding 直接放上生產系統是災難。

但他們也不主張禁用 AI。解決方案是:把開發週期切成兩條軌道,清楚分開「探索」與「生產」這兩種完全不同的工程紀律。

Track 1:沙箱探索

這條軌道允許、甚至鼓勵 vibe coding 全速前進。具體規則:

• 誰主導: PM、設計師、業務分析師等「非工程背景人員」 + AI agent
• 做什麼: 用 Cursor、Lovable、v0 等工具,一個下午做出可運作的原型
• 核心指標: 拿到回饋的速度(speed to feedback)
• 限制: 完全在沙箱環境執行,不可接觸生產資料、客戶 PII、或核心網路
• 原型的角色: 「拋棄式藍圖」(disposable blueprint),驗證業務想法,不是上線素材

Track 2:嚴謹生產工程

這條軌道是傳統的工程紀律,但更嚴格:

• 誰主導: 資深人類工程師。AI 從「自主創作者」降級為「受限的助手」
• 做什麼: 架構設計、人工編碼、嚴謹型別檢查、人工 code review、CI/CD
• 核心指標: 安全保證、可預測性、可稽核、可維護
• AI 的角色: 受限的助手 — 每個 AI 推薦的套件都要驗證、每個 AI 寫的測試都要人工 review

兩軌如何互動?順向交付

CIO 原文有一句關鍵句:「The vibe code is a specification, not a foundation.」 把 vibe code 當成「會執行的需求文件」,不是「地基」。當 Track 1 的原型驗證通過後,具體的交付步驟是:

• 1. 驗證通過 — Track 1 在沙箱中確認業務價值,得到用戶與 stakeholder 的支持
• 2. 凍結原型 — 原型成為「視覺參考」,定義「我們要做什麼樣的東西」
• 3. 撰寫規格 — 從原型反推需求文件,記錄業務邏輯、安全需求、效能需求
• 4. Track 2 接手 — 從零開始重寫。不要 refactor、不要 salvage、不要 clean up vibe code。打掉重來。

這個「打掉重來」的紀律是這派最反直覺、也最重要的部分。實務上的時程倍數是:vibe 原型 2 天 → 生產系統需要 4-8 週(約 10-30x)。這個落差來自於原型沒做的 80%:錯誤處理、安全強化、可擴展性、營運監控、資料遷移、備份還原。

兩軌如何互動?反向回饋

Track 2 也會回饋資訊給 Track 1,但形式不同:

• 資深工程師 → PM / 設計師: 「這個原型的某段邏輯實際做不到」 → 修正下次的探索方向,避免重複犯同一個錯誤
• 生產上線後 → Track 1: 真實使用數據(A/B 測試、telemetry)→ 啟動下一輪假設驗證
• 安全 / 稽核 → Track 1 規範: 「這類功能未來不能 vibe」→ 列入沙箱黑名單,例如金融計算、認證邏輯絕對不能在 Track 1 做

不可違反的兩條規則 Track 1 的程式碼,永遠不能直接進入 Track 2 的 codebase。Track 2 的時程,絕對不能基於 Track 1 的速度。

第二條規則(時程不能用 Track 1 的速度推估)是最大的文化挑戰。當業務 stakeholder 看到一個「看起來可運作」的原型在週末就做出來,他們的直覺反應是「再給工程師一週應該就完成了」。CIO 原文特別提醒:這是必須持續對話、設定預期的關卡。

派別三:Triple Track Agile(流程學派)

「Strategy → Discovery → Delivery 三軌持續、雙向回饋,而非線性接力。」

這派在主張什麼?

Triple Track Agile 是對傳統 Dual Track 的延伸,主張在 Discovery 與 Delivery 之外再加上一條軌道。但有趣的是,這派內部對「第三條軌道是什麼」並沒有統一意見,目前實務採用度也是三派中最低的。

第三軌的不同版本包括:

• Tempo 版: Operational Track — 監控產品在真實使用中的表現、收集用戶回饋、持續改善
• Caroli 版(本文採用): Business Strategy Track — 設定高層次方向、用 OKR 對齊三軌
• Malouf / UXM 版: Understanding / Exploration Track — 深度研究、人物誌、田野調查

以下我們以 Caroli 的版本為主來介紹,因為它對「三軌如何互動」說明得最清楚。

三軌的角色與工作

• Strategy(策略軌) — 領導 / Stakeholder 主導。設定 OKR、商業目標、優先順序、長期方向。
• Discovery(探索軌) — PM + 設計 + 工程組成的小組主導。做假設驗證、原型製作、用戶訪談。
• Delivery(交付軌) — 工程 + QA + DevOps 主導。做編碼、測試、部署、CI/CD。

關鍵差別在於:這三軌不是線性接力(策略→探索→交付),而是「持續同時並行」。每一軌都有自己的迭代週期,但透過共同機制保持對齊。

如何對齊?四個機制

Triple Track 派的 Caroli 強調:三軌持續並行的關鍵,是有清楚的對齊機制。實務上由四件事組成:

• Team OKR(每季): 三軌共用同一組 Objectives & Key Results。Strategy 軌定義 O 與 KR,其他兩軌的工作都要能對應到 KR。
• OKR Review(雙週): 三軌負責人一起檢視 KR 進度,根據實際成果調整方向。Caroli 特別強調是「雙週」 — 不是季末才檢討。
• Cross-track sync(每週): 三軌負責人同步進度,處理跨軌相依、解決阻礙。
• 共享 Dashboard(持續): 進度、實驗結果、上線數據放在同一個地方,所有人隨時看得到。

資訊在三軌之間怎麼傳遞?

這是這派最關鍵、也最容易被忽略的部分。資訊在三軌之間是雙向流動的,具體可分為兩段:

Strategy ↕ Discovery

• ▼ 向下傳遞: OKR、商業目標、市場 insight
• ▲ 向上回饋: 驗證結果、機會發現、成本估算

Discovery ↕ Delivery

• ▼ 向下傳遞: 已驗證的解法、可互動原型、驗收標準
• ▲ 向上回饋: 技術可行性、使用數據、A/B 測試結果

整個系統靠「實證資料」驅動。A/B test、live telemetry、用戶訪談、業務指標,這些都是讓三軌不會「各做各的」的關鍵媒介。如果沒有這些實證資料,三軌很容易退化成三個獨立部門的官僚協調會議。

這派的精髓 Triple Track 不是新增工作,而是新增「對齊頻率」。OKR 是三軌共用的語言,實證資料是三軌交換的貨幣。

四、三派對照

把三派放在一起比較,可以更清楚看出他們的取捨:

比較構面	SVPG / Marty Cagan	CIO 雙軌工程	Triple Track Agile
主要關切	產品開發流程	工程紀律與安全	策略-執行對齊
軌道數	Dual Track(雙軌)	雙軌(工程內部分軌)	三軌
誰來做	Trio:PM + 設計 + 工程	Track 1:PM/設計 + AI;Track 2:工程	三軌:領導 / Trio / 工程團隊
互動週期	每天 15 分鐘 review;每週 10-30 次迭代	原型驗證 → 規格凍結 → 重寫	OKR 雙週 review;每週 sync
關鍵原則	Trio 三人共同決策	原型不可進生產	三軌持續並行,OKR 對齊
最大風險	如果不真做 Discovery,只是貼標籤	Track 1 速度誤導 Track 2 時程	退化成三個官僚部門開會
實務採用度	★★★ 最高	★★ 中等(剛起步)	★ 最低

五、流程調整建議:四個關鍵動作

拿掉派系包裝,綜合三派的觀點,以下四個動作是任何團隊都可以從下週就開始嘗試的:

1. Discovery 升級   來源:SVPG

從 找出需求、寫 PRD  →  定義問題 + 驗收標準 + 驗證方法

PM 的角色從「需求供應者」變成「問題定義者」。每個進入 Delivery 的工作項目,Discovery 端要先給出「我們在解什麼問題」、「什麼算成功」、「如何驗證」三件事,而不是「要做什麼功能」。

2. 工程內部分軌   來源:CIO

從 全部走同一套流程  →  探索沙箱 vs. 生產工程 分開

明確區分兩條軌道:vibe coding 只在沙箱環境、不上生產;生產 codebase 維持嚴謹的 code review、測試、CI/CD。最大的文化關卡是讓 stakeholder 理解「Track 2 的時程不能用 Track 1 的速度推估」。

3. 重新定義 Sprint   來源:綜合

從 兩週開發週期  →  假設驗證週期(可短至幾天)

把 sprint 的單位從「開發週期」改成「假設驗證週期」。一個 sprint = 一個假設的提出、實作、驗證、決定保留或丟棄。長度可能從兩週縮到一週甚至幾天。AI 讓「實作」變快,sprint 的瓶頸應該是「驗證」。

4. DoD 加上理解性   來源:綜合

從 功能對 + 測試過  →  團隊真的理解這段程式碼

Definition of Done 加上一個檢查項:這段程式碼三個月後,團隊裡有人能安全修改嗎?如果沒人理解、沒人能修,就不算完成。這是回應「理解權流失」這個挑戰最直接的做法。

六、結語

AI 讓寫程式變快,但決策不該跟著變快。

整個產業正在從「Delivery 是瓶頸」的世界,走向「Discovery + 驗證 + 維護是瓶頸」的世界。三派觀點各自從不同角度回應這個轉變:SVPG 用 Discovery Trio 解決產品方向問題,CIO 用雙軌工程解決生產安全問題,Triple Track 用 OKR 與雙向回饋解決策略對齊問題。

實務上最務實的做法,可能是同時採用三派的部分建議:用 SVPG 的 Trio 結構處理 Discovery 端、用 CIO 的雙軌紀律處理工程端、用 Triple Track 的 OKR 機制處理對齊。三者不互斥,反而彼此補位。

最重要的提醒是:在 Delivery 變快的時代,Discovery 與決策反而需要刻意保留「慢思考」的關卡。AI 讓寫程式變快,但你不會希望錯誤的決策也以十倍速度變成程式碼。

參考文獻

本文引用的原始資料,依派別分類整理如下。

SVPG / Marty Cagan / Teresa Torres

• Cagan, M. (2025). Build to Learn vs Build to Earn. Silicon Valley Product Group.
• Cagan, M. (2025). A Vision For Product Teams. Silicon Valley Product Group.
• Cagan, M. (2025). AI Product Management: 2 Years In. SVPG.
• Torres, T. (2021). Continuous Discovery Habits. Product Talk.
• Patton, J. User Story Mapping: Discover the Whole Story; Build the Right Product.
• Cagan, M. workshop notes (2019). 引述 10-30 次 Discovery 迭代 / 週、10-15 分鐘工程師 prototype review / 天等具體節奏。

CIO 雙軌工程策略

• CIO Magazine (2026). The vibe coding crisis: Why you need a dual-track engineering strategy.
• CIO Dive (2026). The enterprise is not ready for vibe coding — yet.
• Vibe-to-Production Gap (2026). vibe-to-enterprise.vercel.app(原型→生產 10-30x 倍數估算)。
• The New Stack (2026). From vibes to engineering: How AI agents outgrew their own terminology.

Triple Track Agile

• Caroli, P. (2023). Triple Track Development: Business Innovation Through Continuous Discovery and Continuous Delivery. caroli.org
• Caroli, P. (2025). The Triple Track One Team Way. paulocaroli.substack.com
• Tempo (2025). Dual Track Agile: Definition, Examples & Differences(含 Operational Track 第三軌定義)。
• Caliari, R. (2024). Triple Track Agile: uma combinação de Problem Space com Solution Space. Medium.
• Coderio (2025). Tri-Track Agile: A Revolutionary Approach(含 OKR 與 sync 機制)。
• Malouf, D. (2018). Tri-track design operations approach(Triple Track 早期論述)。