ClearForge
誰適合這個顧問服務？
AI 開發導入顧問同時服務工程端與產品端——因為 AI 改變的不只是怎麼寫程式，也改變了每個角色在開發流程中的位置。
開發團隊
想把 AI coding 工具（Copilot、Cursor、Claude Code）有紀律地用進日常開發，不只是加速，也守住程式品質與可維運性。
PO／PM
需求在 AI 時代要怎麼寫才能被 AI 用好？任務拆解（SPIDR）、User Story 品質、迭代決策——這些 PM 能力在 AI 時代變得更重要而不是更少。
BA／QA
BA 在 AI 時代如何用 SbE（實例化需求）提升需求規格品質？QA 如何從手動驗證轉型為品質策略制定者，學會評估 AI 生成的程式與規格？
技術主管
如何在組織層面推動 AI 導入，同時做好 AI 治理與品質把關？讓 AI 不只是少數人的特技，而是整個團隊的工作方式。
工程師（個人）
想從「會用 AI 工具」升級到「用 AI 交付可維運的軟體」？Context Engineering、紀律化 AI 開發流程——這是 AI 時代工程師的新核心能力。
想把顧問和課程搭配
顧問是針對你的公司客製陪跑；如果想同時讓更多人快速建立能力，可以搭配 SbE × AI、SPIDR 課程（/courses）。
我們解什麼問題——三個層次
AI 開發導入不只是換工具，而是整個開發方式與角色定位的重塑。
① AI 進開發流程
AI coding 工具（GitHub Copilot、Cursor、Claude Code 等）如何真正嵌進 SDLC（軟體開發生命週期）？不只是「開著補全」，而是在需求規格、設計、實作、測試、code review 各階段，AI 的角色和人的角色分別是什麼。
- AI coding 工具選型與導入策略
- SDLC 各階段的 AI 角色重塑
- Context Engineering：為 AI／Agent 工程化上下文，讓 AI 產出品質可靠
- AI 治理與品質把關：Code review、測試覆蓋、可維運性審查
② AI 時代角色轉型
PO／PM／BA／QA 在 AI 時代的角色不是消失，而是擴張與深化。人人都需要有「PM 能力」：任務拆解、品質評估、迭代決策——因為 AI 讓每個人都能快速生成產出，但判斷對不對、值不值得做，仍是人的工作。
- PO／PM：需求文件如何寫得讓 AI 能有效率地用
- BA：SbE（實例化需求）如何在 AI Agent 時代強化規格品質
- QA：從手動驗證轉型為 AI 生成品質的評估者與策略制定者
- 工程師：從「寫程式」擴張到「驅動 AI 交付可維運系統」
③ 具體技藝：SPIDR × SbE × AI
這些是落地工具，不只是概念：學完當週就能用在真實的 User Story 與需求規格上。
User Story 拆解（SPIDR）
SPIDR 是一套把過大 User Story 有系統地拆成可交付 Story 的方法——Path、Interface、Data、Rules、Operations 五個維度各自有拆法，AI 時代讓拆解本身可以被 AI 協助，但「拆得對」的能力仍在人身上。
AI Agent 時代的需求規格（SbE × AI）
SbE（Specification by Example，實例化需求）用具體範例驅動需求規格，原本就是讓開發端與業務端對齊的橋樑。在 AI Agent 時代，SbE 的結構化規格讓 AI 能正確理解邊界條件與驗收標準，是高品質 AI 開發的關鍵底層。
為什麼找 Jed，不找一般敏捷講師？
| 市場上的敏捷講師／顧問 | Jed（ClearForge） |
|---|---|
| 純敏捷訓練背景 | SbE 底子 × AI × 完整交付生命週期 |
| 教框架，不一定做過上線 | 架構、上線、維運都親自做過 |
| AI 工具是附帶話題 | AI 協作交付是日常（dogfooding 互證） |
| SPIDR／SbE 是課程模組 | 真實專案裡用過的拆解實戰 |
| PM 轉型是理論指引 | 針對你組織的具體角色給出轉型路徑 |
Dogfooding 互證：我們自己就這樣做
ClearForge 的軟體交付本身就用 vibe engineering（紀律化的 AI 工程）——我們不只是教你怎麼做，我們每天就在做。這是理論顧問給不了你的可信度。
看我們怎麼交付軟體術語白話：這些詞是什麼意思？
AI 開發導入顧問用到幾個具名概念，這裡給你直白的解釋。
Vibe Engineering（紀律化的 AI 工程）
Vibe coding 是「憑感覺讓 AI 生成、不加審查」，快但品質失控。Vibe engineering 是帶著架構眼光、品質意識與測試覆蓋去驅動 AI 工具——既得到 AI 的速度，也守住可維運性。ClearForge 的日常交付就是 vibe engineering，不是 vibe coding。
Context Engineering（為 AI／Agent 工程化上下文）
Context Engineering 是指設計、組裝、管理 AI 或 Agent 的上下文（系統提示、範例、工具、記憶等）的工程實踐——讓 AI 在對的情境下產出正確結果，而不是靠運氣。在 AI Agent 時代，上下文品質直接決定 AI 輸出品質。
SbE（Specification by Example，實例化需求）
用具體的例子（examples）驅動需求規格——不只是文字描述，而是「給定這個情境、當使用者做了這件事、應該看到這個結果」的可執行規格。原是測試驅動設計的核心實踐，在 AI Agent 時代讓規格變成 AI 可以直接理解的輸入。
SPIDR（User Story 拆解方法）
SPIDR 是把過大的 User Story 有系統拆解的方法，五個維度：Spike（探索）、Path（流程路徑）、Interface（介面版本）、Data（資料邊界）、Rules（業務規則）。讓巨大的「使用者可以……」拆成可以在一個 Sprint 交付的小故事。
適合的情況
- 開發團隊已在用 AI 工具，但想有系統地提升品質與效率
- PO／PM／BA／QA 想了解自己在 AI 時代的角色如何轉型
- 技術主管想在組織層面推動 AI 導入，又不想品質失控
- 想把 SbE、SPIDR 用在真實專案，不只是學框架
- 需要針對你的組織結構給出客製化的導入路徑
暫不那麼適合的情況
- 只想要一套標準課程，不需要客製輔導（請看 /courses）
- 已有明確技術架構問題，不涉及開發流程或角色轉型（請看技術架構顧問）
- 只想要工具清單，不想改變開發方式
顧問 vs 課程：選哪個？
顧問（本頁）是為你的公司客製輔導與陪跑，根據你的團隊現況、組織結構、工具鏈給出針對性建議並陪你執行。 課程（/courses）是標準化教學，適合想快速讓更多人建立 SPIDR、SbE × AI 等能力的公開班或企業內訓。兩者可以搭配：顧問作為策略與陪跑，課程作為能力建立的加速器。
常見問題
我的團隊適合導入 AI 嗎？
AI 開發工具（GitHub Copilot、Cursor、Claude Code 等）已是現實，問題不是「要不要導入」，而是「怎麼有紀律地導入」。無論是純工程團隊、還是有 PO／PM／BA／QA 的產品開發組織，只要有軟體交付的需求，都值得認真評估 AI 進工作流的方式。適不適合，我們可以在初次諮詢時一起盤點。
導入 AI 開發會不會品質失控？
Vibe coding（憑感覺讓 AI 生成、不加審查）確實會失控。但 vibe engineering（紀律化的 AI 工程）不一樣——它指的是帶著架構眼光、品質意識與測試覆蓋去驅動 AI 工具，讓 AI 加速但不放棄可維運性。ClearForge 自己交付就這樣做（dogfooding），這門顧問服務教你的團隊也這樣做。
PM／QA 在 AI 時代要怎麼轉型？
PM 需要擴張到全交付生命週期：任務拆解（SPIDR）、需求規格品質（SbE × AI）、迭代決策——這些以前靠工程師幫補的能力，現在 PM 需要自己具備。QA 則要從手動驗證轉型為品質策略制定者，學會評估 AI 生成的程式與規格，而不只是點擊測試。顧問服務會針對你的組織結構給出具體的角色轉型路徑。
你和一般敏捷講師差在哪？
Jed 的背景是完整軟體交付生命週期（工程師→Tech Lead→架構師→技術主管→產品中心負責人→顧問），架構、上線、維運都親自做過，不是純敏捷訓練背景。因此能把 SbE（實例化需求）、SPIDR（User Story 拆解）與 AI 工具的實際使用接在一起——不只是流程框架，而是在真實交付壓力下怎麼用。這是與市場上純敏捷講師最明顯的差距。
顧問是怎麼進行的？和課程有什麼不同？
顧問是針對你的公司或團隊的客製輔導／陪跑：先了解你的現況、工具鏈、組織結構與卡點，再給出針對性的建議並陪你執行。課程（/courses）是標準化教學，適合想用公開班或企業內訓快速建立能力的情況。兩者不互斥，可以搭配。