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

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

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

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

上一篇把平台差異拆開之後，馬上出現另一個問題。

有一份「共用工具的完整指令表」，兩個平台其實都要用到，只是各自的使用情境略有不同。如果各自複製一份到自己的平台文件裡，很快就會出現兩份文件內容微妙地不一致——A 平台更新了指令表，B 平台卻沒跟著更新，這種雙份真相是最容易被忽略、卻也最容易誤導人的錯誤來源。

我們的做法是：把這份共同的參考資料抽成一份獨立的共用 knowledge，平台專屬文件只保留「跟這個平台有關的差異與注意事項」，並且明確引用共用資料。

knowledge/
├── device-common-commands.md      共用指令表，只維護一份
├── device-platforms/platform-a/README.md   引用共用指令表 + Linux 平台差異
└── device-platforms/platform-b/README.md   引用共用指令表 + Windows 平台差異

我們也順手把檔名改成能一眼看出適用範圍的形式（例如帶有平台代稱的檔名），讓使用者不用點開文件內容，光看檔名就知道這份文件是共用的還是專屬某平台的。

這裡建立了一個要長期維護的原則：相同內容只保留一份；平台差異要明確命名；所有 router、manifest、以及交叉引用的連結，都要一起更新，不能只改其中一邊。 這條原則說起來簡單，但真正能落實，靠的是每次修改共用資料時，都養成「順手檢查有沒有其他地方在引用它」的習慣。

這加起來其實就一句話：相同內容只保留一份；平台差異要明確命名；引用端要一起更新。

內容整理到這裡，規則本身已經累積得相當可觀，接下來自然會冒出一個問題：這麼多文件、這麼多連結關係，要怎麼確保它們彼此之間沒有壞掉？

下一篇來聊怎麼讓這套「作業說明」被機器檢查。