系列：「一人艦隊：用一群 AI CLI 打造跨平台代理 mesh」— 第 28 篇
紀錄日期：2026-09-21

本機工作草稿，尚未貼到網站。篇次是素材順序，不代表又過了一個日曆日。本篇新增的是測試工具與實際執行證據，沒有完成產品自動開發或部署。

今天的一件事

上一篇確認讓 Spectyn 參與自己的開發，也讓其他 CLI 能檢查與接手。今天真的回到程式，但第一個小任務不是再寫一個總控器，而是確認現有 CLI 值不值得被放進開發迴圈。

我想要的迴圈是：小任務與驗收條件 → 隔離開發 → 測試 → 外部審查與 eval → 候選版 → 測試部署 → 授權範圍內升級或回滾 → 回寫學習。現在先完成最前面可驗證的一小段。

沿用現有入口

程式已經有 spectyn exec --json、指定 session 與 --continue；也有 TaskStore 和 task events。沒有理由在旁邊再建立另一套任務真相。

這次從正在工作的原始碼建置 core/target/debug/spectyn，沒有使用較舊的已安裝執行檔。cargo build --locked --offline --bin spectyn 成功，既有警告仍在。來源是包含先前修改的 worktree，因此不能稱為乾淨 HEAD 的發行品；binary 與測試工具的 SHA-256 都留在證據裡。

寫一支能留下證據的測試工具

新增 scripts/audit/selfdev-cli-characterize.py，只用 Python 標準函式庫。它啟動本機固定回應服務，再呼叫真實 Spectyn 執行檔。設定單一 provider、工具清單為空，用獨立的 SPECTYN_HOME 與工作目錄保存資料，每次輸出目錄不得覆寫。

這裡的固定回應服務不是真正模型。它的用途是把模型波動拿開，單獨看 CLI 傳輸、退出狀態與對話保存。

另外驗證所有請求沒有工具呼叫欄位。這是四個情境加一個共同條件，不能算成五次自主開發成功。

接續測試有個重要細節：固定回應服務只有在新請求真的帶回舊標記時，才回傳正確答案。若服務自己永遠記得答案，即使 Spectyn 沒載入歷史也會假通過。

Spectyn 真的分析了自己的程式碼，但答錯了

接著改用本機已安裝的 Ollama qwen2.5-coder:7b，讓 Spectyn 閱讀一段自己的事件處理程式。這次是真模型，工具仍關閉，沒有修改程式。

約 37.7 秒後，程序 exit 0，也產生完整回答。但程式在 JSON 或 quiet 模式提早 return，後面的工具成功／拒絕計數根本不會執行。模型沒有指出這個差異，還給了引用未綁定變數的片段。

所以這一筆要記兩個結果：執行成功，分析品質失敗。不能因為回了程式碼就直接套用。目前已確認來源中的控制流程，尚未用 denied-tool 端到端案例重現實際退出狀態；兩者也要分開記。

其他 CLI 也需要被查核

Codex 負責整合；OpenCode 協助找入口；agy 提出隔離、接續與中斷的設計風險；Claude Code 與 agy 審查最終測試工具，兩者都給 APPROVE。

但 OpenCode 曾誤判一個實際存在的測試目錄不存在。審查中的「沒有越界」說法也不能當成安全證明：SPECTYN_HOME 和 cwd 是設定隔離，不是 OS sandbox。清理例外時證據可能不完整，以及失敗後沒有獨立保存會話快照，都是目前保留的限制。

這輪使用了專案的 local-ai skill：.claude/skills/local-ai/SKILL.md。多個 CLI 的角色是提供可以檢查的證據與意見，不是靠票數決定真相。

留給下一輪的具體小任務

先建立普通、--json、--quiet 三種模式對同一 denied-tool 情境的重現，再提出最小修正與驗收映射。通過測試與非作者審查後，才往候選版推進。

RC-071 仍是 draft-candidate；本輪沒有把它改成產品實作核准。規定的 PowerShell release-contract 檢查因缺少 pwsh 記為 NOT_RUN。原始資料在專案 docs/specs/demo-monday-mesh/reports/evidence/m5/2026-09-21-selfdev-cli/，包含測試輸出、模型回答、審查、建置紀錄與來源雜湊。

今天還沒有自動接手、部署或升級。但已經有第一個能由另一個 CLI 直接閱讀與重新執行的小任務，也留下了一次不能被包裝成成功的模型失敗。