系列：「邊做邊補：用一個 AI 代理 mesh 專案，補齊 AI 工程師該有的能力」— 第 13 天
紀錄日期：2026-09-21
能力區：第 6 區 Coding Agent（兼第 9 區 評估、第 12 區 多 Agent 協作）｜類型：做

本機工作草稿，尚未貼到網站。這是一次測試工具實作與有限範圍的實驗；不因此調高能力地圖分數，也不宣稱已完成自主開發迴圈。

專案裡哪件事逼我用到

當 Spectyn 要參與自己的開發時，我需要知道它究竟完成了什麼。CLI 有回應、exit 0、甚至產生一段程式碼，都不足以回答這個問題。

這次練習把評估拆成兩層：第一層測系統是否照預期執行；第二層測模型產出是否真的解決任務。先將模型移出第一層，再放回第二層。

第一層：固定回應，測真實程序

我寫了一支 Python 工具，啟動本機 HTTP 固定回應服務，再用從目前原始碼建置的 Spectyn 執行檔呼叫它。沒有下載模型、接外部帳號或開啟工具。

每次跑四個情境：正常完成、跨程序接續、HTTP 400、請求進行中送 SIGTERM。驗收同時看 JSONL 事件、退出碼及對話檔，而不是只看 stdout 出現「成功」。四個情境這次都通過；請求沒有工具欄位的共同檢查也通過。

接續測試使用隨機標記。第二個程序發出 RECALL 時，服務必須在實際收到的歷史中找到標記，才會回傳答案。這讓測試能抓到「沒有載入歷史，卻因測試替身知道答案而通過」的錯誤。

中斷測試也不用固定睡幾秒猜時機。服務收到請求並記錄後，才通知測試程序送 SIGTERM。測到的是 POSIX 程序中斷，不是產品原生取消指令。

第二層：真模型，測分析是否正確

使用本機 Ollama qwen2.5-coder:7b，透過 Spectyn 分析 exec 的一段事件處理程式。題目要求說明計數行為、最小修正與回歸測試。

約 37.7 秒完成，exit 0。可是它忽略了 JSON 和 quiet 模式在計數前就 return，回答還說既有處理正確；建議片段也沒有綁定使用的變數。

這只代表這個模型與設定在這一題的結果。不能拿一題宣判整個產品，也不能用程序成功掩蓋任務失敗。

外部審查怎麼加入

OpenCode 找入口，agy 做風險分析，Claude Code 與 agy 審查測試工具，Codex 對照原始碼及輸出整合判斷。透過專案 local-ai skill 呼叫真實 CLI，沒有把同一份回答換個名字充當多方審查。

兩份審查都核可測試工具，但我仍保留已知限制：清理例外可能讓部分證據未寫完；目前缺少失敗後會話的獨立快照；設定目錄隔離不是 OS sandbox。審查也要經過事實核對，例如 OpenCode 的「目錄不存在」就被實際檔案推翻。

這次學到的能力

我開始能為不同問題選不同證據：固定服務適合重現執行流程，真模型適合檢查任務品質；退出碼代表程序契約，來源控制流程與任務驗收代表另一層正確性。

原始證據保存在 docs/specs/demo-monday-mesh/reports/evidence/m5/2026-09-21-selfdev-cli/。另一個 CLI 不需要相信對話摘要，就能查看執行參數、stdout／stderr、HTTP 請求、會話與雜湊。這仍不是自動接手；TaskStore 的中斷恢復、候選部署和回滾還沒有在本輪驗證。

下一個練習是讓普通、JSON、quiet 三種輸出模式接受同一組失敗情境，先重現，再修正，再讓非作者檢查。RC-071 仍為草案候選，缺少 pwsh 的契約檢查記 NOT_RUN。讓每一步的已知與未知都留下來，才有機會逐步把自我開發變成可信任的工程流程。