不會Claude Code也能上手！用Projects打造AI工作流，5步驟養成長期記憶助理
在 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 的方法論整合自多方資源，部分建議（如指令最佳字數）基於個人經驗而非官方規格，實際效果因使用情境而異。
工具本身不是優勢，怎麼建構工作環境才是。
延伸閱讀：觀點 | OpenClaw能幫你回信、採購、代發社群貼文！但把工作全交給AI代理前，需守好這3道防線
資料來源：Guri Singh (@heygurisingh) on X
本文初稿為AI編撰，整理．編輯／李先泰
延伸閱讀
觀點｜多數4G用戶說夠用，為什麼還推5G？偏鄉救護車上的醫師靠「網路會診」給出了答案
AI來了，台灣年輕人怎麼辦？簡立峰：別搶食衣住行小市場，去解決台積電等級的軟體問題
「加入《數位時代》LINE好友，科技新聞不漏接」