AI 代理人支付在大約一年之內產生了四份彼此競爭的規範、兩個產業基金會，以及海量的報導。它還沒有為絕大多數商家產生的，是營收。噪音與數字之間的落差才是值得理解的部分，因為興奮的報導和輕蔑的報導都以讓人賠錢的方式弄錯了。 確實有真東西正在被打造。Google、OpenAI、Stripe、Coinbase、Shopify、Visa 和 Mastercard 都在這個領域交付了規範或產品，其中兩份規範如今歸屬於中立的基金會，而不是單一廠商。其中一部分已經在正式環境中運作。但正式環境裡的大部分流量，是機器向另一台機器購買 API 呼叫，而不是購物助理向你買一張沙發。 本文把已經交付的東西與只是掛了一排標誌的規範區分開，說明你的結帳流程和風控...
API開發
關於API開發的文章、指南和教程，為開發者和企業提供實用知識與技巧。附實用要點。
Salesforce 整合幾乎從來不是敗在通訊協定上。驗證是已經解決的問題，寫入一筆記錄也是已經解決的問題。真正把專案拖垮的，是每天的請求配額和資料模型的形狀，而這兩件事通常要等到上線大約三週之後才被發現，那時夜間作業開始回傳錯誤，卻沒有人說得清它在測試環境裡為什麼是好的。 這個模式一致到可以預測。開發者對著一個 Developer Edition 組織開發，一切通過，客戶簽字驗收。接著這套程式碼遇上的，是一個已經住著行銷連接器、資料倉儲擷取作業，以及一個 2019 年就在跑的 Apex 觸發程序的正式組織，而那份看起來很寬裕的請求預算，其實是別人早就在花的一口共用的鍋。 這篇文章把意外提前攤開來談：你應該用哪一個 API、配額是怎...
密碼儲存是軟體領域裡少數幾個真正存在標準答案的題目之一。答案早就公開了，一直有人維護，而且免費。但它同時也是最常被做錯的題目之一，原因很單純：那些現在被視為錯誤的做法，在某個年代確實是正確的，而後來沒有人再回頭看過一眼。 失敗的樣子很少稀奇。通常就是一套 2016 年依照 2012 年的建議搭起來的系統，到今天還在跑，還在接受登入請求，而自從當初寫下那段雜湊程式碼的人離職之後，就再也沒有人打開過那個函式。它沒出過事故，也沒被稽核過，所以從來不在任何人的待辦清單上。 如果只帶走一句話：用 Argon2id，真的不行就用 bcrypt。 本文其餘部分都是細節。像 SHA-256 這樣的通用雜湊函式，無論你套用多少次，都不會變成密碼雜湊。...
關於 API 版本管理的爭論，幾乎總是從錯誤的一端開始：版本號到底要放在哪裡。事實上，那是整個主題裡後果最輕微的一個決定。真正要緊的是究竟哪些變更才需要一個新版本，而多數團隊恰好在這裡判斷失準，而且是往掉以輕心的方向失準。他們發布了自認為純屬新增的東西，然後某個用戶端就壞了。 好用的思考模型是這樣：你的 API 是一份承諾，界定了呼叫端可以倚賴什麼。如果一次變更讓一個講理的呼叫端原本倚賴的東西失效，那它就是破壞性的。而呼叫端倚賴的東西，遠遠多過你的文件明確允許他們倚賴的範圍。 讓所有人都踩到的那種變更： 在回應裡多加一個欄位。它只是新增，照理說弄不壞一個寫得規矩的用戶端，可它偏偏經常弄壞真實世界的用戶端，因為其中有些會嚴格驗證回應，...
資料庫效能的排查工作，通常從有人提議換一台更大的執行個體開始，又通常以這樣一個發現收場：每次載入頁面時，有一條查詢都在對 400 萬列做循序掃描。瓶頸從來就不是硬體，瓶頸是執行計畫。 這個模式重複得夠穩定，值得當成預設假設寫下來。當應用很慢而資料庫又很忙時，原因幾乎都是少數幾條特定的查詢，而不是整體容量不足；把機器換大，只能把問題掩蓋到資料表再次長大的那一刻為止。 動手改之前，先量。 憑猜測去最佳化一條查詢，正是團隊花掉整整一週新增索引、結果寫入變慢而讀取一點也沒變快的原因。任何資料庫都能告訴你哪些語句消耗的總時間最多。從那裡開始，修掉排在最前面的那一條，然後再量一次。這樣反覆兩三輪，事故通常就結束了。 資料庫效能始於找出那條查詢總...
微調 vs RAG 這個題目，多半不是以問句出現，而是直接以一句結論登場：我們要拿自己的資料去微調一個模型。這大概是企業 AI 裡最花錢的一句話，而且多數時候是錯的。不是每次都錯，但確實多數如此。這句話背後幾乎只有兩種真實情況：模型不清楚我們公司的事，或者模型回答的方式不合我們的要求。前者用微調來解很糟糕，後者用微調來解很貴。 在微調、RAG 與提示詞之間做取捨，並不是工程師的口味問題。這三者處理的是完全不同類別的毛病，一旦選錯，換來的會是好幾個月的工，而最初那句抱怨依舊原樣擺在那裡。 最能省下預算的一條原則： 如果毛病出在模型不知道某件事，就用檢索。如果毛病出在模型知道，但回答的風格、格式或篇幅不對，先把提示詞改好，真的無效時才輪...
進入 2026 年後，認真考慮遷移離開 OpenAI 的團隊明顯變多了。開放權重模型在日常生產任務上的品質已經很難與頂尖模型區分開來，公開單價更低，而權重本身可以下載這一點，把與廠商的關係從依賴變成了選擇。 但這不代表切換是免費的。API 呼叫本身幾乎一模一樣，真正要做的工作在它周圍的一切。本文說明：哪些東西能原樣搬過去、哪些會悄悄出問題、怎樣設計一次有意義的比較，以及什麼時候留在原地才是正確答案。 先把預期對齊。 換廠商就是換一個基底 URL、一個模型名稱、一份憑證。但要拿回同樣的輸出品質，那是以天為單位計的提示詞工程。給一個範圍明確的功能預留一到三週。任何假設可以即時替換的估算，都是樂觀估算。 哪些東西能原樣搬過去比你想的多，這...
大多數團隊把 API 安全當成身分驗證問題：發放權杖，在每一條路由上檢查它，然後認為事情已經做完了。直到某天，一位測試人員把網址裡的一個數字改掉，就讀到了另一位客戶的發票。 「已通過身分驗證」和「已獲得授權」之間的這道縫隙，正是絕大多數真實 API 外洩事件棲身的地方，而且它並不是掃描器能夠穩定發現的那類問題。自動化工具看到一個有效的權杖和一個 200 回應，就回報成功。只有理解你業務規則的人，才會注意到那個回應裡裝的是別人的資料。 核心區別： 身分驗證證明的是誰在呼叫。授權決定的是這個特定呼叫方可以看到什麼、可以修改什麼，而且它必須落實到每一個物件、每一次請求，並在資料層強制執行。幾乎所有嚴重的 API 漏洞，都是第一件事運作完...
Kimi K3 API 帶著一個不尋常的組合登場：接近前沿水準的基準成績、積極的定價，以及可供下載的權重。Moonshot AI 在 2026 年 7 月 27 日公開了這些權重，使 K3 成為迄今公開發布的最大模型，也是這種規模的模型首次在原則上可以由你自己運行。 對於已經在向前沿供應商付費的團隊而言，這提出的是務實問題而非哲學問題：它在你的技術堆疊裡有沒有位置，把一部分流量遷過去究竟會改變什麼。本文討論成本試算、整合工作，以及那些公開數字無法轉化為生產表現的環節。 簡而言之： Kimi K3 的快取未命中輸入約為每百萬 token 3 美元，快取命中輸入約 0.30 美元，輸出約 15 美元，脈絡視窗為 1,048,576...
凡是按端點數量來估算客製化 API 開發成本的人，幾乎都會算錯，而且通常差三倍。端點本身是整件事裡最便宜的部分：十來個端點，只是讀寫你手上已經有的資料，對一位稱職的後端開發者來說不過是兩週的活。 真正花錢的，是把這些端點變成另一家公司願意把生意押上去的東西所需要的一切：經得起安全稽核的驗證、讓你日後還能改主意的版本管理、好到沒人需要寫信問你的說明文件，以及能告訴你哪個客戶今天早上過得不順的維運裝置。有一個 API，和有一個別人靠著它做生意的 API，兩者之間的那道落差，才是預算真正的去處。 價格區間速覽: 只被你自己的應用程式呼叫的內部 API，通常花費 10,000 到 30,000 英鎊。...