Claude Instructions 怎麼寫？好指令跟爛指令差在哪（附我的真實範例）

「幫我寫一篇 Shopify 教學文章。」

「參考搜尋結果前五名的文章，寫出一篇更好的內容。」

這兩種是我看過最多人放進 Claude Project Instructions 的寫法。看起來都很合理，實際上 Claude 都做不好。

原因不是 Claude 不夠強，是這兩句話從頭到尾沒告訴 Claude：你要的是什麼樣的東西、寫給誰看、用什麼語氣、避開什麼地雷、寫成什麼格式。Claude 只能用平均值去猜——猜出來的東西，就會是那種一看就「AI 寫的」的內容。

Instructions 沒寫好，Project 開再多個都救不回來。這篇我會把 Instructions 到底在做什麼、爛指令跟好指令差在哪、我自己文章專案 Instructions 的真實摘錄，完整講一遍。

Instructions 到底在做什麼？為什麼新手寫的都沒用

很多人把 Instructions 當成「下指令」——以為寫進去之後，Claude 就會照那個指令做。所以才會出現「幫我寫一篇 Shopify 教學文章」這種寫法，以為這就夠了。

但 Instructions 不是「指令」，是「這個 Project 的世界觀跟操作手冊」。你不是在告訴 Claude 一次性的任務，你是在告訴它：在這個 Project 裡，你是誰、你要做的事情是哪一類、品質的標準是什麼、不能踩的線在哪。

這個差別很大。一次性的任務是 Prompt（對話視窗裡的單次指令），Instructions 是讓 Claude 在這個 Project 裡進行每一次任務時都會先讀一遍的底層設定。

所以回頭看那兩句爛指令：

• 「幫我寫一篇 Shopify 教學文章」——這是一次性任務，放進 Instructions 也沒意義。Claude 收到的是「在這個 Project 裡你要做的事就是寫一篇 Shopify 教學文章」，但下次你要寫的是不同主題，Instructions 又得改。Instructions 應該寫的是「在這個 Project 裡，你會被反覆用來做這類事情」的規則，不是某一次具體要做的事。
• 「參考搜尋結果前五名的文章，寫出一篇更好的內容」——這句更糟。「更好」的標準是什麼？是 SEO 排名嗎？是讀者體驗嗎？是長度嗎？是有觀點嗎？Claude 只能用統計平均值的「更好」去猜，結果就是寫出一篇看起來像是把前五名混在一起、再加幾句空話的文章。

好的 Instructions，讀完之後 Claude 應該能回答：「我在這個 Project 裡要產出什麼類型的東西、寫給誰、用什麼語氣、結構怎麼安排、不能寫什麼、品質怎麼判斷。」如果讀完答不出這些，Instructions 就是沒寫好。

爛 Instructions 的三個共同特徵

我看過幾十份新手寫的 Instructions，爛的那種幾乎都有這三個特徵。中一個就會出問題，中兩個以上產出基本上不能用。

特徵一：太籠統，沒講清楚到底要什麼

「寫一篇教學文章」「整理會議紀錄」「幫我做產品分析」——這類描述沒有任何細節。讀者是誰？教學深度到哪？會議紀錄要分幾段、要不要列出待辦事項？產品分析包含哪些面向？

Claude 不是讀心術。籠統的 Instructions 等於告訴 Claude「自己想吧」，它就只能用最普遍的版本去做——但「最普遍的版本」通常就是別人都有的內容，沒有區分度。

特徵二：把判斷責任丟給 Claude

「你決定就好」「依你判斷」「視情況調整」——這類話聽起來很尊重 AI，實際上是在迴避「我自己也沒想清楚」這件事。

Claude 收到「你決定」這種指令時，會用機率最高的選項去做——通常就是平均值、通常就是無聊。如果你希望產出有個性、有觀點，你必須先說清楚你要的個性是什麼。把判斷丟給 Claude，結果就是 Claude 的判斷也是平均值。

特徵三：沒有審美跟品質的判準

大部分爛 Instructions 都只寫「做什麼」，沒寫「什麼樣算好、什麼樣算爛」。沒有判準，Claude 出版之後你看了不滿意，卻很難說清楚到底哪裡不對——因為從頭到尾就沒定義過「對」是長什麼樣。

好的 Instructions 會明確告訴 Claude：這樣的句子可以、那樣的句子不行；這種開場可以、那種開場不行。有對照，Claude 才知道往哪個方向走。

好 Instructions 的三層結構：規範、範例、邊界

我自己摸索了一年多，現在每個 Project 的 Instructions 都會分成三層寫。這個分層不是規定，是我自己用下來覺得最不會漏東西的結構。

第一層：規範類

這一層放「不能讓步的硬規則」。例如寫作風格、結構框架、必做的事項、輸出格式。

規範類的特徵是「沒得商量」——這個 Project 裡每一次任務都要遵守。例如我文章專案的規範類包含：第一人稱「我」、繁中全形標點、不放痛點框、CTA 用淺灰底自然句、URL 不含年份。這些是 Claude 必須無條件遵守的。

寫規範類的關鍵：具體到讓 Claude 可以執行，不要寫成抽象原則。「保持專業」是抽象原則，沒用；「不用『本人建議』要用『我建議』」才是規範。

第二層：範例類

這一層放「正例跟負例的對照」。光寫規則，Claude 還是可能解讀錯——你說「口語化」，它可能理解成「用 LOL、XD」這種網路用語。所以要給它對照。

「❌ 不要這樣寫：本文將為您詳細介紹⋯⋯」「✅ 要這樣寫：直接講重點。」這種一對一的範例，比寫十條規則都有用。

範例類不用寫多，但每一條都要是你真的會反覆遇到的情境。我文章專案的 Instructions 大概有 8 組正反例，涵蓋開場、語氣、Roy 經驗框寫法、CTA 用法——都是我寫文章時最常出錯的地方。

第三層：邊界類

這一層放「絕對不能做的事」。跟規範類不同，邊界類處理的是更嚴重的後果——可能傷害客戶信任、可能違反法律、可能造成品牌風險。

例如我文章專案的邊界類包含：不寫客戶具體案例（只能匿名化）、不寫稅務法務具體建議、不寫客戶諮詢內部流程、價格費用必須查官方頁面確認。這些不是「最好不要」，是「絕對不行」。

邊界類分開寫的好處，是 Claude 會把它當成最高優先級。當其他指令跟邊界類衝突，邊界類永遠贏。

我自己 Instructions 的真實摘錄（文章專案）

講概念太抽象，直接看實物比較有感。我的「網站文章專案」用了一年多，這個 Project 已經幫我產出 80 篇以上的文章（其中 Claude 系列文 CTR 達到 7-17%）。Instructions 經過幾十次回頭調整，以下是去識別化後的真實摘錄。

我把 Instructions 分成三段呈現，對應三層結構。

規範類：寫作風格與結構規範

規範類的重點：每一條都是「可以直接執行的動作」，不是抽象原則。Claude 看完知道要做什麼、不能做什麼。

範例類：語氣與寫法的正反對照

範例類的重點：讓 Claude 知道「哪種寫法可以、哪種寫法不行」，不是只給原則。給 Claude 一對一的對照，它就會學會。

邊界類：絕對不能踩的線

邊界類的重點：用「絕對」「必須」這種強烈的語言。這些不是「最好」「建議」，是 Claude 必須無條件遵守的。我有過幾次 Claude 寫出來的價格是過時或錯的，從那次之後，「價格必須查證」就被升格進邊界類，不只是規範類。

Instructions vs Files：規範放哪邊、範例放哪邊

Claude Project 除了 Instructions，還有 Files（Knowledge）這個欄位。很多人搞不清楚兩者的差別，結果不是把該放 Files 的東西塞進 Instructions（把指令撐到爆），就是把該放 Instructions 的規則丟進 Files（Claude 不會優先讀）。

我自己的分工原則很簡單：

具體一點看：我文章專案的 Instructions 寫「結構規範包含 Article Schema + FAQPage Schema」，而完整的 HTML 模板（裡面有 Schema 的具體寫法）放在 Files。Instructions 寫「文章必須符合集群策略」，而 10 份集群策略檔（C1 到 C9）放在 Files。

這樣分的好處：Instructions 一直保持精煉（讓 Claude 每次對話讀進去的負擔小），Files 可以無限累積（我目前 Files 有 20 多份檔）。如果把 HTML 模板塞進 Instructions，光那一份就會把 Instructions 撐到上萬字，Claude 讀進去的成本會變高，反而效果下降。

判斷哪邊放的快速法則：這個東西是「規則」（每次都要照做）還是「素材」（需要時才參考）？規則放 Instructions，素材放 Files。

更完整的 Project 架構規劃，我寫在另一篇Claude Projects 工作流裡，如果你還沒看過建議搭配讀。

寫完 Instructions 後的 5 個檢查點

Instructions 寫完別急著用，先用這 5 個檢查點過一遍。漏掉任何一個都會在後續產出時遇到麻煩。

檢查點 1：這個 Project 的目標一句話能說清楚嗎

「這個 Project 是用來做什麼的」——能不能用一句話講完？如果說不清，代表你還沒想清楚這個 Project 的範疇，Instructions 就很容易寫得鬆散。

我文章專案的一句話：「這個 Project 用來產出 AJ MarTech 全站基底 SEO 文章，涵蓋 10 個 Topic Cluster，目標是用第一人稱『公開實驗者』語氣建立 Topic Authority，自然轉換成諮詢跟電子報訂閱。」

檢查點 2：讀者是誰、寫給誰看，有講清楚嗎

幾乎所有 Instructions 都會漏掉這條。「讀者」決定了語氣、深度、用詞、舉例方向。沒有這條，Claude 只能寫給「平均使用者」——而平均使用者通常就是沒人。

我會在 Instructions 裡寫：讀者是台灣 SMB 跟服務業者、有基本商業概念但不一定懂 SEO、會被「不講行話」吸引、痛點是「找客戶」「網站架了不會用」這種具體場景。

檢查點 3：有沒有給「品質好壞」的判準

不是寫「保持高品質」這種廢話，是寫具體的判準。例如：「好的文章是讀者看完會做某件事（訂閱、預約諮詢、收藏）；爛的文章是讀者看完只覺得『資訊很多』但不知道下一步該幹嘛。」

檢查點 4：邊界類有沒有寫清楚

邊界類沒寫清楚，出事的時候會很麻煩。寫到一半才想到「啊這個不能寫」，代表邊界類是後加上去的——後加是來不及的。事前就要列清楚：絕對不能寫的內容、必須查證才能寫的內容、需要匿名化的內容。

檢查點 5：有沒有給 Claude「不確定時該怎麼辦」的指引

這條最容易漏。Claude 遇到不確定的時候，如果 Instructions 沒給指引，它會用機率最高的選項去猜——猜錯的話你要花時間修。

我會在 Instructions 寫：「遇到價格、費用、政策、法規類資訊，如果不確定，先告訴我『這部分我需要查證才能寫』，不要自己猜。」「遇到客戶具體案例，如果不確定可不可以寫，先用『我幫過的某個客戶』這種匿名化框架，等我確認再放具體細節。」

給 Claude「不確定時的退路」，比寫一千條規則都有用。

不該放進 Instructions 的東西

寫好 Instructions 的另一半，是知道什麼不該寫進去。我看過太多人把 Instructions 撐到很長，結果效果反而更差——因為塞了太多不該放的東西。

不要放：一次性的任務指令

「幫我寫一篇 Shopify 教學文章」這種，是 Prompt（對話視窗指令），不是 Instructions。Instructions 是「在這個 Project 裡每次都會遵守的規則」，不是「這次要做的事」。把一次性任務塞進 Instructions，下一次要做別的事就要回去改 Instructions——這條根本不應該被建立。

不要放：會頻繁改的偏好

例如「這週我想用比較幽默的語氣」——這是一次性偏好，放對話裡就好。Instructions 是穩定的設定，如果某個東西一個月會改三次，代表它本來就不該在 Instructions 裡。

不要放：大份量的素材

HTML 模板、文章範例、Brand Book、URL 清單——這些都該放 Files，不是 Instructions。塞進 Instructions 會讓 Claude 每次對話都消耗大量 Token 讀進去，反而影響它對真正重要規則的注意力。

不要放：沒想清楚的偏好

「依你判斷就好」「彈性處理」「視情況調整」——這類話放進去等於沒放，還會讓 Claude 以為「這個地方可以隨便」。如果你還沒想清楚，先不要放，真的要放的時候要寫清楚。

不要放：過時、不再有效的舊規則

Instructions 用一陣子之後，有些早期定的規則可能已經不適用。例如我早期 Instructions 寫過「文章字數 2,200-2,800 字」，後來發現這個限制反而影響內容深度，就拿掉了。沒拿掉的舊規則會持續影響 Claude 的判斷，所以「定期回頭審視」是必要的——這也是下一段要講的。

多久該回頭調 Instructions

Instructions 不是寫完就放著的。我自己每隔一兩個月會回頭看一次，觸發回頭調的信號有幾個：

信號 1：同樣的錯誤重複出現

如果你發現 Claude 一直在犯同一種錯——例如老是用「先講結論」開場、老是把 Roy 經驗框寫得太正經、老是漏掉 Schema——代表 Instructions 對這個地方沒講清楚。這時候要回去補規範或補範例。

判斷邏輯：如果你已經在對話裡糾正過 Claude 同一件事超過 3 次，就該升級到 Instructions。對話裡糾正只影響當前那一輪，Instructions 才能讓改正永久生效。

信號 2：新工作流穩定後

當你發現有個新流程或新類型的任務變成例行——例如我後來加入了「電子報 CTA 中段、諮詢 CTA 結尾」這個結構規則——這時候要把它寫進 Instructions，讓 Claude 之後預設就會這樣做。

信號 3：邊界類有新狀況

當你發現某個風險出現（例如 Claude 寫了一段你覺得不該公開的話、或寫出過時的價格），要立刻把這個邊界補進 Instructions，而且寫得比之前更明確。我邊界類裡「價格必須查官方頁面」這條，就是 Claude 寫過幾次過時的 Shopify 月費之後加上去的。

信號 4：Instructions 變太長

如果 Instructions 越寫越長，超過 3,000-4,000 字，要考慮哪些東西該移到 Files。Instructions 不是越長越強，反而會稀釋 Claude 對核心規則的注意力。長的話通常是因為塞了該放 Files 的素材。

我自己的節奏大概是：每寫完 5-10 篇文章就回頭看一次 Instructions（修改到穩定後可以視情況 3 個月再檢查一次即可），看有沒有新模式該加、有沒有舊規則該砍。「引導與調教」是個持續的過程，Instructions 不是一次定稿，是一份會跟你工作流一起成長的活文件。

常見問題

延伸閱讀

• Claude Projects 怎麼用？我把生意切成 6 個專案的工作流
• Claude 用途實戰盤點：我每天靠它做的事
• Claude 用了 18 個月後，我的真實心得（Pro→Max 升級路徑）
• Claude 行銷實戰：每天怎麼用 Claude 做內容、策略、分析
• Claude AI 商業應用完整指南

最後

Instructions 寫得好不好，差距不在「文字寫得多漂亮」，在「你有沒有先把這個 Project 該做什麼想清楚」。所有爛 Instructions 都有同一個根：作者自己也沒想清楚要什麼，只好把責任丟給 Claude。

真正能用的 Instructions，通常是「我先寫了一版 → 用了一陣子發現問題 → 回去改 → 再用一陣子 → 再改」這樣磨出來的。第一版不會完美，沒關係，重要的是有第一版可以開始迭代。

我幫過不少人看他們的 Claude Project Instructions，大部分問題不是技術問題，是「他自己也不確定要什麼」。如果你寫了一版自己不太滿意產出，歡迎預約 30 分鐘的免費諮詢，我可以幫你看看 Instructions 哪邊可以加強，或者你的 Project 該不該切。