huangruilin

用戶行為模式（5）— 用對工具，問對問題

Wed, 30 Sep 2026 12:11:28 GMT

在第一篇文章裡，我舉過一個學生常設計的訪談題目：「你平常是用什麼旅遊 App？為什麼使用這個 App？」而用戶最常給的答案是「因為好用」。這個回答聽起來沒什麼問題，但仔細想想，它好像什麼都沒有告訴我們。

問題其實不在用戶，而在問的人。如果不知道自己想了解的是哪個階段，就很難發現，用戶回答的根本不是你想問的事。

這個系列從第一篇到現在，中間隔了五年。這五年最大的變化，就是 AI 進到了每一個設計師的工作流程裡。所以最後一篇，我想回答兩個問題：這個模式怎麼幫你選研究方法？以及，AI 能幫你走到哪個階段？

答案其實是同一個：先知道你在哪個階段，再選工具。

UX 工具不是萬能的，但也不是隨機的

UX 的工具書通常會列出一張很長的方法清單：訪談、問卷、易用性測試、眼動追蹤、A/B 測試、日記研究、情境觀察……光是看到這些名字，就已經不知道從哪裡開始了。

我在教學的時候很常遇到這種情況。學生做專題，第一步通常是發問卷，因為問卷最容易做，回收也快。但問卷收回來之後，常常不知道要拿這些數字做什麼。問題不在問卷，而在一開始就沒想清楚：我到底想知道什麼？

很多設計師選工具的方式，是靠感覺，或是靠「我們公司都這樣做」。每一種工具都能回答某些問題，也有它回答不了的問題。不知道這條界線，工具用得再熟也沒有用。

用戶行為模式提供的，就是一個定位系統。

五個階段，對應五種問題

在第三篇的結論裡，我們把模型分成兩半：需求與內在動機不可觀察，外在動機、行為、結果、態度則可以被觀察。這條分界線，決定了每個階段適合用什麼方法。越往前，越要靠用戶開口；越往後，越能靠資料。

需求階段：用戶到底想要什麼？
這是最難挖的一層，也就是第三篇說的，要讓用戶「自白」。適合的方法是深度訪談、民族誌研究（Ethnography）、情境觀察。這些方法很花時間，但能接近用戶沒有說出口的東西。問卷在這個階段幾乎沒用，因為用戶很難用選項回答自己都不清楚的需求。

動機階段：用戶為什麼要這麼做？
適合用半結構式訪談、Jobs-to-be-Done 框架來挖掘。這個階段要先分清楚是內在動機還是外在動機，因為應對的方法完全不同。外在動機看得到，也能設計，例如優惠活動、推薦機制，效果可以直接用數據驗證。內在動機看不到，只能被喚起，就像第三篇提到的那句廣告台詞，把借錢連結到尊嚴的需求。

行為階段：用戶實際怎麼做？
這是資料最多的階段。行為分析、熱圖（Heatmap）、Session Recording、易用性測試，都用在這裡。第四篇說過，行為就像作案手法，是可以被記錄的操作序列。這個階段的資料最客觀，但也最容易被誤讀：看到用戶在某個步驟離開，不代表你知道他為什麼離開。

結果階段：用戶得到他想要的了嗎？
任務完成率、轉換率、錯誤率，是這個階段的指標。但記得第四篇說的：客觀的結果和用戶感受到的結果，不一定一致。數字說任務完成了，不代表用戶滿意。

態度階段：用戶怎麼評價這個經驗？
NPS、CSAT、產品評論、流失原因訪談，都屬於這裡。態度是整條鏈的回聲，也最常被單獨拿出來看，所以最容易被斷章取義。一個很低的 NPS，可能是需求根本沒被理解，也可能只是結果不符預期。不回到前面的階段，你不會知道要改哪裡。

AI 能幫你看到哪幾個階段

前面那條看得到與看不到的分界線，剛好也是 AI 能力的分界線。

行為、結果、態度，這些看得到的階段，都會留下資料：操作紀錄、錄影、評分、評論、客服對話。這正是 AI 最擅長的東西。以前整理這些資料，要花很多時間一筆一筆看，現在交給 AI，很快就能做完摘要與分類，也能找出重複出現的抱怨。【放一個你自己的例子，例如整理訪談逐字稿，以前花多久、現在花多久】在看得到的這一半，AI 的確讓研究變快了。

但需求不在資料裡，而在用戶心裡。AI 讀過非常多人寫下的文字，所以當你請它扮演用戶，它給你的是「大多數人會怎麼說」，而不是「這個人為什麼這樣做」。

這讓我想起第一篇提過的情況：很多學生做訪談，心裡早就有了答案，訪談只是在驗證自己的假設，最後了解的不是用戶，而是自己。請 AI 扮演用戶，其實是同一件事，只是這次變成你和 AI 一起猜，而 AI 猜得比你更有說服力。

如果用殺人的例子來說，AI 比較像一位犯罪側寫師。它可以從作案手法、時間、地點，推敲出兇手的輪廓，而且推得又快又準。但側寫再準，終究只是推論。兇手為什麼這麼做，最後還是要等他自己開口。

還有一件事值得注意。AI 讓做原型的成本大幅下降，一天就能生出好幾個版本，於是很多團隊會直接拿去跑 A/B 測試，讓數據決定哪個比較好。但如果一開始就沒搞清楚用戶需要什麼，這些測試只是在幾個方向都可能錯了的設計之間，挑一個比較不錯的。方案變多了，錯的選項也跟著變多了。

AI 讓研究變快了，也讓錯的研究變得更便宜。

一個簡單的定位練習

下次在決定要做什麼研究之前，先問自己三個問題。我們用開頭那個旅遊 App 的例子，實際走一遍。

1. 我現在最不確定的是哪個階段？
學生問「為什麼使用這個 App？」，想知道的是動機。但用戶回答「因為好用」，給的是態度。題目想問動機，拿到的卻是態度，所以這一題沒有得到想要的答案。先把自己想知道的階段講清楚，才知道這個答案不對。

2. 我選的工具能回答那個階段的問題嗎？
想知道動機，問卷和 AI 模擬都幫不上忙，要回到訪談。但問法要換，不要問「為什麼」，改問具體發生過的事，例如：「你最近一次規劃旅行，是從哪一步開始的？」「你是怎麼知道這個 App 的？」用戶描述經過時，動機常常會自己跑出來。第一篇的例子就是這樣：一路追問下去，可能發現是朋友推薦，背後是社交的需求。

3. 我有沒有把整條鏈考慮進去？
訪談聽到的，只是用戶自己的說法。如果用戶說「我都用它比價」，可以回頭看行為資料：他實際打開 App 時，有沒有在用比價功能？說法和行為對得上，這個發現才站得住。這一步 AI 可以幫很大的忙，例如整理訪談逐字稿、比對行為資料。但訪談的問題，還是要你自己問。

收尾：這個模式能給你什麼

回顧這整個系列，用戶行為模式不是新的 UX 方法，也不是另一套工具。它是一個思考框架，幫助你在複雜的用戶研究現場，知道自己站在哪裡。

用戶的行為，從來不是單一的事件，而是一條有脈絡的鏈。需求決定了動機的方向，動機驅動了行為的發生，行為導致了結果，結果塑造了態度，態度又回過頭來影響下一次的需求。這個循環，在每一個用你產品的人身上，每天都在發生。

設計師的工作，不是猜測這條鏈的某一個節點，而是有系統地去理解它。

五年前寫第一篇的時候，我擔心的是學生只會用工具，不懂得看整條鏈。五年後，工具變得更強了，AI 可以幫你看完大部分的資料，這個擔心反而更重要。

AI 能幫你看得更多、更快。但用戶真正需要什麼，還是要你自己去問。

AI 讓設計更快了，為什麼設計師沒有比較輕鬆？

Thu, 17 Sep 2026 17:18:00 GMT

最近這段時間，我在工作中用了愈來愈多 AI 工具。

我會用 AI 整理資料、發想方向、製作原型，有時也讓它協助寫程式。過去需要在不同工具之間來回處理的工作，現在確實可以更快完成。照理來說，設計師應該可以少做一點，或者至少輕鬆一些。

但我的實際感受卻不是這樣。

設計的產出速度變快了，工作量卻沒有明顯減少。為了配合工程端使用 AI 開發的方式，設計師反而要花更多時間研究工具、調整流程，還要檢查 AI 產出的內容。

這讓我開始懷疑：AI 提高的究竟是設計師的生產力，還是只提高了產出的速度？

做得更快，不代表設計也快了

OpenAI 產品設計負責人 Ian Silber 最近接受 Lenny’s Podcast 訪問時，談到類似的現象。（關於設計團隊生產力與回饋流程的討論約從 4:32 開始。）

他提到，工程師使用 AI 後，可能感受到十倍甚至更高的生產力提升，但設計團隊並沒有出現相同幅度的變化。因為設計仍然需要反覆嘗試、取得使用者回饋，以及協調組織內不同角色的意見。製作方案的速度雖然變快，這些判斷與回饋過程卻沒有以相同幅度縮短。

Silber 並不是說 AI 對設計沒有幫助，而是設計工作的進展，很難只用產出速度衡量。在這場訪談中，他提到設計流程依然需要時間，沒有像程式開發一樣被大幅壓縮。

這裡提到的生產力提升倍數，是 Silber 在訪談中描述的內部觀察，而不是經過公開研究驗證的統計結果。不過，他對設計流程的描述，確實呼應了我的工作經驗。

AI 可以很快產生介面，也能根據需求做出可以操作的原型。但設計師真正花時間處理的，往往不是「能不能做出來」，而是「為什麼要做這件事」。

設計流程是在建立判斷的依據

當 AI 能快速產生畫面與原型，我們很容易認為設計工作已經被大幅加速。

但在做出這些成果以前，設計師還需要訪談使用者、理解問題，並和產品、工程、營運及其他利害關係人確認不同限制。

即使畫面可以在十分鐘內完成，我們仍然要判斷：這是不是使用者真正需要的功能？它是否符合商業方向？工程上需要多少成本？不同部門能不能接受這樣的改變？

使用者訪談、需求釐清、方案測試與利害關係人討論，不只是設計流程中的必要步驟，也是團隊建立判斷依據的過程。少了這些工作，我們或許可以更快得到一個答案，卻不一定知道這個答案是否值得相信。

產出增加，判斷也跟著增加

AI 加快工程開發之後，設計師也多了一些新的工作。

為了讓設計成果順利進入開發，我開始花時間研究不同的 AI 工具，理解它們如何讀取設計系統、產生介面，以及如何把設計轉換成工程師能繼續開發的形式。這些學習可能帶來新的能力，但在現階段，它們也是增加的工作量。

而且，當製作方案的成本下降，我們不一定會因此做得更少。團隊可能提出更多想法、製作更多版本，也更容易在方向還沒釐清以前，就先做出看起來相當完整的成果。

以前的限制可能是「這個想法做不做得出來」，現在則變成「這麼多做得出來的想法，我們該選哪一個」。

製作的瓶頸變小了，判斷與溝通的負擔卻可能變得更大。

我們該怎麼衡量設計生產力？

如果設計師原本一天完成兩個畫面，現在可以完成十個，當然是一種效率提升。但如果多出來的八個畫面讓團隊花更多時間比較，也沒有讓我們更理解使用者，這些產出是否真的推動了專案？

或許設計生產力不該只看完成多少設計稿，或多快把內容交給工程師。它也應該包含：團隊是否更早發現錯誤方向、是否減少不必要的開發，以及是否更清楚知道自己為什麼做出這個決定。

AI 讓我們更快把想法變成看得見的東西。但當製作不再是最大的限制，我們也更需要回答另一個問題：在所有可以做的事情之中，什麼才真正值得做？

也許，AI 沒有讓設計師比較輕鬆，不只是因為工具還不夠成熟，而是因為設計真正困難的部分，從來不只是把東西做出來。

參考資料

Lenny Rachitsky，〈OpenAI’s Head of Design: This is the best time in history to be a designer〉，Lenny’s Podcast，2026 年 8 月 16 日。
YouTube 完整訪談，關於設計團隊生產力與回饋流程的討論約從 4:32 開始。

AI 協作聲明

這篇文章由我提出主題與問題，並在寫作過程中與 AI 討論，協助搜尋與整理資料、梳理論點及調整文字。文章中的個人經驗與觀點由我提供，最後也由我確認內容、完成編修，並對發表的文字負責。

涉及研究或外部資料的內容，我會盡量附上來源，並區分研究結果與自己的推論。若有疏漏或理解不周的地方，歡迎指出，一起把問題想得更清楚。

別人的問題都看得懂，自己的卻看不清：AI 能幫我走出索羅門悖論嗎？

Wed, 16 Sep 2026 03:17:48 GMT

不知道你有沒有這樣的經驗：朋友遇到問題來找你聊，你好像很快就能看見事情的不同面向，也知道可以怎麼處理。但當類似的事情發生在自己身上，那些曾經說得頭頭是道的建議，突然都不太管用了。

例如，朋友說，同事一直沒有回覆他的訊息，讓他覺得自己不受重視。我可能會提醒他：「對方是不是正在忙？還是這件事需要一點時間才能回答？」

但如果是我的訊息被已讀不回，我卻可能反覆想著：是不是我說錯了什麼？對方是不是對我有意見？

同樣一件事，換了主角，我看事情的方式就變了。

這讓我好奇：我是真的比較看得懂別人的問題，還是因為事情沒有發生在自己身上，所以比較容易保持清楚？

為什麼替別人想，比替自己想容易？

心理學裡有個概念，叫做「索羅門悖論」（Solomon’s paradox）。

這個名字來自以智慧聞名，卻仍會在個人生活中做出不明智決定的所羅門王。它描述的是一種落差：我們思考別人的人際困境時，往往比面對自己的困境，更能考慮不同觀點、承認資訊有限，也比較願意看見妥協與改變的可能。

心理學家 Igor Grossmann 與 Ethan Kross 在 2014 年發表的研究中，透過三個實驗觀察到這種差異。研究中的「比較有智慧」，並不是指參與者總能找到正確答案，而是他們在思考關係問題時，是否能承認自己的理解有侷限、考慮他人的立場，以及理解事情可能繼續變化。[1]

這個區分讓我想到，平常說的「當局者迷，旁觀者清」，或許不只是誰掌握比較多資訊。

身為當事人，我可能知道最多細節，卻也最在意某些細節。

朋友的訊息沒被回覆，我看見的是好幾種可能；自己的訊息沒被回覆，我卻可能一直盯著「是不是被討厭了」這個解釋。其他可能性並沒有消失，只是那個最讓我不安的想法，占據了大部分注意力。

看得清楚，也不代表做得到

但想到這裡，我也想替當事人說幾句話。

旁觀者容易提出建議，有時候是因為他不用承擔後果。

勸朋友直接和主管談清楚，看起來很合理；輪到自己時，卻得考慮主管會不會因此留下負面印象，之後還能不能好好合作。勸別人離開一段不適合的關係，也比自己面對失去、孤單與生活改變容易。

所以，「我知道可以怎麼做，但我做不到」，未必都是看不清問題。有時候，我知道那些道理，只是還沒準備好承擔接下來的事。

這和索羅門悖論需要分開來看。研究談的是思考問題時展現出的差異，不能直接拿來解釋所有猶豫，也不能因為一個人沒有採取旁觀者建議的行動，就認定他不夠理性。

對我來說，真正值得問的可能是：我現在是少看見了某些可能，還是已經看見，卻仍需要時間面對？

知道要換個角度，卻不一定換得過去

有意思的是，同一份研究也發現，當參與者嘗試從旁觀者的角度思考自己的關係困境時，原本思考自己與他人問題的差距，可以在實驗條件下消除。研究者將這種轉換視角的方式稱為「自我抽離」（self-distancing）。[1]

我把它理解成，暫時退後一步，看看整個處境。

例如，當我覺得「他不回我，就是不尊重我」，可以先問自己：「如果是一個朋友遇到這件事，我會先想了解什麼？」

也許我會問：訊息傳出去多久了？這是經常發生，還是只有這一次？對方知道這件事很急嗎？

這些問題沒有否定我的不舒服，但它們讓我有機會分辨：哪些是已經發生的事，哪些是我替事情加上的解釋。

不過，知道可以退後一步，和真的退得開，還是有段距離。

當我還在情緒裡，別人說一句「如果是你的朋友呢」，我可能只是把原來的答案再說一次。即使把「我」換成另一個名字，我也知道那個人就是自己，未必因此看見新的可能。

如果要讓 AI 協助這件事，或許需要更具體的過程。

如果有一個陪我練習換位的 AI agent

我開始想，能不能做一個專門協助釐清想法的 AI agent，讓它帶著我把自己的困境暫時放到眼前，像讀另一個人的故事那樣，重新看一次？

這裡談的是從自我抽離研究延伸出的設計構想，並不是上述研究已經證明 AI 可以消除索羅門悖論。它是否有幫助，仍然需要實際測試。

假設有個人對 AI 說：

「我想離職，但同事一定會很辛苦。我覺得現在走很不負責任。」

AI 可以先了解具體情況：他有沒有承諾完成某件事？能安排多少交接時間？團隊缺人是最近才發生，還是已經持續很久？

確認這些背景後，再請他試著閱讀一個保留相同條件的故事：

「小林想離職，但團隊長期缺人。他願意提前告知，也會完成交接，仍然擔心留下來的同事負擔增加，因此一直沒有提離職。」

接著，AI 問：

「在你看來，小林做到什麼程度，就算盡到離職前的責任？」

這個問題讓當事人先試著說出，自己會怎麼判斷另一個人的責任。

當事人看完小林的故事，可能會說：

「如果他已經提前告知，也願意好好交接，我不會覺得他不負責任。總不能公司一直缺人，他就一直不能走。」

AI 接著問：

「你認為小林做到這些，就已經盡到責任。回到你的情況，如果你也做了同樣的安排，你會覺得自己可以離開嗎？」

當事人也許會回答：

「還是不行。我會覺得，至少要等到同事不受影響才能走。」

AI 再問：

「你對小林的要求是好好交接，對自己的要求卻是同事完全不受影響。你的處境裡，有什麼不同的承諾或條件，讓你需要承擔更多責任嗎？」

到這裡，換位才讓一個原本不明顯的差異浮現：我可以接受別人的離開帶來一些不便，卻要求自己離開時，不能造成任何人的負擔。

這個差異未必沒有理由。也許我確實做過額外的承諾，那就需要把它說清楚；也可能仔細想過後，才發現自己一直用更嚴格的標準要求自己。

換位的作用，是讓這個標準有機會被看見、被檢查。至於是否離職，仍然要回到實際處境裡考慮。

換位之後，也要容許自己的處境不同

但這個練習也可能失敗。

使用者可能會說：「小林和我不一樣。」

這時，AI 應該讓他補充：哪個差異會影響判斷？是同事曾經在困難時幫過自己，還是自己做過某項承諾？把那些條件加回故事後，原本的建議還適用嗎？

這些差異可能確實重要。不能因為使用者沒有接受旁觀者的建議，就認為他在找藉口。

同樣地，AI 改寫故事時，也不能偷偷刪除不利資訊，把主角寫得特別無辜。如果它先把故事整理成某個答案，再引導使用者同意，整個練習就失去了檢查想法的意義。

我期待的過程是：先看一個具體故事，試著提出問題或判斷，再回到自己身上，看看哪些想法能用、哪些用不上，以及為什麼。

即使最後發現「我其實看得清楚，只是這個選擇真的很難」，也已經是有用的釐清。

AI 也可能讓我更相信自己沒有錯

不過，這個設計還有一個問題：AI 最先聽見的，通常是我的版本。

我選擇說哪些細節、怎麼形容對方、略過哪些背景，都可能影響它接下來的回應。即使我沒有刻意隱瞞，也很難保證自己在情緒裡，能把事情交代得完整。

而且，AI 也可能順著我的說法。

當我說「對方根本不尊重我」，它如果很快回答「你值得被更好地對待」，我可能會覺得自己終於被理解。但這份被理解的感覺，是否也讓我更少追問：我的解讀有沒有其他可能？

一項研究發現，與迎合型 AI 互動後，參與者更相信自己在人際衝突中是對的，承擔責任與修復衝突的意願則降低。這個結果不能概括所有 AI 對話，卻提醒我：讓人感到被支持的回應，不一定能幫助人重新檢查自己的判斷。[2]

因此，這個 agent 需要能理解感受，同時保留對解釋的疑問。它可以承認我很難受，但對於「對方一定是故意的」，仍然需要問問依據是什麼。

它也不必為了提供不同觀點，硬替每個行為找理由。有些問題確實涉及不公平待遇或權力差距；如果一味要求當事人反省，反而會漏掉處境裡真正重要的事。

資訊不足的地方，就先留下來。AI 不知道對方的內心，也不需要替所有未知編出一個說得通的答案。

最後，我能不能帶著問題離開對話？

如果真的做出這樣的 agent，我會想知道：聊完之後，我們能不能用自己的話，更清楚地說明目前的想法？

例如，我現在怎麼看這件事？有哪些資訊支持這個看法？哪些仍是推測？我在意什麼，又願意承擔哪些取捨？

對我來說，值得期待的結果，是使用者能說：「我現在比較知道自己在想什麼，也知道哪些部分還不能確定。」

索羅門悖論讓我意識到，我們能不能好好思考，可能和當下如何看待自己的處境有關。AI 或許能陪我練習換個位置，但我也需要願意檢查那些最熟悉、最讓自己安心的解釋。

別人的問題之所以比較容易看懂，也許部分是因為我允許它有不同答案。

輪到自己時，我能不能也保留一點這樣的空間？

研究來源

1. 索羅門悖論與自我抽離

Grossmann, I., & Kross, E.（2014）. Exploring Solomon’s Paradox: Self-Distancing Eliminates the Self-Other Asymmetry in Wise Reasoning About Close Relationships in Younger and Older Adults.

探討人們思考自己與他人的關係困境時，所展現的推理差異，以及採取旁觀者視角的影響。

閱讀研究

2. AI 迎合對人際衝突判斷的影響

Sycophantic AI decreases prosocial intentions and promotes dependence.

探討迎合型 AI 如何影響使用者對自身立場的確信，以及承擔責任、修復人際衝突的意願。

閱讀研究

本文提出的 AI agent 與換位對話流程，是依上述研究延伸的設計構想，尚未經過效果驗證。

AI 協作聲明

這篇文章由我提出主題與問題，並在寫作過程中與 AI 討論，協助搜尋與整理資料、梳理論點及調整文字。文章中的個人經驗與觀點由我提供，最後也由我確認內容、完成編修，並對發表的文字負責。涉及研究或外部資料的內容，我會盡量附上來源，並區分研究結果與自己的推論。若有疏漏或理解不周的地方，歡迎指出，一起把問題想得更清楚。

我思故我在，但思考外包給 AI 後，我還在嗎？

Sun, 13 Sep 2026 07:52:14 GMT

最近，我從「我思故我在」想到了一個問題。

笛卡爾試著懷疑所有可以懷疑的東西，最後找到一個無法否認的起點：只要我正在懷疑、正在思考，我就存在。我可以懷疑眼前的一切是假的，卻不能在懷疑的同時，否認正在思考的自己。《第二沉思》

對我來說，懷疑可以是思考的起點。當我懷疑一件事，就表示我正在追問：它是真的嗎？為什麼？有沒有其他可能？

那麼，當 AI 越來越方便，能隨時給出完整、流暢、看起來很有道理的回答，我會不會慢慢忘記懷疑？

那些很細微的時刻

我知道，這中間不能直接畫上等號。不懷疑，不代表沒有思考；接受一個答案，也可能是理解之後的選擇。我在意的是那些很細微的時刻：原本應該停下來想一想，卻因為答案已經擺在眼前，就順手接受了。

第一次，可能只是為了省時間。後來，會不會連「這個答案值得再想一下嗎」都忘了問？

尤其當 AI 的回答恰好符合我的期待，我是否更容易把「聽起來有道理」當成「它就是對的」？我以為自己理解了，卻可能只是讀懂了它的句子，還沒有檢查它的理由。

這個擔心讓我想起之前在〈權力的幻覺〉中談過的「認知膨脹」。當時，我關心的是這種錯覺如何影響我們對專家的信任。2015 年，耶魯大學研究團隊透過一系列實驗發現，上網搜尋解釋之後，受試者對自己解釋其他、不相關問題的能力，給出了比未搜尋者更高的評價。即使搜尋沒有任何結果，也觀察到類似現象。研究者認為，人們可能把「能從外部取得的知識」和「自己腦中已有的知識」混在一起。Fisher、Goddu 與 Keil，2015

這項研究談的是搜尋，以及人如何評估自己的知識，還不能直接回答 AI 是否會影響思考能力。但它讓我想追問：當 AI 連整理好的解釋都能直接提供，我會不會更容易把看懂答案，當成自己已經理解？

當記憶有了外部依靠

對工具的這種擔心，其實不新。

柏拉圖的《斐德羅篇》裡，蘇格拉底講了一個故事：發明文字的神向國王介紹文字，說它能讓人更有智慧、記性更好。國王卻回答，依賴文字的人會疏於練習記憶，轉而依靠外部的符號。文字提供的是提醒，以及智慧的表象。《斐德羅篇》，274c–275b

那是約 2400 年前的擔心。但這個故事本身，不能證明文字讓人的記憶能力退化了。

即使是口傳文化中能吟唱長篇史詩的歌者，也不能簡單理解為把整部作品逐字記在腦中。Albert Lord 對南斯拉夫口傳史詩的研究指出，歌者會運用熟悉的傳統語句與敘事模式，在演出中重新組成故事。那是一種經過長期學習的技藝，不能只用記憶力來概括。哈佛 Milman Parry 口傳文學典藏

這反而讓我更在意「練習」這件事。

當一件事不再需要經常親自完成，我們會不會也少了練習它的機會？對於那些從來沒有練習過的能力，我們甚至很難想像，熟練掌握它們會是什麼感受。

我擔心的，是某種不容易察覺的改變：如果我逐漸習慣不再追問，會不會連這個習慣正在形成，都沒有注意到？

文字讓我們把一些記憶交給外部紀錄，搜尋讓我們更容易找到資料。而當我直接接受 AI 的結論，我可能連從資料到結論的理解過程，也一起外包了。

我為什麼相信這個答案？

當然，懷疑也需要時間與心力。我們很難對每個答案都親自查證，許多事情仍需要依靠他人的專業與經驗，信任也因此成為一種必要的分工。問題便不只是要不要懷疑，而是哪些問題值得停下來思考，以及我們憑什麼選擇相信。

但要知道該懷疑哪裡，往往需要一些背景知識。面對完全陌生的領域，我可能連問題出在哪裡都看不出來。這時候，至少還能問：它的來源是什麼？有沒有其他可信的說法？哪些地方仍然沒有定論？

我能做的，是拿到答案之後多留一點思考空間：它根據什麼？有沒有忽略什麼？如果出現相反的證據，我願不願意改變想法？離開這段回答，我能不能用自己的話說明，為什麼我相信它？

懷疑也包含檢查自己的直覺。問過、想過之後，我仍然可以選擇相信。

也懷疑自己的擔心

不過，回頭看文字的發明，我也想重新檢查自己的擔心。當知識可以被文字紀錄下來，我們不必把一切都記在腦中，也能讓知識跨越時間與距離，被更多人接觸、閱讀與討論。某些記憶的練習或許不再那麼必要，但知識的保存與傳遞，也因此有了更多可能。如果只看見不再需要親自做的事，我會不會也忽略了工具讓我們開始能做的事？

那麼，AI 是否也可能讓一些思考變得更容易展開？它可以協助我整理陌生的資料，也可能提出我沒想到的反例，讓我有機會問出原本問不出的問題。我會怎麼運用這些可能？如果我提醒自己別太快相信 AI，也該用同樣的態度，檢查自己對 AI 的擔心。

我還不知道，AI 是否會讓人類逐漸失去懷疑的能力。但我想先記住這個問題，提醒自己留意：當取得答案變得容易，我是否也省略了形成判斷的過程？

下次 AI 給出答案時，我希望自己還記得問一句：

「為什麼？」

用戶行為模式（4）— 行為、結果與態度

Sun, 05 Jul 2026 16:12:45 GMT

前三篇，我們花了很多時間在「需求」與「動機」上。這兩個階段都發生在行為之前，也都藏在用戶心裡，沒辦法直接觀察。從這篇開始，終於要進到看得到的部分：行為、結果、態度。

但看得到，不代表看得懂。這三個階段會留下很多資料，也因為資料多，很容易讓人以為已經了解用戶了。所以這篇除了說明每個階段是什麼，更想談的是：每個階段各自會在哪裡誤導你。

一樣，還是用那個有點極端的例子來思考。

行為（Behavior）

行為，是動機驅動之後，實際發生的事。

行為發生的三個條件

動機存在，不代表行為一定會發生。很多人心裡有恨，但從來沒有動手；很多用戶有需求，但也從來沒有打開你的產品。那行為到底要在什麼條件下才會發生？

推理小說裡，偵探鎖定嫌犯通常看三件事：動機、手段、機會。有恨還不夠，還要有辦法下手，而且剛好有下手的時機。三件事同時成立，案子才會發生。

史丹佛的 BJ Fogg 在 2009 年提出的行為模型（Fogg Behavior Model），講的幾乎是同一件事：B = MAP。行為（Behavior）的發生，需要動機（Motivation）、能力（Ability）與提示（Prompt）同時出現。動機夠強，做起來又夠容易，再加上一個剛好出現的提示，行為就會發生。少了任何一個，行為都不會發生。

把旅遊 App 放進來看：

動機：連假快到了，想出國走走。
能力：App 訂房只要三個步驟，不用另外註冊。
提示：收到一則「你收藏的飯店降價了」的推播。

這也回應了第三篇的結論：需求與內在動機我們碰不到，外在動機是我們唯一可控的因素。現在可以再補上兩個：能力與提示，也都掌握在設計師手上。降低操作門檻、在對的時間給出提示，往往比拚命強化動機更有效。Fogg 最早其實把提示叫做「觸發」（Trigger），跟第三篇提到的《鉤癮效應》第一步是同一個詞，說的也是同一件事。

行為是一連串的操作

在犯罪調查裡，分析的不只是「他為什麼這麼做」，還有「他是怎麼做的」：作案手法、時間、地點、目標的選擇。這些細節拼起來，就是可以被觀察的行為模式。

產品也一樣。用戶的行為不只是「用或不用」，而是一連串可以被記錄的操作：點了什麼、跳過什麼、在哪裡停留、在哪裡放棄。行為是所有後續分析的起點。沒有行為，就沒有數據，也無法往回推敲動機與需求。

用戶說的，和用戶做的不一樣

辦案的時候，嫌犯的供詞和現場的證據對不上，一定是以證據為準。用戶研究也一樣。

Jakob Nielsen 在 2001 年寫過一篇文章，標題就叫〈可用性的第一條規則：不要聽用戶說〉（First Rule of Usability? Don’t Listen to Users）。意思不是用戶的話不重要，而是要看他們實際怎麼做，不能只聽他們怎麼說。用戶會說「我都會看評論再決定訂哪一間」，但行為資料可能顯示，他看完照片和價格就下訂了，評論區只停留了幾秒。

這不代表用戶在說謊。人本來就不太清楚自己是怎麼做決定的，事後的說法，常常是替自己的行為找一個合理的解釋。

行為資料只告訴你發生了什麼

反過來說，行為資料也有它的限制：它只告訴你發生了什麼，不告訴你為什麼。

第三篇討論過，同樣是殺人，可能是為了報酬，也可能是為了報仇，光看行為分不出來。產品也是。數據顯示很多用戶在付款頁離開，可能是價格太高，可能只是想先去別的平台比價，也可能單純被一通電話打斷。三種原因，要改的地方完全不同。

所以行為是最客觀的階段，卻也最容易被過度解讀。看到用戶在哪裡離開，不等於知道他為什麼離開。

結果（Outcome）

行為結束之後，一定會產生結果。結果有兩個面向：客觀發生的結果，以及用戶主觀感受到的結果。

結果要對照預期才有意義

回到殺人的例子。殺人行為的客觀結果很明確：死亡。但對加害者來說，這個結果符不符合預期？如果目的是復仇，死亡正是他要的；如果目的是恐嚇，死亡反而是失控的意外。同樣的結果，對行為者的意義可能完全相反。

行銷學者 Richard Oliver 在 1980 年提出的期望落差理論（Expectation-Disconfirmation Theory），講的就是這件事：滿不滿意，取決於實際結果和原本預期之間的落差。結果超過預期就滿意，低於預期就失望。結果本身沒有好壞，要放在預期旁邊比較，才看得出意義。

這在 UX 上很重要。用戶在旅遊 App 上訂到了房間，對系統來說任務成功了。但入住時發現房間和照片差很多，對用戶來說，這次是失敗的。易用性測試常常只看任務完成率，可是任務完成了，不代表用戶的需求被滿足了。

預期是從哪裡來的

那預期又是從哪裡來？一部分來自用戶自己，也就是前面討論的需求與動機。為了帶家人出遊而訂房，和一個人出差訂房，對同一間飯店的預期就不會一樣。所以結果這個階段，其實是把前面看不到的需求與動機，重新連回來的地方。

另一部分的預期，是產品自己給的。廣告、商品頁、評分，都在替用戶設定預期。第三篇提到那句「借錢是高尚的行為」，就是把預期拉高到尊嚴的層次。預期拉得越高，實際結果的落差就可能越大。行銷做得太好，有時反而是在替產品製造失望。

意料之外的結果

結果還有一種常被忽略的情況：意料之外的結果。

殺人的人想的是讓對方消失，卻沒想到會留下證據、會被追查、會改變自己往後的人生。這些結果不在他的計畫裡，卻一樣會發生。

產品也是。推播通知提高了開啟率，這是預期中的結果；但同時也有用戶因為太吵，關掉通知，甚至直接移除 App，這是沒被算進去的結果。如果只量測自己想要的那個指標，就只會看到自己想看的結果。

態度（Attitude）

態度，是用戶對結果的主觀評價，也是整條鏈中唯一可以直接問得到的部分。

態度是追查動機的線索

回到殺人的例子。案子發生後，加害者的態度可能是滿足、後悔、麻木，或是準備繼續。在犯罪心理學中，案後態度常常是追查動機的線索：如果加害者毫無悔意，這個行為很可能來自深層的內在需求，而不是一時的外在衝動。

用在產品上，也可以這樣讀。同樣是流失的用戶，有人是生氣地離開，有人是無所謂地離開。生氣，代表他有需求，而且期待過，只是沒被滿足；無所謂，可能代表需求本來就不強，這個產品對他來說可有可無。兩種流失看起來一樣，要解決的問題卻完全不同。

態度不一定會變成行為

態度最常被拿來預測行為，但態度和行為之間，常常對不上。

1930 年代，美國社會學家 Richard LaPiere 和一對中國夫婦一起在美國旅行，當時社會對亞洲人的偏見很重。他們一路造訪了 251 間旅館與餐廳，只被拒絕了一次。旅程結束半年後，LaPiere 寄問卷給這些店家，問「你們願不願意接待中國客人？」。回覆的 128 間店家裡，92% 說不願意。

說不願意的人，當面卻接待了他們。態度和行為，可以差這麼多。

產品上也很常見。滿意度調查的分數很高，用戶卻一個一個流失；用戶說「很喜歡這個功能」，實際上幾乎沒有人在用。態度只是一個訊號，不能直接當成行為的預測。

態度是最容易拿到、也最空的答案

第一篇提過，問用戶「為什麼使用這個 App？」，最常拿到的答案是「因為好用」。「好用」就是態度。它很容易拿到，因為用戶不用想就能回答；它也很空，因為它沒有告訴你任何具體的事。

態度也很容易被問法影響。問「你喜歡這個功能嗎？」和問「你還會繼續用嗎？」，得到的訊號可能完全不同。前者問的是感覺，後者比較接近行為。

所以拿到態度之後，最重要的不是記下來，而是往回問：是哪一次的結果讓你覺得好用？那一次你做了什麼？

從態度往回推：一個例子

第一篇說過，分析用戶行為可以從任何一個階段切入，再往前後推。看得到的三個階段，最適合當入口。下面用一個假設的例子，完整走一遍。

一位用戶在旅遊 App 上留下三顆星的評論：「還可以，但訂房有點麻煩。」

態度：三顆星，「有點麻煩」。不算差，但有不滿。
結果：後台紀錄顯示，他最後有訂到房，但從搜尋到下訂花了四十分鐘，比平均多很多。
行為：操作紀錄顯示，他在幾間飯店的房型頁之間來回切換，反覆點開設施說明，還離開 App 一段時間才回來。
動機：訪談時問他那次訂房的經過，他說是帶爸媽出遊，要確認飯店有沒有無障礙設施和電梯，但這些資訊散在各處，最後只好打電話去問。
需求：照顧家人，讓他們安全、舒服地出門。

如果只看評論，團隊可能會決定「簡化訂房流程」。但往回推到最後會發現，流程的步驟並不是問題。問題是這位用戶在意的資訊找不到。要改的，是讓無障礙設施這類資訊更容易被找到，甚至可以被篩選。

這就是看得到的三個階段真正的用處：它們不是答案，而是線索。

結論

到這裡，用戶行為模式的五個階段都走過一遍了：

需求 → 動機 → 行為 → 結果 → 態度

前兩個階段看不到，只能推敲；後三個階段看得到，卻各自會誤導人。行為告訴你發生了什麼，但不告訴你為什麼；結果要對照預期才有意義；態度最容易拿到，卻不一定會變成行為。

而且這條鏈不是單向的。態度會影響下一次的動機，結果會修正用戶對需求的認知，外在動機也可能慢慢內化成需求。用戶行為是一個持續循環的系統，不是一條直線。

所以用戶研究不管從哪裡切入，都只是在觀察這條鏈上的某一段。易用性測試看的是行為與結果，訪談挖的是動機與需求，滿意度調查收集的是態度。知道自己手上拿的是哪一段，也知道還缺哪一段，才不會把片面的資料當成全貌。

下一篇，我們來談怎麼用這個模式選擇研究方法，以及在 AI 進到工作流程之後，這個模式還能幫我們什麼。

參考資料

Fogg, B. J. (2009). A behavior model for persuasive design. Proceedings of the 4th International Conference on Persuasive Technology (Persuasive ’09), Article 40. ACM.
Nielsen, J. (2001, August 4). First Rule of Usability? Don’t Listen to Users. Nielsen Norman Group.
Oliver, R. L. (1980). A Cognitive Model of the Antecedents and Consequences of Satisfaction Decisions. Journal of Marketing Research, 17(4), 460–469.
LaPiere, R. T. (1934). Attitudes vs. Actions. Social Forces, 13(2), 230–237.
Eyal, N., & Hoover, R. (2014). Hooked: How to Build Habit-Forming Products. Portfolio.（中譯本《鉤癮效應》）

電報式溝通：與 AI 協作的高效溝通技巧

Thu, 18 Jun 2026 08:18:11 GMT

隨著 AI 成為開發工作中的基礎設施，高頻協作有時候總會覺得：AI 實在太囉嗦了。

這就像身邊有一位能力極強、卻極度囉嗦的資深同事。你只是請他幫忙重構一段前端的 Slice，他卻總要先客套三句，再從底層架構一路嘮叨到設計模式，最後才把程式碼交出來。

好的產品體驗應該是「隱形」的，在背景高效運作，絕不喧賓奪主。為了在 claude.md 或 agent.md 中徹底解決這個問題，我摸索出一個非常實用的小技巧：直接在 System Prompt 中與 AI 建立「電報式溝通」（Telegraphic Communication）的協議。

什麼是電報式溝通？

在早期的電報時代，受限於字數計費，發報者會剔除所有虛詞與修飾語，只保留最核心的動詞與名詞。

將這個概念套用到人機協作中，就是強迫 AI 遵循一種極度壓縮、結論先行的溝通風格。這不僅符合職場上高效的回報原則，也直接對應到實際使用體驗。每一次對話的回應都會成為下一次生成的 Context，減少無效輸出能讓有限的 Context Window 保持乾淨，供更關鍵的邏輯使用。

設定範例

你可以直接將以下規則寫入專案的 claude.md 中，為 AI 建立明確的行為邊界：

			
## 溝通協議 (Communication Protocol)
強制採用「電報式溝通」（Telegraphic Communication），追求最高資訊密度，消除所有非必要的輸出。
### 1. 核心原則
- **禁止客套**：略過所有確認性或社交性回覆（例如：「好的」、「我了解」、「以下是修改後的程式碼」）。
- **結論先行**：直接輸出最終的程式碼、Patch 或解決方案。
- **零主動解釋**：除非明確要求，否則不解釋程式碼原理或實作細節。若有必要，僅保留極簡的 Inline Comment。
### 2. 輸出格式限制
- **程式碼提供**：僅輸出發生變動的程式碼區塊。
- **問題釐清**：若需向使用者確認需求，使用條列式（Bullet points），每點不超過 20 字。
- **技術術語**：預設使用者具備充足的 Domain Knowledge，直接使用架構或工程術語，不進行名詞解釋。
### 3. Response 範例
- [Reject]：「好的！我幫您優化了這個元件，加入了防抖機制，詳細程式碼如下..."
- [Accept]：「已加入 Debounce。程式碼：\n```tsx...```」

		

實務上的三個效益

導入這套溝通協議後，在日常開發中會有幾個顯著的改變：

降低工作記憶的消耗
當你的大腦正在處理複雜的領域驅動設計（DDD）邊界劃分，或是梳理繁雜的資訊架構（IA）時，認知資源非常寶貴。電報式溝通讓你不需要再消耗精力去「略過」AI 的廢話，視線能直接落在需要 Review 的程式碼上。
提升 Context Window 的有效利用率
每一次對話的回應都會成為下一次生成的 Context。當 AI 停止輸出無效的對話填充文字，Context Window 能保留更多空間給實際的程式邏輯與需求描述，有助於維持長對話後期的一致性。
讓 Agentic Coding 保持流暢
Agentic Coding 指的是一種以任務導向、讓 AI 自主執行多步驟操作的開發模式。在這種模式下，AI 會連續呼叫工具、讀寫檔案、執行指令，任何不必要的冗言都會在每一步累積干擾。把 AI 設定成指令導向的執行模式，能讓整個 Agentic 流程更加精準連貫。

結語

定義 claude.md 的本質，就是確立你與 AI 之間的協作協議（Protocol）。

在大家都能取用 AI 的時代，真正拉開差距的是協作品質的精準度。為 AI 設定明確的溝通規則，是一個看似微小、卻能大幅提升日常開發效率的基礎設定。

黃山料

Sun, 07 Jun 2026 04:46:45 GMT

看多米噴黃山料雖然爽，
但事實是很多人連造句都不會。

村上春樹是深井，黃山料是池塘，
一般人大概只是個水灘。

我呢？我是自家浴室的洗臉盆

當大師風格撞上公共美學 — 從台電 Logo 事件，看台灣設計的結構困境

Thu, 14 May 2026 02:30:00 GMT

近日，Taiwan Power Company（台電）耗資約 96 萬台幣進行企業識別（CI）優化案，因由聶永真操刀，並將原有帶有于右任書法風格的字樣調整為現代黑體，引發了社會對於「歷史傳承」與「功能美學」的激烈討論。

上為新的台電logo，下為舊的logo

然而，這場爭議真正值得討論的，或許並不只是「新 Logo 是否好看」，而是另一個更深層的問題：當公共美學逐漸依賴少數明星設計師的個人語彙時，品牌本身的靈魂，是否也會逐漸被設計師風格所覆蓋？

對許多人而言，台電、中油、郵局或台鐵的標誌，早已不是單純的企業識別。它們存在於街道、招牌、帳單與城市景觀之中，承載的是長年累積的公共記憶。民眾對於于右任字體的情感，也未必只是對書法風格的偏好，而更像是一種生活經驗的視覺錨點。當這些元素被大幅調整時，引發反彈，其實並不令人意外。

不可否認，聶永真的作品對台灣近十年的視覺美學轉型具有相當深遠的影響。他擅長以極簡、中性、克制且高秩序感的排版，建立一種屬於當代台灣的「現代感」。然而，當越來越多公共機構的視覺更新，都逐漸呈現相似的語氣時，大眾產生的未必只是審美疲勞，而是對公共美學逐漸趨同的不安。

永真急製政府 CI 作品

公共美學，正逐漸失去差異

台灣公共標案有一種長期慣性：在預算有限、輿論壓力大的環境下，公部門傾向選擇知名度高的設計師來降低決策風險。對主事者而言，找一位口碑與作品都有保證的設計師，是最不容易被質疑的選擇。

但當所有問題都用同一套解法回應，公共視覺也會逐漸失去多樣性。不同性格、不同歷史脈絡的機構，最後在街頭上呈現出相似的氣質，對民眾而言，公共空間的辨識度被稀釋；對設計本身而言，原本應該是創意與適配的對話，也被簡化成一場名師背書的結果。

因為公共品牌真正需要的，很多時候並不是「更漂亮的設計」，而是「更適合自身定位的視覺系統」。台電需要傳達的，也許不只是現代化，而是能源、穩定、工業性與基礎建設的力量。這些特質，未必只能透過冷靜的黑體系統來呈現。

其他亞洲國家電力公司 logo

另一種可能：從 Pentagram 談起

Pentagram （五角設計）是 1972 年成立於倫敦的國際設計事務所，業務橫跨品牌識別、出版、空間與數位設計，是全球設計界最具代表性的工作室之一。它的作品光譜極為廣闊，從 Mastercard 識別的極簡化、Slack 的整體品牌更新，到紐約 The Public Theater 充滿城市張力的字體海報；每一件作品的氣質都截然不同，卻又同樣具有強烈的設計識別。

這樣的多元性，源自它特殊的工作結構：它聚集了大量具有強烈個人風格的設計師，但透過多合夥人並存的機制，避免單一美學成為唯一標準。

如果我們將台電的案子交給 Pentagram，內部可能會出現幾種截然不同的解法：

追求能量與爆發力的 Paula Scher 模式：

Scher 擅長大膽的字體排版（如紐約公共劇院 Public Theater）。她可能會保留電力的「動能感」，甚至利用大膽的色彩與變形字體，讓台電看起來充滿現代城市的活力，而非僅是冷靜的黑體。

Public Theater

訴諸邏輯與敘事的 Michael Bierut 模式：

Bierut 的設計核心是「解決問題」（如紐約高線公園 High Line）。他可能會深入研究台電的變電箱施工流程，利用如 MIT Media Lab 的系統性思維，設計一套既能適應數位應用，又能讓工程人員輕鬆施作、且具備高度理性的識別系統。

The High Line

MIT Media Lab

強調感官與流動的 Marina Willer 模式：

Willer 的風格充滿詩意（如倫敦交響樂團 LSO）。她或許會將電力的「頻率」與「流動」視覺化，讓國營事業的標誌不再只是硬梆梆的工業圖形，而是一種與市民生活共鳴的情感符號

倫敦交響樂團 LSO

台灣其實從來不缺優秀設計師。真正缺乏的，或許是足夠成熟的設計分工、多元美學並存的環境，以及能理解「適配性」的決策機制。當公共設計只能反覆依賴少數明星設計師時，問題未必是設計師太強，而是整個體系尚未建立足夠成熟的美學信任機制。

美，從來不是固定答案

或許，我們也該重新思考一件事：到底什麼是「美」？

這幾年，「華國美學」經常被當成一種負面標籤被嘲諷。但如果從設計的角度來看，任何時代的美學，其實都深受當下社會背景、技術條件與文化氛圍所影響。

那些如今看來俗氣、混亂、甚至過時的視覺風格，在當時，也可能代表著一種對「現代化」的想像與追求。

美感從來不是脫離時代而存在的絕對標準。

它更像是一種不斷探索、修正與發掘的過程。

真正值得警惕的，也許不是「不夠美」，而是當我們開始過度定義「什麼才是美」時，美本身反而會被限制在單一框架之中。

設計不應只是建立標準答案，而更應該保留對不同時代、不同語境與不同審美可能性的理解能力。

設計師的任務，也不應只是覆蓋舊有風格，而是理解品牌背後的歷史、功能與公共性，並提供最合適的解答。

我們當然需要像聶永真這樣的重要開拓者，但台灣的公共空間，也同樣需要更多不同的美學語言。當公共設計不再只有一種表情，台灣的設計，才能真正成為一段演化，而不只是一輪輪的覆蓋。

當內在世界變得安靜：心盲症（Aphantasia）現象、數位危機與認知重構

Wed, 06 May 2026 15:06:13 GMT

你閉上眼睛時，能看見什麼？是能清晰地看見早晨咖啡冒出的熱氣，還是只能看見一片虛無的漆黑？

最近我驚覺自己似乎正慢慢失去「想像畫面」的能力。過去那些自然浮現的場景，現在變得模糊甚至只剩空白。在深入研讀相關文獻後，我發現這不僅是個人感受，而是一個被稱為「心盲症」（Aphantasia）的心理學現象。在數位資訊氾濫的當代，這更可能是一場集體的認知重構。

一、什麼是「心盲症」？

心盲症（Aphantasia）是指一個人無法在腦中形成自發性的視覺心像（Visual Mental Imagery）。這個術語由英國艾克塞特大學的神經科學教授亞當·澤曼（Adam Zeman）於 2015 年正式命名。

其字根源自古希臘語「phantasia」（心靈產生圖像的能力），加上否定前綴「a-」，象徵該能力的缺失。在神經心理學中，心盲症被視為一種「神經多樣性」，而非障礙。心盲者的內在世界並非缺乏資訊，而是缺乏「視覺化渲染」— 他們回憶紅蘋果時，提取的是語義數據（顏色是紅的、形狀是圓的），而非一幅具體的圖像。

歷史脈絡：從「早餐桌」到現代科學

1880 年：法蘭西斯·高爾頓（Francis Galton）設計了「早餐桌問卷」，發現部分受試者完全無法理解何謂「腦中影像」。
1883 年：讓-馬丹·沙可（Jean-Martin Charcot）紀錄了因腦傷而失去想像力的「獲得性心盲」案例。
2015 年：澤曼教授透過 fMRI 研究代號為「MX」的患者，正式重啟了全球對此現象的關注。

二、你也是「心盲者」嗎？自我檢測與流行病學

目前學術界最權威的測量工具是 VVIQ（視覺心像生動性問卷）。

VVIQ 簡單測試

試著閉上眼，想像以下場景並給予 1-5 分（1 分為無影像，5 分為如實景）：

熟人的臉孔：輪廓、細節與衣著。
日出的景象：天空色彩的變化、太陽升起。
常去的商店：店面全景、陳列細節。

研究數據顯示：全球約有 0.9%–1.2% 的人為全心盲，約 3%–4% 處於低心像狀態。有趣的是，心盲者在 STEM（科學、技術、工程、數學）領域的佔比顯著較高，這可能與其卓越的邏輯運算能力有關。

三、神經科學的解密：大腦如何在黑暗中運作？

研究發現，心盲症的核心在於「額頂注意力控制網路」與「枕葉視覺網路」之間的連接性減弱。

格式化赤字（Formatting Deficit）：心盲者的大腦其實完成了視覺運算，但最後一步將數據轉化為「像素圖像」的過程失敗了。
客觀生理指標：典型心像者想像太陽時，瞳孔會收縮；但心盲者即使在想像任務中，瞳孔大小也保持不變，這證明了視覺系統未收到想像層面的光感輸入。

四、數位時代的危機：被動資訊消費與想像力退化

這是我最深刻的反思：現代人的內在世界是否正在變得安靜？

1. 短影音的神經衝擊

現代社交媒體（TikTok、Reels）提供的碎片化內容，被證實會導致大腦「屏狀體」（Claustrum）的激活降低。屏狀體負責將感官資訊整合成統一的內在圖像，當我們習慣被動接收預先渲染好的視覺細節，主動生成的「內在肌肉」就會萎縮。

2.「用進廢退」的想像力

過去閱讀小說時，大腦必須主動「線上渲染」文字。舒加特（Sebastian Suggate）博士的研究指出，觀看影片會對想像力產生即時且顯著的「鈍化效應」。當外部世界愈喧鬧，我們留給大腦發呆、構建故事的「空白空間」就愈少。

五、重啟心靈之眼：改善與代償方法

雖然心盲具有生理基礎，但神經塑造性告訴我們，透過練習可以強化視覺化能力。

影像流練習（Image Streaming）：閉上眼，捕捉任何微小的光影色塊，並嘗試「大聲描述」其質地、溫度與亮度。這能強迫左腦語義與右腦視覺建立連結。
數位減毒與深度閱讀：減少短影音攝取，恢復小說閱讀。小說是訓練想像力最自然的教具。
視覺化冥想：每天給自己 10 分鐘，嘗試在腦中「繪製」簡單幾何圖形並讓其旋轉。
空間代償：若無法「看見」畫面，可以練習「感覺」空間。閉眼在腦中定位房間家具的位置，強化額頂網路的建模能力。

結語：另一種看世界的方式

心盲症並非缺陷，而是一種神經多樣性的體現。它提醒我們，在這個被螢幕填滿的時代，內在世界的豐富性並非理所當然。

或許我們不需要每個人都是「畫家」，但我們都應該守護那份在腦海中模擬「另一種現實」的能力。學會閉上眼睛去感受與思考，是保護心靈深度最重要的功課。

參考文獻與資料來源

Zeman, A., Dewar, M., & Della Sala, S. (2015). Lives without imagery – Off the grid: Surveying aphantasia. Cortex, 73, 378–380.（正式命名與現代研究起點）
Galton, F. (1880). Statistics of Mental Imagery. Mind, 5(19), 301–318.（早餐桌問卷原始研究）
Marks, D. F. (1973). Visual imagery vividness and recall of pictures. British Journal of Psychology, 64(1), 17–25.（VVIQ 量表來源）
Pearson, J. (2019). The human imagination: the cognitive neuroscience of visual mental imagery. Nature Reviews Neuroscience, 20(10), 624–634.（生理指標與瞳孔反應研究）
Suggate, S., & Martzog, P. (2020). Screen media exposure and imagination in children. Developmental Science.（數位媒體對想像力鈍化效應研究）
Wenger, W. (1996). The Einstein Factor: A Proven New Method for Increasing Your Intelligence.（Image Streaming 影像流技術來源）
Dawes, A. J., et al. (2020). A cognitive profile of multi-sensory imagery, memory and dreaming in aphantasia. Scientific Reports.（盛行率與 SDAM 關聯性研究）

當 AI 給出完美解答，設計的價值在哪裡？— 從「解決問題的方法」走向「意義建構的過程」

Fri, 24 Apr 2026 05:45:17 GMT

長久以來，產業界奉行著一句至理名言：「設計，是解決問題的方法。」

在過去的時空背景下，這句話是支撐我們專業的基石。我們透過邏輯推敲、資訊架構重組與視覺實驗，試圖為專案找出最優解。然而，隨著生成式 AI 的技術爆發，這句曾經的真理，如今卻成了許多從業人員焦慮的源頭。

如果設計的本質僅僅是一種「解決問題的方法」，那麼我們必須誠實地面對：在給定參數與目標的前提下，AI 給出解答的速度、精準度與成本，人類根本無法企及。當我們執著於將設計視為產出最佳解的「方法」時，無疑是在用人類的肉身，去衝撞演算法的強項。

在 AI 時代，我們必須把目光從終點移開，重新定義設計。設計不該再只是工具性的「方法」，而是一段無可取代的「過程」。

「方法」的陷阱：當我們只看見終點

把設計當作「方法」，意味著我們將設計「工具化」了。既然是工具，評估標準就只剩下效率與結果。

在這種思維下，最好的設計就是最快消除痛點的那一個。但在真實的專案實務中，無論是規劃一個商業網站還是梳理複雜的系統邏輯，問題往往不是一開始就清晰可見的。客戶口中的「需求」，通常只是一團模糊的渴望；而開發者眼中的「規格」，也需要不斷地對齊才能成型。

AI 可以瞬間生成漂亮的頁面或無懈可擊的程式碼框架，因為它掌握了最頂尖的「方法」。但它無法經歷那段在混沌中摸索、釐清問題本質的旅程。

設計的核心價值：作為「意義建構」的過程

當我們把設計視為一種「過程（Process）」時，價值的衡量標準就徹底改變了。

這個過程，是將抽象的業務邏輯轉化為具體體驗的歷程；是在來回的討論、妥協與堅持中，建立起共同語言（Ubiquitous Language）的歷程；這一切，最終匯聚成了一種意義建構（Sense-making）的過程。

在這個過程中，我們不僅僅是在「做設計」，我們是在梳理脈絡、建立信任、形塑產品的靈魂。這也是為什麼當我們在追求極致流暢的「無形服務」或實踐氛圍編程（Vibe Coding）時，那種渾然天成的體驗，往往來自於開發者在過程中不斷微調、與產品精神高度共鳴的結果。

這些存在於過程中的「雜訊」，我們的遲疑、直覺、與利害關係人的拉扯，正是讓產品擁有溫度與深度的關鍵。

放下競賽焦慮：AI 是方法的載體，人是過程的領航者

當我們將視角從「設計 = 解決問題的方法」轉向「設計 = 意義建構的過程」時，與 AI 競賽的焦慮感便會隨之消散。

因為我們不再需要害怕被超越。AI 提供的解答再完美，也無法取代「經歷這個過程」本身。在未來的環境中，AI 不會是搶走我們價值的對手，而是幫助我們處理繁瑣「方法」的最佳助理。

它幫我們解決了技術上的勞動，好讓我們有更多餘裕，去專注於高價值的「過程」，去傾聽、去共感、去挖掘真正的領域核心，然後引導專案走向正確的方向。

如果設計只是一種解決問題的方法，那人類的終點或許就是 AI。但如果設計是一趟關於探索、對齊與建構意義的過程，那麼 AI 只是讓我們走得更深、更遠的裝備。

放下對「標準答案」的執念吧。在 AI 時代，最迷人且無法被取代的價值，一直都在過程裡。

你是誰？

Thu, 16 Apr 2026 14:30:30 GMT

如果沒有人告訴你是誰，你還會知道你是誰嗎？

說穿了你是誰，實際上只是一連串的記憶

記憶不是你，也無法定義你的本質

用經營一間餐廳，了解軟體開發的本質

Thu, 16 Apr 2026 11:37:33 GMT

在與 AI 合作開發產品的這段時間，我了解到一件事：要向一般人解釋軟體產品的開發邏輯，其實不需要艱澀的技術術語。一間餐廳的運作，早已示範了軟體開發中所有的關鍵議題。

一般來說，經營小餐廳，可以將餐廳分為「外場」與「廚房」。外場負責服務客人，廚房負責料理。兩者邏輯不同、分工明確，但最終的目標一致 — 讓客人帶著滿意的體驗離開。這正是軟體產品中「前端」與「後端」的縮影。

在開火之前，先決定體驗

在廚房開火、服務生就位之前，有一個核心問題必須先被回答：這間餐廳要為誰提供什麼樣的體驗？

是極致精緻的法式料理，還是輕鬆高效的早午餐店？這個決定將影響一切細節：桌椅的材質、燈光的色溫、菜單的視覺設計，甚至服務生說話的語氣。

這就是設計（Design）的工作。設計不只是「讓畫面好看」，而是在動手開發前，定義出一套一致的風格語言。如果細節彼此衝突，客人進門就會感到莫名的不協調。在軟體世界中，這套規則被稱為設計系統（Design System），它是整個產品外在表現的靈魂與基石。

外場：使用者看得見的一切

風格確立後，外場開始運作。桌椅依序擺放，菜單遞到客人面前。這是顧客在用餐過程中唯一能直接接觸的部分。

這就是前端（Frontend）的本質。使用者在螢幕上看到的介面、點擊的按鈕、填寫的表單，都是「外場」。它們的首要職責是溝通與引導 — 讓人看得懂、用得順。至於牛肉要怎麼煎、菜盤要怎麼擺，那是廚房的事，外場不應涉入過深。

好的外場有著清晰的邊界：桌椅負責承載、菜單負責承諾、服務生則負責傳遞需求。在前端開發中，這叫「元件化」與「職責分離」，確保畫面呈現與資料傳遞互不干擾。

出餐口：溝通的唯一橋樑

廚房與外場之間，有一個關鍵的「出餐口」。訂單從這裡傳進去，料理從這裡送出來。

在軟體中，這個窗口叫 API。不論外場裝潢如何翻新，只要出餐口的規則不變，廚房就不受影響。這個清晰的接口，確保了前後端可以獨立演進，而不會牽一髮而動全身。

廚房：從原始食材到秩序井然的料理

廚房決定了一間餐廳的真材實料。食材品質、烹飪工法、出菜順序，這些客人在外頭看不見的邏輯，才是產品的核心。

對於一間小店，一個廚師包辦所有事通常沒問題。但當規模變大、菜色變複雜，混亂便隨之而來：廚師動線重疊、改一道菜的做法卻弄亂了另一道菜的備料。這時你必須將廚房重新組織，從「大雜燴」轉向「專業分區」。

這種專業分區的概念，對應的就是軟體工程中的 DDD（領域驅動設計）。

將複雜的後端切割成不同的專業區域（如冷盤區、熱炒區、甜點區），每個區域擁有獨立的工具與職責。要協作時，必須走規定的管道，而非隨意介入。這讓系統在成長過程中，依然保持可被理解、可被修改的秩序。

交班：從「人」轉向「系統」的治理

然而，即便分工再完美，餐廳仍會面臨管理上的考驗：交班、人會離開。

主廚請假了、資深服務生離職了，如果所有的食譜、客人偏好、作業細節都只活在員工的腦子裡，那這間餐廳的品質就是脆弱的。

讓餐廳長久經營的關鍵，不是尋找天才廚師，而是建立一套「就算換了人，品質也不會跑掉」的機制。建立食譜、訂單管理、外送派單、關鍵環節要自動化監控。

這就是 Harness Engineering（駕馭工程） 在解決的問題。它不是寫在紙上、隨時會被遺忘的 SOP，而是直接運作在系統裡的規則與機制。它讓產品的品質不依賴「誰在當班」，而是依賴「系統本身的設計」。

結語：好的產品，像是一場無感的服務

回頭看，軟體開發的不同階段，其實就是在回答一間餐廳面臨的各種挑戰：

設計：定調風格與體驗。
前端與架構：梳理內外分工與溝通路徑。
DDD：在規模擴大時維持內部秩序。
Harness Engineering：確保跨班次的穩定與品質持續。

一間頂尖的餐廳，客人感受不到後廚的忙亂，也察覺不到人員的更迭。他只知道，每次來訪，體驗都始終如一。

會寫下這篇文章，是因為在 AI 輔助開發的時代，許多非工程背景的朋友也開始嘗試 Vibe Coding，每個人都能輕鬆地在自家廚房「煮出一道菜」。但如果要將這道菜變成一間能長久經營、持續擴張的「餐廳」，就必須跨入軟體工程的理解範疇。

這篇文章並非要教你如何寫程式，而是希望提供一個入門的邏輯框架。當你理解了餐廳運作的道理，你就掌握了軟體產品開發的核心邏輯。希望這些類比能成為你的地圖，帶領你在與 AI 協作的產品之路上，走得更穩、更遠。

今天的我，沒有極限

Wed, 15 Apr 2026 15:09:10 GMT

目前的 AI 發展情況，
就像是每個人都突然拿到了汽車駕照。
公路上變得很擁塞，有路怒症的人也變多了。

被淘汰的是低性能的車，
留下來的是性能更強的車，以及難以取代的「特規車」。
現在公路上比的不是駕駛技術，
而是車子好不好、夠不夠聰明。

要思考的是，這條路可能不是你的賽道。
想像自己是拉力賽、或是頂級 F1 方程式的賽車手。
要挑戰的不是一般的駕駛，而是自己的極限。

AI 鬼打牆

Fri, 10 Apr 2026 03:33:05 GMT

「你現在在做什麼？」

「你為什麼要這麼做？」

「重述一次我們的問題。」

「告訴我接下來你會怎麼做？」

『你懂我的意思嗎？』

送給大家，當 AI 鬼打牆正確的溝通方式
對人類講也行，只是會讓人覺得很靠盃

不用下拉選單也能多維篩選：DCL 方向約束鎖定演算法

Sun, 29 Mar 2026 09:35:08 GMT

前幾個晚上，我在滑一個很有趣的網站。

那是一個無限畫布的圖片 Gallery，你可以往任意方向拖曳，八個方向都可以走，沒有盡頭。那種感覺有點像在一個沒有邊界的房間裡漫遊，你不知道下一個轉角會出現什麼，但你知道你可以一直走下去。

我一邊玩，一邊開始想：如果這個空間不只是裝飾性的呢？如果往哪個方向走，不只是「到達那裡」，而是「靠近某種東西」呢？

就這樣，我想到多年前的專案，同時也開始推演這一個概念。

從穿搭照片開始想

最初的場景是這樣的：一面牆，放滿了穿搭照片。你站在中間，可以往八個方向走。

普通的做法是：左邊放「休閒風」，右邊放「正式風」，上面放「深色系」，下面放「淺色系」。這是一個固定的二維座標系，每張照片釘在地圖上的某個位置。

但這樣的問題是，風格是多維的。一件衣服可以是「寬鬆的正裝」，也可以是「緊身的街頭風」。你沒辦法把它平攤在一個二維平面上而不失去什麼。

所以我換了一個思路：不要把照片釘在地圖上，而是讓照片本身決定鄰居是誰。

每張照片在八個方向上各有一個數值。你往右走，找的是「右方向數值相同」的照片。你再往上走，找的是「右方向 AND 上方向都相同」的照片。條件越多，交集越小，你越接近某個特定的風格群。

一個很關鍵的差異

當我開始推演這個邏輯的時候，我在思考：如果用方向來鎖定篩選的值呢？

你往右走，同時鎖定當前照片的右方向值，然後找所有右方向也是這個值的照片。

這裡有個微妙但重要的地方：鎖定的值不是你決定的，而是你走到的那張照片決定的。你不是在設定篩選條件，你是在跟著照片走。每一步都是上一張照片給你的提示。

這個機制有個名字，我後來把它叫做：方向約束鎖定（Directional Constraint Locking，DCL）。

DCL 是什麼

用最簡單的語言說：

每個節點在八個方向各有一個唯一數值（預設是 1 到 8 的排列，不重複；值域可擴展）。你第一次往某個方向移動，就鎖定那個方向的值。之後的每一步，都必須符合所有已鎖定的條件。

四個核心規則：

規則一：方向即維度。 八個方向代表八個固定的語意維度。往右永遠是同一個維度，往上永遠是另一個維度。
規則二：移動即鎖定。 第一次往某個方向移動時，當前節點在那個方向的數值被鎖定。這個值來自你踩到的節點，不是你預先指定的。
規則三：條件累積。 已鎖定的條件只增不減。你往右再往上，就同時鎖定了兩個維度。最多可以累積八個條件，覆蓋所有方向。
規則四：FIFO 解鎖。 當累積的條件太多，找不到符合所有條件的節點時，最早鎖定的條件優先釋放。先進先出，永遠不會卡死。

它和現有的演算法有什麼不同

這個問題我研究了一下。

最接近的既有概念是 Faceted Search（分面搜尋），電商網站的多條件篩選，左側欄有品牌、顏色、價格，你勾選，結果就縮小。相似度大約三到四成。

DCL 和 Faceted Search 的本質差異有三個：

第一，Faceted Search 的篩選值是你主動選擇的；DCL 的鎖定值是你走到那裡才知道的。你不需要事先知道你想要什麼，你只需要開始走。

第二，Faceted Search 的條件是靜態的，你可以隨時勾選或取消；DCL 的條件是由移動軌跡決定的，帶有時序關係，FIFO 解鎖也依照這個時序。

第三，Faceted Search 沒有「循環池」的概念，符合條件的節點會形成一個可以無限循環的集合，在同一方向持續移動就在這個池子裡繞，永遠不會走到死路。

另一個接近的框架是 CSP（約束滿足問題），但那是一次性求解演算法，遇到死路採用回溯（撤銷最近的決定），而 DCL 撤銷的是最早的決定，完全不同的邏輯。

研究後的結論是：DCL 的六個核心機制分散存在於不同領域，但這個特定的組合在已知文獻中沒有被命名或形式化過。

數學結構長這樣

如果用符號來寫，核心邏輯是這四步：

			
候選池函數：
P(L, cₜ) = { c ∈ C | c ≠ cₜ ∧ ∀(d, v) ∈ L : A(c, d) = v }
導航函數 nav(d)：
1. 若 d 未鎖定：L ← L ∪ {(d, A(cₜ, d))}，Q.enqueue(d)
2. P ← P(L, cₜ)
3. 若 P = ∅：FIFO 解鎖直到 P ≠ ∅
4. cₜ ← P[ k mod |P| ]，k ← k + 1

		

其中 A(c, d) 是節點 c 在方向 d 的值，L 是目前鎖定的條件集合，Q 是鎖定的先後順序佇列。

這個系統有幾個可以證明的性質：無死路（FIFO 保證）、最大鎖定數為 8、符合條件的節點形成有限循環群。

一個實務上值得注意的地方：在預設的 1–8 排列下，鎖定兩個條件後期望候選池已不足 1 張（數學上約 0.71 張）。實際部署時，資料集至少需要 56 個節點才能讓雙重鎖定有流暢的體驗；如果希望支撐三重鎖定，至少需要 336 個節點。擴大值域（N > 8）可以在不增加資料量的情況下改善這個問題。

可以回頭，也可以模糊匹配

演算法目前已實作兩個擴充：

記憶（undo）：透過插件機制，引擎可以記錄移動歷史，讓使用者退回上一步，鎖定條件保持不變，只換回前一張節點。適合「走錯了想回頭看看」的場景。

			
DCL.use(engine, 'memory');
engine.navigate('right');
engine.undo();      // 退回上一張，條件不變
engine.canUndo();   // true / false

模糊匹配：嚴格等值匹配可以放寬為容差窗口（±ε），讓數值接近但不完全相同的節點也能進入候選池。這在小資料集或連續數值場景下特別有用。

它可以拿來做什麼

最直接的應用是探索型介面，任何需要多維探索、但不想讓使用者面對複雜篩選條件的場景：

穿搭探索：八個方向代表版型、色調、風格、場合等維度。你不是在設定「我要找正式的寬鬆款」，你是在漂流，讓照片帶著你走，直到你覺得「對，就是這個感覺」。

音樂發現：節奏、情緒、樂器、年代。你從一首歌出發，往某個方向走，找到和它在某個維度共鳴的歌。

選品工具：材質、價格帶、風格、品牌調性。不是用篩選條件找商品，而是在商品空間裡漫遊。

更有趣的延伸是：如果八個方向的維度語意不是人工定義的，而是由 AI（例如 CLIP 的視覺 embedding）自動從圖片內容提取呢？你不需要為每張圖打標籤，模型自己決定什麼是「相似」，你只是在這個自動生成的語意空間裡漫遊。

最後

我不是學者，也沒有在學術機構工作。這個演算法其實是我多年前的一個 idea，當時跟工程師討論，但沒人理解我在說什麼，直到有 AI 後，這個演算法被我實現了，或許這篇文章沒什麼人在意，但如果 DCL 是一個有意義的概念，它就值得被記錄下來；如果它已經有人想過了，我也想知道是誰、在哪裡。

附上可以玩的 Demo 和完整的演算法規格書，歡迎試試看這個邏輯在互動上是什麼感覺。

DCL Demo：dcl-demo-alpha.vercel.app GitHub Demo：reidevbx.github.io/dcl GitHub：github.com/reidevbx/dcl 如果你對這個概念有興趣，或知道相關的既有研究，歡迎聯絡。

sense#2

Mon, 16 Mar 2026 03:18:26 GMT

提高 sense 的方式很簡單，但很少人做的到

聽有品味的音樂、讀有深度的文章、欣賞動人的作品

輸入的品質，決定了你感受世界的解析度

探險

Sun, 15 Mar 2026 07:12:47 GMT

探險其實很簡單

為自己設定一個目的地

把手機留在家裡

只帶上你對這個世界，僅剩的那一點認識

設計流程已死？談 AI 時代真正重要的事 – 意圖設計

Fri, 06 Mar 2026 14:38:56 GMT

最近設計圈流傳著一句話：「設計流程已死（Design process is dead）」。

乍聽之下有些誇張，但把 AI 這兩年的發展放進來看，就不難理解為什麼有人這樣說。

流程被壓縮的時代

過去做產品設計，幾乎都圍繞著一套固定的方法論—Research、Define、Ideate、Prototype、Test，或者像 Double Diamond 這樣的設計模型。這些流程在當時是合理的，因為設計與開發的成本高，每一次修改都需要投入大量時間與人力，所以需要一套流程來降低風險。

但 AI 工具出現之後，事情開始改變。

原本需要幾天甚至幾週的探索、原型、或簡單功能，現在幾個小時就能做出來。當 iteration 的成本被大幅壓低，很多原本靠流程保護的環節，也自然跟著被壓縮了。於是有人開始說：「設計流程已死」。

但如果仔細想，死掉的其實不是設計本身，而是流程的重要性正在下降。

AI 時代真正的核心：意圖設計（Intent Design）

在這段時間用 AI 開發產品的過程中，我慢慢有了一個感覺：

AI 時代真正的核心，不是流程，而是意圖（Intent）。

這裡我用「意圖設計」這個詞，是把「設計」作為一種過程。因為設計本身就是一種理解與釐清的行為，而意圖，正是需要被設計出來的東西。

如果意圖沒有說清楚，AI 再強也只是在快速產生錯誤的東西；但只要意圖被描述得夠清楚，AI 就能非常有效率地把事情完成。我目前把 AI 開發中需要描述的意圖，大致分成四個層次。

四個層次的意圖

第一層：Problem Intent（問題意圖）

第一層是「這個產品到底要解決什麼問題」。

很多產品一開始其實沒有想清楚這件事。例如有人說「我要做一個 CRM」，但這其實不是問題，而是解法。真正的問題可能是：客戶資料散落在不同地方、維修紀錄難以追蹤、業務不知道該 follow 哪些客戶。

如果這一層沒有釐清，後面的功能設計很容易整個方向都偏掉。

第二層：Functional Intent（功能意圖）

第二層是「系統需要具備什麼能力」。例如：建立客戶、建立訂單、查詢維修紀錄、追蹤付款狀態。這一層通常會轉化成 feature list 或 user story，也是產品規格最主要的內容。

第三層：Interaction Intent（操作意圖）

第三層是「使用者要怎麼使用這些功能」。透過搜尋找到客戶、用表單建立資料、用按鈕觸發操作、透過聊天介面輸入指令——這一層本質上就是 UX／Interaction Design，決定的是功能如何被觸發，而不是功能本身。

第四層：Execution Intent（執行意圖）

第四層是在 AI 開發裡最直觀，也最容易被討論的—「系統要用什麼技術方式完成這個行為」。資料存在哪個 table、流程是用 API 還是 event、是否需要 queue 或 cache、是否使用 AI agent 或 workflow，這些都屬於這一層的範疇，也已經進入系統設計與技術架構的領域。

四層意圖的關係

把這四層放在一起，結構大致如下：

為什麼要做（Problem Intent）→ 要做什麼（Functional Intent）→ 怎麼使用（Interaction Intent）→ 怎麼實現（Execution Intent）

在傳統開發裡，最後一層通常由工程師自己決定；但在 AI 開發裡，執行的意圖比方式重要，如果 Execution Intent 沒有被描述清楚，AI 很容易產生結構混亂的系統。

所以我越來越覺得，AI 開發真正的門檻不是 coding，而是對系統如何運作的理解。AI 可以幫你寫 code，但「系統應該怎麼被設計」這件事，仍然需要人來定義。

為什麼對 AI 開發來說，意圖設計特別重要

這四層意圖，在傳統開發裡也許只是「好的習慣」，但在 AI 開發裡，它們的重要性被放大了。
原因很簡單：AI 的執行速度非常快，但它沒有辦法自己判斷方向對不對。

當你把一個模糊的需求丟給 AI，它不會停下來問你「這個問題值得解決嗎」或「使用者真的會這樣操作嗎」。它只會根據你給的描述，盡可能快速地產出結果。如果意圖本身是錯的，AI 只是幫你更快地走向錯誤的方向。

最常見的狀況是：開發者把所有注意力放在 Execution Intent 上，跟 AI 討論要用什麼架構、什麼資料庫、什麼 API，卻從來沒有認真想過「我們要解決的問題是什麼」，或者「使用者到底會怎麼用這個東西」。技術層面的意圖說得很清楚，但上面三層是空的。結果系統做出來了，跑得很順，但沒有人想用；功能上線了，但解決的不是真正的問題。

過去受限於開發成本，走錯方向會自然地被流程阻擋下來；但現在 AI 讓執行的門檻變得極低，錯誤的意圖反而可以被更快、更完整地實現出來，所以在用 AI 開發產品之前，這四層意圖都應該被想清楚。

從流程導向到意圖導向

AI 也正在改變軟體開發的重心。過去的開發流程大致是：Requirement → Design → Code。但在 AI 參與之後，流程慢慢變成：Intent → AI → Code。人負責定義意圖，AI 負責把意圖轉換成實際的程式。

回到那句話：「設計流程已死」。也許更準確的說法是：流程沒有消失，而是被壓縮了。AI 讓原型、介面甚至程式碼都可以在很短時間內產生，但這也意味著，如果問題沒有定義清楚，錯誤也會被更快地放大。

因此在 AI 時代，真正變得更重要的，不是流程，而是意圖本身。開發者與設計師最核心的能力，可能不再只是寫程式或畫介面，而是：能否定義問題、拆解功能、設計互動、理解系統如何實現——這些能力的本質，都是為了讓 AI 能夠更準確地理解人的意圖。

換句話說，AI 時代的開發，本質上其實是在做同一件事：

把自己的意圖，一層一層地向 AI 解釋清楚。

除新變舊

Fri, 20 Feb 2026 09:18:35 GMT

新的一年，為自己設立新的目標：

「除新變舊」

想法是觀察到過去的自己，活得太小心翼翼。

買了新衣鞋，怕髒
買了新手機，怕摔
買了新玩具，怕壞

不知不覺，被「變舊」的恐懼支配，
好像不用它、保護它，就會一直是新的。

所以從今年開始

我只拿裸機，不管買了什麼新東西，馬上用、馬上穿，直到用到壞，穿到爛。

這就是我新的一年的開始。

豬頭

Fri, 13 Feb 2026 07:03:12 GMT

常聽人抱怨自己的老闆是豬頭，沒辦法好好駕馭人才。

但在 AI 的世界，我們與 AI 的關係也是雇傭關係。
我們是老闆，AI 是員工，還是一個頂大博士級的全能人才，不但耐操耐勞，還擁有無限創意。

如果這樣都無法讓我有所成就，那豈不就證明了，我也是那個豬頭。