從 Change 到真實狀態：如何讓持續迭代的系統收斂，而不是發散
·2 分鐘
1. 問題是從哪裡開始的？ #
這次思考的起點，其實不是想整理一套軟體開發方法，而是因為我開始嘗試和 LLM 一起工作。
AI 時代有一個很明顯的變化：產生資訊、整理資訊、修改程式與建立文件的成本大幅下降。以前需要花很多時間才能完成的分析、規格整理或實作，現在可能只需要幾輪對話就能產生一個可用的版本。
這讓「把想法快速變成東西」變得非常容易，但也帶來一個蠻反直覺的問題：當產生資訊的成本接近於零，資訊本身反而開始爆炸。
這也是我開始重新思考 SSoT、Intent、Spec 與 Canon 的原因。
開發一個新的系統或工具時，我很自然會採用 MVP 的方式。
先有一個想法，快速做出雛形，確認它是否真的有用。只要能運作，就拿到真實的專案裡使用。
接著，實際使用會產生新的問題：
- 某個功能不符合預期
- 某個需求原本沒有想清楚
- 某個規則不夠完整
- 實作方式產生新的限制
- 使用後發現其實還需要另一個能力
於是，每一個問題又變成下一個 Change。
這個循環一開始非常有效：
但當系統越來越大，問題就開始出現了。
舊問題還沒處理完，新問題又不斷冒出來。
最後 backlog 越來越長，功能越來越多，系統卻沒有變得更一致。
這時候我心裡冒出一個很直覺的疑問：
是不是系統已經開始發散了？
2. 問題可能不是 Iteration，而是 Change 被扁平化了 #
仔細觀察後我發現，問題不一定出在「持續迭代」。