一個人當十個人用——AI 輔助開發的 SOP 方法論與多模型分派策略

2026 年初我開始自學程式。5 個月後，我一個人同時維護 6 個專案——官網、Telegram 機器人、爬蟲系統、刷題 App、社群分析 Dashboard、AI 內容引擎。

不是因為我特別聰明。是因為我建立了一套方法論。

這套方法論讓我可以在 Claude Code Pro 月費內（約 NT$600），用 7 個免費 AI 模型分工協作，每月幾乎不花額外的 API 費用，產出一個小型工程團隊的成果。

這篇文章就是這套方法的完整拆解。

核心哲學：為什麼需要 SOP

一個人 + AI 開發最大的陷阱不是技術，是混亂。

沒有流程的時候，你會在同一個問題上反覆橫跳：一下改前端、一下調模型、一下又跑去研究新工具。一天過去了，什麼都沒交付。

這套 SOP 解決三個問題：

做什麼——spec-driven 確保範圍清楚，不會發散
誰來做——多模型分派讓對的模型做對的事
怎麼省錢——script-first 調度讓大部分工作走免費額度

第一層：Spec-Driven 工作流程

判斷標準

不是所有任務都要寫 spec。關鍵是複雜度：

需要寫 spec（複雜任務）：

跨多個檔案修改
涉及架構決策
新功能從零開發
範圍邊界模糊，需要先界定

不需要 spec（簡單任務）：

單行修正、錯字、明顯 bug
小範圍調整
已經有明確具體的指令

Spec 檔案結構

規格檔統一放在專案根目錄 specs/ 下，命名格式 TASK-YYYY-MM-DD-###.spec.md。

---
goal: 建立多科目刷題系統
scope_in:
  - 科目切換 UI（下拉選單）
  - 本地儲存各科進度
  - 題庫資料表多科欄位
scope_out:
  - 成績分析 Dashboard（另開 spec）
  - 社群分享功能（另開 spec）
constraints:
  - 不影響現有 PMP 刷題功能
  - 需支援離線使用
validation:
  - 切換科目後進度正確恢復
  - 各科題目不互相污染
status: draft
---

為什麼中度 spec 而不是重度

我試過寫很詳細的 spec（UI 線稿、API 規格、資料庫 schema 全列），結果花在寫 spec 的時間比寫程式還多。後來收斂到這邊的中度 spec：只定義範圍和邊界，不設計實作細節。

重點是回答一句話：「做完這張 spec，什麼東西會改變，什麼東西不會動。」

第二層：Script-First 派工策略

問題背景

Claude Code Pro 月費內含的子代理功能（Agent 工具）走的是 Anthropic API，子代理怎麼呼叫不是使用者能控制的——它們會走 Pro 月費內的模型（Haiku/Sonnet），不花額外的錢。

但在我建立的 10 體 AI Agent 組織中（CTO、COO、CMO、研究員等），大部分任務是純文字推理、生成、翻譯、分析——不需要讀寫檔案或執行指令。

這些任務如果用 Pro 內含的子代理，會佔用 Pro 的對話限額。更好的做法是：寫 Python 腳本，透過本地 LiteLLM 閘道（http://127.0.0.1:4000），把任務分派給 OpenRouter/DeepSeek 的免費模型。

三級派工決策樹

任務來了
  │
  ├─ 純文字推理/生成/翻譯/分析？
  │     │
  │     ├─ 單次簡單查詢 → free-model CLI（閘道，免費）
  │     ├─ 平行大量任務 → Python script + ThreadPoolExecutor（閘道，免費）
  │     └─ 批次多任務 → batch-free-model（閘道，免費）
  │
  └─ 需要讀寫檔/執行指令/WebFetch？
        └─ Agent 子代理，一次 1-2 個（Pro 內含）

實際案例

前天我需要把 10 篇英文技術文章翻譯成繁體中文。如果一篇一篇手動處理要搞一整天。

做法是寫一個 30 行的 Python script，用 ThreadPoolExecutor 同時把 10 篇文章發給 LiteLLM 閘道，指定 deepseek-v3.2 和 glm-4.7 雙模型各翻一次，再比對取品質好的版本。10 篇文章 90 秒全部完成，API 費用 $0。

第三層：多模型分派策略

7 個免費模型的實測排名

我對 7 個免費模型做了完整的效能評測（2026-05-08），每個模型跑 40 題相同的測試，從品質、速度、簡潔度、可靠性四個維度評分：

#	模型	總分	品質	速度	適用場景
🥇	deepseek-v3.2	90.1	8.71	5.7s	全能首選，預設模型
🥈	qwen-coder	83.3	7.78	9.4s	程式碼生成、debug
🥉	nemotron	80.3	7.89	18.6s	深度推理、複雜分析
4	gemma-4	78.0	8.85	44.4s	高品質長文（不趕時間）
5	llama-4	77.1	6.44	3.8s	大量簡單任務、快速預覽
6	qwen3.5	75.0	9.04	30.6s	❌ 可靠性問題，不建議
7	glm-4.7	67.0	8.62	48.7s	繁中品質佳，但太慢太囉嗦

分派規則

┌─────────────────────────────────────────────────┐
│  任務類型              →  首選模型    備選模型    │
├─────────────────────────────────────────────────┤
│  預設/一般查詢         →  deepseek-v3.2         │
│  程式碼生成/審查       →  qwen-coder  deepseek  │
│  深度推理/複雜分析     →  nemotron    deepseek  │
│  高品質長文            →  gemma-4     nemotron  │
│  大量快速簡單任務      →  llama-4     deepseek  │
│  繁體中文內容          →  deepseek    glm-4.7   │
│  雙模型驗證（重要）    →  deepseek + nemotron   │
└─────────────────────────────────────────────────┘

雙模型驗證模式

對於重要任務（例如考試題目答案驗證、關鍵程式邏輯審查），我會用雙模型交叉驗證：

同一個問題同時發給兩個不同模型
兩個答案一致 → 高信心採用
兩個答案衝突 → 親自判斷，或發給第三個模型當裁判

之前我驗證 677 題證券業務員考題，用 deepseek-v3.2 + glm-4.7 雙模型對答案，發現 99% 一致率，68 題需要修正——這在單模型下是不可能發現的。

完整工作流：從點子到交付

把三層結合起來，一個任務從頭到尾的流程長這樣：

1. 收到需求
   └─ 複雜？→ 寫 spec，等自己審過再動手
      簡單？→ 直接開始

2. 拆解步驟
   └─ 把 spec 拆成 2-5 個獨立步驟，每步 < 5 分鐘

3. 分派執行
   └─ 純文字工作 → script 調閘道免費模型平行跑
      需工具操作 → Agent 子代理（Pro 內含）

4. 審查整合
   └─ 重要結果用雙模型驗證
      審查通過 → 整合進專案

5. Git commit + 記憶更新
   └─ 每次完成一個有意義的變更就 commit
      重要決策寫入記憶系統

基礎設施：LiteLLM 閘道

這整套方法的核心基礎設施是本地 LiteLLM 閘道。

它跑在 http://127.0.0.1:4000，統一介接 11 個模型（DeepSeek、Anthropic、OpenRouter、智譜），對外暴露標準 OpenAI API 格式。所有免費模型的呼叫都透過它路由，不需要管理多組 API key 和多個 SDK。

成本方面：OpenRouter 初始 $5 儲值，跑了上百次任務只消耗約 $0.05。DeepSeek 平台也有免費額度。整個系統的模型呼叫成本幾乎可以忽略。

這套方法論適合誰

這套 SOP 不是萬能的。它的設計背景是：

一人開發者，沒有團隊可以分工
非技術背景，自學程式不到一年
多專案並行，需要同時維護 5-6 個 repo
預算有限，月費 NT$600 就是全部的工具支出

如果你在類似情境——獨立開發者、side project 多、想用 AI 加速但不想花大錢——這套方法可以直接套用。

如果你有團隊、有預算、有專業工程師，那你可能不需要這麼克難的免費模型調度。但 spec-driven 的規劃習慣和雙模型驗證的做法，在任何規模都適用。

下一步

這套方法論還在持續演化。接下來的計畫：

自動化分派腳本：一鍵把 spec 拆成 task 並自動分派給最適合的模型
品質儀表板：追蹤各模型的歷史表現，動態調整分派策略
CI/CD 整合：commit 前自動跑多模型 code review

方法論的本質不是工具，是把混亂變回秩序的習慣。5 個月前我連 git commit 是什麼都不知道，現在我能同時開 6 條戰線——不是因為我學會了什麼高深的技術，而是我建立了一套讓 AI 幫我做事的方法。

而這套方法，任何願意動手的人都學得會。