傳統上，複雜的軟體專案，除了程式設計師之外，還會搭配系統設計師，甚至系統分析師，確保領域知識及商業邏輯都有朝對的方向前進。
生成式 AI 既然會寫程式，下一個問題就是：它也會做系統分析嗎？
理論上來說，應該是的。畢竟我們在前一篇文章都親眼看過，AI 既然能理解規格、潤飾需求、撰寫程式碼，甚至生成測試案例，那麼系統分析 (SA) 和系統設計 (SD) 這類「中間產物」，確實也難不倒它。畢竟，系統分析本質上就是資訊的整理、建模與推理，而這些都是 AI 擅長的領域。
我認為，SA/SD 也應該納入 AI 協作。尤其是從 SA/SD 擅長的建模角度，能夠協助我們及早確認領域知識及商業邏輯，檢查需求規格是否有矛盾、遺漏或模稜兩可的地方，甚至提出改善建議，幫助系統分析師更快定位問題，減少後期開發的返工成本。譬如說，透過 AI 生成的狀態轉移圖，也有助於規劃黑箱測試，提高測試覆蓋率，進而提升系統的穩定性與可靠性。
接下來就是現實問題了：讓 AI 產生的狀態圖，真的比人工畫得更好嗎？能省多少時間？
這就要實測了！現在，就讓我們拿前一篇文章的規格作為引子，看看 AI 生成的狀態圖表現如何吧！
狀況一：過於窮舉
提示詞 #1：
Generate a UML-style state diagram for the game.
吐出的狀態圖，細節可能每次都有些不同，以下是較常見的版本：
嚴格說起來，這份狀態圖並不符合 UML 格式⋯⋯但我暫時不挑剔這一點，等最後一步再來處理。
這份狀態圖，把所有可能的狀態都窮舉了，應該很合乎測試狂人的胃口。不過，窮舉得太過於累贅，很難消化。若不予以抽象化，很難進一步發展出程式。
狀況二：濃縮過度
我們請 GenAI 整頓一下，在不影響正確性的前提下，將過於累贅的狀態精簡濃縮一遍：
Is it possible to reduce the states without compromising correctness or clarity?
吐出的狀態圖，細節可能每次都有些不同，我挑出其中一個版本來聊聊：
有了這份濃縮過的狀態圖，就比較容易一眼看出問題。最大的問題就是，有兩個紅色箭頭的地方濃縮過頭了，誤把 2-0 及 0-2 比分判定為比賽結束。
基本合格的狀態圖
我請 GenAI 修正三個地方：
Three issues need to be addressed:
- The “Px leads by 2 points” transition is too vague. Does it account for cases like 2-0 or 0-2?
- The two “Game Start” transitions should be merged into one.
- Add an initial state for the 0-0 (“Love-Love”) score.
如此這般調整，通常我們很快就可以得到比較滿意的狀態圖，既清晰，又正確：
轉換成機器可讀的版本
既然好不容易生出清晰正確的狀態圖，我們應該把圖形轉成像是 PlantUML 這種可程式化的文字表述形式，以預留後續應用的可能性。
提示詞：
Proceed to represent the state diagram using PlantUML syntax.
我們會得到這樣的狀態圖規格文字：
PlantUML 格式的狀態圖
@startuml
[*] --> LoveLove : Game Start
LoveLove --> Score : P1 or P2 Scores
Score --> Score : Regular Scoring
Score --> Deuce : Both >= 3 & Equal
Deuce --> AdvantageP1 : P1 Scores
Deuce --> AdvantageP2 : P2 Scores
Score --> WinP1 : P1 >= 4 & Lead >= 2
Score --> WinP2 : P2 >= 4 & Lead >= 2
AdvantageP1 --> WinP1 : P1 Scores
AdvantageP2 --> WinP2 : P2 Scores
AdvantageP1 --> Deuce : P2 Scores
AdvantageP2 --> Deuce : P1 Scores
WinP1 --> [*]
WinP2 --> [*]
@enduml
這份狀態圖以及 PlantUML 規格文字，很值得放進系統分析文件，甚至規格書。
不過，如果你有潔癖，希望狀態圖要合乎正統的 UML 規定，可以把上面的文字丟到PlantUML 軟體去產生完全合乎標準的 UML 狀態圖：
系統分析的再思
許多威力強大的機器學習與人工智慧技術，本質上是黑箱的，可觀測性與可解釋性，一直是技術發展與推廣的大挑戰。
對於 GenAI 神兵利器，許多人只在程式碼的層次與 GenAI 對話，畢竟光速產生程式的快感，很難不上癮。
系統分析？很抱歉，這是光速領域，沒有預留座位。
但我還是想要稍微保守一點，寧可慢一點。在前段的規格、中段的系統分析與設計、後段的測試驗收，與 GenAI 多一點協作，在中間產物身上，多留下一些可觀測、可解釋的線索，並力求可以穩定再現。
畢竟，順向工程比較容易，逆向工程比較困難。如我前一篇文章〈當 AI 會寫程式，程式碼會變得即寫即棄嗎？〉所說，程式碼之所以會變得可以即寫即棄，是因為我們用更有效率的方式，將「可用的軟體」的內涵，轉寫到「詳盡的文件」裡面，讓它成為更有意義的 “ground truth”。
在與 GenAI 協作時，別忘了「詳盡的文件」也是協作的重點。