從「手動編碼」到「代理協作」：利用 Claude Code 實現開發效率翻倍

 在 AI 工具爆炸式成長的今天，開發模式正經歷一場從「輔助輸入」到「代理協作（Agentic Workflow）」的典範轉移。Claude Code 的出現，定義了全新的開發邊界：它不再只是回答問題的 Chatbot，而是一個具備自主權的開發代理，能理解代碼庫、執行終端機指令、進行多檔案重構，並在人類工程師的監督下解決複雜的架構問題。

身為開發者，如何在 AI 時代保持領先？以下是我實踐出的五個核心策略。

1. 採納「探索、規劃、實施」的專業工作流

直接讓 AI 寫 Code 通常是技術債的開始。將開發過程拆解為四個階段，能極大化 AI 的邏輯正確性：

• 探索 (Explore)： 進入 Plan Mode。讓 Claude 遍歷代碼庫、分析現有架構並釐清依賴關係，此階段嚴禁修改任何代碼。

• 規劃 (Plan)： 要求 Claude 產出詳細的實施提案（RFC）。你可以在文字編輯器中微調邏輯，確保方案符合系統擴充性。

• 實施 (Implement)： 切換至 Normal Mode。讓 Claude 根據核准的計劃執行編寫，並同步進行單元測試驗證。

• 提交 (Commit)： 完成後，由 Claude 根據變更範疇撰寫描述性的 Git Message 並建立 PR，確保版本控制的品質。

2. 定義驗證標準：最高槓桿的工程行為

當 AI 具備自我修復能力時，「定義成功」比「編寫代碼」更重要。提供明確的驗證邊界，是 senior 工程師展現價值的地方：

• 測試驅動代理： 與其要求「實施功能」，不如要求「先撰寫 Test Cases，實施後必須通過測試」。

• 視覺與 UI 驗證： 針對前端變更，可配合 Chrome 擴充功能獲取 Dom Tree 或截圖，讓 Claude 對比 Design Spec 與實作結果的差異。

• 根因分析 (RCA)： 遇報錯時，要求 Claude 「追蹤 Call Stack 並修復根本原因而非抑制症狀」，確保系統的健壯性。

3. 精準的上下文架構管理 (Context Architecture)

Claude 的表現與上下文視窗（Context Window）的雜訊成反比。積極管理 Context 是維持開發效率的關鍵：

• CLAUDE.md： 在專案根目錄建立此配置檔，寫入 Build Commands、代碼規範（Linting Rules）與特定工作流。Claude 在啟動時會自動讀取，這就是你的「專案指南」。

• 精確參考： 善用 @ 符號標記特定的檔案路徑，減少 AI 盲目搜尋造成的 Context 浪費。

• 子代理 (Subagents) 策略： 面對大型重構，指派子代理在獨立上下文中進行特定模組的研究，避免主對話空間充斥過多技術雜訊。

4. 自動化整合：GitHub Actions 與 CI/CD

將 Claude 深度嵌入現有的開發自動化流程中：

• 標記即回應 (Mention-to-Act)： 透過 GitHub Actions 整合，你只需在 PR 評論中標記 @claude，它就能分析代碼變更、進行 Code Review 或直接實施 Bugfix。

• 安全性考量： 嚴禁將 API Key 硬編碼，應統一透過 GitHub Secrets 管理，並限制代理的操作權限。

5. 未來工程師的必備技能：Agent Skills & MCP

未來的工程師將演變為「代理管理者（Agent Orchestrator）」。建議優先掌握以下前瞻技術：

• 自定義技能 (Custom Skills)： 在 .claude/skills/ 中定義可重用的工作流（如：特定的遷移腳本、API 文件生成），讓 Claude 能「學會」你的私有工具鏈。

• 模型上下文協定 (Model Context Protocol, MCP)： 利用 MCP Server 讓 Claude 打破沙盒限制，直接與 Google Drive、Slack、Figma 或數據庫進行交互，實現跨平台的自動化。

---

學習資源與專業認證

Anthropic 目前提供了多項免費的 AI 實踐課程。完成後獲得的憑證，不僅是技術力的證明，更是你轉型「AI 原生開發者」的里程碑：

• Claude Code in Action：深度解析如何將代理環境整合至生產流程。

• Introduction to Agent Skills：學習如何構建與分享特定的代理技能。

你可以直接訪問官方教學平台 anthropic.skilljar.com 並註冊，開啟你的 AI 轉型之旅。

告別咒語，擁抱工程：AI 時代的開發者生存指南

 

告別咒語，擁抱工程：AI 時代的開發者生存指南——從咒語師到上下文架構師

[建議插圖：一張現代感的圖片，左邊是混亂的魔法陣與螢光代碼，右邊是整齊的建築藍圖與結構化數據，中間有一條進化的路徑。]

【導讀】 AI 寫代碼的速度已遠超人類思考，傳統開發模式正瀕臨失效。如果你還在靠「唸咒語」引導 AI，小心被代碼洪流淹沒。本文提出三大工程化支柱，教你如何管理認知負債，轉型為新時代的「上下文架構師」。

---

在軟體工程領域，我們正經歷一場前所未有的範式轉移（Paradigm Shift）。

AI 的崛起不僅改變了我們寫代碼的方式，更顛覆了整個開發流程。如果你還只是把 GitHub Copilot 或 Cursor 視為高階的自動完成（Autocomplete）工具，或者依賴雜亂的 .cursorrules 檔案和複製貼上的提示詞（Prompt）來管理 AI，那麼你可能還沒真正意識到這場變革的深度。

變革的核心：速度與認知的衝突

AI 生成代碼的速度已經遠超人類的思考和評估能力——AI 只需幾秒鐘，就能完成人類可能需要幾分鐘甚至幾天的工作。

知名管理大師 Jurgen Appelo 甚至直言：「Scrum 已成為歷史。」這並不是說敏捷方法論失效了，而是傳統以人為本的慢節奏開發模式，已無法匹配 AI 噴湧而出的程式碼洪流。

在這個新時代，開發者的核心職能不再是單純「產出代碼」，而是轉向：

1. 管理認知負債（Cognitive Debt）

2. 工程化 AI 的上下文（Context）

為了不被這股速度淹沒，並真正釋放 AI 的潛力，我們需要一套全新的軟體工程協議。這套協議建立在三個核心支柱之上，讓開發者從依賴運氣的「咒語師」轉型為掌握全局的「上下文架構師」。

下面，讓我們逐一探討這些支柱，並分享實踐指南。

---

支柱一：將 Vibe Coding 視為策略性工具——快而不亂

[建議插圖：一個衝浪者在巨大的代碼浪潮上平穩滑行。]

「直覺式開發」（Vibe Coding）常常被誤解為一種隨意的、追求極速的 Coding 方式。但事實上，在工程領域，它應該是策略性的工具，用來在最短時間內驗證想法。

問題在於，許多開發者沉迷於「快」的快感，卻忽略了如何將這種速度轉化為長期穩定的基礎。真正的高手，知道如何在 Vibe Coding 中注入紀律，避免程式碼淪為不可控的混亂。

正確實踐 Vibe Coding 的三個關鍵原則：

1. 先有架構，後有直覺（快而不亂）

在啟動 AI 之前，花一點時間規劃系統的核心架構。這不需要複雜的 UML 圖，一張簡單的手繪圖表或文字描述，就能確定主要模組、資料流向和關鍵介面。

• 好處： 避免程式碼成為技術債，讓 AI 在明確的邊界內運作，提高輸出品質。

• 範例： 開發 Web 應用時，先定義後端 API 的端點和資料模型，再讓 AI 填入實作細節。

2. 模組化思維

即使是直覺式開發，也要強迫自己將功能拆分成獨立的模組。

• 好處： 便於後續重構和擴展，更重要的是，它讓 AI 的上下文保持乾淨、可控。

• 對比： 讓 AI 一次性生成整個應用（❌ 糾纏的邏輯） vs 拆分成「用戶驗證」「資料儲存」模組（✅ 精準工作，減少錯誤）。

3. 收斂能力

知道何時停下來是高手與新手的區別。當你完成 MVP（最小可行性產品）或驗證核心想法後，立刻切換模式。

• 行動： 將 Vibe Coding 的臨時方案收斂成穩健的架構。這可能涉及手動重寫部分代碼、添加註解，或整合到版本控制系統中。

• 心態： Vibe Coding 是起點，不是終點。

透過這些原則，Vibe Coding 從一種「快樂的混亂」轉變為高效的策略工具。

---

支柱二：實施 CDLC——將上下文工程化

[建議插圖：一個現代化的流水線，傳送帶上運送的是結構化的 Prompt 符號，經過測試儀器。]

過去，我們常常依賴試錯式的「咒語」（Prompt）來引導 AI，但這種方式低效且不可靠。你還在從論壇或筆記本中複製貼上雜亂的指令嗎？是時候拋棄這種做法了！

我們需要將 AI 的上下文視為一種工程產出，像程式碼一樣進行管理。這就是 Context Development Lifecycle (CDLC) 框架的核心，由 DevOps 之父 Patrick Debois 提出。它將上下文從隱性知識轉化為可維護、可測試、可分發的資產。

CDLC 框架的四個進化階段（閉環）：

1. 生成 (Generate) — 結構化你的隱性知識 別再追求完美的「一句話咒語」。相反，將腦中的架構決定、業務邏輯和編碼規範結構化為 AI 可執行的規則包。例如，使用 JSON 或 YAML 格式定義 Prompt 模板，將變數參數化。這讓 Prompt 轉化為動態的數據結構，便於重用。

2. 評估 (Evaluate) — 關鍵的 CI/CD（★最重要★） 這是 CDLC 中最具革命性的部分！借鑒 Spec by Example (SBE) 方法，我們不僅測試程式碼是否能運行，還要驗證 AI 的「行為」是否符合開發者的「意圖」。例如，為 API 定義輸入/輸出範例，讓 AI 生成代碼後自動檢查是否匹配。這是從傳統 TDD 進化到**「意圖驅動驗證」**，確保 AI 不會產生幻覺。

3. 分發 (Distribute) — 知識供應鏈運維 像管理 npm 包一樣，將上下文規則包版本化並跨團隊分發。使用 Git 儲存庫或專門的 Prompt 管理系統，讓團隊成員能輕鬆拉取最新版本。這建立了知識供應鏈的運維機制，確保團隊協作的一致性。

4. 觀察 (Observe) — 實戰中的回饋循環 在生產環境中監測 AI 的表現。如果 AI 犯錯，是規則模糊還是衝突？收集回饋，迭代規則包。就像監控系統一樣，建立指標（如錯誤率、生成時間），形成持續改進的循環。

實施 CDLC 後，你將從「咒語試錯」轉向工程化管理，讓 AI 成為可靠的夥伴。

---

支柱三：定義 AI 世代的 Scrum 會議新協議——強迫人類慢下來思考

[建議插圖：一個團隊圍在螢幕前，螢幕上顯示著複雜的 Mob Review 代碼，有人舉手示意暫停思考。]

當 AI 能在 10 秒內完成過去兩週的工作量時，團隊的挑戰不再是產出不足，而是如何管理認知負債和 AI 幻覺。

傳統 Scrum 會議需要進化，強迫人類「慢下來」進行深度思考，確保品質和知識對齊。

建立新的 Scrum 會議節奏：

1. Deep PBR (產品待辦清單精鍊) —— 流程的「心臟」

• 頻率： 高頻（每週 2-3 次），作為「慢軌道」的思考時間。

• 關鍵觀念： 在 AI 時代，「精確定義規格」就是開發的核心。 團隊產出高品質的 SBE 實例，這些實例不僅成為 AI 的 Prompt，還作為驗證 AI 輸出的黃金準則。事實上，當 PBR 完成時，開發工作已進展 80%。

2. Debt-Clearing Daily (債務清理站會) —— 攔截認知負債

• 做什麼： 拋棄傳統的流水帳報告，聚焦一個問題：「有沒有哪段 AI 產出的程式碼，人類已經看不懂了？」

• 解決方案： 如果發現認知負債，立刻啟動 15-30 分鐘的 Mob Review（群體審查），團隊集體解剖代碼，確保知識對齊。這不僅清除債務，還強化團隊智慧。

3. Tool-Chain Retro (工具鏈回顧會) —— 優化「人機協作協議」

• 做什麼： 檢討 Prompt 策略的失效點、AI 模型的錯誤率，以及如何優化開發環境（如整合更多自動化測試）。這是持續優化人機協作的機會，讓下一個迭代更高效。

這些新協議讓 Scrum 從「加速產出」轉向**「管理品質」**，在 AI 洪流中維持人類的控制力。

---

總結：數位時代的專業主義

「模型會變，但你的業務邏輯不變。」

AI 模型如 GPT-4 或 Claude 3 會不斷演進，甚至被新技術取代，但企業的核心業務邏輯和架構決策是恆久的。

真正的專業主義在於將 AI 的「快」轉化為「穩」，從依賴雜亂指令的「咒語師」轉型為管理知識的**「上下文架構師」**。

在 AI 寫出每一行程式碼的背後，都必須有一個人類敢於站出來說：**「我懂它，我負責。」**這不僅是技術技能，更是現代開發者的專業姿態。

擁抱這套新協議，你不僅能生存於 AI 時代，還能引領變革。讓我們一起從工程視角重新定義軟體開發吧！

---

你目前在開發流程中遇到了哪些 AI 管理上的挑戰？你更傾向於當一個「咒語師」還是「架構師」？歡迎在下方留言分享你的看法！

---

#軟體工程 #人工智慧 #AI開發 #DevOps #CDLC #敏捷開發 #Scrum #程式設計 #職涯發展

效率革命：構建基於 Google Gemini 的模組化 AI 工作流

在 AI 驅動的開發範式中，我們不再是編寫每一行邏輯，而是建立一個「編排系統」（Orchestration System）。以下是利用 Google AI 技術實現「從內容生成到自動執行」的完整技術路徑。

一、 核心架構：AI 工作流的四層模型

一個健壯的 AI 工作流必須像微服務架構一樣，具備模組化與可觀測性。

1. 感知層 (Ingestion)：透過 Google Drive API 或 Vertex AI Vision 收集數據。

2. 邏輯層 (Reasoning)：由 Gemini 1.5 Pro 進行結構化思考與決策。

3. 執行層 (Action)：透過 Function Calling 串接 Google Workspace 或外部 API。

4. 監控層 (Observability)：利用 Google Cloud Logging 追蹤 AI 的決策路徑與 Token 消耗。

---

二、 技術實作路徑：從原型到生產環境

1. 模組化 Prompt 工程：結構化提示 (Structured Prompts)

在 Google AI Studio 中，不要使用長篇大論的敘述，應採用「變數化」設計。

• System Instruction: 定義 AI 的角色與限制（例如：你是一位嚴謹的專案排程師）。

• Input Variables: 使用 {{input_data}} 標籤，便於後續在 Google Sheets 或程式碼中批次替換。

• Output Schema: 強制要求輸出為 JSON 格式。這是模組化的命脈——只有結構化數據，下一個模組（如自動發信程式）才能解讀。

JSON

// 預期的結構化輸出範例
{
  "task_priority": "High",
  "action_required": "Email_Supplier",
  "reasoning": "Inventory levels for Item_A dropped below 15%."
}

2. 中間件轉發：Google Apps Script (低代碼路徑)

這是將 Google Sheets 變成「AI 指揮中心」最有效的方式。你可以撰寫一個簡單的腳本，將表格內容發送到 Gemini API，並將結果回填。

• 場景應用：當 Google 表單收到新的客戶需求，腳本自動觸發 Gemini 進行分類，並根據分類將任務派發到不同的 Trello 看板或 Gmail 轉發。

3. 進階執行力：Function Calling (函式調用)

這是 AI 從「說」到「做」的關鍵技術。Gemini API 允許你定義一系列工具（Tools），AI 會根據語境決定「何時」以及「如何」使用這些工具。

Python

# 定義一個查詢庫存的工具函數
def get_inventory_stock(item_name: str):
    """查詢特定商品的即時庫存數量"""
    # 這裡串接你的資料庫或 Google Sheets API
    return db.query(item_name)

# 將工具傳遞給 Gemini
model = GenerativeModel("gemini-1.5-pro")
chat = model.start_chat()
response = chat.send_message("目前妖怪御守還有多少貨？", tools=[get_inventory_stock])

---

三、 實戰範例：自動化 Vlog 內容生產流水線

假設你要管理一個旅遊 Vlog 頻道，我們可以建立以下模組化流程：

模組名稱	使用技術	輸入內容	AI 任務	輸出/執行動作
素材分析	Vertex AI (Multimodal)	原始錄影檔	識別關鍵畫面、語音轉文字	結構化分鏡腳本
文案轉化	Gemini 1.5 Flash	腳本與主題	撰寫標題、SEO 描述與社群貼文	多平台文案 JSON
自動排程	Google Calendar API	發布計劃	尋找最佳發布時間點	自動佔用日曆時段
庫存/週邊管理	Apps Script + Sheets	銷售數據	監控週邊商品庫存	紅色警示與自動補貨提醒

---

四、 關鍵的 Trade-offs 與架構考量

身為架構師，在設計時必須權衡以下三點：

• 成本 (Cost)：Gemini 1.5 Flash 速度快且便宜，適合處理簡單的分類與格式化；Pro 模型則留給需要複雜邏輯推理的環節。

• 延遲 (Latency)：為了提升用戶體驗，應採用「非同步處理」（Asynchronous Processing）。不要讓用戶在前端等待 AI 生成，而是處理完後透過通知（Webhook）回傳。

• 安全性 (Safety)：避免讓 AI 直接擁有「寫入」核心資料庫的最高權限。應設計一個「隔離區」（Staging Area），所有 AI 的執行動作需經過一層驗證邏輯或人工審核。

---

五、 總結：流程設計能力即資產

未來的技術競爭，在於誰能將 Gemini 的推理能力與 Google Workspace 的執行能力完美封裝成一個個獨立、可重複使用的「積木」。

「Prompt 是火花，工作流才是引擎。」

---

以下我為你撰寫了一段完整的 Google Apps Script。它具備以下特性：

1. 結構化輸出：讓你可以自定義系統指令（System Instruction）。

2. 錯誤攔截：當 API 失效或 Token 超限時會給出明確提示。

3. 靈活性：你可以直接在試算表格格中使用 =GEMINI(A2, B2)。

---

第一步：獲取 API Key

1. 前往 Google AI Studio。

2. 點擊 "Get API key" 並複製該金鑰。

第二步：部署腳本

1. 打開你的 Google Sheets。

2. 點擊選單：延伸功能 > Apps Script。

3. 刪除原有代碼，貼入以下內容：

JavaScript

/**
 * 調用 Google Gemini API 的自定義函數
 * * @param {string} prompt 使用者輸入的內容
 * @param {string} systemInstruction (選填) 設定 AI 的角色或邏輯（例如：你是一位專業文案師）
 * @return {string} AI 生成的結果
 * @customfunction
 */
function GEMINI(prompt, systemInstruction = "你是一位專業的助手，請提供簡潔且結構化的回答。") {
  
  // 1. 設定你的 API Key (建議將來存放在 Script Properties 中更安全)
  const API_KEY = 'YOUR_API_KEY_HERE'; // <--- 請在此處貼上你的 API Key
  const API_URL = `https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:generateContent?key=${API_KEY}`;

  if (!prompt) return "錯誤：請輸入提示內容";

  // 2. 構建請求載體 (Payload)
  // 我們使用 Gemini 1.5 Flash，因為它速度快、成本低，非常適合批次處理表格數據
  const payload = {
    "contents": [
      {
        "role": "user",
        "parts": [{ "text": prompt }]
      }
    ],
    "system_instruction": {
      "parts": [{ "text": systemInstruction }]
    },
    "generationConfig": {
      "temperature": 0.7,
      "maxOutputTokens": 800,
    }
  };

  const options = {
    "method": "post",
    "contentType": "application/json",
    "payload": JSON.stringify(payload),
    "muteHttpExceptions": true
  };

  try {
    // 3. 發送請求
    const response = UrlFetchApp.fetch(API_URL, options);
    const json = JSON.parse(response.getContentText());

    // 4. 解析結果
    if (json.candidates && json.candidates[0].content && json.candidates[0].content.parts) {
      return json.candidates[0].content.parts[0].text.trim();
    } else {
      return "錯誤分析：" + response.getContentText();
    }
  } catch (e) {
    return "系統錯誤：" + e.toString();
  }
}

第三步：在試算表中使用

現在回到你的 Google Sheets，你可以像使用 SUM() 一樣使用 AI 了：

A 欄 (原始資料)	B 欄 (系統指令)	C 欄 (公式)
客戶說：鞋子尺寸不合想退貨	你是一位客服專家，請判斷情緒並給出簡短回覆建議	=GEMINI(A2, B2)
健行筆記：今日攻頂玉山，雲海很美	你是一位 Vlog 攝影師，請幫這段文字生成 3 個吸睛的標題	=GEMINI(A3, B3)

---

💡 架構師的進階實戰建議：

1. 批次處理的限制：Google Apps Script 的 UrlFetchApp 在單次執行中有時間限制（通常是 6 分鐘）。如果你有幾千行資料，建議不要一次全部拉下公式，而是分批拖曳填充。

2. 安全存取：在生產環境中，不要把 API Key 直接寫在代碼裡。點擊 Apps Script 左側的「齒輪（專案設定）」，找到「指令碼屬性」，新增一個 GEMINI_API_KEY，然後在代碼中用 PropertiesService.getScriptProperties().getProperty('GEMINI_API_KEY') 來調用。

3. 結構化輸出的威力：

   • 如果你希望 C 欄直接變成可用的 JSON。

   • 在 B 欄（系統指令）加入："請嚴格以 JSON 格式回覆，包含 {'sentiment': '...', 'urgent': boolean}"。

   • 這樣你的下一個模組（例如自動發信腳本）就能直接讀取 C 欄的屬性。

這就是模組化工作流的基礎——你已經成功把 Gemini 的大腦，封裝進了一個標準化的 Excel 函數積木中！