Claude Projects 怎麼用？我把生意切成 6 個專案的工作流（2026）

你打開 Claude 想用 Project 把工作整理起來，用了一陣子發現問題：輸出越來越亂、Claude 不記得上次的脈絡、規範跟範例混在一起、同一份檢查清單在不同對話被改成不同版本。

大部分人遇到這狀況的反應是「Claude 是不是退步了」、「Project 是不是設計得不好」。但我自己跑了一年多之後的結論是：問題不在 Claude，是 Project 切得太粗。

這篇我把目前在用的 6 個 Project 完整公開——電子報、網站文章、社群、業務諮詢、簽約客戶、個人生活——以及背後的決策邏輯、Instructions 跟 Files 怎麼分工、我犯過的設計錯誤。如果你正在用 Claude 但覺得「明明訂閱了卻沒發揮應有的效率」，Project 切法可能就是缺的那一塊。

為什麼一個 Project 不夠用

剛開始用 Projects 的時候，我也是「電子報、文章、客戶、自己的事」全部丟進同一個 Project，Instructions 寫了一大段試圖涵蓋所有情境。我那時候的想法很單純：Claude 已經很聰明了，我只要把背景講清楚，它應該分得清楚現在在做什麼。

跑了兩個禮拜就放棄這個做法。問題不是 Claude 不夠聰明，是不同任務的「對話脈絡」本來就完全不同。電子報的脈絡是「寫給已經訂閱的人，可以更直接、更實戰」；網站文章的脈絡是「寫給陌生讀者，要把背景講清楚」；客戶相關的脈絡是「處理單一個案的具體需求」。把這三種脈絡丟到同一個對話流裡，前面在改電子報的口吻、下一個對話就跳去寫網站文章，Claude 會被前面殘留的脈絡干擾，語氣偏掉、長度錯亂、引用錯誤範例。

更現實的問題是 Files。文章專案會放「過去 56 篇上線文章作為範例」，電子報專案會放「過去發過的電子報」，業務相關專案會放報價單模板。這些檔案在不同任務之間互相干擾——寫文章的時候 Claude 可能誤拉電子報的口吻去寫文章開頭，寫電子報的時候誤把文章的 Schema markup 邏輯帶進來。

切開的成本只有一個：每次要開新對話時，我得花 1-2 秒決定「這件事屬於哪個 Project」。這個成本跟「輸出品質下降到要重做」比起來，完全不在同一個量級。

我怎麼決定要切幾個 Project（三條判斷規則）

不是每個工作項目都該開一個 Project。切太細的代價是維護成本變高、Instructions 重複寫好幾份。我自己用三條規則來判斷該不該拆：

規則 1：規範差很多就拆。如果兩個任務的「規範類」內容差超過 30%——例如語氣、長度、格式、禁止事項——就拆。電子報跟網站文章的規範差很多（語氣、結構、CTA 邏輯都不同），所以拆；網站文章跟 LP 文案規範也差很多，所以也應該拆。

規則 2：素材檔會打架就拆。如果兩個任務各自會累積一批範例 / 模板 / 參考檔，而且這些檔案的口吻或結構會互相干擾，就拆。文章 Project 的範例檔跟電子報 Project 的範例檔放在一起，Claude 很容易拉錯參考。

規則 3：頻率高 + 任務型態清楚就拆。就算規範看起來相近，只要這件事我每週都會做、而且每次的流程很固定，就值得開獨立 Project。理由是「重複高頻任務」最能從 Instructions 累積中受益——你越常做，越能把規範磨細，輸出品質指數上升。

反過來，如果一件事我一年只做兩三次、規範也很彈性，我就不會開 Project，直接在一般對話裡處理，把背景資料貼進去就好。

我的 6 個 Project 各自負責什麼

講完判斷邏輯，直接看我目前的切法。這是跑了一年多累積出來的版本，中間刪掉過 1 個（原本有「端營 / 短影音」Project，但這塊我自己還沒做出成績，所以先收起來）、調整過幾次邊界。

1. 電子報。每週寄給訂閱者的內容。Instructions 規範語氣（比文章更直接、實戰）、長度、開頭鉤子的寫法、不可以重複網站文章已經寫過的東西。Files 放過去發過的電子報、訂閱者輪廓、不同主題的初稿草稿。

2. 網站文章（SEO）。這是我用得最重的 Project。Instructions 規範 HTML 模板、Schema markup、Roy 第一人稱口吻、不能說的話（例如過時資訊、編造案例）、框框使用規則。Files 放過去 56 篇已上線文章的精選範例、HTML 模板 v3.1、集群策略文件、全站 URL 跟內部連結矩陣、受眾輪廓。新文章一進來，Claude 已經知道整個體系怎麼運作。

3. 社群（還在摸索中）。老實說這個 Project 我用得不順，目前主要是測試貼文鉤子、把文章重點改寫成貼文。Instructions 寫了「以個人經驗出發、不說教、開頭一定要一個鉤子」這些原則，但我自己社群還沒做出成績，所以這個 Project 偏實驗性質。

4. 業務客戶諮詢。諮詢完之後的初步需求整理、報價單模板化。我會把諮詢時討論的需求條列起來，讓 Claude 幫我補上格式、確認沒漏掉常規項目，接著套進報價單模板裡。Instructions 規範報價單的格式、付款條件、交付週期等標準條款。Files 放報價單模板、過去常見的 FAQ。這個 Project 純粹是內部效率工具，不涉及客戶的對話內容。

5. 已簽約客戶。處理進入合作後的工作流。Files 放事先建好的雲端模板：排程表、checklist、產品資料表。新客戶進來開新對話，把模板給 Claude，讓它根據客戶情況改寫成符合的版本。這個 Project 不放具體客戶資料，放的是「通用 SOP 框架」。

6. 個人生活。我自己的事——出國行程規劃、家裡裝修、長期目標追蹤這類。本來覺得不需要，但生活的事情累積起來也夠頻繁、規範也跟工作完全不同（語氣可以更隨性、不需要 SEO 結構），所以開了一個。我發現把生活的對話脈絡跟工作分開，工作 Project 的輸出品質更穩。

Instructions 跟 Files 各放什麼？

這是 Project 設計裡最容易搞混的地方，也是新手最常出錯的地方。我的分工原則一句話講完：規範類放 Instructions，範例 / 模板類放 Files。

Instructions = 規範類。放 Claude「永遠要記住的規矩」。包含：語氣怎麼寫、長度多少、格式長什麼樣、禁止事項、必須做的檢查、輸出時要包含哪些區塊。原則是「每一條都短而具體」——重點是「每條規矩」要短而具體，不是整份 Instructions 要短。我文章 Project 的 Instructions 其實很長，但每一條都很精確，沒有套話、沒有「請以專業友善的方式回答」這種廢話。需要寫多長就寫多長，重點是別塞模糊指令。

Files = 範例 / 模板 / 參考資料類。放 Claude「參考用」的素材。包含：過去成功的範例、模板檔、檢查清單、外部參考資料、受眾輪廓、品牌相關資訊。原則同樣是「該放什麼就放什麼」——不是越多越好，是「該有的都要有」。我文章 Project 的 Files 有 20+ 個，因為這個工作流真的需要這些素材。但每加一個檔案都該想清楚為什麼，不是「多放保險」。

簡單判斷：如果某段內容是「每次都要遵守」的規矩，放 Instructions；如果是「需要時參考」的素材，放 Files。把長範例堆進 Instructions 是最常見的錯誤——拖慢回應、稀釋規範、Claude 反而抓不到核心原則。如果你還沒寫過 Project Instructions、不確定好的指令長什麼樣，可以延伸閱讀Claude Project Instructions 怎麼寫：好指令跟爛指令的差異。

跨 Project 的 Knowledge 不會共享，怎麼辦？

這是 Projects 架構的一個現實限制：每個 Project 是獨立的島，Claude 不會跨 Project 記住任何東西。你在電子報 Project 跟 Claude 討論過的受眾輪廓，網站文章 Project 完全不知道。

實務上會遇到的問題：有些東西是「跨 Project 都會用到」的，例如「受眾輪廓」、「品牌語氣設定」、「我的個人背景」、「不可以做的事」這些。如果每次開新 Project 都重寫一份，維護成本爆炸高；改一處要記得同步到所有 Project，常常會漏。

我的處理方式是把「跨 Project 通用素材」當作主檔來管理。具體做法：

• 主檔放在雲端（Notion / Google Drive）。受眾輪廓、品牌語氣、我的背景、隱私邊界這些通用素材，各自一個獨立檔案。
• 更新時改主檔，然後同步到所有相關 Project 的 Files。例如受眾輪廓更新了，我會把新版本貼到每一個會用到的 Project 裡（文章、電子報、社群）。
• Instructions 裡明確指出「請參考 Files 裡的 OO 檔」。讓 Claude 知道有這份素材在，需要時要去看。

這個流程不完美——同步要靠人工——但老實說沒有想像中累。我會分兩塊講：

指令類的更新頻率，比你想的低很多。例如 SEO 文章 Project 的 Instructions，我大概半年才會回頭檢視一次，看 Google 演算法有沒有什麼新方向需要調整。但大方向其實都沒怎麼變。剛建好 Project 那段時間會比較常改 Instructions 跟原則類的檔案，後面進入穩定期之後，這些東西幾乎不動。

真的會一直新增的，是「範例 / 集群素材」這類檔案。例如我每完成一個新的文章集群，就會把新的集群策略檔上傳到文章 Project。這跟「原則類 Files」（受眾輪廓、品牌語氣、模板）是不一樣的東西——原則類幾乎不動，集群類隨工作進度自然累積。維護的真實樣貌不是「定期回去改一堆東西」，而是「新東西進來就加一個檔，老東西放著就好」。

你可能會問：那 Anthropic 後來推的 Skills 不就是要解這件事嗎？是，Skills 確實是一條可能的路。但我評估過後目前還沒換，下一段直接講為什麼。

為什麼我目前還沒換成 Skills、Cowork 或 Agent

Anthropic 這兩年陸續推了好幾個可能影響我工作流的新功能。每次新功能出來，我都會認真評估要不要換。目前的結論是維持「Project + Instructions + Files + 人工審閱」這個架構，新功能還沒進入我的工作流。簡單說明每個的判斷邏輯：

Skills

Skills 的概念是把「特定任務的處理流程」打包成獨立技能檔，Claude 會在判斷需要時自動載入。最大優點是跨 Project 通用，理論上能解前一段講的「同樣素材要複製到多個 Project」這個問題。

但我評估之後目前不換，兩個主要原因：

第一，Skills 是「Claude 判斷需要時才載入」，Project Files 是「每次都自動載入」。我寫每一篇文章都需要受眾輪廓、品牌語氣、HTML 模板、隱私邊界這些素材——尤其是隱私邊界（哪些客戶資訊不能寫進文章）這種「絕對不能漏」的規矩，不能有「這次 Claude 沒判斷要載」的風險。Project Files 的「永遠都載」對我這種高品質要求的工作流更可靠。

第二，Skills 比較適合流程性的可重複任務。例如報價單格式產出、Excel 數據轉換這種「規則清楚、輸入輸出格式固定」的工作。但我的文章寫作每一篇都有判斷成分——這篇要走什麼切角、Roy 經驗框放哪、結構要怎麼變化才不會模板化——這些不是「跑流程」能解的，需要每次來回討論。把它做成 Skill 反而會限制彈性。

我未來會考慮用 Skills 的場景大概是「報價單產出 SOP」這種高頻、規範清楚的內部任務，不是文章寫作。

Cowork

Cowork 是桌面端工具，讓 Claude 在本地端執行任務、處理檔案、產生輸出檔。對需要本地檔案批次處理的人很適合——整理整個資料夾的素材、批次轉檔、跨檔案分析這類。

但我的文章工作流是「Claude 直接產 HTML → 我貼到 Shopify 後台」，輸出物是貼進網站，不是在本地端產檔案。所以 Cowork 對我這種「網站內容產出」情境幫助有限。如果你的工作需要大量本地檔案處理（例如客戶資料整理、批次素材製作），Cowork 是另一個值得評估的方向。

AI Agent

Agent 適合處理「例行公事自動化」——每天定時抓 GSC 數據、定時跑報表、定時通知這類規則清楚的工作。我也想過拿來自動化 SEO 數據監控。

但目前 GSC 數據判讀對我來說還是需要人工判斷：哪些字要追、哪些文章該回更、新發現的長尾要不要規劃成新內容——這些決策的價值在於「我看到數據後的判斷」，而不是「自動跑出結論」。Agent 幫我自動產出的結論，我還是要重新審閱一次，效率提升其實有限。

當我的工作流裡出現一塊真的「重複、規則清楚、不需人工判斷」的事情，Agent 才會進入評估清單。目前還沒到那個階段。

底層的判斷邏輯一致：新功能值不值得換，看它解的是不是我目前真正的瓶頸。我目前的瓶頸不是「Project 維護太累」（其實還好），也不是「跨 Project 共享難」（手動同步可以接受）。真正的瓶頸是「人工審閱每一篇輸出」這件事——但這個瓶頸是我刻意保留的，因為這就是「公開實驗者」跟「AI 量產內容」拉開差距的關鍵。新功能要解的如果是這塊，我反而不會用。

一個新工作流要怎麼決定該不該變成 Project

新工作流冒出來的時候，不要急著開 Project。我會用三個指標判斷：

頻率夠高嗎？每週至少做一次，或者每個月超過 4 次。低頻任務直接在一般對話裡處理就好，把背景貼進去、講清楚要做什麼。

規範會重複嗎？每次做這件事，你會重複講同一套規矩（語氣、格式、禁止事項）。如果每次規範都不一樣、每次都要重新想，Instructions 抓不到模式，就不適合開 Project。

素材會累積嗎？這件事做久了，會累積出範例 / 模板 / 參考檔，可以放進 Files 讓未來的對話品質更高。如果不會累積、每次都是孤立任務，Files 就只是擺著沒在發揮。

三個都符合再開 Project。三個只符合一兩個，就先用一般對話處理，等真的成熟了再升級。我自己的「社群」Project 嚴格說起來只符合「頻率」這條，規範還在摸、素材還沒累積——所以它一直停在「實驗階段」的狀態，我不會把它跟其他成熟 Project 用同樣標準看待。

更進階的問題是「要不要把整個工作流自動化」——例如 Claude 寫完直接發到電子報系統、文章寫完直接上傳。這已經超出 Project 設計的範圍，屬於 AI 自動化的領域，可以延伸閱讀AI 自動化是什麼？怎麼把日常工作交給 AI 處理。

Project 維護：什麼時候該更新、什麼該砍

Project 不是設定完就放著的，Instructions 跟 Files 都會過時。我有三個觸發回頭調整的訊號：

訊號 1：輸出品質明顯下降。同樣類型的任務，Claude 突然出錯比較多——通常是 Instructions 沒跟上實際工作流的演進。例如我文章 Project 的模板從 v3.0 更新到 v3.1 後，Instructions 沒同步，Claude 還在套用舊規格。

訊號 2：任務型態變了。原本這個 Project 在做 A 類事情，後來慢慢演變成 A + B + C 混在一起。這時候要判斷：B、C 是不是該獨立出來開新 Project，或是 Instructions 需要擴充涵蓋。

訊號 3：Files 有東西開始打架。累積到一定數量後，Files 裡的範例可能會彼此矛盾（例如新舊兩個版本的範例都還在），Claude 拉錯參考的機會升高。這時候要做一次 Files 清理：刪掉過時、合併重複、把最新版本標清楚。

除了被動回應，我也會主動每季回看一次每個 Project：Instructions 還準確嗎？Files 有沒有過期？有沒有 3 個月沒用到的 Project，值得考慮歸檔？「端營 / 短影音」那個 Project 就是這樣被砍掉的——半年沒用，代表這條工作流沒成形，留著只會干擾我對「成熟 Project」的判斷。

我犯過的 Project 設計錯誤

這一年多累積下來，有三個錯誤我重複犯過、也看到不少人犯。寫出來省你的時間：

錯誤 1：一開始把所有事都丟進一個 Project。我前面講過了，這是最常見的起點錯誤。如果你現在還停在「一個萬用 Project 處理所有事」的階段，建議至少先拆出「工作 / 個人」兩個，觀察一陣子，你會自己感受到分開的價值。

錯誤 2：Instructions 太籠統像「萬用指令」。例如寫成「請以專業、友善、清楚的方式回答」——這種指令等於沒寫，Claude 預設就會這樣。好的 Instructions 必須具體到「跟其他 Project 不一樣的地方」。如果你的 Instructions 抽掉之後 Claude 行為沒差別，代表這份 Instructions 沒在做事。

錯誤 3：Files 塞太多範例，反而被 Claude 誤導。我有段時間想說「範例越多越好」，文章 Project 的 Files 一度塞了 30+ 個範例文。結果發現 Claude 開始拉一些我其實沒那麼想當範例的舊文章來模仿（風格不一致、結構過時）。後來我整理成「精選 8-10 篇近期、品質高、結構標準的範例」，輸出品質反而穩定下來。Files 不是越多越好，是「越精確越好」。

常見問題

延伸閱讀

• Claude Project Instructions 怎麼寫？好指令跟爛指令的差異（實戰範例）
• Claude 用途實戰盤點：我每天靠它做的事
• Claude AI 是什麼？中小企業商業應用完整指南

最後

Projects 看起來只是 Claude 介面上一個功能，但用對之後它其實是「把你的工作流系統化」的工具。一個 Project 就像一個專業助理，你給它越清楚的規範、越精準的範例，它越能在你的脈絡裡發揮。

切 Project 沒有標準答案，我這 6 個的切法不一定適合你——重點是判斷邏輯：規範差很多就拆、素材會打架就拆、高頻任務就拆。其他的細節跟著實際使用慢慢調。

我幫過不少客戶處理 AI 工作流整合的問題，如果你的生意正在規劃怎麼把 Claude 系統性導入，可以預約 30 分鐘的免費諮詢聊聊，我可以根據你的工作型態給你具體建議。