前言：一句話交辦，半小時後拿到能跑的 Playbook？
「幫我把十台新節點裝好 kubelet、加進叢集，順便把舊版 Docker 清掉。」如果你在 CIM infra 維運現場，這句話每天都會出現。過去它要變成一支 Ansible Playbook，得有人查模組文件、寫 YAML、跑測試、修冪等性——至少半天起跳。現在 Agent 宣稱一句話就能生出來，問題只剩一個：生出來的東西，你敢不敢直接跑？
這篇文章不談「模型會不會寫 YAML」，談的是「怎麼讓它寫出來的東西值得信任」：ACL 2026 的評測數據先潑一盆冷水，Red Hat 的產品路線告訴你編輯器助手走到哪了，最後是一條可以今天就動手的驗證梯，和一段生成加驗證的迴路骨架。
一、先看數據：模型寫 Ansible，一次寫對的機率有多低
中佛羅里達大學（UCF）與奧本大學（Auburn）的團隊在 ACL 2026 發表了 ITAB（後續版本改名 ExITBench），第一個用「實際執行」評模型寫 Ansible 能力的評測。126 個任務來自真實的 Stack Overflow 提問，橫跨伺服器設定、網路、政策設定、模板、部署管線、變數管理、檔案管理七個領域。每個任務都要求狀態調和（state reconciliation）：Playbook 跑完後系統要到達指定狀態，而且再跑一次不能再有變更。
結果不太客氣。14 個開源模型裡，最好的 Qwen2.5-Coder-7B-it 在 pass@10 也只有 12.0%，多數模型的 pass@1 不到 4%。擴大到 17 個模型、納入專有模型的新版數據也好不到哪裡去：GPT-4.1-Mini 的 pass@10 最好，也只有 23.9%；Claude-3.5-Sonnet 的 pass@1 最好，但同樣遠稱不上可靠。
錯誤分類更有啟發性。分析 1,411 次執行失敗後，兩大類佔了近七成：狀態調和相關的推理失敗佔 44.87%——變數問題 11.43%、主機問題 11.84%、路徑問題 11.63%、模板問題 9.97%；模組執行知識不足佔 24.37%——屬性與參數錯誤 14.44%、模組選錯 9.93%。換句話說，模型不是輸在 YAML 語法，而是輸在「跑完之後系統應該是什麼狀態」這種維運人員習以為常的判斷上。模板與變數管理是最弱的兩個領域，正好是 Playbook 最常出錯的地方。
這組數字的實務意義只有一句話：不要用「模型寫得像不像」來驗收，要用「跑起來對不對」來驗收。評測標準從 BLEU 分數改成實際執行，是整個題目最關鍵的轉向。
二、編輯器助手走到哪了：Lightspeed 與 AAP 2.6
產品端走得比論文快。Red Hat 的 Ansible Lightspeed（現在改稱 automation coding assistant）最早接 IBM watsonx 的專用模型，現在 VS Code 擴充套件已經支援 Gemini 與 OpenAI 相容端點（透過 Red Hat AI），在編輯器裡用自然語言生成整支 Playbook 或 Role，生成後自動跑 lint 檢查。2026 年 8 月更新的官方實作 lab，走的就是這個流程：描述需求、生成、檢查、部署到兩台節點。
2026 年 10 月 30 日發布的 Ansible Automation Platform 2.6，把這條路再往前推了一步。VS Code 擴充套件不再自己帶模型，而是內建 MCP Server、可攜式 Agent Skills 與原生聊天整合，讓你自己的 AI 助手變成 Ansible 專家——知識來自你的實際工作區：已安裝的 collections、Python 環境、執行環境。平台 UI 裡也內嵌了一個 automation intelligent assistant 聊天介面。
重點是分工的變化。編輯器助手解決的是「寫得快」，它不負責「證明寫對了」。Lightspeed 會幫你 lint，但不會幫你跑 check mode、不會驗冪等性、更不會擋下你把明文密碼寫進 Playbook。寫得快但不敢跑，省下的半天會在除錯時連本帶利還回去。這就是為什麼需要下一節的驗證梯：生成是模型的活，驗證是管線的活，兩件事要分開。
三、驗證梯：五道關卡，便宜的先跑
如圖一，驗證梯的原則只有一個：便宜的檢查先跑，貴的檢查只留給已經通過前面關卡的候選者。KodeKloud 的實作整理把順序排得很清楚：
第一階：yamllint，毫秒級。 先確認 YAML 本身沒寫壞。縮排錯、冒號錯這種問題，不值得浪費模型一次重試。
第二階：ansible-playbook --syntax-check，秒級。 確認 Playbook 結構合法、引用的模組存在。這一步就能擋掉大量「看起來像 Ansible，其實不是」的輸出。
第三階：ansible-lint，秒級。 風格與最佳實務：完整集合名稱（FQCN）、不要用裸 shell、任務要有 name。這一步開始有「維運品味」的成分。
第四階：check mode 對真實 inventory，分鐘級。 用 --check 在測試環境跑一次，看它「打算」改什麼。這是第一次真正碰到目標系統的狀態。
第五階：Molecule，分鐘級。 在拋棄式環境完整跑一次 converge，再跑一次驗冪等性：第二次執行必須回報零變更。Molecule 預設的測試序列本來就把 idempotence 排在 converge 與 verify 之間，最難的那道關卡是現成的，不用自己搭。
五道關卡之外，還有三條確定性規則，不要用提示詞去「拜託」模型，直接寫死在管線裡：shell 任務沒有 changed_when 就拒收、沒有完整集合名稱就拒收、出現明文密碼就拒收。確定性閘門比提示詞可靠，因為它不依賴模型當天的心情。
最後一條是流程規則：Agent 的輸出是一份 pull request，不是直接套用到真實 inventory 的指令。生成速度值得要，生成自主權不值得要。
四、實作骨架：生成加驗證的迴路
如圖二，整個迴路可以濃縮成一個迴圈：生成、跑驗證梯、把失敗餵回去修、重試有上限、通過才產出 PR。骨架如下：
import subprocess
MAX_RETRIES = 3
GATES = [
["yamllint", "playbook.yml"],
["ansible-playbook", "--syntax-check", "playbook.yml"],
["ansible-lint", "playbook.yml"],
["ansible-playbook", "--check", "-i", "inventory/test", "playbook.yml"],
["molecule", "test"], # 內含 converge + idempotence
]
def run_gate(cmd: list[str]) -> tuple[bool, str]:
r = subprocess.run(cmd, capture_output=True, text=True)
return r.returncode == 0, (r.stdout + r.stderr)[-2000:]
def generate(prompt: str, feedback: str = "") -> str:
# 呼叫你的模型：系統提示詞寫死三條規則
# （FQCN、shell 須有 changed_when、禁止明文密碼），
# feedback 帶上上一輪驗證失敗的輸出。
...
def agent_write_playbook(request: str) -> str:
feedback = ""
for attempt in range(1, MAX_RETRIES + 1):
playbook = generate(request, feedback)
open("playbook.yml", "w").write(playbook)
for gate in GATES:
ok, output = run_gate(gate)
if not ok:
feedback = f"第 {attempt} 輪，{gate[0]} 失敗：\n{output}"
break
else:
return playbook # 全部通過，交出 PR
raise RuntimeError(f"{MAX_RETRIES} 輪都沒通過，轉人工處理")
幾個設計決策值得說明。第一，重試上限寫死三輪，超過就轉人工，不要讓模型無限自我修復下去燒 token。第二，失敗回饋只餵最後 2,000 字輸出，完整的 lint 報告模型也看不完，重點是失敗的那幾行。第三，驗證梯跑在拋棄式測試環境，Molecule 跑完就銷毀，髒狀態不會留到下一輪。第四，這支程式本身不碰真實 inventory——能動真實環境的只有人類合併 PR 之後的那一步。
五、給 Drydock 的落點：生成是新功能，驗證是舊底子
這個主題離 Dylan 的工作很近。Drydock 本來就是 Ansible 的圖形介面：選節點、編排操作、看執行結果。Agent 生成 Playbook 可以做成一條新管線：使用者在介面輸入一句話，Agent 生成草稿，Drydock 在沙箱把驗證梯跑完，通過的才變成一支可以排程的 Playbook，執行前照樣要人工確認。
這條管線幾乎不用新發明東西。驗證梯的五道關卡都是現成工具，Molecule 的冪等性檢查是內建的，Drydock 本來就有節點編排與執行紀錄。再疊加 11 月 8 日那篇的稽核做法：每次生成、每次驗證、每次執行都寫進稽核日誌，同一條雜湊鏈覆蓋，事後誰都能查「這支 Playbook 是誰生成的、通過了哪幾道關卡、誰批準執行的」。
上線順序建議反過來排：先把驗證梯與 PR 流程做起來，生成模型晚一點接也沒關係。驗證梯是確定性的，今天就能寫；生成模型的能力曲線還在爬，ACL 2026 的數據說它還沒準備好獨立上工。先有籠子，再放老虎。
我的看法
結論：先看。 讓 Agent 獨立寫 Playbook 並直接執行，現在還不到時候——ACL 2026 的數據擺在那裡，最好的專有模型十次裡也只有兩次多寫對，直接放行等於把維運的正確性交給一個四分之三機率會寫錯的助手。
為什麼是「先看」而不是「跳過」：驗證梯那一半已經能用了。yamllint、ansible-lint、check mode、Molecule 冪等性檢查全是現成工具，不依賴模型變強，今天就能搭起來。真正要等的只是生成那一半的正確率，而且等的方式不是乾等：先讓 Agent 在沙箱裡生成、驗證、產 PR，累積自己環境的通過率數據，通過率穩定過半再談放寬。
務實建議：這週先在 Drydock 補一條「生成到 PR」的管線，不接自動執行，生成模型先用現成的 Lightspeed 或 VS Code 擴充套件頂著。等內部評測跑一個月，看到 pass@1 的實際數字，再決定要不要把生成收進 Drydock 自己的迴路。籠子先蓋好，老虎慢慢養。
結論
Agent 寫 Ansible 最大的誤解，是以為難在「寫」。ACL 2026 的評測證明難在「寫對」，而且錯的地方正是維運老手最在意的地方：狀態調和、變數、模板、模組知識。Red Hat 把生成做進編輯器、把 MCP Server 與 Agent Skills 做進 AAP 2.6，解決的是寫得快的問題；寫得對不對，要靠另一條管線回答：五道驗證梯、確定性閘門、PR 而非直接執行。生成可以交給模型，證明必須留在自己手上。等到哪天模型的 pass@1 穩定過半，再來談放寬也不遲——在那之前，先把籠子蓋好。
來源
- UCF／Auburn 團隊，Large Language Models for IT Automation Tasks: Are We There Yet?（ACL 2026 錄取），ITAB／ExITBench：126 任務、pass@10 最高 12.0%（開源模型）／23.9%（GPT-4.1-Mini）、錯誤分類：https://arxiv.org/abs/2505.20505
- Red Hat Developers，Try the Ansible playbook generation lab with Gemini and OpenAI（2026-08-26）：https://developers.redhat.com/articles/2026/08/26/try-ansible-playbook-generation-lab-gemini-and-openai
- Red Hat Blog，Getting started with Red Hat Ansible Lightspeed with IBM watsonx Code Assistant（2026-10-20 更新）：https://www.redhat.com/en/blog/getting-started-red-hat-ansible-lightspeed-ibm-watsonx-code-assistant
- Red Hat，Ansible Automation Platform 2.6 文件（2026-10-30）：VS Code 擴充套件內建 MCP Server、Agent Skills、automation intelligent assistant：https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/pdfs/aap-discover-2-6-pdf.pdf
- KodeKloud，An AI Agent That Writes and Validates Ansible Playbooks（2026）：驗證梯、冪等性閘門、PR 流程：https://kodekloud.com/blog/building-an-ai-agent-that-writes-and-validates-ansible-playbooks/
