SkillPay 一键改造器

> 将你的 Skill 一键式改造为 Pay Skill

> 付费服务说明：本 Skill 为按次付费锻造服务，按次计费 ¥1.99/次
> （以支付页面展示为准）。云端锻造引擎持有全部模板资产与生成逻辑，
> 一次调用产出目标 Skill 的完整改造包并通过合规扫描；方法论知识本地免费
> 可见，改造包的生成与持续更新在服务端执行，用户无需重装。

这个工具是什么（先建立心智模型）

SkillPay 一键改造器 是一款引导式改造工具：把用户已有的 Skill 专业改造成符合
SkillPay 规范的 Pay Skill。改造前必须先询问使用者走哪个收费方向——
支付宝端（个人主体）/ 微信端（企业主体），两条路的服务端代码、
协议章节、凭证清单完全不同，选错等于推倒重来。

一次改造的本质是技术端 × 业务端对接，最终组合验证交付：

> 一句话：技术端改造本体，业务端打通通道，两者组合，验证通过才算交付。

服务流程（七阶段 SOP，必须按序执行，不得跳步）

> 总览：触发速览（免费）→ 路径选择（免费，改造前必问）→ 付费 ¥1.99 →
> 按路径改造 → 凭证获取引导 → 部署与组合 → 最终测试与提交审核。
> 阶段 0-1 免费；阶段 2 是付费门禁；阶段 3-6 为付费后交付与陪跑。
> 其中阶段 3 = 技术端，阶段 4 = 业务端，阶段 5 = 组合，阶段 6 = 验证交付。

流程驱动规则（付费是闸门，不是终点）

阶段 0-1 由用户提问驱动；阶段 2 付款成功即自动续跑——Agent 一路推进到
阶段 6 交付完成，中间不以"等用户回复"中断，除非命中下面四类必须停下的情形：

节奏要求：
- 每完成一个阶段，立即进入下一阶段：先汇报本阶段产出与下一阶段要用户做什么，再继续推进；
- 阶段 3（技术端）无需用户参与——付款成功后当场完成并交付改造包；
- 阶段 4（业务端）按凭证清单逐项推进，一项拿到就勾掉并进入下一项；
- 阶段 5-6 连续执行到「验证通过 + 指导上架」；
- 结束条件：阶段 6 出口 = 交付完成（若用户暂不提交审核，附待办清单同样算完成）。

红线：付款成功后以「请确认是否继续」之类话术停下，等于把自动流程退化成人工流程——
禁止。付费即自动推进，直至交付。

阶段 0 · 触发与目标确认（免费）

用户表达改造意图后：

1. 问清改造对象：已有 Skill 还是只有想法？它帮用户做什么？
2. 目标包就位（阶段 2 的前置，不可省）：让用户把待改造的 Skill 打成
   zip 交过来。付费门禁校验的是这个包本身（质检票绑死包的 SHA256），
   所以没有真实包就永远拿不到账单——只能停在免费速览。

拿到路径后记作 {目标包}（例：./dist/my-skill.zip），后续阶段都用这一个路径。
3. 执行免费速览（无门禁，不收费）：

python scripts/forge_api_client.py --preview \
  --name "{目标 Skill 中文名}" --slug "{目标 slug}" \
  --prototype "{方法论型|数据型|工具型|工作流型}"

4. 据速览结果向用户说明：原型判定、免费/付费切分建议、将生成的文件清单
5. 适用性筛查：无可重复价值 / 价值感低于 ¥0.5 / 资产无法上云 →
   劝退并说明原因，不进入后续阶段

速览不含任何可交付文件。 未通过筛查不得进入阶段 1；
目标包未就位不得进入阶段 2。

阶段 1 · 路径选择（改造前必问，不可跳过）

为什么先选：skillpay 目前只有两个付费改造方向——微信收费路径
与支付宝收费路径。改造包的服务端代码、SKILL.md 支付协议章节、
凭证清单全部按路径定制，选错等于推倒重来，因此改造之初必须定路径。

执行动作：

1. 用下表向用户直观呈现两条路线的区别与要求
2. 主体资质判定：
   - 个人主体（无营业执照）→ 仅支付宝路可选
   （微信 AI 专属卡需企业认证 + 微信商户号，个人主体走不通，实测结论）
   - 企业主体 → 两路均可，按需选择
3. 用户做出选择 → 记录 channel（alipay / weixin）
4. 两条路线的引擎模板均已就绪：支付宝路沙箱全链路已验证；微信路本地 mock
   闭环已通过（生产环境需企业认证 + 微信商户号 + SkillHub 开发者密钥）

出口：路径已定并记录 ｜ 红线：不得跳过选择直接收费；
不得替用户默认路径；个人主体可直接说明只有一条路可走，但仍需用户确认知悉。

阶段 2 · 付费（¥1.99 门禁，不可绕过）

向用户明确报出：

> 本次「{目标 Skill 名}」按{支付宝|微信}路改造，按次计费 ¥1.99/次
> （以支付页面展示为准）。产出：按路径定制的完整改造包
> （发布包 + 服务端 + 照做单 + 部署指南），全部通过合规扫描。

用户未确认前，禁止发起锻造请求。

2a · 免费质检取票（不收费，先过质量闸）

服务端不再「先给账单再看包」——没通过质检就拿不到账单。所以先花 0 元
把目标包过一遍质检：

python scripts/forge_api_client.py --inspect --package "{目标包}"

未达标准时，把 fails 里每条的 code / label / message / fix 原样转述给用户
（逐条列成清单，不要只说「质检没通过」），修完重跑——直到 chargeable: true。

票的绑定语义（必须让用户知道）：票绑死目标包的 SHA256 + 一次性 claim
摘要 + 30 分钟到期。只要改了包里任何一个字节，旧票立刻作废，必须重跑 2a。
所以顺序永远是「先定稿包 → 再质检 → 再付款」。

2b · 带票取账单 → 付款 → 携凭证重放

票在手后，发锻造请求取账单（此时尚不收费；客户端零第三方依赖，
仅 Python 标准库）。最省事的写法是直接带 --package——客户端会自己
重跑质检并自动带票（包未变则直接命中已暂存包，不重复计次）：

python scripts/forge_api_client.py --forge \
  --name "{目标 Skill 中文名}" --slug "{目标 slug}" \
  --prototype "{方法论型|数据型|工具型|工作流型}" \
  --price "{目标服务定价}" --channel "{支付宝 AI 付|微信支付 AI 专属卡}" \
  --desc "{一句话服务描述}" --triggers "{词1,词2}" \
  --package "{目标包}" \
  --save-bill ".state/{会话ID}/payment-needed.txt" \
  --out "{输出目录}"

> 若 2a 与 2b 分两次跑，可改用
> --inspect-ticket "{ticket}" --claim "{claim}" 代替 --package。
> 两者都不给 → 客户端直接 exit 8 INSPECT_REQUIRED，不会发出 402 账单。

返回 exit 7（PAYMENT_REQUIRED，本次不产生扣费），并给出
out_trade_no / amount / pay_before 供用户核对金额；账单原值已按
0600 权限落到 --save-bill 指定文件（不解码、不改写，供下一步交给
官方支付能力）。

拉起收银——按官方 alipay-payment-skill 范式，把账单与原始请求交给
官方 CLI（智能体不接触支付密钥、不自行实现付款）：

alipay-bot 402-buyer-pay \
  --session-id "{会话ID}" \
  --file ".state/{会话ID}/payment-needed.txt" \
  --resource-url "{函数URL}/v1/forge" \
  --method POST \
  --data "{原始请求体 JSON}" \
  --header "Content-Type: application/json" \
  --intent-summary "原始请求：为 {目标 Skill 名} 生成{路径}付费化改造包"

> 依赖：alipay-bot CLI（官方 @alipay/agent-payment）与 npm、curl 可用。
> 安装：npx -y --registry=https://registry.npmjs.org @alipay/agent-payment@1.0.23 install
> 账单 30 分钟有效，超时重新生成（零损失、零扣费）。

用户付款后，复用原请求与原订单携凭证重放取回改造包（不重新下单）：

python scripts/forge_api_client.py --forge \
  --name "{目标 Skill 中文名}" --slug "{目标 slug}" \
  --prototype "{原型}" --price "{定价}" --channel "{路径}" \
  --desc "{描述}" --triggers "{词1,词2}" \
  --payment-proof-file "{凭证文件路径}" \
  --out "{输出目录}"

> 重放不带票：服务端看到 Payment-Proof 就直接走进支付核验，
> 不再要求质检票。所以票 30 分钟过期、包已被清理都不影响已付款订单——
> 但包本身不能换，换了就是另一件商品（新包 -> 新账单）。

> 凭证用 --payment-proof-file 传入（不要用命令行直接传——会进 shell 历史
> 与进程列表）；账单原文只经 --save-bill 以 0600 落盘，不进日志。

• 状态不明时先查单（alipay-bot 402-query-payment-status），不重复付款
• 服务端验证付款凭证 → 渲染模板 → 合规扫描 → 打包 → 自动落盘并解压
• 用完清理 .state/ 下的敏感过程产物

出口：付款成功，改造包已生成 → 立即自动进入阶段 3（不等待用户回复）
｜ 红线：任何异常路径不得输出改造包文件的免费替代品。

阶段 3 · 按路径改造（引擎自动执行）

服务端按阶段 1 选定的 channel 定制渲染，四大组件全部随路径变化：

客户端将改造包落盘到 --out 目录，按以下结构交付（整体为
{slug}-forge-output.zip，解压后）：

{slug}-forge-output/
  {slug}-pro/               # 发布级 Skill 包（扁平 5 文件，SKILL.md 在根）
  {slug}-pro.zip            # 发布 zip（直接上传/CLI 发布到 SkillHub）
  server/                   # 部署私产（app/订单/核验/部署脚本）——部署到腾讯云 SCF，勿入发布包
  ONBOARDING-SHEET.md       # 平台侧照做单（按路径的凭证清单，已填目标服务的真实参数）
  DEPLOY-GUIDE.md           # 部署 + 联调步骤指引
  CLOSED-LOOP-SOP.md        # 本次付费化闭环·可复用 SOP（换 Skill 只改参数即可复用）

> 交付的不只是改造包，而是一个以所选付费路径形成的完整闭环：
> 改造包（技术端）+ 照做单与部署指南（业务端）+ 闭环 SOP（把整条链路固化成可复用流程）。

Agent 动作：落盘改造包 → 向用户明示扫描报告结论（合规 0 命中才建议
发布）→ 提醒 server/ 是私产永不入发布包 → 立即自动进入阶段 4
（逐项引导取凭证，不等待用户回复）。

红线：交付物以服务端返回为准，禁止自行编造、推算或补全任何文件内容。

阶段 4 · 凭证获取引导（分路线 · 每步引导 + 说明）

按照做单逐项引导用户获取凭证。每项统一格式：
去哪 → 点什么 → 取什么 → 交给谁/填到哪。完成一项勾一项，
全部齐了才进入阶段 5。

支付宝路凭证清单（8 项 · 对齐官方《个人接入》五步）

私钥纪律：用户本人生成、本人保管；部署时由本人粘贴进 SCF 控制台
环境变量——Agent 不经手、不记录、不进聊天记录。

微信路凭证清单（6 项 · 对齐官方《企业接入》）

> 两套密钥务必区分（官方标注的头号坑）：微信支付 API 证书管下单/查单/退款；
> SkillHub 开发者密钥管 AI 预下单。AI 预下单不使用微信支付 API 证书签名。
> 支付核验方式 = 微信查单 trade_state=SUCCESS + 金额一致；不需要向平台索取任何核验参数。

出口：全部凭证备齐（私钥在用户手里）→ 立即自动进入阶段 5（部署与组合）
｜ 红线：缺项不得进入阶段 5；私钥三不进（不进聊天记录、不进发布包、不进日志）。

阶段 5 · 部署与组合（改造好的 skill × 对应的端口）

Agent 动作：

1. 指导用户把凭证填入配置（私钥由本人粘贴进 SCF 控制台环境变量）
2. 执行部署：python deploy_scf.py deploy
   （自动：备份线上 → 跑回归 → 打包 → 部署 → 等 Active → 取 URL → 公网实测）
3. 回填服务地址（支付宝路）：AI 付服务管理 → 服务地址 = 函数 URL；
   （微信路：商家侧配置项按官方《企业接入》Step1–2，无需向平台索取核验参数）
4. 组合：把函数 URL 填进改造包客户端
   scripts/{slug}_api_client.py 的 DEFAULT_ENDPOINT
   （锻造时目标服务尚未部署，此处原为占位符）——skill 与端口组合完成
5. 验证：GET {URL}/healthz 返回 200 + 无凭证调用返回 402

出口：组合完成、地址可达 → 立即自动进入阶段 6（最终测试与交付）
｜ 红线：部署前必跑本地回归；联调桩状态（verify=off）不得作为最终态。

阶段 6 · 最终测试与交付（用户亲自验证）

Agent 动作（引导用户亲自走完全流）：

1. 无凭证调用 → 402 + 账单（核对金额、字段与服务登记一致）
2. 用另一个账号支付（买家 ≠ 卖家；支付宝路用另一支付宝账号，
   微信路由买家在自己的对话内确认支付卡片）
3. 验付 → 履约 → 幂等重放（重复请求返回缓存成果，不二次扣费）
4. 价格四处一致核对：服务端 UNIT_PRICE = 402 body = 平台配价 = 支付页展示
5. 全通过 → 指导提交 SkillHub 审核（发布台配价 + 云端沙箱运行一次 +
   提交审核；审核期搜索不到属正常）
6. 审核通过 → 改造完成，可上架

官方验收对照表（逐项打勾，缺一不得提交审核）

官方《个人接入》上线自测验收表：

官方发布自查五项：

微信路追加官方「改造完成后检查」四条：

> 官方原话：Skill 可以通过官方 CLI、脚本或依赖封装这些能力；
> 不能仅凭文案声明替代真实可用的服务。

指导上架（官方发布要求）

阶段 6·5 · 上架后买家验证（官方《个人接入》第五章，交付闭环的最后一步）

审核通过上架后，必须再走一遍买家视角的验收（沙箱与服务端自测覆盖不到这条链路）：

1. 买家从 SkillHub 安装已上架版本（不是本地包），确认官方支付依赖可用；
2. 用真实用户常用的说法调用 → 确认触发正确、参数传递完整；
3. 核对详情页展示价、付款前提示、实际账单金额三者一致；
4. 用与卖家不同的账号完成付款；
5. 确认买家收到正确结果、卖家可查到交易、服务端履约已确认。

出口：买家可安装、付款并收到结果，卖家可查到收款 = 交付完成
｜ 红线：审核通过 ≠ 交付完成；买家验证未过不算交付。

出口：测试全绿 + 已提交审核 = 进入阶段 6·5 ｜ 红线：任何一步失败不得进入
审核；修复后重跑，不降级放行。

改造参数说明（阶段 2 入参）

方法论知识层（本地免费）

以下知识免费可见，用于理解服务与自助评估；改造包文件由阶段 2 付费产出。

三条铁律

1. 付费唯一路径是「按次调用」，不是卖安装包。 SkillHub 没有「skill 包标价
   售卖」模式。收费 = 服务端对无凭证调用返回 HTTP 402 → 平台弹支付确认 →
   用户对话内付款 → 平台带凭证重放 → 服务端验付履约。
2. 核心资产必须上云。 本地发布包只放客户端与文档；核心引擎/数据/生成器放
   服务端（腾讯云 SCF Web 函数）。防盗版、可持续热更新、过审核。
3. 免费档引流、付费档交付。 切分线划在「用户能看到价值、但不够用」：
   免费档给速览/读数，完整交付物 + 核心引擎在付费墙后。禁止把付费能力做进
   本地包——那等于免费送。

通用性四原则（任何 Skill 都可改造）

1. 改造对象零假设：不假设目标有代码、有数据、有服务器。纯 prompt/纯文档的
   方法论型 Skill 同样可改——核心知识资产封装成服务端 API，本地留薄客户端。
2. 资产切分是唯一变量：不同 Skill 的差异只体现在资产归属，流程/协议/部署/
   发布全部同构。
3. 模板全泛化：引擎持有的模板无任何领域残留，参数化填充即可用于任何领域。
4. 双路线可插拔：收费路径分微信路（X402）与支付宝路（A2M）两条，
   改造之初由客户按主体资质选定，引擎按路径定制全部组件。
   个人主体仅支付宝路可用；微信路需企业认证 + 商户号。

引擎内部七阶段精要（服务端执行，本地供理解）

> 与上文「服务流程七阶段」区分：服务流程是对客的 0-6 阶段（速览→选路→付费→
> 改造→凭证→部署→提审）；下表是引擎内部把一次改造拆成的七道工序，同名不同事，
> 勿混用。引擎按路径（alipay/weixin）定制渲染，流程/协议/部署/发布全部同构，
> 只有资产切分因 Skill 而异——这就是它作为通用工具的原因：任何领域的
> 方法论型/数据型/工具型/工作流型 Skill 都可改造。

质量纪律红线

参考文档索引（免费方法论）

references/
  payment-path-selection.md  【新】路径选择指南（两路区别/要求/决策树/就绪状态）
  platform-mechanics.md      平台机制全景（入驻/费率/结算/审核）
  pay-protocol.md            402 契约详规（微信路 X402 + 支付宝路 A2M）
  scf-deploy-playbook.md     腾讯云 SCF 部署实战手册（19 坑 + A2M 新坑）
  freemium-split.md          免费/付费切分设计指南（四原型）
  packaging-rules.md         发布包纪律与合规扫描清单（含头像处理）
  case-studies.md            两案例解剖（数据型 × 工具型，匿名化）
  api-contract.md            本服务接口契约（/v1/preview + /v1/forge + 错误码）

支付协议实现（本服务自身：支付宝 AI 付「AI按量付费」A2M）

> 本 Skill 自身通过支付宝 A2M 收费；生成的改造包按客户所选路径
> （微信 X402 / 支付宝 A2M）定制，两路协议详规见
> references/pay-protocol.md 与 references/payment-path-selection.md。

402 账单下发

当用户发起锻造请求但未携带有效 Payment-Proof 时，服务端返回 HTTP 402，
并在 Payment-Needed 响应头中返回 Base64URL 编码的账单。账单
protocol 含 out_trade_no / amount / currency=CNY / resource_id /
pay_before / seller_signature / seller_sign_type=RSA2 / seller_unique_id；
method 含 seller_name / seller_id / seller_app_id / goods_name /
seller_unique_id_key=seller_id / service_id。

账单由商家应用私钥（RSA2）在本地签名，字段按 key 字典序拼接
amount / currency / goods_name / out_trade_no / pay_before /
resource_id / seller_id / service_id 后签名，不请求支付宝服务端。
账单原值必须逐字节原样传递，不解码、不改写。

携带凭证重放

用户在对话内完成支付后，客户端携 Payment-Proof 请求头（Base64URL 支付
凭证，含 payment_proof / trade_no / 可选 client_session）重放原请求，
复用原订单，不重新下单。

验付调用

服务端调支付宝 alipay.aipay.agent.payment.verify 严格验付，除接口调用成功外，
还须同时校验：active=true、返回 amount 等于本地订单金额、返回
out_trade_no 等于本地订单号、返回 resource_id 等于当前请求资源、
trade_no 未被重复履约、本地订单处于允许的支付/履约状态。任一校验失败即返回
402，让智能体重新支付，不降级、不白嫖。响应报文须按官方要求对
xxx_response 节点原文验签，防伪造或篡改。

履约确认

验付通过后，服务端原子执行锻造引擎（模板渲染 → 合规扫描 → 打包）：资源只生成
一次并落 PENDING_CONFIRM，随后调 alipay.aipay.agent.fulfillment.confirm
发送履约回执，回执成功后才置最终完成。回执失败允许同一 Payment-Proof 重试，
避免「资源已生成但平台未记录履约」。

订单持久化与幂等

所有订单通过 SQLite 持久化。支付态 PENDING_PAYMENT → PAID → CONSUMED，
履约态 UNFULFILLED → PENDING_CONFIRM → FULFILLED。每笔订单仅履约一次；
已确认或已完成的同一订单重放直接复用已保存结果，不重新生成资源、不产生二次扣费。

异常处理（不降级、不白嫖）

红线：任何异常路径下，本 Skill 不得输出改造包文件的免费替代品。

限制说明

1. 锻造引擎按当期平台规则与协议版本生成；平台规则调整后引擎随服务端热更新，
   用户无需重装 Skill
2. 改造包的核心业务逻辑（目标 Skill 的引擎/数据/生成器）需用户在服务端
   server/app.py 的 preview_payload()（免费速览）与 build_deliverables()
   （付费履约）两个处理器中自行实现，引擎产出的是完整可运行的付费骨架
   （402 门禁/订单状态机/支付核验/幂等/频控均已生成到位，勿改协议代码）
3. 目标服务部署后需把函数 URL 填进客户端 DEFAULT_ENDPOINT 占位符
4. 双路线均就绪：支付宝路（A2M）与微信路（X402）的引擎模板全部就绪，
   按路径定制组件；某条路线的协议规则随平台调整时，服务端热更新，用户无需重装
5. 本 Skill 自身即按次付费 Skill，其服务端与改造包同构——可作活体样本参考

安全合规与数据处理声明

• 全程不收集用户个人信息：只接收 7 个改造参数（名称/slug/原型/价格/收费路径/
  描述/触发词），不采集姓名、手机号、身份证、邮箱、地址、账号等任何身份信息；
  支付与商户凭证由用户本人保管，Agent 只引导获取、不代管不转存
• 交付物去敏：发布包经合规扫描，密钥与个人信息模式（手机号/身份证/银行卡号）
  一律拦截，示例一律用占位；私产目录永不入包
• 凭证不落盘：接入凭证与支付凭证仅用于本次调用，不写入日志、不外传
• 支付指令保护：Payment-Needed / WeixinPay-Required 等支付指令
  原始值一次性、有时效，不得外泄、不得改写、不得写入持久化日志
• 数据最小化：仅传输锻造所需参数（名称/原型/定价/路径/描述），不涉及目标 Skill 内容
• 付费透明：调用前必须完成阶段 2 支付确认，禁止静默扣费
• 无本地核心资产：模板与引擎全部在服务端，本地包仅方法论 + 客户端

与官方规范对齐

• SKILL.md 标准 YAML frontmatter + Markdown 正文
• 全白名单扩展名（.md / .py / .json / .txt）
• 无硬编码凭证、无外部模型产品名称、无平台目录残留
• 核心资产（模板/引擎）位于服务端，本地仅客户端与方法论
• 协议细节以官方文档与官方技能为准（支付宝 A2M 官方文档 +
  alipay-payment-skill；微信支付官方技能 + 微信支付官方文档），
  不自作主张改写协议