AI
ai
e
AI繪圖-Midjourney 新手的AI生圖冒險
韓語基礎會話K1B
AI
ai
e指揮AI團隊-2027 軟體開發工作流Ｘ系統整合實戰
菜鳥救星線上真人課程簡介
為什麼要學
別再自己寫程式了 —— 指揮一支 AI 團隊替你交付
過去兩年，我們學會了怎麼讓 AI 幫忙寫程式。
接下來要學的，是怎麼讓「一群 AI」協作，把事情真正做完。
這兩件事的難度差距，比多數人想像得還要大。一個 AI 寫錯，你通常看得出來；但當五個 AI 同時修改專案，其中一個宣稱完成、測試卻根本沒通過時，你可能連問題出在哪裡都不知道。
多代理（Multi-agent）不是同時開五個 AI 專案就會自動變快，這本質上是一個涉及 Context 工程、規格設計、任務邊界、品質閘門與成本控制的「系統工程問題」。
這堂課將使用一個真實的 FastAPI 專案，帶你從頭建立完整的工作流：設計 Context、拆分可並行且可驗證的任務、編排 AI 團隊、讓 Claude 與 Codex 互相審查，再將驗證閘門接進 CI。你甚至會親眼看到，自己建立的品質閘門是如何被 AI 繞過，並學會找出漏洞、補強機制。
我不會告訴你多代理有多神奇。
我會告訴你它在什麼條件下有效、什麼時候不該使用，以及當整套流程壞掉時，你應該從哪裡開始找問題。
- AI 協作模式升級：AI 已具備撰寫程式的能力，未來的競爭優勢將從單兵操作 AI，轉變為指揮多個 AI 進行專案協作。
- 突破傳統開發瓶頸：過去任務拆解、進度追蹤與品質檢查仍高度依賴工程師；進入 2027 年，開發趨勢將走向「人指揮 AI 團隊完成交付」。
- 多代理分工與驗證：透過 Claude Code 的 subagents、agent teams 與 background agents 實現多代理分工，並結合 Claude × Codex 跨模型互審。
- 自動化審查機制：導入 GitHub Actions 與 CI 自動審查及驗證閘門，確保 AI 的產出可被測試、追蹤且值得信任。
- 建立自動交付工作流：課程不著重基礎操作，而是聚焦 Context 工程、規格驅動、多代理編排、跨工具協作與 CI 治理，打造可實際導入的專案流程。
- 工程師價值轉型：隨著編碼工作自動化，工程師的核心價值將轉移至「定義得清楚、指揮得有效、驗證得可靠」。
學習痛點
許多工程師在日常使用 AI 工具時，常面臨以下瓶頸：
- 規則被忽略：AI 無法確實遵守 CLAUDE.md 內的規則，源於未釐清「context」與「config」的差異。
- 檔案修改衝突：開啟多個 AI 並行作業時，缺乏管控機制，導致不同 AI 互相覆蓋或踩到同一個檔案。
- 代理名詞混淆：面對 agent teams、subagents、background agents 等專有名詞，不知如何依據情境正確選用。
- 缺乏驗證機制：當 AI 宣稱任務完成但測試未通過時，開發者缺乏有效的自動攔截與防呆機制。
- 成本與效益不明：多代理運作導致 Token 費用大幅增加，卻難以精確估算投資報酬率與實際提升的開發速度。
- 框架真偽難辨：網路充斥各式多代理框架，開發者難以判斷其實際效用與真偽。
本課程解決方案：逐一拆解上述痛點，並建立一套可驗證的機制 —— 不再只是期望「AI 聽話」，而是做到「不合規就自動擋下」。
課程大綱
- 單元1：講師介紹、課程總覽與十堂課的一條主線
- 單元2：context rot 的三個機制（注意力預算、訓練分布、位置偏置）
- 單元3：Chroma 十八模型實證 —— 一個干擾項就會讓模型出錯
- 單元4：用 /context 當 profiler，打開 Claude Code 的 context 黑箱
- 單元5：CLAUDE.md 是 context 不是 config（引導用 context、強制用 hook）
- 單元6：prefix cache 與成本 —— 穩定的往前放、易變的往後放
- 單元7：分層記憶設計（AGENTS.md → CLAUDE.md → rules → skill → auto memory）
- 單元8：長時任務三招與 ACE 增量維護法（為什麼不要叫 AI 整理 CLAUDE.md）
- 完成分層 context 設定，並用稽核 hook 證明規則按需載入
- 單元1：多代理的根本張力（Cognition 的隱含決策 vs Anthropic 的讀寫並行性）
- 單元2：規格驅動開發（SDD）＝ 讓並行的 agent 只執行、不決策
- 單元3：GitHub Spec Kit v0.12.9 黑箱解剖 —— 所有保證都是 prompt 級的
- 單元4：[NEEDS CLARIFICATION] 把「棄權」變成可 grep 的結構化欄位
- 單元5：任務分解的形式化 —— tasks.md 是 DAG，並行等於圖上互相不可達
- 單元6：[P] 是一份並行安全證明，而沒有任何機器在檢查它
- 單元7：三種衝突與修法（拆架構／序列化／單一寫者）
- 單元8：算帳 —— 用 critical path 算加速比，決定該不該開團隊
- spec／plan／tasks 三件鏈，且 linter 回報 0 error（標記是聲稱，0 error 才是證明）
- 單元1：custom commands 已併入 skills（allowed-tools 是授權，不是限制）
- 單元2：hooks 全景 —— 29 個事件五大族，以及「誰擋得住」的關鍵矩陣
- 單元3：兩條控制路徑（exit 2 加 stderr，對上 exit 0 加 JSON）
- 單元4：用 PreToolUse 的 updatedInput 改寫 AI 即將執行的指令，省下數萬 token
- 單元5：五種 hook handler 與 if 條件過濾（command／http／mcp_tool／prompt／agent）
- 單元6：headless 的 --bare —— CI 的可重現性，也是安全邊界
- 單元7：MCP 的三種 scope、tool search，以及「有 CLI 就別用 MCP」的成本反直覺
- 單元8：安全基線（寫入限制、prompt injection 防護、-p 模式會停用信任確認）
- 可跑的 skill＋hook＋headless 腳本＋MCP 接入，且能說出自己的 hook 擋不擋得住
- 單元1：三機制對照與決策樹（subagents／agent teams／background agents）
- 單元2：官方為什麼說「順序相依、同檔編輯的工作，單一 session 更有效」
- 單元3：subagent frontmatter 十六欄位（路由層／權限層／成本層／context 層）
- 單元4：maxTurns 是「跑飛的 agent」的解；memory 讓 subagent 跨 session 學習
- 單元5：isolation: worktree —— 讓 subagent 在自己的隔離副本裡改檔案
- 單元6：scope 優先序，與 plugin subagent 被忽略的三個欄位
- 單元7：最小權限與模型路由（reviewer 沒有 Edit 是機制，不是約定）
- 單元8：用 SubagentStart／SubagentStop hook 證明 description 真的路由到誰
- 三個可重用 subagent ＋ 委派路由 log，reviewer 嘗試改檔案時被白名單擋下
- 單元1：agent view 調度盤（claude agents／--bg／六種狀態／不 attach 就 peek）
- 單元2：supervisor daemon 與 scripted 介面，以及「刪 session 會連 worktree 一起刪」的陷阱
- 單元3：隔離的四條路 —— 多數人只知道最後一條（手動 git worktree）
- 單元4：兩個必踩的坑（base branch 預設不是你的 HEAD；.env 不會跟過去）
- 單元5：成本經濟學 —— 官方每人每活躍日 13 美元，agent teams 約為單 session 的 7 倍
- 單元6：用 /usage 量測與斷路（歸因到 skills／subagents／plugins／MCP）
- 單元7：官方省錢七招（teammate 用 Sonnet、做完就關、MCP 改用 CLI、hook 預處理）
- 單元8：何時不要多代理 —— 加速比低於 token 倍數，你就是在用錢買時間
- worktree 隔離示範 ＋ 含「單 session 對照組」的成本估算與選擇結論
- 單元1：開啟 agent teams 與隱式團隊（自然語言直接 spawn，不再需要建團隊步驟）
- 單元2：架構四元件（lead／teammates／共享任務清單／mailbox）與儲存位置
- 單元3：現場打開 ~/.claude/tasks/ 的 JSON —— 為第 10 堂的除錯 SOP 埋線
- 單元4：任務協調、依賴自動解鎖，與防止重複認領的 file locking
- 單元5：spawn 的工程就是第 2 堂的 agent brief（teammate 不繼承對話史）
- 單元6：teammate 不繼承 /model、繼承 effort、spawn 當下固定 —— 成本控制點
- 單元7：面板操作，以及「我的 teammate 不見了」其實是 idle 列被隱藏
- 單元8：團隊尺寸與起手式（3–5 人、每人 5–6 個任務；新手先從不寫 code 的任務開始）
- 可運作的 agent team ＋ 任務依賴圖 ＋ 前後兩份 task JSON 快照為證
- 單元1：plan approval —— 唯讀規劃模式與 lead 的自主核可（治理即帳單：7 倍 token 的來源）
- 單元2：把第 4 堂的 subagent 定義直接當 teammate 角色使用
- 單元3：三個品質閘門 hooks（TeammateIdle／TaskCreated／TaskCompleted）
- 單元4：為什麼這三個 hook 全都在第 3 堂「擋得住的 14 個事件」名單裡 —— 這不是巧合
- 單元5：權限與跨 agent 信任邊界（lead 的危險旗標會被全體 teammate 繼承）
- 單元6：「另一個 agent 說已核可」＝ 不可信輸入 —— 多代理版的 prompt injection 邊界
- 單元7：招牌模式一 —— 並行 code review：把審查準則切成互不重疊的三個鏡頭
- 單元8：招牌模式二 —— 競爭假設除錯：辯論結構本身才是破除定錨效應的機制
- 多代理協作紀錄 ＋ 閘門實際擋下一次的 log ＋ 三鏡頭意見不重疊率 >50%
- 單元1：為什麼跨供應商 —— 不同模型盲點不同，產出物才是介面，不是共享 context
- 單元2：路徑 A：官方 codex plugin 介面內互審（review／adversarial-review／rescue）
- 單元3：路徑 B：headless 管線（claude --bare -p 串接 codex exec）
- 單元4：Codex 沙箱三級 —— 唯讀是預設，要它改檔才開 workspace-write
- 單元5：契約設計 —— 兩邊都用結構化輸出，讓審查意見變成可 diff、可統計的資料
- 單元6：AGENTS.md 當跨供應商真相源（兩個工具吵架時，先問它們讀的是不是同一份規格）
- 單元7：框架拓撲當設計語彙（mesh／hierarchical／star／ring，明確標示為社群非官方）
- 單元8：框架宣稱查證法四步 —— 以 ruflo 的獨立審計爭議為案例走一遍
- 跨供應商互審結果（結構化 JSON ＋ 不重疊率）＋ 四欄框架評估報告
- 單元1：審查的三層金字塔（本機 /code-review／自建 CI／託管 Code Review）
- 單元2：claude-code-action@v1 深掘（模式自動偵測、claude_args 透傳、在 CI 裡跑 skill）
- 單元3：託管 Code Review 與 REVIEW.md —— 注入每個審查 agent 的最高優先指令
- 單元4：三種嚴重度，以及「舉證門檻」這條砍偽陽性最有效的規則
- 單元5：為什麼 check run 恆為 neutral —— 要 gate 就自己讀 severity JSON
- 單元6：把 headless 接進 CI —— 第 2 堂那支 linter 的第三個位置
- 單元7：CI 安全（secrets、最小權限、OIDC；-p 模式會停用信任確認）
- 單元8：第三方 PR 的內容本身就是 prompt injection 面 —— AI 結論不可自動 merge
- PR 自動審查 bot ＋ 測試生成 ＋ 一道真的會 fail 的品質閘門
- 單元1：除錯 SOP 的第一原則 —— 多代理系統就是磁碟上的 JSON，先觀測再猜
- 單元2：三步除錯法（讀任務清單 JSON → 進 teammate 對話 → 看 hook log）
- 單元3：失敗模式目錄之一：協調類（狀態滯後、lead 搶工、teammate 看似消失）
- 單元4：失敗模式目錄之二：執行類（停擺、同檔互踩、跑飛的 agent、長輸出被截斷）
- 單元5：失敗模式目錄之三：經濟類（token 爆掉、忘記關 teammate、規劃模式全開）
- 單元6：幻覺完成與三層驗證閘門（自主權越高，閘門越硬）
- 單元7：最進階的一段 —— 閘門也會被繞過：AI 把測試標記略過讓閘門變綠
- 單元8：閘門必須驗證「受測者改不動的東西」；導入既有專案的兩個關鍵
- Capstone 通過 5 項 rubric，並展示「閘門被繞過 → 補強 → 再也繞不過」的前後證據
課程目標
完成課程後，學員將能設計並操作一套可實際導入專案的「多代理 AI 開發工作流系統」：
- 建構系統化工作流：從 Context 工程與規格驅動開發起步，逐步掌握核心開發流程。
- 多代理編排與互審：完成 Claude Code 的 subagents、agent teams 與 background agents 編排，並串接 Claude × Codex 跨模型互審。
- 導入自動審查與驗證：結合 GitHub Actions 建立 CI 自動審查與驗證閘門。
- 打造自動交付流水線：建立具備任務分工、並行開發、品質驗證、錯誤攔截與失敗除錯機制的開發流程，確保 AI 產出真正具備可管理、可追蹤與可上線的條件。
- 累積式實作專案：採 Capstone 專案設計，自第 6 堂起每堂完成一個建置階段，並於第 10 堂依照 5 項驗收指標進行成果檢核。
- 帶走可落地系統：學員獲得的將不是零散的 AI 技巧，而是一套能直接導入既有專案、可持續調整與重複使用的完整開發工作流系統。
學習完後，你能獲得……
「你已經會用 AI 寫程式了——這堂課教你如何指揮它們完成交付。」
完成課程後，你將能夠：
- 建立可導入既有專案的多代理 AI 開發工作流。
- 編排 Claude Code 的 subagents、agent teams 與 background agents，讓多個 AI 分工並行。
- 結合 Claude × Codex 跨模型互審，降低單一模型的盲點。
- 將 AI 審查串接 GitHub Actions 與 CI，建立自動測試與品質閘門。
- 診斷多代理衝突、驗證失敗與成本失控等常見問題。
- 評估多代理帶來的成本、速度與實際效益，判斷何時該用、何時不該用。
你帶走的不是零散技巧，而是一套能被管理、驗證，並實際投入專案的 AI 開發工作流系統。
無論你想提升團隊交付效率、建立個人的 AI 開發工作流，或為 2027 年的工程職能轉型做好準備，這堂課都將帶你建立 AI 時代最關鍵的兩項能力：系統整合與團隊指揮。
誰適合學
本課程適合以下對象：
- 已經在日常開發中使用 Claude Code、Codex、Copilot、Cursor 等 AI 編碼工具，希望進一步建立多代理協作流程的工程師。
- 經常遇到 AI 不遵守專案規則、產出品質不穩，或完成結果無法直接合併與交付的人。
- 想讓多個 AI 同時處理不同任務，但不清楚如何拆分工作、隔離修改範圍與避免檔案衝突的人。
- 需要把 AI 產出接進既有的 Git、Code Review、CI 與測試流程的資深工程師、Tech Lead 或技術主管。
- 想評估多代理開發的 Token 成本、執行時間與實際效益，判斷哪些任務適合使用多代理的人。
這門課處理的不是「怎麼讓 AI 多寫幾行程式」，而是如何讓多個 AI 在可控的流程中分工、驗證與交付，並能整合進既有的軟體開發流程。
本課程不適合：
- 尚無軟體開發經驗，或不熟悉 Git 與命令列操作的人。
- 尚未使用過 Claude Code、Codex、Copilot、Cursor 等 AI 編碼工具的人。
- 想學習 AI 工具安裝、基礎操作或入門程式設計的人。
- 只想學單一提示詞技巧，不打算建立完整開發工作流的人。
講師介紹
Joe老師
- 頂尖科技廠實戰架構師：現任聯發科技系統架構工程師，專責手機晶片性能與功耗建模，實務上曾成功協助降低 10–15% 的系統功耗；過去任職 Garmin 一級工程師期間，更主導導入 DeepLabV3+、OCR＋SuperGlue 與 SfM 3D 建模等深度學習技術，實現導航地圖製作全面自動化，為企業年省逾千萬人力成本。
- 扎實的學術與技術底蘊：畢業於國立清華大學資訊工程研究所（專攻電腦視覺與深度學習）及國立中央大學資訊工程學系，具備深厚的學理基礎，並曾於國際頂級影像處理會議 IEEE ICIP 2019 發表學術論文。
- 直擊痛點的系統整合力：專長涵蓋系統架構設計、多元件整合、深度學習應用與 AI 開發工作流自動化。憑藉多年來處理「複雜多元件系統架構」的本行實力，能精準拆解多代理協作的難題，直接呼應並支撐本課程「AI 工具系統整合」的核心精神。
- 講求實證的工程師教學派：秉持「先理解機制，再動手操作」的教學哲學。拒絕空泛的提示詞玄學，強調課程中的每一項技術主張都必須有跡可循、可受查證，確保學員產出的每一個實作成果，都能通過真實工程環境的驗收標準。
Q&A
為了確保您能順利跟上課程的實作進度，請於上課前確認具備以下環境，並完成相關帳號與 API 註冊：
- 硬體與網路：一台可順暢上網的電腦，並具備穩定、高頻寬的網路環境，以利進行即時的 API 呼叫與雲端作業。
- 基礎開發環境：請確保電腦中已安裝 Git，並具備基本的命令列（Command Line / Terminal）操作能力。
必備軟體與 AI 服務官方連結（請學員先行註冊或評估訂閱）：
- Cursor AI 程式碼編輯器：課程中強烈建議使用的開發環境。
👉 前往 Cursor 官方網站 - Anthropic (Claude) API：實作多代理協作（Claude Code）的核心模型。
👉 前往 Anthropic Console 註冊 API - OpenAI API：用於實作跨模型互審與防禦機制。
👉 前往 OpenAI Platform 註冊 API - GitHub 帳號：課程將大量實作 GitHub Actions 與 CI 自動化審查。
👉 前往 GitHub 免費註冊
【重要提醒】：本課程的核心在於「指揮 AI 團隊」，實作過程中將會呼叫 Claude 與 OpenAI 等第三方 API。課程報名費用並不包含上述 AI 服務的 Token 消耗費與付費版軟體訂閱費用，實際的計費標準與使用額度，請依各平台最新公告為準。
誠實地說，這堂課不適合完全零基礎的初學者。
本課程是專為「已經在實務開發中使用過 AI 工具（如 Copilot、Cursor、Claude），卻深感 AI 難以管理、產出品質不穩」的現職工程師、資深開發者或技術主管所設計。
課程不會花時間教授「如何安裝工具」或「基礎程式語法」，而是直接進入深水區——探討 Context 工程、多代理編排與架構設計。若您還不熟悉 Git 版本控制或尚未在專案中導入過 AI 輔助，我們建議您先參與基礎的 AI 程式開發課程，待累積一定實務痛點後再來挑戰，收穫會更加巨大。
絕對可以，這正是本課程要為您解決的核心痛點！
很多工程師發現，無論在提示詞（Prompt）裡寫得多詳細，AI 還是經常會忽略專案的 Context（上下文）或是造成檔案覆蓋衝突。在這堂課中，Joe 老師將會帶您跳脫「期待 AI 聽話」的思維，轉向「不聽話就自動擋下來」的系統治理機制。
您將學到業界少見的「多代理失敗模式除錯」，並實戰演練如何將 AI 的產出強制串接 GitHub Actions。透過建立嚴格的自動測試與 CI 品質閘門，確保任何不合規、未通過測試的程式碼，都無法被輕易合併與交付。您將從單純的「AI 使用者」，蛻變為能真正管控 AI 產出品質的「指揮官」。
您帶走的將不僅僅是幾招零散的 AI 提示詞技巧，而是一整套「可落地、可管理、可重複使用」的自動交付流水線。
課程採用 Capstone 累積式專案設計，從第 6 堂課開始，您將親手在一個 FastAPI 後端專案上，逐層疊加多代理 AI 開發工作流。完成課程時，您將擁有一套具備「任務分工」、「跨模型互審」、「自動品質驗證」與「錯誤攔截」機制的系統雛形。
這套系統您可以直接帶回公司，套用至既有的專案架構中。無論是為了提升團隊整體的交付效率，或是為了您個人在 2027 年的工程職能轉型鋪路，這套具備實戰價值的自動化工作流，都將是您拉開與一般工程師差距的關鍵武器。
完全適用。本課程雖然使用 FastAPI（Python）作為專案基底來進行示範，但我們真正要傳授的是「系統架構層級的方法論」。
無論您熟悉哪一種程式語言，關於「如何拆解 AI 任務（subagents）」、「如何隔離修改範圍」、「如何進行跨模型互審（Claude × Codex）」以及「如何利用 CI/CD 設立品質驗證閘門」，這些核心底層邏輯與架構思維都是互通的。只要掌握了這套編排與防禦機制，您絕對可以將其無縫移植到 Java、Go、Node.js 或任何您所熟悉的技術堆疊與專案中。
我們提供完善的諮詢管道！若您對課程內容、系統需求或報名流程有任何疑問，歡迎隨時至我們的「常見問答頁面」查詢相關資訊。
此外，您也可以直接加入官方 LINE 帳號：@lccedu，我們將有專人針對您的個人學習需求與專案現況，提供最即時、專業的諮詢協助與建議。
課程留言板
