起因：一个小工具，想收一次钱

事情很朴素。我有个周末顺手写的小工具，最近居然有几位陌生用户在用，于是冒出了那个所有独立开发者都会冒出的念头：能不能收点钱，哪怕一次一毛一块的。

打开支付宝 AI 付的文档翻了半天，我发现事情比想象中"丰富"——能帮你接支付的东西不止一个。花了个把小时把它们各自过了一遍，这篇就当摸底笔记。

第一件：支付集成 Skill，"说人话"就能开工

这是我上手的第一样东西。它把核心支付能力封装成了遵循开放 SKILL.md 标准的组件，装好之后你直接用自然语言描述需求，比如"我要做一个电脑网站，用户可以下单并用支付宝付款"，AI 就会自动生成接入代码。

安装方式给了好几种，对我这种懒人很友好：

• 一键打开 Qoder 客户端安装（版本要求不低于 0.12.2）；
• npx 下载；
• GitHub 仓库直接取；
• 魔搭 Skill 中心搜索"支付宝支付集成 Skill"。

有个细节值得单独说：使用这个 Skill 时，支付宝会自动分配快速沙箱和测试账号并展示在会话里，不用先注册登录就能直接跑沙箱测试。当然，沙箱只用于测试，不涉及真实资金。

文档里还有一句反复强调的话，我原样抄在这里给自己也抄给你：AI 生成的接入代码，开发者请务必审查代码，需自行确认代码逻辑。 Vibe Coding 爽归爽，钱的事情别全交给 AI。

第二件：MCP Server，让 Agent 自己会创建订单

第二样东西思路完全不同。Skill 是"帮你写代码"，MCP Server 是"让 Agent 直接具备支付操作能力"——在 Cursor、Cline 这类工具的配置文件里加上支付宝环境变量（APP_ID、私钥等）就能启动。

核心工具大概是四组：创建支付（根据环境选手机支付或网页支付订单）、查询支付状态、发起退款、查询退款结果。

我的体会是，它适合的场景是"你的产品本身就是个 Agent"。比如我在折腾的助手类项目，希望它在用户授权下自己完成下单动作，走 MCP 就比让 AI 生成一堆静态代码更顺——毕竟支付这件事是要在运行时反复发生的，不是一次性集成。

第三件：A402，按次收钱的"自动投币机"

第三样最有趣，也最贴我最初的需求。A402 是基于 HTTP 402 Payment Required 状态码的按量付费方案：服务方给自己的 API、MCP 服务或数字内容标好价格，调用方（人或者 AI Agent）用一次、付一次。

按官方文档的描述，一次调用的链路是这样的：Agent 匹配到商户的 Skill 并发起调用，服务端返回 402 状态码和所需金额，Agent 侧匹配支付能力生成付款卡片，用户确认支付，支付结果查询通过后服务才真正执行、返回结果。

换句话说，它让"收钱"这件事嵌进了 HTTP 协议本来的语义里——服务还没给你，先告诉你这要付费；你付了，我马上履约。对 API 服务、AI 技能这类单价低、频次高的场景，这套模式比让用户先充套餐自然得多。

顺带一提，如果你也在找真实的付费场景练手，PAYATHON 2026 · Pay for AI 黑客松的五条赛道（Vibe Pay、Skill Pay、Machine Pay、Token Pay、Agent Pay）正好和上面这几件工具一一对应，报名期到 12 月 1 日，暂无完整产品也可以先占个位，我自己的小工具打算提交 Machine Pay 赛道试试水。

三件工具怎么选

摸完一圈，我的划分标准很简单：

• 要给一个"应用"加收款（网页、小程序、App）→ 支付集成 Skill，说需求、改代码、跑沙箱；
• 要给一个"Agent"加操作支付的能力（运行时创建订单、退款）→ MCP Server；
• 要给一个"服务"加按次计费（API、MCP Tool、数字内容）→ A402。

三者不互斥。我的小工具最后走的组合是：Skill 完成基础集成，服务接口上 A402 按次计费。

接下来的行动清单

• 把支付集成 Skill 重装一遍拿最新版（官方提示支付产品迭代后 Skill 会同步更新）；
• 给小工具的三类接口分别定价，先在沙箱里跑通 402 流程；
• 检查我生成的接入代码，逐行确认参数与签名逻辑；
• 确认正式签约入驻需要的账号与资料，避免测试转正式时卡壳。

写完即止，不总结。

产品能力与接入方式信息引自支付宝开放平台文档及 AI 付官网（2026 年 10 月口径），以实际环境为准。具体以官方最新说明为准。