Agentic Coding 工具實戰比併：CodeWhale vs gstack vs 自己寫 prompt

---
title: "Agentic Coding 工具實戰比併：CodeWhale vs gstack vs 自己寫 prompt"
date: "2026-05-27"
slug: "agentic-coding-codewhale-vs-gstack-vs-prompt"
summary: "CodeWhale、gstack、自己寫 prompt——三種 agentic coding 策略，邊個真係幫你慳時間？實測半年後發現，最貴嘅工具未必最快，最靈活嘅方案反而最考自制力。"
tags:
  - build
  - ai-coding-tools
  - agentic-workflow
  - developer-productivity
  - prompt-engineering
cover_image: "../../assets/heroes/agentic-coding-codewhale-vs-gstack-vs-prompt.jpg"
draft: false
lang: zh-Hant
---

2025年每個人都問「AI 寫 code 得唔得？」2026年個問題已經進化咗——唔係得唔得，而係點樣用先最慳時間。我用咗半年時間，分別用 CodeWhale、gstack、同埋自己寫 prompt 三種方法去 ship 產品，發現一個反直覺嘅真相：愈多 automation 嘅工具，唔一定幫你慳最多時間；反而係要你投入最多 cognitive effort 嘅方法，喺特定場景下回報率最高。關鍵唔係工具本身，而係你嘅 work pattern 夾唔夾。

## CodeWhale：多模型編排嘅浪漫與現實

CodeWhale 嘅核心賣點好性感——唔使你諗用邊個模型，系統自動 dispatch 最適合嘅 model 做最適合嘅 task。寫型別定義用 Claude 4，生成 React component 用 GPT-5，做 static analysis 用本地 open-source model。理論上呢個係 agentic coding 嘅終極形態：你專注寫 logic，model selection 交俾系統。

現實係另一回事。我喺一個中型 Next.js + tRPC monorepo 上試咗兩個月，最大痛點係 latency。每次 model switching 要等 2-3 秒，唔算耐，但一日幾百次切換累積落嚟就係十幾分鐘嘅 dead air。Flow state 一斷就好難 pick up。更核心嘅問題係 routing logic 唔夠成熟——有時寫 React component 嘅 task 俾咗 Claude，寫得好地地；下次 dispatch 同類 task 突然跳咗去 GPT-5，output style 唔一致之餘，仲要人手修正風格衝突。

CodeWhale 最啱用嘅場景係 research 同 prototyping，尤其係你需要快速比較唔同 model 對同一個問題嘅反應。但作為 daily driver，multi-model orchestration 帶嚟嘅 overhead 仲大過佢慳返嘅時間。結論係：方向正確，但今時今日嘅 execution 未足以取代一個 single model 嘅 consistent workflow。

## gstack：唔係工具，係一套工序

Garry Tan 嘅 gstack 今年喺 GitHub 爆咗 104K stars，唔係因為佢係另一個 AI coding tool，而係因為佢重新定義咗「用 AI 寫 code」呢件事。gstack 唔係一個 editor plugin，唔係一個 CLI agent——佢係一套工序（workflow），將 Claude Code 變成一個 virtual engineering team。

實際用落，最大嘅衝擊係「structured process」同「blank slate」之間嘅 productivity gap。平時自己寫 prompt，你由零開始諗點樣表達需求；用 CodeWhale，你淨係俾 task 俾系統 dispatch。但 gstack 嘅做法完全唔同——佢迫你行一個完整嘅 sprint：/office-hours 先 challenge 你個 idea，/plan-ceo-review 再迫你諗清楚 scope，/plan-eng-review 落 architecture 同 test plan，然後先開始寫 code。聽落好重皮，但實測發現呢個 process 慳嘅時間遠超佢消耗嘅時間。

點解？因為平時自己寫 prompt 最浪費時間嘅 moment 唔係寫 code，而係寫完先發現方向錯咗、architectural decision 冇諗清楚、或者 scope creep 咗。gstack 嘅 forcing function 將呢啲錯誤嘅成本提前到寫 code 之前。我試過用 gstack 做一個 calendar integration feature，由 office hours 到 ship，全程三個鐘搞掂。同一件事用傳統方法（自己 write spec → 自己寫 prompt → iterate），前後搞咗兩日。

gstack 最大嘅 trade-off 係 learning curve。二十三條 skill commands 要記、要理解每條 command 做咩、要適應佢嘅「CEO review 模式」同「eng review 模式」——呢啲全部要時間。而且佢 presuppose 你用 Claude Code，如果你個 workflow 唔係 terminal-first，gstack 嘅價值會大打折扣。

## 自己寫 prompt：終極靈活，終極自律

講到尾，最原始嘅方法——自己寫 prompt——依然係最靈活嘅選項。冇 vendor lock-in、冇 learning curve、可以針對任何 model、任何 task 即時調整 prompt structure。對於一啲高度 domain-specific 嘅 task（例如處理 legacy PHP codebase、寫 hardware interface binding、或者特定 regulatory compliance 嘅 code），自己寫 prompt 嘅 control 係任何 tool 都比唔上嘅。

但靈活嘅代價係 discipline。我觀察到一個 pattern：用 CodeWhale 或者 gstack 嘅時候，工具本身 impose 咗某種 structure，迫你唔可以跳步。自己寫 prompt 嘅時候，好容易貪快 skip 咗 planning，直接叫 AI 寫 code。結果係 output quality 好參差，要花大量時間 review 同 rewrite。另一個問題係 inconsistency——每次 prompt 嘅 quality 取決於你當時嘅 mental state，今日寫得好嘅 prompt 聽日唔一定寫得返。

我自己嘅實戰策略係 hybrid：日常開發用 Claude Code 嘅 raw prompting 快速 iterate；當 feature 有一定 complexity（跨五個 file 以上、涉 database migration、或者要改 business logic），就行 gstack 嘅 structured review process。CodeWhale 留俾需要 cross-model validation 嘅場景，例如 security audit 或者 performance benchmarking。

## 結論：揀 workflow，唔係揀工具

半年實測之後，我嘅建議好簡單。如果你係 solo founder 或者 indie developer，gstack 值得你花一星期學——佢嘅 process 本身訓練咗你點樣同 AI 合作，呢個 skill 嘅 half-life 遠比任何 tool 長。如果你嘅工作涉及多個 codebase 或者要同 team 協作，自己寫 prompt 嘅靈活性反而係優勢，但要建立自己嘅 prompt template library，確保 consistency。CodeWhale 適合 AI research 或者 multi-model 比較，未 ready 做 daily driver。

最核心嘅 insight 係：慳時間唔係來自工具本身，而係來自你同工具之間嘅默契。任何 agentic coding tool 都係 amplifying your judgment，唔係 replacing it。用多模型定單一模型、用 structured workflow 定 freeform prompting——呢啲選擇嘅 outcome 差距，遠細過你嘅 code review discipline 同 architectural thinking 帶嚟嘅差距。2026 年嘅贏家唔係用最多 AI 工具嘅人，而係最知道自己想要咩 output、最識得 review AI generate 嘅 code、最清楚幾時要跳過 automation 直接落手寫嘅人。