前面幾篇已知充分了解「流程有 Skill、經驗有知識庫、規則有把關」等等了
不過 AI 終究是我們在工作時的一種工具，它能大大加速流程，但終究能有效判定是否真的正確的還是在於「人」本身
也能回顧到第一天的內容
我最怕的就是團隊變成
A：「這個 Bug 是什麼原因？」
B：「AI 說是快取沒清。」
A：「好，那就這樣寫進報告吧。」「好，那就直接 merge PR 吧。」
Skill 裡放的是什麼？
知識庫裡放的是什麼？
前面幾天做的事情，本質上就是把「人腦裡的東西」搬到「AI 讀得到的地方」。
問題是：搬過去的東西，如果「一開始」就是錯的呢？
某某功能的規格，PM/RD/QA 全部人都看過規格了，都表示沒問題，就開始著手開發了
此時
這份案例跟規格一起被放進知識庫。
現在讓 Skill 跑一次排查：完全吻合
結論是團隊成員們都高信心的：沒有問題！
但殊不知，其實漏掉了一個特殊的邊界條件，但沒有人想到，導致上線後用戶反映了相關問題
但這種事情在軟體開發過程中幾乎可以說是是層出不窮的，在尚未有 AI 之前是如此，有了 AI 也仍會如此
因為「多個來源互相印證」是判斷可信度最重要的訊號之一
沒錯！聰明的做法！
同時
QA 的職責本來就不只是照規格寫案例，查看規格功能的合理性、看設計圖有沒有漏掉流程或不合理的操作等等，這些本來就在範圍內。
所以交給 AI 審查規格通常能看出：
| AI 審得出來 | 原因 |
|---|---|
| 規格自我矛盾 | 前後兩段互相打架，文件裡就看得到 |
| 邊界條件沒列完 | 條件列舉不完整，比對得出來 |
| 描述含糊、有多種解讀 | 語意本身就模糊 |
| 跟其他規格衝突 | 兩份文件擺在一起就對得出來 |
這幾類現在都值得讓 AI 先掃一遍，省下很多時間。
但因為有一類， AI 可能掃不出來：
這份描述的行為本身就不該是這樣的規格。
舉個例子：規格寫「訂單取消後退款 80%」。
這句話完整、明確、沒有矛盾、沒有漏掉邊界。AI 從文件本身找不到任何問題。
但 80% 本身到底對不對？
那要看當初跟客戶談的合約、看法務怎麼認定、看那場會議上到底決定了什麼。
這些東西往往不在文件裡，它們在文件產生更之前。
一句話：AI 可以審規格寫得好不好、但審不了規格本身對不對。
就算 AI 真的標出了一個疑點，事情也還沒結束。
它說「這個邊界條件好像沒有處理」，這句話至少有三種可能：
第三種往往最麻煩
因為它在文件上看起來就是個瑕疵，實際上卻是個決定——而且是一個還沒結束的決定，正在等真實數據回來。
這件事在敏捷團隊裡會更明顯。
敏捷的初衷本來就是快速迭代、擁抱變化。
沒有人會刻意設計一個 bug 給用戶，規劃的時候一定都是朝著 100 分走。
但當團隊需要讓用戶盡快使用到東西，就只能拆階段上線
例如：先做出一個 70 分的版本滿足需求，剩下的後續再迭代。
這種版本上線之後，規格上看起來就會有一堆「怎麼沒處理」的地方。
而且下一步更麻煩：用戶反饋回來之後，原本規劃剩餘的那 30 分，很可能整個要重想。
這時候規格要改、測試案例要改、知識庫也要跟著改。
此時團隊心情肯定是XD：
也就是說，知識庫的內容不只「可能一開始就寫錯」，它還會因為現實往前走而過期
要分辨這些，還是得回去問那個做決定的人。
前面講的都是「該寫的沒寫」或「寫了但寫錯」。
還有一種情況是：它不能寫。
跟客戶談的合約條件、法務對某個條款的認定、某個定價背後的商業考量、用戶個人資料
這些內容本身就有機敏性，不會、也不該被丟進一個團隊裡所有人跟 AI 都讀得到的地方。
之前講過機敏憑證不能進 context，這是同一個道理，只是範圍更大：不是所有「有助於判斷的資訊」，都適合被存起來。
可能就出現一種現象是知識庫會是有 刻意留白。
而留白的地方，往往正好就是「這個決定為什麼會長這樣」的答案。
Skill、知識庫、再強的模型，做的事情其實都一樣：把人已經寫下來的東西，用得更快、用得更廣、讓學習曲線變得更更低。
但這也是我們為什麼要一直保持舉一反三的學習心態
因為餵給 AI 的東西，源頭終究是人
AI 能加速的是判斷的過程，但不是判斷的來源。
這也是我覺得現在 AI 造就了很多人非工程領域的人也能成為開發者，開發一個 Web/APP 上架給大家使用
但真正要能夠長期迭代、有效維護、資安、如何行銷等等問題，都還是少不了真正的專業度人員，這些經驗、判斷力就是仰賴在最源頭的！
也許五年、十年後，AI 變得更加厲害，上述的問題都有辦法被解決，畢竟 AI 成長速度實在太快。
iThome鐵人賽
看影片追技術