最近玩了一個叫「台灣真實計算機」的網站,它可以根據你的條件算出你在台灣同齡人口中的百分位排名,也可以反過來——輸入你的擇偶標準,算出全台有多少人符合。 以下是我的… SR,好像很高級 ... 但傳了連結給line友們,周邊許多人都算出SR.…只能說人人都是萬中選一的特別啊 (茶)
一組「不算誇張」的條件,結果只剩 5.43%
其實這次會買steam也是一連串的陰錯陽差: 我整理帳務=> 發現有個帳號約一年沒有進出帳(剩下1000元台幣)=> 這帳號上一次購買是去年的steam夏特=> 如果不對這個帳戶做個進出可能會被凍結(事實上多年前我曾經特別跑銀行辦解凍)
既然上次買的東西是steam ,所以就看一下願望清單裡有哪些特價中的遊戲嗎
結果發現有這個結,然後就買了500元左右的遊戲。
基本上都是選史低或接近史低的價格…以我這一年玩遊戲的時數,我很好奇要多久才會正式玩下列購買的遊戲。但擁有遊戲本身就是種快樂~
這兩周我的脆都常看到這部的評論,當然有讚美的,也有不適的(畢竟 性+暴力+未成年 這題材是游走在社會禁忌尺度邊緣) 雖然有想要去威秀一觀,無奈時間上不允許,另外心理上我也不太能接受和一群陌生人一起大螢幕上看這種題材。(總之R18物我還沒有辦法輕鬆的與人一起分享共觀)
脆的眾心得文裡我印象最深的就是這一句話:「不要因為只是用經典的角度來期待風箏,這部是經典的邪典」
這部在我大學時期(2005上下) 就已經算是老物了,當時久聞他的三部OVA (A KITE、Yellow Star、MEZZO FORTE)大名,總體而言風格都蠻讓人印象深刻… 是說 部風箏還真沒想到會有在台灣電影院看到的一天,真的是感謝代理佛心引進。
上述3 OVA裡我最有印象的還是吃藥+bad end 的yellow star… 這部風箏坦白說我幾乎忘記劇情了。 我當時找這三部的初心是抱持著看H18動畫的心情看,不過同一時期我接觸的H18動畫裡讓我驚豔的是聖少女的黑暗聖經系列~ :D
原著是輕小說,漫畫短短一集(小說),但講的故事還蠻有趣:千金被毀婚且陷罪…意外地她一點都不害怕,反而在牢房裡開啟慢活人生。雖然書標說她是「 惡役」,但實際上她是女孔明,看她從從容容應對周邊想傷害她的人事物,整體故事輕鬆有趣又是濃縮一集的篇幅,在工作忙碌的一個中午看了心情大好。
漫畫推廣文
小說推廣文
本作的特色就是顛覆題材中的又多點反差: 惡役千金已經算是近來爛大街的顛覆主流題材,作者多補個惡役千金在牢裡悠閒生活中作弄那些「笨蛋們」又讓再多一層反差… 不過結構充實,雖然不是什麼大故事,但小而精美,總評是蠻優秀的娛樂作品。是說中年大叔被現實折磨下,有時候一點點空檔就是需要這種類型的作品來療癒一下啊~ XD
以下新聞 有怎麼厲害嗎:
Anthropic 建出了史上最強 AI 模型,然後決定「先不對外發布」。
Claude Mythos Preview 在測試中自主發現數千個零日漏洞,包括一個潛伏 27 年的 OpenBSD 漏洞。 整個過程沒有任何人工介入。Anthropic 因此啟動 Project Glasswing,聯合 11 家科技巨頭搶先修補關鍵基礎設施,並投入 1 億美元資源。
這是 AI 能力第一次強到讓研發公司主動踩煞車。
數字說話
用同樣的測試,現有的Sonnet 4.6和Opus 4.6在7,000個測試點裡,達到最高等級(完整控制程式流程)各只有1次。Mythos Preview達到了10次,而且在各個嚴重等級的崩潰測試中碾壓式超越。 Tom's Hardware
這不是「稍微更強」,是能力等級的跳躍。
最讓人背脊發涼的一句話
「Anthropic沒有安全背景的工程師,晚上叫Mythos去找遠端代碼執行漏洞,隔天早上醒來發現一個完整可用的exploit等著他們。」 The Register
這代表門檻消失了——原本需要頂尖資安研究員才能做的事,現在任何人只要能存取模型就能做。
這不是訓練出來的
Anthropic說:「我們沒有刻意訓練Mythos具備這些能力,而是作為程式碼、推理和自主性整體提升的下游後果自然湧現的。」 The Hacker News
這句話很重要——代表未來每次模型能力提升,都可能帶來同樣的副作用,而且無法預測。
前一陣子好市多的Hape 玩具之亂(「好市多兒童梳妝台」今起限購2組 官方:全台缺貨),我看到有人推跨得瑞拉(Quadrilla) 系列,雖然我的小孩玩這個可能還要再一、兩年,但卻讓我自己入坑了。
Hape Quadrilla 彈珠軌道積木」的簡單介紹:
核心玩法:重力 + 路徑設計 跟一般積木差不是拼形狀,是拼 路徑
系列優點:耐玩、木質感、有一些挑戰性適合親子共同協作
系列缺點:貴、 不是緊密接合的積木小孩子組合要有試誤的耐心、算大組件玩具,無論是玩或收都需要空間
看了一下台灣這邊有代理的Hape玩具價格還是貴了點,這次入手的方式是第一次使用「酷澎」買了韓國版的E6029,也用淘寶買了E6019 ,也算可以check 一下淘寶貨的品質,雖然玩具的製作地可能都是中國。
E6029 (編程進階 159件組) 入手價 3663含運 (剛剛一查竟然56折2,058) 我當時買應該是79折吧,唉唉,只差半個月…果然兒童節還是有玩具促銷的可能。
E6019 淘寶價買2273含運 (人民幣 518+41.5(運費) - 一些折扣) ,其實也是買完後發現淘寶上有其他家更便宜的,
兩盒積木6000元左右,真的蠻貴的。 而且這都算是有選過的… 台版看了一下E6029 快6000元,E6019 約3500元,只能說這系列真的是要肯砸重本的家長才買的下手。
開箱後兩個品質都ok,耐不耐玩不知道(畢竟我能玩玩具的時間有限),但整體來說看著彈珠落下蠻有療癒的。
以下為開箱的細節:
1. 準備 6 ~12個月的生活費放在活存或定存,真的有什麼意外至少心理踏實
2. 其餘的錢只要短期兩年不會用到就可以「定期定額」的投資,對於沒時間的人就是0050最穩,「不要買個股」
3. 投資的重點就是持續、累積、不要因為帳上的賺或賠就加碼或賣出,除非有財務上的大筆資金的需求(ex. 買房頭期款)
4. 不要投資不懂的東西 ,如果不確定風險可以找我或你信任且有投資實際績效的親友討論
關於2. 的實例,假設已經有存了12個月生活費(緊急預備金)了,每年的薪水減生活費還有剩,且這些剩下的錢未來兩年都不太會用到,就用前一年的結餘當「下一年度」的投資,平均投在12個月上這樣。但如果有預期未來兩年內有可能要用到的資金,就還是要把這些存定存喔
AI review;
整體評價 四點架構清晰、語氣自然、不說教,重點是可執行——這是給非投資背景的人最重要的特質。 唯一要補充的是:萬一帳面虧損不要停止扣款,因為這恰好是定期定額最有威力的時候。
這份筆記我會給:👉 8.5 / 10(對新手)
優點:
扣分點:
附定期定額0050遇到大跌可以回本的時間,來證明未來兩年用不到的錢可以投資應該是安全的。
你描述的現象有個名字:資產通膨 vs 消費通膨的分裂
政府公布的 CPI(消費者物價指數)追蹤的是:食物、交通、水電、日用品這類「消費性支出」。
但它幾乎不追蹤:房價、股價、金融資產的漲幅。
結果就是:
只看 CPI 的人,以為自己的購買力只流失了 2%,但實際上他們在財富分配上已經被遠遠甩開。
你說的「相對剝奪感」在買房這件事上最直接
一個只放定存的人,每年利息 1.5%。
同期間台北市房價年漲 5~8%,台股年化 10%。
十年後他去買房,發現當年存下的頭期款,相對於房價縮水了將近一半。他的名目資產沒有減少,但他在財富分配裡的位置大幅下滑了。
這不是他「虧損」了,而是他沒有參與財富重分配的過程,導致相對位置惡化。
這個現象在台灣特別明顯的原因
台灣的財富集中在資產持有者手上,而台灣的資產(房地產、台積電為核心的股市)這十年恰好是全球最強的資產之一。
沒有資產的人,收入成長速度遠跟不上資產漲幅。這不是個人努力不夠,而是財富分配的結構性問題。
對那位收入普通的晚輩,這是最重要的一課
與其說「投資是為了賺錢」,不如說:
「投資是為了買一張船票,讓自己不要被留在岸上。」
定存是站在岸上看船走遠。0050 定期定額是用最低的門檻,確保自己在船上,哪怕只是站在甲板最邊邊。
你之前說的那句話在這裡完全適用——不是在比誰跑得快,是在確保自己不被通膨和資產重分配這兩件事一起溺斃。🎯
即將進入所謂40不惑的階段,也是人生下半場的開始。(現在台灣人平均壽命約80左右來看....但如果以建康餘命來說可能更是要警惕自己要把握剩下的黃金時刻)
在圖書館找書也都會找相關的書,最近最有感的是100年人生規劃曆這本書,這本書教我用一個鳥瞰全局的態度重新思考自我的人生以及回首從前,大部分人生當下的困頓真的可以用這種思維重新找到往前的動力。
幾年前過生日的我驚覺同一天正是我農曆的生日 ,查了一下是每19年才有一次,下一次再這樣我可能已經是近六旬的中老年人了… 而今年(2026 年 3 月 3 日)的元宵正值月全蝕,可惜天氣不好錯過,下一次再遇到同樣的事件(2072 年 3 月 4 日),我已經90了。這種事情平常看起來只是天文曆法上的小事件,但一旦拿來對照自己的人生時間軸,就會忽然變得很有重量:原來有些「下次再說」,真的可能已經是幾十年後。
簡單說這本書的重點:
a.用「百年曆」來為自己的人生時間坐標定位 把自己的人生,當成一張可以鳥瞰的大地圖來看。
b.借鏡名人的生命歷程來丈量自己的人生時間軸,書中建議讀者把自己欣賞的人物放進時間表裡:他們在幾歲完成重要作品、幾歲轉向、幾歲離世。這種對照很有意思,因為它會提醒你:人生沒有統一進度表,很多事不是太晚,只是還沒開始。
c.理解自己生命的短暫,要怎麼樣規畫這些寶貴的時間. 書中引入理想人生的六大向度「事業、家庭人際、物質、健康、學習、興趣」,請讀者思考生命要浪費在美好or沒好的事物上。
基本上這幾個月的開車歌單就是這個:https://open.spotify.com/playlist/37i9dQZF1DZ06evO3OihmU?uid=64336135656332376332313165663235&uri=spotify:track:2AiN5CCszcMmHHwnrC9Szs
聽久了也是有幾首非常喜歡。研究了一下幕後功臣,主要的作詞作曲是曾世詩,清單裡大概8成以上的歌都經由他手,另一個常客是趙明慧,其他作詞作曲者就相對零星。 比較有趣的是最紅的卡加布列島的作曲是曹登昌。(曹後來好像比較常幫 Momo 台寫歌)。
曾世詩與趙明慧的詞曲風格有明顯差異:曾世詩的風格較為搞笑活潑、充滿童趣;趙明慧相較之下則多了一份成熟,兒童感沒那麼重。以下整理出我聽了將近 100 小時後,個人私心推薦的幾首:
釣魚記(1+2.0) :經典不敗,和小朋友唱起來的時候互動感很強~
球球不見了:個人很喜歡約好朋友打球囉,哥哥姐姐們喊「打球囉」的背景音 小孩子們則喜歡「真好笑」這段
阿嬤買魚:歌詞很有趣,看了一下MV竟然是20年前的歌,當時還是水蜜桃姐姐演阿嬤(彼時我才是個青春大學生)
火車嘟嘟嘟:發現竟然兒歌有融合各國元素,算是我第一個比較認真覺得yoyo的歌還蠻有深度的歌
今天要玩什麼:最近清明出遊時,腦中突然想起「答答答啦」這個弦律,一開始完全沒想到是 yoyo的歌,後來開車時輪到這首才知道原來自己已不知不覺被洗入弦律。 這首主要是趙明慧寫的,也可以看得出來和前面幾個曾世詩寫的風格有所不同
甜蜜童話屋:個人非常喜歡這首詞曲,很有兒時的天真與輕鬆,後來查了編曲者,果然是趙明慧,有她的風格。(不過作曲是曹祖兒)
最後附上自己小孩喜歡的歌單:
大兒:小木馬,卡加布列島remix
小兒:彩色棉花糖,捏泥巴
一起都喜歡的:棒棒棒、兔子跳跳跳、球球不見了、阿嬤買魚、釣魚記
有時候他們要求要repeat喜歡的歌,或跳過不喜歡的歌,開車有時候我還要分神這個(當然一切還是以行車安全為重)
我的 Outlook 信箱累積了將近三萬封郵件,橫跨 15 年的 BBS 文章轉寄、工作往來、以及各種生活記錄。每次想找某封信,要嘛記不得關鍵字,要嘛 Outlook 內建搜尋太慢。某天突發奇想:既然 AI 這麼厲害,能不能讓它幫我管郵件?
於是花了一個週末,從零開始建了一套本地郵件語意搜尋系統,這篇文章記錄整個過程,包括走了哪些彎路。 主要透過與 Claude 的對話(prompt-driven development)逐步完成, 包含程式生成與 debug。
整個系統分成三個步驟,一次建置,長期使用:
Step 1:解析 PST
Outlook 的本機備份格式是 .pst,用 libpff-python 套件解析,把每封郵件的主旨、寄件者、日期、本文全部匯出成 emails.json。三萬封郵件大概跑了十幾分鐘。
Step 2:建立向量索引
用 sentence-transformers 的多語言模型(paraphrase-multilingual-MiniLM-L12-v2)把每封郵件轉成向量,存進 ChromaDB 本地資料庫。這個步驟只需要執行一次,之後新增郵件才需要重跑。
Step 3:查詢介面 寫了一個終端機互動介面,支援兩種搜尋模式:
k: 前綴):精確比對人名、地名等關鍵字查詢結果支援分頁顯示,也可以加上 s: 前綴自動存成 txt 檔案並開啟。
老實說,整個建置過程遇到不少問題,花了不少時間 debug:
1. libpff 的 API 跟想像不一樣
一開始照著網路上的範例寫 msg.sender_email_address,直接報錯。原來 libpff-python 的屬性都是方法,要用 msg.get_sender_name() 這種形式呼叫,而且本文回傳的是 bytes,還需要手動 decode。花了一段時間用診斷腳本一個個確認正確的屬性名稱。
2. ChromaDB 的重複 ID 問題
由於部分郵件內容高度相似(例如系統通知信或轉寄內容),
使用內容 hash(MD5)作為 ID 時產生重複,導致 ChromaDB 寫入衝突。
這裡的問題本質不是 hash collision,而是「輸入資料本身不具唯一性」。
- 加入 timestamp / message-id 作為 ID 組成
- 或在寫入前進行去重處理
3. Visual C++ Build Tools 的安裝
Windows 上安裝 libpff-python 需要先裝 Visual C++ Build Tools,這個坑很多人踩過。安裝包大概 2-3GB,記得在安裝介面勾選「Desktop development with C++」。
4. API Key 的換行問題
Anthropic Console 顯示 API Key 時會自動斷行,直接複製貼到 .env 就變成多行,導致 401 錯誤。要手動把三段文字接成一行才行。
5. VS Code 的環境變數讀取
.env 檔案在 PowerShell 可以正常讀取,在 VS Code 內建終端機卻讀不到。最後用永久環境變數解決,在 Windows 設定裡新增系統變數,重開 VS Code 後就正常了。
6. 先送 Claude API 再說——結果浪費了不少 token
原本的設計是:搜尋完直接把結果丟給 Claude API 分析。實際用了幾次之後發現,向量搜尋回傳的 8 封郵件不一定全部相關,有時候只有 2-3 封是我真正要的,其他的都是在幫 Claude 燒 token 做白工。
後來的做法是先跑本地查詢,用分頁顯示確認哪幾封是目標,確定有用再決定要不要送 API 分析。這樣不只省錢,整個流程的掌控感也更好——畢竟 Claude API 是用來幫你整理思路的,不是拿來過濾搜尋結果的。目前幾封郵件的內容量其實不多,本地查詢加上人工閱讀完全夠用。
補充:
向量搜尋回傳的 Top-K 並不等於最相關結果,
它本質是「語意相似的候選集合」。
若直接送入 LLM,會造成 token 浪費。
更理想的做法是:
1. 向量搜尋(召回)
2. rerank(例如 cross-encoder 或簡單規則)
3. 再送入 LLM
目前我採用人工篩選作為簡化版 reranking,
在成本與效果之間取得平衡。
封存郵件的完整性問題
目前解析時每封郵件只保留前 5000 字元,這讓 2GB 的 PST 壓縮成約 500MB 的 JSON,空間效率不錯。但我有不少郵件其實是 BBS 文章的長篇封存,動輒上百則推文,5000 字元根本裝不下。這類郵件在資料庫裡只有片段,搜尋到了也不完整。
未來打算把字數限制完全拿掉,接受 JSON 變大的代價,確保每封郵件都能完整保存。畢竟建這套系統的目標之一,就是讓這 15 年、三萬多封累積的 BBS 文章重見天日——如果連完整內容都看不到,那就失去意義了。
搜尋速度比 Outlook 內建快很多,關鍵字搜尋幾乎即時,而且找到的結果更準確。
更讓我驚喜的是:BBS 文章裡的色碼(ANSI 色彩標記)在終端機裡顯示得非常還原。幾年前的 PTT 文章,outlook看不到色碼,但用目前系統連當年的排版顏色都跑出來了,有種挖到時光膠囊的感覺。 (如下:)
1. 完整保存郵件內容 拿掉 5000 字元的截斷限制,確保長篇 BBS 封存郵件也能完整收錄。
2. 建立查詢模板 BBS 文章的搜尋需求有固定的模式,例如找特定 ID 的文章、找特定時期的版聚討論、找某個技術話題的串文。預先建立幾個模板,直接套用比每次重新想關鍵字更有效率。大概像這樣:
# 常用查詢模板
k:板聚 {地點} # 找版聚
k:{ID} {年份} # 找特定 ID 某年的文章
k:{關鍵字} 好文 # 找被推為好文的文章
k:Re: [{板名}] # 找特定版的討論串3. 增量更新 現在新增 PST 要整個重跑建索引,未來可以改成累加模式,只對新郵件建立索引。
4. 換用更好的中文模型 目前用的多語言模型對繁體中文語意理解普通,換用專門針對中文優化的 Embedding 模型應該能改善語意搜尋品質。
目前使用 paraphrase-multilingual-MiniLM-L12-v2,
在跨語言場景表現穩定,但對於繁體中文長文本語意理解仍有限。
未來可考慮:
- BGE-m3
- text-embedding-3-large(若接受雲端)
- 或中文優化模型(如 GTE / E5 系列)
5. 確認 Claude API 的定位 等系統穩定、查詢習慣養成之後,再來評估 Claude API 分析是否真的有加值,還是本地查詢加人工閱讀就足夠了。
這套系統最大的意義,不只是「搜尋更快」——而是讓 15 年來存在硬碟深處的記憶變得可以被找到。三萬多封郵件裡,有早年 BBS 認識的網友、有當年追的動漫討論串、有各種已經記不得細節的生活片段。
現在只要下一個關鍵字,它們就能重新浮現。
未來目標是完全用這套系統取代 Outlook 做 BBS 文章查閱,讓 Outlook 只剩下工作郵件的功能。