地端幫手能接工作，先把邊界講清楚

先拆開整條流程

做 Jarvis 時，我把語音助理拆成喚醒、聽懂、思考、說話與執行。我的順序是先把一段跑通，再接下一段。真正花時間的，是讓每個模組知道自己要收什麼、交什麼，而不是一開始就把所有工具塞成一條長指令。

沒聽到、轉成錯字、回答錯了，是三種不同問題。我會先做聽一句、回一句的最小迴路，再加其他動作。輸入、輸出與失敗訊號清楚，思考層要換模型時，也比較容易保留其他已經跑通的部分。

把地端模型接進來當幫手，我也得重新想一次分工。檔案清單、固定欄位轉換、附來源摘要，這些工作比較容易限定範圍與驗收。做錯能重跑，又能很快判斷對錯，才適合拿來試第一輪。

我第一次派給 Qwen 時，它回答得很完整，理由也很像真的；回頭查原始資料，卻有幾件事根本對不上。那次讓我知道，接通只是開始。需求模糊、帳密、公開發布與難以復原的操作，我留在自己與雲端的判斷範圍。

後來我把工作單縮成幾項：目標、必要背景、可讀與可改的檔案、輸出格式、驗收方式、何時停下。只給這件事需要的資料，缺資料就回報，不靠猜測把答案補滿。兩邊也不能假設自然共享對話與權限。

比如派一份清單，我會寫：「只讀指定目錄，輸出檔名、路徑與類型，不讀內容、不改檔案。筆數要與實際清單一致，重複項另列；無法存取就回報。」交回來時，我就能拿同一張工作單逐項查，而不是憑回答的氣勢判斷。

我加的第三道關卡是另外驗收。先查有沒有碰到範圍外的檔案，再核對內容與測試：程式看差異、摘要查來源、清單對筆數。它說測試通過，我還要看執行結果；沒有紀錄，就先當作待確認。

地端 worker 做第一版，雲端和我重新核對，最後接受、修改或退回由我決定。失敗時先縮範圍或調整驗證方式，仍對不上就換回已確認的流程。這幾道關卡讓幫手比較可用，也讓我看見審核本身花了多少工。

2026-07-25 那次，我記到雲端派工、拆任務與檢查花了快一萬五千 tokens；同一件事直接由雲端做的三千到四千，是我的估算，沒有做同條件對照測試。所以這筆帳提醒我的是派工有成本，還不能說地端一定省額度。

我下一步想比較同一批工作完成多少、退回多少、等待多久，以及實際用量。讓地端直接讀寫允許檔案的端到端差異，當時也還沒親測。另一個要查的是資料路線：Jarvis 或模型在本機，語音、搜尋或轉交服務仍可能出網。