前一篇最後提到，需求到了工程師手上以前，PM／SA 往往已經討論過，也整理成工單或 Word 文件。那麼，當工程師開始使用 SDD，這些內容是怎麼帶進來的？
這篇就以我們團隊的經驗來說。我們先在工程師端使用 Spectra，後來也讓 PM／SA 開始使用內部 AI Agent。查資料、討論與建立文件都方便了不少，但工程師接手後，還是得再整理一套 SDD 規格。
最初是 PM 建立工單，SA 依照需求撰寫 Word 規格，工程師再拿著工單與對應的 Word 開始修改 code。工單記錄要做什麼，Word 則用來說明功能的細節：
以我們當時的情況來說，先從工程師端導入比較容易開始。工程師原本就在管理 repo、操作 Git，可以直接使用 Spectra；PM／SA 則繼續透過工單與 Word 整理需求。要讓他們自己操作 SDD，還需要另外安排工具與使用方式。
工程師拿到需求後，如果還有不清楚的地方，就先透過 discuss 和 AI 討論，再回頭向 PM／SA 確認。等方向談妥後，才由 propose 建立 proposal、specs、design 與 tasks，接著實作。所以，PM／SA 雖然沒有直接操作 Spectra，仍然會參與需求的討論與確認。
這樣讓工程師端有了一套可以確認與驗證的流程，但同一個需求也分散在三個地方：工單、Word，以及工程師端的 SDD artifacts。需求後來改了，到底該更新哪一份？另外兩份又由誰一起改？
討論或實作時，難免會發現原本沒想到的情況，需要補充需求或調整作法。工程師也可能提出不同方案，或想順便整理附近的 code。不過，討論後確認要改的內容，不一定都有同步更新到工單與 Word，有時只留在工程師端的 artifacts。等到測試或重新比對需求時，才發現大家手上的內容已經不一樣了。
後來，團隊自行開發了一套內部 AI Agent，讓 PM／SA 開始使用。這套應用使用 Pi Agent，PM／SA 開啟系統就能詢問，不必進入 repo、操作 Git，或先準備開發環境。
它先幫忙處理的，是查詢現有規格與系統邏輯。以前 PM／SA 想確認某項功能怎麼運作，得先找規格書與相關段落。文件沒寫清楚，或內容已經落後於 code，就要再請工程師找出相關程式、確認實際行為，再把結果回覆回去。
接入 AI Agent 後，PM／SA 可以直接提出問題，讓 AI 查找規格，必要時再讀 code 確認。雖然還在實驗，少掉人工翻文件、找程式與來回轉述的過程後，確實省下了不少時間，大家的反應也都不錯。
查詢變得比較方便後，團隊也開始讓 AI Agent 連接工單系統，並在內部應用裡加入保存規格的功能。這時產生的規格直接存在系統裡，不再另外寫成 Word。
客戶提出需求後，PM／SA 可以先和 AI 討論。AI 會參考已有的規格與 code，協助確認這個需求在現有系統上是否可行，還有哪些問題需要問清楚。等方向談到差不多，再請 AI 建立工單與對應的規格文件。工程師拿到工單後，也回到這套系統查看規格：
目前有些需求仍然透過工單與 Word 交接，有些已經開始由 PM／SA 先和 AI 討論，還沒有全部改成同一種作法。工程師端則仍然使用 Spectra。
也就是說，工程師讀完內部系統的規格後，還是得把內容帶進 Spectra，建立另一套 proposal、specs、design 與 tasks。原本是 Word 和 SDD artifacts 分開，現在換成系統內的規格和 SDD artifacts 分開。規格換了保存位置，重複整理的問題還在。
既然如此，我想調整的就不只是 Word。工單可以繼續用來追蹤工作，但 PM／SA 與工程師能不能不用再各自整理一套規格？
我希望 PM／SA 可以留在熟悉的內部 AI Agent 裡討論需求、建立規格與查看 tasks。工程師回到自己的電腦後，則用 Claude Code、Codex 等工具，接著這份 SDD 規格實作與檢查，不必重新產生另一套內容。下面是我希望做到的方向，還不是團隊已經完成的流程：
例如，PM／SA 討論後調整了需求，工程師應該能看到更新後的內容；工程師完成 tasks，或發現還需要確認的問題，PM／SA 也能從內部系統看到進度與問題。雙方不必使用同一套工具，但前面已經談好的內容，要能繼續用下去。
這也是我開始開發 Speclink 時，就想嘗試的另一個方向：PM／SA 留在內部 AI Agent 裡討論需求，工程師繼續使用熟悉的開發工具，但不用各自維護一套規格。目前這條流程還在實驗，還沒有完整接進團隊的日常工作。
真正要做到這件事，接著就得處理：規格放在哪裡？不同工具要怎麼讀取與更新，才能接著前面確認過的內容往下做？
接下來，就來看看我目前做了哪些嘗試吧！
iThome鐵人賽
看影片追技術
看更多
