AI 代理人支付在大約一年之內產生了四份彼此競爭的規範、兩個產業基金會，以及海量的報導。它還沒有為絕大多數商家產生的，是營收。噪音與數字之間的落差才是值得理解的部分，因為興奮的報導和輕蔑的報導都以讓人賠錢的方式弄錯了。 確實有真東西正在被打造。Google、OpenAI、Stripe、Coinbase、Shopify、Visa 和 Mastercard 都在這個領域交付了規範或產品，其中兩份規範如今歸屬於中立的基金會，而不是單一廠商。其中一部分已經在正式環境中運作。但正式環境裡的大部分流量，是機器向另一台機器購買 API 呼叫，而不是購物助理向你買一張沙發。 本文把已經交付的東西與只是掛了一排標誌的規範區分開，說明你的結帳流程和風控...
自動化
關於自動化的文章、指南和教程，為開發者和企業提供實用知識與技巧。涵蓋範圍、工作量與實際成本。
Agentforce 依用量計費，光是這一點就該改變你編預算的方式。多數 Salesforce 買家帶著席次授權的思維進場，問一個代理人每位使用者每月多少錢，然後拿到一個並不描述自己帳單的數字。帳單取決於代理人執行了多少次動作，而那又取決於代理人設計得有多好，以及你的知識庫有多好。 這讓它在企業軟體採購裡顯得不尋常。代理人內部的設計決策就是帳單上的項目。一步答完一個問題的代理人，成本只有磨過五步那種的五分之一，而授權條款不會告訴你自己做出來的是哪一種。你會從帳單上知道答案，通常是在第三個月。 Agentforce 到底要花多少錢？ Salesforce 有兩種計費方式。Flex Credits 是每 100,000 點 USD...
Salesforce 整合幾乎從來不是敗在通訊協定上。驗證是已經解決的問題，寫入一筆記錄也是已經解決的問題。真正把專案拖垮的，是每天的請求配額和資料模型的形狀，而這兩件事通常要等到上線大約三週之後才被發現，那時夜間作業開始回傳錯誤，卻沒有人說得清它在測試環境裡為什麼是好的。 這個模式一致到可以預測。開發者對著一個 Developer Edition 組織開發，一切通過，客戶簽字驗收。接著這套程式碼遇上的，是一個已經住著行銷連接器、資料倉儲擷取作業，以及一個 2019 年就在跑的 Apex 觸發程序的正式組織，而那份看起來很寬裕的請求預算，其實是別人早就在花的一口共用的鍋。 這篇文章把意外提前攤開來談：你應該用哪一個 API、配額是怎...
事故檢討很容易召開，卻很難做得有用。會開了，文件寫了，四條改善事項記下來了，六個月後同一個故障又發生一次，而某個人正好在找別的東西時翻出那份舊文件。 談到這件事時，注意力幾乎都落在「不究責」這個詞上。這條原則確實重要，但失效的地方並不在那裡。有大量組織把不究責執行得一絲不苟，檢討卻什麼也沒有改變，原因很簡單：他們把檢討本身當成了交付物，而不是當成產出交付物的手段。 判斷你們的檢討是否有效，有一個簡單到令人難堪的測試：過去六個月記錄下來的改善事項，實際完成的比例是多少？ 如果答案是「大部分」，那麼無論流程長什麼樣，它都在發揮作用。如果低於一半，你們是在開會而不是在運行一個流程，換更漂亮的範本也救不了。少數幾條帶負責人與期限的事項，勝過...
軟體供應鏈安全聽起來像是設有專職資安部門的大型組織才需要煩惱的事，而正是這種定位讓人判斷失準。一個只維運少數幾項服務的小型團隊，通常同樣相依於數百個套件，而其中沒有任何一個是團隊裡有人真正讀過的。這些套件會在建置時從團隊無法掌控的套件庫抓下來，接著在存放部署認證資訊的機器上執行安裝腳本。 暴露程度並不跟著公司規模等比例放大。它跟著相依套件的數量與建置自動化的程度放大，而小型團隊往往是前者更多、後者更少人盯著，處境比那些公開談論這件事的大型組織還要吃緊一些。 令人不舒服的算術： 你的應用程式大概有十來個直接相依套件，以及數百個間接相依套件。那十來個是你自己挑的。其餘的不是，你一個也沒讀過，而其中任何一個只要執行安裝腳本，拿到的權限就跟...
技術文件的失敗方式非常具體，也非常好預測。有人在兩週清閒的時間裡寫下一大堆，接著系統變了，沒有人回頭更新，一年之內那份文件就開始信心十足地講著錯誤的內容。到了那個時候，它比什麼都沒有還要糟，因為相信它的讀者會依據早已不成立的資訊去動手。 常見的反應是號召大家多寫一些，而這只會讓同樣的失敗來得更快。有用的反應是少寫，並且認真挑選寫什麼，因為真正的瓶頸不是寫作的工夫，而是維護的工夫。文件從寫完那一刻起，就開始被現實甩在後面。 判斷一份文件該不該存在，唯一經得起時間的檢驗是： 當它變錯的時候，會不會有人察覺？部署指南天天有人用，錯誤立刻就會浮出來。一份二十頁的子系統說明只會被讀一次，它的錯誤要等到十八個月後，有人照著它動手時才浮出來。沒有...
開發者到職通常是用新人訓練花了幾天來衡量的，而那是問題的另一頭。真正重要的數字是另一個：一位新來的工程師要過多久，才能改動某個東西，而且有把握自己沒有弄壞別的地方。在大多數團隊裡，這個數字是以月計算的，而不是以天計算的。 延遲很少出在人身上。它出在系統裡有多少部分只存在於別人的腦袋裡，以及前兩週裡有多大一部分時間，是靠一次次打斷別人，一點一點把這些東西挖出來的。 唯一值得追蹤的指標：從到職到他們的第一次改動進入正式環境，需要多久。 不是第一次提交，提交可以只是改一個錯字，而是一次有意義而且真正上線的改動。如果這個時間超過一週，障礙幾乎從來都不是能力。而是一份最近沒有人從零走過一遍的環境建置流程，或者一份沒有人帶路就找不到入口的程式碼...
可用性 SLA 看起來像一句承諾，實際運作起來卻更像一份退款政策。供應商很清楚這一點。客戶往往並不清楚，於是在簽下服務等級協議時以為自己買到了可用性，而真正買到的，只是萬一沒拿到時的一點折扣。 這不一定是筆糟糕的交易。它只是與大多數人以為自己在簽的那筆交易不同，而這個差別恰恰在系統停擺、有人追問合約究竟怎麼寫的那一刻顯現出來。 三個九聽起來接近完美，卻允許每月 43 分鐘的停機。 四個九允許四分鐘。如果你的業務吸收得了平日下午 43 分鐘的中斷，99.9% 就足夠了，不必為更高的數字付費。如果吸收不了，再多的九也幫不上忙，因為協議給你的是一筆抵用金，而不是阻止這次中斷。 可用性 SLA 用分鐘兌現的承諾百分比把一個非常大的區間壓縮成...
在小團隊裡，災難復原通常只剩下一份從來沒人打開過的文件裡的一行字：備份已經開啟。這句話本身沒有錯，卻算不上任何問題的答案，因為它既沒有說明真正出事時救回來的資料會有多舊，也沒有說明還原一次要花多久，更沒有說明到今天為止究竟有沒有人完整地做過一次還原。 擁有備份和真的能復原之間存在一段明顯的距離，多數的服務中斷正是在這段距離裡升級成事故。一份存在、內容也夠新、卻從來沒有被還原過的備份，本質上仍然只是一個假設；而你第一次驗證這個假設的時刻，剛好是發現它其實是錯的最糟糕的時刻。 兩個數字能把意見變成計畫。 你承受得起丟多少資料，又承受得起停多久？這就是你的復原點目標與復原時間目標。只要營運那一側沒有人把這兩個數字說出口，關於備份頻率的一切...
談到軟體測試策略，大家幾乎都從覆蓋率說起，而覆蓋率偏偏是整個領域裡資訊量最低的一個數字。一個覆蓋率達到九十的程式碼庫，照樣可能在最常被走到的路徑上把缺陷送上線，因為覆蓋率量的是測試執行期間有哪些程式碼行被跑過，而不是有沒有針對這些行做出任何有意義的斷言。 真正信任自己測試套件的團隊，並不是覆蓋率百分比最高的那一群。他們是這樣的團隊：東西真的壞掉時測試會亮紅燈，其餘時候測試安安靜靜。這個特性，比多數人想像的更難用錢買到。 對任何一個測試都值得問的問題： 如果它失敗了，我知道該怎麼辦嗎？因為行為改變而失敗的測試，會告訴你一些事情。因為某個實作細節換了位置而失敗的測試，只能告訴你有人做了重構。這種失敗累積到一定數量，團隊就不再讀失敗訊息，...