剛開始把 AI 放進 Kubernetes 的工作流程時，我最常遇到的問題不是它不會寫 YAML，而是它太容易只看眼前那一份 YAML。它可以很快補出一個 Deployment，卻不一定知道這個服務要不要經過 Argo CD、它的 Secret 從哪裡來，或是公開入口還少了叢集外的設定。
後來我沒有再把需求和幾段設定直接貼進對話，而是讓 AI 從 GitOps repository 開始讀。那個 repository 本來就是我維護叢集的地方；裡面的目錄、README 和設定檔，剛好也能讓 AI 補上我平常放在腦中的脈絡。
我先給 AI 一張地圖
我的 repository 不追求複雜的抽象，重點是讓人能從入口一路找到部署內容：
gitops/
├── bootstrap/ # 初始安裝時才需要的東西
├── clusters/apps/ # Argo CD Applications
├── apps/ # 各服務的 manifests 與 values
├── terraform/ # 叢集外的雲端資源
└── docs/ # 架構與操作筆記
有了這張地圖，「新增一個服務」就不再只是多一個 Deployment。AI 可以先找出這個服務會碰到的 Application、Kustomization、values、Secret reference 和 Terraform，而不是猜一份看起來合理、實際上接不起來的設定。
例如 root Application 的用途很單純：它指向 Git 裡管理子 Application 的目錄。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: platform-root
namespace: argocd
spec:
source:
repoURL: <git-repository-ssh-url>
targetRevision: main
path: clusters/apps
destination:
server: https://kubernetes.default.svc
namespace: argocd
syncPolicy:
automated:
prune: true
selfHeal: true
每次修改前，先讓它說回來
我現在不會一開始就要求 AI 改檔案。先請它讀相關目錄，然後用自己的話說明：目前怎麼部署、這次會影響哪些檔案、缺少什麼依賴，以及驗證要看哪裡。
這一步很像跟同事確認理解。回答如果只提到 application YAML，卻完全沒提到 Argo CD 或外部 IaC，我就知道它還沒讀完整。相反地，若它能把 Git 裡的期望狀態和需要從叢集確認的事實分開，我才會繼續討論修改。
我常用的工作指令很短：
閱讀與這個需求有關的 IaC、Argo CD Application、Kustomization 和文件。
先告訴我目前設計、受影響檔案、依賴關係、風險與驗證步驟。
不要讀取或要求 Secret 值、私鑰、token、IP、內部網域或 Vault 路徑。
在我確認前，不修改檔案，也不對叢集做任何操作。
這比一句「幫我部署服務」慢一點，但能少掉很多來回。更重要的是，計畫本身會留下來，之後 review diff 時也能回頭檢查原本的假設有沒有成立。
Argo CD 讓依賴關係有地方可看
有些東西不能一起上。CRD 和 operator 得先存在，引用它們的資源才有意義；提供 Secret 的流程沒準備好，應用程式即使 YAML 正確也起不來。這些關係不是靠我在 prompt 裡反覆提醒，而是寫在 Argo CD Applications 的分層與同步順序裡。
因此，AI 讀到的不只是「叢集用了哪些元件」，還包括它們大致如何接在一起。當它建議修改某個服務時，我會要求它說明：這是純粹的 application change，還是會碰到入口、機密交付或叢集外的資源？不同答案，檢查方式也不同。
Secret 的範例也只停在引用層。這足以說明工作負載依賴哪一個 Secret，而不會洩漏任何值：
envFrom:
- secretRef:
name: app-runtime-secrets
Git 裡的預期，和叢集裡的事實
AI 可以幫我閱讀設定、比較 diff、render Kustomize，也可以把驗證步驟整理好；但它不需要因而擁有管理員權限。我把「看 repository」和「看 live cluster」分開。
Repository 這一側回答的是：我希望系統長什麼樣子。需要看叢集時，我只提供唯讀、範圍有限的觀測能力，例如 Application 是否同步、rollout 是否完成、事件裡是否出現錯誤，以及 service 是否有可用 endpoint。它看得到問題的輪廓，卻不能任意執行 shell、讀取 Secret、進 Pod 或 restart workload。
這個限制反而讓除錯更有條理。它可以先指出「Git 中的版本已更新，但 rollout 還沒 ready」，我再決定要不要做下一步的人工處置。任何持久性的修改仍然先回到 Git，經過 review 後交給 Argo CD 收斂。
寫文章是最後一步，不是另一份猜測
一次修改完成後，AI 還能幫我把工作過程整理成文章。這時它已經看過實際的檔案結構、修改 diff 和驗證結果，所以可以先列出背景、改動原因、實作順序和踩過的坑。我再把不適合公開的部分拿掉，確認文章沒有把一次性的排障指令寫成通用做法。
我很喜歡這個順序：先做出能被 Git 和 Argo CD 驗證的改動，再回頭寫它。文章不再是靠記憶拼湊的 Kubernetes 教學，而是一次真實維運工作的整理。
AI 在這裡比較像熟悉 repository 的協作者，而不是叢集的權威。它幫我少花時間在檔案間切換，也提醒我漏掉的依賴；真正的變更依然有 source of truth、review 和安全邊界。這樣用起來，我才敢讓它參與日常的 infrastructure 工作。