前言
我聽說過這樣一句話：「AI 並不是消除瓶頸，而只是把瓶頸轉移到其他流程而已。」雖然我並不是在系統導入中能夠完全駕馭 AI 的人，但畢竟也有部分地方會活用 AI，所以我重新回顧了一下自己在系統導入的流程中，是如何進行的，以及瓶頸究竟在哪裡。
前提
先大致寫一下導入流程。流程如下分成六個階段：需求定義、驗證、設計、建置、測試、營運。驗證會在什麼時候實施，依專案而異。有時會在需求定義後進行，有時也會另外作為 PoC 或驗證專案單獨實施。把各階段的輸入、輸出，以及我自己花最多時間的地方畫成圖，大致會像下面這樣。
先不談需求定義，橘色的驗證和綠色的設計，是手動作業最多的部分。
這次文章中的導入系統範例先簡化如下：在 AWS 上建置 EC2 伺服器，並進行修補程式套用、備份取得與系統監控。
驗證
我花最多時間的就是驗證階段。在這裡會透過管理主控台把細節一點一點確認清楚。比如說 Patch Manager 的運作方式是什麼。
不只是單純看修補程式有沒有套用成功，也會在管理主控台中一邊點選操作，一邊確認像下面這些項目：
- 有可套用的修補程式時會怎樣，沒有可套用時又會怎樣
- 如果伺服器處於停止狀態會怎樣
- 套用後會不會自動重新啟動
- 發生問題時，是否有輸出可用來協助排除問題的日誌
- 如果一邊用 Patch Manager 套用、一邊又手動套用，會發生什麼事
除了動作本身之外，也會在這裡確認設定不同參數時，行為會如何改變。比如說，在詳細設計以後的階段會製作參數表（以下是用 Claude Code 製作的範例），這個參數代表什麼意思、設計依據是什麼，都會在這裡思考。
由於是使用 AI 來進行，驗證過的資訊會作為實際執行結果與設計依據的資料持續累積下來。
設計
會根據需求與驗證過的資訊來製作設計書和參數表。這部分也有一些地方已經能以需求與驗證資訊作為輸入來自動化，但像格式、架構圖製作、圖表插入等，還有很多地方仍然得手動處理，所以我希望能再進一步自動化。
建置、測試
建置與測試階段在很多地方都已經能夠自動化。
- 根據參數表建立 IaC 程式碼
- 根據驗證資訊與設計資訊，建立 Markdown 版的建置手順書與測試規格表
實際建置時，會一邊讓 AI 讀建置手順書，一邊使用 IaC 程式碼來進行建置。測試也是一邊讓 AI 讀測試規格書，一邊實施，並產出測試成績書與測試證據。
營運
驗證時的資訊，以及建置與測試時的資訊，因為都是和 AI 一起進行的，所以知識都累積在 MD 檔中。像是為什麼會採用這樣的設定、為什麼在這裡不順利，這些以前屬於所謂默會知識的內容，也逐漸被形式知識化。因此，只要善用這些資訊，就能提高營運階段的可重現性。
成為瓶頸的項目
再把前面的圖貼一次。
成為瓶頸的部分，就是橘色的「驗證」項目，以及綠色的「設計書・參數表」項目。建置之前的階段在很多地方都已能自動化。前面也提過，我希望設計書・參數表這一段能再多一些自動化。
不過，驗證這一部分我認為還是可以像以往一樣花時間。反過來說，正因為在這裡花了很多時間去理解系統的運作方式，後續流程才能夠自動化。
例如，考慮修補程式套用的測試。到了測試規格書階段，能夠用命令列執行的部分就會盡量用命令來做。修補程式的套用與確認，也會使用 AWS CLI 或 PowerShell 來執行，然後取得結果。因為已經理解系統的運作，所以即使是命令與執行結果，也能看懂並判斷是 OK 還是 NG。但如果對系統不夠理解，還要用 CLI 執行，就會很難判斷 AI 給出的回答。還有，驗證這個部分也是最有趣的。另外，雖然有人說因為活用 AI，獲得基礎基礎設施知識的機會變少了，但如果像這樣一邊實際動手一邊做驗證，基礎的基礎設施知識還是會慢慢累積起來。
總結
無論是為了學習基礎知識，還是為了後續流程的自動化，包含驗證在內、用來理解系統的部分，仍然需要手動花很多時間。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
