Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP16。

skill 剛寫出來的版本，往往只涵蓋「理想路徑」。

連線成功、指令照預期執行、裝置乖乖回應。但真實裝置從來不會只照理想路徑走，幾次現場部署之後，我們補回了好幾個重要的修正：

• 唯讀資源需要明確的暫時開放流程，操作完要有對應的收尾步驟，不能開了就不管。
• 裝置重新啟動後，不能假設一切恢復原狀——要重新確認服務、版本、連線狀態，才能判斷操作真的成功。
• 遠端連線的身分識別發生變動時（例如裝置韌體更新後），要有一套受控的重新信任流程，而不是讓 AI 自己想辦法繞過。

這三件事都不是一開始就寫進去的，而是現場出過狀況之後，才被補回流程裡。

這些教訓有一個共通點：它們都讓 skill 從只描述「理想路徑」，變成同時把「裝置重啟」、「連線身分變動」、「操作失敗後該怎麼確認現況」也寫進流程裡。

回頭看，這些修正幾乎都是先出過一次小狀況，才被寫進文件的——這其實也呼應了 EP08、EP09 提到的回顧與審查機制：現場的教訓，正是透過那套流程被沉澱回共用規則的。

這加起來其實就一句話：skill 的成熟度，不是看平常跑得多順，而是看意外發生時有沒有一條清楚的路可以走。

有了這些安全設計的教訓，下一篇來聊另一種累積知識的方式：把「症狀」整理成一張可以按圖索驥的分診表。