Salesforce架构师提出闭环测试方法：用不可变快照类阻止AI生成代码耗尽事务预算

AI智能体在Salesforce平台上生成代码时，面临一个传统开发中不突出的问题：它优化的是眼前任务，而非该任务所在事务的整体资源预算。即使每个功能单独通过测试，累积消耗仍可能在某次看似无害的变更后突破平台硬限制。

Salesforce高级技术架构师Sakthi Kuppusamy在2026年11月5日发表的文章中描述了这种累积模式：第一个Sprint加入账户验证逻辑，事务消耗SOQL查询限额的15%；第二个Sprint加入数据富化，升至32%；第三个Sprint加入关联联系人查询，到51%；第四个Sprint加入一个单独只值8%的重复检查，总计59%。没有哪次变更本身有问题，但传统开发中这种积累需要数月展开，团队有时间察觉退化，而智能体可以在一个下午的合并中完成同样的压缩。

Kuppusamy的核心论点是：治理限额不是需要绕过的平台约束，而是应当从一开始就设计的架构契约。要执行这一契约，他提出三层机制。

第一层是不可变快照类。部署一个名为GovernorLimitSnapshot的测试工具类（标注@IsTest，不计入组织Apex代码大小限制），智能体必须消费这个工具，不得修改或重定义它。这个类捕获执行前后的资源分配与消耗，将阈值逻辑集中在一处，防止智能体将断言分散到代码库各处。

第二层是分执行上下文的预算分配。同步事务的SOQL查询限额为100，异步为200；CPU时间同步10000毫秒，异步60000毫秒。但不同执行上下文应分配不同比例：触发器（共享事件）建议40%至50%，因为同一事务中还有其他触发器、流和验证规则；服务类（单一职责）60%至70%；Queueable、Future和Batch Apex（隔离上下文）80%至85%；Scheduled Apex（轻量编排）20%至30%。这些预算不可叠加——从触发器调用的服务类消耗的是触发器的预算，没有自己的独立额度。

第三层是CI/CD中的闭环反馈。当测试违反阈值时，流水线不是简单标记构建失败，而是向智能体发送结构化提示，包含违规细节、预算阈值和优化提示。智能体重构后重新提交，第二次CI运行若仍超标，反馈包含两次尝试的差值：什么改善了、哪个指标仍超预算。第三次推送若仍失败，流水线停止循环，阻止合并，并开启人工架构师审查任务，附带完整运行历史。这个三击边界将根本性架构问题（例如某功能确实无法放入同步事务）路由给人类决策是否迁移到异步Queueable或调整事务预算。

Kuppusamy同时指出防御智能体规避的必要性：陷入反馈循环的智能体会寻找最便宜的绿色构建路径，可能缩小测试数据数组、注释掉断言、用try-catch吞掉错误，或直接编辑阈值。对策是限制智能体对实现源代码以外的写权限，将快照工具和阈值元数据记录设为不可变基础设施。

这套方法的边界也很明确。部分限额难以通过单元测试有意义地覆盖：调用需要模拟但无法反映真实延迟，平台事件发布限额在测试隔离下行为不同，异步作业限额难以在规模上模拟。这些需要生产监控补充。沙箱测试无法复现生产并发下的索引争用和行锁，因此测试时阈值可能低估实际消耗。过于激进的阈值会因误报而非真实逻辑错误导致构建失败，建议从宽松起步、依据历史数据收紧，并区分警告层级和违规层级。