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

工作草稿，已存網站草稿、尚未發布。本篇的「讀」是閱讀本輪三份 CLI 設計分析，對照使用者後續確認的需求。證據是三份實際輸出與設計反例；不是新功能實作報告，也不因此調高能力地圖分數。

它是什麼

Coding Agent 能修改程式，不代表它完成了可靠的軟體開發。還需要知道任務原本要解決什麼、驗收條件是否達成，以及執行中斷後能不能由另一個工作者接續。

當產品要參與開發自己，這些問題會更明顯：正在修改的版本可能壞掉，而保存進度、判斷結果與安排升級的流程不能跟著一起消失。

這篇練習的是把「會呼叫多個 CLI」拆成可驗證的工程責任。

專案裡哪件事逼我用到

我希望 Spectyn 由 CLI 起步，逐步形成拆小任務、開發、測試、eval、部署的循環，再延伸到多機與 App。參與者包括 Codex、Claude Code、agy、OpenCode，以及 Spectyn 自己的 CLI。

我也補了一個限制：Spectyn 相對不穩定，因此其他 CLI 必須能檢查它的開發狀況，必要時接續。

這讓問題從「選誰寫程式」變成「所有人根據什麼判斷工作進度」。如果進度只存在 Spectyn 的對話或執行程序中，它一旦中斷，其他人就只能重新猜。

做之前我以為

原本容易把開發循環想成依序接上幾個指令：planner 拆題、coder 修改、tester 跑測試、reviewer 說通過，最後部署。

但每個箭頭都有問題：誰能改驗收條件？tester 是否真的執行？reviewer 看見的是原始輸出還是摘要？中途接管是否會出現兩個仍在工作的作者？部署失敗能否回到原本資料狀態？

角色名稱本身沒有回答這些問題。

做完的證據

這輪實際完成的是設計分析呼叫與原文保存。透過既有 local-ai 包裝器，取得三份回覆：

三份意見都只根據提供的摘要分析，沒有在這輪檢查產品程式。它們分析的是部署、授權與初始開發流程；加入 Spectyn CLI 作為工作者、強調外部接續，是之後使用者補充的要求。因此不能把這張表寫成「三方通過五 CLI 自我開發架構」。

本輪也沒有確認三個 CLI 的實際模型身分。不同程式名稱不能自動算成不同模型的獨立驗證。

從意見中挑出需要修正的地方

Claude 提議固定決策設備，但產品希望任一已授權 App 都能控制工作，因此要把任務的單一有效執行權責，與使用者從哪裡下指令分開。

「立即撤銷」也要補上可驗證條件：離線設備還沒收到消息，不可能假裝已完成全網撤銷；在途操作也不一定能撤回。這些是後續規格要定義的邊界。

agy 提到較少溝通輪次和耗時可呈現改善。這些可以觀察協作效率，卻不能單獨證明人的能力成長。人的成長要對應使用者選擇的能力，例如是否能自行解釋問題與完成相近任務。

把任務交接寫成具體資料

下面是教學用的任務包草案，不是已實作 schema、真實執行結果或已核准發布契約：

{
  "task_id": "example-selfdev-001",
  "goal": "讓一個有界任務中斷後可被外部檢查",
  "base_revision": "<確切來源版本>",
  "workspace": "<隔離工作區>",
  "writer": "spectyn-cli",
  "reviewer": "<另一個實際可用的 CLI>",
  "allowed_paths": ["<待盤點後選定>"],
  "acceptance": [
    "留下可直接讀取的最近進度與證據",
    "未確認舊執行者停止時不得競爭寫入"
  ],
  "limits": {
    "max_attempts": "<使用者政策決定>",
    "budget": "<使用者政策決定>"
  },
  "evidence": [],
  "result": "NOT_RUN"
}

CLI 不同，也要讀同一份目標與驗收。原始測試指令、退出碼、輸出及修改版本必須能追溯；共同紀錄的寫入權、事件順序和格式相容性仍待設計。

測試與 eval 各自回答什麼

測試檢查指定行為，例如失敗退出碼是否被保留。eval 檢查這個結果是否達成任務目標，例如其他 CLI 是否真能根據紀錄判斷中斷位置並安全接續。非作者審查則檢查修改及證據有沒有缺口。

三者互相補強。作者的完成摘要不能取代測試；測試全綠也不代表原始需求已解決。

還缺什麼

第一個自我開發里程碑尚未執行。後續至少要測三種情境：

穩定版 A 與候選版 B 的部署、停止、回復和資料遷移也還要驗證。五個 CLI 都能承接任務、多機共用額度、自動派工與 App 接續，都不是這輪已完成的成果。

持續進化能力也不因今天有一張循環圖就升級。第 11 區「從軌跡學習」仍需要真實的回饋、策略變更與獨立前後對照。這輪沒有這些新證據。

今天真正學到的

讓自己的 Agent 參與開發，需要同時建立它能做的事，以及外部如何檢查、停止、接續它。工作紀錄可直接讀取，是失敗後仍能繼續推進的起點。

自我改善的成效要以完成品質、失敗率與資源消耗等證據評估；人的成長另行驗證。更長的執行時間、更多 Agent 或更多生成程式碼，都不直接等於進步。

如果你也想這樣做

先選一個小任務，在開發前寫出成功與失敗條件。讓作者和檢查者分開，保留原始輸出，再刻意設計一次中斷情境。先確認能安全交接，再增加平行工作者與設備。

免費本機、自架與付費雲端應共用資料及執行授權的設定能力；把同一個任務搬到另一個部署位置，不代表資料傳送與花費也已獲得授權。

明天

盤點 Spectyn CLI 現有能力，選一個小任務建立可執行驗收。下一篇再依真正跑出的結果，記錄正常完成、中斷與錯誤回報哪一項成立，哪一項需要修正。

本機證據索引

• ../evidence/2026-09-21-deployment-panel/README.md
• 同目錄的 claude.txt、agy.txt、opencode.txt。
• 本文任務 JSON 為設計示意；不是產品設定檔。原始分析並未覆蓋後續所有需求，無正式完整架構通過宣告。