Hexo blog 想加 iOS 風炫過場？跑半天 morph 沒成，反而發現自己藏了 84MB 圖片巨石
昨天晚上看了 Coding2GO 一條 5 分 46 秒的影片，講 CSS View Transition API 終於支援跨文件了——純 CSS 兩頁各加幾行（同源 + 兩頁都 @view-transition { navigation: auto; }）、靜態網站也能做出 SPA 風的換頁過場。我當下就想到自己那個 Hexo blog：能不能加上 iOS 相簿那種「點縮圖、圖飛進去變大圖」的 morph 效果？ 今天動手，跑半天 morph 沒成。但 debug 過程裡順手 PowerShell 抓了一下封面圖檔大小——35 張總共 84.3MB，平均 2.4MB 一張。 結果 morph 收手，反而把整站圖片壓掉 93%（84MB → 6MB）。本來想搞炫的，沒成；結果抓到真正拖慢網站的東西。記錄一下這次的過程。 原本的目標清單下班前的 2 小時 budget，我想要的兩個東西： 整頁 cross-fade 換頁過場（基本款） list 縮圖 → 詳情頁大圖的 hero morph（進階款） 我以為大半是 CSS 的事，看起來很簡單。估了 2 小...
57.5% 的網頁請求已經不是人類——你的網站還在只為真人設計嗎
這篇文章的題目，是一個機器假扮成人類、去敲另一台機器的門撈回來的。 今天我想更新部落格，照慣例讓 Claude Code 上網找找熱點。它撈資料的指令我順手看了一眼——curl 後面掛著一長串 Mozilla/5.0 ... Chrome/124.0.0.0 Safari/537.36 的 User-Agent。那串字翻成白話是：「我是一個人類，正在用 Chrome 瀏覽器」。但下指令的不是人，是我的 AI 工具；它連的也不是給人看的網頁，是一個只吐 JSON 的 API。原因很實際：那個 API 用 nginx 擋掉所有看起來像程式的請求，預設的 curl/8.x UA 會被直接 403 回絕。所以為了幫我這個真人找今天的新聞，機器得先假裝自己也是個正在滑網頁的人。 撈回來的那堆 JSON 裡，有一條新聞正好在講這件事的全貌。 過了那條線：57.5% 對 42.5%2026 年中，一個分水嶺數字開始在圈子裡流傳：在 Cloudflare 網路上、對 HTML 網頁內容的 HTTP 請求裡，57.5% 來自機器人，只有 42.5% 來自真人瀏覽器——這是 Cloudflare R...
AI 篤定說 CSP 的 style-src unsafe-inline 拿不掉，我追問一句後它道歉了
2026-06-01 早上，甲方把一份 ZAP 弱掃報告丟過來，四條中風險全是 CSP（Content Security Policy，瀏覽器用來限制頁面能載入哪些來源的一層 HTTP header 防護）相關，附帶一句「中風險都要修」。最難纏的一條是 style-src 'unsafe-inline'。 我把報告丟給 Claude Code，請它評估。那天它給的結論是：這條技術上修不乾淨，只能寫一封信去說服甲方接受。兩天後，我們把它從正式機完全拿掉了，全站 94 個頁面實測零影響。 中間發生的事，比結論本身有意思——因為它一開始錯得很徹底，而我差點就照單全收了。 先搞清楚 V3 到底還剩幾條Claude Code 先把我們 Vue 3 專案正式機的 Web.config 拉出來對。弱掃報告裡那串髒兮兮的 CSP 其實是同台 server 上舊版 AngularJS 站台的，不是 V3 的。V3 的狀況比我以為的好： 1234script-src 'self' 'wasm-unsafe-eval'style-src &#x...
別讓 AI agent 自己決定花多少錢：四道讓 token 帳單不爆的護欄
讓 agent 自己跑批次任務之前，我以為成本是可以「事後再看」的東西。 那是一個排程任務：每天半夜起來，把前一天累積的一批項目逐筆讓 agent 處理、分類、寫回。我設好就睡了。隔天早上看帳單，一個晚上燒掉的量，差不多是我平常手動用一整個月的程度。 東西是有跑完，但這個價錢完全不合理。我花了點時間把它拆開來看，發現失控的不是「AI 很貴」這個籠統印象，而是三、四個很具體、而且都能堵住的洞。這篇就是那幾道護欄。 先搞清楚錢是怎麼流掉的LLM 的計費單位是 token，輸入和輸出分開算，而且輸出通常比輸入貴好幾倍。先記住這條核心關係：你每次呼叫付的錢 ≈（這次塞進去的 input token + 吐出來的 output token）× 對應模型的單價。實際帳單還有快取、推理 token 之類的細項，但抓大放小，主導成本的就是這三個變數——而每一個我那晚都用錯了。 把這條公式攤開來算一次就很清楚。假設我那個任務每次呼叫平均塞 50K token 的 context，跑 200 筆，光 input 就是 1,000 萬 token。如果我還傻傻地全程用最貴的模型——以我寫這篇的當下，旗...
你的商品開始在 ChatGPT 裡被賣了：Shopify Agentic Storefronts 技術拆解
3 月 24 日，Shopify 把 560 萬家商店的商品直接塞進了 ChatGPT、Google AI Mode、Microsoft Copilot 和 Gemini 的對話裡。不需要商家安裝任何 app，不需要額外設定，預設就開。 這不是「未來的電商趨勢」。這是上週發生的事。 發生了什麼事一個消費者在 ChatGPT 裡問「推薦一款適合冬天跑步的防風外套」，ChatGPT 直接列出商品、價格、評價，點擊後跳轉到商家網站完成購買。整個流程中，消費者不需要打開 Google、不需要逛電商平台、不需要比價網站。 數字說話：AI 導流量比 2025 年 1 月成長 7 倍，AI 歸因訂單成長 11 倍。Shopify 一口氣讓 560 萬商家對接 ChatGPT 的 8.8 億月活用戶。 技術架構：三層堆疊Shopify 不是簡單地把商品目錄丟給 ChatGPT。背後是一套完整的 agentic commerce 架構。 第一層：Shopify CatalogShopify 用自家的 LLM 自動分類和標註商品資料。關鍵在於——AI agent 不讀 HTML 描述。如果你的商品規...
一天、$400 的 token、年省 $500K：Reco 用 AI 重寫 JSONata 的真實帳本
Reco（一家 SaaS 安全公司）用 AI 在七小時內把 JSONata 從 JavaScript 重寫成 Go，產出 13,000 行程式碼，通過 1,778 個測試案例。token 花費 $400。上線後每月省 $25,000 compute 費用，加上後續的 pipeline 優化，年省 $500K。 這個故事在 Hacker News 上拿了 207 分和 186 則討論。數字很吸睛，但真正值得學的不是數字——是他們怎麼確保 AI 生成的 13,000 行程式碼不會在生產環境炸掉。 問題：一條昂貴的語言邊界Reco 有一個 policy engine，用 JSONata（一種 JSON 查詢和轉換語言，類似 jq 但有 lambda）對資料管線中的每條事件做規則比對。幾十億條事件，上千條規則。 JSONata 的參考實作是 JavaScript。Reco 的 pipeline 是 Go。所以他們多年來一直在 Kubernetes 上跑一整組 Node.js pod——Go 服務透過 RPC 呼叫 Node.js 來做 JSONata 運算。 每次呼叫的代價：序列化 → ...
你的 AI 應用塞了 50 個工具？GPT-5.4 的 Tool Search 讓你省下一半 token
上個月我在幫一個客服系統接 AI，工具列表長到我自己看了都頭痛——查訂單、退款、修改地址、查庫存、轉人工、寄信、查物流……加起來 47 個 function definition。每次 API 呼叫，光是把這些工具塞進 prompt 就吃掉 8,000 多個 token。使用者問一句「我的包裹到哪了」，模型還得先讀完退款政策和寄信格式才能回答。 GPT-5.4 在三月初發佈時帶來的 Tool Search 機制，直接解決了這個問題。 問題的根源：你付錢讓模型讀它用不到的東西傳統的 function calling 很直觀——你把所有工具的 JSON schema 丟進 tools 陣列，模型看完後決定要呼叫哪個。問題是，模型不管用不用，都得讀。 算一筆帳： 123一個工具定義 ≈ 150-300 tokens30 個工具 ≈ 4,500-9,000 tokens每次對話 10 輪 ≈ 45,000-90,000 tokens 花在重複讀工具定義 這些 token 不產生任何價值。它們只是讓模型知道「我有這些能力」，但 90% 的對話只會用到 2-3 個工具。 更糟的是，工具太多...
Xcode 終於讓 AI Agent 進場了：兩分鐘做出一個 App 的背後意味著什麼
二月底，Apple 悄悄推了 Xcode 26.3。沒有 Keynote，沒有 Craig Federighi 站在台上用動畫炫技。但這次更新可能是 Xcode 近五年來最重要的一個版本。 因為從這個版本開始，你可以在 Xcode 裡直接使用 AI coding agent。不是那種「自動補完下一行」的小聰明，而是整個 agent 接管你的專案：理解架構、搜文件、改多個檔案、跑 build、看 Preview、發現 UI 有問題還會自己修。 有人用它兩分鐘內做出一個完整的 Pomodoro 計時器 App——有設定頁面、提醒功能、能跑的 UI。 兩分鐘。 這不是 Copilot 的升級版先說清楚 agentic coding 跟傳統 AI 輔助寫 code 的差別。 GitHub Copilot 和早期的 AI 工具做的事情是「你寫一行，它猜下一行」。你是主角，AI 是配角。你的游標在哪裡，它就在那裡幫你。 Agentic coding 完全不同。你給 agent 一個目標——「幫我做一個 Pomodoro 計時器」——然後它自己拆解任務、決定要改哪些檔案、寫 code、跑 bu...
當 Siri 終於有了大腦：Apple 與 Google 聯手打造的三層 AI 架構解析
等了快十年，Siri 終於要從「智障助理」畢業了。 Apple 在 iOS 26.4 中重新打造了 Siri，背後用的是 Google 的 Gemini 模型。這不是小改版——是整個架構砍掉重練。22 億台 Apple 裝置將在三月底收到更新，這是史上最大規模的 AI 助理部署。 身為開發者，我最關心的不是行銷話術，而是三個問題：架構怎麼設計的？隱私怎麼處理？對我們的 App 有什麼影響？ 三層處理架構：該在哪算就在哪算新 Siri 的核心設計是一個三層漸進式架構。不是所有請求都丟給雲端，而是根據任務複雜度，動態決定在哪一層處理。 第一層：裝置端處理（On-Device） 簡單任務直接在手機上跑。設鬧鐘、開 App、查天氣——這些不需要網路請求，回應速度在毫秒等級。Apple 在 A17/M 系列晶片上跑的本地模型處理這些綽綽有餘。 隱私上最安全，因為資料根本不離開裝置。 第二層：Apple Private Cloud Compute 本地模型搞不定的中等複雜度任務，送到 Apple 自己的私有雲。這層用的是 Apple 自研的模型，跑在 Apple Silicon 伺服器上。 ...
當 IIS 遇到代理伺服器：如何在複雜網路環境下實現真實 IP 白名單控制
前情提要：測試機被臨時收走台電那邊因為要做白帽滲透測試，得暫時把測試機關掉。但開發團隊三不五時還是需要一個能驗功能的環境，於是我們把程式臨時搬到另一台機器上跑。原本盤算著，IIS 設個 IP 白名單就能擋住外人，半小時搞定。結果這個白名單，前後折騰了我大半天。 問題：白名單一開，全員 403我在 IIS 管理器的「IP 位址及網域限制」裡，把信任的 IP 一個個加進白名單，存檔，重新整理頁面。畫面回我一個乾脆的 403。 換個設定再試，規律很清楚： 設成「允許未指定的用戶端」→ 一切正常 設成「拒絕未指定的用戶端，只放行白名單」→ 所有人都 403 白名單裡明明有我自己的 IP，怎麼也被擋？翻 IIS Log 才看懂： 1c-ip: 192.168.0.28 每一筆請求的來源 IP 都是 192.168.0.28。這是那台 Proxy Relay 伺服器。外部請求全部先打到它，再由它轉發進 IIS。IIS 眼裡只有代理伺服器這一個來源，真正的客戶端 IP 它根本看不到——白名單再怎麼設都是擋自己人。 追查：真實 IP 藏在哪個標頭代理轉發時，習慣上會把原始客戶端 IP 塞進...
