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

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

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

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

當團隊要支援的裝置平台從一種變成兩種，我們遇到了 EP22 提過的分界問題的真實案例。

例如一種是 Linux 式的 SSH 連線環境，另一種是 Windows 式的帳密互動環境：同一個知識主題，兩個平台的連線帳號、路徑慣例、服務管理方式、除錯工具的操作習慣完全不同。

一開始的做法是把兩個平台的內容寫進同一份文件裡，用「Linux 的話……、Windows 的話……」交錯說明。結果讀起來很快就變得又長又亂，AI 也容易讀到一半就把兩邊的細節搞混。

所以我們把知識拆成平台路由的形式：

knowledge/device-platforms/
├── README.md          共同入口，先選平台
├── platform-a/README.md   Linux 式裝置：SSH、路徑、服務管理
└── platform-b/README.md   Windows 式裝置：帳密登入、互動密碼

這次拆分保留了共同的概念（例如「服務要怎麼重啟」這個抽象問題本身），但拒絕把平台差異藏在一份模糊、需要讀者自己分辨「這句話是講哪個平台」的文件裡。

對 AI 而言，先選平台、再載入規則，遠比讀完一份混合文件後自行猜測「這個平台適不適用這條規則」要安全得多——猜錯的代價，可能是把 Linux 的服務管理指令套用到一台 Windows 裝置上。

這加起來其實就一句話：先選平台再載入規則，遠比讀完一份混合文件後自行猜測安全。

平台分開講清楚了，但共同的部分——例如兩個平台都會用到的某個共用工具的完整指令表——又該放在哪裡呢？

下一篇來聊「共用參考資料」該怎麼安放。