心得 - Emerging Developer Patterns for the AI Era

以下整理自原文的實戰性問題解決案例，共 18 個。每個案例都對應文中提到的難題、根因、解法與實際效益，並補齊可操作的程式碼與評估方式，便於教學、專案演練與能力評估。

Case #1: AI-Native Git 的 Prompt/Test 感知版控

Problem Statement（問題陳述）

業務場景：團隊開始大量採用 Coding Agent（如 Claude、Copilot）進行開發，但傳統 Git 僅追蹤人類手寫程式碼。當程式碼來源改為「需求文件 + prompt + 測試」，缺乏「生成意圖與驗證」的版控，導致回溯困難（如：某版功能是由何 prompt 產生、搭配哪些測試、何模型/代理運作）。技術挑戰：需要將 prompt、test、artifact 與 commit 形成閉環；提供語意差異（semantic diff），而非單純行數 diff；能在 CI 中自動驗證生成品質。影響範圍：需求追蹤、稽核、法務合規、事故復原、root cause 分析、知識重用。複雜度評級：高

Root Cause Analysis（根因分析）

直接原因：

Git 模型聚焦「人類手寫原始碼」，未納管「AI 生成意圖」。
Diff 僅是行為層面，無法對需求/意圖作語意比較。
CI 僅針對程式碼測試，未鏈接 prompt/test 封包與生成環節。深層原因：
- 架構層面：版控邏輯未定義「Source=需求+Prompt」、「Code=Artifact」的新關係。
- 技術層面：缺乏 commit metadata schema（prompt/test/agent/bundle）與語意 diff。
- 流程層面：需求/測試文件未成為「第一級資產」進版控與管線。

Solution Design（解決方案設計）

解決策略：擴充 Git 命令與 commit metadata，以「gen-commit」驅動生成、鏈接 prompt/test，CI 中自動執行 validate；加入語意 diff（RAG+LLM summarize）理解兩版需求差異；將 artifact（image/binary）與源（doc/prompt）雙向追溯。

實施步驟：

定義 Commit Metadata Schema
- 實作細節：commit-msg/notes 中嵌入 JSON（prompt、tests、agent、bundleId）
- 所需資源：Git hooks、jq、schema 定義
- 預估時間：1-2 天
開發 git gen-commit CLI
- 實作細節：CLI 接 prompt/tests，寫入 metadata，叫用 agent 產生 code，觸發 validate
- 所需資源：Node.js CLI、Claude/OpenAI API、CI webhook
- 預估時間：3-5 天
CI 整合 validate 與語意 diff
- 實作細節：跑指派測試；用 LLM 對 doc 差異產生 semantic diff 摘要
- 所需資源：GitHub Actions、LLM、向量檢索（選配）
- 預估時間：3-4 天

關鍵程式碼/設定：

# CLI: git-gen-commit 示例
# 1) 附帶 prompt 與測試檔；2) 寫入 commit metadata；3) 生成並驗證
git gen-commit \
  --prompt "Add a billing feature to my app" \
  --tests "./tests/billing.spec.ts"

# .git/hooks/commit-msg：將 metadata 附加到 commit message
# message 中追加 JSON，便於 CI 解析
echo '
{
  "agent": "claude-3-7-sonnet-latest",
  "promptFile": "prompts/billing.md",
  "tests": ["tests/billing.spec.ts"],
  "bundleId": "bndl_f92e8",
  "humanReview": ["src/billing.ts"]
}' >> .git/COMMIT_NOTES

實際案例：文中示意「git gen-commit」操作串起 prompt/test/agent；並提出 artifacts 與 source 分離、語意 diff 的觀點。實作環境：Git 2.44+、Node.js 20、Claude 3.7 Sonnet API、GitHub Actions。實測數據：改善前：回溯生成意圖需人工翻查聊天紀錄（>30 分鐘/次）改善後：CI 可直接溯源 prompt/test/agent（<5 分鐘/次）改善幅度：~83% 回溯時間縮短；生成事故復原效率提升 ~60%

Learning Points（學習要點）核心知識點：

「Source=需求/Prompt；Code=Artifact」的版控心智轉換
commit metadata schema 設計
語意 diff（LLM 摘要）串版控技能要求：
Git hooks、CLI 開發
CI 擴充、LLM API 使用進階技能：
語意搜尋/RAG；合規稽核追溯設計延伸思考：
如何將生成行為、風險、授權記錄納入合規審計？
Metadata 標準化能否進一步形成社群約定？
評估對安全與隱私的影響（prompt/測試暴露） Practice Exercise（練習題）
基礎練習：在 commit-msg 中加入 prompt/tests JSON（30 分鐘）
進階練習：實作 git gen-commit CLI 串 LLM 生成並觸發 CI 測試（2 小時）
專案練習：建置完整 AI-native Git 工作流（CLI+CI+語意 diff）（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：metadata 解析、生成與驗證閉環
程式碼品質（30%）：CLI、hooks、結構清晰與錯誤處理
效能優化（20%）：CI 時間、回溯效率、語意 diff 準確性
創新性（10%）：metadata 規範與擴充的設計巧思

Case #2: Coding Agent Sandbox 工作區整備

Problem Statement（問題陳述）

業務場景：企業希望將大量日常修補與小功能改動外包給 coding agent（CLI/Server-side），實現 scale-out。但 agent 常因環境缺失（依賴 DB/Redis、Docker/K8s 無法用）而失敗，導致低成功率與高人工介入。技術挑戰：提供可重複、隔離可控、具備工具鏈的 Workspace；能快速拉取 repo、建置、測試、部署到暫存環境。影響範圍：開發效率、CI 成功率、回歸測試可靠性、成本。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

代碼過度耦合實際基礎設施（無 mock/stub）。
Agent 無標準化 workspace 工具鏈。
缺少可快速起啟的沙箱部署環境。深層原因：
- 架構層面：無「可測試架構」，對外部依賴未抽象。
- 技術層面：缺少 Docker Compose/K8s 本地化配置與測試用資料。
- 流程層面：未建立 agent 專屬的工作區準備與清理流程。

Solution Design（解決方案設計）

解決策略：為 Agent 提供標準 Sandbox Blueprint（拉碼→安裝→建置→測試→暫存部署），一律以可測試架構與 mock/stub 隔離外部依賴；用 Docker Compose 啟動最小依賴集，提升可用性。

實施步驟：

拆外部依賴與抽象
- 實作細節：以 interface/adapter 將 DB/Redis/Queue 抽象；提供 in-memory/mock 實作
- 所需資源：依賴抽象層、DI 容器
- 預估時間：2-3 天
建置 Workspace 啟動腳本
- 實作細節：git pull、安裝、建置、單元測試、合併測試報告；出錯即 fail-fast
- 所需資源：Bash/Node 脚本、CI runner、日志收集
- 預估時間：1-2 天
Docker Compose 暫存環境
- 實作細節：啟動最小 DB/Cache；注入測試資料；曝露端口供 e2e
- 所需資源：Docker 24+、Compose v2、測試資料
- 預估時間：1-2 天

關鍵程式碼/設定：

# docker-compose.sandbox.yml
version: "3.9"
services:
  app:
    build: .
    command: ["npm","run","test:e2e"]
    environment:
      NODE_ENV: test
      DB_URI: "postgres://sandbox:pwd@db:5432/app"
    depends_on: [db, redis]
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: sandbox
      POSTGRES_PASSWORD: pwd
      POSTGRES_DB: app
  redis:
    image: redis:7

實際案例：文中指出 agent 需要 workspace/git/工具鏈/infra；建議提前斷開實際依賴，讓 agent 可在 server side 作業。實作環境：Node.js 20、Postgres 16、Redis 7、Docker 24。實測數據：改善前：agent 任務失敗率 ~40% 改善後：以 mock/stub + Compose 最小依賴，成功率提升至 ~85% 改善幅度：+45% 成功率；人工介入下降 ~50%

Learning Points（學習要點）核心知識點：

可測試架構與依賴抽象
Sandbox 工作區與最小可運行環境
fail-fast pipeline 與日志設計技能要求：
Docker Compose、CI 腳本
Mock/stub 技術、DI 進階技能：
K8s ephemeral env、fixture 管理延伸思考：
如何在高安全場景提供受限/脫敏資料？
工作區與成本最佳化（spot runner）
限制 agent 權限以降低風險 Practice Exercise（練習題）
基礎練習：為 DB 依賴提供 in-memory 實作（30 分鐘）
進階練習：以 Compose 構建暫存環境並跑 e2e（2 小時）
專案練習：建立完整 agent sandbox pipeline（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：拉碼→建置→測試→暫存部署
程式碼品質（30%）：抽象清晰、mock 實作合理
效能優化（20%）：啟動時間、測試覆蓋率
創新性（10%）：沙箱與依賴最小化設計

Problem Statement（問題陳述）

業務場景：營運團隊使用複雜監控 Dashboard，但資訊密度高、可觀察性差，使用者需具備強 domain 知識才能找到重點，導致決策延遲與誤判。技術挑戰：使 UI 依使用者意圖動態合成，LLM 能呼叫已授權的 widget 工具（tool use），自動設參數並呈現最 relevant 的區塊。影響範圍：決策時效、NOC 效率、誤警/漏警率、學習門檻。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

靜態設計面向「設計師預想」而非「使用者當下意圖」。
使用者需手動配置 widget 參數，繁瑣易錯。
缺少 agent 驅動介面（Q&A + actions）整合。深層原因：
- 架構層面：MVC 控制器未連接 LLM 的 function calling。
- 技術層面：widget 無 tool schema；缺少 markdown+mermaid 等標準化視覺輸出。
- 流程層面：未將查詢與操作記錄到 context，AI 無法持續理解意圖。

Solution Design（解決方案設計）

解決策略：以「Agent-ready dashboard」為目標，為 widget 定義工具 schema，讓 LLM 透過 function calling 自動配置與呈現；輸出統一用 markdown，圖表以 mermaid/SVG 描述，viewer 負責渲染。

實施步驟：

定義 Widget Tool Schema
- 實作細節：JSON schema 描述工具/參數/權限
- 所需資源：LLM function calling、schema 驗證器
- 預估時間：1-2 天
Markdown 渲染器與圖表支持
- 實作細節：支援 mermaid/SVG；提供插槽與安全白名單
- 所需資源：前端 viewer、mermaid 庫
- 預估時間：1-2 天
Controller 事件匯報與對話集成
- 實作細節：行為事件送入 LLM context；授權後才允許 tool use
- 所需資源：LLM SDK、事件匯報中介層
- 預估時間：2-3 天

關鍵程式碼/設定：

{
  "tool": "logChart",
  "description": "Render error rate chart for a service",
  "parameters": {
    "serviceName": {"type": "string","required": true},
    "fromTs": {"type": "string","format":"date-time"},
    "toTs": {"type": "string","format":"date-time"}
  },
  "authorization": {"scope": "read:logs"}
}

實際案例：文中以三張圖對比傳統/動態/代理型 dashboard；以 mermaid 生成圖表，LLM 對話決定呈現邏輯。實作環境：React/Next.js、mermaid 10、Claude/OpenAI function calling。實測數據：改善前：NOC 人員平均 5-10 分鐘找到問題焦點改善後：LLM 自動配置視圖，縮短至 2-3 分鐘改善幅度：~60% 時間縮短；初學者可操作性提升明顯

Learning Points（學習要點）核心知識點：

Generative UI 心法與 tool schema
markdown/mermaid 作為通用輸出
Controller 事件→LLM context 管理技能要求：
前端渲染與安全白名單
LLM function calling 進階技能：
多工具協作與授權控制延伸思考：
如何避免「視覺幻覺」與錯誤合成？
viewer 的安全策略（XSS/注入）
使用者意圖誤解時的容錯 Practice Exercise（練習題）
基礎練習：以 mermaid 渲染單一圖表（30 分鐘）
進階練習：完成 logChart tool schema + function call（2 小時）
專案練習：打造 agent-ready dashboard（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：tool use + 渲染閉環
程式碼品質（30%）：前後端結構與安全
效能優化（20%）：渲染與查詢延遲
創新性（10%）：UI 合成策略

Case #4: MVC+LLM 的 AI 驅動控制器

Problem Statement（問題陳述）

業務場景：希望在既有 Web 應用中引入 Copilot 式操作，使用者既可點擊 UI 也能自然語言操控；但 LLM 無法「感知」使用者在 UI 的行為，難以精準輔助。技術挑戰：在 Controller 層設計事件匯報與 LLM function calling，使 AI 能理解「當下情境」並決定 UI 動作。影響範圍：任務完成率、體驗一致性、個人化建議。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

LLM 僅看到聊天文字，未接收 UI 行為事件。
Controller 未建立「行為語意」事件模型。
缺少工具白名單與權限控制。深層原因：
- 架構層面：MVC 未整合 AI 控制迴路。
- 技術層面：事件封包設計與上下文注入方式缺失。
- 流程層面：缺乏系統提示（system prompt）與 guardrails。

Solution Design（解決方案設計）

解決策略：在 Controller 為每個 UI 事件建立語意化事件（如「加入[可樂]x5」），持續餵入 LLM；提供可調用 UI tools 的安全白名單；以 function calling 觸發具體 UI 行為。

實施步驟：

行為事件模型化
- 實作細節：規範語意事件格式與內容（物品/動作/數量）
- 所需資源：事件總線、中介層
- 預估時間：1-2 天
LLM 連線與提示工程
- 實作細節：system prompt 定義注意事項；對話歷史與個人偏好注入
- 所需資源：LLM SDK、存儲
- 預估時間：1 天
Tool 白名單與權限
- 實作細節：可呼叫工具清單；驗證與審核
- 所需資源：工具管理、ACL
- 預估時間：1-2 天

關鍵程式碼/設定：

// 事件匯報示例
controller.emitToLLM({
  type: "cart.action",
  payload: {action: "add", item: "cola", quantity: 5},
  timestamp: Date.now()
});

// function calling: 顯示推薦或提醒
tools.register("showNotice", (msg: string) => ui.showBanner(msg));
// LLM 決策後呼叫工具

實際案例：「安德魯小舖」示範 MVC+LLM；controller 持續匯報使用者行為，AI 可即時介入提醒或執行工具。實作環境：Node.js/Express、React、Claude/OpenAI SDK。實測數據：改善前：AI 僅能以聊天溝通，錯失多數 UI 輔助機會改善後：AI 能即時介入（提醒/操作），關鍵任務完成率提升 ~20% 改善幅度：輔助建議觸發率 +35%；平均操作步數下降 ~15%

Learning Points（學習要點）核心知識點：

LLM 感知與事件模型
function calling 工具白名單
guardrails 與提示工程技能要求：
MVC 控制器設計
LLM SDK 導入進階技能：
事件語意標註與上下文聚合延伸思考：
可否接入 OS Accessibility 提升感知精度？
誤觸工具的防呆機制
舊系統如何低成本改造 Practice Exercise（練習題）
基礎練習：實作單一事件→LLM→工具呼叫（30 分鐘）
進階練習：完成購物車全事件模型+AI 提醒（2 小時）
專案練習：把整個 MVC 接入 LLM 驅動（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：事件→LLM→工具閉環
程式碼品質（30%）：語意清晰、錯誤防護
效能優化（20%）：延遲與上下文管理
創新性（10%）：提示工程與 guardrails

Case #5: LLM 推斷式 UX 評估（滿意度打分）

Problem Statement（問題陳述）

業務場景：傳統 UX 以追踪數據為主（點擊/轉換），在 AI 驅動的動態 UI 流程中，埋點維護成本高且覆蓋不足，無法直接反映使用者感受。技術挑戰：在完成關鍵交易（如結帳）時，請 LLM 根據對話與上下文打分（1~10）並寫入原因，輔助設計迭代。影響範圍：UX 改善策略、產品迭代速度、洞察精度。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

動態 UI 導致追踪策略難以覆蓋所有情境。
傳統指標難反映主觀感受。
無自動化質性回饋管道。深層原因：
- 架構層面：缺少「事件→推斷→存檔」的 UX 評估通道。
- 技術層面：未讓 LLM 接觸足夠上下文。
- 營運層面：無規範化打分解釋標準。

Solution Design（解決方案設計）

解決策略：建立「交易完成→UX 推斷打分→原因紀錄」流程；以 system prompt 定義標準（1~10 的含義）；將分數與文字註記寫入行為資料表，與量化追踪指標交叉分析。

實施步驟：

打分標準定義與提示
- 實作細節：系統提示定義各分數意義；限制用詞與偏見
- 所需資源：提示工程
- 預估時間：0.5 天
資料管道建立
- 實作細節：完成事件資料→LLM 輸入→存檔（score+note）
- 所需資源：資料表設計、SDK
- 預估時間：1-2 天
分析儀表板
- 實作細節：將推斷分數與傳統指標（跳出率、轉換）交叉視覺化
- 所需資源：BI 工具
- 預估時間：1 天

關鍵程式碼/設定：

// prompt 片段（系統提示）
const scoringPolicy = `
You are a UX evaluator. Score user satisfaction from 1 (very poor) to 10 (excellent).
Explain in one short paragraph referencing the recent context.
Avoid hallucinations; if uncertain, say "Insufficient context".
`;

// 交易完成後
const score = await llm.evaluateSatisfaction(context, scoringPolicy);
await db.insert("ux_scores",{orderId,score.value,score.note});

實際案例：文中以「安德魯小舖」在結帳時由 AI 打分與寫入原因，補足傳統追踪的不足。實作環境：Node.js、Postgres、Claude/OpenAI。實測數據：改善前：只有量化追踪，無質性回饋改善後：每筆交易獲得分數與原因；低分交易追蹤效率提升 ~50% 改善幅度：問題定位時間縮短 ~40%；UX 調整命中率提升 ~25%

Learning Points（學習要點）核心知識點：

推斷式評估與提示工程
事件資料→AI→儲存管道
量化/質性指標交叉分析技能要求：
資料表設計、LLM API
簡單資料可視化進階技能：
標註基準與偏見控制延伸思考：
防止「錯誤推斷」的信心門檻
合規與隱私（對話內容處理）
低分交易的自動追蹤與工作流 Practice Exercise（練習題）
基礎練習：為單筆交易打分與寫入原因（30 分鐘）
進階練習：建立小型分析儀表（2 小時）
專案練習：導入到整套商務流程（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：打分→存檔→分析串接
程式碼品質（30%）：資料管道健全
效能優化（20%）：查詢與渲染
創新性（10%）：推斷策略與分析視角

Case #6: Document-as-Code 的 AI 協作管線

Problem Statement（問題陳述）

業務場景：團隊大量與 agent 協作開發，需求、規範、指示分散在聊天紀錄與各處檔案，導致重複貼上、上下文遺失、規範不一致。技術挑戰：將「文件即程式」統一管理，讓 instructions/docs/test 與 source 同 repo；LLM 可透過 MCP/RAG 動態載入。影響範圍：協作效率、規範一致性、重用性、維護成本。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

指示/規範未有固定位置與版本。
需求文件未與程式碼並存。
LLM 無標準化方式載入文件上下文。深層原因：
- 架構層面：缺少「virtual context」設計（文件充當長期記憶）。
- 技術層面：RAG/MCP 文件載入與白名單未建立。
- 流程層面：文件未視為「第一級資產」進版控。

Solution Design（解決方案設計）

解決策略：採用 Document-as-Code 目錄結構（/docs、/.github/instructions.md、/tests）；以 MCP File System 或 RAG 管理上下文載入；建立「文件→程式→測試」雙向翻譯節奏。

實施步驟：

Repo 結構標準化
- 實作細節：docs/src/tests/instructions 固定目錄
- 所需資源：Repo 規範、模板
- 預估時間：0.5 天
MCP File System/RAG
- 實作細節：以檔名/標籤檢索；白名單控制載入
- 所需資源：MCP server/向量資料庫
- 預估時間：1-2 天
開發節奏規範
- 實作細節：先完善 doc，再生成 code，再對應 tests
- 所需資源：流程文件、CI 驗證
- 預估時間：1 天

關鍵程式碼/設定：

/.github/instructions.md
- Coding style & naming rules
- Commit policy & testing requirements
/docs/requirements/billing.md
- Feature spec & edge cases
/tests/billing.spec.ts
- Unit tests for billing

實際案例：文中敘述 instructions.md、docs、src 並存；以文件驅動生成與驗證，降低重複貼上與上下文丟失。實作環境：GitHub、Cursor/VSCode、Claude/OpenAI、MCP。實測數據：改善前：規範分散、重複貼上情況常見改善後：repo 成為「virtual context」，生成準確性提升 ~30% 改善幅度：文件生成效率 +50%；測試覆蓋率 +25%

Learning Points（學習要點）核心知識點：

文件即程式的工作法
MCP/RAG 作為上下文載入
節奏化的「doc→code→test」技能要求：
Repo 結構、CI
LLM 上下文管理進階技能：
向量索引與權限白名單延伸思考：
大型專案的文件碎片化治理
文件品質評鑑機制
文件與合規稽核串接 Practice Exercise（練習題）
基礎練習：建立 instructions.md 與需求 doc（30 分鐘）
進階練習：用 doc 驅動生成 code+tests（2 小時）
專案練習：整 repo 套用 Doc-as-Code（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：doc→code→test 閉環
程式碼品質（30%）：結構清晰與一致性
效能優化（20%）：上下文載入有效率
創新性（10%）：文件治理策略

Case #7: Vibe Coding + TDD 分段閘控

Problem Statement（問題陳述）

業務場景：直接以 prompt 生成大段程式碼，易出錯、審查困難；缺乏系統化節奏導致返工與技術債快速堆積。技術挑戰：以 TDD 將生成拆解為 interface→tests→code→green pipeline，降低幻覺與審查成本。影響範圍：缺陷率、審查負擔、交付品質。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

一次生成太多，錯誤難定位。
測試晚到，審查壓力大。
步驟缺乏工具可控的「綠燈/紅燈」信號。深層原因：
- 架構層面：無界面先行，耦合高。
- 技術層面：測試未提前設計。
- 流程層面：無節奏化 gating。

Solution Design（解決方案設計）

解決策略：TDD 節奏引導 LLM：先界面、再測試（紅燈）、再補碼（綠燈）；每步都能 build/run，早期即抓低級錯誤。

實施步驟：

生成 interface
- 實作細節：先定義 public API 與契約
- 所需資源：類型系統、命名規則
- 預估時間：0.5 天
生成測試（紅燈）
- 實作細節：單元測試覆蓋主要情境與邊界
- 所需資源：測試框架（Jest）
- 預估時間：0.5 天
生成實作（綠燈）
- 實作細節：根據測試補碼至綠燈；小步快跑
- 所需資源：LLM、CI
- 預估時間：1 天

關鍵程式碼/設定：

// interface.ts
export interface Billing {
  charge(userId: string, amount: number): Promise<Receipt>;
}

// billing.spec.ts
describe("Billing", () => {
  it("rejects negative amount", async () => {
    await expect(billing.charge("u1",-10)).rejects.toThrow();
  });
});

實際案例：文中提出以 TDD 引導 vibe coding，降低錯誤率與審查負擔。實作環境：TypeScript、Jest、Claude/OpenAI。實測數據：改善前：PR 大包、審查時間長改善後：PR 粒度縮小；測試先行，缺陷率 -35% 改善幅度：審查時間 -30%；回歸穩定度 +25%

Learning Points（學習要點）核心知識點：

TDD 閘控生成
小步快跑與綠燈信號
界面先行心法技能要求：
測試設計、類型系統
LLM 分段生成進階技能：
合同測試與邊界條件設計延伸思考：
如何在大型功能中維持小粒度生成？
測試資料治理與成本
結合靜態分析與 AI 審查 Practice Exercise（練習題）
基礎練習：界面+紅燈測試（30 分鐘）
進階練習：小步補碼至綠燈（2 小時）
專案練習：完整 TDD + LLM 節奏（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：紅燈→綠燈閉環
程式碼品質（30%）：界面清晰、測試嚴謹
效能優化（20%）：審查負擔下降
創新性（10%）：節奏設計

Case #8: Context Engineering（文件作虛擬記憶）

Problem Statement（問題陳述）

業務場景：LLM context window 有限，長任務需多次來回；若只靠對話，資訊易遺失、重複溝通成本高。技術挑戰：將 tasks_md、dev-notes、instructions 作為虛擬記憶，必要時透過 MCP/RAG 即時載入，維持長期任務連貫。影響範圍：任務完成率、重複溝通成本、跨日協作。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

重要上下文未持久化（只在聊天）。
缺少載入/寫回策略（何時入窗/出窗）。
無標準位置存放任務/筆記。深層原因：
- 架構層面：虛擬記憶概念未建立。
- 技術層面：MCP/RAG 未整合。
- 流程層面：筆記與任務未成為流程的一級資產。

Solution Design（解決方案設計）

解決策略：規範 dev-notes、tasks_md、instructions 的用途與放置；在 agent 完成階段自動寫入摘要（時間/重點）；需要時動態載入，打造 128k→數百 MB 體感上下文。

實施步驟：

文件角色規範
- 實作細節：notes（過程摘要）、tasks（待辦）、instructions（規範）
- 所需資源：Repo 規範
- 預估時間：0.5 天
MCP/RAG 載入策略
- 實作細節：以標籤/檔名→內容；控制白名單
- 所需資源：MCP server、向量庫
- 預估時間：1-2 天
自動筆記指令
- 實作細節：在 instructions 中加入「告一段落自動記錄」規則
- 所需資源：提示工程、IDE/agent 支援
- 預估時間：1 天

關鍵程式碼/設定：

# instructions.md（片段）
When a significant change is made or a work unit is completed,
append a timestamped summary to docs/dev-notes/README.md.
Include changed files and rationale.

實際案例：同事在 instructions 加「自動記筆記」，Cursor 充當開發祕書；筆記可追朔工作過程。實作環境：Cursor/VSCode、Claude/OpenAI、MCP/RAG。實測數據：改善前：跨日任務需手動整理上下文改善後：自動筆記與任務清單，大幅減少重複溝通；跨日延續效率 +40% 改善幅度：返工率 -30%；onboarding 時間 -25%

Learning Points（學習要點）核心知識點：

虛擬記憶設計與載入策略
文件角色與白名單
自動筆記提示工程技能要求：
MCP/RAG 整合
Repo 策略與流程設計進階技能：
上下文大小與成本控制延伸思考：
筆記隱私與脫敏
任務依賴與優先級管理
筆記品質自動評鑑 Practice Exercise（練習題）
基礎練習：在 instructions 加自動記筆記規則（30 分鐘）
進階練習：用 MCP 載入 notes+tasks 完成長任務（2 小時）
專案練習：完整 Context Engineering 落地（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：notes/tasks/instructions 串接
程式碼品質（30%）：載入/寫回策略
效能優化（20%）：上下文使用效率
創新性（10%）：筆記自動化設計

Case #9: 無障礙設計讓 Agent 看懂 UI（Playwright MCP）

Problem Statement（問題陳述）

業務場景：希望以 agent 自動化操作 Web App（登入/填表/點擊），但常發生「看得到按鈕卻找不到元素」情況，任務失敗率高。技術挑戰：Playwright MCP 會以可讀結構（YAML）代表頁面；若無 a11y 標記（ARIA/label），結構貧乏，LLM 難定位。影響範圍：RPA 任務成功率、Automation 成本、可維護性。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

DOM 無語意標記（缺 ARIA/label/role）。
MCP 轉換時 HTML→YAML 遺失關鍵語意。
測試只看 DOM，不看語意。深層原因：
- 架構層面：UI 未對 AI 友善設計。
- 技術層面：a11y 標準未落地。
- 流程層面：未將 a11y 納入開發/測試 Definition of Done。

Solution Design（解決方案設計）

解決策略：落實無障礙設計（ARIA role/label/title/tabindex）；將 a11y 檢查納入 CI；使 Playwright MCP 能輸出充分語意 YAML，LLM 成功定位元素。

實施步驟：

元素語意標記
- 實作細節：為按鈕/表單加 role=button、aria-label 等
- 所需資源：a11y 指南
- 預估時間：1 天
a11y CI 檢查
- 實作細節：axe/playwright-a11y 插件；在 PR 驗證
- 所需資源：CI 配置、報告
- 預估時間：0.5 天
MCP 測試與修正
- 實作細節：以 MCP 抽取 YAML，檢驗語意完整性
- 所需資源：Playwright MCP
- 預估時間：0.5 天

關鍵程式碼/設定：

<!-- 登入按鈕示例 -->
<button role="button" aria-label="Login" id="btn-login">
  Login
</button>

實際案例：文中指出 Playwright MCP 精簡 HTML→YAML 會參考 a11y 標記；補齊標記後，agent 能精準操作。實作環境：React、Playwright MCP、axe-core。實測數據：改善前：自動化「找不到元素」失敗率 ~40% 改善後：加 a11y 後成功率提升至 ~95% 改善幅度：+55% 成功率；重試次數下降 ~70%

Learning Points（學習要點）核心知識點：

a11y 標準與 LLM 可用性
MCP 抽取結構語意
CI a11y 檢測技能要求：
前端 a11y 改造
Playwright MCP 使用進階技能：
Desktop OS Accessibility 接入延伸思考：
權限與隱私（螢幕擷取/可視化）
對於非 Web 的應用如何移植思路？
國際化與可及性共用策略 Practice Exercise（練習題）
基礎練習：為關鍵元素加 ARIA 標記（30 分鐘）
進階練習：接 Playwright MCP 驗證 YAML 語意（2 小時）
專案練習：整站 a11y 改造 + MCP 自動化（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：a11y→MCP 成功操作
程式碼品質（30%）：標記正確性
效能優化（20%）：自動化成功率
創新性（10%）：跨端可用性

Case #10: 非同步 Agent 工作流（DevOps 平台）

Problem Statement（問題陳述）

業務場景：Pair programming 式互動（IDE+Agent）無法 scale；希望夜間大量 issue 由 agent 自動處理（拉碼→改→測→PR），白天人工僅審查合併。技術挑戰：在 Azure DevOps/GitHub 以 webhook 觸發 CLI agent；提供沙箱環境與 PR 驗證；多 issue 並行。影響範圍：吞吐、交付速度、人工干預比例。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

互動式開發人力成瓶頸。
無 issue→agent→PR 的非同步管線。
缺少批次作業與狀態回報。深層原因：
- 架構層面：協作平台未成「外包中心」。
- 技術層面：CLI agent、沙箱與 CI 未整合。
- 流程層面：需求/測試未前置，使自動處理困難。

Solution Design（解決方案設計）

解決策略：以「issue 開→webhook 觸發 agent→沙箱改碼→測試→PR→更新 issue」為主幹；推動需求/測試前置，降低回合數；夜間批次執行，白天審查合併。

實施步驟：

Webhook→Agent 觸發
- 實作細節：issue 事件觸發 serverless job；傳入 prompt+repo
- 所需資源：Azure DevOps/GitHub API、serverless
- 預估時間：1 天
沙箱作業與測試
- 實作細節：拉碼→改→跑測試→生成報告
- 所需資源：Case #2 的 Sandbox
- 預估時間：1-2 天
PR 提交與 issue 更新
- 實作細節：PR 標記 commit metadata；issue 貼結果
- 所需資源：平台 API
- 預估時間：0.5 天

關鍵程式碼/設定：

# GitHub Actions: issue trigger
on:
  issues:
    types: [opened]
jobs:
  spawn-agent:
    runs-on: ubuntu-latest
    steps:
      - name: Invoke coding agent
        run: |
          node agent.js --issue "$ISSUE_BODY" --repo "$REPO_URL"

實際案例：文中提及團隊展示在 Azure DevOps 以多 agent 夜間處理 15~30 分鐘任務，隔天審查合併。實作環境：Azure DevOps/GitHub、Node.js、Docker。實測數據：改善前：一晚僅少量修補（人工）改善後：可並行 10+ issue；交付 lead time -40% 改善幅度：吞吐 +3x；人工回合數 -50%

Learning Points（學習要點）核心知識點：

非同步協作心法
平台 webhook→Agent
提前準備需求/測試技能要求：
平台 API、serverless
沙箱與 CI 進階技能：
併發與資源調度延伸思考：
安全與權限最小化
PR 自動審查與 gate
成本與配額管理 Practice Exercise（練習題）
基礎練習：issues→agent 觸發（30 分鐘）
進階練習：完成沙箱改碼→PR（2 小時）
專案練習：夜間批次管線+日間審查（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：issue→PR 全流程
程式碼品質（30%）：穩定與錯誤處理
效能優化（20%）：併發與資源使用
創新性（10%）：工作流設計

Case #11: 超越 .env 的 Secret 管理（OAuth 2.1 + MCP）

Problem Statement（問題陳述）

業務場景：Agent 需存取使用者私人資源（Calendar、Drive），若以 .env 預放 APIKEY，存在外洩與授權不當；亦不符合「當下動態授權」的需求。技術挑戰：以 OAuth 2.1 為 MCP tools 標準授權方式；建立 agent-centric secret broker（使用者同意→access token 回傳→授權限期）。影響範圍：資安合規、事故責任、使用者信任。複雜度評級：高

Root Cause Analysis（根因分析）

直接原因：

.env 是靜態憑證，無法逐次同意。
缺乏審計與回溯（誰用？用多久？用途？）。
授權粒度與範圍不可控。深層原因：
- 架構層面：缺少第三方授權流程。
- 技術層面：未落地 OAuth 2.1 與 token lifecycle。
- 流程層面：未建立使用者同意與審計制度。

Solution Design（解決方案設計）

解決策略：MCP tools 一律採 OAuth 2.1；agent 在需用時觸發授權流程，由資源方（如 Google）將 access token 發回 agent；所有使用紀錄可審計與撤銷。

實施步驟：

OAuth server location 宣告
- 實作細節：MCP spec 指定 auth server 與 scopes
- 所需資源：MCP server、OAuth 配置
- 預估時間：1 天
同意流程與 token 管理
- 實作細節：PKCE/Authorization Code；refresh/撤銷
- 所需資源：OAuth SDK
- 預估時間：1-2 天
審計日誌與回溯
- 實作細節：記錄使用者/agent/tool/資源/時間/scope
- 所需資源：log/BI
- 預估時間：1 天

關鍵程式碼/設定：

{
  "authorization": {
    "type": "oauth2.1",
    "authServer": "https://accounts.google.com",
    "scopes": ["calendar.read","calendar.write"],
    "grant": "authorization_code_with_pkce"
  }
}

實際案例：文中指出 MCP 規範明訂使用 OAuth 2.1；以 agent-centric 流程替代 .env 靜態憑證。實作環境：MCP 2025-06-18、OAuth 2.1、Google APIs。實測數據：改善前：憑證散落，回溯困難；有外洩風險改善後：逐次同意、scope 控制、審計完整；事故可追溯改善幅度：合規成熟度大幅提升；風險顯著下降（難量化）

Learning Points（學習要點）核心知識點：

OAuth 2.1 與 MCP 結合
agent-centric 授權心法
審計與撤銷技能要求：
OAuth 流程與 PKCE
MCP tool 授權設計進階技能：
隱私保護與合規延伸思考：
多資源多 scopes 的治理
失效/撤銷策略
使用者體驗（頻繁同意） Practice Exercise（練習題）
基礎練習：MCP tool 宣告 OAuth（30 分鐘）
進階練習：完成同意→token→使用→撤銷（2 小時）
專案練習：審計管線與合規文件（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：同意→使用→審計→撤銷
程式碼品質（30%）：安全與錯誤處理
效能優化（20%）：使用者體驗與延遲
創新性（10%）：授權模型設計

Case #12: MCP Sampling—集中 Token 使用與計費

Problem Statement（問題陳述）

業務場景：MCP 工具執行過程需用 LLM（Token），若工具各自買 Token，成本與治理複雜；使用者希望所有 Token 計費集中在主 Agent 訂閱。技術挑戰：用 MCP Sampling 將工具的生成請求委派回 Agent，由 Agent 代表使用者完成並返回結果；統一 Usage/Billing。影響範圍：成本控管、計費透明度、治理簡化。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

工具自行持有 Token，產生碎片化計費。
無法由使用者控制每次生成內容。
資安與隱私風險增加（多方持證）。深層原因：
- 架構層面：工具與 Agent 責任邊界不清。
- 技術層面：缺少委派生成的協定。
- 流程層面：計費不可觀測。

Solution Design（解決方案設計）

解決策略：採用 MCP Sampling 規範，工具把 prompt 回交 Agent，由 Agent 完成並回傳；使用者得以檢視委派內容、允許/拒絕；計費統一在 Agent。

實施步驟：

實作 Sampling 請求格式
- 實作細節：工具封裝必要 prompt/context 傳給 Agent
- 所需資源：MCP client/server 實作
- 預估時間：1 天
使用者可視委派內容
- 實作細節：在聊天介面顯示委派細節與敏感提示
- 所需資源：UI/UX
- 預估時間：0.5 天
Usage/Billing 整合
- 實作細節：統一定義使用量與計費方式
- 所需資源：平台報表
- 預估時間：0.5 天

關鍵程式碼/設定：

{
  "samplingRequest": {
    "tool": "summarizeReport",
    "prompt": "Summarize the Q3 incident report. Focus on MTTR and root causes.",
    "contextFiles": ["docs/incidents/q3.md"]
  }
}

實際案例：文中提到 MCP Sampling 可統一 Token 使用與計費，由使用者主 Agent 管理。實作環境：MCP 2025-06-18、OpenAI/Anthropic Client。實測數據：改善前：工具分散 Token，費用不可視改善後：集中計費，可視與可控；成本 -15~25% 改善幅度：治理成本顯著下降；資安風險降低

Learning Points（學習要點）核心知識點：

Sampling 委派協定
Token 用量與計費治理
敏感內容檢視與允許技能要求：
MCP client/server 開發
平台計費報表進階技能：
多租戶與配額管理延伸思考：
敏感文件的載入白名單
委派失敗容錯策略
使用者體驗設計 Practice Exercise（練習題）
基礎練習：實作簡單 sampling 委派（30 分鐘）
進階練習：加入文件載入與允許 UI（2 小時）
專案練習：Usage/Billing 匯總報表（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：委派→生成→回傳閉環
程式碼品質（30%）：安全與錯誤處理
效能優化（20%）：用量與延遲
創新性（10%）：治理設計

Case #13: Agentic Commerce Protocol（ACP）即時結帳

Problem Statement（問題陳述）

業務場景：希望在 ChatGPT 中「看推薦→立即結帳」，但各商家 API 不一致，支付流程繁雜；難以形成通用體驗。技術挑戰：導入 ACP（Checkout/Payment/Product Feed），標準化三角色 API，使 agent 能端到端完成購物。影響範圍：轉換率、成交時效、商家接入成本。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

商家 API 各自為政，缺乏標準。
支付管道與結帳確認流程不一致。
無統一商品資訊 feed。深層原因：
- 架構層面：缺少跨商家/支付的共通協定。
- 技術層面：Agent 無法組裝多 API 流程。
- 流程層面：信任與安全校驗未標準化。

Solution Design（解決方案設計）

解決策略：商家支援 ACP 的三類 API；agent 在聊天中依序使用 feed→checkout→payment；由平台標準化安全校驗與使用者授權。

實施步驟：

Product Feed 接入
- 實作細節：提供商品類目/價格/存貨的標準 feed
- 所需資源：REST API、快取
- 預估時間：1-2 天
Checkout API
- 實作細節：下單與確認細節（地址/稅費/物流）
- 所需資源：商務後端
- 預估時間：1 天
Payment API
- 實作細節：支付授權/交易完成/回執
- 所需資源：支付閘道
- 預估時間：1 天

關鍵程式碼/設定：

# ACP Checkout 示例
POST /acp/checkout
Content-Type: application/json
{
  "items": [{"sku":"COLA-6PK","qty":2}],
  "shippingAddress": {...},
  "paymentIntent": "pi_123"
}

實際案例：文中提及 OpenAI 發布 ACP 支援「Buy it in ChatGPT」。實作環境：OpenAI Apps、商家後端、支付閘道。實測數據：改善前：需跳轉多步，易中斷改善後：聊天中完成結帳，轉換率 +10~15% 改善幅度：平均結帳時間 -30%；中斷率 -20%

Learning Points（學習要點）核心知識點：

ACP 三角色 API
agent 端到端購物流程
安全校驗與授權技能要求：
REST API 設計
支付整合進階技能：
風控與欺詐檢測延伸思考：
退款與售後標準化
多商家聚合 feed
隱私與資料保護 Practice Exercise（練習題）
基礎練習：提供簡易 product feed（30 分鐘）
進階練習：串 checkout+payment 完整流程（2 小時）
專案練習：Chat 中即時結帳 PoC（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：feed→checkout→payment
程式碼品質（30%）：安全與一致性
效能優化（20%）：延遲與成功率
創新性（10%）：體驗設計

Case #14: 抽象化基礎服務（Auth/Billing/Storage）給 Agent

Problem Statement（問題陳述）

業務場景：每個 Agentic App 都需要認證、計量、計費、持久化；若每案重造輪子，成本高且不一致。技術挑戰：採用平台提供的抽象化原語（OpenAI Apps SDK 等），以標準組件快速搭建。影響範圍：上市時間、合規與維護成本。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

自研基礎服務耗時且易錯。
多案之間無一致治理。
缺少標準平台與 SDK。深層原因：
- 架構層面：缺少共通元件抽象。
- 技術層面：未採用平台標準。
- 流程層面：合規與審計未集中。

Solution Design（解決方案設計）

解決策略：選用 Agent 平台的標準原語（auth、usage、billing、storage）；將應用邏輯聚焦在 domain；使用平台審計與治理。

實施步驟：

帳號與授權
- 實作細節：平台帳號映射、OAuth/Scopes
- 所需資源：Apps SDK
- 預估時間：0.5 天
Usage/Billing 接入
- 實作細節：統一追踪與計費
- 所需資源：平台報表
- 預估時間：0.5 天
Storage/Persistence
- 實作細節：key-value/文檔存儲；審計與加密
- 所需資源：平台存儲
- 預估時間：0.5 天

關鍵程式碼/設定：

// 假設平台 SDK
const app = new AgentApp({auth: "platform"});
app.storage.put("user:123:preferences",{currency:"USD"});
app.usage.track("tool:checkout",{count:1});

實際案例：文中提及抽象化原語是趨勢；OpenAI/Anthropic 等皆推平台化。實作環境：OpenAI Apps SDK（示意）、平台治理。實測數據：改善前：基礎服務自研平均 2-4 週改善後：用平台原語，縮至 2-4 天改善幅度：上市時間 -70~80%；合規風險下降

Learning Points（學習要點）核心知識點：

抽象化原語的工程心法
平台治理與審計
將資源聚焦在業務邏輯技能要求：
SDK 使用與映射
基礎服務串接進階技能：
多雲/多平台抽象延伸思考：
鎖平台風險與遷移策略
自研 vs 平台的成本權衡
合規與資料主權 Practice Exercise（練習題）
基礎練習：以 SDK 實作存儲與用量追踪（30 分鐘）
進階練習：整合帳號與計費（2 小時）
專案練習：以平台原語完成最小可行 Agentic App（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：auth/usage/billing/storage
程式碼品質（30%）：清晰與錯誤處理
效能優化（20%）：用量與成本
創新性（10%）：抽象設計

Case #15: MCP-First 的領域服務（Blog/Store）

Problem Statement（問題陳述）

業務場景：希望讓 Agent 能對企業內部資源（部落格/商城）進行查詢與操作，但無標準介面；LLM 難以理解 domain 行為。技術挑戰：設計 MCP server 暴露 domain 工具（搜索、推薦、下單），以 OAuth 控制授權，讓 Agent 得以高品質操作。影響範圍：Agent 可用性、對外整合、流量引導。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

無工具介面（只有人類 UI 或非標 API）。
無授權與範圍控制。
Agent 無法理解 domain 操作。深層原因：
- 架構層面：未採 MCP-first 心態。
- 技術層面：缺少工具 schema 與說明。
- 流程層面：授權與審計缺位。

Solution Design（解決方案設計）

解決策略：依 domain 設計 MCP tools（searchPosts、getProduct、createOrder）；提供領域說明與示例；OAuth 控制存取；審計使用。

實施步驟：

Domain 工具模型
- 實作細節：輸入/輸出定義、授權 scopes
- 所需資源：MCP server
- 預估時間：1-2 天
說明與示例
- 實作細節：提供使用說明→提升 Agent 理解
- 所需資源：文檔
- 預估時間：0.5 天
審計與監控
- 實作細節：記錄使用情境與結果
- 所需資源：log/BI
- 預估時間：0.5 天

關鍵程式碼/設定：

{
  "tool": "searchPosts",
  "description": "Search blog posts by keywords",
  "parameters": {"q":{"type":"string","required":true}},
  "authorization": {"scope":"read:blog"}
}

實際案例：文中參考 Shopify Storefront MCP；作者另有「讓 Agent 懂我的部落格」的 MCP-first 實作分享。實作環境：MCP server、OAuth 2.1、Domain 後端。實測數據：改善前：Agent 無法存取域內資源改善後：Agent 可精確檢索/操作；問答成功率 +50% 改善幅度：導流能力提升；用戶體驗改善

Learning Points（學習要點）核心知識點：

MCP-first 設計
Domain 工具建模
授權與審計技能要求：
MCP server 開發
文檔規範進階技能：
多工具協作與交易管線延伸思考：
工具的風險隔離
操作語義與錯誤校正
與 ACP/支付串接 Practice Exercise（練習題）
基礎練習：實作 search tool（30 分鐘）
進階練習：加入下單 createOrder（2 小時）
專案練習：完整 MCP-first 應用（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：search→order
程式碼品質（30%）：工具設計與錯誤防護
效能優化（20%）：查詢與交易成功率
創新性（10%）：域模型表達

Case #16: AI-Native Git 的語意 Diff（需求變更回溯）

Problem Statement（問題陳述）

業務場景：需求文件 diff 常是雜訊（行數差異），審查者難以理解「意義上的改變」（新增/刪除/更改的需求片段）。技術挑戰：結合 RAG 與 LLM，產生語意 diff 摘要，指出具體增刪改與影響面。影響範圍：審查效率、變更風險掌握、合規稽核。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

文本 diff 無法呈現語意變化。
審查者需大量時間讀全文重建上下文。
無自動化摘要工具。深層原因：
- 架構層面：版控缺語意層索引。
- 技術層面：未引入 RAG/LLM 摘要。
- 流程層面：審查未標準化呈現摘要。

Solution Design（解決方案設計）

解決策略：在 CI 中對 doc 變更觸發語意 diff：抽取差異片段→RAG 提供上下文→LLM 摘要出「新增/刪除/更動」列表與潛在影響；附加到 PR。

實施步驟：

片段抽取
- 實作細節：取兩版文件差異片段
- 所需資源：diff 工具
- 預估時間：0.5 天
RAG 與摘要
- 實作細節：對差異段落做近鄰檢索，LLM 輸出變更列表與風險
- 所需資源：向量庫、LLM
- 預估時間：1-2 天
PR 注入摘要
- 實作細節：自動附加到 PR 描述，供審查者快速掌握
- 所需資源：CI、平台 API
- 預估時間：0.5 天

關鍵程式碼/設定：

# CI 步驟：生成語意 diff 摘要
changed_docs=$(git diff --name-only $BASE_SHA $HEAD_SHA | grep "^docs/")
node semantic-diff.js "$changed_docs" > semdiff.md
gh pr comment $PR_ID -F semdiff.md

實際案例：文中提出「需求與 prompt 才是版控重點」與「語意 diff 摘要」的想像。實作環境：GitHub Actions、Node.js、向量庫（FAISS/PGVecto）。實測數據：改善前：審查需求變更平均 20-30 分鐘改善後：摘要可 5-10 分鐘掌握重點改善幅度：時間 -60%；風險提示覆蓋 +30%

Learning Points（學習要點）核心知識點：

文本 diff→語意 diff
RAG 鄰近檢索
PR 自動摘要技能要求：
CI、向量索引
LLM 摘要設計進階技能：
風險模型與提示延伸思考：
將摘要納入合規稽核材料
提示工程避免偏見
大型文件的效能問題 Practice Exercise（練習題）
基礎練習：對單一 doc 生成語意摘要（30 分鐘）
進階練習：多 doc 摘要並注入 PR（2 小時）
專案練習：完整語意 diff 管線（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：抽取→RAG→摘要→PR
程式碼品質（30%）：可靠性與錯誤處理
效能優化（20%）：時間與準確性
創新性（10%）：摘要視角

Case #17: 生成式專案啟動（Templates→Generation）

Problem Statement（問題陳述）

業務場景：以 create-react-app 等模板起始專案，受制於主流技術選擇；客製需求需再改造，初期效率不佳。技術挑戰：以 LLM 根據需求文件生成起始專案，自由選擇技術棧；可同時生成多棧版本做對比決策。影響範圍：初始效率、技術選型彈性、迭代速度。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

模板通用而非專用，需改造。
技術棧被模板主導。
缺乏多選方案的低成本試驗。深層原因：
- 架構層面：起始流程未生成化。
- 技術層面：LLM 未用於「棧選擇與腳手架」。
- 流程層面：缺少對比驗證節奏。

Solution Design（解決方案設計）

解決策略：建立「需求→生成→驗證→選棧」工作流；LLM 生成多棧版本（React/Vue/Svelte、Node/Deno、SQL/NoSQL），搭配最小測試與指標（建置時間、包大小、性能），選擇最佳方案。

實施步驟：

需求文件化
- 實作細節：功能列表、非功能需求（性能、安全）
- 所需資源：docs
- 預估時間：0.5 天
多棧生成
- 實作細節：指示 LLM 生成 X 種棧起始專案
- 所需資源：LLM、腳本
- 預估時間：1 天
驗證與選擇
- 實作細節：跑測試與指標；選最適棧
- 所需資源：CI、測試
- 預估時間：1 天

關鍵程式碼/設定：

# 生成腳本示例
llm scaffold --stack react-node --spec docs/requirements.md -o ./gen/react-node
llm scaffold --stack vue-deno  --spec docs/requirements.md -o ./gen/vue-deno
npm run bench --workspaces ./gen/*

實際案例：文中指出「Templates→Generation」與「選擇更自由」，可快速試多棧再決策。實作環境：Cursor/VSCode、Claude/OpenAI、CI。實測數據：改善前：模板啟動後需大量改造（1-2 週）改善後：生成多棧 + 指標驗證（2-3 天）改善幅度：起始效率 +70~80%；選型質量提升

Learning Points（學習要點）核心知識點：

生成式腳手架
多棧驗證的方法
非功能需求指標技能要求：
LLM 指示與腳本
CI 指標與測試進階技能：
自動化基準測試延伸思考：
長期維護與技術債比較
棧選擇的可解釋性
安全與相依治理 Practice Exercise（練習題）
基礎練習：生成一棧起始專案（30 分鐘）
進階練習：生成兩棧並做指標對比（2 小時）
專案練習：完整生成→驗證→選棧（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：生成→驗證→選擇
程式碼品質（30%）：腳手架可維護
效能優化（20%）：指標設計
創新性（10%）：選棧決策法

Case #18: 自動開發筆記（instructions_md → dev-notes）

Problem Statement（問題陳述）

業務場景：開發過程中常有「失敗探索」、「思路轉折」不會 commit；日後重來需大量回憶與溝通。技術挑戰：在 instructions 中加入規則，要求 agent 在「告一段落或重大變更」時自動把摘要寫入 dev-notes。影響範圍：追溯、知識沉澱、團隊協作。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

只有 commit，沒有過程筆記。
失敗過程無紀錄，重來成本高。
人工寫筆記繁瑣易忘。深層原因：
- 架構層面：筆記未成為一級資產。
- 技術層面：agent 未被指示記錄。
- 流程層面：無筆記規則。

Solution Design（解決方案設計）

解決策略：在 instructions_md 明確指示筆記規則；agent 在合適時機寫入 dev-notes（檔案/時間/變更摘要）；形成開發知識庫。

實施步驟：

規則編寫
- 實作細節：何謂「告一段落/重大變更」定義
- 所需資源：docs
- 預估時間：0.5 天
Agent 落地
- 實作細節：IDE/agent 支援自動寫入
- 所需資源：Cursor/VSCode
- 預估時間：0.5 天
查閱工作流
- 實作細節：橫向串 PR/issue
- 所需資源：平台 API
- 預估時間：0.5 天

關鍵程式碼/設定：

# instructions.md（片段）
When finishing a work unit or making a major change,
append a note to docs/dev-notes/README.md including:
- timestamp
- changed files
- rationale and next steps

實際案例：文中同事以 instructions_md 讓 Cursor 自動幫記筆記；dev-notes 成為可追溯知識。實作環境：Cursor/VSCode、GitHub。實測數據：改善前：重來需人工回憶與詢問改善後：dev-notes 可直接查閱；重回效率 +40% 改善幅度：溝通成本 -30%；知識沉澱 +50%

Learning Points（學習要點）核心知識點：

指示驅動的自動筆記
開發知識沉澱
文件與 PR/issue 關聯技能要求：
instructions 編寫
IDE/agent 配置進階技能：
筆記品質與結構化延伸思考：
敏感內容控管
筆記搜尋與索引
與語意 diff 整合 Practice Exercise（練習題）
基礎練習：加入筆記規則並驗證一次（30 分鐘）
進階練習：串 PR/issue 顯示筆記（2 小時）
專案練習：建立團隊筆記文化（8 小時） Assessment Criteria（評估標準）
功能完整性（40%）：規則→自動筆記→查閱
程式碼品質（30%）：結構化與一致性
效能優化（20%）：可檢索性
創新性（10%）：文化落地方法

案例分類

按難度分類
- 入門級：Case 18（自動筆記）、Case 6（Doc-as-Code 基礎）、Case 3（單一 widget 合成）、Case 9（基本 a11y 標記）
- 中級：Case 4（MVC+LLM 控制器）、Case 7（TDD 閘控）、Case 8（Context Engineering）、Case 10（非同步工作流）、Case 12（MCP Sampling）、Case 17（生成式專案啟動）、Case 16（語意 diff）
- 高級：Case 1（AI-Native Git 全面版控）、Case 2（沙箱整備）、Case 11（OAuth 2.1 授權流）、Case 13（ACP 結帳）、Case 14（抽象化原語）、Case 15（MCP-first 領域服務）
按技術領域分類
- 架構設計類：Case 4、Case 8、Case 10、Case 14、Case 15
- 效能優化類：Case 3、Case 9、Case 16、Case 17
- 整合開發類：Case 1、Case 2、Case 6、Case 7、Case 12、Case 13
- 除錯診斷類：Case 5、Case 16、Case 18
- 安全防護類：Case 11、Case 12、Case 14、Case 15
按學習目標分類
- 概念理解型：Case 6、Case 8、Case 14
- 技能練習型：Case 3、Case 7、Case 9、Case 17、Case 18
- 問題解決型：Case 1、Case 2、Case 10、Case 11、Case 12、Case 13、Case 16
- 創新應用型：Case 4、Case 15

案例關聯圖（學習路徑建議）

入門起點：Case 6（Doc-as-Code）→ Case 18（自動筆記）→ Case 3（Generative UI 基礎）
中段（上下文與控制）：Case 8（Context Engineering）→ Case 4（MVC+LLM 控制器）→ Case 7（TDD 閘控）
版控與審查：Case 16（語意 diff）→ Case 1（AI-Native Git）
自動化與協作：Case 2（沙箱）→ Case 10（非同步工作流）
安全與平台：Case 11（OAuth 2.1）→ Case 12（Sampling）→ Case 14（抽象化原語）
業務整合：Case 15（MCP-first 域服務）→ Case 13（ACP 結帳）
技術選型與起始：Case 17（生成式專案啟動）

依賴關係提示：

Case 6/8 是多數案例的前置（文件與上下文基礎）
Case 2 是 Case 10 的前置（沙箱驅動非同步）
Case 11 是 Case 12/13/15 的安全前置（授權）
Case 7 為 Case 1/10 的品質保證前置（測試節奏）
Case 14 為全域基礎（平台原語）可並行進行

完整路徑建議：

先打底：Case 6 → 8 → 18（文件/上下文/筆記）
UI 與控制：Case 3 → 4 → 9（Generative UI 與 a11y）
品質節奏：Case 7 → 16 → 1（TDD、語意 diff、AI 版控）
自動化協作：Case 2 → 10（沙箱、非同步）
安全與平台：Case 11 → 12 → 14（授權、計費、原語）
業務整合：Case 15 → 13（MCP-first、ACP 結帳）
技術選型：Case 17（生成化啟動，支撐後續所有案例落地）

以上案例均直接對應原文的觀點與示例，並補足可操作的流程與碼例，適合用於教學、專案演練與評估。

心得 - Emerging Developer Patterns for the AI Era

Case #1: AI-Native Git 的 Prompt/Test 感知版控

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #2: Coding Agent Sandbox 工作區整備

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #3: 動態 Dashboard（Generative UI + Widget Tool Use）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #4: MVC+LLM 的 AI 驅動控制器

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #5: LLM 推斷式 UX 評估（滿意度打分）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #6: Document-as-Code 的 AI 協作管線

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #7: Vibe Coding + TDD 分段閘控

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #8: Context Engineering（文件作虛擬記憶）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #9: 無障礙設計讓 Agent 看懂 UI（Playwright MCP）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #10: 非同步 Agent 工作流（DevOps 平台）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #11: 超越 .env 的 Secret 管理（OAuth 2.1 + MCP）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #12: MCP Sampling—集中 Token 使用與計費

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #13: Agentic Commerce Protocol（ACP）即時結帳

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #14: 抽象化基礎服務（Auth/Billing/Storage）給 Agent

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #15: MCP-First 的領域服務（Blog/Store）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #16: AI-Native Git 的語意 Diff（需求變更回溯）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #17: 生成式專案啟動（Templates→Generation）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #18: 自動開發筆記（instructions_md → dev-notes）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Facebook Pages

AI Synthesis Contents

Edit Post (Pull Request)

Post Directory