能不能只做 UI，能力用第三方？

结论：可以大量使用第三方能力，但正式产品通常不能只做 UI。至少要有受控业务后端负责登录、权限、订单状态、密钥、计费、审计和异常兜底；支付、短信、地图、模型等非核心能力再通过适配层接入。

“只做 UI”适合无真实账号和交易的演示原型，或第三方产品本身已经提供完整后端、客户只是进行品牌配置的场景。只要系统包含用户数据、订单、支付、会员权益、企业知识或设备控制，让浏览器/App 直接调用所有第三方，就会暴露密钥、难以统一权限，也无法在供应商超时、重复回调、价格变化或停服时保护业务状态。

在继续拆分功能、数据与验收场景时，还可以对照 能不能给我留一个自己也能改的配置后台，而不是每次小改动都得找你们？；这些内容补充了需要放在同一项决策中考虑的上下文。

三种建设方式的边界如下：

方式	自己掌握什么	优点	主要风险	适用结论
纯 UI + 第三方完整后端	页面、品牌和少量配置	上线最快	数据模型、路线和迁出受制于平台	原型或白标产品可用
自有 UI + 业务后端 + 第三方能力	用户、权限、流程、数据和供应商适配	速度与控制较平衡	仍需维护集成和账单	多数生产产品优先
核心能力自研、非核心采购	差异化算法或业务引擎也自有	路线和数据控制最强	研发、合规和运维投入最高	核心能力确实形成竞争力时采用

适合采购的通常是已经标准化、受监管或规模效应明显的能力，例如支付通道、短信邮件、地图、对象存储、CDN、推送、音视频、OCR 和模型推理。自研这些基础设施很少带来客户可感知差异。应自己掌握的是账户与组织关系、权限、核心业务事实、定价和权益、审核规则、客户数据、供应商选择逻辑以及跨服务的异常处理。

后端最重要的作用是隐藏密钥和统一信任边界。客户端只拿短期用户令牌，请求业务后端；后端检查租户、角色、对象和额度，再调用第三方。支付回调校验签名并幂等落账，模型调用去除无关个人信息，短信限制频率和模板，地图密钥按域名或应用签名限制。把永久 API key 写进 Web、App 或小程序包，即使代码混淆也能被提取。

每项第三方先制作能力与退出卡片：服务内容、地区、数据是否保存或训练、子处理方、SLA、限流、单价、最低消费、账号主体、许可证、故障通知、数据导出、停服和替代方案。开源组件则记录版本与许可证，可用 SPDX 许可证清单 标准化标识。合同和技术清单都要更新，不能只在代码中留一个 SDK 名称。

并非所有能力都值得同时接两家。多供应商抽象层适合支付路由、短信、存储或关键模型等高影响服务，但如果两个供应商语义差别大，追求“随时一键切换”会制造最低公分母和双倍测试。先确定恢复目标与可接受停机：低风险地图搜索可以等待原厂恢复，高峰交易短信可能需要备用通道，核心数据存储则要有独立备份和迁出演练。

接口适配层把第三方请求响应转换为内部稳定模型，并保存供应商请求 ID、版本、耗时、费用和错误类别。可用 OpenAPI 规范 描述内部合同，供应商升级或替换时不让变化扩散到全部页面。超时必须明确“未知、失败或成功”，不能盲目重试造成重复扣款；队列、熔断、缓存与人工兜底按业务风险选择，而不是所有接口套同一策略。

预算应按三年用量分段测算。低用量时 API 最便宜，用户和调用增长后，按次费用可能超过自建或包量；还要计算网络、存储、人工复核、技术支持和平台渠道费用。滚水科技会把第三方费用与研发费分开，并在客户主体账号下开通核心服务，避免续费和迁移依赖我方。相关资产交付原则可查看 透明交付标准。

验收覆盖正常调用、权限不足、限流、超时、重复回调、供应商返回脏数据、余额不足和服务中断，确认 UI 给出可理解状态、业务数据不重复、日志可定位且能够切回人工。供应商营销页只能证明宣称能力，最终仍要用客户地区、账号套餐和真实样本测试。

滚水科技可以按“自有业务内核 + 合理采购能力”交付，而不会为了增加研发额强推全部自研。