我如何在公司成功導入 SDD：在既有專案落地 OpenSpec（從 1 到 100）

開場#

2026 上半年，我在公司把 SDD 從個人實驗推進到既有專案的團隊協作流程。最直接的結果是：中午做完技術分享，下午公司就拍板導入。

這篇文章整理的是我這次導入 SDD / OpenSpec 的完整經驗：我怎麼降低導入門檻、怎麼讓主管和工程師各自看到價值、在既有專案裡踩過哪些坑，以及為什麼我認為 SDD 會成為 AI coding 團隊協作的重要基礎。

這篇內容原本來自公司內部技術分享，整理成部落格後，我會把重點放在導入脈絡、實務做法，以及哪些因素讓它真的推得動。

上次分享《2025 AI Coding 回顧及免費資源分享》回顧了我整年的 AI Coding 經驗，也稍微提到 SDD——那時提到我用 Amazon Kiro 導入新專案的 SDD 文件（從 0 到 1）體驗很不錯。

這次則是另一個階段：我把 SDD 從自己的 side project、新專案，推進到既有專案，讓它成為團隊可以協作、主管可以理解、AI agent 也能跟著執行的流程。

背景：我怎麼一路走到導入 SDD#

我在2023年就開始導入AI到我的工作流程中。ChatGPT 剛出來我就開始用；2024 整年基本上是「開著 web 一問一答、自己複製貼上」的階段；2025 年初換成 Cursor 這類 AI IDE 做 AI coding；到了 2025 下半年，再進化到 Claude Code 這種 AI CLI 的形式。

這些使用經驗，我在年初就在公司內部分享過一輪（也就是上面那篇《2025 AI Coding 回顧及免費資源分享》）。那次分享其實很關鍵：它讓公司知道我在做什麼、我的認知邊界在哪裡，也讓不少同事因此開始用 AI coding。換句話說，等我這次要推 SDD 時，公司對「這個人很有 AI coding 實戰經驗」這件事已經有共識。

比較難的地方：公司還沒有正式投入 AI token#

老實說有個現實的坎：公司當時還沒有正式發給員工 AI token。我用的這些工具，全程都是自己付錢，或自己去找免費資源撐著。

但我很清楚這是個趨勢、是「做對的事情」。所以在公司還沒有正式資源投入之前，我選擇先自己把 AI coding 的實戰經驗跑出來，累積到足以判斷哪些東西只是玩具、哪些東西真的能放進工作流程。也正是在大量使用 AI coding 的過程中，我才認識了 SDD，才有後面這整套導入。

為什麼這次導入會成功#

先講結論：這次導入當天就進到專案 V 的實際開發流程，沒有停在一句「聽起來不錯」。

具體來說，當天下午專案 V 的負責人就指示前端也要針對同一個 IAP feature 補上 OpenSpec 的 SDD 文件。也就是說，這套流程當天就從後端擴到前端，變成前後端協作時共同使用的工作方式。

當時我們也討論到一個很實際的問題：文件會不會衝突？後來的結論是，以「實際負責人」為單位拆分 SDD。像 IAP 這種 feature，協作模式通常是前端一位、後端一位，不會有多人同時改同一份後端 spec 或前端 spec 的情境。所以後端由我維護後端 SDD，前端由前端同事維護前端 SDD，前後端文件拆開，反而更符合團隊實際工作方式。

回頭看，我覺得有幾個原因讓它這麼順：

1. 我把門檻壓低，貼合實務#

SDD 是好事，但如果一上來就要大家認真產出 OpenSpec 框架下的一堆文件，很容易把人淹沒、還沒開始就先放棄。

所以我把重心擺在一個地方：先用 AI agent 的 plan mode 把 plan.md（規劃文件）寫好，再由這一份去展開成 OpenSpec 的四份 SDD 文件就好。大家只要顧好一份東西，不用同時面對四份文件的壓力。其實plan.md本身也是SDD，後面會提到。

2. 有了 AI coding，寫 SDD 文件這件事變便宜了#

以前「寫文件」的心理障礙跟時間成本都很高，所以大家寧可不寫。現在文件交給 AI 產，成本大幅下降，導入 SDD 的阻力自然小很多。

3. 管理層各自找到他們要的東西#

分享之後，不同層級的主管在同一套 SDD 框架裡，各自看到吸引他們的價值：

技術主管看上 tasks.md（任務清單）：對他來說，這是一份能即時掌握工程師工作進度的東西——哪幾項做完、哪幾項在做、哪幾項還沒開始，一目了然。
管理高層看上 proposal.md（提案文件）：管理層／企劃的想法要傳達到工程端實作時，工程師可以先回一份提案文件，主管很快瞄一眼這份高層次文件，就能確認「方向跟我想的一不一樣」，不一樣的話可以馬上調整，不用等到做完才發現歪掉。

同一套框架，技術端跟管理端都各自有獲得，自然就推得動。

4. 漸進式導入，不必先補完整份規格#

很多人一聽到「既有專案導入 SDD」就卻步：難道要先花一個月把整個系統的規格倒著補一次？不用。從當下正在改的那一小塊開始累積就好。

5. 我是一路實作上來才導入的#

我的導入是階段化推進的：先在 side project 練手，再到我自己主導的新後台完整跑一輪，最後才到與團隊協作的既有專案後端。每一層都有實作經驗才往上推一階——這也讓同事相信，我會先驗證，再往團隊推，不會看到新東西就急著導。

為什麼需要 SDD#

2026 上半年都快過完了，AI Coding 模型一個比一個強。有人會覺得：現在 AI 都這麼厲害了，plan 規劃完直接執行就好，東西也做得出來、也不會壞——還需要 SDD 嗎？

我自己用下來覺得，SDD 仍然非常有它的價值。三個原因：

1. 程式碼即文件的做法可以更好#

以前工程師懶得寫文件，最後變成「程式碼就是文件」。後面接手的人很難知道當初為什麼這樣設計、為什麼選 A 不選 B。

現在有 AI agent，導入 SDD 讓專案開始有文件——給自己、給未來的自己、給同事看、給AI agent看。而且寫文件這件事的心理障礙跟時間成本，因為交給 AI 去寫，降低非常多。

2. 規範 AI 的行為#

AI 模型再強，還是會跟你的想法不對齊。

SDD 就是在規範 AI 的行為，確保它做出來的東西跟你的想法對齊。OpenSpec 的 config.yaml 還可以把專案 convention 寫進去（命名、檔案結構、提案規則），AI 每次產文件、寫程式都會吃這份 context，就不會亂跑。

3. 任務清單對我最有用#

tasks.md 規劃好任務步驟為一個一個 checklist讓你後續可追蹤。

舉例常見場景：

1. 斷點續做#

撞到 5hr limit？沒關係。等限額重置後叫 AI「看一下 openspec/changes/xxx/tasks.md，從未勾選的那一項繼續」，它直接接著做。

2. 跨人換手#

我請假但 feature 要趕上線？同事打開 tasks.md，看哪幾項 [x]、哪幾項 [ ]、哪幾項 [~]（部分完成），直接接手。

3. 等外部依賴（專案 V 實際案例）#

專案 V 的 IAP 要把後端的假驗證（stub）換成真驗證。前端 Unity client 會透過 submitPurchaseReceipt 這支 API 把購買 receipt 送給後端——但 Unity IAP 5.x 會把 receipt 層層包裝，後端得先拿到真實樣本、確認包裝後的結構，才知道怎麼拆來驗。

真正卡住的地方是這個 feature 是前後端一起進行的：前端那邊 receipt 怎麼帶，當時都還在開發、調整中。我要拿到真實的 iOS 參數結構，就得等前端這段告一段落、再打一版 iOS build 跑 TestFlight Sandbox 把樣本撈出來——這條線的進度，我這邊無法單方面決定。

但 Android 的樣本先到、結構先確認了（3 層嵌套 JSON）。所以我用 tasks.md 把任務切成兩段：Phase A（Android，結構已確認 → 立刻開工） 與 Phase B（iOS，gated on 真機樣本），等外部 input 的卡點項目用 [~] 加備註明確標出來。前端在處理他那邊的同時，我可以先把整個 Android 驗證做完，進度不會被卡死——而且這個卡點是「被追蹤的」。

SDD 的四份文件：proposal / design / spec / tasks#

這邊就簡單介紹SDD內的文件，以OpenSpec為例。

先看一張對照表：

文件	角色	回答的問題	何時改動
`proposal.md`	變更提案	為什麼要改？影響範圍？Non-goals 是什麼？	提案階段（每個新 change）
`design.md`	技術設計	怎麼改？資料流？依賴？回滾策略？	提案被接受、進入實作前
`spec.md`	規格（真相來源）	系統目前該長什麼樣？	archive 時自動合併
`tasks.md`	任務清單	具體要做哪些事？進度到哪？	實作中持續勾選

白話一點展開：

proposal.md 像是寫給主管的提案信：講清楚「為什麼這件事值得做」「會動到哪些檔案 / repo」「明確不做什麼（Non-goals）」。
design.md 像是工程文件：DB schema 要不要動？第三方 SDK 怎麼接？萬一上線壞掉怎麼 rollback？
spec.md 是唯一的真相來源——它描述「系統現在實際運作的樣子」。每次變更 archive 後，這份規格會被自動更新。
tasks.md 是 markdown checkbox 清單，每一項都是可勾選的小任務，進度一目了然。

想看更詳細的 requirements / design / tasks 三段論定義（EARS 格式、user story 寫法、acceptance criteria），推薦讀高見龍那篇《SDD 規格驅動開發》，講得非常完整。

為什麼選 OpenSpec：Brownfield-first 的設計哲學#

上次分享的 Kiro 我覺得很適合新專案。它的工作流偏向 Greenfield：先寫 requirements，再 design，再 tasks，三段論走完開始做。

但既有專案不一樣。高見龍在《OpenSpec 讓 SDD 變簡單的三個指令》裡這段講得很到位：

既有系統通常有很多隱藏或是前人留下來的「資產」，這些東西不一定寫在文件裡，可能只存在於某個資深工程師的腦袋中，或是散落在各種 commit message 和 PR 討論裡。如果我們直接跟 AI 說「幫我加一個新功能」，AI 不知道這些脈絡，很容易改壞其他地方。改壞了直接噴個 HTTP 500 還算好處理，最怕的是改了之後看起來能動，但其實破壞了某個我們沒注意到的隱性規則。

舉例來說，我最近在另一個後端服務專案處理 LogServer 改成去 BigQuery 拿資料時，就很有這種感覺。裡面有一堆 config 環境，像 config_platformA_ob、config_platformA_qc、config_platformA_rev，還有 config_docker_dev、config_jp。光看名字，其實很難判斷哪些是這次要改的，哪些根本不在這次工作的範圍內。

像 config_docker_dev，我一開始完全看不出來是什麼環境，後來問了同事才知道那是技術長在測 Docker 用的，我這次不用管。config_jp 也是，名字看起來像同一組設定，但實際上是在另一條跟 JP 有關的遠端分支處理，也不在我這次工作範圍內。這些資訊單看程式碼很難知道，往往只存在熟悉專案的人腦中，所以我覺得這類脈絡特別適合補進文件，讓後面接手的人或 AI agent 比較不會踩錯。

這就是為什麼 OpenSpec 把 specs/ 拉出來當「真相的來源」，再搭配 config.yaml 當專案說明書——讓原本只在某些人腦袋裡的脈絡，被固化成 AI 跟新人都讀得到的文件。

而 brownfield 還有另一個痛點：主規格已經夠複雜，每次想動一塊都怕碰壞別的。OpenSpec 的解法，是把 specs/（真相）和 changes/（提案）分開管理——目錄結構長這樣（以專案 V 為例）：

1
openspec/
2
├── config.yaml              # 專案級慣例 / convention
3
├── specs/                   # 真相的來源（系統目前實際運作的規格）
4
│   └── iap-validation/
5
│       └── spec.md
6
└── changes/
7
    ├── <ongoing-change>/    # 進行中的變更（獨立工作區）
8
    │   ├── proposal.md
9
    │   ├── design.md
10
    │   ├── tasks.md
11
    │   └── specs/           # Delta Specs（差異規格）
12
    └── archive/             # 已完成的歷史變更
13
        └── 2026-05-07-xxx/

關鍵點是「真相的來源」與「變更提案」分開管理：

specs/ 永遠只放一份最新的主規格
changes/<name>/ 是獨立工作區，你在這裡寫提案、設計、任務，不會污染主規格
變更採用 Delta Specs：你不需要重寫整份 spec，只要標記要做什麼操作——ADDED（新增段落）、MODIFIED（修改段落）、REMOVED（刪除段落）
archive 時自動把 delta 合併回 specs/，並把整個 change 資料夾搬到 changes/archive/ 保存歷史

OpenSpec 還有幾個 Kiro 沒有的優點：

工具無關：支援 Claude Code、Codex、Cursor 等 20+ AI agent，不像 Kiro 綁在自己的 IDE 裡
輕量：一個 npm package，openspec init 一次搞定，不需要切換到特定編輯器
彈性：相比 GitHub Spec Kit 強制走「規格 → 計畫 → 任務 → 實作」剛性階段門檻，OpenSpec 沒有強制流程，你可以跳著用，舉例來說，實作到一半想要改規格也沒問題，就在跳回去前面的步驟修改文件後再繼續實作。

archive 階段做了什麼：Delta Spec 合併機制#

每次 /opsx:archive 執行時，OpenSpec 做兩件事：

1. 覆蓋與更新#

把 change 資料夾裡的 Delta Specs（差異規格），按 ADDED / MODIFIED / REMOVED 規則精準合併進主規格目錄 openspec/specs/<spec-name>/spec.md。

舉例：以專案 V 的 IAP 為例，未來如果要加 Apple App Store Server Notifications V2 的支援（webhook 退款通知），會新建一個 change：

1
openspec/changes/2026-08-add-apple-server-notifications/
2
├── proposal.md          # 為什麼加 webhook
3
├── design.md            # webhook 流程、簽章驗證
4
├── tasks.md             # 實作任務清單
5
└── specs/
6
    └── iap-validation/
7
        └── spec.md      # delta：ADDED 一個新 Requirement 段

archive 後，主規格 openspec/specs/iap-validation/spec.md 會被自動新增該段落，主規格永遠保持最新。

2. 保留歷史軌跡#

把這次完成的 openspec/changes/2026-08-add-apple-server-notifications/ 資料夾，整包搬移到 openspec/changes/archive/ 底下保存。

總結：主規格只有一份，每次變更像 patch。歸檔後主資料夾保持最新狀態，所有的修改過程與決策紀錄則妥善保存在 archive 區塊。未來要追決策原因，去 archive 翻提案就找得到。

為什麼 openspec 放在 monorepo 根目錄#

專案 V 是 monorepo，根目錄底下有：

1
project-v/
2
├── GameClient/       # Unity 遊戲客戶端
3
├── GameServer/       # 遊戲伺服器（Node.js + 內部框架 + MongoDB + Redis）
4
├── AdminServer/      # 後台管理
5
├── LogServer/        # 日誌伺服器
6
├── ManageServer/     # 管理介面
7
├── web/、jenkins/、docs/ ...
8
└── openspec/         # ← 放這裡

很多人第一個直覺會是：「應該每個子專案（GameServer / AdminServer / LogServer）各自放一份 openspec 啊？」

我選擇放在 monorepo 根目錄，主要理由：

1. AI agent 在根目錄 context 最完整（最主要原因）#

AI 時代我希望 agent 能「看到全局」。在根目錄底下，agent 可以直接 grep / read 任何子服務的真實程式碼——前端 Unity 怎麼包 receipt、後端怎麼拆、後台怎麼查、Log 怎麼記。Spec 跟著放在根目錄，AI 才能在寫 spec 時參照到真正的程式行為。

如果每個子 repo 各自一份 openspec，AI 寫 GameServer 的 IAP spec 時，看不到 GameClient 的 receipt 包法、也看不到 LogServer 的紀錄分類，最後產出的 spec 就是片面的。

Monorepo 在 AI 時代有天然優勢，spec 也要跟著放在根目錄才能配合。

2. 跨 repo 的 feature 通常不只一個 repo#

IAP 驗證牽動 GameServer（後端驗證 + Consume）、GameClient（Unity 前端送 receipt 格式）。如果 spec 各 repo 一份，這種 feature 寫起來會被切碎。

3. config.yaml 是跨 repo 的專案級約定#

config.yaml 是 OpenSpec 裡比較高層次的一份檔案——它寫的是專案級的約定：每個 repo 的技術選型、專案規範、團隊 convention。AI 在規劃每一個新 change 時都會預先載入它，等於是它動手前一定會先讀過的「專案說明書」。

我現在的 config.yaml 其實只描述 GameServer——這反映的是我的導入範圍：我是後端工程師，目前只在 GameServer 這個子 repo 導入 OpenSpec。重點是它「長得出來」，未來要擴大到 AdminServer、GameClient，只要把那些 repo 的選型與 convention 補進同一份 config.yaml 就好。

換句話說，這份檔案天生就是跨 repo、描述整個專案的，不屬於任何單一子 repo。一份「描述整個專案」的約定，只有放在 monorepo 根目錄才擺得對位置。

4. 歷史變更不分裂#

archive/ 集中一份。未來要追「某個跨服務決策當初為什麼這樣做」，一個地方就找得到，不用跨 repo 翻來翻去。

5. 工具務實面#

openspec init 一次、config.yaml 一份，不用每個子 repo 各維護一套。

來看專案 V 的 openspec/config.yaml context 段落（已去識別化的精簡版）：

1
schema: spec-driven
2

3
# Project context (shown to AI when creating artifacts)
4
context: |
5
  專案：專案 V —— 多 repo 手遊專案
6
  主要 repo（目前 spec 範圍先以此為主）：
7
    - GameServer/ 遊戲伺服器（Node.js + 內部框架 + Socket.io + MongoDB + Redis）
8
      入口：app.js；主要業務邏輯與多數對外 API 定義於 cloud/*.js
9
      cron 工作於 cronJobs/，共用設定於 param/，公用工具於 utilities/
10
      第三方平台 SDK 串接：cloud/sdk_*.js（多家遊戲發行／金流平台）
11
      部署：Docker
12
  其他 repo（暫不納入 spec 範圍，僅供參考）：
13
    - AdminServer/   後台管理（Node.js）
14
    - LogServer/     日誌伺服器（Node.js）
15
    - GameClient/    Unity 遊戲客戶端
16

17
  Tech stack（GameServer）：
18
    - Runtime: Node.js（CommonJS）
19
    - Framework: 內部框架（fork 自開源後端框架，掛載全域物件）
20
    - DB: MongoDB、Redis
21
    - Realtime: socket.io
22
    - Auth: JWT；Cron: cron；環境變數：dotenv
23

24
  程式慣例：
25
    - 多數遊戲 API 入口註冊於 cloud/*.js，少數 HTTP 型端點定義於 api/*.js
26
    - cloud/*.js 以單一功能域為單位，內含業務邏輯、對外入口與跨模組 exports
27
    - 跨模組共用邏輯集中於共用工具檔；DB 名稱、路徑、平台設定集中於 param/
28

29
# Per-artifact rules
30
rules:
31
  proposal:
32
    - 預設影響範圍僅限 GameServer；若需跨出到其他 repo，必須在提案中明確標註並說明理由
33
    - 需列出受影響的檔案路徑，並包含「Non-goals」段落
34
  design:
35
    - 需說明是否涉及 DB schema、param/ 設定、第三方 SDK、cronJobs、部署或跨 repo 影響
36
    - 涉及上述項目時，需說明相依關係、風險、回滾方式與驗證方式
37
  tasks:
38
    - 任務切分以單一 cloud/*.js 模組或單一 API 端點為單位
39
    - DB schema、param/ 設定變更、第三方 SDK 改動各自獨立為一個 task
40
  specs:
41
    - 規格以「模組」為單位撰寫（對應 cloud/*.js）
42
    - 描述 API 介面時須包含：呼叫路徑、輸入參數、回傳格式、錯誤碼

這份 config 在 AI agent 每次產 proposal / design / tasks 時都會被注入當 context，等於是專案級的 coding convention。

在寫 SDD 文件之前，我會先跑一輪 Plan Mode#

前面講的是 OpenSpec 本身的文件結構與設計，接下來補一個我自己實際使用時的前置步驟：先用自己慣用的 AI agent 的 plan mode 產出 plan.md。

四份 SDD 文件產出前，我會先餵給 AI agent 一份 plan.md，而我的 plan.md 是用 Claude Code 的 Plan Mode 產出來的。

Plan Mode 為什麼強#

進入 Plan Mode，Claude Code 會切換到「強制唯讀（Read-only）模式」——系統直接鎖死它修改檔案的權限，它只能做三件事：讀取檔案、搜尋專案、問你問題。

我覺得這個限制才是重點。因為不能馬上動手寫 code，它被迫把算力全部砸在「思考架構」上，不會急著生出一坨能跑的東西。

而且 Plan Mode 不走單一路線——它會派出多個 subagent 平行探索你的 codebase，從不同角度各自產生規劃，然後在決定方向之前反過來問你 clarifying questions。等於是有好幾個 agent 同時在看你的專案，再收斂成一份計畫。

不 plan 就直接動手，我踩過的狀況#

舉個我實際遇過的例子：如果不規劃就直接讓 AI 直接動手，它很可能自己幻想出一個新的 middleware、或多寫一個其實用不到的函式。但其實我只需要在 plan 裡寫一句「這裡用哪個現成的共用函式」，就能擋掉這種「AI 自行發明、製造垃圾」的狀況。

我自己的感受是：在 Plan Mode 階段把雜訊清掉，遠比讓 AI 直接開幹、做歪了再回頭修省時間。 而且——Review Code 很痛苦，Review Plan 相對輕鬆太多了。

對我來說，`plan.md` 本質上就是 SDD#

跑下來我的體會是：用 Plan Mode 寫出來的 plan.md，本質上就是一份 SDD。

所以我實際上只雕琢 plan.md 這一份，反覆改到自己滿意，再拿它當作 SDD 文件的 source——後面 proposal / design / spec / tasks 四份，我都交給 AI 從 plan.md 去延伸生成。

這樣我就不會為了「要寫四份 SDD 文件」看到頭昏眼花，心力集中在一個地方就好。

我的工作流#

這只是大概流程，大家可以依照自己習慣，或慣用的ai agent自行調整流程。

1
[1] Claude Code plan mode 產出 plan.md
2
       │
3
       ↓
4
[2] 開新 session Claude Code review plan
5
       │   ← 整理 review points，各個擊破
6
       │     (不要一次面對所有問題，會被淹沒)
7
       ↓
8
[3] /opsx:propose  → 產 proposal / design / specs / tasks
9
       │
10
       ↓
11
[4] Claude Code review proposal 有沒有照 plan
12
       │
13
       ↓
14
[5] /opsx:apply    → AI 依 tasks.md 逐項實作
15
       │
16
       ↓
17
[6] Claude Code review 實作
18
       │
19
       ↓
20
[7] Codex review 實作  (雙模型交叉檢查)
21
       │
22
       ↓
23
[8] /opsx:archive  → 合併 delta spec 回 specs/
24
                    change 整包移到 archive/

我的做法：

我會仔細看的，只有 `plan.md`#

SDD 一次產出四份文件看起來嚇人，但其實只要把 plan 雕琢好，後面 proposal / design / spec / tasks 直接用 AI 從 plan.md 推導出來。

所以工時應該集中在第一份 plan.md 上。

開新 session review#

每次要 review 的時候開新 session，不要在產 plan 的同一個 session 裡 review——同一個 AI 對自己剛寫的東西容易有 confirmation bias。

Review points 各個擊破#

review 跑出來常常有 5–10 個點，一次全部看完會被淹沒、也容易遺漏。先整理成 review point list，一個一個擊破，每個都明確下決策（採納 / 拒絕 / 改寫）。

雙模型交叉檢查#

Claude 跟 Codex 的訓練資料、思考模式都不同，會抓到不一樣的問題。重要的變更我會用兩個模型各 review 一次，誤判率會明顯下降。

漸進式導入：不需要一次把整個專案規格補齊#

導入既有專案時最大的心理障礙是：「難道我要先花一個月把整個系統的規格倒著補一次？」

不需要這樣做。 實務上，直接從當下正在做的新功能或變更開始建立 spec，邊做邊累積就好。這樣比較有經濟效益，也比較不容易做到一半就放棄。

重點是先把「現在正在改的那一小塊」寫準，不需要一開始就補完整個專案。等一個個 change 做下來，核心模組自然會慢慢累積出規格；而且這些規格都是「實作當下寫的」版本，通常也會比事後回補更準確。

我的導入路徑：階段化推進#

這次分享，主要是整理我從自己開始使用，到把 SDD 帶進團隊協作的導入路徑。我的做法是先讓它在一個明確範圍內跑起來，確認真的能降低溝通成本、讓 AI agent 更穩、也讓主管看得懂進度，再往外擴。

Side project（個人實驗）
先在沒壓力的環境熟悉基本指令與工作流，踩過幾次坑，確認這套方法自己用得順不順。
公司新後台（我負責的專案）
在自己負責、可控度比較高的專案上，先完整跑過一輪，確認SDD的流程是否真的可以落實。
專案 V 後端（既有專案導入）
再往既有專案推進時，我有先和專案 V 的負責人討論，從後端某個範圍明確、適合觀察成效的 feature 開始，例如 IAP 驗證。這樣的做法比較務實：一方面後端同事們本來就比較常在使用 AI agent，另一方面也能先累積一個貼近實戰的案例。
專案 V 前端（從單點導入擴到前後端協作）
技術分享當天下午，專案負責人就指示前端也針對 IAP 這個 feature 補上 OpenSpec 的 SDD 文件。我們沒有把前後端硬塞進同一份文件，最後採用以實際負責人為單位拆分的方式：後端由我維護後端 SDD，前端由前端同事維護前端 SDD。這樣既不會互相衝突，也符合實際協作方式。
後續 feature 延續導入
從 IAP 這個 feature 開始，後續的 feature 也延續這套做法導入 OpenSpec SDD。這對我來說才是真正的落地：分享完之後，它真的進到專案流程裡，成為後續開發會繼續使用的工作方式。

延伸資源#

OpenSpec 官方 workflows 文件：https://github.com/Fission-AI/OpenSpec/blob/main/docs/workflows.md
OpenSpec docs 全集：https://github.com/Fission-AI/OpenSpec/tree/main/docs
高見龍《SDD 規格驅動開發》：https://kaochenlong.com/sdd-spec-driven-development（requirements / design / tasks 三段論、EARS 格式介紹）

開場#