AI 開發時代的平台工程

為原型提供進入正式環境的途徑

人們可以用不同 AI 工具探索想法，同時由組織提供共同的正式環境交付途徑。平台團隊讓這條途徑明確、受到支援，而且可以重複使用。

對有用的原型，蒐集使用者任務、範例流程、可取得的原始碼，以及預定處理的資料。評估要改寫現有程式碼，還是依探索所得的需求重建。使用正式環境存取憑證或機密輸入前，依必要控制措施驗證應用程式、開發工具和執行環境。

服務若必須在自己的基礎架構執行，就提供受支援的部署方式，放入自己的雲端帳戶或網路。納入身分、機密值處理、發布證據、監控和復原。另行審查模型資料流；擁有執行環境，不代表控制了每項開發服務。

將平台視為服務使用者的產品

平台提供受支援能力，讓團隊建置與維運軟體，例如身分、環境、交付管線、資料庫、監控和政策檢查。真正有用的單位，是滿足重複需求的完整工作流程。

CNCF 將平台描述為圍繞內部使用者設計的能力，具有一致介面，並在適當情況下提供自助服務。入口網站可以呈現這些能力，但入口網站本身不等於平台。CNCF 平台白皮書。

從真實需求開始。以虛構公司為例，多個團隊需要具備員工登入和代管資料庫的內部網頁服務。先為這項需求建立受支援途徑，再考慮大量很少使用的功能。

將代理程式也視為平台使用者

AI 代理程式可以快速生成基礎架構程式碼。但若缺少最新平台上下文，也可能選擇不受支援的區域、身分模式或部署方法。生成速度更快，無法補上缺少的組織限制。

提供可靠介面給代理程式。定義輸入、允許值、輸出和失敗行為。提供符合已安裝版本的範例。回傳能引導處理的錯誤資訊，但不暴露機密值。對人員與代理程式的呼叫，套用相同授權檢查。

對內部服務而言，請求可以指出負責人、資料類別、環境、復原要求和受支援執行環境。平台便能選擇已審查設定，或解釋為何請求需要另外決定。

定義受支援途徑與限制

這只是責任分工範例。與實際團隊和提供者確認。沒有人承擔的責任，不會因平台存在就消失。

公布預設方案以外要求的例外處理途徑，指出決策負責人與所需證據。例外處理若太困難，可能促使團隊在平台之外建立不受支援的系統。

建立服務後，持續維護

範本只是起始版本，不會自動修補用它建立的應用程式。決定平台變更如何傳遞到現有服務，以及如何檢查相容性。

為共用介面與模組保留版本。公布移除條件，並在必要時提供受支援的移轉方式。需要安全修補時，追蹤哪些服務仍使用受影響版本。

避免讓平台團隊成為每項例行操作都要排隊等待的人工核准關卡。自動執行可重複的檢查，將人工決策留給後果尚未釐清的事項。衡量成功使用情形、等待時間、復原結果和維護投入。

連結平台與軟體工廠

平台工程定義受支援能力和維運邊界。軟體工廠則連結需求、規劃、實作、證據與交付。當工廠依實際平台規劃工作，兩者可以互補。

評估時納入持續維運。確認誰負責掃描軟體是否出現新弱點、部署修補、處理事件，以及維護法遵證據。這些能力需要約定範圍和負責人；「軟體工廠」這個名稱並不保證具備它們。

在具體環節評估整合：生成的變更能否使用現有部署途徑，並保留原有控制？團隊能否檢查為何需要例外？平台改變時，由誰更新共用上下文？

DORA 的研究將 AI 能力放在組織環境中檢視。用這個觀點評估完整流程，包括仍由平台團隊承擔的工作。DORA 2025 報告。