為什麼你的 AI 比較笨？可能犯了這三大上下文錯誤
· 約 9 分鐘 活動AI 工具Claude Code

為什麼你的 AI 比較笨？可能犯了這三大上下文錯誤

文章目錄（5 節）

影片

生成式 AI 小聚的現場錄影，全長 2 小時 47 分鐘。

你的 AI 累積使用時數有多少？

這是我之前參加生成式 AI 小聚活動當工程師好朋友時，認識了大師姐 Vivi。他邀我來跟麻瓜 (非工程師) 背景的朋友分享我在使用 AI 進行開發時的心得，現場還有錄影。這次分享內容是我本來想要寫的「保護你的上下文」，但你看我這次講了三個小時，你就知道為什麼我拖這麼久寫不出來 XD

看之前先問自己一句

  • 這次分享我有對非工程師背景的人調整了簡報的內容，適合對象是有一定使用 AI 經驗的人。
  • 先問自己，你的 AI 累積使用時數有多少？這次分享的內容，我建議至少 100 小時以上再來看，比較會有感。
  • 想要提升 AI 輸出的品質，不是去收集很多人分享的 Prompt，而是你必須在乎你提供的「上下文 (Context)」的品質。

整個分享的方式我分成兩部分：前面講心法，後面講規格開發。

前半場：心法

每個心法搭配我實際使用的方式做說明。

後半場：規格開發

後面的規格開發會提到 BMad-method、spec-kit、Memory Bank 等做法。

當天有來聽的人的心得

Vivi Chen 大師姐

Leo Chen 詳細的筆記

Peggy 麻瓜天花板 XD

繼續變得更好

這次分享北鼻也有來聽，隔天我們討論後發現有很多可以改善的地方。

下一場要調整的地方

  • 我感覺大家好像直接看 Demo 比較有感覺也比較有興趣，應該更多示範demo。
  • 後續也有收到大家的回饋。

只好有空再來開一場了（誤

AI 幫你先整理好了

這部影片（標題：AI Coding 心得分享 Jackle）是一場長達 2 小時 47 分鐘的深度技術分享會。

講者 Jackle 系統性地拆解了在使用 AI 進行編程 (AI Coding) 時，從新手 (麻瓜) 到高階使用者會遇到的痛點，並提出了一套以「上下文工程 (Context Engineering)」為核心的框架來解決這些問題。

  • 這場分享會的框架核心是：AI 輸出的品質，取決於你提供的「上下文 (Context)」的品質

講者圍繞這個核心，提出了導致 AI 犯錯的三大主因，並分享了如何透過「正確性」、「完整性」和「空間效率」三個層面來優化上下文，最後介紹了如 SDD (規格驅動開發) 和 Memory Bank 等高階方法論。

三大主因對應三個優化層面 AI 犯錯的三個根源各自對應一個上下文優化層面：錯誤的資訊對應正確性，靠 CLAUDE.md、階層式小本本與儲思盆處理；遺漏的資訊對應完整性，靠 SDD、Snapshot 與 Remix 處理；雜訊對應空間效率，靠監控用量、壓縮與子代理處理。 AI 犯錯的三大主因 上下文的三個優化層面 錯誤的資訊 Garbage In, Garbage Out 遺漏的資訊 AI 產生幻覺的主因 雜訊 提供了無關的資訊 正確性 Correctness CLAUDE.md、階層式小本本、儲思盆 完整性 Completeness SDD、Snapshot、Remix 空間效率 Efficiency 監控用量、壓縮、子代理

左右滑動看完整內容

三大主因與三個優化層面是一對一的：錯誤的資訊靠正確性擋、遺漏的資訊靠完整性補、雜訊靠空間效率清。

影片內容框架與時間軸

分享會五個部分的時間分佈 全長 2 小時 47 分 58 秒。第一部分開場與痛點分析佔 15 分鐘，第二部分上下文工程三大支柱佔 41 分鐘，第三部分完整性與空間效率佔 20 分鐘，第四部分規格驅動開發佔 56 分鐘是全場最長的一段，第五部分總結問答佔 36 分鐘。 全長 2:47:58 0:00 0:30 1:00 1:30 2:00 2:30 第一部分 00:00–15:27 開場與痛點分析 第二部分 15:27–56:35 上下文工程三大支柱 第三部分 56:35–1:16:22 完整性與空間效率 第四部分 1:16:22–2:12:22 規格驅動開發 SDD 第五部分 2:12:22–2:47:58 總結 Q&A

左右滑動看完整內容

五個部分在 2 小時 47 分裡的分佈，第四部分的規格驅動開發吃掉將近一小時。

第一部分：開場與痛點分析 ( [00:00] - [15:27] )

  1. [00:00] - [02:41] 開場寒暄與設備測試。
  2. [02:41] - [06:52] 破冰：觀眾背景調查
    • 講者為了調整內容難度，開始調查聽眾使用 AI Coding 的經驗。
    • 詢問使用過的工具 (如 ChatGPT, Cursor, Codium 等) [03:38]、使用 AI 開發過的專案數量 [05:07]，以及累積的時數 [05:57]。
  3. [06:52] - [09:18] 講者經驗分享
    • 分享自己的工程師背景、目前主力使用的工具 (Codium)，以及使用 Waka 追蹤的編程時數 [07:59]。
  4. [09:18] - [15:27] 定義核心痛點：錯誤與 Prompt
    • 點出 AI Coding 最大的痛苦是 AI 頻繁輸出錯誤 [09:33]，導致開發者陷入「嘗試 -> 報錯 -> 貼上錯誤 -> 再次嘗試」的無效循環 [10:53]。
    • 這引導到 Prompt Engineering (提示詞工程) 的重要性，並強調這項技能是需要透過「刻意練習」和承受痛苦才能精進的 [15:23]。

第二部分：上下文工程 (Context Engineering) 的三大支柱 ( [15:27] - [56:35] )

[16:44] - [27:32] 導致 AI 犯錯的三大主因

講者提出，比起 Prompt，更重要的是「上下文工程」。他用圖表解釋 Context Window [17:00]，並總結 AI 輸出錯誤的三個根源：

[24:12] 錯誤的資訊

(Garbage In, Garbage Out)

[24:55] 遺漏的資訊

(AI 產生幻覺的主因)

[26:01] 雜訊

(提供了無關的資訊)

[27:32] - [56:35] 優化 AI 輸出 (一)：正確性 (Correctness)

[31:49] 核心工具：CLAUDE.md / AGENTS.md

介紹如何使用「小本本」(系統提示詞檔案) 來確保 AI 每次都能獲取正確的基礎資訊。

[33:07] 關鍵技巧：階層式 CLAUDE.md

分享他的進階用法：在不同的資料夾（如前端/後端）放置不同的 .md 檔案，能精準提供相關上下文，避免「雜訊」[35:48]。

[44:35] 核心概念：儲思盆 (Pensieve)

將 AI 學習流程比喻為哈利波特的「儲思盆」。

[45:40] /lesson 指令

他展示自訂的 /lesson 指令，能自動將當前對話中學到的「教訓」或「規則」，抽離並儲存到對應的 CLAUDE.md 檔案中 [47:39]。

[49:08] /review 指令

當 CLAUDE.md 變得肥大時，使用 /review 指令將其「減肥」，把「規格 (Spec)」分離出去，只保留核心「規則 (Rule)」[49:40]。

[52:10] (補充) 工程師的進階技巧

提及透過架構、型別約束 [52:34] 和撰寫「測試」[53:28] 來確保正確性。

第三部分：上下文工程的另外兩大支柱 ( [56:35] - [01:16:22] )

[56:35] - [01:00:34] 優化 AI 輸出 (二)：完整性 (Completeness)

[56:58] SDD (規格驅動開發)

提到這是目前最夯的方法（後面詳述）。

[57:21] Snapshot (快照)

將專案結構製作成快照，讓 AI 快速理解。

[58:39] Remix (工具)

介紹 re-mix 工具，能將整個專案打包成單一檔案，適用於小型專案，讓 AI 擁有 100% 完整的上下文 [59:23]。

[01:00:34] - [01:16:22] 優化 AI 輸出 (三)：空間效率 (Efficiency)

[01:00:45] 監控 Context 用量

他喜歡 Claude Code 的原因之一是它會顯示 Context Window 的使用率 (如 16%)，他會控制在 50% 以下 [01:01:17]。

[01:03:09] 壓縮 (Compression)

內建的自動壓縮

討論自動壓縮的缺點。

自己的 /compress 指令

他展示了自己的 /compress 指令 [01:04:55]，能將對話摘要成一份 MD 檔案，再開一個新對話載入，以維持高效。

[01:12:28] 子代理 (Sub-Agents)

工具內建

使用 Sub-agent（Codium 功能）將讀取檔案等「雜訊」任務，交給獨立的 Context Window 處理 [01:12:53]。

[01:13:30] 人工 Sub-agent

建議沒有此功能的用戶，可以「手動開新視窗」當作子代理。

第四部分：高階方法論 - 規格驅動開發 (SDD) ( [01:16:22] - [02:12:22] )

[01:18:46] - [01:28:48] (穿插 Q&A) 介紹講者的其他自訂指令 (如 /autotest, /doc, /test arrow 等)。

[01:33:04] - [01:35:42] 深入介紹 SDD (Spec Driven Development)

  1. [01:33:30] 介紹 BM (Bgent-Mark)

    講者使用的是一套名為 "BM" 的 SDD 框架。

  2. [01:35:55] BM 的角色扮演

    BM 透過模擬軟體開發團隊中的不同角色 (分析師、架構師、PM、UX 等) 來生成規格 [01:38:53]。

  3. [01:41:29] BM 的文件流程

    展示其工作流程：PRD (產品需求文件) -> Epic(s) (大型功能) -> Story(s) (用戶故事)。每一步都是獨立的 Context，產出文件後再交給下一步，避免錯誤傳遞 (蝴蝶效應) [01:46:24]。

[01:49:36] - [01:58:04] 推薦「麻瓜」的 SDD：Memory Bank

[01:50:16] Memory Bank

推薦一套更輕量、適合新手的 SDD 方法論「Memory Bank」。

[01:51:00] Memory Bank 解說

它只用一個 Prompt，就能自動維護 6 份核心規格文件（如 brief.md, product_context.md, active_context.md, progress.md 等）[01:51:45]。

[01:53:33] Demo

展示一個使用 Memory Bank 開發的 Wiki 助理小專案。

[01:58:04] - [02:12:22] 總結：從 Memory Bank 到 BM

講者說明他自己目前的開發流程，是 BM (大型功能) 和自訂規格 (小型修改) 的混合體，而這套系統是從 Memory Bank 演化而來的。

[02:04:37] 關於測試的 Q&A

討論了 AI 寫測試的困難點，他會先請 AI 提出「測試案例」[02:10:39]，他看過後再請 AI 實作。

第五部分：總結 Q&A ( [02:12:22] - [02:47:58] )

[02:14:58]

關於 CLAUDE.ms 和 Slash Command 的關係。

[02:18:19]

在 SDD 流程中如何處理小修改（結論：直接改自訂的規格，而非 BM 生成的 Story）。

[02:37:21]

index.md (檔案索引) 如何自動更新 (使用 BM 內建的 /index 指令)。

[02:38:41]

Token (用量) 不夠用的解法 (精算用量、推薦的工具組合)。

[02:45:46]

如何同步 Claude Code 的 CLAUDE.md 和其他工具的 AGENTS.md (使用自訂腳本)。

[02:47:37]

如何用 AI 協助部署。

留言