業州愚公去年底接了一個整理客戶服務手冊的案子，當時的做法是每次開新對話就重新上傳相關文件和重新打要求，結果到第二個星期就開始搞混新舊版文件。後來他使用了 Claude 的「專案」功能，可以讓資料在專案中累積，不需要每次都重新上傳文件，從而提高了工作效率。這個案子讓業州愚公體會到使用合適的工具可以帶來顯著的工作便利和效率提升。
菜鳥之友系列：《AI 工具實操與提示詞》・工具篇作者：業州愚公
去年底我接了一個活：幫一家小公司整理客戶服務手冊。底稿三十多頁，還有一套內部術語表。我的做法很「原始」——每次開新對話，就把相關文件重新上傳一遍，再把要求重新打一遍。
頭一個星期還行。到第二個星期，我開始搞混：這個對話裡上傳的是新版還是舊版？最崩潰的一次，我拿著 AI 寫的段落交給對方核對，對方回了一句：「我們根本沒有這個條款。」——因為那個對話裡，我上傳的是三個月前的舊稿。
問題的根源很簡單：對話是一次性的，但我的資料不是。每一次新對話都是一間空屋子，我得把傢具搬進去、擺好，然後這間屋子用完就拆了。後來我換了思路：把資料養在一個固定的「抽屜」裡，而不是每次都往對話裡塞。這個抽屜，在 Claude 裡就叫專案（Project）。這篇文章把它的用法講清楚，順帶說一說跟它搭檔的Artifacts——一個能讓 AI 當場把東西「做出來」給你看的側邊窗口。介面細節以官方最新版本為準，這類產品改版很快。
打開 Claude，在側邊欄找到「Projects」，點進去新建一個專案。建好之後，你會得到一個相對獨立的空間，主要由三部分組成：
| 組成部分 | 它是什麼 | 解決的問題 |
|---|---|---|
| 知識庫（Project knowledge） | 你上傳到專案裡的文件，專案內所有對話都能引用 | 免去每次對話重複上傳資料 |
| 專案指令（Project instructions） | 針對這個專案寫的常駐說明 | 免去每次重複交代背景、口吻、要求 |
| 專案內對話 | 在這個專案裡開的所有對話 | 紀錄集中在一起，不散落在聊天列表裡 |
一句話概括：知識庫管「它知道什麼」，專案指令管「它該怎麼做」，專案內對話管「紀錄放哪」。專案屬於付費方案的功能（Pro、Team 等方案可用；免費用戶能否使用、各項額度，以官方最新版本為準，我不在這裡報數字，因為報了很快就過時）。
上傳文件這件事，看起來沒有技術含量，其實是最容易做壞的一步。我踩過的坑，總結成三條規矩。第一條：餵「最終版」，不要餵「過程稿」。我當年把新舊兩版手冊都留在知識庫裡，想著「資料多總沒錯」。結果 AI 引用時拿了舊版條款來回答，就出了前面說的事故。知識庫裡的文件，AI 是真的會讀、會引的——舊資料不是「躺在那裡不礙事」，而是會污染答案。現在我上傳之前，先刪掉要淘汰的版本，知識庫裡永遠只留當前有效的那一份。
第二條：一個專案只管一件事。我最開始建了一個「工作資料庫」，什麼都往裡塞：客戶手冊、會議紀錄、個人筆記。結果每問一個問題，AI 都在一大堆不相干的資料裡翻，答案要麼跑題、要麼把 A 事務的數字安到 B 事務頭上。後來我拆成了幾個專案。專案越專，答案越準——因為 AI 檢索的範圍小了、干擾少了。
第三條：文件寧可多分、不要一大坨。與其把所有內容合成一個幾百頁的大 PDF，不如按主題拆成多個文件。某一部分更新了，只替換那一個文件，維護方便，AI 定位也更直接。
另外有個細節：上傳知識庫之後，建議先問它一句驗證性的問題。比如上傳完手冊，我會問「根據知識庫裡的資料，我們的退換貨政策是什麼？」答得準，說明文件讀進去了；答得含糊，就檢查是不是文件格式太亂。驗證條件不能靠「我覺得它應該讀到了」——這是我用 AI 這幾年學到的最重要的一課。
專案知識庫解決的是「它知道什麼」，專案指令解決的是「它怎麼說、怎麼做」。這一欄的內容會自動作用於專案內的每一個新對話，不用重複交代。
我的手冊專案裡，指令大概長這樣（節選）：
你在協助維護一家軟體公司的客戶服務手冊。所有回答必須基於知識庫中的文件；知識庫裡沒有的內容，明確說「知識庫中沒有相關記載」，不要自行補充。語氣平實，用繁體中文，避免行銷腔。
幾個寫法上的要點：
有人會問：這跟 ChatGPT 的自訂指令有什麼區別？上一篇寫過 ChatGPT 的自訂指令和專案空間，想法類似，都是「設定一次、處處生效」。差別在於：ChatGPT 的自訂指令更偏「我這個人的偏好」，Claude 的專案指令更偏「這個活兒的規矩」——一個是人的設定檔，一個是工程的施工規範。做具體項目時，後者的針對性明顯更強。
前四節講的是「資料管理」，接下來這個功能管的是「成果輸出」。你讓 AI 寫一段 HTML 網頁、做一張流程圖、寫一份文檔，一般的體驗是：它輸出一大段代碼，你看著那面「代碼牆」腦補它長什麼樣。Artifacts 把「腦補」這一步省了：當 Claude 生成這類內容時，它會在對話旁邊開出一個獨立的預覽窗格，內容直接渲染出來——寫網頁就顯示網頁本尊，畫流程圖就顯示圖本尊，你每改一句要求，它更新之後立刻能在窗格裡看到效果。
| 你要它做的東西 | Artifacts 的呈現方式 | 對新手的意義 |
|---|---|---|
| HTML 網頁 / React 元件 | 窗格內直接渲染，可互動點按 | 不用自己架環境、開瀏覽器除錯 |
| Mermaid 流程圖、圖表 | 渲染成圖形 | 看圖比看代碼直觀得多 |
| 長文檔、方案書 | 獨立文檔視圖，與對話分離 | 方便整篇複製或修改，不淹沒在聊天記錄裡 |
| 程式碼片段 | 帶高亮的代碼視圖 | 複製即用，不用從散文裡摳代碼 |
我自己的用法舉個例子：整理手冊時，我讓它「把退換貨流程畫成一張流程圖」。放在普通對話裡，它會輸出一堆 Mermaid 源碼，我還得找工具渲染。在 Artifacts 裡，圖直接出現在旁邊，我看完說「這裡少一個審核節點」，它改完圖立刻刷新。整個過程我一次都沒碰代碼。
另外，Artifacts 生成物可以生成分享連結發給別人（具體操作與權限以官方最新版本為準）。我把做好的流程頁把連結丟給同事，對方打開就能看——不用發文件、不用裝任何東西。
用專案＋Artifacts 跑完手冊那個項目之後，我對比了一下前後的差別：
| 環節 | 用之前的做法 | 用專案之後 |
|---|---|---|
| 開新對話 | 重傳文件＋重打要求，每次三五分鐘 | 點開專案直接問，零準備 |
| 資料版本 | 靠記憶分辨新舊版，出過事故 | 知識庫裡只有當前版，不會引錯 |
| 成果確認 | 對著代碼牆腦補，改一版看不懂 | Artifacts 即時渲染，改完立見 |
三條心得說給你聽：
一、它的價值不在「能做的事更多」，在「不用重做的事更多」。專案沒有讓 Claude 變聰明，省下來的全是重複勞動——重傳、重述、重找。但算算帳：一個項目三十個對話，每個省三分鐘準備，就是一個半小時，還不算省掉的那次「引錯舊版」事故。
二、資料乾淨比資料多重要。新手最容易犯的錯，是把知識庫當網盤用，什麼都塞。記住：知識庫裡的每一份文件，都是 AI 回答時的「證據」——證據池裡混了假證據，判決就不可信。
三、Artifacts 是新手入門程式的最低門檻。很多人想學做小網頁、小工具，卡在第一關：搭環境。Artifacts 把這一關跳過了——你描述，它生成，窗格裡馬上看效果，改壞了讓它改回來就行。試錯成本接近零。
適合立刻上手的：手裡有一攤固定資料、需要反覆對著它提問的人——做手冊的、寫方案的、整理客戶紀錄的、備考要反覆刷自己筆記的。資料重複出現的次數越多，專案省得越多。
可以先觀望的：只是偶爾問問通用問題、沒有固定資料的輕度用戶——專案對你們是「為用不上的倉庫付費」，普通對話夠用；真想解決「每次重複交代偏好」，免費做法是善用對話開頭前三句話，把背景一次說全。
最後照例提醒：本文寫到的所有功能名稱、入口位置與額度，都以官方最新版本為準——這類工具改版快，介面如有出入，以你螢幕上的為準，思路不變就好。
帶走的判斷力：判斷一個 AI 功能值不值得用，別看它「能做什麼新事」，看它幫你免掉多少重複勞動。
工具推薦隨身機器人（新用戶免費試用 7 天）
看完想動手又怕配置麻煩？我們站內的「隨身機器人」幫你把常用 AI 能力打包好，開箱即用，新用戶可免費試用 7 天——先試後買，合不合手用了才知道。前往 sylogs.com 首頁即可找到入口。
下一篇預告：查資料最怕的不是搜不到，是搜到假的。下一篇我們實測 Perplexity 的聯網檢索與來源核查，看看它給的每一條答案後面掛的「出處」，到底經不经得起點開驗證。
業州愚公 ｜ SY 視野（sylogs.com）原創內容，轉載請註明出處。
編輯評論 / Editor's Note
近年來人工智慧工具的發展日新月異，讓使用者能夠更有效地管理和處理大量資料。通過將資料整理到專案中，使用者可以輕鬆地將資料轉化為有用的資訊，提高工作效率。這種創新的應用方式不僅節省時間，還能夠幫助使用者發現新的洞察和機會。