昨天我們提到「踩坑清單」，這個概念源自學生時期常聽到的「錯題本」，不過那時我甚至沒有在做筆記......因為對學習模式沒有什麼概念，所以不知道筆記要怎麼做對自己有幫助的筆記，最後就不了了之都不寫 XD
我過往的學習方式是快速看過知識講解後就開始做題目，遇到不會做的就往前翻翻看找答案，也算是一種錯題本，但是最後都沒有彙整，只會在考試前看過這些被圈起來的題目，仰賴年輕人的短期記憶力（？），所以大考很容易翻車 XD
我剛開始學習程式時也是如此，會大量地試錯（Tial & Error），讓腦袋有這個流程的肌肉記憶，不知道 React.useState 怎麼用，我就一直寫，寫壞也沒關係，直到記住為止。
還記得昨天說到的「學習模式的迭代」嗎？
在建構新知識時，試錯的確是可行且有用的，但是隨著我們越來越熟悉，一定會覺得試錯很花時間。
在沒有 AI 的時代，我們會嘗試分析、梳理流程、寫虛擬碼，開始習慣動手做之前先想一想，慢慢拓展解決問題的思維與面向。
有了 AI 之後，試錯變得很容易，因為繁瑣的工作都可以丟給這些時薪比工讀生還便宜的乖孩子，回答不滿意就按下 retry，惡言相向也不會收到傳票^O^
雖然我只是基層員工，不過 AI 可是隨意我們使喚的！
所以建立一套處理問題的 SOP 就更加重要，有了 SOP 就可以排除許多無效的事前準備，將腦力與時間花在值得探索的方向上，我認為這也是工程師這個職位應該要具備的價值。
我們已經有實作的經驗，那麼 SOP 中有很多部分是可以移交給 AI 來做做看，由我們的經驗來檢驗這位孩子的成果。
如果它越走越偏，回答越來越幻覺，有時候不是因為這個模型太廢（雖然 Cursor 某些模型經常斷線讓我非常不爽^^），這個孩子「目前」就只能做到這樣，那麼我們就得調整執行策略，換個 prompt、換個方法、繼續腦力激盪找關鍵字......無論如何，最後負責向上交差（背鍋）的是我們本人，不是這孩子。
我目前探索下來，比較有效解決 AI 不靈光的方式，是寫好範例，最好多列舉一些，並把需求拆解成更細的步驟，讓它依樣畫葫蘆，或是按照我們的思路去尋找解決方案，總之要身體力行，而不是養兒防老，祈禱它突然通靈來救我們 XD
聽起來有沒有很像小組長呢？我們以為只要向上管理，結果還要向下管理 AI......但這就是 AI 普及後必然的現象。
今天的內容水分偏多 XD 但這是我轉職一年以來的真實心得，工作上遇到的問題很多剛好都是以前作業、專題做過，或是黑客松有學到，所以我覺得實作經驗始終是不可或缺的。
今天的懶人包：
iThome鐵人賽
看影片追技術