DevOpsDays Taipei 2026 DevOpsDays Taipei 2026

講者資訊

鍾筑安 (Judy ch)

鍾筑安 (Judy ch)

Reddoor 紅門互動
產品部-資深技術經理

鍾筑安(Judy),現任 Tech Lead,12 年技術背景橫跨 IoT(工研院台灣首間無人商店核心演算法)、MarTech(行銷自動化平台)至 AI 產品開發。曾擔任 PO 並帶領 11 人跨職能團隊,深刻體會傳統開發流程的溝通成本與效率瓶頸。目前從 PO + Tech Lead 的雙重視角,帶領 2 人小組探索「非純 SDD 的漸進式規範化」流程。初期的效率提升令人振奮,但更關注持續維運、技術債控管、團隊擴散等長期挑戰。這是正在進行的實驗,4 月初步驗證、6 月完整反思。

演講議程

從 Vibe Coding 到 SDD:AI 時代的小團隊開發流程實驗

【為什麼我們開始這個實驗】

當 AI 工具席捲開發領域,每個團隊都在問:如何在「快速產出」與「程式品質」之間找到平衡?Pure SDD 理論很美好,但團隊不習慣「規格先行」;直接用 AI 亂寫很快,但技術債會爆炸。我們在同一團隊內進行了一場對照組實驗:2 人採用全新的三階段流程,其他人維持傳統模式。初步觀察顯示開發週期明顯縮短、溝通摩擦大幅降低,但真正的挑戰在後續——持續維運與迭代能否保持這個效率?技術債是否真的清償?這些都還在驗證中。

【我們創建了什麼】

可立即複製的三階段開發框架

階段 1:Vibe Coding — PM/PO 用 AI 直覺產出雛形,允許混亂、快速驗證

階段 2:RD 重構 — 接手混亂 code,建立清晰結構與可複製 pattern

階段 3:SDD 開發 — 基於規範產出雛形 + FRD,實現高效持續迭代

包含完整操作手冊:每階段 checklist、工具使用場景、時間分配、角色分工。

【我們發現了什麼】

1.真實對照組數據與啟發

初步數據:開發週期明顯縮短、溝通成本大幅降低、Code Review 時間顯著減少

但真正的挑戰浮現:持續維運與迭代能否保持效率?規範會不會過時?技術債是否真的清償?

為什麼只有 2 人在用?其他人覺得「太難」、不知「從哪開始」、擔心「AI code 品質」

關鍵啟發:快速開發只是第一步,長期可維護性才是真正的考驗

2.降低導入門檻的實戰策略包

從 2 人最小試點開始、提供具體起步包(checklist、prompt 範例、pattern 範本、FRD 模板)

建立信心三步驟(展示數據、結對實踐、持續支持)

處理新舊並存的管理挑戰

【我們的下一步】

三種團隊演進路徑的選擇指南

路徑 A:小單元獨立作戰(2-5 人、功能獨立、快速迭代)

路徑 B:中型團隊新型協作(6-15 人、複雜系統、深度整合)

路徑 C:個人+AI 戰隊(初創階段、MVP 驗證、小工具)

附團隊健診工具:評估人員能力、產品特性、團隊文化,選擇最適合的演進路徑。

長期成功的持續關注清單

迭代維運關鍵指標:規範生命週期、技術債監控、品質把關、系統複雜度臨界點

團隊能力演進方向:PM 技術深度 vs AI 依賴、RD 規範制定能力、知識傳承機制

【整體反思】

這是正在進行的實驗(4 月初步驗證、6 月完整反思)。初期的開發效率提升令人振奮,但我們更關注的是:能否擴散到整個團隊?不同產品類型的適用邊界?長期的持續維運與迭代是否能維持效率?團隊能力是提升還是退化?

我們不確定最終會成功還是失敗,但無論結果如何,這個探索過程的數據、策略與反思,都值得與社群分享。

你將帶走: 三階段流程操作手冊、團隊健診評估表、導入起步包、持續優化追蹤表。


聽眾收穫:

  1. 可立即複製的三階段開發框架完整流程操作手冊(Vibe Coding → 重構 → SDD)
  2. 真實對照組數據與啟發
  3. 降低導入門檻的實戰策略包
  4. 三種團隊演進路徑的選擇指南
  5. 長期成功的持續關注清單關鍵 Takeaway: 開發效率提升只是第一步,持續維運與迭代才是真正考驗。從 2 人試點開始、用初步數據說服團隊、基於健診結果選擇演進路徑、持續關注長期挑戰。
詳細介紹