billing-setup

Credyt 设置

引导用户了解其计费模式，然后通过 MCP 工具在 Credyt 中完成所有配置，最后自动端到端验证完整计费周期。此技能可多次运行——用于添加新产品、更改定价或设置其他资产。

首先：检查现有内容

在开始了解需求之前，先调用 credyt:list_assets 和 credyt:list_products 检查当前状态。

如果他们已经配置了产品，请确认现有内容：

“我看到你已经设置了 [X]。你是想添加新内容、更改现有定价，还是从头开始？”

如果他们想从头开始，不要归档或删除现有产品。保留现状。用户随时可以通过对话管理现有产品（例如“归档 Pro 产品”“删除这个产品”）——绝不要自动执行这些操作。

如果这是他们首次设置，请开始完整的需求了解流程。

需求了解：了解他们的业务

每次只问一个问题。听完每个回答后再问下一个。根据他们的回答调整后续问题。这是一场对话，不是表格。

你的应用是做什么的？

“介绍一下你的应用——它能做什么？用户主要会用它来做什么？”

后续问题都要结合他们的具体应用和活动提出。

哪些事情会让你产生费用？

“这些活动中，哪些会产生提供服务的费用？例如，如果你调用 AI 模型，每次调用都会产生费用。哪些部分成本较高？”

这有助于确定可计费事件——也就是他们要跟踪并最终收费的活动。

你想如何收费？

帮助他们在三种方式中做出选择。用他们自己的应用举例说明每种方式，而不是使用抽象的概念：

• 按用量付费（预付钱包）：用户充值，每次活动都会从余额中扣款。余额用完后，用户需要充值，否则服务会暂停。OpenAI 和 Replicate 就采用这种方式。

• 月度订阅：无论用量多少，都按月收取固定费用。这是经典的 SaaS 模式，例如 Netflix。如果他们还在摸索定价，或者希望收入可预测，这种方式很合适。

• 混合模式（订阅 + 积分）：月费中包含一定额度的积分，超出部分需要额外付费。Cursor 和 Clay 就采用这种方式。

目前还不确定也没关系

如果他们还不确定如何定价，引导他们先跟踪用量，之后再定价：

“没关系——你现在不必决定定价。我们可以先跟踪应用中的所有重要活动及其成本。Credyt 会展示你的单位经济效益，你可以根据实际数据制定价格。”

对于这种情况：将产品价格设为零或占位价格，并强调要为事件添加成本。

使用美元还是积分？

“你希望用户看到的价格以美元表示（例如‘每个视频 2.50 美元’），还是使用自己的货币单位，例如积分或代币（例如‘每个视频 10 积分’）？”

适合使用积分的情况：后台成本会变化、用户不懂技术、你希望用户能够赚取积分，或者以后可能调整价格。

适合使用美元的情况：每项活动的成本固定、用户是开发者、你希望完全透明。

如果他们不确定，建议使用积分——这样以后调整会更加灵活。

定价是否会变化？

“成本会因某些因素而变化吗？比如更高质量的输出成本更高，或者不同的 AI 模型价格不同？”

如果会变化，请了解具体情况。这些因素会成为 Credyt 中的定价维度。

需求确认

开始配置前，确认你了解以下内容：

• 应用的功能以及哪些活动很重要
• 哪些活动会产生费用
• 计费方式（按用量付费、订阅、混合模式，或先跟踪用量）
• 使用美元还是自定义货币
• 定价是否会因任何维度而变化

如果有任何不清楚的地方，请提问。需求了解完成前不要继续。

通过 MCP 配置

逐步引导用户完成每个步骤。在执行任何会创建或修改数据的 MCP 调用之前，先向用户展示包含预期参数的表格，并取得明确确认：

“我将使用以下设置创建 [X]——这些设置都正确吗？”

字段	值
...	...

“如果你想更改任何内容，请在我继续之前告诉我。”

这适用于所有变更操作：创建资产、产品、供应商、版本和调整项。绝不要假设用户尚未确认的值，尤其是精度、定价和事件类型。

创建自定义货币（如果使用额度／令牌／金币）

仅当用户选择了自定义货币时才创建。必须在创建任何使用该货币的产品之前创建。

使用 credyt:create_asset。务必明确确认精度——额度通常为整数（精度为 0），但必须得到确认。例如：

字段	值
名称	Credits
代码	credits
精度	0（整数额度，不含小数）
汇率	1 credit = $0.05 → $1 可购买 20 credits

用具体的金额说明兑换比例，方便用户确认是否合理：

创建后，使用 credyt:quote_asset 验证兑换比例。报价说明 $1、$10 和 $50 各可购买多少单位：

“我来验证一下……✓ $1 可购买 20 credits，$10 可购买 200 credits，$50 可购买 1,000 credits。这样看起来正确吗？”

如果兑换比例不正确，使用 credyt:add_asset_rate 更正后重新报价。

创建带定价的产品

对每项计费活动使用 credyt:create_product。例如：

字段	值
名称	Image Generation
代码	image_gen
事件类型	image_generated
用量类型	unit
价格	每次事件 10 credits

需要向用户确认的关键字段：

• 产品名称和代码：此计费项目的名称及其标识符
• 事件类型：触发计费的活动名称（例如，“image_generated”）——必须与应用将发送的值完全一致
• 用量类型：按发生次数计费（“unit”），或按令牌等数量计费（“volume”）
• 定价：每次事件的费用

如果用户希望“先追踪”，将价格设为零，并在表格中明确说明。

**一个产品可以同时包含固定周期性价格和基于用量的实时价格。**例如，每月 $20 的订阅，同时按每项 AI 作业收取 1 credit，这是一个包含两种价格的产品——周期性 USD 价格和按事件计费的 credit 价格。默认使用一个包含多个价格的产品；只有用户明确提出需求时，才创建独立产品。

要更新现有产品的定价，始终使用 credyt:create_product_version 创建新版本——绝不要创建新产品。这样可以保留计费历史，并让客户继续使用现有订阅。创建版本前，同样要展示确认表格。

每次创建或更新产品后，都使用 credyt:simulate_usage 进行验证。在模拟中始终明确指定产品版本（例如，version: 1），不要依赖默认版本——这样可以确保测试的是刚刚配置的内容：

“我来测试一下——生成一张图像应花费 10 credits……✓ 已确认：扣除了 10 credits，相当于 $0.50。这符合你的预期吗？”

如果模拟结果不符，使用 credyt:create_product_version 创建包含修正后定价的新产品版本，并重新模拟，直至结果正确。创建新版本前，先用表格确认版本参数。

版本变更说明：创建新产品版本后，现有测试客户仍会订阅旧版本。运行验证前，要么创建一个订阅新版本的新测试客户，要么更新现有客户的订阅。

随附额度（权益）

如果计费模式包含订阅中附带的额度（例如，“$20/月包含 1,000 个额度”），应在产品级别将其配置为权益，而不是负价格或单独的产品。

在 create_product（或 create_product_version）调用中加入 entitlements 数组。权益有两种模式：

周期性 — 额度按计划刷新（例如，每月刷新 1,000 个额度）：

"entitlements": [
  {
    "name": "Monthly Credit Allowance",
    "asset": "{assetCode}",
    "amount": 1000,
    "purpose": "bundled",
    "lifecycle": {
      "duration": "month",
      "duration_count": 1,
      "refresh": {
        "strategy": "expire_and_replace"
      }
    },
    "accounting": {
      "revenue_basis": 0.00,
      "cost_basis": "auto"
    }
  }
]

一次性 — 额度仅发放一次，之后永不刷新（例如，注册奖励或促销赠送）。省略 lifecycle.refresh：

"entitlements": [
  {
    "name": "Welcome Bonus",
    "asset": "{assetCode}",
    "amount": 500,
    "purpose": "promotion",
    "lifecycle": {
      "duration": "month",
      "duration_count": 1
    },
    "accounting": {
      "revenue_basis": 0.00,
      "cost_basis": "auto"
    }
  }
]

lifecycle.duration 设置过期时限；duration_count 用于指定时长倍数（例如，duration: "month", duration_count: 3 表示 3 个月后过期）。对于订阅附带的额度，purpose 为 "bundled"；对于一次性赠送，purpose 为 "promotion"。

创建前，使用标准参数表向用户确认权益字段（名称、资产、数量、生命周期时长以及是否刷新）。

不要尝试将附带额度建模为负的固定价格——这会导致验证失败，也不是正确做法。

设置成本跟踪（对此进行询问）

验证之前，询问用户是否想要跟踪各项活动的成本：

“您想跟踪每项活动的实际成本吗？例如，如果生成一张图片的 API 费用是 $0.03，Credyt 可以将其与收入一并记录，这样您就能实时查看利润率。”

如果想要，为每个服务提供商（OpenAI、Anthropic、AWS 等）使用 credyt:create_vendor 创建供应商：

“您提到使用 OpenAI 生成图片——我会将其注册为成本提供商，以便我们跟踪这些成本。”

说明：当他们从应用发送用量事件时，需要在其中包含一个 costs 数组，列出供应商和金额。然后，Credyt 会自动计算利润。

如果不想要，也没关系——他们以后可以添加成本跟踪。

验证配置

配置完所有产品后，自动运行完整的计费周期测试。不要询问，直接执行。

“现在我来运行一次测试计费周期，验证所有环节是否正常……”

针对本次会话中创建或修改的每个产品运行验证。对每个产品，按照 skills/billing-verification/references/procedure.md 中的六步流程操作。

如果任何步骤失败，请说明问题所在并协助修复，然后重新运行该产品的验证。

“测试客户会保留在您的账户中——由于您处于测试模式，这不会造成任何影响。”

收尾

总结创建和验证的内容，然后建议后续步骤：

“以下是在 Credyt 中已设置并验证的内容：

• [列出已创建的资产]
• [列出产品、定价摘要和验证状态]
• [列出已创建的供应商]

准备好将其接入应用时，请运行 /credyt:billing-integration；如需添加更多产品，请再次运行 /credyt:billing-setup。”

下一步

此技能仅配置产品和定价。不要自行编写集成代码——SDK 结构、端点和身份验证标头很容易猜错。

接下来运行 billing-integration 技能。如果未安装，请让用户安装：

“运行 npx skills add credyt/ai-tools，然后让我运行 billing-integration 技能。”

如果该技能不可用，且用户没有明确要求你编写集成代码，请在此处停止并等待他们安装。不要手动编写 fetch 调用，也不要臆造 API 端点。

在应用程序代码中调用 Credyt API，首选方式是使用官方 SDK 之一：@credyt/api-client（TypeScript/Node.js）或 credyt-api（Python）。如果这两个 SDK 都不适合其技术栈，billing-integration 技能也涵盖直接通过 HTTP 调用。