在模型运行之前
用户提供提示词和一个别名，如 cheap、fast 或 smart。生产服务端在接受任务之前检查认证、工作区归属与权限。供应商模型 ID 与密钥留在这条边界之后——友好的别名是客户端唯一需要的模型词汇，因为到真实供应商模型的映射是配置，而不是契约。
持久的任务记录在后台执行开始前就给请求一个身份。这个身份把提交、worker、用量记录与结果串起来，也让用户在离开页面后能找回这项工作。
顺序很重要：昂贵的工作只在便宜的检查通过之后才开始。在任何任务入队之前先验证认证、归属与权限，能让未认证或未付费的请求永远到不了供应商——也让失败对用户可解释。AI 模块指南记录了这些检查住在哪里；工作区边界一文解释了为什么归属在服务端推导，而不是信任客户端。
决定用谁的密钥、谁的上限
AI 功能是一个花钱的决定。supastack 允许工作区自带供应商密钥——加密存储、绝不暴露给客户端——或跑在平台密钥上，并按模型价格目录执行每个工作区的预算。无论你怎么实现，问题都一样：谁付钱，上限在哪里执行？
执行属于服务端工作流，而不是浏览器侧的估算。生成之后才检查的预算只是记录超支；派发之前检查才能阻止超支。供应商密钥设置讲了配置那一侧。
让执行显式化
Trigger.dev 运行 ai.generate 工作流。能力感知路由器根据已配置策略与请求要求选择模型。把该策略当作运维输入：不可用的别名不应在界面上显示为可用选项。
提交过程中的网络故障会让客户端不确定任务是否已入队。生产路径使用任务级幂等键与已保存的提交，使恢复可以复用原始请求。每次超时后都新建任务，会有重复工作与重复扣费的风险。
持久性也是让界面保持简单的东西：界面读取任务状态并渲染，而不是编排重试。当生成跨模型调用、工具步骤或调度时，显式的工作流契约——enqueue、status、cancel——才是让“进行中”保持诚实的机制。
给失败模式点名
在请求与结果之间，会出错的是一个具体而有限的集合。按名字逐个设计，而不是为笼统的“错误”设计——每个任务都应该落到可解释的状态：已入队、运行中、带原因的失败、或带结果的完成。任务恢复是套件在恢复一侧的参考。
底下对界面的要求是：任何状态都不能撒谎。比工作活得更久的转圈，或是为从未运行的任务亮出的成功消息，都是一张等着发生的客服工单和计费纠纷。
- 提交超时——通过已保存的提交与任务级幂等键恢复，而不是重新入队。
- 供应商在任务中途失败——把任务标记为失败，并给出界面能展示的原因。
- 预算耗尽——在派发之前拒绝，而不是在花完之后。
- 用户离开了页面——持久记录与恢复 URL 能找回状态和结果。
追踪发生了什么
生成产生的不只是文本。应用会记录用量与任务结果，界面通过已认证的 API 读取状态。正是用量记录让预算可以执行——它在结果返回之前写入，而不是事后估算。
完成邮件是独立的步骤，有独立的投递记录。模型响应成功并不能证明邮件已送达。把这些结果分开，让失败更容易解释与重试，而不必无谓地重跑模型。
结果还需要一个用户可以回访的家：任务页、历史列表、或随完成邮件送达的恢复 URL。只存在于转瞬即逝的通知里的生成，是你迟早被要求再做一遍的工作。
验证每一条边界
先用确定性的 fake 适配器测试应用的决策：拒绝访问、禁用别名、重复提交、结果恢复与通用错误。这些测试应在没有供应商凭证的情况下运行。
然后使用明确 opt-in 的供应商冒烟流程验证真实集成。它要求文档化的沙箱配置以及对外调用的批准。这种区分让日常开发保持快速，也让生产证据具体且可追溯。
产品变化时保持这种划分稳定：在每个边界决定附近都有确定性覆盖，这样换供应商、改路由策略或新增别名只会让测试失败，而不是让客户失败。
关于 SaaS 中 AI 功能的常见问题
每次谈到把 AI 放到付费墙后面，总会冒出这几个问题。
- AI 功能的授权应该放在哪里？ —— 在任何任务入队之前：认证、解析工作区、检查权益，然后才创建任务。生成之后才跑的检查只是在给滥用做记录。
- 我需要支持 BYOK 吗？ —— 如果你的客户有自己的供应商关系，就需要：它决定谁付钱、谁拥有速率上限。密钥要加密存储、远离客户端——AI 配置指南讲了这个模型。
- 怎么防止重试造成重复计费？ —— 把幂等键限定在任务上，并在恢复时复用已保存的提交，这样一次超时就造不出第二次计费运行。
- 应该记录哪些用量数据？ —— 按任务记录：模型、消耗的单位、对照价格目录算出的成本，以及所属工作区——足够执行预算、也足够回答支出问题，而无需重跑任务。
- 什么时候生成该放进后台任务？ —— 只要它可能比一次请求活得久。模型延迟、重试和多步工作都要求持久执行；只有即时且便宜的调用才适合内联。