前一篇整理好 AI 寫規格時需要的背景與要求。不過，專案裡那些早就寫好、一直在運作的功能，可能還沒有對應的正式 specs。
新功能可以隨著 changes 一份份補上規格，但如果想先把既有功能整理出來，讓後面的討論與規劃有資料可以查呢？這就是我在 Speclink 加入 Baseline 想處理的問題。
專案目前沒有正式 specs，還是可以直接挑眼前要做的需求進入 discuss 或 propose。等 change 完成並 archive，對應的規格就會一份份累積。OpenSpec 對既有專案也採用相同的方向：不用先替整個 codebase 補完文件，可以從下一項要修改的功能開始。
只是，還沒有被後續 changes 碰到的功能，暫時不會出現在正式 specs。如果我希望 AI 在討論與規劃時，可以先查規格，了解目前有哪些功能，就能主動使用 Baseline，先整理這些既有行為。它是需要時才使用的工具，不是導入 Speclink 前一定要做的準備。
我給 Baseline 的要求，是先記下能從 code 與 tests 確認的行為。盤點時即使發現 Bug、缺少的功能，或想順便重構的地方，也要另外討論，不能直接把預期中的結果寫成系統現況。
因此，Baseline 本身不修改 code，也不建立 change，而是把確認過的現況直接寫進 openspec/specs/。之後想修正或增加功能，再透過 discuss 或 propose 開始一份 change。
不過，在寫規格以前，得先確認這次要看哪些功能，以及有哪些資料可以幫我們確認它們實際怎麼運作。
Baseline 會先查看目前有哪些正式 specs。還沒有 specs 時，就從這次指定的範圍開始；沒有指定，才以整個 codebase 為範圍。如果已經有部分 specs，就只補還沒涵蓋的地方，不會直接改寫原本的規格。既有規格需要調整時，仍然另外建立 change，留下修改的原因與內容。
接著，Baseline 會取得 config.yaml 裡的專案背景、規格語言與 rules.specs，也就是寫 specs 時需要遵守的要求。讀取設定出錯就先停止，不會跳過這些要求繼續寫。這不表示每次都得先跑 Config Skill；現有設定已經夠用，就可以直接開始。
有了範圍與背景後，AI 才查看 README、專案設定檔、程式目錄與 tests。先從文件了解專案用途，再沿著指令、網頁或服務的入口查看程式，確認功能實際怎麼運作；tests 則能提供具體的條件與預期結果。
專案很大時，不需要一次讀完所有檔案，可以先從相關入口與 tests 開始查。查到的內容也要分清楚：哪些已經能從 code 或 tests 確認，哪些還只是推測。沒有把握的地方，就停下來問我，或暫時不寫，不能為了讓規格看起來完整就自己補答案。
確認過的行為整理出來後，下一步才是決定：它們要分成哪些 capabilities？
AI 會先提出一份 capability 清單，也就是 Skill 裡的 capability map。每一項都要列出名稱、負責的範圍，以及參考了哪些 code 或 tests，還不能直接建立規格檔案。
因為後續 changes 會沿用這些名稱與範圍，我希望先確認這樣分合不合理。拆得太細，以後一個需求可能得同時修改很多份 specs；全部塞在一起，又會很難看出這份規格到底負責什麼。
所以，AI 列出清單後，會先停下來讓我決定哪些要合併、拆開、改名或拿掉。同時也會列出這次套用的 rules.specs，讓我知道它準備按照哪些要求來寫。
清單確認後，Baseline 才會為每個 capability 建立正式規格：
openspec/specs/<capability>/spec.md
每一條 requirement 都要有實際讀過的 code 或 tests 作為依據；scenario 則盡量使用 tests 裡已有的條件與結果。規格要寫的是功能怎麼運作，而不是程式放在哪個模組、用了哪個函式。否則只是移動檔案或重構，功能明明沒變，規格卻得跟著改。
寫完後，Baseline 會執行 strict validation，檢查規格格式與必要內容。格式檢查通過，只代表工具讀得懂這份規格，不代表 AI 一定把功能理解對了；rules.specs 裡的要求有沒有做到，也得另外核對內容。
最後，AI 會整理這次建立了哪些 capabilities、哪些行為還無法確認、哪些範圍先留到以後，以及實際套用了哪些規格要求。從盤點到寫入，整個過程如下：
這些步驟能幫我整理目前查得到的行為，但 code 與 tests 本身也可能有 Bug，或和原本想要的功能不同。Baseline 留下的是目前的狀況；哪些地方需要改，還是要另外討論。
Baseline 補好既有功能的規格後，後續要修改功能，仍然回到前面介紹的 change 流程。把它和其他功能放在一起，就比較容易看出各自會在什麼時候用到：
把這些功能放在一起看，平常有需求要做，還是沿著 discuss、propose、apply 到 archive 往下走；Config、Baseline 與 improve，則是在需要整理規則、補上既有規格，或回頭檢查程式結構時才使用，不需要每次全部跑過一遍。
從【Day - 13】開始介紹 Speclink，到這裡，總算把我在專案裡怎麼和 AI 討論、規劃、實作與留下紀錄說完了。不過，這幾篇主要談的，都是需求已經到了我手上以後的事。
在我們團隊裡，需求交到工程師以前，PM／SA 就已經討論過，也整理成工單或 Word 文件。等我開始和 AI 討論時，要怎麼把這些內容一起帶進來，才不必再交代一次？後來需求改了，兩邊留下的規格又要怎麼對得上？
接下來，就來聊聊我們團隊在這段交接上遇到的問題吧！
iThome鐵人賽
看影片追技術
看更多