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 白名單就能解決，沒想到踩到了一個大坑... 問題出現：IP 白名單完全失效當我興高采烈地在 IIS 管理器中設定「IP 位址及網域限制」，把信任的 IP 加入白名單後，發現一個詭異的現象： 設定為「允許所有」→ 正常運作 ✅ 設定為「拒絕未指定，只允許白名單」→ 所有人都 403 錯誤 ❌ 檢查 IIS Log 後發現真相大白： 1c-ip: 192.168.0.28 # 所有請求都顯示這個 IP！ 原來所有外部請求都是透過 192.168.0.28 這台 Proxy Relay 伺服器轉發過來的。IIS 只看得到代理伺服器的 IP，完全拿不到真實的客戶端 IP。 深入追查：尋找真實 IP 的蹤跡建立一個簡單的測試頁面來檢查所有可能的 HTTP 標頭： 123456789101112<%@ Page Language="C#" %><!DOCTY...
前端架構大亂鬥：讓 React 和 Vue 在同一個專案中和平共處的黑科技
還在為「公司要從 Vue 轉 React」或「新專案用什麼框架」而頭痛嗎？如果我告訴你，現在有一種技術可以讓 React 和 Vue 在同一個專案中完美共存，你會不會覺得我在說夢話？ 今天要跟大家分享的 Vite + Module Federation，就是這樣一個讓人眼睛為之一亮的黑科技。它不只解決了框架選擇的痛苦，更開啟了前端架構設計的全新可能性。 什麼是微前端？為什麼我們需要它？想像一下，你正在開發一個大型電商平台。產品團隊負責商品展示頁面，購物車團隊處理結帳流程，用戶中心團隊維護會員系統。傳統做法是把所有功能打包成一個巨大的應用程式，結果就是： 一個人改了購物車邏輯，整個網站都要重新部署 產品團隊想用最新的 React 18，但購物車團隊還在用 Vue 2 測試時牽一髮動全身，誰都不敢隨便改程式碼 微前端架構就像是把一個大房子分割成多個獨立的套房，每個團隊都有自己的空間，可以自由裝潢、獨立出入，但仍然共享同一個地址。 Module Federation：前端界的樂高積木Module Federation 最初是 Webpack 5 的旗艦功能，它的核心概念很簡單：讓不...
