如果想複製某則動態的連結，可以按右下角的🐔。但不開放留言，因為我玻璃心。
小學的時候，我曾經到某位同學家和他一起玩電動，在我們一陣廝殺之後，他路過的表哥決定下場參戰，幫我同學把我這個小學生痛扁了一頓（當然是在遊戲裡）。
當時我很不服，說「你為什麼只幫他？」
他表哥只是理所當然地說：「他是我表弟，我當然幫他啊。」
那是我第一次察覺到某種差異，更準確地說，某種優勢。畢竟，我沒有遊戲機，他有；我沒有能招待同學來玩的房間，他有；最重要的，我沒有表哥，他有。
從這件事之後，我開始注意到：有些人的家裡更有錢、有些人更聰明、有些人打架很強、有些人有很多朋友，每個人或多或少都有相對於別人更具有「優勢」的地方。
在觀察了更多樣本之後，我確定：的確有不同層級、不同方面的優勢存在。
結構性優勢（Privilege）就是其中的一環。
備註：Privilege，常譯為「特權」，但我更偏好「結構性優勢」這個詞，更貼合原意。不過這幾天我的看法有點改變，現在更喜歡「霹靂力距」
結構性優勢是指因為制度、文化等等，具有某些身份、特質或族群的人更容易獲得優勢，並且這種規則帶來的優勢是穩定的、可複製的。
像是一個主張應試教育的班級，考前五名有健達出奇蛋，那麼在這個制度底下，能做到努力備考的學生、能夠補習的學生、家裡鼓勵學習的學生，就會比其他學生更有優勢，付出相對低的成本就能爭取更多的健達出奇蛋。即使今天換一批學生，相似特質或身份的學生仍然會取得同樣的優勢。
大型活動較常舉辦在都市，那麼居住在都市的人，相較鄉村就有著更多大型活動的參與機會；固定上下班又能煮飯的人，比起輪班仔和加班仔更容易維持健康習慣。諸如此類，都是因為某些非個人能決定的因素，導致做同一件事的成本或效率有所差異的例子。
就算把鏡頭移到遊戲裡，某些卡牌遊戲的規則本身就鼓勵特定牌組或特定玩法（對，就是你，爐石）；又或是打 LOL 常說的角色 Meta，其實就是大家發現遊戲規則或是賽季更新讓一些角色更加吃香、更有優勢。
不管往哪個方向看，「因為規則、環境、文化、身份所帶來的某些優勢」到處都是。
只是結構更大、由系統和環境所帶來的優勢會讓人更難以察覺，尤其當我們跟比較對象相隔更遠的時候，就更難了。
很多時候，某些優勢已經成為了一種日常、一種理所當然，很難想像沒有這些條件的人們是怎麼生活的。最窮只窮到每餐吃麵包的人，無法想像歷史上存在人吃人的時期；終日耕作的古代農民，可能會覺得皇帝就是拿金鋤頭耕地的。
畢竟，大多數人類在思考其他人類的處境時，習慣性地會把無關的條件都預設成自己經歷的一樣。但這並不妨礙我們思考：如果不是呢？如果我們並不一樣呢？如果某些規則、某些習慣，或是我們無法理解的、某些宏觀的因果關係，使得我們彼此之間的確有所不同呢？
以我個人來說，因為住過沒有便利超商的地方，所以知道「家附近就有超商」是一種霹靂力矩。因為必須打工才能上學，所以知道「家裡能夠付清學費」也是一種霹靂力矩。
甚至，我能寫下這段文字，你能閱讀這段文字，都需要一些霹靂力矩。
我們不妨承認：到處都是霹靂力矩。更不用說相比霹靂力矩來說，用詞範圍更大、更抽象的「優勢」、「特權」、「資源」了。
承認優勢存在，並不會減損我們的其他特質。某個人擁有某些優勢，並不會否定掉這個人所付出的努力（更何況又有優勢又努力的人比比皆是）。進一步說，當某個人想要努力，而他也「能夠努力」，這件事本身就是一種優勢。
真正帶來差異的，是我們窺見系統一角之後的反應：是否認？是比爛？是嗤之以鼻？還是理解到每個人手上的牌的確有所不同，學著感謝自己能擁有的事物、思考怎麼運用這個遊戲制度和自己的優勢，並且尊重每個人都會有自己的痛苦和限制？
我們的環境、身份、特質，的確會為我們帶來某些優勢。但我們要怎麼看待這件事情，終究還是回到我們自己的選擇，而我們的選擇也將決定我們會成為怎樣的人。
最後，我想附上一些在這波討論中喜歡的一些文，以及一些延伸的內容：
- 【筆劍浮世繪】一盤之間的貧富差距──階級複製的故事 | 達達主譯
- 《社工觀察》美國社工界與覺醒文化（三）：特權（Privilege)
- 侯宗佑的貼文 - Facebook
- 蓮藕的貼文 - Threads
- Privilege 是什麼？「看不見的優勢」為何成為公共討論焦點
備註：感覺目前 Threads 上的論戰已經脫離原本 Privilege 的範圍，更多是在討論中文語境下的「特權」了。
比起「都市小孩相較鄉村小孩，更容易獲得施打疫苗的機會」，現在看見的議題已經變成：
- 「他家有特權所以他打疫苗一定插隊有夠壞」
- 「他都有疫苗打了還不滿足，還笑別人活該生病」
- 「打個疫苗而已哪叫特權，誰沒有打」
- 「你不能因為我打疫苗就否定我有努力運動讓身體健康啊」
這種大亂鬥（？）
但這不影響我想表達的內容，只是註記一下避免我以後搞混。
今天已經刷到兩篇從 MCP 走回 CLI 的貼文了，我們終於要進入反省期了嗎？
最近在反思 MCP （Model Context Protocol） 的使用方式。 雖然協定本身很強大，但在本地跑一堆 server 感覺還是太重了，另外對 agent 的 context window 來說也是一個負擔。 我開始嘗試回歸本源，盡量直接使用 CLI 工具來讓 AI 調用。
AI Agent 產品開發仍然不簡單 – ihower { blogging }
他最後補了一段我很喜歡: 「如果你根本不需要 MCP 呢?」很多 MCP server 過度設計，塞了一堆工具吃掉大量 context，其實用簡單的 CLI 工具透過 Bash 執行就好。
Queues Don’t Fix Overload - “My bad opinions”
某個時候佇列溢出，你就會失去所有資料。接著會有一場嚴肅的會議，大家討論這怎麼可能發生。
開發者 #3 建議增加更多工作執行緒，開發者 #6 建議讓佇列具備持久性，這樣當它當機時就不會遺失請求。
「酷，」大家說。回去工作。
某個時候系統又掛了。佇列重啟了，但它已經滿了，噁心。
開發者 #5 進來想：「喔對，我們可以再加更多佇列」（我發誓我以前不懂事的時候就看過這一幕）。
大家說：「喔對，這會增加容量」，然後就去做了。
然後它又死了。沒有人想到那個狡猾的紅色箭頭：
When people blindly apply a queue as a buffer, all they’re doing is creating a bigger buffer to accumulate data that is in-flight, only to lose it sooner or later. You’re making failures more rare, but you’re making their magnitude worse.
當人們盲目地把佇列當作緩衝區時，他們所做的只是建立一個更大的緩衝區來累積正在傳輸中的資料，最終遲早還是會遺失。
你會讓失敗變得更罕見，但也讓失敗的規模更大。
找到真正的瓶頸 - NO
把水槽弄得更大，大家一起排隊 - YES YES YES
我們又成功把問題延後了，感謝 Queue，又是美好的一天。
BlogBlog Club 部落部落俱樂部 | Wiwi Blog
網站上最主打的活動是「BlogBlog 同樂會」。這是一個大家一起寫文章、互相串門子、幫彼此衝人氣的活動，很好玩喔！
規則很簡單，基本上就是直接抄襲仿效國外的 Indieweb Carnival2（感謝 Alex Hsu 丟給我這個點子，他自己參加過兩次英文版）。只是變成台灣中文版：
每個月由當月的主持人（一開始當然是我）選定一個主題。
大家在各自的部落格上寫一篇跟主題相關的文章，並將連結以 E-mail 寄給主持人。
截稿後，主持人把所有參與者的連結收集起來，在自己的部落隔上發一篇整理回顧文。（BlogBlog.Club 網站也會連過去）
就這樣！沒有排名、沒有獎品，但可以把大家的 blog 連在一起。
第一期（2026 年 1 月）的主題是「推坑」。就像我現在正在推坑你寫 blog 一樣，你也可以寫一篇推坑文，推坑任何你覺得超讚的東西，不管是你家巷口的蛋餅店、你覺得超好用的馬桶刷，或是改變你人生的一本書都可以。但不可以是收錢的業配文喔！
看到這個 BlogBlog 同樂會，主題投稿感覺蠻有趣的耶，很好奇其他人會寫什麼。
不過一時半刻想不太到要推坑啥🤔
Hello world!
看到 Ivon 的這篇「給網站加入螢窗小語的「動態牆」頁面，替代 Facebook 的功能」蠻心動的，決定也在自己家弄一面動態牆試試。
雖然我的發文頻率有點悲劇，自己都懷疑動態牆這點子能持續多久，但有一小塊能閒聊、 …
看到了 PJ Wu 的 Stream 頁面，覺得超讚，尤其是顏色分類和排版，閱讀起來很舒適。
其中最有感的是留言功能，前幾天在搬推文到部落格的時候，最困難的部分就是原本的留言和引用難以保留。原本我在推特發了一則推文之後，如果後續有想要補充的資料或心得，就會用留言的方式放在推文底下；或者，我看到了另一則推文，覺得兩則推文之間有點關聯，我就會引用該則推文到我發的推文底下留言，這樣不管在原本的推文或是被引用的推文，都能夠雙向關聯到對方。這些操作都是基於推特這類留言平台才能完成的。
也因此，前兩天製作動態牆頁面時，很自然地就做成了簡單的短文列表。但看到了 PJ 的 Stream（特別是〈我為什麼要在網站上加上 Outdated 的樣式？〉裡這句「為我自己需求而做的小小功能」）之後，心想「對呀，自己做不就行了唄！」馬上召集團隊成員（Claude）搓了一版引用功能，過程順暢，歡喜非常，值得一記。
另一個收穫是順著 PJ 的 Stream 去逛了 Linus’s stream 和 Owen 的短想法，發現有更多人做著同樣的事，意外地令人高興。到某個人的部落格、閱讀某個人的短文，有種串串門子聽對方分享一些想法的親近感。在搭車回家的路上，不禁想像了一個到處都是各有特色的部落格，人們互相拜訪並交換小紙條的世界。
如果認知沒有先改變，就算把馬換成了汽車，也只會拿著鞭子抱怨。
Hello world!
看到 Ivon 的這篇「給網站加入螢窗小語的「動態牆」頁面，替代 Facebook 的功能」蠻心動的，決定也在自己家弄一面動態牆試試。
雖然我的發文頻率有點悲劇，自己都懷疑動態牆這點子能持續多久，但有一小塊能閒聊、抒發的版面，感覺也滿不錯的。接著打算慢慢把之前放在 Twitter 和 Threads 的貼文也搬一份到這裡。
所以，只要是比這篇早的動態，就是補發的啦。希望我不會搬家搬到手抽筋囉
前陣子聽的各個 AI 講座，大多都把重點放在生產力、工具介紹，或是快速兜出一個原型等等，這次 .Net Conf 難得聽到了一場從可觀測性的角度出發的分享。
的確，怎麼讓人員在 AI 大量產生的程式碼裡面更快定位問題，在設計時也該有憲章程度的地位才對。之前沒往這個方向思考過，算是打破了一個盲點吧。
12-09 補場次：Spec-kit x O.D.D：打造 AI 時代的 .NET 開發新選擇？
也推一下講師的部落格 m@rcus 學習筆記 跟 粉專
主打 DotNet 和可觀測性，提供給跟我一樣靠微軟把拔吃飯的朋友們參考
Theory-building and why employee churn is lethal to software companies
Many teams in the industry constantly rewrite parts of their code. Not because they keep figuring out better ways of approaching the problem but because nobody on the team has an accurate mental model for how it works and how the code fits in with the rest. If you can’t hold onto the original team, if you grow the team too quickly, you end up running to stay in place. Code keeps getting written without any improvements of substance to the software itself.
業界許多團隊不斷重寫部分程式碼。不是因為他們持續找到更好的解法，而是因為團隊中沒有人對系統如何運作以及程式碼如何和其他部分銜接有準確的心智模型。如果你無法留住原始團隊，或是團隊擴張過快，最後會發現自己只是為了維持現狀而疲於奔命。程式碼不斷被重寫，軟體本身卻沒有實質性的改進。
回想我參與過的、團隊決定重寫某段程式碼的那些討論，的確，大多時候我們會選擇重寫一版，其實就是因為我們已經沒人改得動了而已。
我才發現這沒那麼簡單，當一陣子沒有寫作之後，連想出文章主題都很不容易，就更別提難堪的文筆了。我是有一個很長的「待寫清單」沒錯，但上面的東西既然已經被我放了那麼久了，我要現下寫完根本不可能啊！
看到這段的待寫清單，心有戚戚焉，真的是放越久就越寫不出來。我有一個收件匣，像是工作上研究了什麼工具，或是跟同事聊到某個想法，覺得「好像可以寫一篇耶」就會先存下來。
但過陣子再回去看，連脈絡都忘得差不多了，更不用說寫成文章了。
太多的警報、沒有幫助的警報，或是每次發生事情都加一筆新警報，都會導致警報疲勞。
警報疲勞會導致團隊對警報失去信任、對警報的反應時間變慢，甚至無視警報，使得原本的警報變得更沒用。
Alert fatigue: What it is and how to prevent it
隨著環境變化，新趨勢可能會迅速使現有的監控失去準確性。與此同時，在每次新事件後建立警示，會把原本簡單的策略變得複雜化。把監控視為一次性或被動的工作，將會導致警示疲乏。
當監控系統產生過多警示或警示不相關、不具幫助時，就會發生警示疲乏，導致識別關鍵問題的能力下降。太少或太頻繁地更新警示，都會造成誤報和重複警示，令團隊不堪負荷。習以為常的團隊將無法及早發現問題，並會失去對監控系統的信任，進而擾亂生產並對業務造成負面影響。
Understanding Alert Fatigue & How to Prevent it
以下是七種需注意的警報疲勞徵兆：
- 回應時間延遲：當資安團隊難以處理大量通知時，回應警示的時間可能會比平時更長。
- 遺漏警示：當團隊被不斷湧入的警示淹沒時，可能無法將緊急且高優先度的事件與較不重要的問題或誤報區分開來。
- 忽視誤報：當團隊收到過多誤報警示時，可能會開始無意識地忽略或在心理上迴避這些通知。
- 壓力與倦怠增加：持續的警示會造成團隊成員壓力，並導致工作滿意度下降。
- 生產力下降：當團隊花太多時間處理警示時，生產力可能會下滑。
- 威脅評估準確度降低：由於警示量大，團隊可能因疲勞而做出判斷錯誤或不當評估潛在的安全風險。
- 事件紀錄不一致：當團隊不堪負荷時，事件紀錄與回應記錄可能不完整或不一致，造成難以分析事件並改善未來回應。
這週假日完全投入在絲之歌，目前進度為腐汁澤結束。
這代的推圖跳跳樂有感變多，即使是當年能在楓谷忍耐任務叱吒風雲的我也有點吃不消，尤其某些椅子和 BOSS 相距很遠，甚至加上跳跳樂 + 車輪戰 + BOSS 戰的可怕 Combo，死了馬上就得 …
絲之歌進度來到了無名鎮，總算攻略了某個結局必經的跳跳樂。
跳跳樂是一種我又愛又恨的關卡設計，玩家必須在尖刺和陷阱的夾縫中穿梭，用精準的跳躍閃避飛來的鋸齒、拿武器敲擊怪物來反彈向上⋯⋯有時還會加上時間限制，在被水流或怪物追殺的壓力下竄逃求生。一旦失誤下墜，就必須重新來過。如果是比較困難的關卡，重來十次百次到摔手把都是很常見的事。
在不斷重來的過程中，憤怒、沮喪、失落，都不會帶來什麼改變。只有不斷的練習、不斷地重試，直到能在正確的時機、正確的位置，做出正確的動作，才能抵達目的地。感覺跟「正射必中」的精神也有點相似了吧。
想起之前在 《血源詛咒》如何善用內在動機讓玩家甘願受虐？ 看過的這段：
『當玩家在死亡後反覆嘗試，發現自己能一次比一次進到地圖的更深處，或者距離戰勝boss越來越接近（這可以從你死掉的時候 boss還剩下多少血來判斷），就可以具體認知到自己的進展。
好不容易戰勝boss之後，玩家不會像終於打到最高級寶物那樣頓失遊戲動機，而是會興奮地帶著自己更精進的戰鬥技巧繼續前進。』
我們提出並測試 LLM 腦腐化假說：持續接觸垃圾網路文本會導致大型語言模型（LLMs）持久的認知衰退。為了因果隔離數據質量，我們在真實的 Twitter/X 語料庫上進行控制實驗，通過兩個正交的操作化方式構建垃圾和反向控制數據集：M1（參與度）和 M2（語義質量），在各條件下匹配標記規模和訓練操作。與控制組相反，對 4 個 LLM 在垃圾數據集上進行持續的預訓練會導致推理、長上下文理解、安全性以及膨脹「黑暗特質」（例如，心理病態、自戀）等方面的非微不足道下降
想到《福爾摩斯探案記》的這段：
你看，我認為人的腦子本來就像一間空空的小閣樓，應該有選擇地把傢俱放進去，傻瓜才會把他見到的所有破爛一古腦兒的裝進去。這樣一來，那些對他有用的知識反而被擠了出來；或者，最多不過是和許多其他的東西摻雜在一起，在取用的時候也會很困難。所以一個會工作的人，在要把一些東西裝進他那間小閣樓似的頭腦中的時候，確實是非常小心謹慎的。
如果想自行準備食材（資訊來源），就從 RRS 開始吧
告警越多，通知就越多；
通知越多，對通知麻痺的人就越多；
對通知麻痺的人越多，能被看到的告警就越少。
所以，告警越多，告警越少。
這次鏈鋸人的〈JANE DOE〉聽起來有種圓舞曲的感覺，重播了好幾次。搜到了這篇訪談，原來是這樣子的畫面呀
【音樂翻譯‧雜感】米津玄師 - JANE DOE - 箱庭博物館
── 撰寫〈JANE DOE〉的歌詞時你有過什麼畫面嗎？
米津：首先浮現的是，赤著腳站在破碎成片的玻璃上，用割傷的腳前進的景象呢。蕾潔是一位來歷不明的女性，對她來說生活的重心就在於消除自己的痕跡而活。擁有這樣人性一面的她，在玻璃碎片上行走，傷口鮮血直流，成為一個又一個的紅色腳印，這景象首先浮現在我的腦海，讓我想到「妳就是這樣走來的呢」。我思考這樣的景象是否能成為這首歌的主軸。
偶然看到真三國無雙２要重製的消息，真令我歡喜。
二代是我認識無雙的入坑作，當時 PS2 一半時間都給了它，留下了在合肥新城涼亭被弓箭手射成刺蝟、打南蠻被大象輾過去的一卡車遊戲回憶。想不到隔了二十幾年，還有機會用當代的畫質重溫當年的感動，這次只能謝謝光榮了
在受過職場無情的鞭打之後，我現在信奉的估時技巧是：
「數值和單位各加一」
兩小時就是三天，三天就是四週
有專案要做到年底？跟我的退休金說去吧
同事們還在把點數當划拳喊的時候，我已經在看股票了
這就是生產力的差距。
來聊聊那些非常欠人教訓的提問 & 發問 | 是 Ray 不是 Array
清楚描述你的邏輯以及過程
除了上面提到的「#求解」、「#救命」、「#我不會」、「#我不懂」以及「#在線等」等字眼，不可以出現在問題內容中之外，你也必須清楚 詳細的描述你的程式碼邏輯，如果你不清楚的話，我會這樣建議您條列你的問題：
- 提供原始碼
- 覺得有問題的檔案以及行數
- 你預期結果會出現什麼
- 但實際結果是什麼
- 你已經嘗試過哪些以及搜尋過哪些資料
- 你理解之後又是如何
除了這些之外的內容「通通不要有」，我是認真的。
今天在脆收到這篇，基本上就是當代白話版的〈提問的智慧〉，決定關聯到之前分享過的精準提問術做為參考，同時列到「當同事問了奇怪問題時直接甩過去」的文章清單
這週假日完全投入在絲之歌，目前進度為腐汁澤結束。
這代的推圖跳跳樂有感變多，即使是當年能在楓谷忍耐任務叱吒風雲的我也有點吃不消，尤其某些椅子和 BOSS 相距很遠，甚至加上跳跳樂 + 車輪戰 + BOSS 戰的可怕 Combo，死了馬上就得重跑，跑到都快幻聽〈三百六十五里路〉了，非常痛苦。
但戰鬥實在太好玩，大黃蜂的機動性非常高，在拿到飛針這類技能之後，搭配道具和下劈可以打出令人舒暢的空中戰鬥，還有不同紋章帶來的不同攻擊模組及特性，純論打架的話實在沒什麼能挑剔的，打完一場考驗玩家勇氣和冷靜的 BOSS 戰所帶來的快樂（或是用外鄉手段解決一些專門噁心人 BOSS 的愉悅）足以讓我願意多跳上兩三小時的跳跳樂。
幸好下週還有教師節連假，希望能一路殺進第一個結局。
10.22 回來補上這部影片：
【絲之歌】為什麼我說 腐汁澤的設計水準並不低？ - Bilibili
刷到這部談腐汁澤地圖設計的影片。回想了一下，雖然玩的時候氣得牙癢癢，但通關後的確會覺得腐汁澤是優秀的關卡。
開場先展示陷阱方向的差異，過程中也讓玩家有足夠次數練習躲避怪物的攻擊，大量利用標示和習慣誘導玩家踏入陷阱，並且基於玩家前面對蛆水的經驗形成的厭惡，準備了如果敢跳進蛆水反而更好打的 Boss 戰和隱藏補給點。
雖然有非常噁心的超長跑圖打王環節，但如果不是精心設計的話，還真的沒辦法給玩家留下這麼深的恨意，值得敬佩。
