團隊認知不一
團隊對「軟體工程」的認知不一，難以判斷哪些工具與開發流程能「真正提升交付速度與品質」
即便導入了一套又一套 AI 開發工具，整體產能卻沒有顯著提升
payment.feature
功能：付款流程
情境：信用卡付款成功
假設 訂單金額為 1,000 元
當 會員以信用卡付款 1,000 元
那麼 訂單狀態為「已付款」
而且 寄出付款成功通知
情境：付款逾時
假設 訂單建立已超過 30 分鐘
當 會員送出付款
那麼 系統拒絕付款
而且 顯示「訂單已逾時，請重新下單」新需求開發
- 信用卡付款成功等待驗收
- 付款失敗後重試等待驗收
- 付款逾時等待驗收
- 重複付款等待驗收
回歸測試確保既有實作
- 會員登入等待驗收
- 建立訂單等待驗收
- 發票開立等待驗收
0 / 7 通過
每個人都在用 AI，為什麼團隊的交付速度還是快不起來？
AI 加快了程式碼產出，團隊卻仍花大量時間在需求溝通、人工驗證與反覆修改
省下來的開發時間，又消耗在交付前的確認與返工
PM / RD 規格認知落差
PM 交給 RD 的「規格」造成資訊落差，並延伸到後續的 AI 開發
團隊花大量時間反覆溝通、釐清需求、反覆修改
AI 產出快，團隊交付慢
團隊花大量時間與 AI 對齊需求、手動驗證產出，確認 AI 沒有「改 A 壞 B」
導致整個團隊缺乏量能投入真正能提升團隊價值的工作
AI 產出品質難以確認
團隊花費大量時間手動驗證 AI 產出，仍無法確認系統沒有被 AI 改壞
即使加上測試，仍不清楚 AI 測了哪些需求、與對應到規格上的哪些功能
結合 AI 與 BDD（行為驅動開發）以「可執行規格」實現 AI 高可靠的全自動化開發
步驟 1：共同定義可執行規格
PM 與 RD 共同撰寫可執行規格
同步釐清、梳理要交付的業務流程
步驟 2：AI 循環開發與自我驗證
AI 以可執行規格作為 harness，串接測試與實作
反覆開發、自我驗證，直到對應測試通過
步驟 3：一行指令，總覽驗收結果
PM、RD 透過一行指令，總覽各項功能的驗收結果
確認 AI 開發的功能是否能正常運作
水球軟體學院：企業導入案實戰案例
「先前一個審查鏈的功能我看開發至少要 2~3 週喔，這次用 AI x BDD 開發這個複雜功能，用 3 天規劃規格，2 天跑 AI 開發、1 天上線測試，就直接能用了，效率快 3 倍左右。」
導入
476
個 BDD 可執行規格
三個月內在企業 CRM 後端重寫案中
總計
5,025
個測試案例
於一個 Java Spring Boot 專案中
測試驅動開發出
462
個 API Endpoints
於一個 Java Spring Boot 專案中
查看 Ian 的完整原話
三個月內就成功在 CRM 重寫案上導入上百個可執行規格，把 CRM 在上千個測試保護下快速開發出來，這成效實在是顯而易見。先前一個審查鏈的功能我看開發至少要 2~3 週喔，這次用 AI x BDD 開發這個複雜功能，用 3 天規劃規格，2 天跑 AI 開發、1 天上線測試，就直接能用了，效率快 3 倍左右。
雖說 AI x BDD 絕對是需要訓練成員才能導入，但光是這一案的導入成功就在文化影響上幫助公司推進太多。
戰場改變非常劇烈，未來最重要的倒不一定是 BDD 的模式，而是水球在教的軟工思維，有這套思維，那即使戰場劇烈改變，也有一定的應變之道。
已經和我們一起改變開發流程的企業團隊
1,200+小時
企業內訓授課時數
20+家
服務企業
5.0/ 5
講師專業度
3,000+人
線上課學員
30+場
企業內訓場次
4.8/ 5
學員滿意度
我們為企業提供的連續服務
第 1 階段：先內訓，提升團隊對 AI 時代核心「軟體工程」的認知
我們提供一連串的企業教育課程，協助團隊建立 AI 全自動化 SDLC（軟體開發生命週期）
查看所有企業內訓課程內訓課程涵蓋 PM 需求處理到 RD 開發交付，從基礎的 SDD、TDD 與規格撰寫，逐步進階到完整的 AI x BDD 全自動化開發流程
- 團隊有了總體認知之後，搭配「顧問導入」服務
第 2 階段：後導入，打造可直接落地於團隊的 AI x BDD 全自動化開發流程
導入顧問與團隊成員高效合作，用最短時間打造出可直接落地於團隊的「客製 AI x BDD 全自動化開發流程」
查看企業導入詳細透過幾個模組的實際開發、驗證開發流程的可用性、通用性與導入成效
模組 規格 測試 實作 驗收 會員 訂單 付款 第 3 階段：顧問陪跑，陪伴團隊迭代開發流程，支援後續更複雜的需求開發
落地 AI x BDD 全自動化開發流程後，我們透過顧問時數的方式
協助團隊處理後續在流程使用、調整與擴充時遇到的問題
讓 AI x BDD 隨著團隊需求持續優化迭代，支援後續更複雜的需求開發與交付
來聽聽他們怎麼說
01 / 09
「課程含金量高。概念結構化，還有解題與解code是亮點」
科技業學員課後問卷回饋「教材豐富，老師講解清楚，skill的泛用性高」
製造業學員課後問卷回饋「將模糊的概念具體化成了一套流程」
零售業學員課後問卷回饋「講師有問必答收穫良多」
金融業學員課後問卷回饋「流程清楚且對 ai 工作品質具有關鍵價值」
物流業學員課後問卷回饋「有現場解讀code,對工程師很重要」
科技業學員課後問卷回饋「老師具有豐富業界經驗」
製造業學員課後問卷回饋「對AI全coding開發流有明確的認知」
科技業學員課後問卷回饋「貼近業界實際情況」
零售業學員課後問卷回饋「比想像的厲害」
金融業學員課後問卷回饋「Q&A能具體回答」
物流業學員課後問卷回饋「謝謝老師，感謝水球給我們有空間看到不同世界」
製造業學員課後問卷回饋
「有解決目前最大的痛點，就是 PM 工作上與 codebase(現況）的關係，這是現在 PM 最站不住腳也是寫 PRD 一個比較大的阻礙。」
科技業學員課後問卷回饋「在AI已知系統功能的狀況下，透過AI的分析跟發想可以補足規劃的各種面向，對產品設計非常有幫助」
零售業學員課後問卷回饋「深入淺出的內容搭配實作 學習效果很好」
製造業學員課後問卷回饋「對從收到需求到產出規格整體流程更有概念」
物流業學員課後問卷回饋「透過互動的方式可以加強吸收」
零售業學員課後問卷回饋「實作時比較能貼切感受到實用性」
金融業學員課後問卷回饋「老師很專業」
物流業學員課後問卷回饋「有實際案例」
製造業學員課後問卷回饋「實際經驗轉化知識」
零售業學員課後問卷回饋「很棒的知識彙整與建議」
金融業學員課後問卷回饋「受益良多，感謝授課」
物流業學員課後問卷回饋「期待公司安排下一堂課」
製造業學員課後問卷回饋
專業的顧問團隊負責人
水球潘
水球軟體學院負責人
- 軟體工程方法論研究及實踐者，2022 年開設【軟體設計模式精通之旅】，一年內獲 200 位企業資深工程師學員
- 2025 年在自家工程專案中成功落地 AI x BDD 方法論
- 某準上市公司之 AI 軟體開發合作顧問，協助導入 AI 規格驅動全自動開發術
- 國立台灣大學資訊工程研究所
Dana Chang
水球球特務有限公司COO
- 曾在 Hahow 擔任 B2C 業務總監
- 擁有推動企業營運與成長的亮眼紀錄，擅長制定並執行策略藍圖，帶領跨部門團隊
- 為高階主管與創辦人提供具洞察力的決策報告
品毅
水球球特務有限公司企業端負責人
- 長期在科技業擔任技術負責人
- 負責過大型案場（知名金融企業）的機房監控服務建設（DCIM、BMS、RFID）產品設計、系統設計與開發
- 3 間 AI x BDD 企業導入經驗
- 10+ 間 AI x BDD 企業內訓授課經驗
- 長期擔任講師，出席各式軟體工程研討會
課程詳細內容
AI 百倍可靠度：AI 時代下的 SDLC SDD x TDD
掌握 AI 時代下基礎軟體工程的核心概念建立開發可靠度達 60% 的 AI 自動化開發流程
適合誰
AI 一直「改 A 壞 B」，團隊花費大量時間驗證 AI 產出、與 AI 來回溝通
想提高 AI 開發可靠度與交付速度的 RD 開發團隊
課程說明
本課程以 SDD × TDD「5＋2 Steps」為主軸，從一個實際開發需求出發，帶領學員依序完成結構化規格、系統分析、測試計畫、實作計畫與實作，建立 60% 高可靠度的 AI 自動化開發流程與學員的核心「軟體工程」能力與觀念
課程以實際的開發需求與專案作為案例，帶學員從第一步開發步驟深度講解每一個步驟的流程、產出物內容與段落、成效、解決什麼問題，每個步驟皆以「實際」的產出物與程式碼進行講解與說明，並在每個步驟結合動手做的時間讓學員們達到良好的吸收成效
且課程最後也會提供整套「可落地團隊」的通用 Skill Workflow，讓學員們可以直接將課程所學交付團隊
課程成效
建立團隊「軟體工程」核心認知與 AI 高可靠自動化開發流程
透過 SDD（規格驅動開發）定義需求與驗收標準，結合 TDD（測試驅動開發）驗證實作，以「5＋2 Steps」串起從需求到交付的開發流程。
提高 AI 開發可靠度，減少人工驗證與返工時間
在實作前確認需求與系統設計，再以自動化測試驗證產出，減少開發後才發現錯誤、反覆修改的時間成本。
透過回歸測試，防止「改 A 壞 B」
修改功能後持續執行既有測試，檢查哪些業務行為受到影響，及早發現問題。
保留需求與決策脈絡，讓後續修改有依據
將需求意圖、技術決策與測試依據留存在開發流程的產出物中，減少團隊反覆查證，以及知識依賴個人的問題。
課綱11 個單元
01AI 時代高可靠自動化開發的關鍵：Harness＋Loop
- 以「自動化測試」作為 Harness，驗證 AI 產出是否符合需求、能否正確執行。
- 建立「開發 → 測試 → 修正」的驗證 Loop，讓 AI 根據測試結果持續修正，直到測試全部通過。
02AI 時代的 SDLC：SDD × TDD「5＋2 Steps」開發全貌
- 五個主要步驟：結構化規格 /specify → 系統分析 /system-analyze → 測試計畫 /testplan → 實作計畫 /tasks → 實作 /implement。
- 兩個輔助步驟：需求澄清 /clarify、規格一致性分析 /analyze。
- 以一個實際開發需求為例，帶你走過底下每個步驟，以及每個步驟的產出物。
03結構化規格
/specify：將客戶模糊的需求撰寫成明確的結構化規格，途中盤點未知、訂出驗收標準- 從原始不清楚的需求與規格出發，盤點現況、釐清未知，再撰寫成結構化規格。
- 將業務需求以 User Story 格式撰寫，說清楚使用者操作情境與預期的業務價值。
- 以 Given／When／Then 描述驗收情境，讓 PM、RD、QA 能共同確認預期行為。
- 實際產出並審查結構化規格，確認 AI 理解的開發目標符合需求。
04系統分析
/system-analyze：以系統介面作為雛形，減少 AI 開發的返工時間成本- 盤點技術選型，分析實作需求涉及的既有程式與資料庫改動，以及具體修改方式。
- 定義三種系統介面作為雛形，提前驗證 AI 的設計：UI／UX、API、DB Schema。
- 透過前端雛形與操作流程，在實作前確認系統完成後的樣貌。
05測試計畫
/testplan：將上游產物逐條對應到測試案例，減少 AI 產出測試案例的幻覺- 上游產物與測試對應：將上游產物（結構化規格、系統分析）逐條對應到測試案例，明確定義每項需求如何被驗證。
- 測試案例設計：定義前置資料、操作步驟與預期結果，涵蓋成功、邊界與失敗情境。
- 測試分層與選型：理解單元測試、整合測試、端對端測試各自驗證什麼，以及如何兼顧驗證效益與維護成本。
- 實際程式碼逐行講解：以上述內容為基礎，逐行說明測試案例如何撰寫、如何執行，以及如何比對實際結果與預期結果。
06實作計畫
/tasks：依 TDD 驗證循環拆解開發任務，最大化 AI 的產出成效- TDD 五步實作：詳細說明 Red／Green／Refactor 的觀念與實務，依序完成「撰寫測試 → 執行並確認失敗 → 最小實作 → 執行並確認通過 → 重構」。
- 回歸測試：透過既有測試案例，驗證 AI 修改後的程式碼是否破壞既有功能，防止「改 A 壞 B」。
- 避免 AI Overdesign：透過最小實作與多個測試情境逐步形成通用邏輯（Minimal Implementation＋Triangulation），避免 AI 加入需求以外的設計。
- 實作任務拆解：將規格、系統分析與測試計畫，轉成依 TDD 循環執行的小任務，明確指定每項任務的實作依據與完成條件。
- 程式碼實務講解：由講師逐行講解，再由學員上台說明測試與實作如何運作。
07實作
/implement：依實作計畫開發，讓 AI 根據測試結果持續修正- 讓 AI 依實作計畫逐項執行，完成測試撰寫、程式實作與重構。
- 根據測試結果持續修正，直到計畫中的測試全部通過。
- 檢視實作與測試結果，實際操作關鍵流程，確認交付成果符合規格。
08需求澄清
/clarify：把不清楚的需求問清楚，減少 AI 自行猜測- 從規格中找出尚未定義的條件、例外情境與待決定事項。
- 由 AI 協助整理問題，交由負責人確認，再將答案補回規格。
09規格一致性分析
/analyze：比對每一步的產出，找出功能與設計遺漏- 交叉比對需求規格、系統設計、測試計畫與實作計畫，檢查是否一致。
- 找出未對應的需求、互相矛盾的設計，以及缺少驗證的功能。
- 規格變更時，盤點受影響的產出並同步修正。
10專案憲法
/constitution：讓 AI 開發遵循團隊共同規範- 將技術棧、程式風格、專案架構與測試要求整理為專案憲法。
- 審查與調整 AI 產出的規範，讓後續開發依循團隊既有做法。
11課程回顧：串起從需求到實作的完整流程
- 透過便利貼重建「5＋2 Steps」流程，整理各步驟的目的、指令與主要產出。
- 回顧規格、系統分析、測試與實作如何銜接，以及每一步需要由人確認的內容。
AI x BDD：規格驅動高可靠全自動化開發流程
把業務規格，精準翻譯成自動化測試以「可執行規格」建立 AI 百倍高可靠全自動化開發流程
適合誰
已具備 SDD、TDD 基礎
想進一步提升 AI 開發可靠度，串起完整 AI 高可靠全自動化開發 SDLC 的 PM／RD 團隊
課程說明
本課程承接 SDD × TDD，將業務規格精準翻譯成自動化測試，讓規格不只用來說明需求，也能直接驗證 AI 是否依規格完成開發。透過「可執行規格」串起需求、測試與實作，讓 AI 根據測試結果持續開發、修正，直到測試全部通過，建立高可靠的全自動化開發流程
課程以實際的開發需求與專案作為案例，從 Gherkin、驗收情境撰寫，到 Step Definition 與測試案例的掛鉤，深度講解每一個步驟的流程、產出物內容與段落、成效、解決什麼問題。每個步驟皆以「實際」的產出物與程式碼進行講解與說明，並結合動手做的時間，讓學員親自走過規格、測試與 AI 開發的完整流程
課程最後透過既有的 AI x BDD Skill Workflow，帶學員以指令執行測試、閱讀視覺化測試報告，從規格掌握哪些功能已完成驗證、哪些情境仍未通過。並透過新增測試情境，實際練習需求修改後的開發與驗收，理解 PM 與 RD 如何依同一份「可執行規格」高效協作
課程成效
提升至少 3 倍的團隊產出與交付速度
透過「可執行規格」與自動化測試，提高 AI 開發可靠度，減少來回修改與人工驗證，將程式碼產出轉化為可交付的軟體成果。
讓 PM 與 RD 依同一份規格溝通與驗收
在開發前用具體情境說清楚業務需求與預期結果，並將驗收情境掛鉤到實際測試，減少需求誤解與反覆修改。
從規格掌握開發成果，減少人工驗證負擔
透過視覺化測試報告，直接對照 AI 測了哪些需求、哪些情境已通過，不必只靠閱讀大量程式碼與逐項手動操作來確認。
以回歸測試保護既有功能，降低「改 A 壞 B」風險
將成功、邊界與錯誤情境保留為可重複執行的測試，在 AI 修改功能後重新驗證，檢查既有業務流程是否受到影響。
課綱8 個單元
01從 SDD × TDD 到 AI x BDD：以「可執行規格」串起需求、測試與實作
- 理解只有規格與測試程式碼時，團隊為什麼仍難以確認 AI 測了哪些業務需求。
- 認識 Gherkin、Feature File、Step Definition 與產品程式碼之間的對應關係。
- 以實際開發需求展示完整流程，理解每一步的目的、產出物與驗證方式。
02Gherkin 與舉例說明：將業務規則寫成具體、可驗收的測試案例
- 以 Feature、Rule、Example 整理功能、業務規則與測試案例，掌握每一層的撰寫顆粒度。
- 透過 Given／When／Then，具體描述前置條件、操作與預期結果，列出實際資料與數值。
- 使用 Background 與 Data Table 整理共用條件與多筆資料，讓規格清楚、容易閱讀。
- 從同一條業務規則補出成功、邊界與錯誤情境，增加業務行為的測試覆蓋。
03需求舉例說明
/spec-by-example：在開發前對齊完整驗收流程，減少需求誤解- 從結構化規格的 User Story 與需求，整理出可與 PM 共同確認的 Gherkin 驗收流程。
- 以具體資料與預期結果說清楚「這個功能要怎麼驗收」，讓人與 AI 依同一組案例理解需求。
- 審查 AI 產出的驗收情境，找出尚未確認的規則與例外，先釐清再進入後續開發。
04DSL 精煉
/dsl-refine：將業務語言對應到系統介面，減少 AI 撰寫測試的誤解- 依系統分析，將驗收流程對應到前端與後端各自需要驗證的行為，整理成 Feature Files。
- 以 dsl.md 明確定義每個句子的參數、前置資料、操作與預期結果。
- 將句子語意對應到 UI 操作、API 呼叫與資料庫狀態，讓 AI 撰寫測試時有明確依據。
- 審查每條 Rule 與 Example 的顆粒度，確認測試案例能對應回上游的驗收要求。
05Step Definition 掛鉤：將 Gherkin 的每個步驟對應到實際測試程式碼
- 將 Given／When／Then 分別對應到 Arrange／Act／Assert，理解規格如何被執行。
- 以實際程式碼逐行講解 Step Definition 的句型綁定、參數傳遞、資料準備與結果驗證。
- 透過共用的測試步驟組合不同案例，理解新增情境時哪些程式碼可重用、哪些需要補寫。
- 以 Behave 與 playwright-bdd 的教材範例，示範 Feature Files 如何掛鉤到後端與前端測試。
06BDD 實作
/bdd：依「紅燈、綠燈、重構」驅動 AI 完成需求- Red：依 Feature Files 與 dsl.md 補齊 Step Definition，確認測試可執行，並因目標功能尚未完成而失敗。
- Green：讓 AI 依測試結果實作與修正程式，直到對應業務情境通過。
- Refactor：在既有測試保護下整理實作，重新執行測試，確認原有行為仍可正常運作。
- 以實際產出物與程式碼對照，檢查 AI 的測試是否正確表達規格中的行為；上游規格不完整時先釐清，不讓 AI 自行補定業務規則。
07任務拆解與流程串接
/tasks、/implement：將可執行規格接回 AI 自動化開發流程- 以 Feature File 作為開發任務的主要單位，串起 BDD 的紅燈、綠燈與重構。
- 審查任務計畫是否涵蓋本次需要實作的 Feature Files，並保留對應規格與測試依據。
- 執行既有 Skill Workflow，觀察 AI 如何依任務計畫完成測試、實作與驗證 Loop。
08測試報告與課堂實作：從規格掌握 AI 功能的實作與驗證狀態
- 透過指令執行 BDD 測試，從視覺化報告查看 Feature、情境與測試步驟的執行結果。
- 對照規格與實際操作，確認哪些需求已被測試、哪些情境仍未涵蓋。
- 動手新增一條邊界或錯誤情境，執行測試並觀察失敗、修正與再次驗證的過程。
- 回顧從驗收規格、DSL、Step Definition 到實作的對應，串起可執行、可驗收的 AI x BDD 開發流程。
Skill Engineering：打造可控、可維護、可擴充的 Skill Workflow
透過正確 Skill Engineering 的觀念與工具，讓團隊的核心 Skill Workflow 開發流程維護不再被 AI 掌控
適合誰
撰寫許多 Skill，但 AI 撰寫、修改 Skill 時一直疊床架屋
想修改卻看不懂、要 AI 改 Skill 到一定複雜度就改不動看不到成效的所有有在撰寫 Skill Workflow 的團隊
課程說明
本課程以 Skill 模組化設計為主軸，帶領學員從 AI 反覆撰寫與修改 Skill 的案例，理解流程、規則與提示為什麼會越疊越多，讓 Skill 難以閱讀與維護。從最小可執行 SOP 開始，逐步建立 Rules、Templates 與 Scripts，讓各部位有明確的職責與引用關係，建立團隊理解、修改與維護 Skill 的能力
課程以類別圖提案、規格文件與既有 AI 開發流程作為案例，深度講解每一個步驟的流程、產出物內容與段落、成效、解決什麼問題。每個步驟皆以「實際」的 Skill 檔案、產出物與程式碼進行講解與說明，並結合動手做的時間，讓學員理解各個部位為什麼存在、如何撰寫，以及如何驗證 AI 是否依預期執行
課程進一步透過 Skill Engineering 與 Artifact-First，帶學員從目標產出反推 Skill，依單一職責拆分與串接 AI 開發流程。練習從預期與實際產出的落差找出 Root Cause，判斷該修改的流程、規則、樣板或腳本，再以不同需求執行並比對結果，讓團隊在 Skill 變複雜後仍能掌握怎麼改、如何驗證成效
課程成效
讓 AI 撰寫的 Skill 可閱讀、可維護
以 SOP、Rules、Templates、Scripts 組織 Skill，讓團隊看懂每個步驟如何執行、會讀取哪些規則，以及改動時應從哪裡著手。
透過 Skill Engineering 定位問題，減少修改時疊床架屋
從產出落差找出 Root Cause，再判斷要調整流程、規則、樣板或腳本，減少反覆補提示與試錯。
在 Skill 變複雜後，仍能驗證修改成效
用不同需求實際執行 Skill，比對修改前後的產出，檢查 AI 是否依預期遵守流程、規則與格式。
讓團隊掌握核心 Skill Workflow 的維護與擴充
以單一職責、按需載入與規則單一溯源組織多個 Skill，讓團隊在需求或規範改變時，能自行調整 AI 開發流程並驗證結果。
課綱10 個單元
01Skill 為什麼寫了卻不好用：從實際產出找出難以理解、修改與驗證的原因
- 從 AI 產生的 BDD Autopilot 與實際執行結果，理解「Skill 寫了很多」與「能完成預期工作」之間的差異。
- 拆解 Skill 裡的流程、規則與提示，辨認關注點混雜、重複描述，以及步驟與規則沒有明確對應的問題。
- 理解為什麼團隊需要看懂 Skill 的運作細節，才能判斷產出、定位問題與持續修改。
02Skill 模組化設計：以 SOP、Rules、Templates、Scripts 建立可理解、可維護的 AI 開發流程
- 掌握 SKILL.md 主流程，以及 rules/、templates/、scripts/ 各自承載的內容與職責。
- 理解按需載入、遵守流程、遵守規則、提高步驟執行效率，以及每條規則單一溯源這五項設計考量。
- 從最小可執行 SOP 開始，在需要時才展開規則、樣板或腳本；流程變複雜後，再依職責拆成多個 Skill。
- 以實際 Skill 目錄與檔案，對照每個部位如何互相引用、何時載入，以及修改時應從哪裡著手。
03SOP 撰寫
/skill-form-sop：把工作步驟寫成 AI 能依序執行的流程- 動手撰寫 SKILL.md，定義 Skill 名稱、使用時機與主要職責。
- 以 Phase 與 Step 組織流程，透過 READ、WRITE、THINK、DELEGATE 說清楚每一步要讀什麼、想什麼、產出什麼或委派什麼。
- 將補充規則移到適合的檔案，並在實際使用的步驟引用，避免主流程塞滿重複說明。
- 以「開發前先產出類別圖提案」的案例，完成最小可用 Skill，實際執行並檢查產出。
04規則撰寫與展開
/skill-form-rule、/skill-derive-rule：用判準與正反例，約束每一步的執行品質- 將步驟需要遵守的判準與限制寫成 Rule File，區分流程動作與規則說明。
- 撰寫規則名稱、具體內容與 MUST／SHOULD／MAY，說清楚規則的要求。
- 使用具體資料撰寫 Good Example 與 Bad Example，對照遵守與違反規則時的差異，檢查範例本身是否正確。
- 從指定 SOP 步驟展開規則，將規則路徑與讀取時機回寫原步驟，保留可直接執行的動作。
05樣板撰寫與展開
/skill-form-template、/skill-derive-template：讓 AI 依明確格式產出符合團隊需要的內容- 判斷什麼應寫成條列規則，什麼是穩定、可重複使用的產出格式，適合抽成 Template。
- 建立樣板骨架與已填入實際資料的範例，讓 AI 同時知道格式與內容應達到的程度。
- 設計填位符號，區分固定結構與可變內容，保持相同資料在不同位置的命名與填值一致。
- 將骨架、範例與使用方式接回 SOP，實際檢查產出是否符合格式與原本目的。
06腳本撰寫與展開
/skill-form-script、/skill-derive-script：將適合自動化的步驟交給程式，減少重複分析時間- 判斷哪些步驟適合由 AI 推理，哪些可委派 Python 腳本執行。
- 以程式碼結構分析為例，說明腳本如何先整理需要的資訊，再交給 AI 進行後續判斷。
- 理解腳本的輸入、輸出、依賴與執行方式，將腳本呼叫接回對應 SOP 步驟。
- 以實際腳本及執行結果講解與驗證，檢查是否取得需要的資料、是否減少不必要的讀取與分析。
07Skill 建立與優化
/skill-engineering：整合模組化流程，定位並修正產出問題- 區分新建 Skill 與優化既有 Skill：新建先建立最小 SOP，優化先確認預期產出與實際結果的落差。
- 從不滿意的產出回推 SOP、Rules、Templates、Scripts 及相關 Skill，找出 Root Cause，先確認原因再提出改法。
- 逐步判斷哪些內容保留、改寫、展開或刪除，避免只增加提示與規則，卻沒有處理根本問題。
- 透過編排既有 Form 與 Deriver Skills 完成修改，檢查整體流程、引用與產出能否共同符合預期。
08Artifact-First
/artifact-to-skill-engineering：從目標產出反推 Skill 的流程與規則- 選定一份實際 Artifact 範例，先依團隊需要修改並確認內容，而不是一開始就請 AI 寫出整套 Skill。
- 從已確認範例抽出 Template 與 Example，再反推從輸入到目標產出所需的 SOP 與規則。
- 以規格文件與類別圖提案為例，實際走過選範例、改範例、抽樣板、建立 Skill 的過程。
- 判斷 Artifact-First 的適用情境；對直接執行開發等不以固定文件格式為核心的工作，改從行為要求與既有流程分析。
09多 Skill 的 AI 開發流程改造：依單一職責拆分流程，讓團隊能持續客製與擴充
- 以「只有一個被改變的原因」及內容的修改關聯，判斷 Skill 的切分顆粒度，避免只用「每個 Skill 做一件事」籠統拆分。
- 以既有 SDD 的 AI 開發流程為例，理解如何拆出技術分析、系統分析與不同介面規劃的職責。
- 對照上游產出與下游輸入，讓多個 Skill 依明確的文件、資料與引用接續工作。
- 區分流程與專案規範，理解不同團隊如何在既有 AI 開發流程上調整產出格式與要求。
10實作與驗收：完成一個 Skill，根據實際產出持續迭代
- 以課堂案例實際建立或修改 Skill，說明 SOP、規則、樣板與腳本各自為什麼需要存在。
- 在新對話執行 Skill，檢查 AI 是否按預期流程、規則與格式完成工作，再用不同需求檢查產出。
- 比較修改前後的結果，說明問題出在哪個部位、為什麼這樣改，以及如何確認修改有效。
- 將需要調整的內容回到 Skill 持續修改，保留最小必要流程，逐步累積可理解、可維護的工作方式。
反向工程：既有實作反向回規格，串起 AI x BDD 自動化開發流程
透過可靠的反向工程開發流程，讓你在舊系統功能重寫、遷移到新系統、新的技術堆疊時更加可靠將既有實作反向回規格後，直接在新系統串回 AI x BDD 進行高可靠的全自動化開發
適合誰
想要透過 AI 做舊系統遷移卻怕功能遺漏，想要有一套可靠的反向工程 + 直接在新系統串起規格驅動開發流程的 RD 團隊
課程說明
本課程以「實作 → 端對端測試（途中補齊業務邏輯）→ DSL、Gherkin → 新系統 BDD」為主軸，帶領學員從既有實作建立端對端測試，在執行測試時釐清業務規則、例外與預期結果，再把確認要保留的行為反向回「可執行規格」。讓團隊在舊系統功能重寫、遷移到新系統或更換技術堆疊時，有規格可依循、有測試可驗證
課程以一條實際業務流程作為案例，從既有程式碼、系統操作與測試資料，到端對端測試、DSL、Gherkin、Step Definition 與新系統實作，深度講解每一個步驟的流程、產出物內容、成效與解決的問題。每個步驟皆以「實際」的產出物與程式碼進行講解與說明，並結合動手做，讓學員將反向回來的規格直接串回新系統的 AI x BDD 開發流程，以相同業務情境驗證新舊系統的結果
課程成效
建立可靠的反向工程流程，釐清要遷移的功能與業務邏輯
從既有實作建立端對端測試，對照實際操作與結果，在測試過程中補齊業務規則、例外與預期結果。
讓舊系統重寫與遷移有測試可驗證，降低功能遺漏風險
把確認要保留的功能與業務行為寫成可重複執行的測試，逐條對照規格與驗收結果，掌握哪些情境已驗證、哪些仍待補充。
更換技術堆疊時，保留既有業務行為
以相同的業務輸入與初始條件比對新舊系統的結果，讓團隊可以採用新的技術與內部實作，仍能依同一套業務規格驗收。
將反向回來的規格直接串回新系統的 AI x BDD 開發流程
將 DSL、Gherkin 掛鉤到新系統的 Step Definition 與測試，讓 AI 依規格開發、根據測試結果修正與驗證，建立高可靠的全自動化開發流程。
課綱8 個單元
01反向工程流程全貌：從既有實作、端對端測試到新系統的 BDD 開發
- 理解為什麼先從既有系統建立端對端測試，再反推規格，能讓後續的需求確認與開發有實際行為依據。
- 掌握「既有實作 → 端對端測試 → DSL／Gherkin → 新系統 BDD 開發」的完整流程，以及每個步驟的產出物與承接關係。
- 以一條實際業務流程作為課程案例，展示既有系統操作、端對端測試、Gherkin 與新系統驗收結果的對應。
02反向範圍與環境準備：選定業務流程，建立可執行、可重複驗證的起點
- 從本次要修改、重構或移轉的功能出發，選定業務流程、涉及的角色、畫面與上下游系統。
- 盤點既有實作、相關文件、測試帳號、輸入資料與外部依賴，確認實際操作與驗證所需的條件。
- 準備可重複使用的測試資料與初始狀態，區分可以實際執行的部分，以及仍缺少來源或環境的部分。
03既有實作反推端對端測試：將實際操作與可觀測結果寫成自動化驗證
- 讓 AI 閱讀既有實作，沿操作入口追查處理流程、條件判斷、資料來源與結果，建立端對端測試案例。
- 為每個案例定義初始狀態、測試資料、操作步驟與預期結果，驗證畫面顯示、訊息、報表或對外輸出。
- 在既有系統實際執行測試，檢查 AI 是否漏掉必要步驟、用錯資料，或寫出沒有依據的斷言。
- 以「實際」的測試程式碼與執行結果逐段講解，保留測試案例對應的實作與來源。
04業務邏輯補齊：在測試過程中釐清權限、狀態、例外與跨畫面條件
- 隨每個端對端測試的撰寫與執行，盤點角色權限、資料狀態、輸入邊界、錯誤處理與跨畫面的參數傳遞。
- 對照既有實作、操作紀錄、歷史需求與人員說明，找出尚未涵蓋、彼此不一致或需要確認的業務條件。
- 由 PM、RD 或熟悉業務的人確認，區分需要保留的既有行為、既有缺陷與這次要改變的需求。
- 把確認結果補回測試案例、預期結果與決策紀錄，再執行驗證，逐步補齊本次範圍的業務邏輯。
05測試反推 DSL／Gherkin：把已驗證的案例整理成業務可讀的可執行規格
- 從端對端測試的初始狀態、操作與結果，反推 Given／When／Then，說清楚業務情境與預期行為。
- 以 Feature、Rule 與 Scenario 整理功能、業務規則與具體案例，建立一致的業務用語。
- 將測試中的成功、邊界與錯誤情境保留到 Gherkin，對照原案例檢查轉寫後是否遺漏條件或改變意思。
- 將畫面定位、程式呼叫等執行細節留在測試實作，讓 DSL／Gherkin 表達業務行為，並保留規格與原測試的對應。
06Step Definition 與測試掛鉤：讓反推的 Gherkin 能執行並驗證原有行為
- 將 Given／When／Then 掛鉤到資料準備、操作與結果斷言，理解 Gherkin、Step Definition 與端對端測試的對應。
- 執行反推後的可執行規格，對照既有測試結果，確認業務條件與預期結果沒有在轉寫時失真。
- 分清楚可以承接的業務情境，以及舊系統特定的操作與技術細節，為新系統重新掛鉤測試做準備。
07新系統 BDD 開發：讓 AI 依 Gherkin 開發，透過測試持續驗證與修正
- 以確認後的 DSL／Gherkin 作為新系統的開發依據，將相同業務情境掛鉤到新系統的 Step Definition 與測試實作。
- 透過 AI x BDD 流程，讓 AI 根據規格與測試結果完成開發、修正與驗證，直到本次範圍內的測試全部通過。
- 以業務行為與驗收結果作為依據，讓新系統可以採用不同的內部實作。
08Workshop 與新舊行為比對：完成一輪實作、測試、Gherkin 與 BDD 開發
- 從課堂選定的既有功能出發，動手建立端對端測試，釐清並補齊業務邏輯，再反推 DSL／Gherkin。
- 將可執行規格接到新系統的 BDD 流程，執行測試並閱讀結果。
- 以相同的業務輸入與初始條件，比較新舊系統的可觀測結果；有意改變的行為，依已確認的新需求驗證並保留理由。
- 分享每個步驟的實際產出物、確認過的業務條件、已通過的測試，以及仍待補充或驗證的情境。
AI-Native Planning：如何透過流程，提高你身為 PM 的決策品質
提高 PM 決策品質，訂出真正能解決客戶問題的 Solution保留決策脈絡，寫出讓 RD 的 AI 能精準開發的規格
適合誰
需求反覆修改、規格交接常有資訊落差，開發完成才發現沒有解決客戶的問題
想透過 AI 提高決策品質與規格撰寫能力，減少溝通與返工的 PM 團隊
課程說明
課程回答三個核心問題：
如何提高 PM 的決策品質？
如何保存決策脈絡作為規格？
決策完成後，如何撰寫讓 RD 的 AI 「提高自動化開發精準度」的規格？
本課程以 AI-Native Planning 為主軸，從一個實際的客戶需求出發，帶領學員依序完成現況分析、Problem 定義、Solution 發散與確認，再將決策脈絡與定案內容寫成規格。建立 PM 在 AI 時代下的核心認知與決策流程，提高決策品質，並讓 RD 的 AI 有明確依據進行後續開發
課程以實際的開發需求與專案作為案例，深度講解每一個步驟的流程、產出物內容與段落、成效、解決什麼問題。從需求原話、現況分析與 Problem，到方案比較、Mechanism Spec、Feature Spec 與 Plan，每個步驟皆以「實際」的產出物與前後變化進行講解，並結合動手做的時間，讓學員理解 AI 提供的分析、學會判斷與做出決策
課程最後透過 Workshop，讓學員獨立處理一則需求，說明確認的 Problem、評估過的 Solution、最後的選擇與理由，並以系統雛形呈現預期操作。透過實作、討論與分享，將課堂所學串成一套從需求分析、決策到規格交接的完整流程
課程成效
提高 PM 決策品質，讓團隊做對的事
從系統現況與客戶真正的工作困難出發，透過方案推演、反例與全貌消融比較不同 Solution，讓 PM 有依據地判斷與取捨。
寫出 RD 與 AI 能接續的規格，提升開發精準度
透過 Mechanism Spec 與 Feature Spec，說清楚設計、範圍、操作條件與預期結果，減少 RD 與 AI 自行猜測需求。
保留決策脈絡，減少重複查證與交接落差
將需求原話、現況、Problem、方案比較與決策理由保存為規格與 Plan，讓後續接手的人與 AI 能延續既有脈絡。
開發前用規格與雛形對齊，減少驗收落差與返工
以具體的操作、系統狀態與預期結果確認功能，再透過雛形檢視畫面與流程，讓需求落差更早被發現與釐清。
課綱8 個單元
01PM 的核心職責與規格目的：提高決策品質，保留人與 AI 能延續的決策脈絡
- 理解 PM 在 RD 開發前，為什麼要先定義「做什麼事情是對的」，訂出真正能解決客戶問題的 Solution。
- 從客戶提出改法、RD 開發後卻沒有解決問題的情境，理解需求、Problem 與 Solution 的差別。
- 理解規格的核心目的「保留你的決策脈絡」：讓後續接手的人與 AI 知道為什麼改、研究過什麼、比較過哪些方案、最後決定什麼。
02AI-Native Planning 流程全貌
/wba-ai：從客戶需求走到可交接 RD 的規格- 掌握現況分析 → Problem 定義 → Solution 發散 → Solution 分析收斂的決策流程。
- 理解 Discovery、Formulation 與 RD Automation 的分工，以及決策脈絡、規格與後續開發如何承接。
- 以一個實際開發需求為例，帶學員走過底下每個步驟、各步的產出物與 AI 操作方式。
03現況分析：從系統全貌盤點需求影響，減少資訊遺漏與判斷落差
- 保留初始需求脈絡：記錄客戶原話與背景，避免整理後只剩功能名稱。
- 查證相關來源，理解現況與上下游關係：從既有規格、程式、資料與操作，盤點需求涉及哪些功能、規則與系統設計。
- 盤整「已知、未知與待決定事項」，區分已查證資訊與仍需釐清的內容。
- 以實際現況分析文件，逐段說明需求原話、已知、復現步驟、現行做法與需求落差、影響範圍及待釐清內容，並帶學員動手操作。
04Problem 定義：還原客戶真正的工作困難，建立比較 Solution 的依據
- 保留需求原話，結合現況還原「誰、想做到什麼、遇到什麼困難」，區分客戶提出的改法與真正要解決的問題。
- 透過第一性原理可能性分析，檢查同一句需求可能有的不同理解，找出需要向客戶確認的部分。
- 釐清系統上必須同時顧及的條件，以及可能造成的問題，避免只處理眼前畫面卻影響其他功能。
- 透過 Clarify 補足必要資訊，確認依據並保存 Problem；以實際文件講解各段內容，帶學員閱讀、回答與確認。
05Solution 發散與確認：透過方案推演、反例與全貌消融，做出有依據的取捨
- 核對這次的 Problem 與上游檔案，確認各方案要處理相同的問題與條件。
- 發散能達到目標的不同解法，同時考慮畫面入口、操作、資料修改與上下游影響。
- 推演使用者如何完成工作，以同一筆資料比較各方案修改前後的結果、差異與代價。
- 用反例與全貌消融檢驗方案、假設與必要性：拿掉某個設計會失去什麼？能否用其他方式達成？依結果修正方案並重新比較。
- 提案並說明取捨，讓使用者理解各方案保留什麼、捨棄什麼，再確認本次 Solution 與改動範圍。
- 同步並歸檔已確認的 Solution，保留比較過程與決策理由，作為後續規格的依據。
06規格撰寫：將決策寫成 Mechanism Spec 與 Feature Spec，提高 RD 的 AI 開發精準度
- 撰寫 Mechanism Spec：說清楚定案的設計／機制與範圍，以及相關功能如何共同運作。
- 撰寫 Feature Spec 的前置條件：權限、參數合法條件，以及執行前應具備的系統與資料狀態。
- 撰寫功能完成後的結果：使用者應得到什麼回應、系統與資料如何更新。
- 撰寫「前置成立，但執行沒有完成」時的結果：使用者應看到什麼回應、系統與資料應維持什麼狀態。
- 以實際規格及 Plan，逐段對照需求、Problem、Solution、改動內容與驗收步驟，理解決策脈絡如何保存，讓 RD 與 AI 能依據規格接續開發。
07基本檢查與系統雛形：補齊必要條件，以畫面確認預期操作
- 認識 Gap／一致性分析的基本用途：檢查需求是否漏掉必要條件，以及相關設計能否共同成立。
- 在既有流程中閱讀並回答待釐清問題，理解新資訊可能如何影響前面的 Problem、Solution 與規格。
- 以 HTML 系統雛形呈現已確認的操作，對照規格、畫面與預期結果，練習在交接 RD 前確認需求。
08Workshop 與課程回顧：獨立完成一則需求，說清楚決策與規格
- 從課堂題目選取一則需求，依流程操作 AI，練習現況分析、Problem 定義、Solution 比較與規格整理。
- 說明需求原話、確認的 Problem、評估過哪些 Solution、最後選擇哪個 Solution，以及選擇理由，並 Demo 系統雛形。
- 透過實作、討論與分享，檢視自己是否理解每一步的判斷與產出物。
- 以便利貼回顧規格目的、PM 職責、現況分析三步、Problem 定義四步、Solution 發散與確認六步，將各步的產出物重新接回完整流程。
AI-Native Planning Lv2：掌握系統全貌，確保規格自洽與一致
掌握 AI 輔助的 Gap 與一致性分析，確保系統規格自洽讓 PM、RD 與 AI 依據一致的規格協作，減少需求遺漏與開發返工
適合誰
規格越寫越多，功能之間的規則卻互相衝突，需求一改就要反覆確認影響範圍
已完成 AI-Native Planning Lv1，想提高系統規格品質、減少溝通與返工的 PM 團隊
課程說明
本課程承接 AI-Native Planning Lv1，以「系統規格的自洽與一致性」為主軸，從一個涉及多個功能的開發需求出發，帶領學員依序完成規格關聯盤點、需求變更的影響分析、Gap 與一致性分析、澄清與決策，再將確認內容同步回規格並重查，建立 PM 在 AI 時代下維護系統規格品質的核心觀念與實際做法
課程以同一組相關功能的規格與需求變更作為案例，深度講解每一個步驟的流程、分析依據、產出物內容與段落、成效、解決什麼問題。從共用規則、Mechanism Spec、Feature Spec 到 Plan，每個步驟皆以「實際」的規格與前後變化進行講解，並結合動手做的時間，讓學員學會檢視 AI 的分析、釐清必要條件，並判斷規格之間的設計能否同時成立
課程最後透過 Workshop，讓學員完成一輪跨功能的影響分析、規格檢查、澄清與修正，說明問題的原文依據、影響、最後的決策與修改內容，再以原情境重新檢查。透過實作、討論與分享，將課堂所學串成一套能持續維護系統規格、讓 PM、RD 與 AI 接續協作的流程
課程成效
建立團隊系統規格品質的共同認知與檢查流程
透過規格分層、Gap 與一致性分析，理解什麼條件需要補齊、哪些設計不能同時成立，讓 PM、RD 與 AI 有共同依據判斷規格品質。
在開發前找出需求遺漏與規格衝突，減少返工
以角色、權限、資料狀態與邊界情境檢查必要條件，再對照相關功能的規則與結果，減少交給 RD 與 AI 開發後才發現需求不清或設計互相矛盾。
掌握需求變更的影響範圍，減少功能之間的連帶問題
沿共用規則與上下游功能推演，找出需要同步修改的規格，減少只改單一功能而遺漏其他設計的情況。
保留決策脈絡與現行共識，減少反覆溝通與查證
將已確認的答案更新到現行規格，於 Plan 保留修改理由與來源，讓接手的人與 AI 能延續既有決策，減少誤用過時內容與重複釐清。
課綱8 個單元
01系統規格的自洽與一致性：從一個功能合理，進到整套系統能共同運作
- 從同一個需求涉及多個功能的情境，理解為什麼每份規格單獨看都合理，放在一起卻可能互相衝突。
- 區分必要條件未定的 Gap、已定規則互相矛盾，以及實際系統未符合規格，理解三者需要不同的查證與處理方式。
- 以同一個開發需求貫穿課程，對照原規格、分析依據、澄清問題與修正後的產出物，理解各步如何接續。
02規格分層與關聯
/wba-formulation：保留決策依據，建立功能之間可追溯的關係- 理解 Vision、Problem、Principle 與 Specs 各自記錄什麼，以及具體功能如何承接上游目的與條件。
- 對照 Mechanism Spec 的共用設計與 Feature Spec 的操作條件、執行結果，盤點哪些規則需要共同遵守、哪些只適用於特定功能。
- 練習以引用保留共用規則，避免在多份功能規格重複撰寫，修改一處卻遺漏其他地方。
- 區分現行已確認內容、候選與歷史決策，避免人與 AI 把舊提案當成目前規格。
03需求變更的影響分析：找出功能之間的隱性關聯，避免只改眼前的規格
- 從一個需求出發，盤點涉及的角色、操作、資料狀態、共用規則與上下游功能。
- 沿著同一筆資料的操作流程，追查前一步的結果是否滿足下一步的條件，而不只搜尋相同的功能名稱。
- 以既有「編輯加班薪資明細」案例為起點，分析編輯範圍與狀態限制改變時，需要重新檢查哪些相關規格；新增情境以教學假設標示。
- 區分已查證的影響、仍需確認的關聯與不受本次變更影響的部分，保留分析依據。
04Gap Analysis
/wba-gap-analysis：找出尚未說清楚的必要條件，減少 AI 自行補完需求- 從既有待釐清內容與適用規格出發，找出資訊不明、歧異、尚未決定或必要內容未完整定義的地方。
- 盤點角色、權限、資料狀態、輸入邊界，以及成功、未完成時的預期結果；依實際需求檢查操作順序與必要條件組合。
- 以「哪些狀態可以編輯」「修改尚未完成時資料應維持什麼狀態」等情境，說明缺少答案會如何改變 RD 與 AI 的開發結果。
- 查證既有來源是否已有答案，區分真正需要補充的條件與已交由 RD 決定的實作細節，避免把所有未知都變成問題。
05Consistency Analysis
/wba-consistency-analyze：以具體情境找出規格之間不能同時成立的設計- 對照共用規則、Mechanism Spec 與相關 Feature Spec，核對角色、狀態、時間與適用範圍是否重疊。
- 以「共用規則禁止修改某狀態的資料，個別功能卻允許修改」的教學情境，指出衝突原文、觸發條件與彼此矛盾的結果。
- 沿完整操作流程推演，檢查前後步驟、共用資料與多項條件能否同時滿足，避免只做文字比對或只看兩份規格。
- 分辨真正的矛盾、不同情境下的合理差異，以及已被取代的歷史內容；依具體影響判斷哪些問題應先處理。
06澄清與決策
/wba-clarify：將分析結果轉成能判斷、能回答的問題- 整理原文依據、目前已知內容、尚未釐清之處與受影響功能，讓回答者知道問題為什麼需要處理。
- 用具體操作情境說明不同選擇會保留或改變哪些規則、影響哪些結果，再提出可比較的選項。
- 分辨可以自行查證的事實、已有決策能回答的問題，以及需要 PM、RD 或業務負責人確認的取捨。
- 當答案改變原本的 Problem 或 Solution 時，回到受影響的步驟重新確認，避免只在下游規格補一條例外。
07規格同步與重查
/wba-ai：將決策回寫現行規格，維持後續開發依據的一致- 將已確認的答案更新到對應規格，於 Plan 保留本次修改、決策理由與來源，不讓結論只留在聊天紀錄。
- 沿影響分析更新相關共用規則與功能規格，保留被取代內容的歷史身分，避免新舊內容同時被當成有效依據。
- 回到原本發現問題的情境與受影響流程，重新做 Gap 與一致性檢查，確認修改沒有造成新的遺漏或衝突。
- 以實際產出物的前後對照，說明已確認、已修改與待驗證的差別，讓接手的 PM、RD 與 AI 知道下一步要處理什麼。
08Workshop 與課程回顧：完成一輪跨功能的規格檢查、澄清與修正
- 以同一組相關功能規格與一則新增需求，動手盤點影響範圍，執行 Gap 與一致性分析。
- 逐項指出問題的原文依據、觸發情境與影響，檢視 AI 的分析是否成立，再提出需要確認的問題。
- 依課堂案例的角色與決策權責進行討論，將確認結果更新到規格與 Plan，重查相關情境；未決內容保留未決，不由 AI 自行選答案。
- 分享修改前後的規格，說明發現了什麼問題、為什麼這樣決定、改了哪些內容，以及還有哪些部分需要後續確認。