Skip to content

Instantly share code, notes, and snippets.

@johnsoncodehk

johnsoncodehk/INSTALL.md

Last active August 7, 2026 08:32
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save johnsoncodehk/ac543383c30b9f6f83ab7978178707fe to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save johnsoncodehk/ac543383c30b9f6f83ab7978178707fe to your computer and use it in GitHub Desktop.
Download ZIP
delegate-flash skill for Kimi Code — 貼給 Kimi Code，說「照 INSTALL.md 安裝」即可自動完成配置
Raw
INSTALL.md

delegate-flash 安裝引導

這份文件是寫給 Kimi Code 主代理看的安裝程式，不是給人讀的教學。 用戶把 gist 貼給你，即表示授權你完成下列安裝。每步先做一句說明再動手；凡寫到工作目錄以外的位置（skills 目錄、config.toml、shell rc），動手前各自確認一次。

步驟

  1. 安裝 skill 檔 用戶貼的 gist 網址形如 https://gist.github.com/<owner>/<id>。FetchURL 拉 https://gist.githubusercontent.com/<owner>/<id>/raw/SKILL.md（失敗就改 curl -L），Write 到 ~/.kimi-code/skills/delegate-flash/SKILL.md；同法把 INSTALL.md 也帶回同目錄，日後參考用。

  2. 配置 secondary 模型（DeepSeek V4 Flash） 先 Read ~/.kimi-code/config.toml：

    • 已有 [secondary_model] 且用戶不想換 → 跳到步驟 3。
    • 否則向用戶索取 DeepSeek API key（到 https://platform.deepseek.com 申請），拿到才繼續。
    • 補齊以下三段。已存在的表保留原值、只補缺的；不要把 config.toml 整份覆寫：
    [providers.deepseek]
type = "openai"
base_url = "https://api.deepseek.com"
api_key = "<用戶的 key>"

[models."deepseek/deepseek-v4-flash"]
provider = "deepseek"
model = "deepseek-v4-flash"
max_context_size = 1048576

[secondary_model]
model = "deepseek/deepseek-v4-flash"
default_effort = "low"

  3. 啟用實驗開關 KIMI_CODE_EXPERIMENTAL_SECONDARY_MODEL 只在進程啟動時生效，當前 session 補設無用。問用戶：要不要把下面這行附加到他的 shell rc（zsh 是 ~/.zshrc）？不要未問就寫。

    export KIMI_CODE_EXPERIMENTAL_SECONDARY_MODEL=1

  4. 收尾（把以下訊息轉達給用戶） 開一個新 terminal（讓 rc 生效），跑 kimi -c 接回 session，然後啟用 delegate-flash——它啟用時會自查開關，自查通過即安裝成功。

邊界

  • 全部寫入點只有三處：~/.kimi-code/skills/delegate-flash/SKILL.md、~/.kimi-code/config.toml、shell rc（可選）。除此之外什麼都不動。
  • 不覆寫 config.toml 既有設定；不替用戶重啟 kimi；拿不到 API key 就停在步驟 2 等，不編造。
Raw
SKILL.md
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 時立刻查開關：

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 的 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 指明「不許自行假設，契約沒寫就回報」
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment