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

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

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

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

腳本越寫越多之後，我們開始明確要求每一支腳本都要符合幾個原則。

讓自動化不只是「少打幾個指令」，而是真正降低人為的遺漏與誤判：

1. Idempotent（可重複執行）：同一支腳本跑第二次，不應該產生跟第一次不一樣的意外結果。
2. 清楚的輸入輸出：不猜測參數的預設行為，該檢查的前置條件先檢查完再動手。
3. 敏感檔案清理：任務結束後，暫存的憑證、日誌要有明確的清除步驟。
4. 實際結果驗證：腳本回傳成功，不代表任務真的完成——要有一個步驟去確認「現實世界」真的變成預期的樣子。

# 一個符合上述原則的腳本骨架
param([string]$Target)

if (-not (Test-Connection $Target -Quiet)) {
    throw "目標不可連線，停止執行"
}

# 已存在的狀態要能被正確處理，而不是直接覆蓋或報錯中斷
if (Test-ExistingState $Target) {
    Write-Output "偵測到既有狀態，將以既定規則合併，而非覆蓋"
}

Invoke-Action $Target
Confirm-ActualState $Target   # 執行後一定要回頭確認實際狀態

這幾條原則聽起來像是老生常談，但真正被要求寫進每一支腳本之後，效果很明顯。

同一個流程再次執行時，工程師可以預期它會怎麼處理已存在的檔案、已經啟動的服務，或是上一次中途失敗留下的狀態——而不用每次都先手動確認「現在到底是乾淨的環境，還是有殘留」。

這加起來其實就一句話：腳本要可重複執行、輸入輸出清楚，並且用現實世界的狀態驗證，而不是只看成功碼。

單一腳本的可靠性有了，接下來要處理更複雜的情境：當一個操作需要好幾種能力接力完成時，該怎麼把它們串成一條完整的鏈？

下一篇來聊。