需求確認後留下了一份我看過、刪過、改過的需求文件，包含準備交給 Claude Code 的文件也一起產出。
很多人到了這個階段，就會直接把文件交給各種 AI Agent，開始讓它執行整個專案。

那我呢? 到底開始叫 AI 寫程式了沒？

我個人來看應該要知道這套系統到底準備怎麼運作、需要哪些技術和元件，以及最後預計會長成什麼樣子。
就跟你裝潢一間房子總要先確認過設計圖、你煮一道菜總要先知道你要煮甚麼

所以我把需求文件交給 AI，請它規劃整體架構。
它給了我一張看起來很完整的架構圖，但這時候又是另一連串對話的開始。

架構圖

下面這張架構圖是 AI 產出的，不是我自己畫的。

從左到右，大致是使用者的瀏覽器、Nginx、應用層及資料層，旁邊還有掃描 Worker、企業 AD 和 SIEM。整個上架流程則包含上傳原始碼、觸發掃描、取得報告、人工審核，以及最後正式發布工具。

這是一張邏輯架構圖，主要呈現各個元件負責什麼工作，以及彼此之間如何交換資料。至於 Port、網段、Docker 網路、備份、單點故障等問題，比較偏向後續的部署設計，這篇就先不展開，不然篇幅真的會講不完。

為什麼不自己畫？

首先，自己從零開始規劃、畫圖，確實需要花不少時間。另一方面，AI 可以很快提出一套架構，甚至補充一些我們原本沒有想到的元件與設計。

這也是現在很多人使用 AI 的原因。除了速度快，另一個原因是我們不一定具備所有領域的專業知識。

例如，一個想開發系統的人，可能熟悉前端、後端、網路或資安，也可能完全不是資訊相關背景。每個人擅長的領域不同，而 AI 可以協助補足自己不熟悉的部分，讓我們有更多方案可以參考。

但這不代表 AI 提出的東西就應該照單全收。

我的做法跟前面講的一樣：把需求交給 AI，請它提出方案；看不懂的就問，不合理的就請它解釋，直到我能夠理解每個元件為什麼存在、需要哪些資源，以及某個環節出了問題，可能會影響哪些地方。

為什麼要花這麼多時間確認？

因為 AI 有時候很會幫你想更多。你只是想做一個簡單的系統，它可能順手幫你規劃一堆目前根本用不到的功能與元件。

功能越多、架構越完整，不一定代表越適合你的需求。

所以，當 AI 畫出這張架構圖之後，我真正要做的事情才剛開始。

看不懂？先別急著同意 AI 的觀點

我通常會先問它：為什麼要這樣設計？為什麼選擇這個技術？有沒有其他做法？如果拿掉某個元件，會發生什麼事？

使用 AI 的時候，我習慣保持著「十萬個為什麼」的心態。

例如，先問 AI A，請它提出架構和設計理由。接著，把同樣的問題或它提出的方案交給 AI B，看看另一個 AI 有沒有不同的看法。

如果 AI B 提出了不同的建議，我就繼續拿去問 AI C，請它比較這些方案的差異，以及各自可能存在的問題。

然後呢？當然還沒結束。

我會把 AI B 和 AI C 提出的問題，再拿回去問原本的 AI A，看看它會怎麼解釋，或是會不會因此調整原本的設計。

為什麼要這麼麻煩，自己手動在不同的 AI 之間來回詢問？

因為我希望在這個過程中，自己也能看懂它們提出的理由，知道不同方案到底差在哪裡，而不是讓幾個 AI 討論完之後，就直接把最後的答案當成定案。

當然，現在也有人透過 MCP 或其他整合方式，串接多個 AI，讓它們自動進行交叉討論，最後再由使用者檢視結果。

這確實是另一種做法，但也需要考慮工具權限、資料存取，以及外部服務整合所帶來的風險。至於 MCP 本身的安全議題，大家有興趣可以再深入研究。

我目前還是習慣手動進行這些討論。雖然比較花時間，但可以讓自己逐步理解每個方案的差異，也比較容易發現 AI 是不是誤解了我的需求。

不過，多問幾個 AI 並不代表答案就一定正確。如果它們引用了相同的錯誤資訊，或一開始就誤解了需求，也可能得出類似的錯誤結論。

交叉詢問是為了幫助自己發現問題，不是把最後的決定交給多數決。

當幾個 AI 討論出不同的方案之後，接下來還有一件更重要的事情：把自己真正的環境和限制帶進來。

例如，AI 可能建議增加 Redis、訊息佇列或其他服務，理由是未來比較容易擴充。但如果我第一版只有一台資源有限的 VM、使用人數不多，而且還要自己負責後續維運，那現在真的需要這些東西嗎？

同樣地，AI 可能為了讓系統比較容易開發，把不同功能放在同一個服務裡。但如果其中一個功能需要處理使用者上傳的不可信檔案，我就必須考慮是否需要將它獨立隔離。

最後請他產生的時候再仔細確認 例如他根本亂給答案

諸多討論後給一版符合需求的架構圖

但這可能也不會是最後一版，但至少可以作為初版來進行下一步

當然所有的問題都沒有標準答案。
真正的重點，是把 AI 提出的通用方案，調整成符合自己跟企業的環境設計。

小結

在架構規劃的過程中，AI 提出了好幾個方案，有些是經過討論後調整 AI 的建議，有些則是讓我重新思考自己原本的規劃。

這不代表 AI 原本提出的架構一定對或錯，而是我一開始可能沒有把實際環境、資源限制，以及需要考量的資安風險交代清楚。如果沒有進一步追問，它就可能依照一般情境，提出一套看起來合理，卻不一定適合我的架構。

其實這就像你想打造一個心目中的家。

以前，你會找建築師或室內設計師，告訴他自己想要什麼樣的生活空間。對方依照你的需求提出設計圖，你再跟他討論哪裡需要隔間、收納空間夠不夠、插座要放在哪裡，以及哪些設計會不會超出預算。

你不一定會畫建築圖，也不一定懂每一種建材，但至少要知道自己想住在什麼樣的環境，並且能夠跟設計師討論，確認最後的設計符合你的需求。

今天，只是原本由人擔任的討論對象，變成了 AI。

不管對方是人還是 AI 你都不能因為設計圖看起來很漂亮，就同意施工

對我來說這個階段要確認的，不是 AI 畫出一張漂亮的架構圖，
而是能不能解釋這套架構為什麼這樣設計，符不符合我的需求，
未來某個地方出了問題，可能會影響哪些地方或我該怎麼處理。

其實資安最重要的工作之一，就是識別風險、分析與評估風險，再決定要採取哪些因應措施。
所以首先你必須理解才能夠識別風險

風險不一定全部都要消除，也不可能全部消除。有些可以透過技術降低，有些可以透過架構設計避免，有些可以轉移，也有些是在充分了解影響之後，由有權責的人決定是否接受。

這也是為什麼我想在正式開發之前，先把架構圖畫出來。至少要先知道系統有哪些元件、資料怎麼流動、哪些地方跨越了信任邊界，才能進一步討論哪裡可能被攻擊、會造成什麼影響，以及應該採取哪些防護措施。

架構圖不是畫完就可以直接開工，而是接下來進行風險分析的基礎。