這一講回答一個問題：把筆記放在一個資料夾裡（Obsidian 叫它 vault），而且一直整理下去，請 AI 做事時到底有什麼不同？內容有四個好處、六個開發案例，以及分享成果時怎麼分清楚「做過」和「還沒做」。整套系統長什麼樣子、AI 助理怎麼分工，看第 3 講；vault 怎麼建起來，看第 4 講。
這是第 3 講的延伸，接在「AI 助理怎麼分工」後面講，課堂約 10～12 分鐘。案例都改寫成一般情境，不是哪個單位的真實資料。
先講結論
有了 vault，AI 每次開工前找得到相關資料；事後你也查得出，它是根據什麼下判斷的。
收集、整理、抓重點、做成成品，這四步沒有變。多出來的好處是：那些可以一用再用的背景資料，直接交給 AI 去讀，讓它一起幫忙查資料、排計畫、寫程式，也幫忙複核（再檢查一遍別人做好的東西）。
學員最常接著問的一題是：「花時間建 vault，除了整理筆記，實際做事有什麼差？」這一講就是在回答它。後面的開發案例只是其中一種答案。如果你不寫程式，看懂下面〈一張表看懂差別〉那張對照就夠了。
四個好處：找得到、查得回、接得上、驗得過
每個好處都有前提，講的時候要一起說。
| 好處 | vault 裡放了什麼 | 你會看到什麼 | 一定要先說清楚的前提 |
|---|---|---|---|
| 找得到（不用每次從頭交代） | 專案背景、專有名詞、之前做過的決定、現在做到哪，都有固定的地方可以查 | 一件做了好幾週的工作要接著做，AI 會先查前因後果，再來問你 | 資料要真的找得到，還要寫清楚適用在哪裡、是哪一天的資料 |
| 查得回（答案找得到出處） | 原始檔、整理好的概念頁、出處連結，還有這一頁是不是還在草稿 | 你可以點回原文，看 AI 有沒有引錯 | 有附出處，不代表引得對。版本和內容還是要自己對一下 |
| 接得上（整理一次，用很多次） | 素材抓完重點後，連到相關的概念、專案和你以前的想法 | 同一份材料可以拿來問問題、寫報告、備課，或用在下一個專案 | 只收不整理，也不拿出來用，這個好處不會自己出現 |
| 接得上（長期的工作可以交接） | 規格、說好不做的事、驗收劇本（照著操作一遍、確認有沒有做對的步驟）、測試結果、為什麼這樣決定 | 開一段新的對話、換一個開發者、換一個 AI，都接得下去 | vault 存的是決定和證據；程式碼和執行環境，還是放在各自的系統裡 |
| 驗得過（分工做，也驗收得了） | 大家共用的資料入口，還有每個角色能看什麼、能改什麼 | 整理、開發、複核可以分給不同的角色 | 資料錯了，好幾個 AI 會一起跟著錯。所以還是要人來審，也要有獨立的檢查 |
一張表看懂差別
| 只靠一次聊天 | 有一個一直在整理的 vault |
|---|---|
| 每次都要重講背景，聊完就很難接著做 | AI 從固定的入口查背景，也查得到上次的決定 |
| AI 給了結論，但根據是什麼，散在對話裡 | 答案連得回原始檔，也連得到驗收的證據 |
| 換一個 AI 工具，就要重新教一次 | 純文字檔哪個工具都讀得懂，再看每個工具被允許碰哪些資料 |
講者提醒：這裡比的是資料和過程有沒有留下來、找不找得回來。有了 vault，不保證一定比較快、比較省錢，或不會出錯。沒有量過前後的差別，就不要說省了幾成。
寫程式時，vault 和程式庫各放什麼
如果你會寫程式，或請 AI 幫你寫，東西會分兩個地方放。程式庫是放程式碼的地方，vault 放的是程式碼以外的部分：
| 放在 vault | 放在程式庫 |
|---|---|
| 需求、會議結論、說好不做的事 | 程式碼 |
| 規格、驗收劇本、做了哪些決定、為什麼 | 設定檔、測試程式 |
| 測試結果、複核意見、試用回饋、放行紀錄（誰同意可以上線） | 執行環境，以及部署腳本（把程式放上主機的步驟） |
兩邊要互相指路：vault 裡的規格，寫清楚程式放在哪個程式庫；程式庫的說明檔，也寫清楚規格在哪份文件。上課時不要把 vault 講成放程式碼的倉庫。它裝的是：為什麼這樣做、做到哪裡、怎樣才算做對。
六個開發案例
每個案例後面都標了狀態。講的時候照標籤講，「做過」「決定了」「構想」的完成度不一樣，不要講成同一種（說明見下方〈分享成果時，四種狀態分開講〉）。
案例 A｜做一張報表：從一句話的需求，到使用單位驗收｜✅ 做過
某個單位要一張新報表。一開始的需求通常只有一句話，不會講清楚要哪些欄位、資料從哪裡來、誰可以看、特殊狀況怎麼處理、怎樣才算對。
| 階段 | vault 留下什麼 | AI 做什麼 | 人決定什麼 |
|---|---|---|---|
| 開工前 | 會議紀錄、現有欄位的定義、給誰用、說好不做的事 | 找出還沒講清楚的地方、列出要確認的問題、把工作切成幾段 | 這張報表要達成什麼、做到哪裡為止、哪些結果不能接受 |
| 開發中 | 規格、驗收劇本、測試資料從哪來、每一段的結果 | 寫計畫、寫程式、跑測試、回報哪裡失敗 | 看實際的畫面，走一遍實際的工作流程，指出 AI 不知道的現場狀況 |
| 交付前 | 測試、獨立的複核、試用回饋、放行紀錄 | 一條一條對照驗收條件，列出哪些完成、哪些還沒 | 能不能交給使用單位試用，或正式上線 |
台上可以這樣說：「報表一開始只有一句話。AI 可以幫忙設計、寫程式，但要先問清楚：誰看、看什麼、資料從哪來、怎樣算對。最後拿使用者真的會做的操作步驟，一步一步驗收。」
案例 B｜接手沒有文件的舊系統：把查到的東西留下來｜🔎 有調查工作，情境式講法
有人問：「這個欄位是怎麼算出來的？」舊系統沒有文件，AI 第一次只能一路往回查：看畫面、看系統之間傳資料的介面（API）、看程式碼、看資料從哪裡來。下一步查什麼，要看上一步查到什麼。這種工作有人叫它「考古」。如果最後只留下聊天裡的一句答案，下次又得從頭查一遍。
vault 應該留下這五樣：
- 已經確認的資料怎麼流、從哪裡來
- 查過哪些地方、什麼時候查的
- 還沒證實的假設
- 想過、後來被推翻的做法，以及為什麼推翻
- 下次接手的人要先看哪裡
台上可以這樣說：「第一次讓 AI 考古，到底有沒有省時間，很難說。第二次碰到同一個系統，不用再把所有前提重推一遍，這時候才看得出累積下來的東西有什麼用。」
要說清楚：這是把實際做過的調查工作，改寫成教學用的情境，不是這個問題真的發生過。vault 也取代不了直接看程式碼、實際去查資料。
案例 C｜先選對做法：一般程式、AI 加固定流程，還是 AI 代理｜📝 有決策紀錄
「把一份 Excel 轉成指定的欄位」和「查出一個不熟的系統為什麼出問題」，都叫開發需求，做法卻完全不同。
先說兩個詞。LLM 就是 ChatGPT、Claude 這類會讀也會寫的 AI。AI 代理（Agent）是讓 AI 自己決定下一步要做什麼，邊查邊往下走。
| 題目長什麼樣 | 比較適合的做法 | vault 記下的判斷 |
|---|---|---|
| 規則固定、欄位也固定 | 寫一般的程式，加上測試 | 輸入什麼、輸出什麼、欄位規則、出錯的例子 |
| 要寫出一段文字，但步驟是固定的 | 用 LLM，配上固定的步驟和檢查 | 給 AI 的指令（prompt）是哪一版、輸出長什麼樣、品質要到哪裡才算過 |
| 下一步查什麼，要看剛剛查到什麼 | 讓 AI 代理去調查，但限制它能做什麼 | 目標、可以用哪些工具、可以碰哪些資料、什麼時候該停、查過什麼的紀錄 |
判斷時只要問一句：下一步做什麼，是誰決定的？如果是人或固定的規則決定，就用不到 AI 代理。要 AI 自己決定下一步查什麼，才是 AI 代理的題目。用得到 LLM，不代表就要用 AI 代理。
台上可以這樣說：「vault 裡除了寫 AI 要做什麼，也記下當初為什麼選這種做法。下次有類似的需求，就不用從『現在流行哪個工具』開始吵。」
案例 D｜讓 AI 查工作上的資料：給它一個只能查、不能改的工具｜💡 延伸構想，還沒做
假設 AI 要回答某一筆申請、或某一項資產現在是什麼狀態。vault 記下這個查詢工具的說明：用來做什麼、要給它什麼、它會回什麼、誰可以查、哪些欄位要遮起來、查太久或出錯時怎麼回報。但工具真正去查的時候，還是要由系統背後處理資料的那一端（後端）確認身分和權限，並留下誰查了什麼的紀錄（稽核紀錄）。
台上可以這樣說：「說明書只是告訴 AI 有什麼可以用，真正的門鎖要裝在工具和後端。一開始只給它查，要讓它改資料，另外設一道人工核准。」
這只是架構示意，不能說成已經上線的服務。
案例 E｜AI 說「做完了」：拿測試和操作劇本來對｜✅ 做過
同一個功能，要測四種情況：正常使用、剛好卡在上下限（邊界）、輸入錯誤、沒有權限的人來用。vault 存下驗收條件、不該通過的例子（反例）、測試結果、人實際試用的意見，還有複核的結論。下次修改時，把同一組條件再跑一次，確認原本好的功能沒有被改壞。
台上可以這樣說：「AI 回一句『做完了』不算完成。完成是一組事先講好、看得到的結果。你可以不一行一行讀程式，但要看得懂工作流程有沒有真的走得通。」
不要把「某一組測試全部通過」講成「整個系統已經正式上線」。
案例 F｜換一個 AI 或換人接手：先把證據交接好｜📊 做法可行，效益還沒量測
原本那段 AI 對話結束了。下一個接手的人（或 AI），先從 vault 找到這些：這次要做到什麼、說好不做什麼、現在是哪個版本、還剩哪些問題、已經跑過哪些測試、上次為什麼被退回。接著再對照程式庫裡實際的狀態，開始工作。
台上可以這樣說：「帶得走的是資料、規格和決策紀錄。新的 AI 接手後，還是要重新確認自己能用哪些工具、現場現在是什麼狀況。」
「換了 AI 模型以後省了多少時間」，目前沒有做過對照量測。把它當成可以觀察的預期好處就好，不講數字。
分享成果時，四種狀態分開講
這一段也是給你的提醒：以後你分享自己用 AI 做出來的東西，也可以照這四種狀態分開講。
| 狀態 | 可以怎麼講 | 不要講成 |
|---|---|---|
| ✅ 做過 | 有需求和決策、分段開發、測試、複核的紀錄。先拿掉認得出人或單位的細節（去識別）再講，而且只講紀錄有涵蓋的那一段 | 「整個系統都上線了」 |
| 📝 決定了、還沒交付 | 講你怎麼判斷的，例如「固定的流程，不硬做成 AI 代理」 | 已經做好的成品 |
| 💡 規劃中 | 標明是「延伸構想」 | 已經上線的成果 |
| 📊 還沒量測 | 講道理：為什麼可能比較快 | 省了幾成工時、成本降多少、準確率提高幾 % |
真的想算出數字，先固定同一組工作，量人花的總時間（包括審查和重做的時間），還有合格做完幾件，再比較有 vault 和沒有 vault 差多少。
展示用的資料：只用去識別過的例子，或自己重新做的樣本。公司文件、帳號、檔案路徑、內部截圖和敏感資料，都不要放進對外的投影片。