SDD 的侷限

過去我一直有習慣把不錯的文章存下來，可能是有趣的開源專案、別人的經驗談、或是有價值的新知，通常會存下來代表交代未來的自己要想辦法找時間來消化這些資訊。但實務上好像變成一種囤積症，久而久之這些存下來的文章越積越多根本不可能全部消化，有些之前存的資訊可能也都過時了。

所以我想要先從我最近重度使用的 Threads 上開始著手，自動化把那些儲存的文章變成一個 Obsidian 的資料庫，這樣就可以在上面建 RAG，有助於 AI 系統的迭代或是想法的實踐。

我有考慮過要用 SDD 來開發，但想說這個想法蠻免洗的，應該是幾個 script 就能解決的事情，可以省下一開始各種需求，因為沒什麼需求嘛，不就只是把這些文字給存下來而已嗎？

沒意外的話就要出意外了。首先光是 Threads 的 API 就不是很規律，有些畫面是直接用 SSR 的方式渲染，找不到 API，這時候 AI 就用 Playwright 來模擬瀏覽器操作。本身不太喜歡這個做法，因為是依據 HTML 的 id 或是 class 來找到指定的結構，這個一旦前端 UI 改變可能腳本就會壞，而且速度上絕對沒有比 API 還要快。除非再花時間找到對應的 API 不然只能先這麼做。

成功拿到資料後又發現資料不完整，有串文、圖片、影片、轉發、長文，這些都不是直接丟給 AI 就能支援的。如果單純一篇的文字隨便下個 prompt 都能輕鬆解決，但是要支援一堆格式在不做功課的情況下真的就只是一直浪費 token，更何況我已經開到最新的 Opus 4.6 了還是一樣需要來回好幾次溝通才能幫我把功能做到位。

回頭檢視這一切，發現其實重視品質的情況下，其實不存在不用事先規劃無腦洗頭這件事，一開始都會過度輕視一項任務，到後面反而會被細節追著打。就這個專案而言其實 SDD 能幫的事情不多，因為最大的難點在於找到平台的資料取得方式，這個研究如果不是有經驗的工程師介入，AI 容易一直鬼打牆，如果不是我給他提示他會一直卡在登入頁面。工程師在某些領域被稱為 RD，目前看起來 Development 可以套用 SDD，但 Research 的部分目前還沒那麼強大。

其實有一點讓我很訝異，因為前不久在研究自動發文沒有這次這麼痛苦，看來是一開始擲骰子走到難度比較高的一條路。上次 AI 是用 puppeteer，這次是 Playwright，Playwright 明顯比較卡，不知道是套件本身差異還是機率問題，總之這兩次都是我人工介入提供相關資訊才疏通。這些任務也是不太可能直接丟給龍蝦就能解決的，看來工程師又多出幾集可以逃了。