如果你覺得我分享對你有幫助，歡迎使用我的推薦碼註冊幣安帳號，支持開源交易框架 bbgo 的開發。 🤗🤗🤗 accounts.binance.com/en/regi…

這女婿也太帥了吧 🥸🤯🥸🤯🥸🤯🥸🤯🥸🤯🥸🤯🥸🤯

宮下玲奈長這麼美、身材又超好，到底為何要去當 AV 女優啊 🤯 她有好幾張照片某些角度根本就超像 BlackPink 的 Lisa ，明明有那個本錢可以當女明星的呀

其實考慮到 AI coding efficiency ，幾乎所有的動態型別語言都不是 AI friendly 的語言。對，就是 PHP Python Ruby Perl 因為在這些動態型別語言裡面，特別是 Ruby 跟 Perl ，有一種特殊文化，就是會利用語言的特性來創建 DSL (Domain Specific Language ），然而這種 API 設計是給人類看了覺得爽用的，對 AI 來說，他會需要把這些 DSL 的底層 library 讀過一遍才有辦法依照這個 DSL 去寫出正確的程式。 另外一個動態型別語言的問題就是，物件在不同層級傳遞的時候常常會在中間去安插一個新的欄位，然而因為這個物件通常都是字典類型的物件，所以AI非常難去找到這個物件欄位的清楚定義。 然而在靜態性別語言身上這件事情就完全不同，函數的輸入與輸出其定義的型別可以讓 AI 很容易找到該型別的定義，進一步增加了AI coding 的穩健性。 基於這幾點，雖然我們還在AI Coding的過渡期，但我相信這類型的動態語言將會在最近幾年大幅失勢。 因為同樣用AI來寫程式，你可以選擇寫出更高效率更節能，而且讓AI更有效率開發的程式語言，那你就沒有必要再繼續使用原本是設計給人類寫的動態程式語言了。

我剛剛請 AI 幫我設計最新版的 Apple Keyboard

我有一台開給客戶用的 Linode (2011 年) 今天終於功成身退了

ChatGPT 現在不允許我刪除對話... 靠...渾身不舒服

「你就是那條龍」 飛龍在天 😁😁😁

我在 Gonna 吃飯，隔壁桌貌似是工程師，討論到 Flutter 其中一位在說她女兒已經在用 AI 寫手機 App，好像用了什麼新技術，叫 Flutter ，他還研究了一下才知道 Flutter 是什麼 另外一位問他說 Flutter 是什麼樣的東西 「Flutter 就是啊 ..... (下略） 」 幹 我突然覺得我好老

上個月補貨得意廚房紙巾，發現價格不變，但容量已經縮水一半，點餐的時候發現原本 79 元可以加一整顆酪梨，現在看到帳單上是 1/2 酪梨。 去鬍鬚張副牌精簡康買一盒雪霜豬肉 105 元只買得到 150 克 我的生活品質正在濃縮中 .........

50嵐店面的背景音樂是找人自己編曲的嗎？都很好聽耶其實

我的 Claude code 的 token 一直用不完，但令人最覺得瘋狂的是，我可以去全家坐個 25 分鐘就可以做完 3-4 個 feature（只要你描述得夠清楚，基本上做的又快又準）

Junie 的 Harness 說真的不差，而且比 Antigravity 產出的品質好非常多

用兩個字譬喻玩皮克敏: 練蠱

這年頭 AI 寫程式好像造成了一大票工程師恐慌。 網路上每天都有人展示自己用 Claude、ChatGPT 或 Gemini 在幾個小時內做出網站、手機 App，甚至直接做出可以收費的 SaaS 服務。看久了，很多人自然會開始擔心：「那工程師是不是快要被取代了？」 但真正長期使用 AI 做開發的人，大多會發現另一件事情：AI Coding 的生產力提升是真實存在的，但它並不是無限擴張的。 很多人被各家模型宣傳的百萬級 Context Window 所吸引，以為只要把整個 Repository 丟進去，AI 就能理解所有程式碼並完成任何修改。然而 Context Window 解決的其實只是「看得到多少資訊」的問題，而不是「理解多少資訊」的問題。 這就像把一千頁文件全部攤在桌上，不代表你能同時理解那一千頁的內容。 當 Context 越來越大，AI 必須在大量資訊中持續搜尋、篩選、建立關聯並進行推理。資訊量越大，判讀成本就越高，而判讀成本越高，錯誤率自然也會跟著提高。這也是為什麼許多人在大型專案中經常感受到 AI 開始出現混淆、失真，甚至產生幻覺。 小型專案通常感受不到這個問題。 如果你的專案只有幾千行程式碼，你可以很輕鬆地告訴 AI：「幫我加上會員登入功能」、「幫我做一個管理後台」、「幫我接上 Stripe 付款」，然後得到相當不錯的結果。 但當你的系統逐漸成長到數十萬行程式碼之後，事情就完全不一樣了。 此時 AI 不再只是寫程式，它必須先知道相關功能在哪裡、理解現有架構、分析依賴關係、找出商業邏輯、確認資料流向、評估修改風險，最後才能提出一個合理的解決方案。 換句話說，AI 開始面對的已經不是 Code Generation，而是 Software Engineering。 而軟體工程最大的難題，從來都不是把程式碼打出來。 而是理解系統。 當 Repository 越來越大，AI 搜集出來的資訊也會越來越多。它可能引用不存在的函式、使用過時的 API、誤解 Domain Model、修改錯誤的模組，甚至提出一套看似合理卻完全違反現有架構的方案。 這些問題在 Side Project 裡面通常只是小麻煩，但在正式產品環境裡，很可能就是 Production Incident。 因此真正有經驗的團隊，很少把 AI 當成自動駕駛。 更多時候，它比較像是一位速度極快、記憶力極強，但偶爾會一本正經胡說八道的工程師同事。 而且隨著專案規模擴大，AI 的另一個成本也會開始浮現：Token。 很多素人以為 AI 開發的成本趨近於零，但實際上當專案變得複雜之後，你會發現邊際效益正在遞減，邊際成本卻在不斷上升。 為了讓 AI 理解問題，你需要提供更多 Context。 為了修正錯誤，你需要反覆對話。 為了驗證結果，你需要不斷追問。 為了避免幻覺，你需要讓 AI 重新搜尋整個專案。 於是 Token 開始快速燃燒。 這也是為什麼網路上經常看到有人在幾天之內燒光所有額度，然後不斷等待 Reset Time，或是持續加購更多 Credit。 因為他們正在用 Token 去彌補自己無法快速判斷答案正確性的成本。 很多人以為 AI 時代最重要的是 Prompt Engineering。 但我認為真正重要的其實是 Pair Programming。 使用 AI 寫程式，並不是像直男癌一樣單向輸出自己的需求，然後等著對方把事情做完。你需要與 AI 持續溝通、持續修正、持續驗證。 你越理解程式碼，越能指出問題在哪裡。 你越理解架構，越能縮小搜尋範圍。 你越理解系統，越能給出精準的指令。 而這些能力都會直接轉換成更好的產出品質、更低的 Token 消耗，以及更快的開發速度。 所以寫程式這項技能並沒有因為 AI 的出現而突然失去價值。 真正貶值的，是把程式碼一行一行打出來的勞動。 真正升值的，是理解程式碼、理解系統、理解問題本質的能力。 AI 並沒有消滅工程師。 它只是讓工程師的價值，從「寫程式的人」逐漸轉變成「理解系統的人」。 而當專案規模越大，這件事情反而會變得越明顯。