Andrej Karpathy 前陣子提了一個概念：LLM Wiki——把 wiki 的結構化知識和 LLM 的語言能力結合，讓 AI 不只是生出看似合理的文字，而是基於你真正寫過的、整理過的、沉澱過的知識來回答問題。
老實講，這概念一看就覺得「對啊，為什麼沒有人這樣做？」於是我自己刻了一個。
一個基於 Karpathy LLM Wiki 哲學的雲端知識庫服務。把素材丟進去，AI 自動讀懂、重組成結構化 wiki，然後你可以用自然語言查詢整個知識庫——每個答案都有 citation，點擊就能追回原始文章。跟 RAG 最大的差別：不是查詢時才匆匆翻幾頁，而是入庫當下就讓 LLM 把知識整理好。
從排斥 vibe coding 到把 AI Agent 當成個人基礎設施：Morning Brief 自動化、WP-CLI 遠端管理、Skill 體系、多 Agent 分工模式。與其當做個會對話的 AI，這更像是個人 AI 作業系統。
稍微研究了一下BepInEx這個很常見的模型修改外掛在macOS下要怎麼使用，我用Chill with You – Lo-Fi Story來舉例。首先，你當然要有且下載這個遊戲：
從 iPhone 13 Pro 用到現在，已經快三年半了。原本沒特別想換，但最近看著螢幕邊框越來越舊、電池健康掉到 82%，加上身邊朋友陸續換新機，還是忍不住開始研究今年的 iPhone 17 系列。
一開始的目標其實是 iPhone 17，Pro 系列向來是「全都要」的選擇。但仔細比規格後發現，今年 Apple 的取捨策略跟以往不太一樣。iPhone 17 Pro 雖然有三鏡頭、更好的散熱、更大電池，但很多功能對我這種不打遊戲、不拍專業影片、不需要極致多工的人來說，真的用不到 :
一直到這個時候其實我都完全沒有考慮過iPhone Air。17 Pro 系列價格比 17 高出一大截，CP 值瞬間讓我動搖。去年 iPhone 16e 被砍到連 MagSafe 都沒有，今年 17無印反而回歸「該有的都有」，螢幕有 ProMotion 120Hz、支援 Always-On，MagSafe 也完整保留，感覺 Apple 終於把「平而不貧」的平衡點找回來了。
Read more “iPhone Air Review: Lightweight and Elegant”大多數電車車主應該都知道電池分為LFP跟三元鋰(我們取主流的NMC)，也都知道LFP建議充到100%來做「電池校正」，而通常對NMC則是沒有類似的建議。
任何有BMS(電池管理系統)的電池都有個百分率，告訴你用掉了多少電。這個百分率有時會不準確，通常這些百分率會在下幾個週期BMS的電池校正中貼近正常。那為什麼唯獨磷酸鐵鋰(LFP)需要特別關心電池校正，而三元鋰(NMC)不太需要？
直覺上，我們判斷一個電池剩下多少電，通常是看他的電壓，再去參照放電曲線。在大多數的情況下的確是如此:
恭喜踏進T公司！以JG34來講，如果你是副理(DM/AM)的話，你有很大的機率已經開始預備跟之後團隊磨合，打成一片了。但是如果你是技術副理的話，技術副理的挑戰與其說能力，更不如說是心態。有很多挑戰考驗的不只你的硬實力，也考驗你的做事方法。
首先，多了兩個字”技術”代表你短時間內不會帶團隊，你的定位會比較像是Principle Engineer。但是，台積電本身技術方面吃重程度遠低於Domain Know How，也就是說你一開始其實是…掛著個34的菜雞 — 對於整個團隊的產出上根本不可能在兩三個月內勝過33甚至32，你會看著他們熟練地解決一個一個的難題，但是你掛的比他們高卻什麼忙都幫不上，又不像副理感覺那麼有目標的開始融入團隊，開始準備帶team大殺四方。技術副理可說是有點無頭蒼蠅的味道，你不知道你要幹嘛，別人也不知道你能幹嘛。
所以這條路其實並不好走。會碰到的挑戰比想像中的多很多。由於JG34算是稀缺資源，所以一個新人一進來就拿34卻很難有所產出就會非常尷尬。我自己是有幸有非常好的夥伴幫我走過一段，我自己是總結出這些心得。並不是所有的技術副理都會碰到這些崁，甚至有些新人技術副理會碰到更多，這邊完全也沒提到的崁，所以就當作參考跟應對就好。
簡單的說，副理跟技術副理在台積是兩條不同的路，也沒辦法說哪條路比較簡單還是困難。不過以一個新人技術副理在這邊一陣子的經驗，「不需要帶團隊」這件事情並不會使onboarding較為輕鬆，而且也是充滿了挑戰。不過台積文化來講，副理被轉換成技術副理通常會被視為左遷，所以台積文化來講還是比較重視副理的。但是副理挑戰絕對不會比較少，帶隊過了蜜月期以後很快就要面對event，面對很多技術外的雜事挑戰，面對自己隊伍負責的功能的深度知識，更不像技術副理有較為充足的時間去一頭栽進文件裡面。
以我自己為例子，在前三個禮拜我有非常嚴重的無頭緒感，後來由於有一間建廠的事情趕工我去支援別的團隊，幫他們趕code後發現他們的整個產品可以做一些最佳化，於是我額外花了點時間幫他們做了一個新設計，主動提給我們家老闆，討論以後在我進來第二個月作為一個正式計劃提上去並且討論。
這需要對整個產品結構的廣度有一定程度的了解，實際進去動手才能體會整個產品痛點在哪裡，以及哪裡沒有align開發者的目標，進而提出改善計劃。之前花時間K的這些document會起很大的作用，即使跟自己專案沒有直接關係，但是會在這種地方讓你收到回饋。
技術副理不能只做資深工程師的事，不要忘記自己的使命不但是把事情做好，還要讓大家更容易把事情做好。恭喜加入團隊！
Model Y在一年前有迎來一波滿大的降價（約20萬），很多剛買的車主自覺變成韭菜。不過他人的韭菜就是我的快樂啦，趁著這波降價就把家裡的小白升級成大白。
當時是改款後Model S/X進台灣，我本來一開始的目標是Model S，在網路上填表單也是要試乘S。後來台特打電話來說明目前S並沒有開放試乘，不過歡迎來台特內湖靜態賞車，也能先安排一下Y的試乘。
Read more “回顧一下這一年的電車生活”之前花了不少時間在goland上跑起leetcode plugin，需要一些設定才可以讓整個goland跑起來。現在多了一個Rust可以玩解題，那我們首先還是要先把整個環境搭起來啦！
在講這個之前，先提一下主流語言通常「錯誤檢出」方面通常分為三個階段：
goplsC++擁有非常混亂的LSP實作，常常pre-compile time報錯，但是compile下去沒問題，以及反之….主要也是因為C++實在是過於複雜。而go是一個滿特殊的語言，他能夠把一些runtime才能檢出的東西藉由gopls以及go vet 做結構性語法檢查下，將錯誤把runtime提前到pre-compile time。