序言：上一篇問的是：
這包方法裝進 Claude 以後，會不會讓工作環境變重？你付錢後，拿到的是可以留下來的方法，還是訂閱期間才能叫回來的內容？
這一篇問另一件更麻煩的事。
當它開始替你做出人物誌、使用者旅程、用戶回饋和設計建議時，你還分得清楚嗎：
哪些來自真實資料？
哪些是根據資料做出的推論？
哪些只是 AI 把空白補得很完整？
真正的風險，不是 AI 寫得很差。
真正的風險，是 AI 寫得太順、太像真的。於是團隊看到一份完整的人物誌、一張漂亮的旅程圖、一頁看似有根據的建議，就忘了問最簡單的一句：
這些話的證據在哪裡？
作者補充：這一篇仍然拿同三組東西對照：
Claude Code 的省 token 工作習慣；
Claude 官方的設計功能，例如你的帳號若有
/design、/design-sync，以及輸入/de後可能看見的設計相關技能；
本文把 /design 放在「把想清楚的事情做成畫面和概念原型」的位置。它可以幫你做出可討論的畫面，但不會替你找到真實使用者，也不會讓猜測自動變成研究。
所以看到 /design 和 /uxai:heuristic-critique 都帶有 design 字眼，不代表它們在做同一件事。
上一篇先帶走什麼？
上篇先把「裝不裝」這件事拆開了。
這一篇接著補上三件事：
AI 生成的回饋，什麼時候只是用來想問題，什麼時候不能再被叫做研究？
官方
/design、/design-sync和 UX 方法庫，到底各自在做什麼？新手怎麼用 AI 幫忙，而不是讓 AI 替自己假裝做完研究？
先分清楚：流程跑得通，不等於研究做完了
付費方法庫裡的「合成使用者」或「合成回饋」，最容易讓人誤會成：
裝了以後，我就可以做使用者研究。
不是這樣。
先想像你剛做出一個預約看診 App 的原型。
你可以請 AI 扮演不同情境，幫你跑一次流程：
使用者會不會找不到取消預約？
手機字體放大後，按鈕會不會被擠掉？
選日期、確認身分、提交資料，會不會卡在中間？
流程是否有明確的成功和失敗狀態？
這些是合理的早期檢查。
它在問的是：
這條流程本身走不走得通？
不是：
真實使用者為什麼會這樣想？
這裡可以把工作分成三個階段。
白話一點：
概念驗證：先看這個想法能不能跑。
小規模試行：找真人來看它能不能站住。
最小可行產品：做一個真的能用的最小版本，測最重要的假設。
它們不是同一件事。
AI 可以幫你跑流程，不能替你變出使用者
一個比較穩的早期工作流程是：
先把你已知的事情寫進自己的檔案。
讓 AI 幫你把流程、假設和反例整理出來。
用原型檢查流程是否明顯卡住。
把發現寫回自己的紀錄。
再去找真人測試。
例如，你可以先在 project.md 寫：
產品：
線上預約看診服務
使用者：
第一次使用線上醫療服務、數位信心較低的人
任務：
在 3 分鐘內完成預約，並知道如何改期或取消
限制：
手機優先；字體需要可放大；不能假設使用者熟悉醫療術語
成功條件：
使用者能完成預約、看懂確認訊息、找到取消或改期入口
然後才請 AI 幫你做有限度的事：
根據 @project.md：
1. 列出這個流程可能卡住的 5 個地方
2. 為每個卡點提出一個反例
3. 標記哪些是推測，不是研究發現
4. 列出下一步可找真人驗證的問題
這樣 AI 是幫你找漏洞，不是替你發明一群「很像使用者」的人。
如果你手上真的有去識別後的訪談逐字稿、放聲思考紀錄或可用性測試觀察，AI 可以幫你整理。
但輸入材料、最後判斷與寫回紀錄，都還是你的責任。
你可以把這個低預算流程想成四步：
輸入：使用自己的去識別資料
整理：把資料轉成可測試的任務、情境和成功條件
檢查：讓 AI 協助找卡點、反例與明顯問題
寫回：把結論、限制和下一步驗證方式寫回自己的檔案
/design 可以幫你把畫面做出來。
但畫面做出來，不代表概念驗證已完成。
概念驗證做完，也不代表你做過使用者研究。
不要把一張能點的畫面，直接寫成：
我們已經驗證了使用者需求。
這中間差了一整段真人資料。
合成回饋可以用，但不能冒充訪談
這裡要講清楚：問題不是 AI 生成的人物誌本身。
合成內容可以有用。
它可以幫你：
找出可能被漏掉的例外情況
幫你壓力測試訪談題綱
想像反對意見
把模糊的設計假設寫清楚
列出下一輪該找真實使用者確認的問題
在進入真人測試前，先抓掉很明顯的流程問題
但它不是參與者資料。
它不是訪談。
它不是可用性測試。
它不是使用者說過的話。
它也不是可以對外宣稱的研究發現。
真正危險的情況是：
AI 生了一份「使用者回饋」，團隊把它放進簡報，最後說：
「使用者告訴我們……」
如果沒有招募、沒有真人、沒有原始材料、沒有分析過程，這句話就站不住。
所以每一份合成內容都應該有一張小標籤：
來源：
模型生成 / 使用者提供的去識別資料 / 混合
是否包含真實參與者資料：
是 / 否
這份內容可用於：
假設、反例、流程風險、早期概念驗證
這份內容不能用於：
宣稱研究發現、宣稱已完成使用者驗證
下一步要驗證什麼：
要由哪一種真實資料確認？
例如：訪談、任務測試、問卷、客服紀錄、產品數據
有了這張標籤，合成內容不必被丟掉；但它比較不容易被誤當成研究。
NN/g 也建議，合成使用者產生的洞察應視為需要測試的假設，真實使用者研究仍不可取代。
UX 社群還會問八件事
就算你已經知道「合成回饋不是研究」，UX 社群仍會繼續問。
這些問題不是為了讓人不敢用工具，而是避免新手把一份完整的 AI 文件，誤當成一份完整的 UX 工作。
1. 它有沒有告訴你：什麼時候不要用？
新手真正缺的，往往不是第 101 個方法，而是停下來的判斷。
例如：
現在該做訪談、任務測試，還是桌面研究？
這個方法是在探索問題，還是在驗證方案？
沒有資料、樣本太少、風險太高時，應不應該停？
醫療、金融、公共服務、未成年人或弱勢群體，能不能直接套同一套方法？
一套方法若只教你「怎麼跑」，卻沒有告訴你「什麼時候不該跑」，它少的不是進階功能，而是基本的研究界線。
2. 它是在幫你思考，還是在幫你生模板？
UX 圈很常看到這種文件：
有人物誌
有使用者旅程
有介面檢查清單
有研究摘要
有優先級矩陣
看起來什麼都有。
但只要問：
這一條結論來自哪一位使用者？哪一次測試？哪段資料？
就沒答案。
我把這叫做文件幻覺：
文件很完整，證據卻是空的。
所以要問：
它有沒有要求你標資料來源？
它有沒有要求你寫不確定的地方？
它有沒有要求你列反例？
它有沒有要求你說下一步怎麼驗證？
如果沒有，它也許能幫你做出漂亮的文件，但未必幫你做出可靠的判斷。
3. 它真的適合你的使用者嗎？
方法多，不代表什麼人都適用。
企業後台和一般消費者 App 不一樣。
高齡健康服務和電商結帳不一樣。
多語言、低識字率、不同文化背景、螢幕閱讀器使用者，也不一樣。
例如，設計給長者的醫療服務時，不能只拿電商的「縮短結帳步驟」邏輯硬套。使用者可能更在乎確認感、可撤回性、家屬協助、術語解釋和對錯誤的恐懼。
所以不要只問：
它有沒有無障礙方法？
更應該問：
它有沒有讓我看見，那些被預設使用者排除在外的人？
合成使用者特別容易產生「平均值」答案：看似合理，但缺少個人情境、情緒、例外和差異。ACM Interactions 的討論也指出，合成 UX 內容可能傾向摘要化與概括化；它或許能幫助形成假設，但不能替代對真實情境與差異的理解。
4. 這個方法的版本和來源是什麼？
如果方法放在 connector 裡，團隊要能回答：
這個方法改寫自哪裡？
有作者嗎？
有版本號和更新日期嗎？
去年跑的步驟，和今年還一樣嗎？
舊專案能不能重做當時的流程？
我們能不能記錄「當時用了哪個方法、哪個版本」？
這不是吹毛求疵。這叫能不能重做。
如果一份研究摘要只寫：
由 AI UX 方法生成。
那半年後沒有人知道它怎麼得出結論。
5. 如果 AI 建議錯了，誰負責？
AI 可以給建議，但不能替團隊承擔後果。
例如，它可能：
忽略某一類使用者
把無障礙問題排到後面
根據合成回饋建議砍掉功能
對長者、移民、身心障礙者或低收入使用者做出錯誤假設
最後要問的是：
誰決定採用？
誰看過原始資料？
誰有權說「AI 這次錯了」？
工具可以出初稿、列風險、提出反例。
但產品決策、研究結論與對外聲明，還是要有人負責。
6. 它會不會讓新手跳過真正的研究能力？
這是 UX 教育裡很敏感的問題。
如果新手一開始就讓 AI 一鍵生人物誌、旅程圖、洞察與建議，他可能學會的是「怎麼下指令」，而不是：
怎麼找對的受訪者
怎麼建立訪談信任
怎麼追問模糊回答
怎麼聽出沉默、猶豫和矛盾
怎麼從原始資料整理出主題
怎麼承認「我們還不知道」
AI 很會補空白。
但 UX 研究很重要的一部分，是知道：
有些空白不能補，只能回到人身上問。
這不是反對工具，而是反對拿完整的文件假裝已經完成研究。
7. 敏感資料被送到哪裡？
如果工具鼓勵你把訪談逐字稿、客服紀錄、病歷情境、內部規劃或行為資料丟進 connector，先不要急著貼。
先問：
資料會傳到哪裡？
是否會保留？
是否可能用於訓練？
保存多久？
能不能刪除？
有沒有去識別化流程？
受訪者是否同意資料會交給第三方 AI 工具？
是否符合你所在地的隱私與研究倫理要求？
這不只是資安問題。
這也關係到你是否對研究參與者誠實。
本文沒有逐項審查這個 connector 的隱私條款。所以我不會說它一定合規，也不會說它一定有問題。正確做法是：使用前自己查清楚。
8. 省下來的時間，最後花到哪裡去了？
AI 工具常說：更快、更便宜、不必招募。
UX 社群會反問：
省下來的時間，是拿去做更多真實驗證，還是乾脆把驗證刪掉？
兩種用法差很多。
合成內容比較適合做低風險的假設生成、工具測試、教學練習和例外情境檢查。
但如果是高風險決策、與弱勢群體有關的服務，或會直接決定產品方向的研究，就不能把它當成真實使用者的替代品。
/design、設計系統和研究，別放進同一格
付費方法庫很容易讓人覺得：
Claude 本身不夠懂 UX，所以我需要再加 101 個方法。
但其實很多工具做的是不同工作。
下面這張表不是官方規定，而是比較好用的工作分工。實際能用哪些技能，仍要看你的帳號、版本與你在 /de 裡看到的選項。
/design-sync 的公開描述是把 repository 裡已有的 React 設計系統轉換並上傳到 Claude Design，讓畫面能使用真實元件。它不是「看一張圖就替你長出一套設計系統」的保證。
所以有三個常見誤會：
你已有設計評估或無障礙檢查技能，又加一個名字很像的付費方法，可能只是重複。
/design能做出可點畫面，但不能生出真實使用者資料。能從一張畫面長出一套風格，不代表那就是一套可以被團隊維護的設計系統。
