昨天我們提到踩坑清單，這個概念源自學生時期常聽到的「錯題本」，不過學生時期我其實很懶得做筆記......因為對學習模式沒有什麼概念，只知道就是要學、要考試，所以不知道「對自己有幫助的筆記」要怎麼做出來，最後就乾脆不做 XD

試錯的學習

我過往的學習方式是快速看過知識講解後就開始做題目，不會做就往前翻翻看找答案，也算是另類的錯題本，但是最後大多沒有彙整，只會在考試前看過這些被圈起來的題目，仰賴我還年輕的短期記憶力（？），所以在知識範圍很大的大考就容易翻車。

我剛開始學習程式時也是如此，會大量地試錯（Tial & Error），讓腦袋有這個流程的肌肉記憶，不知道 React.useState 怎麼用，我就一直寫，寫壞也沒關係，直到記住為止。

還記得昨天說到的學習模式的迭代嗎？在建構新知識時，快速的試錯是可行且有用的，但是隨著我們越來越熟悉這套流程後，一定會覺得試錯很花時間，感覺自己在重複建構一樣的知識模型。

在沒有 AI 幫忙的以前，我們會嘗試分析、梳理流程、寫虛擬碼，慢慢習慣動工之前先想想，拓展解決問題的思維與面向。

有 AI 之後試錯變得很容易，因為繁瑣的試錯工作都可以丟給這些時薪比工讀生還便宜的乖孩子，回答不滿意就按下 retry，惡言相向也不會收到傳票^O^

垂直管理

雖然我現在也只是基層員工，不過 AI 可是隨意我們使喚的！

建立一套處理問題的 SOP 尤其重要，有了 SOP 就可以在事前排除許多腦力與時間的消耗，投資在值得探索的方向上，我認為這也是工程師這個職位應該要具備的價值，engineering 這個單字代表的不只是科學理論的實踐，更多是標準化、規格化的制定與檢驗。

我們已經有實作的經驗，那麼 SOP 中有很多重複性工作就可以移交給 AI 來做做看，透過我們的實務經驗來檢驗這位孩子的成果。

如果它越走越偏，回答越來越幻覺，有時候不是因為這個模型太廢，這個孩子「目前」就只能做到這樣（物理極限），那麼我們就得調整執行策略，換個 prompt、換方法、換格式等等，無論如何，最後負責向上交差（背鍋）的是我們本人，不是推給這孩子。

（但部分的 AI 服務真的要加油，對話經常斷線，都不知道要怎麼幫你洗地了。）

我目前探索的心得是，要減少幻覺最好是先寫好範例，多列舉一些，並把需求拆解成更小、更細的步驟，讓它依樣畫葫蘆，在上下文範圍不大的情況下，準確率其實是很高的。整理出共通的開發規則與範例，就可以讓 AI 按照我們的思路去尋找解決方案。

總之要身體力行，而不是養兒防老，祈禱它突然通靈來救我們 XD

聽起來有沒有很像小組長呢？我們以為只要向上管理，結果還要向下管理 AI......但這就是 AI 普及後必然的現象。

本日小結

我先承認今天的內文水分偏多 XD 但這是我轉職一年左右的真實心得，工作上遇到的問題很多剛好都是以前作業、專題做過，或是黑客松有學到，所以我想實作經驗始終是不可或缺的。

今天的懶人包：

• 沒有完美的 prompt，就像寫程式一樣，要先試錯
• 建構自己的 SOP，培養工程化思維
• 持續累積實作經驗，AI 挖的洞需要靠我們的經驗來把關
• 學習拆解需求，寫成規格與範例，讓 AI 在我們的思路上執行
• 學習管理能力，從個人的工作管理開始，慢慢延伸到管理 AI，最後管理整個專案的運行

參考資料

• 軟體工程師應具備的 5 個思維與態度