Latest / 創意每天聽 / 程式上線前先考你？反直覺機制強化AI開發品質管理

Transcript

程式上線前先考你？反直覺機制強化AI開發品質管理 · 創意每天聽

• 0:00
  今天想聊一個很有意思的工具，叫做 Sphinx。它是一個很特別的程式碼檢查機制。
• 0:10
  怎麼說特別？不就是程式碼審核嗎？現在很多公司都有 Code Review 啊。
• 0:20
  其實你可能沒想到的是，這個工具不是讓別人來審核，而是要求開發者在部署 AI 程式碼之前，先「自我測驗」一下，確保自己真的理解這段程式碼的功能。
• 0:38
  等等，開發者寫的程式碼，他自己會不理解嗎？這不是很奇怪嗎？而且還要「測驗」，這不會拖慢開發進度嗎？感覺成本很高。
• 0:52
  這就是它的出乎意料之處。原文有提到，這主要是針對「agent-assisted development」，就是那種有 AI 輔助寫程式的情況。現在 AI 寫程式越來越普遍了嘛。
• 1:14
  嗯，AI 幫忙寫程式，開發者再檢查一下，應該很快吧。為什麼還需要一個額外的測驗步驟？
• 1:25
  因為 AI 幫忙寫出來的程式碼，有時候開發者可能只是稍微調整，或者沒有完全搞懂每個細節。Sphinx 會在你 push 程式碼到正式環境之前，給你出一個問題。
• 1:45
  出問題？具體會問什麼？會不會問一些很基礎的東西，那不是浪費時間嗎？
• 1:54
  像原文舉例，它會問：「你的 webhook handler 現在在呼叫 `charge()` 之前會先儲存 event ID。如果 Stripe 超時又發送同一個事件，會發生什麼事？」
• 2:17
  哦，聽起來是比較實務、針對潛在錯誤情境的問題。那如果答錯了怎麼辦？
• 2:26
  答錯了，它會解釋錯在哪裡，然後讓你嘗試新的情境，直到你答對了才能繼續推送。這個工具會連接你的 Git 和 coding agent，還可以讓你選擇哪個模型來審核。
• 2:46
  所以它有點像一個自動化的「老師」？那這樣每次 push 都要考一次，效率會不會很低？開發者會不會覺得很煩？
• 3:00
  其實開發者也不是完全沒有變通的選項。原文有提到，如果你真的非常趕時間，可以輸入 `sphinx yolo`，它就會讓你跳過測驗直接推送。但每次跳過都會被記錄下來。
• 3:20
  這樣做的目的，就是讓開發者對 AI 寫的程式碼有更深的理解，避免因為不理解而產生的錯誤。那對於一般中小企業或創業者來說，能學到什麼？
• 3:37
  我覺得，這給了我們一個關於「品質控管」和「人員訓練」的新思路。即使我們引入了高度自動化或 AI，人的理解和掌控仍然是關鍵。
• 3:53
  怎麼把這個概念應用到我的小店？我又沒有 AI 寫程式。
• 4:00
  比如說，如果你店裡引進了一套新的 POS 系統或自動點餐機。在員工正式使用前，你可以設計一些小測驗，確保他們真的理解在異常情況下，系統會怎麼反應。
• 4:18
  嗯，這確實是一個好點子。比如點餐機故障、客人重複點餐、或是結帳錯誤時，員工知道怎麼處理，而不是只會照 SOP 走。這比只是口頭訓練有效率。
• 4:36
  對。很多時候 SOP 寫得很清楚，但員工不一定真的理解背後的邏輯。這個「自我測驗」的機制，能把「理解」這件事前置化。
• 4:51
  那一般上班族呢？這個概念怎麼帶入自己的工作？
• 4:57
  像我們處理一些例行性報表，或者使用新的軟體工具。在使用前，可以試著自己想像幾個「如果發生了什麼，系統會怎麼反應」的問題，自己問自己，而不是只是一味操作。
• 5:16
  我想到一個情境。如果我是一個負責行銷的，我會要求自己在發佈一個自動化行銷活動之前，先自己設想幾個用戶可能遇到的問題，然後去檢查我的設定能不能妥善處理。
• 5:35
  沒錯，這就能避免很多因為不理解而造成的潛在風險。畢竟，你可以外包思考，但不能外包理解。
• 5:46
  這麼說來，這個 Sphinx 的做法確實很有意思，它提醒我們在追求效率和自動化的同時，不要忘了「人」才是確保品質和控制風險的最終關卡。
• 6:03
  嗯，好像也提醒了我們，任何工具的導入，最終都要回歸到「人」有沒有真的掌握它。