Agentforce 按用量计费，仅这一点就应该改变你的预算方式。多数 Salesforce 买家带着席位许可的思维进场，问一个智能体每用户每月多少钱，然后拿到一个并不描述其账单的数字。账单取决于智能体执行了多少次动作，而这又取决于智能体设计得有多好，以及你的知识库有多好。 这让它在企业软件采购里显得不同寻常。智能体内部的设计决定就是账单上的条目。一步答完一个问题的智能体，成本只有磨过五步那种的五分之一，而许可条款不会告诉你自己造出来的是哪一种。你会从发票上知道答案，通常是在第三个月。 Agentforce 到底要花多少钱？ Salesforce 有两种计费方式。Flex Credits 是每 100,000 点 USD 500...
企业软件
关于企业软件的文章、指南和教程，为开发者和企业提供实用知识与技巧。涵盖范围、工作量与实际成本。
Salesforce 集成几乎从来不是败在协议上。认证是已经解决的问题，写入一条记录也是已经解决的问题。真正把项目拖垮的，是每天的请求配额和数据模型的形状，而这两件事通常要等到上线大约三周之后才被发现，那时夜间作业开始返回错误，却没有人说得清它在测试环境里为什么是好的。 这个模式一致到可以预测。开发者对着一个 Developer Edition 组织开发，一切通过，客户签字验收。随后这套代码遇上的，是一个已经住着营销连接器、数据仓库抽取作业和一个 2019 年就在跑的 Apex 触发器的生产组织，而那份看起来很宽裕的请求预算，其实是别人早已在花的一口共用的锅。 这篇文章把意外提前摊开来讲：你应该用哪个 API、配额是怎么算的、当你的...
可用性 SLA 看上去像一句承诺，实际运作起来却更像一份退款政策。供应商很清楚这一点。客户往往并不清楚，于是在签署服务级别协议时以为自己买到了可用性，而真正买到的，只是万一没拿到时的一点折扣。 这不一定是笔糟糕的交易。它只是与大多数人以为自己在签的那笔交易不同，而这个差别恰恰在系统宕机、有人追问合同究竟怎么写的那一刻显现出来。 三个九听上去接近完美，却允许每月 43 分钟的停机。 四个九允许四分钟。如果你的业务能吸收工作日下午 43 分钟的中断，99.9% 就足够了，不必为更高的数字付费。如果吸收不了，再多的九也帮不上忙，因为协议给你的是一笔积分，而不是阻止这次中断。 可用性 SLA 用分钟兑现的承诺百分比把一个非常大的区间压缩成看...
软件源代码托管，也就是把源代码交给中立的第三方保管（英文称为 software escrow），回应的是一种完全合理的担忧：为你构建并运维关键系统的供应商倒闭了，而你手上留下的，是一个自己离不开、却又维护不了的东西。托管协议把源代码存放在第三方那里，一旦真的发生这种情况，第三方就把它交付给你。 这种担忧是站得住脚的。问题在于这项工具经常被误解，而两者之间的落差催生出一类协议：每年都在花钱，真到需要它的那一天却帮不上忙。 签字之前应该先问的那个不舒服的问题： 如果明天就把代码交到你手上，你这边真的有人跑得起来吗？一份没有构建说明、没有基础设施定义、没有它所调用的第三方服务凭据、也没有数据的源代码托管，不是业务连续性方案。那只是一个文件...
在小团队里，灾难恢复通常只剩下一份从来没人打开过的文档里的一行字：备份已经开启。这句话本身没错，却算不上任何问题的答案，因为它既没有说明真正出事时找回来的数据会有多旧，也没有说明恢复一次要花多长时间，更没有说明到今天为止究竟有没有人完整地做过一次恢复。 拥有备份和真的能恢复之间存在一段明显的距离，大多数故障正是在这段距离里升级成事故。一份存在、内容也够新、却从来没有被还原过的备份，本质上仍然只是一个假设；而你第一次去验证这个假设的时刻，恰好是发现它其实是错的最糟糕的时刻。 两个数字能把意见变成计划。 你能承受丢多少数据，又能承受停多久？这就是你的恢复点目标和恢复时间目标。只要业务一侧没有人把这两个数字说出口，关于备份频率的一切技术争...
技术尽职调查不是一场代码质量比赛，而为它做准备的团队，往往把时间花在了完全不重要的地方。没有哪个买家是为了给你的抽象层打分才来收购公司的。买方想弄清楚的只有两件事：持有这套系统要花多少钱，以及在钱易手之后，事情可能糟糕到什么程度。 这个视角的转换很重要，因为它会改变你应该优先修哪里。丑陋但能跑、团队看得懂、可以安全修改的代码，只是一条轻微的发现。相反，写得优雅却只有一个人看得懂的代码，是一条严重的发现，而真正会让价格发生变化的，恰恰是后者。 所有问题背后的那个问题： 如果创始工程师在交割后的第二周离职，这套系统还能继续运行、并且继续被修改吗？几乎每一条压低报价的发现，都是对这个问题的具体回答。知识集中在一个人的脑子里、没有文档的部署...
金融科技软件开发在报价和排期上，和普通软件开发没有任何区别，直到有人问出那句话：到底谁有资格持有这笔钱。从那一刻起，项目就不再是一道工程题，而变成一道带着工程成分的监管题，你脑中原本的时间表也不再成立。 技术很少是难点。搬运资金是一个已经解决的问题，市场上有成熟的服务商、有文档齐全的接口，还有第一天就能用起来的测试环境。真正拖长金融科技项目的，是牌照上的身份、面向审计要拿得出的留痕义务，以及好几个架构决定其实早已由持牌方替你做完了。 决定你时间表的问题： 你自己持牌，还是以代理身份挂在别人的牌照下运营，抑或完全避开受监管业务？这三个答案会产生长度完全不同的项目，而差距是用等待的月数衡量的，不是用开发的周数衡量的。在做任何范围规划之...
企业级 SEO 代理机构在解的是与小企业代理不同的一类问题，而差别不是算术意义上的规模。一个大站很少是因为没人知道该修什么而失败。它失败是因为知道的那个人推不上线。 这正是提案里从不谈的部分。审计查出十二个问题，其中十一个需要改动某个模板、某个平台，或某支拥有自己路线图的团队所掌管的发布流程，十八个月后上线了四个。SEO 从来都不是瓶颈。 真正限制企业级 SEO 的： 是实施能力与组织归属，不是诊断。没人能部署的建议，价值等同于没有建议。合适的代理要按有多少条发现真的进了生产环境来评判，任何拒绝被这样衡量的代理，都是在卖文档给你。 为什么诊断是容易的那半在小站上，做 SEO 的人通常也有改动的权限。在大站上，一个标题标签可能由平台团...
企业 AI 智能体是一个熟悉故事的当下版本：一个十分钟就演示得很漂亮的原型，接着是六个月的努力，只为把它做到足够可靠、可以无人值守。几乎全部预算都消耗在这两种状态之间的距离里，而几乎没有任何营销材料描述这段距离。 智能体与聊天机器人有一处在商业上真正要紧的差别。聊天机器人产出文字，由人来决定拿它做什么。智能体则会采取行动：调用系统、写入记录、发送消息。这一转变把风险从尴尬变成了后果，也正因如此，所需的工程纪律更接近构建一套支付系统，而不是一件内容工具。 钱实际花在哪里： 模型是最便宜的部分。成本在工具集成、评测框架、护栏，以及交回给人的路径上。一个简单的内部智能体是 £5,000 到 £12,000，带检索的是 £12,000...
在英国做医疗软件开发，比其他任何行业的同等工作都更贵、更慢，原因并不是代码更难写。原因是预算中相当大的一部分花在证据而不是功能上：临床风险文档、信息治理，以及买方在还没试用产品之前就会索取的合规材料。 在别处做过软件的团队一直低估这一点。他们给应用报价、拿下项目，然后才发现合规这一层不是收尾阶段，而是必须从第一天就开始的并行工作流，因为它会约束那些日后修改代价高昂的架构决策。 真正推高成本的东西： 一个英国医疗项目大约四分之一到三分之一的预算花在临床安全、信息治理和合规证据上，而不是功能。决定性的问题不是你的应用有多复杂，而是它是否接触患者数据、是否影响临床决策、以及买方是不是 NHS。每一项都会各自增加一条独立且无法省略的工作流。...