---
name: delegate-flash
description: 主線強模型 + 便宜子代理的分工紀律——按「耗 token 還是耗判斷」分流：體力活全外包、三行 brief、抽查式驗收（唯獨外部 API 細節必須逐條核對，防自信編造）
type: prompt
whenToUse: 動手做任何開發任務前，決定哪些部分派給 sub-agent；以及拿回交付時如何驗收
---

# K3 動腦，Flash 動手

雙層模型編制，經真實對抗測試驗證（2026-08）：**K3** 是主線用的最強模型，判斷最貼近事實；**Flash** 是 sub-agent 用的便宜模型，成本約 1/20、執行紀律最強，但會自信地編造陌生 API 細節。（作者的編制：Kimi K3 + DeepSeek V4 Flash；型號可替換，紀律不變——本 skill 只規定分工與驗收，不綁具體模型。配置法見同目錄 INSTALL.md。）

## 啟用檢查（每次啟用先做，一步）

子代理要跑在 secondary 模型上，需要兩個前提：啟動進程時帶實驗開關，且 `[secondary_model] model` 已配置（config.toml，或 `KIMI_SECONDARY_MODEL` 環境變數）。啟用本 skill 時立刻查開關：

```bash
echo "${KIMI_CODE_EXPERIMENTAL_SECONDARY_MODEL:-<unset>}"
```

- truthy（`1` / `true` / `yes` / `on`）：直接開工，不用提。
- 否則：提示用戶一句命令重啟並接回當前 session（環境變數只在進程啟動時生效，session 中途補設無用；由用戶自己決定是否執行，不要替他重啟）：

  ```
  KIMI_CODE_EXPERIMENTAL_SECONDARY_MODEL=1 kimi -c
  ```

  `-c` 接回當前目錄最近的 session；要指定 session 用 `kimi -S <id>`。主開關 `KIMI_CODE_EXPERIMENTAL_FLAG=1` 也會啟用此實驗。尚未配置 secondary 模型的，見同目錄 INSTALL.md 的 DeepSeek 範例，或官方文檔 [config-files](https://www.kimi.com/code/docs/en/kimi-code-cli/configuration/config-files.html) 的 `secondary_model` 節。

## 分流標準（唯一的判斷題）

問一句：**這活耗的是 token 還是判斷力？**

- 耗 token（要讀很多、搜很多、改很多、跑很多）→ 外包給 Flash
- 耗判斷（取捨、決策、方向）→ K3 自己做

注意：開放式探索（「X 是怎麼運作的？」）也是體力活——資訊收集最耗 token，K3 不需要先想清楚才派，判讀結論才是 K3 的活。

## 體力活（一律外包，brief 三行以內）

- 讀檔案、搜代碼庫，回報「X 怎麼運作」+ 關鍵位置（檔案:行號）
- 批次機械修改：改名、格式化、N 個檔案同步同類改動
- 跑測試 / 命令 / 腳本，回報原始輸出
- 抓網頁、讀文檔、提煉重點
- 寫樣板：介面已被現有代碼定死的測試骨架、CRUD、配置
- 分析日誌、整理輸出

brief 格式：**一句話目標 + 相關路徑 + 一句話約束**。
例：「找出 src/auth 的 token 刷新流程，回報關鍵函數與檔案行號，不要改任何檔案」。

反模式警報：發現自己 brief 寫超過 5 行，說明這是腦力活或該拆小——**把規格寫完等於把活幹完，外包純虧**。

例外：任務繞不開陌生外部 API 時，把 K3 已核實的事實直接寫進 brief，別讓它猜。

## 操作機制

- **碎片僱用是預設**：sub-agent 當員工養，勞力活不分大小、一行 brief 就派；只有多 agent 並行協作才需要落契約文件（接縫規格寫成 repo 文件，brief 指路徑）
- **員工池**：記住每個 agent 的 id 與已有上下文；同領域的活一律 resume 對口舊員工（超時、做偏也 resume 續命，別重開）——它讀過的檔案不用重讀，這是最省 token 的地方；resume 的 brief 一句話就夠（「順手把 X 也改了」）
- **冷熱門檻**：冷啟動的上下文載入比小活本身還貴。一行 Edit 這種活，有對口熱員工就順手派掉；要開新員工就自己做。同理，不為並行開冷員工——並行只在檔流域真獨立時成立，不是「人多快」
- **自含**：新員工的 brief 必帶確切路徑、已核實事實、可直接執行的命令；規格長就寫成 repo 裡的文件，brief 指路徑

## 並行的邊界（實戰版）

兩個硬序列點先認清：**工作樹是單一可寫表面**（兩個寫 agent 同改一棵樹會互相污染，且其中一個的測試結果變得不可信），**驗收鏈必須對穩定樹跑**（寫流在跑、或主線驗證鏈在跑時，誰都別動 src）。

- **寫流最多並行 N 條，前提是檔案/模組不相交**；同檔案的波次一律串行。多寫流同時交付時**分開驗、分開 commit**——壞了能歸因到單一流，不用 bisect 混合 diff
- **讀取型偵察永遠可並行**（不碰樹）：最佳用途是填「等 wave N 交付」的空轉——派去把 wave N+1 的施工點、現狀、測試缺口查清楚，回來直接變下一波的 brief 素材。行號會因寫流漂移，brief 裡註明「報結構與函數名，行號僅參考」
- **語義/soundness 敏感的翻轉不並行**：寧慢勿亂，單寫流 + 主線緊盯
- **瓶頸認知**：並行省的是等待空轉，不是驗證——驗收鏈延遲和主線抽查才是真瓶頸，兩者都不可並掉。天上同時超過 3 個（1 寫 + 2 讀）通常純浪費

## 腦力活（K3 自己做，不外包）

- 架構取捨、方案選型、任務拆解
- 判讀 sub-agent 回報的結論（可信度、下一步往哪走）
- 最終整合與驗收
- 破壞性或對外操作（刪除、推送、部署到共享環境）

## 驗收（抽查式，不搞儀式）

- 有測試：實際跑一遍，不信「已完成」的口述
- 無測試：隨機抽一處看實際產出（讀檔案 / diff），不讀摘要
- **唯一不能省的**：交付中凡涉及外部 API、CLI 參數、庫版本的調用，逐條與官方文檔核對——Flash 編造高發區，這條是硬規矩
- **自檢報告也算編造高發區**：「我已逐一比對 / 已驗證通過」的口述一律當未驗證；它的細節列點可用，總結不可信
- **UI 交付的完成標準是「真瀏覽器跑起來 console 無錯」**，語法檢查（node --check 之類）不算數——語義 bug 只有真跑才現形
- 並行多 agent 時，接縫（URL 路徑、multipart 欄位、JSON 鍵名）必須在契約文件裡有唯一定義；brief 指明「不許自行假設，契約沒寫就回報」