軟體系統的搭建筆記（一）：為什麼要先決定架構

AI 連續開發會把東西放到特殊位置

AI 開發時，會先看眼前任務要做什麼，接著尋找相關的程式，再從中挑選一個可以動手的位置。當專案有清楚架構時，它會比較容易知道某種邏輯應該放在哪裡、由哪個部分負責。否則，它會找一個當下視野範圍內，能完成工作的地方。

這就是問題開始的地方。

每一個位置都可以讓功能運作，但背後可能對應著不同的架構理論。每次 AI 再開發下一段時，可能會知道之前的習慣而沿用，也可能會產生誤會而挑選另一套理論來實作。最終導致一個專案內有很多不同的風格。

再加上 AI 本身特性就會有些偏移，一次兩次看不明顯，但持續把這些特殊狀況當成前後文累積下去，整個專案就像甩尾一樣越來越歪。

很多人會把這件事理解成 AI 寫法不一致，所以要求 AI 每次都用一樣的邏輯。但這不是重點。

解題邏輯本來就不是唯一，不同情境也有不同處理方式。真正的問題在於沒有先定出責任邊界，AI 不知道什麼東西該出現在哪裡，抽籤的結果就會讓某些東西跑到不該出現的地方。

架構要解決的不是「所有地方都長一樣」，而是讓每一種責任都有合理位置。

AI 後續開發時，不只看你的指令，也會看既有程式碼，它會從既有程式碼推測這個專案的習慣或規則。

如果你有用 skills 或者規格等文件，當然可以在一定程度內控制得很好。但是 AI 本身的特性造就它可能會無視某些規範，即便你三令五申的要求。

而當一個不注意，導致很特殊的東西出現後，AI 後面就可能持續誤判。它會以為這個位置本來就負責這類事情，或以為這種接法就是專案原本的方向。於是原本只是一次局部選擇或者失誤，會慢慢變成後續開發的參考依據。

專案是沿著前一次的偏差再偏一點，到後面你就要開始面對傳統開發上的大問題，難以維護。

有穩定架構時，你大概知道一件事會被放在哪裡，他能有效的減輕理解和維護壓力。畢竟每次重新追溯專案的成本是很昂貴的。

當 AI 也知道你的架構時，他在確認參考的時候，也會優先了解影響範圍，有助於減少他的誤判或猜測所導致的幻想。

如果有穩定的規格文件，那會是更完整的參考依據，很多軟體工程的方法可以相輔相成，而對我們來說，能穩定產出自己想要的東西才是最重要的。

其實，上述的狀況，並不是 AI 才會發生。

怎麼保持 AI 的開發習慣一致？
怎麼保持團隊中的工程師的開發習慣一致？

怎麼確保AI能正確了解專案內部的架構？
怎麼確保團隊中的工程師能正確了解專案內部的架構？

因此我們可以了解，與 AI 合作，跟與不同工程師合作，其實面臨一模一樣的問題。那我們應該可以使用同樣的軟體工程方法，來解決相同的問題。

除了常聽到的 TDD、BDD 到 SDD，利用規格、測試等方法來增加可視範圍以及確認結果之外。我們也可以對整個專案進行切割，類似微服務的概念，目的是讓每個服務的責任邊界縮小並且更加清楚。

這個系列，就是要用我自己的產品案例，來一步步的分析是怎麼設計架構的。