Dairny Lab NAS、自架與數位工作流
AI 工具 2026.05.15 7 分鐘閱讀

Chat 不只是問答——Projects 和長上下文才是精髓。

Claude 的 Chat 模式不只是問答。搭配 Projects 建立持久上下文、善用 200K token 長上下文處理大量資料、掌握幾個 Prompt 寫法——這篇整理 Chat 模式的完整使用方式。

Claude Chat 深度使用：Projects、Prompt 技巧與對話工作流

Claude 的 Chat 介面是大多數人的入門方式：開網頁、打字、拿答案。這樣用可以，但只發揮了它一小部分的價值。

Chat 模式真正強的地方在於Projects 持久上下文、200K token 長上下文，以及幾個能讓輸出品質明顯提升的 Prompt 寫法。這篇把這些整理清楚。

Claude Chat 使用流程

Projects：不再每次從零開始

普通對話每次都是全新開始，你得不斷重複說明背景。Projects 解決這個問題。

什麼是 Projects

Projects 是一個持久的工作空間。你把相關文件、設定說明放進去，之後這個 Project 裡的所有對話都自動帶著這些上下文，不需要每次重新說明。

建立 Project

  1. Claude.ai 左側欄 → Projects → New Project
  2. 點擊 Project Instructions — 寫下你要 Claude 知道的背景
  3. Add content — 上傳相關文件（PDF、TXT、程式碼等）
  4. 之後在這個 Project 內開啟的對話，Claude 都會讀取這些內容

Project Instructions 怎麼寫

Instructions 是這個 Project 的「持久系統提示」。寫得好，每次對話都省去大量說明時間。

範例：部落格寫作 Project

你是一個繁體中文技術部落格的寫作助手。

部落格定位：NAS、自架服務、數位工作流，目標讀者是台灣科技愛好者。

寫作規則：
- 使用台灣繁體中文用詞（不用簡體詞彙）
- 直接說重點，不用「當然！」「很好！」開場
- 技術術語保留英文（Docker、NAS 不翻譯）
- 每篇文章要有實際步驟，不只是概念

輸出格式：
- 標題用 H2（##）
- 步驟用數字清單
- 程式碼用 code block

範例：研究分析 Project

你是一個研究助手，幫我分析和整理資料。

背景：我在研究台灣中小企業的數位轉型現況。

分析風格：
- 先說結論，再說證據
- 用數字和具體例子支撐論點
- 如果資料不足，直接說「資料不足」，不要猜測
- 指出不同來源之間的矛盾

Projects 的上傳文件

可以上傳的格式：PDF、TXT、程式碼、Markdown、試算表等。上傳後 Claude 會讀取這些文件的內容，在對話中可以直接引用。

實際用法： - 把公司的文件規範 PDF 傳進去，要求 Claude 按照規範寫作 - 把程式碼庫的架構說明傳進去，問架構相關問題 - 把競品分析資料傳進去，請 Claude 幫你整理比較

長上下文：一次餵大量資料

Claude 的 200K token 上下文視窗是實際用得到的功能。

Token 大概是多少

內容 約 token 數
一般對話一輪 500–2,000
一篇文章（2,000 字） ~3,000
一份 PDF（50 頁） ~50,000
一本書（300 頁） ~150,000

200K token 足夠同時處理幾本書或一整個中型程式庫。

長上下文的實際應用

多文件彙整：上傳 10 份報告，請 Claude 找出共同結論或矛盾之處，輸出比較表。

整本書分析：把書的 PDF 上傳，「找出這本書關於 X 主題的所有論點」、「整理作者的核心主張」。

長對話不失憶：不需要一直提醒「我們之前說過...」，Claude 在長對話中保持連貫性很好。

Prompt 技巧：讓輸出更符合需求

幾個實際有效的 Prompt 寫法，不是理論，是直接可以用的模式。

給明確的輸出格式

模糊的要求：「幫我整理這份文件的重點」

清楚的要求：

幫我整理這份文件的重點，格式：
- 條列式，每點不超過 30 字
- 最多 5 點
- 如果資訊不足，直接說「資料不足」，不要猜測

輸出格式越明確，需要修改的次數越少。

給角色設定

你是一個資深的 DevOps 工程師，正在 Review 初級工程師的 Docker Compose 設定。
指出問題但語氣建設性，說明為什麼這樣改更好。

角色設定讓 Claude 知道應該用什麼專業角度和語氣回應。

要求分步驟思考（複雜問題）

這個問題請你：
1. 先列出可能的原因（不超過 5 個）
2. 針對最可能的原因提出解法
3. 說明你最推薦哪個解法和理由

分步驟要求讓 Claude 不會跳過推理直接給答案，複雜問題的輸出品質明顯提升。

限制回答範圍

只回答關於 Nginx 設定的部分，其他的我已經處理好了，不需要說明。

避免 Claude 把你已知的背景知識重複說一遍。

要求不確定時說明

如果你不確定，直接說「我不確定」，不要猜測或給可能不準確的資訊。

對需要精確資訊的場景特別重要。

對話工作流建議

寫作工作流

  1. 建立一個寫作 Project，放入風格規範
  2. 新對話：「這篇文章的主題是 X，目標讀者是 Y，請先列出大綱」
  3. 確認大綱後：「展開第二節」、「把這段改得更口語」
  4. 最後：「整篇文章有沒有邏輯跳躍或重複的地方」

不要一次要求 Claude 從頭寫到尾，分段迭代的品質更好。

研究分析工作流

  1. 上傳所有參考資料到 Project
  2. 「先告訴我這些資料的整體方向和主要觀點」（先建立全局觀）
  3. 「深入分析 X 這個面向」
  4. 「這些資料對 Y 問題的回答是否一致？有沒有矛盾？」

問題解決工作流

  1. 詳細描述問題（背景、已嘗試過的方法、預期結果）
  2. 讓 Claude 提問：「你需要什麼額外資訊才能給出更準確的建議？」
  3. 補充資訊後再要求解法

常見問題

Q：Chat 和 Projects 的對話歷史會一直保留嗎？ 對話會保留，但 Claude 不會自動「記住」你說過的事情帶到新對話。Projects 的 Instructions 和上傳文件是持久的，但對話本身在新對話開始時不會自動帶入。

Q：一個 Project 可以多少對話？ 沒有明確上限，可以建立很多對話，都共享同一套 Instructions 和文件。

Q：200K token 夠嗎？會不會用完？ 一般使用很難碰到上限。同時貼入幾份大型 PDF 才會接近。如果快到上限，Claude 會提示你。

小結

Chat 模式的核心用法： - Projects — 建立持久上下文，避免重複說明背景 - 長上下文 — 一次餵大量資料，讓 Claude 做全局分析 - Prompt 格式 — 給明確的輸出格式和角色設定，減少反覆修改

從「問問題」到「建立工作空間」，是 Chat 模式使用層次的跨越。

🔗 系列文章

這篇有幫助嗎？ Chat 不只是問答——Projects 和長上下文才是精髓。
—