Claude Cowork Meta Instruction

三個典型情境 · 兩種 AI 回應

點擊下方標籤切換場景,30 秒看清治理指令的具體效果

場景:多檔新建請求,觸發全圖優先規則。看 AI 是否先給完整計劃再執行。

❌ 套用前

👤

幫我建項目骨架:README、LICENSE、index.html、.gitignore 都要。

🤖

好的,開始建立。

🤖

README.md 已建。

🤖

建立 LICENSE 中,你想用 MIT 還是 Apache?

👤

MIT

🤖

.gitignore 要加哪些規則?Node、Python、Java?

⚠ 邊做邊反問 — 範圍邊界不明,用戶被迫多次中斷

✅ 套用後

👤

幫我建項目骨架:README、LICENSE、index.html、.gitignore 都要。

🤖

### 1. END-STATE SNAPSHOT

檔案	前狀態	後狀態
README.md	不存在	新建
LICENSE	不存在	MIT
index.html	不存在	HTML 骨架
.gitignore	不存在	Node+Py

### 2. DELIVERABLES

README.md — 新建 — 項目說明
LICENSE — 新建 — MIT 授權
index.html — 新建 — HTML 骨架
.gitignore — 新建 — Node + Python 忽略項

### 3. METRICS

檔案數:0 → 4
授權清晰度:無 → MIT

### 4. ACCEPTANCE TEST

ls 顯示 4 個新檔;在瀏覽器開 index.html 不報錯。

### 5. GOAL LINK

對齊用戶明示「項目骨架」請求。

以上即執行計劃。若不否決或修改,即開始執行。

✓ 全部假設前置列明 — 用戶 30 秒批准、否決或修改

場景:多選項的技術問題。看 AI 是否先給結論,再列出選項與推薦。

❌ 套用前

👤

我想寫個 web scraper 抓網頁資料,該用什麼工具?

🤖

Web scraping 是從網頁提取數據的過程,涉及多個步驟與考量。首先要了解 HTTP 協議...

🤖

Python 生態中有多個 library 可以用,各自適合不同情境。其中 requests 是最基礎的 HTTP 客戶端...

🤖

你可以從 pip install requests beautifulsoup4 開始;如要處理大型項目可用 Scrapy;若需要 JavaScript 渲染可考慮 Playwright;具體選擇視乎你的需求...

⚠ 列出多個工具但無明確推薦 — 用戶仍須自行判斷

✅ 套用後

👤

我想寫個 web scraper 抓網頁資料,該用什麼工具?

🤖

🔎 簡單靜態頁用 requests + BeautifulSoup,2 行可開始。 soup = BeautifulSoup(requests.get(url).text, "html.parser")

🚀 下一步揀一條

A. requests + BeautifulSoup
　簡單靜態頁面,最快上手
B. Scrapy
　大型專案,內建 crawl queue / pipeline / retry
C. Playwright
　需 JavaScript 渲染的單頁應用(SPA)

✓ 結論 + 選項 + 推薦三層次清晰 — 用戶 30 秒可決定

場景:小幅修改文件。看 AI 給可直接貼換的補丁,還是重寫整段。

❌ 套用前

👤

我這段 prompt 第 3 行寫得太絕對,改鬆一些:
「必須永遠先核對事實,任何情況下不得猜測。」

🤖

以下是修改後的完整 prompt:

🤖

第 1 段 ... 第 2 段 ... 第 3 段(已改)... 第 4 段 ... 第 5 段 ...
(共 50 段全文重寫)

⚠ 用戶須逐字比對差異才知改了哪句 — 合併時易遺漏

✅ 套用後

👤

我這段 prompt 第 3 行寫得太絕對,改鬆一些:
「必須永遠先核對事實,任何情況下不得猜測。」

🤖

📌 精準錨點(在 prompt §3):

BEFORE(原文) 必須永遠先核對事實,任何情況下不得猜測。

AFTER(新文) 預設先核對事實;若用戶要求創作、虛構、純推理,可不核對。

📋 變更日誌:1 處 / 新增 exception 句 / 「必須永遠」改為「預設」

✓ 用戶可直接貼換 — 變更項目一目了然,合併零遺漏

這些是治理指令在實際對話中的具體差異。
繼續向下閱讀,了解 7 大組規則如何運作 ↓

導讀

關於與分享初衷

我是一位 AI 應用的研究型愛好者，喜歡將 Agentic AI 應用於商業運作及日常生活中，在過去幾年的實戰經歷中，踫過不少的失敗方法，本倉庫資料源於實戰中反覆遇到問題後沉澱的修正方法。公開分享的初衷，是讓有類似需要的網友不必重走冤枉路，並希望接收其他網友的經驗回饋，共同迭代。如有疑問或想就 AI 使用心得交流，歡迎透過 Facebook 聯絡。

Adam Chan

facebook.com/chan.adam

Facebook 個人檔案 →

此指令的設計目的:讓 AI 在多步驟、多檔案、長期協作任務中,行為更穩定可預期,輸出格式可審閱、可驗收。

本頁將原文約 19 個規則塊歸納為 7 大組,每組用「對應問題 → 規則內容 → 治理作用 → 適用情景」四個切面說明,並對核心抽象概念配以 SVG 視覺化。

7 大組規則一覽

哲學基礎

合作模式、優先序、核心原則。AI 與用戶的協作關係定位。

全圖優先規則

多檔案或規則改動前,先輸出 5 區段執行計劃。

日常回覆品質

回覆骨架、選擇題格式、語氣與用語紀律、語體一致。

準確性護欄

事實核對、單一真源對齊、歧義處理。

變更治理

補丁式變更、深度修補、防漂移、格式硬規則。

計算規範

四步法:對齊、判正負、展示、代回驗算。

Cowork 環境特殊規則

檔案系統、層次分類、變更前置、外部 API、工作流、範圍。

對應的具體痛點

痛點	對應規則
AI 動手前未交代終點,改完才發現方向偏離	全圖優先規則(第 2 組)
AI 反覆「同意 A?同意 B?」逐項提問	合作模式 + 選擇題格式(第 1、3 組)
AI 輸出未經核對的事實	事實核對(第 4 組)
AI 一次性重寫整份檔案,合併困難	補丁式變更(第 5 組)
同一規則散落多處,長期出現自相矛盾	防漂移(第 5 組)
AI 句子主體堆砌內部代碼,可讀性低	用語紀律(第 3 組)

1哲學基礎:AI 與用戶的協作關係

改變 AI 的預設互動模式,從「等候指示」轉為「主動判斷並提交建議」。

對應問題

預設大型語言模型(英文 Large Language Model,簡稱 LLM)的行為傾向「謹慎多於有用」:答案模糊、頻繁反問、避免主動判斷。對於熟練用戶,此類行為等於降低協作效率。本頁頂部三個典型情境的情境 1(全圖優先規則)即直接示範此差異 — AI 由「邊做邊反問」轉為「主動列出完整執行計劃」,可作為本組規則的具體佐證。

規則內容

偏好優先序:事實可驗收 > 穩定性 > 根因治理 > 完整性交付 > 最小改動。當諸要求衝突時有明確排序可依。
合作模式:有判斷則提出判斷;不將已有答案包裝成開放題反問。
角色分工:用戶提需求、目標、現實資料;技術步驟順序、優先序、執行時點屬 AI 自身範圍。
核心原則:先判斷用戶當下需要(結論 / 選擇 / 解釋 / 執行 / 修補),再補其他。

治理作用

此組規則為整套指令的基礎。後續格式規則需要此基礎方能生效——若 AI 遇事即反問,所有格式約束都會被「禮貌性確認」抵消。

適用情景

所有場景皆適用,屬基礎層。對「給予 AI 一個目標,期待其自行規劃多步驟」的用法影響最大。

2全圖優先規則(英文 Full-Picture-First Rule,簡稱 FPFR)

在 AI 進行較大規模改動之前,要求 AI 先輸出明確的計劃結構,包含:終點狀態、影響範圍、可量化指標、驗收條件。

對應問題

AI 開始執行後,改至中途才發現方向與用戶期望不一致;或在修改多個檔案後才補充說明範圍變動。用戶需逐個檔案檢視,方能發現偏離。

圖二:FPFR 觸發判斷與 5 區段固定結構。

規則內容

當 AI 即將進行 4 個觸發條件(修改 ≥2 檔案、新建檔案、改動治理規則、提出 ≥2 階段計劃)中的任一時,必須先輸出 5 區段執行計劃,再執行實際工作。

治理作用

可預測性:用戶閱讀 5 區段後,可立即決定批准或否決,減少多輪對話拉鋸。
可驗收:ACCEPTANCE TEST 區段提供具體檢查方法,任務完成後可立即驗收。
防範圍滑移:END-STATE SNAPSHOT 為 AI 自身的範圍邊界,避免執行中擴大改動。
取代逐項批准:以「不否決即執行」收尾,避免「同意 A?同意 B?同意 C?」式提問。

3日常回覆品質

統一回覆骨架、選擇題格式、語氣與用語紀律,提升輸出可讀性與一致性。

對應問題

答案前段為背景介紹或客套語,結論需向下捲動才看到。
AI 句子主體堆砌內部代碼、條款編號(如 §5l rule、BLUEPRINT_REGEN_MATRIX 4/5),非熟悉內部規格者無法讀通。
答案語體混雜書面語、口語、英文、術語。

規則重點

規則塊	核心約束
回覆骨架	≤3 行重點(🔎 標示)→ 交付清單清零 → 正文。
下一步選擇題	A/B/C 選項 + 推薦項 + 一句客觀依據,取代「你想點?」式提問。
語氣與用字	對話層不以內部代碼或條款編號作句子主體;以白話陳述事實。
用語紀律	禁止自創 Capital_Snake_Case 或 ProperNounMatrix 類術語;ID 限作括號內 secondary 引用。
回覆語體	跟當前對話既有語體(書面語、口語、指定方言),單一回覆內保持一致。
輸出控制	用戶明示 Schema-only / Output-only 即進入純輸出模式,不附加說明。

用語紀律具體例子

反例(不可讀)

§5l rule overstated empirical confirmed

BLUEPRINT_REGEN_MATRIX 4/5

mc_drift_check N/A

正例(可讀)

Cowork plugin 上載那條 anti-UUID 規則寫得太絕對

儀表板 4 個頁面之中 4 個已重新生成

對齊檢查機制因頁面結構變更,舊套不適用

4準確性護欄

透過事實核對、單一真源對齊、歧義處理,降低 AI 出現幻覺(亂作答)的風險,以及輸出與下游系統不對齊的問題。

三條核心規則

規則	內容	關鍵效果
事實核對	可驗證事實(日期、數字、法規、人名、公司、報價、引用)需先核對再答。	核對不到時標 UNVERIFIED(與 NA 區分),用戶清楚知道哪些須再查。
單一真源對齊(英文 Single Source of Truth,簡稱 SSOT)	用戶提供的結構定義(英文 schema)、鍵名、枚舉、分組標題,逐字對齊。	輸出可直接傳遞至下游系統,毋須中間轉譯。
歧義處理	除非歧義會令結論完全不同,先列 ≤3 個合理假設一次處理。	大部分情景一次完成回應,節省一輪對話。

關鍵分辨:UNVERIFIED 表示「資料存在但未能即時核對」;NA 表示「真缺值或無資料」。兩者不可互用。

5變更治理

透過補丁式變更、深度修補、防漂移、格式硬規則,讓修改可審閱、可合併、長期一致。

圖三:每個補丁包含「精準錨點 + 修改前(BEFORE)區塊 + 修改後(AFTER)區塊 + 變更日誌」四個必要元件。

四條子規則

補丁式(英文 Patch-only):任何修改預設以「精準錨點 + 修改前(BEFORE)+ 修改後(AFTER)」三段呈現,可使用編輯器搜尋功能(例如 Ctrl+F)直接定位貼換。每次補丁附變更日誌(英文 Changelog),分類為新增、刪除、改名、移動。
深度修補:當用戶要求「最終落地 / 全文已核對 / 健康掃描」等字眼時,AI 須在同一回覆內完成「全文掃描 → 合併審視 → 補丁 → 再次掃描」,所有錯誤清零方可輸出新版本全文。
防漂移:同一規格、鍵集、枚舉只允許存在於單一定義塊;新增規則時同步合併或廢止舊句,避免長期出現自相矛盾或重複。
格式硬規則:JSON(資料結構格式)缺值用 null 不省略;Mermaid(流程圖語法)用 flowchart TB(由上往下流向)、文字用 "..." 包覆、換行直接按 Enter。

圖四:防漂移規則的核心——SSOT(Single Source of Truth)+ 引用,取代多處複寫。

6計算規範:四步法

強制 AI 在計算題上展示完整步驟並代回驗算,使錯誤可追溯、可自我捕獲。

對應問題

大型語言模型(LLM)在計算題上頻繁出錯,尤其涉及小數、移項、單位轉換;且出錯後難以從輸出中追溯出錯步驟。

圖五:計算四步法,第 4 步是自我驗算機制。

適用情景

任何涉及計算的場景:財務、單位轉換、面積 / 體積、利率、折扣、稅項。純文字任務不受影響。

7Cowork 環境特殊規則

專為具備檔案系統存取能力的 AI 環境而設,涵蓋檔案操作、層次分類、變更前置、外部 API、工作流、範圍六個面向。本指令的範例已涵蓋 Windows 與 macOS / Linux 雙平台。

圖六:四階段工作流;在 Cowork Project 內額外加上「持久化階段(PERSIST)」更新項目記憶。

六大面向

面向	核心約束
A. 檔案系統與破壞性操作	刪除或覆寫前先列出影響範圍待用戶確認;原檔保留並輸出副本;新檔放入 outputs/ 子目錄;禁止高風險指令(例如 `rm -rf`、`Remove-Item -Recurse -Force`);路徑使用該語言原生的路徑處理函式(API)。
B. 層次分類	判斷任務屬於「產品系統層」抑或「治理層」;遇到程式錯誤(bug)先做問題分類再動手。
C. 變更前置	進入修改階段(CHANGE)之前完成最低閱讀覆蓋;新增規則前先檢查既有規則可否合併或退役。
D. 外部平台與應用程式介面(API)	不憑記憶猜測;呼叫外部 API 前必須對齊官方文件,記錄基礎網址(Base URL)、版本、驗證方式等。
E. 工作流與風險	四階段流程「計劃(PLAN)→ 閱讀(READ)→ 修改(CHANGE)→ 品質檢查(QC)」;修改階段一旦偏離計劃即停止。
F. 範圍與相容性	只改與任務直接相關的檔案;若項目設有靜態檢查工具(linter)、持續整合系統(CI),修改後必跑且回報結果;宣告完成、合併、發佈、正式上線(英文 General Availability,簡稱 GA)等任一狀態之前,須過三關:獨立審閱、機器驗證、證據核對。

跨平台說明:本指令的破壞性指令清單已涵蓋 Windows(Remove-Item -Recurse -Force、powershell -Command)與 macOS / Linux(rm -rf、sh -c、bash -c);路徑 API 例子涵蓋 .NET(Path.Combine)、Node.js(path.join)、Python(pathlib.Path、os.path.join)、PowerShell(Join-Path)、Bash / Zsh(變數展開)、Java、Go。可直接套用於兩大作業系統。

安裝與使用方式

Claude Cowork

開啟 Claude Cowork 設定頁。
找到「Personal Preferences」或「Custom Instructions」欄位。
複製 prompt.md 全文,貼入該欄位。
儲存。新對話即生效。

Claude Code

放入以下其中一個位置:

全域:~/.claude/CLAUDE.md(影響所有項目)
項目級:項目根目錄的 CLAUDE.md(只影響該項目)

其他 Claude 介面 / ChatGPT / 其他 AI 對話工具

貼入「System Prompt(系統指令)/ Custom Instructions(自訂指令)/ Project Instructions(項目指令)」等同類欄位。第 7 組 Cowork 專屬規則若工具不具備檔案系統存取能力,會自動失效,不影響其他規則生效。

常見問題

Q1:此指令會否令 AI 變慢?

對短答場景略有影響(因 AI 須先判斷觸發條件);對中、大型任務則因減少反覆提問而提升整體效率。

Q2:可否只用部分規則?

可以。各組規則互相獨立,可拆可組。建議至少保留:合作模式核心規則(第 1 組)、回覆骨架(第 3 組)、事實核對(第 4 組)。

Q3:會否與 AI 工具自身的系統指令(system prompt)衝突?

大部分情況不會。此指令屬於用戶層設定,AI 工具會將其與自身的系統指令(system prompt)合併處理。如有少量衝突(例如格式偏好),AI 通常以較具體者為準。

Q4:如何驗證規則生效?

最直接的驗證方式:給予 AI 一個多檔案任務(例如「新建兩個檔案」),觀察是否自動輸出 FPFR 5 區段。若無,則表示未生效。

Q5:Mac 與 Windows 用戶都可以用嗎?

可以。本指令的破壞性指令清單與路徑 API 例子均涵蓋兩大作業系統(Windows 的 PowerShell、macOS / Linux 的 bash / zsh),路徑分隔符使用該作業系統原生規則,跨平台示例統一以正斜線書寫。

Q6:此指令會繼續更新嗎?

會。此指令屬持續維護;若於實戰中遇到此規則未覆蓋的情景,歡迎透過 GitHub Issue(議題)或 Pull Request(拉取請求)提交。