在 Claude Code 與 MCP 搶走目光的這半年，Claude.ai 介面上那個叫做 Projects 的功能，反倒成了最被低估的一項。
Projects 的定位其實很清楚：每一個你會反覆回頭做的工作：特定客戶、長期研究、固定的內容產製，都能擁有一個專屬空間，讓 Claude 永久記住角色、語氣、規則與參考素材。
什麼時候該優先考慮 Projects？判斷標準在頻率。只要同類型對話會在未來幾週重複出現，就值得花 15 分鐘建一個 Project，而不是每次重新貼風格指南、重新交代背景。
X 創作者 Guri Singh（@heygurisingh）把這套被忽略的方法論整理成 5 模組教學，從知識庫架構、四段式自訂指令到 Projects＋Skills＋MCP 三層組合技，提供一份完整的 Projects 進階指南。
Projects 能解決什麼痛點？
Claude 的對話預設不跨聊天室共享脈絡。沒有 Project，每次新對話都從零開始，你得反覆上傳同一份風格指南、反覆描述同一套技術堆疊、反覆交代同一組寫作禁忌。
Guri Singh 稱這是「脈絡稅」，而 Projects 的存在就是為了永久消除這筆稅，尤其你的使用方式還沒進階到 Claude Cowork 或 Claude Code 階段的時候。
認識Project介面
點開任何一個 Project，畫面分成左中右三塊，每一塊對應 Project 機制中的一個角色。以下用一個「電子報生產器」Project 為例。
左上：Project 名稱與描述
頂端是 Project 名稱「電子報生產器」與一行說明「根據每月發佈的文章，寫一篇控制在 2,500 字的電子報文章。」
這行字不只給人看，Claude 每次對話也會讀取，等於是這個 Project 的「一句話定位」。寫得越具體，Claude 越能在第一輪對話就抓到方向。
中央：對話入口與 Cowork 通道
中間是熟悉的對話框，可以選擇模型（圖中為 Sonnet 4.6）。對話框下方有一個容易被忽略的入口「Start a task in Cowork」，這是把當前 Project 的脈絡帶進 Claude Cowork 執行長任務的快速通道，等於 Project 知識庫變成 Cowork 的工作背景。
下方「Your chats / Activity」分頁則保留所有歷史對話，未來開新聊天時 Claude 會自動參考過往對話的脈絡。
右側：Project 的三層大腦
最關鍵的設定全在右側欄。由上到下分別是：
- Memory（僅自己可見）：Claude 累積對話後自動萃取的長期記憶，會在使用幾次後出現
- Instructions（全成員共用）：自訂指令的所在，也就是之後提到的「角色、語氣、規則、格式」四段式內容寫進這裡
- Files（全成員共用）：知識庫文件上傳區，PDF、Markdown、Word 都可，這就是前面講的 ref-、template-、example- 三類檔案的家
把這三塊填好，一個 Project 才算「開機完成」。多數人停在 Files 塞檔案，跳過 Instructions，這也是後面要花最大篇幅解決的問題。
第一步：判斷你需不需要開 Project
不是所有任務都值得建 Project。Singh 提出一個簡單測試：
- 這件事只做一次就不會回頭？用普通對話（Chat）就好
- 同類型對話會在未來幾週反覆出現？開 Project
- 多人需要共用同一套脈絡？開 Team Project
適合的場景：特定客戶帳戶、反覆回訪的研究領域、正在寫的書、經常性的內容產製流程。
不適合的場景：一次性文件摘要、快問快答、含機密資訊且不應長期留存的內容。
第二步：像圖書館員一樣整理知識庫
這是 90% 的 Projects 失敗的環節。知識庫不是垃圾場，該上傳的是參考素材，亦即穩定、可重複引用的文件：
- 風格指南與語氣規範
- 反覆使用的模板（提案架構、信件格式）
- 你引以為傲的作品範例（Claude 從範例學標準，比從描述學更快）
- API 文件、產品規格、品牌指南
不該上傳的：正在編輯的草稿、一次性客戶檔案、個人機密資訊。這些屬於單次對話的附件，不是長期知識庫的內容。
檔案命名也有學問。style-guide-v3-final.pdf 不如 brand-voice-guide.pdf，因為 Claude 會讀取檔名來輔助檢索。文件超過 20 份時，建議加上分類前綴：ref-brand-voice.md、template-proposal.md、example-success-story-1.md。
舉個內容團隊的 Project 知識庫實例。沒整理過的版本通常長這樣：
風格指南-final-v3.pdf
公司簡介.docx
新人手冊2025最新版.pdf
電子報範例.docx
過去寫得好的案子.pdf
品牌字典 (1).pdf
語氣規範-我的版本.md
問題：Claude 看到「風格指南-final-v3.pdf」和「語氣規範-我的版本.md」，無法判斷兩者是否衝突、哪個版本應該優先。
因此，當你問「這封信的語氣對嗎？」，它可能同時讀取三個檔案，得出一份折衷但不精準的答案。
整理過的版本：
ref-brand-voice.md # 品牌語氣總則
ref-tone-rules.md # 用字與禁用詞
ref-company-overview.md # 公司定位
template-newsletter.md # 電子報模板
template-pitch-email.md # 提案信模板
template-proposal-deck.md # 提案簡報架構
example-newsletter-best.md # 表現最好的三期電子報
example-pitch-won.md # 成功提案案例
example-pitch-rejected.md # 失敗提案＋失敗原因
三個前綴對應三種角色：ref- 是規則（Claude 必須遵守的標準）、template- 是骨架（直接套用的格式）、example- 是樣本（從中學習風格與標準）。
當你問「幫我寫一封提案信」，Claude 會優先抓 template-pitch-email.md 套架構、example-pitch-won.md 學語氣、ref-brand-voice.md 校語氣。
檔名說清楚分工，Claude 才知道該怎麼組合。
第三步：用四段式結構寫出有效的自訂指令
自訂指令（Instructions）是整個 Project 最關鍵的部分。Singh 建議控制在 200-500 字，用以下四段式結構：
【角色】你是誰、這個 Project 做什麼
→ 範例：「你是我的 SaaS 新創內容策略師，負責週報、Landing Page 和銷售信件。」
【語氣】Claude 應該怎麼說話（要具體）
→ 範例：「短句、不用術語、第一人稱、禁用 delve 和 leverage。」
【規則】必須做什麼、絕對不能做什麼
→ 範例：「永遠附上來源。未經我核准的工具不准推薦。超過 500 字先問我。」
【格式】輸出長什麼樣
→ 範例：「先給結論再給推論。不要開場白。」
一個實戰技巧：「禁止清單」往往比正面指令更有效。「不要建議換框架」能精準阻止 Claude 最常犯的毛病，而正面描述很難涵蓋到這種情境。
指令不會一次就完美。Singh 建議每 3-5 次對話後檢視：Claude 是否重複犯同一個錯誤？是否反覆問你已經可以寫進指令的背景資訊？每修正一次，就是未來永遠省下的一次糾正。
第四步：搞懂 Projects、Skills、MCP 三層架構
多數人把 Projects 當萬能工具，但它只是三層架構中的一層：
| 層級 | 回答的問題 | 類比 |
|---|---|---|
| Projects | Claude 需要知道什麼？ | 圖書館 |
| Skills | Claude 如何執行特定任務？ | 訓練有素的員工 |
| MCP | Claude 能取得哪些即時資料？ | 連線工具 |
三者組合的實際案例：以一個內容創作者的電子報工作流為例，Project 存放品牌語氣指南與過去 20 期電子報範例；Skill 定義撰寫流程（檢視上期、拉取新內容、產出三個段落、套用語氣）。至於 MCP 則連接 GitHub 抓本週更新、連接搜尋引擎抓產業新聞。
在一個指令啟動 Skill 後，Skill 透過 MCP 拉即時資料，Project 提供風格參考，一次產出到位。
第五步：每週迭代，別追求完美初版
Singh 的核心建議：別花太多時間設計第一版。一個「粗糙但你真的在用」的 Project，遠勝過一個「完美但從未啟動」的 Project。每週重讀一次指令，刪除過時內容，補上已成慣例的新規則。
使用上要注意的地方？
這套方法有幾個前提。RAG 自動擴展（讓知識庫容量提升 10 倍）僅限付費方案用戶，免費用戶上限 5 個 Project 且無 RAG。自訂指令超過 500 字後，Claude 在長對話中容易遺漏部分內容，因此精簡比詳盡更重要。
RAG = Retrieval-Augmented Generation（檢索增強生成）。
簡單講就是：當你問 Claude 一個問題，系統先去你上傳的知識庫文件裡「檢索」相關段落，把找到的內容塞進 Claude 的 context window，再讓 Claude 根據這些檢索結果生成回答。
沒有 RAG 時：Claude 一次性把整份文件讀進 context。文件越多，context window 越快爆掉，所以單一 Project 能放的文件量有上限。
有 RAG 時：知識庫文件先被切塊、向量化存起來。每次對話只把「跟當前問題相關的段落」撈出來餵給 Claude。等於用「按需檢索」換取「容量上限」。
此外，Project 適合的是長期、反覆性的任務，一次性工作直接用普通對話即可，不必為了「用 Projects」而開 Project。
最後，Singh 的方法論整合自多方資源，部分建議（如指令最佳字數）基於個人經驗而非官方規格，實際效果因使用情境而異。
工具本身不是優勢，怎麼建構工作環境才是。
資料來源：Guri Singh (@heygurisingh) on X
本文初稿為AI編撰，整理．編輯／李先泰
