AI 智能体支付在大约一年之内产生了四份彼此竞争的规范、两个行业基金会，以及海量的报道。它还没有为绝大多数商家产生的，是收入。噪音与数字之间的落差才是值得理解的部分，因为兴奋的报道和轻蔑的报道都以让人赔钱的方式弄错了。 确实有真东西正在被建造。Google、OpenAI、Stripe、Coinbase、Shopify、Visa 和 Mastercard 都在这个领域交付了规范或产品，其中两份规范如今归属于中立的基金会，而不是单一厂商。其中一部分已经在生产环境中运行。但生产环境里的大部分流量，是机器向另一台机器购买 API 调用，而不是购物助手向你买一张沙发。 本文把已经交付的东西与只是挂了一排徽标的规范区分开，说明你的结账流程和风控...
自动化
关于自动化的文章、指南和教程，为开发者和企业提供实用知识与技巧。并附真实项目中的具体案例。
Agentforce 按用量计费，仅这一点就应该改变你的预算方式。多数 Salesforce 买家带着席位许可的思维进场，问一个智能体每用户每月多少钱，然后拿到一个并不描述其账单的数字。账单取决于智能体执行了多少次动作，而这又取决于智能体设计得有多好，以及你的知识库有多好。 这让它在企业软件采购里显得不同寻常。智能体内部的设计决定就是账单上的条目。一步答完一个问题的智能体，成本只有磨过五步那种的五分之一，而许可条款不会告诉你自己造出来的是哪一种。你会从发票上知道答案，通常是在第三个月。 Agentforce 到底要花多少钱？ Salesforce 有两种计费方式。Flex Credits 是每 100,000 点 USD 500...
Salesforce 集成几乎从来不是败在协议上。认证是已经解决的问题，写入一条记录也是已经解决的问题。真正把项目拖垮的，是每天的请求配额和数据模型的形状，而这两件事通常要等到上线大约三周之后才被发现，那时夜间作业开始返回错误，却没有人说得清它在测试环境里为什么是好的。 这个模式一致到可以预测。开发者对着一个 Developer Edition 组织开发，一切通过，客户签字验收。随后这套代码遇上的，是一个已经住着营销连接器、数据仓库抽取作业和一个 2019 年就在跑的 Apex 触发器的生产组织，而那份看起来很宽裕的请求预算，其实是别人早已在花的一口共用的锅。 这篇文章把意外提前摊开来讲：你应该用哪个 API、配额是怎么算的、当你的...
故障复盘很容易开起来，很难做得有用。会开了，文档写了，四条改进项记下来了，六个月后同一个故障又发生一次，而某个人正好在找别的东西时翻出了那份旧文档。 在讨论这件事时，注意力几乎都落在"无指责"这个词上。这条原则确实重要，但失效的地方并不在那里。有大量组织把无指责执行得一丝不苟，复盘却什么也没有改变，原因很简单：他们把复盘本身当成了交付物，而不是当成产出交付物的手段。 判断你们的复盘是否有效，有一个简单到让人难堪的测试：过去六个月记录下来的改进项，实际完成的比例是多少？ 如果答案是"大部分"，那么无论流程长什么样，它都在起作用。如果低于一半，你们是在开会而不是在运行一个流程，换更漂亮的模板也救不了。少数几条带负责人和期限的事项，胜过一...
软件供应链安全听上去像是那些设有专职安全团队的大机构才需要操心的事，而正是这种定位把人带偏了。一个只维护少数几个服务的小团队，通常也依赖着几百个包，其中没有一个是团队里有人真正读过的。这些包在构建时从团队并不掌控的包仓库里拉取，然后在存放着部署凭据的机器上执行安装脚本。 暴露面并不随公司规模等比增长。它随依赖数量和构建自动化程度增长，而小团队往往前者更多、后者更少有人盯着，处境比那些公开讨论这件事的大机构还要吃紧一些。 令人不适的算术： 你的应用大概有十几个直接依赖，以及几百个间接依赖。这十几个是你自己挑的。剩下的不是，你一个都没读过，而其中任何一个只要执行安装脚本，拿到的权限就和你的构建进程完全一样。这才是真实的攻击面，而在你亲手...
技术文档的失败方式非常具体，也非常好预测。有人在两周清闲的时间里写下一大堆，接着系统变了，没有人回头更新，一年之内那份文档就开始信心十足地讲着错误的内容。到了那个时候，它比什么都没有还要糟，因为相信它的读者会依据早已不成立的信息去动手。 常见的反应是号召大家多写一些，而这只会让同样的失败来得更快。有用的反应是少写，并且认真挑选写什么，因为真正的瓶颈不是写作的工夫，而是维护的工夫。文档从写完那一刻起，就开始被现实甩在后面。 判断一份文档该不该存在，唯一经得起时间的检验是： 当它变错的时候，会不会有人察觉？部署指南天天有人用，错误立刻就会浮出来。一份二十页的子系统说明只会被读一次，它的错误要等到十八个月后，有人照着它动手时才浮出来。没有...
开发者入职通常是按入职培训花了几天来衡量的，而那是问题的另一头。真正重要的数字是另一个：一个新来的工程师要过多久，才能改动某个东西，并且有把握自己没有弄坏别的地方。在大多数团队里，这个数字是以月计的，而不是以天计的。 延迟很少出在人身上。它出在系统里有多少部分只存在于别人的脑子里，以及前两周里有多大一部分时间，是靠一次次打断别人，一点一点把这些东西挖出来的。 唯一值得追踪的指标：从入职到他们的第一次改动进入生产环境，需要多久。 不是第一次提交，提交可以只是改一个错别字，而是一次有意义并且真正上线的改动。如果这个时间超过一周，障碍几乎从来都不是能力。而是一份最近没有人从零走过一遍的环境搭建流程，或者一份没有人带路就找不到入口的代码库。...
可用性 SLA 看上去像一句承诺，实际运作起来却更像一份退款政策。供应商很清楚这一点。客户往往并不清楚，于是在签署服务级别协议时以为自己买到了可用性，而真正买到的，只是万一没拿到时的一点折扣。 这不一定是笔糟糕的交易。它只是与大多数人以为自己在签的那笔交易不同，而这个差别恰恰在系统宕机、有人追问合同究竟怎么写的那一刻显现出来。 三个九听上去接近完美，却允许每月 43 分钟的停机。 四个九允许四分钟。如果你的业务能吸收工作日下午 43 分钟的中断，99.9% 就足够了，不必为更高的数字付费。如果吸收不了，再多的九也帮不上忙，因为协议给你的是一笔积分，而不是阻止这次中断。 可用性 SLA 用分钟兑现的承诺百分比把一个非常大的区间压缩成看...
在小团队里，灾难恢复通常只剩下一份从来没人打开过的文档里的一行字：备份已经开启。这句话本身没错，却算不上任何问题的答案，因为它既没有说明真正出事时找回来的数据会有多旧，也没有说明恢复一次要花多长时间，更没有说明到今天为止究竟有没有人完整地做过一次恢复。 拥有备份和真的能恢复之间存在一段明显的距离，大多数故障正是在这段距离里升级成事故。一份存在、内容也够新、却从来没有被还原过的备份，本质上仍然只是一个假设；而你第一次去验证这个假设的时刻，恰好是发现它其实是错的最糟糕的时刻。 两个数字能把意见变成计划。 你能承受丢多少数据，又能承受停多久？这就是你的恢复点目标和恢复时间目标。只要业务一侧没有人把这两个数字说出口，关于备份频率的一切技术争...
人们谈论软件测试策略时，几乎总是从覆盖率讲起，而覆盖率恰恰是整个领域里信息量最低的一个数字。一个覆盖率达到九十的代码库，照样可能在最常被走到的路径上把缺陷送进生产环境，因为覆盖率衡量的是测试运行期间哪些代码行被执行过，而不是有没有针对这些行做出任何有意义的断言。 真正信任自己测试套件的团队，并不是覆盖率百分比最高的那一批。他们是这样一群人：当东西真的坏了，测试会红；其余时候，测试保持安静。这个性质比大多数人想象的更难用钱买到。 对任何一个测试都值得问的问题： 如果它失败了，我知道该怎么办吗？因为行为改变而失败的测试，会告诉你一些东西。因为某个实现细节挪了位置而失败的测试，只能告诉你有人做了重构。这样的失败积累到一定数量，团队就不再阅...