工序式 workflow 才是 agentic coding 的真正殺手鐧

過去一年，我見過太多開發者掉進同一個陷阱：以為 AI coding tool 愈自動化就愈慳時間。佢哋追求「一鍵完成成個 feature」、「一句話生成整個 app」，結果係寫 prompt 嘅時間多過寫 code，debug AI 產生嘅垃圾 code 嘅時間多過自己寫，最後 productivity 仲衰過唔用 AI。呢個現象唔係 AI 冇用，而係我哋用錯方法。

真相係：愈多 automation 唔一定愈慳時間。真正嘅生產力爆發嚟自工序式 workflow — 將 agentic coding 拆解成結構化嘅 sprint 流程，每個步驟有清楚嘅 input/output 同 quality gate。gstack 呢套做法證明咗，當你唔係叫 AI「做晒成件事」，而係叫佢「做呢個步驟、產出呢個交付、等我 review 完再下一步」，效率先至會真正提升。

全自動化嘅迷思：You’re just shifting the bottleneck

好多 AI coding 工具嘅賣點係「自動完成一切」。你俾一個 high-level 描述，佢就幫你由頭寫到尾。聽落好理想，現實係咁：AI 產生嘅 code 往往有 subtle bug、architecture 決定同你嘅 codebase 唔夾、testing 覆蓋率不足、仲要大量 context 重複傳遞。結果你 spend 大量時間响 code review 同 correction loop 入面。

呢個現象嘅根本原因係：寫 code 從來唔係樽頸。理解問題、做正確嘅 architecture decision、確保 code 同現有系統一致——呢啲先係真正消耗腦力嘅地方。全自動化嘅 AI tool 將呢啲 cognitive load 由「寫 code 嘅過程」轉移咗去「review AI 嘅 output 嘅過程」。你冇慳到時間，你只係換咗一種嘔血嘅方式。

gstack 嘅做法完全相反：佢唔追求一次性解決所有問題，而係將一個 feature 拆成多個 sprint，每個 sprint 有明確嘅 scope 同 deliverable。呢種做法迫咗開發者同 AI 都 focus 响一個具體問題，唔會出現「AI 寫咗 500 行 code 但方向錯晒」嘅浪費。每次 sprint 完成後，開發者可以做出 judgement call，決定下一步做咩，而唔係被 AI 嘅 output 牽住走。

工序式 workflow 嘅核心：Input、Process、Output、Quality Gate

工序式 workflow 嘅精髓在於將 agentic coding 標準化為可重複嘅工序。每一道工序有以下元素：清楚嘅 input（邊個檔案、邊個 context）、定義好嘅 process（用咩 tool、咩 prompt template）、預期嘅 output（產生咩檔案、改咩 code）、同埋 quality gate（點樣 verify 呢個 output 係 acceptable）。

以 gstack 嘅 sprint 流程做例子：每個 sprint 開始前，開發者要先寫清楚「點解要做呢個 sprint」、「成功嘅 criteria 係咩」、「scope 嘅邊界喺邊」。呢個唔係 bureaucracy，而係 cognitive offloading — 與其喺 coding 途中不斷做 decision，不如喺開始之前已經諗清楚。AI 响呢個框架入面唔係決策者，而係執行者。佢嘅角色係根據你俾嘅 spec 產生 code，用你定義嘅 style guide 同 pattern 去寫，然後俾你 review。

呢個做法嘅好處係：當你發現 AI 嘅 output 有問題，你可以好快 pinpoint 到係邊個工序出錯。係個 spec 唔夠清晰？定係個 prompt template 唔啱？定係 quality gate 唔夠嚴格？你唔需要由頭到尾重新嚟過，而係 fix 個別工序就得。呢種 debuggability 係全自動化流程俾唔到你的。

Em Dash 思維：Deliberate Pause 嘅力量

講到工序式 workflow，不得不提 em dash（—）嘅概念。em dash 喺英文寫作入面代表一個停顿、一個插入、一個轉折。响 coding workflow 入面，em dash 就係嗰啲刻意插入嘅 review point、decision gate、同 reflection moment。

全自動化嘅 AI workflow 最大問題就係冇呢啲 em dash。佢一條龍由頭跑到尾，中間冇 pause、冇 reflection、冇 course correction。結果係錯嘅方向行咗好遠先發現，浪費大量時間。

工序式 workflow 刻意將流程打斷，插入 multiple checkpoints。每個 sprint 完結之後，你停一停，問幾個問題：呢個方向係咪啱？test coverage 夠唔夠？performance 有冇問題？code quality 係咪 acceptable？呢啲 pause 唔係浪費時間，而係避免更大嘅浪費。

呢種做法同 TDD（Test-Driven Development）嘅理念一脈相承。TDD 叫你寫 test 先、寫 code 後，工序式 workflow 叫你 define acceptance criteria 先、俾 AI 執行後。兩者都係用結構去對抗混亂，用工序去減少 cognitive load。

點樣開始實行工序式 workflow

如果你讀到呢度覺得有道理，以下係幾個具體行動點：

第一，為你嘅 project 定義 standard sprint template。每個 sprint 應包括：objective（一句話講清楚做咩）、scope（明確話俾 AI 知改邊啲 files、唔改邊啲 files）、acceptance criteria（點樣先算完成）、同埋 review checklist（code style、testing、performance 等）。

第二，將 AI 當做 junior developer 咁 manage。唔好俾佢自由發揮，而要俾佢好清楚嘅 spec 同 constraints。佢 produce 完 code 之後，你要做 code review，唔好淨係信佢。呢個 analogy 好重要：你唔會叫個 intern「寫個 e-commerce platform」，你會俾佢「寫呢個 product listing component，跟住呢個 design spec，用呢個 API contract」。

第三，建立你嘅工序 library。隨住你用 AI coding 愈來愈多，你會發現好多工序係重複嘅：寫 unit test、refactor function、add error handling、optimize query。將呢啲工序標準化成 reusable prompt template，下次直接用，唔使由零開始寫 prompt。

最終，agentic coding 嘅真正殺手鐧唔係更聰明嘅 AI model，而係更聰明嘅工序設計。當你將寫 code 由一門手藝變成一條生產線，每一個工序都有清楚嘅 input/output 同 quality control，AI 嘅生產力先至會真正爆發。gstack 嘅經驗話俾我哋知：工序先行，AI 輔助，呢個先係 agentic coding 嘅正確打開方式。