近期 AI 寫 Code 的一些想法
之前用 AI 寫程式，比較 free style，簡單說，就是功能能運作就好，反正就解決單點問題，就算是個商業應用，也大多設計成可以離線使用，架構很簡單。
但最近為了要完成我 Growth OS 的野望，我又回到以前工程師年代，會很在意目錄架構、資料結構、資料流、權限控制，甚至也會思考更多關於擴展性、多租戶、系統邊界設計的問題。
也因為有較深入的思考，對於 AI 參與開發這件事，我有了多一點的體悟。
Rule-baesd 模式
從前的程式開發大多是建立在有明確規格之後，演算法就像數學公式一樣，輸入什麼樣的參數，往往就能得到一個可預期的結果。
簡單的說，就是「確定性」，所以以前的測試根據的是輸入 A/B，是否得到 C 結果。
直到現在，如果我們對一個程式的執行結果，最主要看的是「確定性」，也就是執行一百次都要得到可預期的結果。那最後或許還是只有清楚的 rule 能做到這件事。
所以那些不容有失的程式，你還是需要讓程式碼每個 conditions/rules 都寫得清清楚楚，不然肯定會掛。
Principle-baesd 模式
最近透過 AI 在進行比較有架構性的程式設計時發現，有很多需求若要用 rule-based 來處理，複雜度真的很高，同時也不見得有必要。例如針對一份簡報給回饋，評價一份履歷，每次給出的結果略有不同其實不會有什麼太大的問題。
只要你不是這次說簡報超棒，下次說超爛，履歷不會這次說合適，下次剔除就好。我們需要的是「一致性」而非確定性。每次的評價都是正面的，至於是超級棒，還是很棒是其次，而就算兩次都是超級棒，原因略有差異也沒關係。因為最終都會進入到下個階段，或者都不會有下個動作。
以最近的案例為例，我撰寫的 OKR 工具，會根據我定義好的原則來回饋使用者所設定的內容。
但同樣的內容，在兩次執行過程中給出的結果卻有極大的差別，雖然兩者最後都需要再調整 KR 的內容，但要改的地方卻有極大的差異。這就偏離了我想要的結果，這結果不一致。
面對這類「一致性」的需求，我覺得以羅列「原則(Principle)」的方式來進行非常適合。對我來說，目前寫在 markdown 檔中的內容，對我來說就是一條條的原則。
而 Prompt + LLM 算起來就是一種基於原則(Principle-baesd)的開發模式。
而要做到一致性，你的原則也不能定義的太鬆散或模糊，不然會失去一致性，但如果你要把所有原則都羅列清楚，把所有判斷條件都講完，那就會很接近 rule-based。
但我覺得沒有必要，因為窮舉所有的 rules 代價太大，根本不划算。現階段，我覺得 Claude Code 滿足我最多的其實是這一塊。
因為我過去想過很多次要把一些複雜的概念系統化時，我總會面臨到抽象容易，但要具象到可實作難度太高了。最後我只能走 divide-and conquer 的模式，先把範圍拆小，然後一層一層透過 rule-baesd 把需求定義清楚。但即便限縮範圍了，我還是很難窮舉所有可能性，而當無法窮舉時，我想做的系統根本就做不出來。
我現在想通的是，過去我一直在追求結果的確定性，但其實我只需要做到一致性就好。
Scenario-Generating 模式
第三種模式，我稱之為叫 Scenario-Generating 模式。有些需求其實我尚未釐清，也不確定我可以怎麼做，我只是描述一個情境，然後說明我想看見的可能樣貌，然後請 Claude Code 先幫我做一個版本出來看看。
從前這種創意是稀缺品，因為我們很難叫團隊夥伴去想想看，或者叫員工自己去找尋可能的方向。但我們自己又經常卡在念頭尚未通透，需求若有似無的狀態，最後的結果通常是 - 放棄。
但現在，我會把我想到的情境告訴 Claude Code，然後請他幫我找相似的案例，或者根據我當下的描述，他來闡述他的理解，抑或幫我做出一個他想像中的東西。最後我可以針對他的敘述或成品來進一步說明逼近我真正需要的東西。
在我開發過程，我覺得最有趣的地方是，以前是實作者會來訪談(拷問)我，希望我把需求講清楚。AI 其實也會問我想法到底是什麼？
但現在我會跟他說：「你先跑三個案例的結果給我看。」、「你每個都做一次，我來看看哪個比較接近我要的。」
從前，第一個要求，案例通常是我來想，但現在我都直接交給 AI。而第二個要求，往往是老闆跟員工之間最大的衝突點，一不小心就會被說是慣老闆。但其實，這兩種模式都大大加快了我釐清需求的速度。
還記得上次跟 Happy 在最新一期的《搞什麼鬼》中聊到「要做 GM，不要做 PM」。
PM 總是習慣把需求講得鉅細靡遺，把規格寫的清清楚楚，然後讓工程師去完成所要開發的功能。所以動腦的人是 PM，工程師只是負責建造跟執行的人。
GM 則是負責提需求，不負責想細節，細節應該交給其他人來想。以前的程式無法做好這件事，但現在的 AI 完全能做到思考、聯想、創造。
我們不需要再扮演一個想盡辦法完善所有細節的人，而應該大膽嘗試將創意交給 AI，自己專注提出需求就好。
對於那些不追求正確性跟一致性的東西，或許 Scenario-Generating 模式更適合。
不過我近期的任務中，很多狀況是先走 Scenario-Generating 模式，有個雛型後我再切入 Principle-baesd 模式，在幾個小時內生成一個我滿意的成果。
因為我做的大多不是規格功能從一開始就確定的東西，在過去經驗中，我要從構想到產出成品，通常需要花上一兩個月以上的時間。而現在，可能只是一天或半天的時間就能做到。
這種改變讓我感到非常興奮，也讓我有重新開始好好寫程式，打造產品的念頭。
這三種模式其實是並存的：
- Rule-baesd 追求確定性
- Principle-baesd 在意一致性
- Scenario-Generating 重點在可能性
AI Coding 的時代，真的很有趣。
如果你覺得我內容寫得還不錯，歡迎訂閱我的電子報，我每雙週會發送一封電子報到你的信箱。訂閱連結在這，過往的電子報也在這：Gipi電子報
也鼓勵你可以將我的電子報分享給你認為有需要的朋友們，也許你的舉手之勞，將會改變另一個人的思維與習慣。
