大多數人使用 Claude 的方式就像在搜尋欄打字一樣。
每次對話的開始方式都一樣。你是行銷文案寫手。我的業務是這個。我的受眾是那個。現在幫我寫出東西。然後你關掉分頁，隔天又從頭開始重複整個簡報流程，每天早上訓練同一個員工，然後讓他們在夜晚來臨前忘光一切。
這不是工作流程。這是永遠從零開始。
Claude Projects 可以解決這個問題，但幾乎沒有人正確設定它們。大多數人建立一個專案，貼上一行指示，丟進一份隨機的 PDF，然後納悶為什麼它感覺起來沒有比一般對話好多少。它的威力是真實的，但藏在設定畫面沒有說明的細節裡。
這是一份完整的課程，教你如何像那些真正依賴 Claude Projects 的人一樣來設定它們。這裡的每個功能都是真實且最新的。到最後，你將擁有一個能自動為每次對話載入完整背景資訊、永遠不需要重新簡報、並且產出聽起來像你、而不是像個通用助手的專案。
專案到底是什麼
撇開行銷話術，一個 Claude Project 其實是三個東西綁在一個持久工作區裡。
自訂指示。 一個系統層級的提示，會自動套用到專案內的每次對話。這是一份常設簡報，塑造 Claude 的行為、它認為自己在跟誰說話、以及它遵循哪些規則，而你完全不需要在對話中輸入這些。
知識庫。 Claude 可以在每次對話中參考的檔案與文件，隨時可用，永遠不需要重新上傳。風格指南、規格、過往作品、參考資料。
範圍內的對話。 專案內的所有對話都會被分組在一起，並繼承相同的指示與檔案。
有一件重要的事需要先了解，因為它經常讓人卡住。專案內的對話不會彼此共享訊息歷史。共享的狀態是指示與檔案，而不是對話。每次新對話都是只帶著這兩樣東西重新開始。這對於你如何設計以下所有內容至關重要。
Projects 在所有 Claude 方案上皆可使用，包括免費方案，不過免費使用者最多只能建立五個專案，而專案指示本身是付費功能。在 Pro、Max 和 Team 方案上，你可以使用完整設定。
幾乎所有人都會犯的錯誤
在開始設定之前，先了解這個最大的單一錯誤，因為避免它就能解決大部分問題。
人們把知識庫當成儲物櫃。他們把所有東西都丟進去。整本品牌手冊。六個月的會議記錄。一份四十頁的策略簡報。這個邏輯聽起來似乎合理。更多背景資訊等於更好的輸出。
但事情不是這樣運作的，原因如下。專案知識不會被完整載入到每個回應中。Claude 是透過檢索來提取每次查詢最相關的內容。當你用關聯性鬆散的資料塞爆知識庫時，你就稀釋了 Claude 找到真正重要訊號的能力，並且冒著用檔案填滿上下文視窗的風險，留下更少的空間給實際的對話。
能產生顯著更好輸出的規則，與人們的預期正好相反。保持每個知識文件精簡且具體，大約一到三頁。一份三頁的品牌語調指南，每次都勝過一份四十頁的品牌手冊，因為有用的訊號更密集，雜訊更少。在知識庫中，精準永遠勝過數量。
步驟 1：帶著真實意圖建立專案
打開 Claude，點擊側邊欄的 Projects，然後點擊 New project。
名稱的重要性比看起來更大。要具體命名。「Newsletter」、「Client Proposals」或「API Documentation」，而不是「Work」或「Stuff」。原因是，你最終會有多個專案，而整個重點就在於區隔。一個模糊的名稱會導致一個模糊的專案，慢慢累積不相關的雜物，這正是上面提到的稀釋問題。
這引出了大多數人忽略的第一個原則。一個專案對應一個關注領域。 不要把後端程式碼和行銷內容放在同一個專案裡。不要把客戶 A 和客戶 B 混在一起。分開的專案意味著更乾淨、更集中的背景資訊，而集中的背景資訊正是專案之所以有效的全部原因。想要一個萬能大專案的本能，正是想要重現你原本想逃離的那個通用聊天機器人的本能。
步驟 2：把指示寫成常設簡報，而不是提示詞
這是整個設定中槓桿效應最高的部分，也是弱專案與強專案之間差距最大的地方。
一個弱的指示區塊會說：「你是一個撰寫行銷內容的有用助手。」這給了 Claude 它本來就有的東西。
一個強的指示區塊是一份完整的常設簡報，寫給一個對你一無所知的人，因為這正是專案中每次新對話開始時的情況。它應該涵蓋：你是誰以及你做什麼、這個專案存在的主要任務、你的語調和風格偏好、你要求的輸出格式、Claude 應該假設的領域知識，以及至關重要的是，Claude 絕對不該做的事。
這是一個在幾乎所有專案類型中都適用的模板結構：
角色
你是 [具體角色]，從事 [具體領域]。你正在為 [對他們一無所知的特定受眾] 寫作。
這個專案的用途
這裡的主要任務是 [任務 1]、[任務 2]、[任務 3]。除非另有說明，否則假設每個請求都與其中之一相關。
如何回應
語調：[具體]。格式：[具體]。長度：[具體]。
除非真的卡住，否則不要問澄清問題。做出合理的假設，陳述它，然後繼續。
要假設的事
[領域事實、產品細節、定位，這些在每個回應中都應被視為已知條件。]
絕對不要
[Claude 在這個專案中絕對不該做的事：AI 陳腔濫調、某些主張、某些格式、任何你的硬性規定。]
關於不要問澄清問題的那條指示值得特別提出來。預設情況下，Claude 經常以一輪「在我開始之前，你能告訴我更多關於...」來開場。對於你每天使用的專案，這個開場白純粹是摩擦。告訴它做出合理的假設、陳述它、然後繼續，可以消除來回確認，並立即加快每次對話的速度。
為那個與你毫無歷史淵源的讀者撰寫這些指示，因為每次新對話確實是從那裡開始的。指示和檔案是唯一會延續下去的東西。你上一次對話的記憶並不會。
步驟 3：精準建立知識庫
現在來看檔案。記住規則。精簡、具體、每份一到三頁。以下是以內容專案為例，說明一個建構良好的知識庫實際上該放什麼。
語音與風格指南。 你如何寫作。句子節奏、你使用的詞彙、你禁止的詞彙、你輸出的感覺。
受眾文件。 你為誰寫作、他們關心什麼、他們已經知道什麼、他們對什麼持懷疑態度。
支柱或範圍文件。 這個專案涵蓋的特定主題或類別，讓 Claude 保持在範圍內。
一小組最佳範例。 三到五件你實際最好的作品。這透過示範來教導，效果遠比描述來得好。Claude 從真實範例中學習你的模式，比從任何數量的指示中學習得更好。
與工作相關的參考資料。 SEO 筆記、產品規格、技術限制，無論領域需要什麼。
為每個檔案取一個描述性的名稱。「Brand Voice Guide v3」、「Q2 Product Roadmap」、「API Documentation Payments Module」，而不是「notes」或「stuff」。描述性的名稱有助於檢索為正確的查詢找到正確的文件，而這正是你所依賴的整個機制。
值得知道的限制。在 Pro、Max 和 Team 方案上，每個專案最多可以有 20 個檔案，每個檔案 30MB，支援 PDF、文字、Markdown、程式碼檔案、CSV 和圖片。如果你遵循精準規則，這已經足夠。如果你碰到上限，問題幾乎總是你上傳了數量而不是訊號。
步驟 4：在信任檢索之前先測試它
這是一個幾乎沒有人會做的步驟，它區分了那些「認為」自己專案有效的人和那些「知道」它有效的人。
上傳你的知識後，在專案中開啟一個對話，並明確測試 Claude 是否能檢索到每個文件。直接問：
根據專案知識中的品牌語調指南，我應該如何處理一篇貼文的開頭？引用你正在使用的具體指引。
如果 Claude 準確地引用了該文件，表示檢索正常運作。如果它給出一個通用的答案或找不到指引，那就表示有問題。也許檔案沒有處理成功，也許命名太模糊，也許文件被太多其他檔案埋沒了。最好在測試中發現這個問題，而不是在三週後才發現 Claude 從來沒有真正讀過你最重要的檔案。
對每個關鍵文件執行這個測試。這只需要五分鐘，卻是區分一個你「希望」有效的專案和一個你「知道」有效的專案的關鍵。
步驟 5：為每次對話選擇正確的模型
一個大多數人完全忽略的細節。在專案內部，你可以獨立地為每次對話選擇要使用哪個 Claude 模型。專案不會把你鎖死在一個模型上。
這對成本和品質都很重要。在專案內進行例行草稿撰寫時使用較快的模型，並在需要深度推理或複雜整合的對話時切換到能力更強的模型。同一個專案、同樣的指示、同樣的知識，根據特定任務的需求使用不同的引擎。大多數人從未意識到他們可以這樣做，結果要麼把所有事情都跑在頂級模型上而多付錢，要麼把所有事情都跑在快速模型上而表現不佳。
步驟 6：把對話當作思考過程，而不只是任務
這是一個習慣，會隨著時間讓專案變得更強大。
不要只把專案對話用於完成任務。用它來進行思考。解決一個問題，解釋你的推理過程，討論你為什麼做出某個決定。由於專案是有範圍且一致的，這些思考對話能幫助 Claude 理解你的推理模式，而不只是你的輸出模式。
結果是，在數週之後，一個被良好使用的專案中的 Claude，不僅會開始匹配你的格式，還會匹配你的判斷力。它會提出符合你實際思考方式的方法，因為它已經在那個有範圍的背景中看過你是如何思考的，而不只是你產出了什麼。
步驟 7：維護它，因為專案的有效性取決於其檔案的時效性
一個專案不是設定好就一勞永逸。它的準確性完全取決於裡面的內容，而過時的知識會產生自信滿滿但錯誤的背景資訊，這比沒有背景資訊更糟。
建立一個維護習慣。當你的定位改變時，更新語音指南。當規格修訂時，取代舊的。當策略轉變時，更新範圍文件。每季檢討你的專案指示，因為六個月前寫的指示現在可能與你正在做的事情積極牴觸，而 Claude 會忠實地遵循那個過時的規則。
那些保持有價值的專案，是人們持續更新的專案。那些悄悄變得無用的專案，是那些被設定一次後再也沒碰過，而實際工作早已在它們周圍繼續進行的專案。
新層級：Cowork 專案
值得了解，因為它顯著擴展了以上所有內容。截至 2026 年的更新，Projects 也存在於 Claude Cowork（桌面代理應用程式）中，而這個版本增加了基於聊天的 Projects 所沒有的功能。
Cowork 專案增加了跨工作階段持續存在的範圍記憶，所以你可以說「延續上週的報告」，而 Claude 確切知道那是什麼，同時不會將該背景資訊洩漏到你的其他工作中。它們增加了專用的本地資料夾，因此專案可以在你的機器上讀寫真實檔案。它們還增加了排程任務，因此專案可以按照你設定的節奏自動執行重複性工作。
設定的邏輯與上述所有內容相同。清晰的指示、精簡相關的檔案、一個專案對應一個關注領域。但天花板更高了，因為一個 Cowork 專案不僅僅是為對話提供資訊，它還能針對真實檔案執行工作，並且可以在沒有你的情況下按排程運行。一個好的第一步是將它指向一個資料夾並說：
讀取這個資料夾中的每個檔案。然後總結你對這個工作區的了解：這裡有什麼、我可能用它來做什麼、以及你會遵循哪些指示。如果有任何不清楚的地方，在假設之前先問清楚。
這一個指令就能讓 Claude 在第一天就了解專案，並從此記住。
你今天就可以建立的四個專案模板
理論只有在具體化時才有用。這裡有四個專案設定，直接對應到最常見的使用案例，每個都說明了指示與知識庫中分別該放什麼，讓你可以複製這個結構。
內容專案。 指示定義你作為特定受眾寫手的角色、你的語調、你的格式規則以及你的嚴格禁止事項。知識庫包含語音指南、受眾人物誌、支柱文件以及三到五篇你表現最好的作品。這個專案能讓你發布的所有內容聽起來始終如一地像你，而不是每次都像不同的寫手。知識庫中的最佳範例在這裡比任何指示都更有用，因為語調是「感染」來的，而不是教來的。
程式碼專案。 指示定義你的技術棧、你的慣例、你偏好的模式以及你永遠不希望做的事情。知識庫包含架構文件、你的關鍵原始碼檔案、你的編碼標準以及專案接觸到的任何東西的 API 文件。把 Claude 指向這裡，它就會停止建議與你現有模式衝突的程式碼，並開始匹配它們。一個程式碼庫一個專案，永遠不要共用，因為混合兩個程式碼庫是獲得對兩者都不適用的建議的最快方法。
客戶專案。 每個客戶一個專案。指示定義客戶是誰、他們的品牌、他們的偏好以及你與他們合作的範圍。知識庫包含他們的品牌指南、過往交付成果、提煉到要點的會議記錄以及任何對他們特定的限制。這就是個人工作者或代理商如何完美地分離每個客戶的背景資訊，讓客戶 A 的語調永遠不會滲入客戶 B 的工作中。
研究專案。 指示定義你在調查什麼問題或領域，以及你希望如何建構發現。知識庫包含你的原始資料、你之前的筆記以及你的工作假設。當你餵給它更多資料時，它會跨所有資料建立一個圖像，而且由於它是有範圍的，它不會將這項研究與你正在處理的任何其他事情混淆。這是基於聊天的專案最接近「第二大腦」概念的樣子——一個你可以詢問的知識體，因為它與所有不相關的事物隔離，所以保持連貫。
注意這四個模式的共同點。指示承載常設規則和行為。知識庫承載參考資料和範例。這種區隔是刻意的，而將正確的內容放入正確的層級，是讓專案運作的大部分關鍵。關於如何行為的規則屬於指示。Claude 需要參考的文件屬於知識庫。將它們搞混，例如把行為規則放在知識庫檔案中，或把參考文件貼到指示框裡，是讓專案表現不佳而又沒有明顯原因的隱蔽方式。
大多數人忽略的分層個人化
還有一件事值得了解，因為它可以疊加在上述所有內容之上。專案指示並不是 Claude 唯一的個人化層級，了解它們如何結合能讓你獲得更好的控制。
總共有三個層級，它們會在每個回應中同時作用。帳戶範圍的指示，在你的個人檔案設定中設定，會套用到所有地方的每次對話，無論專案為何。專案指示只套用在特定專案內。而風格，在每次對話中設定，可以調整該次對話的語調和格式。
實際的做法是讓每個層級發揮其最擅長的作用。把你用 Claude 做所有事情都適用的規則，例如你的一般溝通偏好，放在帳戶範圍的個人檔案指示中，這樣你就不用在每個專案中重複它們。把專案特定的背景資訊和規則放在專案指示中。當某次特定對話需要與專案預設不同的語調時，使用風格進行一次性調整。
大多數人把所有東西都塞進一個層級，從而失去了這種控制。當你正確地分開它們時，你就不會在每個專案中重複你的通用偏好，而每個專案的指示就能純粹專注於讓該專案與眾不同的地方。再次強調，這種專注正是良好設定專案的整個主題。
真正能產生複利效應的設定
把整個東西組合起來，一個正確建構的專案能給你一般對話永遠無法提供的東西。
每次對話都從已載入完整背景資訊開始。你的語調、你的受眾、你的規則、你的參考資料，在你打出一個字之前全部到位。你不再需要重新簡報。你不再從零開始。你不再每天早上訓練同一個員工。
輸出不再聽起來像通用的，而是開始聽起來像你，因為 Claude 是根據你實際的範例和標準在工作，而不是一張白紙加上一個匆忙寫成的一行提示詞。
而且它會產生複利效應。第一週需要小幅修正，因為 Claude 從檔案中學習你的模式。到了第三週，它已經足夠接近你的方法，你不再需要解釋那些你過去每次都要解釋的事情。那三十分鐘的設定會在數個月內得到回報。
這裡是誠實的結論。大多數人從未獲得這個好處，不是因為這個功能很難，而是因為他們在九十秒內設定完畢，然後再也沒有做過那些真正重要的部分。精準的知識庫。真正的常設簡報。檢索測試。維護習慣。
做好這四件事，Claude Projects 就不再只是一個存放對話的資料夾，而是會成為區分你把 Claude 當作搜尋欄使用，還是把它當作一個已經確切知道你是誰、你需要什麼的系統來運作的關鍵。
這週就正確地設定一個專案。選擇你最常做的工作。寫下真正的指示。上傳三份精簡的文件。測試檢索。然後看看下一次對話的感覺有多麼不同。
追蹤 @cyrilXBT 以獲取完整的建構方法、精確的指示模板，以及我每天使用的專案設定。
