引言#
生成式 AI 是這幾年來技術圈最火的話題之一，從它剛出現到現在，不過短短幾年，技術變革的速度卻快得讓人喘不過氣。每隔一兩周就有新工具、新功能冒出來，甚至有些東西還沒學會就已經被淘汰了。在這樣的環境下，AI 對我的工作流程帶來了哪些衝擊？我又是怎麼應對的？這篇文章就來聊聊我的一些實際經驗。
備註：用了
AI之後越來越懶了，這篇也是由AI協助校稿支援
從 Prompt 到 Skill 的變化#
想當初剛出現 AI 這種東西的時候，我們首先接觸到的是網頁式的聊天工具，它能夠扮演一個什麼都懂的導師，往往有什麼問題都可以從他那邊得到一些啟發或想法。雖然還是常常有錯誤，但只要有正確的觀念，還是能夠從中獲益不少。
接著，AI 的技術逐漸進入 IDE，開始與開發工具整合。這時候，AI 不再只是回答問題，而是能夠幫助你完成程式碼的撰寫，甚至主動建議修改。隨著技術的進步，「Agent」這個名詞開始出現，AI 不僅能協助你，還能主動在 IDE 裡修改檔案，讓開發者的工作效率大幅提升。
再來，PLAN 模式的出現更進一步改變了遊戲規則。AI 不僅能執行指令，還能遵循規格或事先講好的計畫去完成任務，這讓開發者能更放心地將部分工作交給 AI。然而，這些技術仍然侷限在 IDE 的範疇內。
在這個階段，SDD（Specification-Driven Development）的概念也開始慢慢浮現。早期大家接觸到的，不一定是很完整、很標準化的 SDD 工具，而是一些開始強調規格、流程、Agent 協作的產品。像 Manus 這類網頁型 AI agent 產品，讓很多人第一次感受到「AI 不只是回答問題，而是真的可以幫你執行事情」；而 Kiro 則更明確地把 spec-driven development 這種想法帶進開發環境裡。嚴格來說，它們不完全是同一種類型的工具，但都在推動大家從單次 prompt，慢慢走向更有結構的工作方式。
真正讓我感覺更多人開始實際嘗試 SDD，是在 CLI 工具慢慢成熟之後。像 OpenSpec 和 Spec Kit 這類工具，把 spec-driven development 這件事講得更完整，也更容易落地。若看公開時間，OpenSpec 其實還比 Spec Kit 更早一些，所以與其說是哪一個單獨率先引領風潮，不如說它們是在差不多的時間點，一起把這股風潮推了起來。對我自己來說，Spec Kit 的概念很完整，但也相對比較重；後來 OpenSpec 這種短小精悍的方式，反而更符合我的使用習慣。
值得注意的是，SDD 的概念與現有的 TDD（Test-Driven Development）和 BDD（Behavior-Driven Development）有相似之處，但更強調規格的完整性與可操作性。這些工具的出現，讓開發者開始重新思考如何以規格為核心來驅動開發流程。
Spectra也是我自己覺得方便好用的工具之一。REF(https://kaochenlong.com/spectra-with-openspec)
也是在這樣的開發流程裡，我越來越明顯感受到，測試這件事的重要性不只沒有下降，反而變得更重要了。
只是這個「重要」已經不太像以前那樣，重點放在你要怎麼背語法、怎麼寫很多細節，而是你真的得開始理解測試到底在驗證什麼。
像 BDD 裡面常講的 Given、When、Then，其實就是一種很好的思考方式。你要先想清楚前提是什麼、觸發了什麼行為、最後預期得到什麼結果。E2E 也是一樣，重點不是工具本身，而是你有沒有真的站在使用者流程的角度去確認整個系統是不是正常運作。
這些事情最後指向的其實都是同一件事，就是軟體品質。AI 介入之後，開發人員某種程度上可以從很多實作細節裡被解放出來，把更多精力放在產品本身，去思考功能、流程、風險，還有品質到底要怎麼被驗證。而 AI 如何協作測試這一塊，我自己認為又是另一門很深的學問。
也就在大家開始思考，AI 不只是幫你寫幾段程式，而是要怎麼更完整地接進整個開發流程時，MCP（Model Context Protocol）出現了。
MCP 一出來，業界可以說是為之瘋狂，甚至一度讓不少人相信這就是解決所有問題的唯一方案。它的出現讓 AI 的應用範圍大幅擴展，也讓更多人開始認真思考，AI 到底要怎麼和工具、資料來源、工作流程做更深的整合。
隨後，CLI 工具的崛起再次改變了局勢。人們開始發現，有些開發工作其實不一定要綁在 IDE 裡，很多事情直接在終端機裡反而更快、更直接。也因為這樣，CLI 不再只是輔助工具，而是慢慢變成很多人日常工作流裡的核心部分。這時候，更多的工具與應用開始湧現，AI 的角色也變得更加多元。
最後，Claude Code 這類工具的 skills、hooks、instructions 也開始嶄露頭角。對我來說，這代表的不是又多了一個新名詞，而是 AI 工具開始更進一步貼近真實工作流。你不只是跟它聊天，也不只是叫它改幾行程式，而是可以慢慢把團隊習慣、開發規則，甚至常做的事情，整理成它能理解並持續遵循的形式。
也很有意思的是，當 skills 這類做法開始越來越成熟、越來越實用之後，MCP 的聲量反而不像前一陣子那麼高了。不是說 MCP 不重要了，而是大家慢慢發現，真正決定工具好不好用的，不只是能不能接多少外部系統，而是它能不能真的融入你的日常工作流，幫你把事情做完。
從網頁聊天到 IDE 整合，再到 MCP、CLI 與這些更進階的工作流能力出現，AI 技術的每一次進步都在改變我們的工作方式，而這一切到現在都還在持續。
AI 第一次真正進入我的工作現場#
如果要講我自己實際怎麼用 AI，我覺得最有感的一段，應該是我當時負責建立公司一個內部應用網站的時候。
那時候 INFRA 端提供給我的，基本上只有機器和軟體，剩下很多事情都要我自己決定。我要自己想清楚每一台機器要做什麼、哪些服務要放在哪裡、整體要怎麼拆才合理。像是 nginx、haproxy、網站應用本身的容器化、自動更版、手動更版機制、排程設定、SignalR 跟網站怎麼串、Redis backplane 要怎麼放，甚至還有 filebeat、ELK、Grafana、Prometheus 這些觀測和監控相關的東西，全部都要一個一個拼起來。
老實說，那時候我一開始想的不是什麼很大的理論，而是很單純地在想，到底要怎麼讓 AI 幫我協作。因為這些東西牽涉的面向很多，從反向代理、負載平衡、部署策略，到即時通訊、日誌收集、監控告警，每一塊你都可以自己研究很久。但有了 AI 之後，我可以先從網頁版一問一答開始，把問題一個一個拆開，把我當下卡住的地方先問出一個方向，再回來慢慢組合成真正能落地的方案。
所以我很多基礎設計，其實就是這樣慢慢建構出來的。不是 AI 一次把答案全部吐給我，而是它陪我把很多原本零散的資訊逐漸收斂，讓我比較快看見有哪些選項、各自的風險是什麼、不同元件之間可能怎麼串。
而且在那個階段，還有一個對我來說非常實際的使用場景，就是我得在自己其實沒有那麼熟的 Linux 主機上做很多自動化。那時候我很大程度依賴的，其實就是網頁版聊天工具。我會直接跟它說我的需求，描述我現在的環境、我想完成的事情，然後讓它幫我產出 shell script，或至少先給我一個可以開始修改的版本。
現在回頭看，至少在我當時接觸到的使用場景裡，那仍然是很明顯 prompt 當道的階段。周遭很多人都在研究怎麼寫 prompt，怎麼把需求描述得更完整，讓 AI 可以更精準地產出高品質的程式碼。而我自己則還是比較偏向用我原本比較熟悉的方式，先把需求講清楚，取得 script 之後，再手動拿到 PROD 環境裡一邊測、一邊修，慢慢把它調整成真的能運作的東西。
而到了系統上線並且穩定跑過一段時間之後，我後來也開始陸續整理專案文件，因為接下來要面對的就不只是開發，而是後續的維運工作。
這裡面很重要的幾份資料，就是 PROD 環境的架構圖，還有 LOG 與監控資料的走向圖。因為當系統真的上線之後，你會開始更在意問題發生時要怎麼追、告警出來之後要怎麼看、日誌是從哪裡進來，最後又流到哪裡去。這些東西如果沒有整理清楚，平常可能還不覺得怎麼樣，但一旦真的要查問題，成本就會非常高。
不過，當系統真的慢慢成形之後，下一個痛點就出現了，就是畫架構圖。因為這時候問題已經不是單純知道有哪些元件，而是你要把它們真的整理出來。我要回頭去找各種設定值、補齊每一個節點機器的角色，再把這些東西統整成一張一目了然的圖。這件事非常繁瑣，而且比想像中還花時間。
我自己在做這件事情的時候，剛好也開始接觸 Claude skill。我那時很想讓 skill 幫我處理這件事，於是花了一周的時間自己拼湊、解坑，最後弄出了一個可以幫我畫出正確圖表的技能。以現在的眼光來看，那個技能其實做得很粗糙，執行效率也不好，但它的確是我接觸 skill 的入門磚。
也因為這樣，我開始更認真去想，到底要怎麼讓 AI 真正進入我日常的開發流程，幫我節省時間，不要再把精力浪費在這種大量整理文件與資料的事情上。
從使用 AI 到設計工作流#
如果要說我後來是怎麼應對這種快速變化，我覺得一個很明顯的轉折，就是我開始把 OpenSpec 和 Spectra 真的拿來處理日常工作，而不是只是把它們當成新工具來研究。
用 OpenSpec 和 Spectra 處理日常開發#
第一個部分，是我開始用 OpenSpec 和 Spectra 來應付日常的除錯，以及一些小功能的調整和開發。這個階段我通常會先利用自己已經知道的領域知識，透過 prompt 搭配 Spectra 的討論模式，把需求、專案背景、限制條件先解釋清楚，然後請 AI 協作整理出對應的解決方案規格設計。
而在這個環節裡，我認為最重要的事情其實不是讓 AI 趕快開始做，而是要非常仔細地去審視產出的文件。因為後面 AI 要怎麼工作，是以這份文件為依據；最後要怎麼驗收，也還是回到這份文件。所以這一步看起來像是在寫文件，但本質上其實是在定義工作邊界、確認需求理解，以及把驗收標準先講清楚。
這也讓我很明顯感受到，自己在這個工作流程裡扮演的角色變了。以前我負責的是理解需求，然後自己開發、自己測試，最後再請人驗收。可是當流程轉成 AI 協作之後，我某種程度上變成了交辦工作的人。這會逼著我開始從功能整體去思考，因為我不需要先把腦力消耗在實作細節上，反而可以把更多精力集中在功能本身，去想它真正的目的、邊界、例外情況，以及它到底有沒有貼近實際需求。
而這種思考上的轉變，我自己覺得其實很重要。它某種程度上是強迫我把視角拉高，不再只盯著程式碼怎麼寫，而是開始更在意這個功能最後交付出去的價值是什麼。
開始用 AI 改善維運工作流#
第二個部分，則是我開始著手做工作流程本身的改善。因為我一直有一個很明顯的痛點，就是系統現況很難確認。很多時候知識文件和程式碼是對不上的，線上真的出問題時，往往又需要非常快地應對。除非是記憶超人，不然一個人要長期記住各個專案大大小小的細部規則，我覺得對誰來說都很痛苦。
所以我現在正在做的，其實就是想辦法處理這件事。我希望可以讓系統現況、知識文件、程式碼之間的落差慢慢縮小，讓需要查問題、理解背景、接手維運的人，不用每次都重新從零開始拼湊。
我自己的知識庫已經改版很多次，有三個 repo，自己額外記錄的資料也有好幾份。我嘗試過很多方式來整理這些東西，但最終效果都不好。最近一次比較明確的心得是，個人知識庫適合用 MOC 結構來整理，找資料會比較方便；而專案本身的設定細節與文件，則應該盡量歸類放在同一個 repo。
當我把它當成提供給 AI 的 base context，然後把 index 與文件寫好之後，AI 才有可能比較完整地知道專案相關的事情。在這個前提下，很多原本做不到的事情，才開始真的有機會發生。
這也是我現在正在做的一個嘗試。我做了好幾個 Skill，每個 Skill 都盡量只解決一件事情。我的想法是，讓 Skill 去幫我處理明確的問題，而不是再像以前一樣，亂槍打鳥地下 prompt，期待 AI 臨場給我資訊，或幫我把事情做完。
有什麼例行工作我需要它協助，就寫一個 Skill。
有什麼線上問題我需要快速知道，就寫一個 Skill。
有什麼專案規格文件需要釐清，就寫一個 Skill。
有什麼文件需要自動化產出，也寫一個 Skill。
如果這些事情都做得起來，那理論上就能串成一個更完整的流程。當系統接到 alert 之後，AI 可以先去看 log、查錯誤，再一路回頭找到原始碼，確認這段原始碼對應的是哪一塊業務，再去找對應的功能文件，接著分析可能的錯誤原因。這中間如果牽涉到系統架構問題，就去看架構設定；如果是邏輯問題，就去翻文件。最後再整理出可能的錯誤重現步驟、成因，以及到底應該修正原始碼，還是調整業務邏輯。
這個畫面聽起來很好，但老實說，我現在還沒有真的把它完整實現，我只是正在朝這個方向前進。
也就是當這個想法慢慢成形的時候，我開始更確定一件事：我真正想做的，不是讓 AI 多幫我寫幾段程式，而是把人力從這些重複、零碎、耗神的事情裡解放出來，做出我自己的工作流，如果有機會，最好也能幫同事一起用上。
我現在最在意的是什麼#
回頭看這一路的變化，我覺得生成式 AI 真正改變我的，並不是單純讓我寫程式變快而已，而是它慢慢改變了我看待工作的方式。
以前我比較容易把焦點放在怎麼把功能做出來，怎麼把問題修掉，怎麼把部署和維運撐起來。但 AI 真的進來之後，我開始更常去想，什麼事情其實不值得人一直重複做，什麼事情應該被整理成規格、流程、文件，什麼事情又應該被抽成一個可以反覆使用的工作方法。
我現在最在意的，已經不是單一一次 AI 幫我省了多少時間，而是能不能慢慢把這些零散的經驗整理成一套真的能持續運作的工作流。因為只有這樣，AI 才不是一時的新鮮感，而是真的會留下來，成為工作的一部分。
題外話#
過去很多行業都有一種很深的文化，就是資深前輩會藏招，真正的本事只傳給少數親傳弟子。這種想法其實影響了很多人，也影響了很多世代。
但軟體產業我認為正在變成另外一回事。至少在 AI 這波變化裡，過去很多人引以為傲的程式撰寫能力，已經不再像以前那樣是絕對門檻。以前大家拼命鑽研的語法、底層細節、框架寫法，現在很多時候 AI 不只會，而且還會用得比你更快。
所以在這樣的時代變遷之下，企業真正的資產到底是什麼？我自己覺得，答案大概不會再只是程式碼。你可以說是人才，可以說是資料，可以說是品牌，可以說是流程，也可以說是對領域的理解，但程式碼本身已經很難再單獨算是一種護城河。
那以前靠寫程式吃飯的人，難道就一夕之間武功盡失嗎？我倒覺得也不是。與其問自己要不要逃走，不如直接問，既然趨勢已經來了，為什麼不加入它？以前大家發現雲端是未來趨勢，就會開始學雲端；現在既然 AI 很明顯是下一個趨勢，那其實也是同樣的道理。
如果真的要學怎麼使用 AI，我反而會覺得不要先從工具出發，而是從需求出發。你到底希望 AI 幫你解決什麼問題？從這裡開始，通常會比一開始就去追最新名詞、最新玩法，來得實際很多。