「凡事求個圓」- AI 助手開發的閉環實踐

2025-08-30

為什麼開發流程總是卡在人工介入？

最近在思考一個問題：為什麼我們用 AI 助手開發程式時，明明 AI 可以快速產生各種 script 和 command，但整個開發流程還是很痛苦？

我認為可能是因為開發流程不是「閉環」的。所謂閉環就是整個流程能夠自己產生反饋，不需要外部介入就能持續運轉。相反地，非閉環的流程中間有斷點，需要人工介入來「橋接」，這樣 AI 就無法獨立完成整個循環。但如果能讓所有環節形成閉環，AI 就能真正自動化開發了。

非閉環的痛苦：人類成為開發瓶頸

我主要在開發日常維運應用的工具，在 Windows 環境上執行維運需要的指令。大部分是撰寫 PowerShell script，不管是取得裝置的狀態、查看 event log，還是設定排程之類各式各樣的腳本或是臨時需求的 command。

但這裡有個環境限制：工作機主要是 MacOS 環境，使用 AI 助手為 Claude Code。並沒有 Windows 為主的開發環境，但是有可以測試用的 VM 或是 UAT 用的機器。

這就造成了一個典型的「非閉環」流程：

需要檢視過去兩天 event log 是不是有應用程式的 crash report。你把這個問題去問 AI 助手，他會很快地給你答案，但是你必須要連上目標的機器，並且打開視窗，然後下指令或檢視結果，再想辦法把結果複製到你要的地方。

這只是描述其中的一次排查問題的其中一個流程。但問題並不是每次都如此順利，可以下一個指令就解決了。所以一天中會反復這件事情非常多次。

更複雜的是，由於不希望中斷裝置原本的功能，我們就得要在背景實作這件事情。讓我們可能會依賴 WinRM 遠端執行，通常是使用 Ansible + WinRM 的方式來向 Windows 裝置下指令。

因為中間會經過人工的複製來傳遞結果以及情境給 AI 助手使用，所以在這個流程裡面「最大的瓶頸就是人類的勞動行為」。

第一次嘗試：還是沒有形成真正的「圓」

所以為了解決這個問題，我想要有一個服務，他是一個簡單的 HTTP 服務，他介於 AI 助手跟目標環境中間。運作起來有一點像 ngrok，但有差別的部分是 ngrok agent 是放在開發者這一端，我們的 client 是放在目標機器上，他會聽遠端的指令來執行。

已經實作了一個基礎的雛形，使用上也沒什麼問題。

在第一版的雛型裡，大部分是用 AI 來產生程式實作的。利用 BDD 的風格來實作，先寫了使用者情境，再把它轉成 BDD Gherkin feature file，接著使用 pytest-bdd 實作驗證的細節，透過 TDD red/green/refactoring 的循環，完成了 HTTP service 部分。

在這裡練習了快速產生出情境與有條理的實作規範，HTTP service 的部分實作上是有滿足使用的。但最後一哩路的部分，讓我覺得痛苦。主要是沒有一個好用的 Windows 開發環境。雖然有了基本雛型後，可以用這樣的服務把要寫的 PowerShell client 放上 Windows 去修改，再回傳回來。

但是敏銳的你應該知道了，這個拿回來部署的動作，需要人工介入。於是我這個人類又成為了開發的瓶頸。在這辛苦的流程中，我終於又完成了一個可用的版本，並且在實務情環使用了一週左右。東西可用，但由於不完全的自動化開發流程，讓我對於要再改善它的心情受到了影響。

體悟與重寫：從 AI 陪伴到 AI 自動化

雖然開發上有些挫折，但優點是其實不太費力。所以，心理想著也許能用現有的經驗再重寫看看。

也許你好奇為什麼又是重寫而不是改寫舊的東西呢？主要理由是我學習新事物的習慣，特別是一個較新的領域，常常會在看到並明白知道階段性的終點後，去理解最後的舒適狀態，並且不太完全 follow 課程內容，試著重複從無到有自己發展看看。像 AI x BDD 工作坊對我來說就是值得這麼練習的內容。

我在實作這專案的初衷也是練習在 AI 輔助下進行 BDD 開發與打磨個人開發流程的 prompt 工具包而來，只是我偏好實作極有可能用到的工具，特別是能直接改善自己日常工作體驗是最好的。

重新再一次，知道先前的缺點，並設法改善或是避免落入同樣的困境。一次一次反復寫著，如同遊戲的 RTA 一樣的有趣。

最新的一次重寫，需要回顧一些體悟。這是過去我分享過的使用 AI 輔助開發的思路轉折（AI + BDD: AI 陪伴轉向 AI 自動化），最終我推論出的想法是，要由 AI 陪伴轉向 AI 自動化的關鍵是 Context 自動補習，而不是人工介入 Context 轉移。

因此，新的開發大力引用了這個想法，同時外加：專案內容如果是外部相依的，那開發的重點反而是 E2E 為主。雖然 BDD 與 TDD 協同開發，可以兼顧軟體的外部品質與內部品質，但缺少了真實情環的 E2E，那最終的品質是無法保證的。所以 BDD / TDD 的測試金字塔選擇要直接用 E2E 切入。

真正的「圓」：Context 閉環設計

清楚目標後，我們剩下要處理的就是怎麼自動補完 context。AI 開發助手需要知道各 component 狀態與細節：

server
client
目前實作的 code

整個流程大致上是這樣：

AI 啟動開發環境 → 啟動 HTTP 服務 → Client 連接並等待指令
AI 發送請求 → 透過 HTTP 服務傳遞 → Client 執行並回傳結果

只是除了 AI 本身在控場之外，其後的各流程都是需要被修改並重新部署與重啟動的。

對於 client 端來說，重新 deploy 的問題其實就是有人得去目標裝置執行：

iwr http://the-tunnel-service:5566/client.ps1 -UseBasicParsing | iex

這一個簡單的指令，從最初版開始就是這麼設計的。它內部是一個簡單的 polling 詢問 server 有沒有下一個 command。在先前開發的困擾就是 client.ps1 可能因為語法錯誤或 send request 失敗導致對 server 已讀不回，就需要人工介入了。

保姆 Loop 的設計巧思

在最新版本的設計，我們用一個簡單的保姆 loop 處理它，不讓 client 直接啟動 client.ps1，而是只提供最外層的 loop 並且保持 loop 最簡單能最大相容各種執行情境。

由於 loop 不是直接負擔 feature，就算不特別提醒 AI 也不會去修改它，這樣責任區域就很明顯了。AI 修改的是 client.ps1，並且設定 client.ps1 變成「單步」執行，取一個 command 執行後結束，或是 10 秒內沒收到 command 就正常結束，當然也可能是 exception 而結束。

這樣設計的優點是 loop 站在旁觀的角色，監看全程。我們只要再包一個 log 記錄就能滿足補完 context 與自動部署的要求：

try {
  Start-Transcript -Path "C:\Temp\demo.log" -Append

  # run main command consumer
  iwr http://the-tunnel-service:5566/client.ps1?single_run=true -UseBasicParsing | iex
}
finally {
  Stop-Transcript
  # Upload log to server
}

完整的 Context 閉環

簡單的說，它就是一個 context 閉環，所有的情境都能回到 AI 助手上，或 AI 助手可以透過 server 獲得無法直接取得的 context。

閉環架構圖

整個閉環是這樣運作的：

開發端（左側）：

AI 透過 FastAPI dev 開發介面進行程式修改
HTTP server 作為中繼站，管理 command queue

執行端（右側）：

HTTP client 從 server 取得指令
PowerShell 執行實際的維運任務
Loop 負責監控和重啟，確保系統穩定運行

閉環的關鍵：

Command queue 確保指令不會丟失
Dev log 自動回傳執行結果給 AI
透過 ngrok / tailscale 打通網路障礙
Loop 設計讓系統具備自我恢復能力

這樣 AI 不再需要等待人工複製貼上，執行結果自動回饋，Client 掛掉也不怕 Loop 會重啟，整個開發過程變成 AI 可控的閉環。

「凡事求個圓」開發法

這就是我總結的「凡事求個圓」開發法（閉環）。

非閉環的痛苦：AI → 產生程式 → 人工複製 → 人工部署 → 人工執行 → 人工複製結果 → AI

閉環的美好：AI → 修改程式 → 自動部署 → 自動執行 → 自動回傳 Log → AI

這個「圓」讓 AI 真正變成了一個可以獨立工作的開發者，而不只是程式碼產生器。任何問題都能回到起點重新處理，沒有斷點，沒有需要人工介入的地方，AI 能夠持續迭代，不會卡在某個環節。

當你發現開發流程中有人工介入的環節時，不妨問問自己：能不能「求個圓」？