很多人使用 Claude 的方式是開一個新對話、貼問題、複製答案，然後結束。這種方式適合一次性問題，卻不適合需要反覆修改、保留背景或產出檔案的工作。
這篇不是把每個功能重新介紹一次，而是回答一個更實用的問題：同一個任務要放在哪個工作介面，才能少重複說明、保留驗收標準，最後真的交付成果？
先選工作介面，不要先選功能
| 你要完成的事情 | 建議介面 | 產出 | 主要限制 |
|---|---|---|---|
| 長期維護同一個主題、專案或寫作規範 | Projects | 帶有固定背景的多次對話 | 文件與權限要定期整理，不能假設內容永遠最新 |
| 把文字、資料或需求變成可修改的檔案／小工具 | Artifacts | HTML、Markdown、SVG、React 或其他可交付內容 | 產出仍要在目標環境測試，預覽不等於正式上線 |
| 讀取程式碼、執行測試、修改多個檔案 | Claude Code | 可在本機驗證的程式碼變更 | 必須限制目錄、檢查 diff，敏感資料與破壞性指令不能盲目授權 |
| 只想問一個明確問題 | Chat | 一次性的回答 | 不適合當成長期知識庫或變更紀錄 |
這張表的重點是「交付物」：如果最後需要一個檔案、一個可執行結果或一組可驗證的修改，就不要只停在聊天回答。
工作流一：用 Projects 維持長期寫作背景
Projects 適合把規範、受眾、既有內容與參考資料集中在一起。它的價值不是讓 Claude 永遠記得所有事情，而是讓每次新對話都有一個可檢查的共同起點。
建立可維護的 Project
建議把內容分成三層，而不是把所有檔案都丟進去：
- 固定規範：網站定位、用語、文章格式、禁止事項。
- 參考資料：官方文件、產品規格、已核對的研究資料。
- 本次任務：這一篇文章要解決的讀者問題、目標關鍵字與驗收條件。
Project Instructions 可以先寫成這種形式：
你是繁體中文技術內容的協作助手。
工作目標：協助我把一個明確的讀者問題整理成可驗證的文章。
輸出規則：
- 使用台灣繁體中文；技術名詞保留英文
- 先列出主張與需要查證的來源，再開始寫正文
- 不確定的資訊標示「待確認」，不要自行補齊
- 每個結論都要說明適用條件、限制或取捨
- 不要把官方文件、個人經驗與推測混寫
寫作時仍要為每篇文章開一個任務對話，明確告訴 Claude 哪些資料是本次有效版本。Project 能保存背景，不能取代編輯者對日期、來源與事實的覆核。
工作流二：把資料整理成可交付的 Artifact
Artifacts 適合「看得見、改得動、能帶走」的產出，例如比較表、單頁 HTML、SVG 圖表、Markdown 文件或小型互動工具。它不只是把回答放在另一個視窗，而是把產出物與對話分開，方便逐輪修改。
一個可重複的 Artifact 流程
- 先說明輸入資料、目標讀者與使用情境。
- 指定輸出格式與不可違反的限制，例如不使用外部追蹤、不洩漏原始資料。
- 要求 Claude 先列出資料缺口與假設，再建立第一版。
- 以驗收清單逐項測試，而不是只說「看起來不錯」。
- 匯出後在實際環境開啟，檢查手機版、錯誤輸入、連結與檔案內容。
例如要做 NAS 備份選擇器，可以這樣下指令：
請把以下備份需求做成單頁 HTML 工具。
先列出你使用的假設；缺少的資料不要自行猜測。
驗收條件：
- 使用者可以選擇資料類型、恢復時間目標與預算
- 結果要同時顯示推薦方案與不適用的原因
- 不連接外部 API，不收集輸入資料
- 手機寬度 390px 時仍可操作
- 最後附上手動測試清單
Artifact 的預覽只證明它能在預覽環境顯示，不能證明部署後的 CSS、瀏覽器相容性、資料安全或商業邏輯都正確。
交付前再交給 Claude Code：把產出變成可驗證的變更
當任務需要讀取專案、修改檔案、執行測試或反覆修正時，Claude Code 比網頁聊天更適合。重點不是「讓 AI 自動改完整個專案」，而是把任務拆成可以審查的變更。
建議的四段式循環
1. 說明目標與不能改動的範圍
2. 先要求檢查現況並提出計畫
3. 只核准一個小變更，要求列出 diff 與驗證結果
4. 通過測試後再進入下一個變更
可以用下面的提示開始：
請先閱讀這個專案的建置與測試方式，不要修改檔案。
接著列出：
- 你理解的問題
- 可能受影響的檔案
- 最小修改方案
- 驗證指令
如果需要新增依賴或接觸秘密資料，先停下來詢問。
每次變更後至少檢查 git diff、測試輸出、產出檔案與錯誤日誌。涉及刪除資料、公開服務、帳號權限或部署設定時，要由人確認最後一步。
把三個介面串成一條工作流
對一篇需要研究、產圖與修改網站的文章，可以採用這個順序：
- 在 Projects 放入網站定位、既有文章與編輯規範。
- 用 Chat 先拆出讀者問題、證據需求與文章大綱。
- 用 Artifacts 做比較表、流程圖或互動範例，並先完成手動測試。
- 把已核對的文字與資產交給 Claude Code，修改網站模板或內容檔案。
- 在本機建置、跑內容稽核、用瀏覽器檢查，最後才推送部署。
這樣分工的好處是每一層都有不同的驗收方式：背景是否正確、產出是否可用、程式變更是否可回復。不要讓同一個聊天同時扮演資料庫、設計工具與部署代理，否則出錯時很難知道是哪一層造成的。
哪些事情不能直接交給 AI
- 沒有來源的價格、版本、方案資格或法規結論。
- 未經檢查就發布的產品比較與推薦。
- 含有 API key、密碼、個資或未公開商業資料的檔案。
- 會刪除資料、改變權限、公開連接埠或部署到正式環境的指令。
- 只看畫面預覽，卻沒有在目標瀏覽器、手機或實際資料上測試的產出。
AI 可以加快整理與修改，但責任仍在內容作者與專案維護者。對 Dairny Lab 這類技術網站，來源、限制、更新日期與可重現步驟，比「回答看起來很完整」更重要。
常見問題
Q：Projects、Artifacts、Claude Code 要全部一起用嗎？
不用。先看任務最後要交付什麼：長期背景用 Projects，可修改的檔案用 Artifacts，程式碼變更用 Claude Code。簡單問題留在 Chat 即可。
Q：Claude Code 會自動保證程式碼正確嗎？
不會。它可以協助讀檔、執行指令與修改程式，但測試、diff 審查、秘密資料保護與正式部署仍需要人工確認。
Q：Artifacts 可以直接當正式網站嗎？
不應直接假設可以。匯出後要重新檢查依賴、資產、瀏覽器相容性、無障礙、資料流與部署安全。
小結
Claude 的進階用法不是記住更多提示詞，而是把任務放到適合的工作介面，並為每個產出定義驗收方式：Projects 管背景，Artifacts 管可見產出，Claude Code 管可驗證的程式變更。
資訊來源與文章範圍
本文是工作流與工具選擇指南，不是 Claude 功能或模型效能測試。方案資格、介面位置、檔案限制、可用模型與安全功能可能變動；執行前請以官方文件為準。文中的提示詞是示例，不代表任何模型都會產生相同結果。
- Anthropic：What are projects?
- Anthropic：What are artifacts and how do I use them?
- Anthropic：設定 Claude Code
🔗 延伸閱讀
- Claude Chat 深度使用：Projects、Prompt 技巧與對話工作流
- Claude Code 實戰：CLI 安裝、開發流程與多步驟任務
- Claude Cowork 深度使用：Artifacts 讓 AI 直接產出可用的東西
- Claude 三種入口怎麼選：Chat、Cowork、Code 工作流總覽
- Prompt 工程實戰：真正有效的寫法與技巧
