
為什麼你的 AI 比較笨?可能犯了這三大上下文錯誤
影片
你的 AI 累積使用時數有多少?
這是我之前參加生成式 AI 小聚活動當工程師好朋友時,認識了大師姐 Vivi
他邀我來跟麻瓜 (非工程師) 背景的朋友分享我在使用 AI 進行開發時的心得
現場還有錄影
這次分享內容是我本來想要寫的「保護你的上下文」
但你看我這次講了三個小時
你就知道為什麼我拖這麼久寫不出來 XD
這次分享我有對非工程師背景的人調整了簡報的內容
適合對象是有一定使用 AI 經驗的人
先問自己
你的 AI 累積使用時數有多少?
這次分享的內容
我建議至少 100 小時以上再來看
比較會有感
想要提升 AI 輸出的品質
不是去收集很多人分享的 Prompt
而是你必須在乎你提供的「上下文 (Context)」的品質
整個分享的方式我分成兩部分:前面講心法,後面講規格開發
每個心法搭配我實際使用的方式做說明
後面的規格開發會提到 BMad-method、spec-kit、Memory Bank 等做法
當天有來聽的人的心得
繼續變得更好
這次分享北鼻也有來聽
隔天我們討論後發現有很多可以改善的地方
我感覺大家好像直接看 Demo 比較有感覺也比較有興趣
應該更多示範demo
後續也有收到大家的回饋
只好有空再來開一場了(誤
AI 幫你先整理好了
這部影片(標題:AI Coding 心得分享 Jackle)
是一場長達 2 小時 47 分鐘的深度技術分享會。
講者 Jackle 系統性地拆解了在使用 AI 進行編程 (AI Coding) 時
從新手 (麻瓜) 到高階使用者會遇到的痛點
並提出了一套以「上下文工程 (Context Engineering)」為核心的框架來解決這些問題。
這場分享會的框架核心是:AI 輸出的品質,取決於你提供的「上下文 (Context)」的品質
講者圍繞這個核心,提出了導致 AI 犯錯的三大主因
並分享了如何透過「正確性」、「完整性」和「空間效率」三個層面來優化上下文
最後介紹了如 SDD (規格驅動開發) 和 Memory Bank 等高階方法論。
影片內容框架與時間軸
第一部分:開場與痛點分析 ( [00:00] - [15:27] )
- [00:00] - [02:41] 開場寒暄與設備測試。
- [02:41] - [06:52] 破冰:觀眾背景調查
- 講者為了調整內容難度,開始調查聽眾使用 AI Coding 的經驗。
- 詢問使用過的工具 (如 ChatGPT, Cursor, Codium 等) [03:38]、使用 AI 開發過的專案數量 [05:07],以及累積的時數 [05:57]。
- [06:52] - [09:18] 講者經驗分享
- 分享自己的工程師背景、目前主力使用的工具 (Codium),以及使用 Waka 追蹤的編程時數 [07:59]。
- [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)
- 講者提出,比起 Prompt,更重要的是「上下文工程」。他用圖表解釋 Context Window [17:00],並總結 AI 輸出錯誤的三個根源:
第三部分:上下文工程的另外兩大支柱 ( [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 指令 [01:04:55],能將對話摘要成一份 MD 檔案,再開一個新對話載入,以維持高效。
- [01:00:45] 監控 Context 用量
- [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)
- [01:33:30] 介紹 BM (Bgent-Mark):講者使用的是一套名為 "BM" 的 SDD 框架。
- [01:35:55] BM 的角色扮演:BM 透過模擬軟體開發團隊中的不同角色 (分析師、架構師、PM、UX 等) 來生成規格 [01:38:53]。
- [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] )