讓 AI 加速生產，需要解決哪些問題？
AI 真的很強，不過我今天不打算討論「AI 要取代我了」這個話題，這話題除了已經聊爛了，而且看起來暫時無解，探討人類的存在價值就是漫長的哲學探討，對我這個大學新鮮人來說太難了。
我覺得除非有打算轉行，不然整天焦慮、空轉這點好像也沒什麼用，所以我作為一個工程師更有興趣的是：AI 可以怎麼幫我加速生產？
目前我覺得還有至少兩個瓶頸要去克服，分別是 AI 不夠懂我們意圖的上下文，也延伸了另一個問題是一旦某個步驟方向錯誤，一步錯，步步錯。
問題一：上下文資訊不足
一旦 AI 不確定你的專案背景、domain knowledge，那其實很常會發生的事情是他照你的指示去做事情，但很常發生跟他所做的行為跟你的預期是不一樣的。
我以前很常聽到有些人在抱怨 AI 不好用，也許就是這個原因吧？這確實是個要克服的問題，所以我們可以來想想：我們可以如何提供上下文？
解法：建立文件文化
我自己的看法是：我們需要建立一套完善的文件文化。其實這不只是在幫助 AI 加速生產，也是在建立一個健康的文化，因為新人今天要有辦法加入到一個專案的開發，也需要去了解這些專案背景跟前後文。只是很常這些東西都是靠前輩口頭介紹，大多數資訊沒有文字或是任何形式的紀錄。
AI 就像是個新人一樣，我們如果要讓他 onboard 進來這個專案開發，那我們勢必就需要把文件也備妥。
開源專案其實就是很可以參考的例子：為了讓全世界的工程師都有辦法加入開發，所以文件很常都會放在 codebase 裡面，然後也會寫好各種
.md 檔案，方便新人進來加入開發。
參考自 Gravitino
經典的文件類型可以像是
README.md, CONTRIBUTING.md，可以的話可以再把一些 spec、專案架構、領域知識給放進來。寫文件的好處
把文件放進 codebase 有兩個好處：
- 方便 vscode agent, cursor 這種整合 AI 的編輯器直接拖拉需要了解的文件給 agent。不用特別串 mcp 到 confluence 之類的或是手動複製貼上。
- 發文件 PR 的時候可以讓團隊的成員都要去 approve，確保大家都有看過該文件、做資訊的同步。
會議記錄轉文字
語音模型的能力真的很強，我平常 prompt 多少都會用 OpenAI 的 whisper。雖然下面這個方案我還沒開始引進到團隊，不過應該會很實用。
現在有很多厲害的 AI meeting 工具，其實也可以考慮在跑 scrum 的 refinement 時，把對於下一期 sprint 的票的討論給記錄下來，包含預計怎麼實作、問題難點、要注意的地方之類的，這些語音資料轉成文字後就附在票上，相信對加速 AI 對這個專案的理解是很有幫助的。
總之我想說的是：讓 AI 理解上下文，就像帶新人 onboard 一樣，文件越清楚，效率就越高。以後就算前輩離開這個 team，知識也可以傳承下去、知識不會耦合在一個人身上。
問題二：一步錯，步步錯
前面的做法都是在實作前可以做的一些準備，接下來我們來聊聊開發當下可以怎麼做。
在下完一次 prompt 之後，我的經驗是 AI Agent 會一股腦做超久、超多的事情，很容易在某一個步驟歪掉後，後面的所有行動通通都歪掉了。
所以我在跟 AI 講完我想做的目標後，我會請他寫個文件記錄他接下來要做的行動，以及我許願的目標怎麼樣才算是完成。在這邊 BDD 就派上用場了，我會請他拆解每個目標要完成的行為，並且透過測試來約定這些行為怎麼樣才算是被滿足了。
有些人可能沒聽過 BDD 這個概念，簡單來說就是用測試來描述程式碼的行為。透過 BDD 我們可以讓 AI 自己去寫測試驗收他所實作的行為，並且在生成要測試的項目時，我們對於要 AI 實作的程式碼會有更具體的規範，更不容易讓 AI 走歪。
如果對 BDD 這類的文章有興趣，也可以到 一起來跑 TDD，直到完成 User Story 為止、軟體測試 101 這兩篇文章來逛逛，我有寫更多我對這類測試的理解跟想法。
不過在我個人的經驗而言，AI 生成測試、實作之後還是會需要調整不少東西，通常我會先從測試方向有沒有寫對開始，調整後通常 AI 也就知道實作上需要調整哪些地方了。
後記
當然有時候 AI 就是很腦，自己來實作程式碼比較快、甚至寫 prompt 都不一定有寫 code 快。
但我認為在接下來的幾年，絕對會逐漸切換為 AI driven 的時代，打個比方：在縫紉機剛出現的時候，可能紡織工會覺得自己動手還比較快、比較有品質，但是一旦學會使用紡織機，可能生產的效率會是手工的十倍、百倍。我在想：會不會以後手工寫程式可能會更像是一種自我娛樂，工程師想活動腦筋骨的時候才會自己來寫個程式？
所以我們就算不想會也得練習這塊方面的技巧。