[AI／UX 實作] 付費 UX 方法新手技能包（上）：101 個指令裝進 Claude ，等等，先別急著買

序言：有人把付費 UX 方法庫包裝成「新手技能包」。

聽起來很吸引人：裝進 Claude，一次多 101 個 UX 指令。

原本不知道怎麼做人物誌、旅程地圖、介面檢查或設計評估，現在好像輸入一條指令就有人帶路。看起來像是把「專業 UX」一次裝進電腦。

但先別急著下結論，說它值或不值。

因為這裡其實混了四件不同的事：

1. 裝進去後，Claude 的工作環境會不會變得更重、更難用？

2. 裡面的功能，和你本來已經有的功能會不會重複？

3. 你買到的是可以留下來的方法，還是訂閱期間才能叫回來的內容？

4. 它做出來的「用戶回饋」，到底是研究證據，還是只是一個待驗證的猜測？

這是上下兩篇文章。

上篇只談兩件事：

• 裝進 Claude 以後，到底多了什麼成本？

• 你付費拿到的內容，到底是不是你的？

下篇才談另外兩件事：

• 它和 Claude 原有的設計功能有沒有重複？

• AI 生成的 persona、回饋和洞察，什麼時候只是猜測，什麼時候才能算研究？

先講一個重要差別：說「裝了以後變重」，其實可能是兩種完全不同的事。

第一種是：指令變很多，選單很長，人開始不知道要選哪一個。
第二種是：真的多花 token，帳單或用量變高。

不要看到「101 個指令」，就直接說它一定很貴。要先看它到底在哪裡變重。

作者補充：這篇拿三組東西來對照。

第一組，是 Claude Code 常見的省 token 做法：清空舊對話、整理上下文、不要把大段日誌留在主對話、先看目前載入了什麼。

這些做法有些可對照 Claude Code 官方文件；文中的情境例子則是工作流示意，不是客戶個案。

第二組，是 Claude 官方的設計路徑。

你的帳號若看得到 /design、/design-sync，或輸入 /de 後出現設計相關技能，這些就是你本來可能已經有的能力。它們和付費方法庫到底重不重疊，下篇再逐項對。

第三組，是 UX+AI MCP 和它的 plugin。

它提供 101 個方法、2 個技能；但 GitHub 上的 plugin 主要是指令與設定，方法正文由付費 connector 提供。

這篇沒有客戶帳單，也不會假裝替你算「每月到底省多少」。我只想先把問題問清楚：

你裝進去的，是一個幫手、一份可留存的方法，還是一個會一直掛在工作環境裡的訂閱入口？

後面要拿這些習慣去對照付費方法庫，所以先用白話把它們講完。

你不需要把 11 條全部背起來。把它當成整理工作桌的規則就好：

• 不同工作，不要硬塞在同一張桌上。

• 不要把已經沒用的文件一直攤在桌面。

• 不要叫 Claude 自己猜檔案在哪裡。

• 不要把幾千行測試輸出全塞給它看。

• 要離開前，把真正重要的結論寫下來。

Claude Code 官方文件說得很直接：每次對話都可能重帶系統提示、專案設定、先前訊息與工具輸出；不相關工作之間可用 /clear 開新對話；長工作可用 /compact 壓縮舊脈絡。快取是否命中，會影響你是否必須重新處理前面的內容。

下面是 11 個常見習慣。不要把它當成考試題庫；你只要看懂它們在防什麼。

早上你請 Claude 幫忙檢查銀行 App 的無障礙問題。它看過色彩對比、螢幕閱讀器標籤、元件命名和報告草稿。

下午你要改電商網站的優惠碼 bug。

這兩件事沒什麼關係。

若你不清掉前面的內容，Claude 在處理購物車問題時，可能還帶著上午一大包銀行 App 的資料。那些資料不一定每次都會直接讓你付大錢，但它們會讓對話越來越雜，也可能在快取失效時增加重新處理的成本。

/rename banking-a11y-audit
/clear
修復 src/cart/applyCoupon.ts：
- 同一優惠碼被重複套用
- 只改最小必要範圍
- 補一個 Vitest 回歸測試

最簡單的判斷是：

• 客戶換了：清。

• 專案換了：清。

• 上午研究、下午除錯：清。

• 同一件事只是討論繞遠了：不要立刻清，先考慮 /compact 或 /rewind。

但有一個例外：還沒把結論寫進自己的檔案前，不要急著 /clear。不然你清掉的不是雜訊，而是你剛整理出來的判斷。

你準備重構一個很大的 TypeScript 表單系統。

Claude 已經讀過架構、核心檔案和測試。

這時你忽然切換模型、調高或調低 /effort，或第一次打開 /fast。Claude 可能需要把前面的內容重新處理一次。

白話說：你本來走在一條已經鋪好的路上，做到一半換了一條路。

前面那段省下來的力氣，可能得重新花。

/model opus
/effort high
目標：重構 packages/forms。
先讀 @docs/form-architecture.md 和 @packages/forms/README.md。
先提出分階段計畫；沒有確認前不要修改。

這不代表每次都要選最強模型、最高思考強度。

真正值得開高檔的，是架構遷移、權限設計、資安修補、複雜資料轉換、醫療或金融規則。

如果只是批次改檔名、整理 Markdown、改 import、更新版本號，不必讓 Claude 用最昂貴的方式反覆深思。

假設你正在寫 AI 治理報告。Claude 已讀過訪談逐字稿、政策文件、風險表格；你也已經整理出報告大綱。

接下來你要去上課兩小時。

這時不要只把終端機放著，期待回來後一切都在。快取有保存時間；超過時間後，前面那一大段內容可能要重新處理。

比較好的做法是：

• 先把真正重要的判斷寫進你的檔案。

• 再叫 Claude 把本輪工作壓成短摘要。

/compact 保留：
1. 報告主張與章節大綱
2. 已確認與待查證的內容
3. 重要引用檔案、段落和行號
4. 下一步要做的三件事
刪除已完成的探索和重複討論。

但如果你只是離開幾分鐘，而且很快回來，未必要硬做 /compact。壓縮本身也要讀一遍舊對話，不是免費魔法。

你本來只想修一個資料處理錯誤。

結果聊了幾輪後，Claude 開始建議你改資料庫結構、重寫下游流程、加入新的排程工具，還讀了一堆不相干的檔案。

這時你不需要把錯誤方向「整理得更漂亮」。

你需要回到它還沒走歪的地方。

/rewind
回到它開始提議「重構整個系統」之前，然後重新說清楚：
只修 models/staging/stg_orders.sql 的 customer_id 空值處理。
不要改資料表結構。
不要新增模型。
不要改下游儀表板。
先提出最小修補方案和測試方式。

/compact 是把正確但太長的對話縮短。
/rewind 是把錯路刪掉。

不要把兩個當成同一件事。

不要只說：

幫我看看帳號刪除功能有問題。

這句話等於叫 Claude 自己在整個專案裡找線索。

它可能要搜尋、開很多檔、猜哪個流程有關，最後把一堆不必要內容留在對話裡。

比較好的做法是直接給它這次要看的材料：

請依據 @docs/data-retention-policy.md、
@src/privacy/deleteAccount.ts、
@tests/privacy/deleteAccount.test.ts 修正帳號刪除流程。
要求：
- 保留法律保留期內的稽核紀錄
- 刪除行為資料與推播 token
- 不得刪除仍在退款爭議期間的付款證據
- 先列出現況與政策不一致的地方，再修改

原則很簡單：

• 這次需要的檔案就給；不需要的不要塞。

• 同一份檔案不要一直重複標記。@ 不是越多越好。

「測試掛了，幫我修。」

這對人類同事都太模糊，對 Claude 更是如此。它只好猜：哪個測試？哪個檔？要不要跑全套？可不可以改資料庫？

結果就是它先到處找，跑很多東西，再把大量輸出帶回對話。

改成這樣：

修復 packages/billing 的失敗測試：
- 指令：pnpm vitest packages/billing/tests/refund.spec.ts
- 失敗案例：退款後 invoice.status 應為 refunded
- 相關檔案：packages/billing/src/refundInvoice.ts
- 已知情況：Stripe webhook 有到，但資料庫交易被回滾
- 不可修改：payment schema 與其他 packages
- 完成條件：原測試通過，並新增一個回滾測試

你不是在省幾個字。你是在避免 Claude 花一堆步驟去找它本來不必找的東西。

大型專案跑測試時，可能出現幾千行輸出：成功的測試、警告、棄用通知、覆蓋率、打包資訊。

你不需要全部交給 Claude。

pnpm vitest packages/checkout --reporter=dot
pnpm lint packages/checkout --quiet
git log --oneline -20
pnpm test 2>&1 | tail -n 80

意思不是「永遠不要看完整日誌」，而是：

平常先讓 Claude 看失敗處和最後一段；真的找不到原因，再往前挖。

你也可以在 CLAUDE.md 裡先寫規則：

## 測試輸出規則
- 預設使用 vitest --reporter=dot
- 測試失敗時，保留失敗段落與最後 100 行
- git log 預設只看最近 20 筆
- 除非變更跨套件，否則不要跑整個專案的測試

有些專案一打開 Claude Code，就覺得還沒做事已經很慢、很重。

這時不要猜，直接輸入：

/context

你可能會發現問題不是程式碼，而是：

• CLAUDE.md 寫了兩千行舊流程；

• 每個 MCP 都開著；

• 設計、研究、部署、客服的規則全都常駐；

• 每個子資料夾都放一大段重複說明。

可以把它想成出門前把整個家背在身上。

改法是：

• CLAUDE.md 只留每次都要遵守的規則；

• 偶爾才做的流程，放到按需要才叫出的 skill；

• 不用的 MCP 先關掉；

• 大量日誌或長文件，交給子代理處理，主對話只收摘要。

這也是你在裝 101 個 UX 指令之前，最該做的第一件事：先看它到底加重了哪一層。

不是每件工作都值得最強模型加最高 /effort。

例如，你要替 40 篇文章改標籤，給標籤對照表和檔案清單就夠了。不要叫 Claude 每篇都重新思考內容策略。

半夜發生系統事故，Nginx、Kubernetes、應用程式和追蹤系統的日誌加起來幾十萬行。

不要把它們一段段塞進主對話。主對話很快就只剩錯誤訊息，原本的問題反而被淹掉。

這種事可以交給子代理：

使用子代理分析 logs/incident-2026-08-18/。
目標：
1. 找出第一次出現 5xx 的時間
2. 對照部署紀錄、資料庫延遲和佇列深度
3. 列出最可能的原因及證據
4. 回傳不超過 500 字的摘要，附檔案和行號
不要修改任何檔案。

主對話只拿最後結論。

但如果你只是要改一個函式名稱、確認某個 endpoint 在不在，就不用特別叫子代理。叫人進來、重新交代背景，也有成本。

如果你要每 30 分鐘檢查一次庫存、價格或資料更新，不要放在已經聊了一整天的主對話裡。

/loop 30m 檢查 inventory.csv：
- 找出庫存少於 10 的 SKU
- 與昨天快照比較
- 只有新增缺貨風險才回報

把它放在另一個終端機、另一個乾淨會話裡。

主工作對話是書桌。
循環任務是定時鬧鐘。

不要把鬧鐘、研究資料、程式錯誤和設計討論全堆在同一張桌上。

到這裡，11 條不用全記住。跟本文最有關的是三條：

• 用 @ 檔名 給 Claude 你自己的材料

• 新會話先跑 /context

• 換工作前先把結論寫回自己的檔，再 /clear

這三條會直接撞上「101 個方法要不要裝」的問題。

你本來只想做一件很小的事：

同一個設計任務，看看這包方法庫究竟是讓選單變長，還是真的讓 token 變貴。

結果你裝完 plugin，輸入 /uxai，跳出一長串方法。

接著又看到兩個 skill，寫著任務合適時會自己判斷要不要上場。

看起來很完整。也很專業。

但你其實還沒知道：

• 選單多了，是否真的影響工作？

• 它什麼時候才會真的載入方法內容？

• 它和你原本已有的能力差在哪？

• 你用完後，方法能不能留下來？

所以第一步不是急著把每個指令都試一遍。

第一步是：

1. 開一個乾淨會話
2. 輸入 /context
3. 看 CLAUDE.md、系統提示、MCP 各佔多少
4. 看 slash 選單多了多少條
5. 還沒裝的人，先讀 plugin README

README 已寫明，GitHub repository 放的是指令定義與設定；方法正文由 connector 提供。

上篇只談第一題和第三題。

第二題與第四題留到下篇，因為那裡才要說清楚：官方 /design 會做什麼、不會做什麼；合成回饋可以怎麼用、又不能怎麼騙自己。

101 個 /uxai: 指令，不代表 101 篇方法全文都被塞進 Claude 的腦袋。

這點要先講清楚。

但選單變長，還是有成本。你可以把它想成餐廳菜單。

一家店只有 8 道招牌菜，你很快知道要點什麼。
另一家店有 101 道菜，而且名字都很像：評估、快速評估、系統評估、AI 評估、無障礙快速檢查……

你不一定吃得更多，但你會花更多時間：

• 找自己真正需要的方法

• 猜每個名字差在哪

• 擔心自己點錯

• 半年後回頭時，忘了當時用了哪一個方法

對個人來說，這是選擇疲勞。
對團隊來說，這是交接和稽核問題。

所以我把它叫做「選單稅」。

/uxai: 有自己的前綴，確實比直接和官方指令撞名好。但前綴不同，不代表選單沒有變長。

另一件事才是 token。

不要把「101 個指令」直接翻譯成「101 倍 token 成本」。

Claude Code 很多 MCP 工具和 skills，是需要時才載入。你看到一個指令，不代表完整方法內容已經進了對話。官方文件也說明，工具資訊可延後到真正需要時才查找，skills 通常也在實際使用時才載入完整內容。

所以比較公平的說法是：

101 個指令可能讓選單變長；真正的 token 成本，要看你呼叫了什麼、何時呼叫、它載入了什麼。

最簡單的測法，是用同一個任務做四次：

A：乾淨會話，不裝 plugin
B：裝 plugin，但不叫任何 UX 方法
C：裝 plugin，明確叫一個 UX 方法
D：讓會自動啟動的 skill 做同一個任務

每次記錄：

- /context 一開始顯示什麼
- MCP、skills、CLAUDE.md 各佔多少 token
- 第一次任務的輸入 token
- 有沒有讀到快取
- 有沒有觸發工具搜尋
- 任務完成花了幾輪
- 最後有多少東西真的寫回 project.md

A 和 B 看的是：裝了之後，選單和起始資訊多了什麼。
C 和 D 看的是：真正使用方法後，多載入了什麼。

本文沒有跑過這組測試，所以不會假裝有帳單數字。

這件事跟方法好不好沒有直接關係。

你可以把它想成 Netflix。

訂閱 Netflix，你可以看很多片。
但你沒有買下那些電影。

取消訂閱後，Netflix App 可能還在手機裡，但你不再能打開片庫。你也不能隨意把電影存進公司的硬碟，說它是你們的內部教材。

付費 UX 方法庫也可能是同樣的模式：

• 訂閱還在時，Claude 可以透過 connector 叫回某個方法。

• 訂閱停止後，connector 可能就不能再把方法叫回來。

• plugin 還裝在電腦上，不代表方法正文還在。

• 方法內容也未必可以合法複製進團隊 wiki、CLAUDE.md、project.md 或正式作業流程。

這不是說它不好。

它只是代表你買的是：

使用權，不是永久持有權。

對一個人來說，這可能很合理。

如果你只是偶爾需要 Claude 帶你做一次介面檢查，或幫你整理一份需求說明，你不一定要永久擁有整套方法手冊。

但團隊要多問一步。

假設半年後：

• 訂閱取消了

• 新同事加入

• 客戶問當時怎麼做

• 主管要回頭檢查當時的研究與決策

如果你們不能留下方法步驟和當時的依據，最後可能只能說：

當時我們透過一個外部連線，跑過某個方法。

這很難交接，也很難重做。

所以團隊採購前先問一句：

我們能不能合法把這套方法的步驟，留在自己的 wiki、作業流程和專案紀錄裡？

如果不能，這不是小字。這就是你買的產品的一部分。

到這裡，不要急著問：

這包方法庫到底夠不夠專業？

先問兩件事：

• 它讓你的工作環境多了什麼成本？

• 你付費後拿到的是可留下來的方法，還是訂閱期間才能叫回來的內容？

如果選單、token、方法版本和保存權都還說不清楚，就先不要急著把 101 個方法裝進每天都用的工作環境。

下一篇才談真正更麻煩的問題：

當 AI 開始替你生成 persona、回饋和洞察時，你怎麼確保那不是一份看起來很像研究、其實沒有研究證據的文件？

下篇只問一句：

它生出來的「用戶回饋」，到底是研究證據，還是待驗證的假設？

會談四件事：

1. 為什麼流程走得通，不等於使用者真的想這樣做

2. 為什麼合成回饋最多只能當假設，不能直接叫做用戶研究

3. 官方 /design、/design-sync 和付費 UX 方法到底在哪裡重複、在哪裡不同

4. 新手如何把 AI 放在助理位，而不是證據位

如果你這週只打算裝一包「新手技能包」，上篇的最低門檻已經夠用：

先說清楚選單多了什麼、token 多花在哪、方法能不能留下來；再決定要不要連線。

至於 AI 生成的回饋能不能叫研究，先別急著在簡報上寫「使用者告訴我們」。

• UX methods 新手技能包（下）：合成回饋不是研究，AI 只能放助理位

• 燒Token一晚做出的demo，讓你更容易把事業交底給平台

• 組織 AI Builder 省了 77% 的 Token，三個月後董事會問得出什麼？

稽核軌跡

觀點、判斷與專欄裡的自製概念是我的。資料蒐集與初稿撰寫有 agent 參與，成稿由我逐段改定。每一則引語、數字與來源，發稿前都對過原始文件；「讀者回函」系列引用的來信與提問來自真實讀者。寫錯了算我的。

Copyright © PrivacyUX Consulting Ltd. All rights reserved.

• Joshua 是 Agentic UX（代理式使用者體驗）的先驅，在人工智能與使用者體驗設計領域擁有超過 15 年的開創性實踐。他率先提出將用戶隱私保護視為 AI 產品設計的核心理念，於 2022 年創立 Privacyux Consulting Ltd. 並擔任首席顧問，積極推動隱私導向的醫療 AI 產品革新。此前，他亦擔任社交 AI 首席策略官（2022-2024），專注於設計注重隱私的情感識別系統及用戶數據自主權管理機制。