给创空间施一场“收款魔法”：ModelScope创空间 × 支付宝接入实战

魔搭ModelScope社区

7人浏览 · 2026-08-10 10:48:25

魔搭ModelScope社区 · 2026-08-10 10:48:25 发布

博格特（Boggart）是《哈利·波特》魔法世界中一种非常独特的、能够变形的非存在生物。博格特没有固定的形态。当你面对它时，它会瞬间读取你内心的想法，并立刻变成你最害怕的事物。它总是在遇到人的瞬间就完成变形，所以魔法界至今没有人知道博格特不被任何人观察时究竟是什么样子。它们喜欢黑暗、封闭的空间，经常躲在衣橱、床底、老式落地钟或阴暗的橱柜里。巫师在面对它时，需要使用滑稽咒（Riddikulus，咒语发音为“滑稽滑稽”）。施咒的诀窍在于，你不仅要念出咒语，还必须在脑海中强迫自己把你最害怕的东西，想象成一个极其搞笑、荒诞的形象。当博格特变成这种滑稽的模样时，人们的大笑会彻底击溃它，让它化作一缕青烟消失。

这段时间，我在ModelScope创空间上线了一堂黑魔法防御术体验课。

旧衣柜的门开始震动，进入教室并完成课堂点名之后，同学们需要回答五道情境题，这些答案将成为博格特显形的参考。紧接着，柜门打开，博格特显形在羊皮纸上。用户可以购买价格为 ¥0.01 的“Riddikulus”咒语体验卡。魔杖轨迹划过屏幕，博格特随咒语发生反转，变成一副滑稽的模样。施咒结束后，用户还可以保存一张记录本次体验的课堂档案卡。

为了让这堂体验课具备完整的付费流程，我接入了支付宝网站支付，完成了产品签约、Web App上线和生产环境付款验证。整套服务运行在ModelScope创空间中。

本项目源于支付宝推出的“AI付”能力。我想要通过一个完整的小项目，验证ModelScope创空间能否承载AI Web应用的付费业务，并顺利完成支付宝“AI付”的接入。最终跑通的体验流程表明，部署在创空间中的应用可以完成从创建订单、跳转收银台、确认支付到解锁生成结果的完整流程。

创空间选型

ModelScope创空间支持Gradio/Streamlit/Static/Docker四种部署方式，在前期设计的时候，我根据应用的实际需求并结合支付宝支付的实际需求进行了测试，最终选定了Docker形式来部署。

在初始设计中，“Boggart实践课”是一个接入了语言模型API和多模态模型API的应用，在简单整理需求之后，得到了这些信息。

完全自定义的 React 视觉界面和交互动画
服务端保存应用私钥、支付宝公钥等敏感配置。
创建订单、查询订单和处理支付结果
提供一个无需登录的公网支付宝异步通知地址
接收支付宝的表单 POST 请求，并原样返回纯文本success
调用 ModelScope API Inference
保存订单、支付状态和用户生成结果
对支付通知做验签、幂等和防重复处理

在简单评估后，首先排除了Static和Streamlit。Static只适合托管前端文件，对于支付宝私钥等内容无法安全保存。也不能提供支付回调、订单数据库和服务端推理接口。Streamlit理论上可以在外围增加支付服务，但是会使项目形成两套运行逻辑，且不利于定制化的视觉体验。所以第一轮先把范围划定在了Gradio和Docker。

Gradio最初是重点候选方案，实测时，我在Gradio应用外挂载了FastAPI，并增加了一个支付宝回调测试接口。本地运行正常，但部署到Gradio创空间后，平台会接管启动入口和对外端口，导致自定义 FastAPI 路由无法稳定暴露。也就是说，当支付宝访问POST /api/payments/alipay/notify时，请求不一定会进入 FastAPI 回调接口。对于需要接入支付宝的项目，支付宝异步通知是服务端确认支付结果的核心依据之一，不能依赖不确定的路由行为。

接下来改用Docker测试，让 FastAPI 独立监听创空间规定的0.0.0.0:7860。实测确认公网可以匿名访问自定义接口、接收表单POST，并正确返回纯文本success，同时可以读取Secrets。

所以最终验证过后，Docker是能够同时满足高保真前端和支付宝公网回调要求的可行部署方式。

应用场景设计

在设计实际应用场景时，我想通过一个实际应用的开发，来验证平台能力。因此，我将支付嵌入了“博格特实践课”的完整体验中，并采用“免费显形、付费反转”的设计。

用户进入应用后，首先完成课堂点名，并回答五道与恐惧有关的情境题。完成测试后，应用会根据答案判断用户的恐惧原型，并调用模型生成一份专属的博格特记录和对应插画。例如，博格特可能显形为不断逼近的考试钟、无法打开的吼叫信、被乌云遮住的满月，或者一扇永远无法逃离的门。第一次博格特显形是免费的。用户可以看到自己的博格特形态、危险等级和一段简短的课堂记录。博格特显形后，用户可以点击 RIDDIKULUS，从四种方式中选择一种反转方法。选择完成后，应用才会展示 ¥0.01 的支付入口。支付成功后，用户获得一次完整的施咒体验，包括魔杖轨迹、咒语命中特效、博格特的荒诞反转插画，以及一张可以保存和分享的课堂档案卡。

这个付费点被设置在体验的情绪转折处。在支付之前，用户已经完成测试并看到了自己的博格特，对最终如何反转这个形象产生了好奇；支付之后获得的是施咒动画、反转结果和课堂档案组成的完整结局。因此，用户购买的实际商品可以被定义为：一次 Riddikulus 个性化内容生成与互动体验服务。“咒语体验卡”是应用世界观中的包装，真实交付内容则是一次付费解锁的AI个性化生成服务。

应用搭建

完成应用场景和付费边界设计后，接下来先搭建不包含支付的基础应用。

前端负责欢迎页、课堂点名、情境题、博格特显形、支付和课堂档案等页面；后端负责保存会话、计算恐惧原型、调用模型以及管理生成任务。用户完成五道情境题后，服务端首先根据固定规则计算恐惧原型，再调用语言模型生成博格特档案，最后调用图像模型生成显形插画。模型调用全部由后端发起，ModelScope Token 通过环境变量配置。生成任务和结果同时保存到数据库，用户刷新页面后仍能恢复进度。

简要项目结构

boggart-practical/
├── app/                         # React 前端页面
│   ├── checkout/                # 支付确认页
│   ├── payment/                 # 收银台与同步回跳页
│   ├── reveal/                  # 博格特显形与施咒入口
│   └── report/                  # 课堂档案与结果保存
├── server/
│   ├── app/
│   │   ├── main.py              # 订单、查单、回调与权益接口
│   │   ├── alipay_payments.py   # 支付宝下单、验签和交易查询
│   │   ├── modelscope.py        # 文本与图像模型调用
│   │   ├── models.py            # 订单、通知、权益和生成记录
│   │   └── database.py          # PostgreSQL 数据库连接
│   └── migrations/              # Alembic 数据库迁移
├── deployment/
│   ├── nginx.conf               # 统一入口与请求转发
│   ├── supervisord.conf         # 管理前端、API 和 Nginx
│   └── start-api.sh             # 执行迁移并启动 FastAPI
├── Dockerfile                   # ModelScope 创空间构建入口
└── .env                         # 环境变量示例

系统部署结构如下：

Nginx 对外监听 7860 端口。页面请求转发到 Vinext，/api/* 与 /generated/* 转发到 FastAPI。Supervisor 管理前端、API 和 Nginx。容器启动时先执行 Alembic 数据库迁移，再启动 API 服务。文本模型使用 Qwen/Qwen3.5-35B-A3B，负责生成博格特档案、施咒方案和图片提示词。图片模型使用 Tongyi-MAI/Z-Image，负责第一次显形和第二次反转插画。模型通过 API 调用，创空间使用免费 CPU 运行 Web 服务。

这里的模型服务使用了ModelScope的API-Inference服务，对于这个小型demo，社区每天的免费额度已经够用了，所以我暂时没有采用其他额外的API。使用也很简单，只需要在创空间部署的环境变量中配置模型名称，modelscope token即可。

完成这一部分后，应用已经能够跑通从课堂点名、情境测试到博格特免费显形的基础流程。接下来只需要在博格特显形与 Riddikulus 反转之间接入支付宝支付。

使用支付宝AI付SKILL接入网站支付

支付宝“AI付”是一组面向AI应用、开发者工具和智能体场景的支付产品及接入工具。它通过 AI-Friendly 文档、Skill、SDK 和沙箱环境，帮助开发者更快完成支付代码集成。https://aipay.alipay.com/ 包含了AI 移动应用收款、AI 网页应用收款、AI 订阅、AI 按量付费等收款产品和Agent 支付作为付款产品。“博格特实践课”运行在ModelScope创空间中，属于浏览器访问的 Web 应用；用户购买的是一次 ¥0.01 的个性化内容生成服务，所以本项目选择了“AI网页应用收款”Skill，帮助在我的AI应用中接入支付宝网站支付接口。

在项目开发环境中执行

npx -y @alipay/alipay-aipay@latest install
#通过该命令，安装支付宝AI付Skill，加载alipay-aipay技能为我的项目集成网站支付，完成沙箱测试，并完成签约入驻

安装完成后可以向AI编程工具提出接入需求，SKILL会根据现有项目结构，协助完成支付部分的代码。

AI付Skill 会限制AI编程工具可以执行的范围，在明确的产品、安全和流程边界内，帮助开发者正确地完成支付集成。下一步还需要在支付宝侧完成产品签约和应用配置。

沙箱配置与初步验证

支付代码接入完成后，AI付Skill会自动创建或获取沙箱配置，并将沙箱应用信息写入受保护的配置文件。开发者只需启动应用，并使用沙箱买家账号完成测试付款。付款完成后，再由AI检查交易查询结果、订单状态和权益发放是否正确。

支付宝沙箱会提供独立的买家测试账号、登录密码和支付密码。我按照提示下载并打开支付宝沙箱 App，使用沙箱买家账号登录。沙箱账号与自己的正式支付宝账号相互隔离，不会产生真实资金交易。在这个过程中，我在本地启动了“博格特实践课”，完成了应用流程直到支付界面，接着点击“支付 ¥0.01”打开了沙箱收银台。使用沙箱买家账号和密码确认付款，付款完成后返回本地应用。

这个沙箱测试的步骤，是AI无法帮助我完成的，不过在沙箱支付完成之后，可以直接让AI帮我查询交易接口检查支付宝侧的订单状态。

经过简单的本地沙箱测试，整个过程已完成初步验证。不过因为本地环境没有HTTPS地址，支付宝还无法向本地服务发送异步通知，接下来可以把应用部署到ModelScope创空间，再进行后续的测试。

创空间部署

ModelScope提供了一个官方的创空间部署Skill，链接如下https://modelscope.cn/skills/modelscope/modelscope-studio。因为在开发之前，我们已经完成了测试与部署方式的选择，所以在部署环节，准备好ModelScope Access Token，并在本地配置export MODELSCOPE_API_TOKEN=你的ModelScope_Access_Token，就可以向AI编程工具提出部署要求。

加载modelscope-studio，将当前项目部署到ModelScope创空间。命名为Boggart
使用Docker类型，先创建为私有空间，并检查构建和运行日志。

获得授权后，Skill会分析项目结构，获取ModelScope用户信息，创建或关联已有创空间，并且自动通过Git同步代码，自动触发Docker构建和部署。

部署完成后，应用获得了 HTTPS 访问地址，可供开发者检查页面和接口。我将创空间临时设为公开，并通过 Secrets 配置支付宝沙箱参数。相比本地测试，这次将 return_url 和 notify_url 都替换为创空间的公网 HTTPS 地址。

https://<创空间域名>/payment/return
https://<创空间域名>/api/payments/alipay/notify

随后，我再次创建了一笔 ¥0.01 沙箱订单，并使用沙箱买家账号完成付款。通过创空间日志可以确认，支付宝服务器成功访问了异步通知接口，服务端完成 RSA2 验签、订单号与金额校验，将订单从 PENDING 更新为 PAID，发放了一次施咒权益，并向支付宝返回纯文本 success。重复查询和重复通知都是正常状态，主动查单也可以在通知延迟时补偿订单状态。至此，下单、付款、异步通知和权益发放组成的沙箱完整链路验证通过。

产品签约与应用上线

沙箱支付和创空间部署完成之后，下一步最重要的是开通正式网站支付。网站支付签约与 WEBAPP 上线可以并行推进。签约申请提交后，无需等待审核生效，即可继续创建应用、配置应用公钥并提交应用审核。

7.1 确认产品与经营类目

AI付 Skill 会先查询：当前账号是否已经签约网站支付；是否存在可以复用的 WEBAPP；已有应用是否已经上线。在选定产品和经营类目之后，需要由商家本人确认并提交。

7.2 产品签约

网站支付产品签约需要提供三张截图：应用首页，数字内容展示页包含商品名称，支付金额和支付宝支付按钮的待付款页。这里需要确保截图应来自完整、正常运行的应用，不能出现沙箱标识、测试账号、报错信息、localhost 或任何密钥。可以直接提交给AI，skill会检查文件、上传截图并且提交网站支付签约申请

7.3 账号授权

涉及商家账号查询和签约提交时，Skill 会生成经过校验的支付宝官方授权页面。作为开发者，我们需要打开官方授权链接并且使用支付宝扫码，同时检查授权范围和经营类目并且本人确认授权。

7.4 创建WEBAPP并配置密钥

产品签约之外，还需要创建或复用一个 WEBAPP，并取得正式环境的 APP_ID。随后使用支付宝官方密钥工具生成 RSA2 2048 位密钥：应用公钥：提交到支付宝；应用私钥：保存在自己的服务端；支付宝公钥：用于验证支付宝返回的签名。开发者只需要向 Skill 提供应用公钥，再通过支付宝官方页面扫码确认。公钥生效后，Skill 可以继续提交 WEBAPP 应用审核。

7.5 确认签约与上线状态

申请提交后需等待两个状态生效，网站支付签约生效并且WEBAPP状态变为ON_LINE，就可以开始配置生产环境并发起真实交易了。

网站支付签约：已生效
WEBAPP 应用状态：ON_LINE

在整个过程中，AI付Skill负责流程引导、状态查询、材料上传和申请提交；商家本人负责授权确认、材料真实性、生产密钥生成和私钥保管。下一步就是把创空间中的沙箱配置替换为生产配置，并完成真实的付款验证。

7.6 AI 与开发者的职责边界

在这个流程中

AI可以帮助完成：创建并保护沙箱配置、启动应用、检查支付入口、查询支付宝交易状态、检查本地订单与权益、分析回调日志

开发者本人需要完成：使用沙箱买家账号登录、确认付款、处理浏览器或沙箱App的交互、判断实际页面体验是否正常

正式生产环境

状态生效后，就可以把创空间从测试配置切换到支付宝生产环境了。

需要配置创空间密钥

PAYMENT_MODE=alipay
ALLOW_MOCK_PAYMENT=false

ALIPAY_APP_ID=正式WEBAPP的APP_ID
ALIPAY_PRIVATE_KEY=应用私钥
ALIPAY_PUBLIC_KEY=支付宝RSA2公钥
ALIPAY_SELLER_ID=商户PID

ALIPAY_GATEWAY=https://openapi.alipay.com/gateway.do
PUBLIC_BASE_URL=https://创空间公网域名
ALIPAY_RETURN_URL=https://创空间公网域名/payment/return
ALIPAY_NOTIFY_URL=https://创空间公网域名/api/payments/alipay/notify

APP_ID、应用私钥和支付宝公钥须对应同一个正式应用，SELLER_ID属于签约商户。完成上线之后，就可以重新部署创空间了。

这里需要注意因为私有创空间无法接收支付宝异步通知，所以正式收款前需要将创空间设置为公开。全部设置完之后，我以普通用户的身份完成了一次生产环境的付款。在支付宝的商家账单中也能够查询到对应的记录。

此外，完成第一次生产环境的付款之后，我继续向AI发出了协助查询创空间日志、数据库、订单状态的需求。确认了以下流程顺利跑通。同时重复发送通知或查询订单，确认同一笔交易不会重复更新订单，也不会重复发放权益。

支付宝完成付款

→ 创空间收到异步通知
→ RSA2 验签通过
→ 订单金额与商户信息一致
→ 本地订单更新为 PAID
→ 发放一次施咒权益
→ 返回纯文本 success
→ 用户完成反转生成
→ 权益更新为 CONSUMED

至此，“博格特实践课”完成了从 ModelScope 创空间部署、支付宝网站支付接入，到真实 ¥0.01 收款和AI内容解锁的完整流程。

总结

这个小项目的构思、选型、接入模型选择、接入支付等整个流程蹚下来之后，我最惊喜的发现是使用 ModelScope创空间、ModelScope API-Inference、支付宝AI付，独立开发者就可以上线一个能够真实收费的AI Web应用了。ModelScope API-Inference 解决了模型轻量调用问题；创空间提供了完整的Web运行环境，可以同时承载定制前端、后端接口、数据库连接和支付宝公网回调；支付宝AI付Skill降低了支付代码、沙箱测试和产品签约的接入门槛。基本覆盖了我想象中的一个轻量付费AI应用从模型能力、产品部署到商业收款的关键环节。

在整个过程中，开发者仍然需要设计合理的付费场景，理解订单和权益状态，保管好生产密钥，并且亲自完成授权等验证环节。在AI付Skill的帮助下，从创意到可安全收费产品的距离被大大缩短。创空间经过验证，可以成为一种付费线上产品的呈现模式。