離線編程的技術架構與組件分工
該實驗採用 OpenCode 作為開源程式碼代理，負責讀取檔案、提出編輯建議並執行命令；Ollama 則負責在本地端運行模型服務。兩者透過本機位址（localhost）通訊，確保請求不經過外部網路。
模型選用 Qwen3.5 9B，因其為開放權重模型，允許下載參數並在本地推理。設定中明確禁用 Ollama 的雲端功能，並僅啟用本地供應商端點，以強制所有運算在斷網環境下進行。
模型選擇依據與公開基準數據
作者參考 Qwen 官方模型卡公布的 LiveCodeBench v6（程式碼生成）與 BFCL-V4（函數調用）分數，選擇了 9B 參數版本而非 4B 版本。Qwen3.5 9B 在兩項指標上的得分分別為 65.6 與 66.1，高於 4B 版本的 55.8 與 50.3。
需注意這些分數僅反映模型本身的理論能力，並非在特定筆記型電腦上的實際執行速度或離線工作流表現。另一款開放權重模型 gpt-oss-20b 雖在程式碼生成上得分較高（74.6），但其函數調用分數未公開報告。
記憶體需求與硬體限制
模型下載大小不等於執行時的記憶體需求。Qwen3.5 9B 的下載檔案約為 6.6–7.6 GB，但參考其他專案建議，運行此規模模型可能需要預算 12–16 GB 的記憶體。
實驗中設定的上下文長度為 64k tokens，這會進一步增加記憶體佔用。若同時開啟其他應用程式或處理大型專案，可用於模型的記憶體空間將受到壓縮，可能導致執行失敗或速度顯著下降。
離線修復 Bug 的實際操作流程
測試案例為一個計算開銷總額的 Python 腳本，原始程式碼錯誤地覆蓋了累加值而非累加。作者先在聯網狀態下確認 OpenCode 能正確讀取檔案並識別專案使用的 unittest 框架，隨後關閉 Wi-Fi 與乙太網路連線。
斷網後，透過 curl 指令驗證本地 Ollama API 仍可回應，而外部網址解析失敗，確認環境已完全離線。接著指示 AI 修復錯誤且不修改測試檔或安裝新套件。AI 提出將 `total = Decimal(amount)` 改為 `total += Decimal(amount)` 的一行修正，並請求執行權限。
AI 執行測試後顯示通過，作者隨後手動執行原始測試指令進行獨立驗證，確認五項測試全部通過且輸出結果正確。此過程顯示在嚴格限制下（不改測試、不裝套件），本地模型能完成簡單的邏輯錯誤修復。
提升離線工作流可靠性的建議
為避免 AI 產生不必要的副作用，應在提示詞中明確指定專案使用的測試命令（例如 `python3 -m unittest -v`），因為模型可能預設建議其他框架如 pytest。
任務範圍應保持聚焦且自包含，僅處理單一 Bug 修復或小功能開發，並保留原始測試檔案作為驗證標準。此外，需預先下載所有依賴套件與文件，因為離線環境無法動態獲取新資源。
