# AI 软件交付与持续服务平台商业模式与成本指标

状态：版本 0.15，更新日期 2026-10-13。2026-10-13 会议认为此前统一计费太麻烦，改为按客户使用不同模式。暂时只记下面两种，依据 D088。后文年付、积分和加价是改模式之前的基线，两种模式怎样使用或替换那些规则尚未说明。

## 2026-10-13 按客户区分的两种计费模式

不同客户使用不同模式。当前只记录这两种。

| 模式 | 客户侧 | 平台侧 |
| --- | --- | --- |
| 用户报价模式 | 创建时做出选择，并带上报价 | 后台查看选择和报价，决定是否启动 |
| 用户自由模式 | 自由选择配置和 token 数量 | 费用从预充值扣除 |

报价模式在后台决定启动之前，不把创建当成已经开通。自由模式的预充值沿用已有充值余额的方向，token 数量与此前“按实际模型成本折积分”是否同一套账，尚未写明。

## 商业定位与独立选配

核心销售是可稳定运行的应用封装和 AI/团队的二次开发能力。首期人工与有限自动定制并存，年付套餐包含开发/运维及 AI 用量，超额按真实调用计费；公开测试赠送以后设计。自动 AI 消耗不保证满意成果，工作流封装与质量改善仍是服务价值，不改变整体应用定制定位。

基础应用、标准部署、运行资源、域名和邮箱帮助客户了解、体验和使用平台，支撑定制成果上线，并以不亏本为原则收费。基础服务可有加价和必要收益，但不作为核心销售目标；二次开发与系统定制承担核心价值销售。实际收入占比需运营后观察，不在规划中预设运行资源是主要收入。

域名、邮箱等仍可独立选配；年付套餐可以合并应用技术封装、约定的初始开发、运行维护及包含的 AI 用量，不要求把开发费全都另开一次性订单。复杂新增需求仍可人工逐单报价。基础服务持续覆盖成本，套餐不得因提前退役按月摊退而损失已完成开发的收入。

## 技术封装、获客与定制成交

应用目录中积累的接入配置、运行组成、部署维护、可修改边界和验证方法构成可复用的技术能力。开源应用可以作为基础，团队的封装与交付能力让后续定制能够在已有基础上实施，而不必每单重新调通整个系统。

建议围绕“展示能做什么、客户体验基础应用、提交业务差异、评估报价或选择已开放 AI 服务、交付定制成果、后续持续调整”组织客户路径。这是待细化的销售流程，不假定所有客户都会购买定制，也不承诺任何需求都可自动完成。

客户将一次明确改动以文字和文档附件提交工单，选择自动或人工模式，不用预设定制能力清单限制提交。自动模式由 AI 判断并开发上线，需要人工时自动转入原工单的人工模式；人工内部设置价格，客户在系统中同意或拒绝金额。需求澄清、价格沟通及后续反馈走在线客服或 Telegram；TG 机器人作为沟通接入候选。

已确认原需求和附件不被覆盖，新增或改变业务范围另建工单，客服消息不自动扩大原范围。失败后允许修订需求再试，建议保留同工单的修订与各次尝试；本次失败修复、真正新增需求和相应费用仍需细化，不能因出现重试按钮就承诺无限免费返工。

定制报价与 AI 成本计费仍按已确认规则执行。成本加价是收费计算方式，不能代替对交付价值、任务边界与客户成果的说明。定制服务需要分别核算 AI、人工、验证和返工成本，判断现有价格能否支持持续交付，不在本轮擅自改变报价方式或 20% 加价方向。

## 已确认的收费方式

| 服务项 | 已确认的计费方向 | 当前交付边界 |
| --- | --- | --- |
| 年付应用套餐及运行配置 | 按年购买，可包含约定开发/运维和 AI 用量；配置档位由后台管理 | 资源有可解释成本与档位，前台不必拆成灵活 VPS 账单；扩容另按规则 |
| 已接入开源应用标准部署 | 不另收部署费，运行资源正常收费 | 已调通的应用版本按标准配置部署；目录外接入另评估 |
| 人工定制 | 内部评估设置金额，客户同意后执行 | 首期复杂开发由人员处理并更新线上，价格协商通过客服 |
| AI 定制 | 先抵扣套餐包含用量，超出后实际模型成本加价，当前拟加价 20%，充值积分支付 | 成功/失败/重试/转人工均计算实际已消耗用量；测试赠送另作隔离权益 |
| 域名购买 | Gname 购买成本加平台服务费 | 独立收费；注册、续费与其他域名操作价格需分别确定 |
| 共享企业邮箱 | 平台制定包年共享邮箱服务价目 | Migadu 账号池内分配，计价对象与客户额度待定 |
| 独享企业邮箱 | 单独定价，经工单人工处理 | 为更强收发需求准备独享 Migadu 账号，注册目前人工完成 |
| 外部托管资源 | 用户提出第三方成本加 20% 服务费，后台可调整 | 外部数据库与云存储纳入未来能力；供应商、共享分摊及浮动成本结算待定 |
| 平台公共 API 服务 | 独立选配并收费 | 持续基础服务包年；接口权益、额度与超额计量后续确定 |

典型组合：仅运行预览应用并使用平台默认域名，收运行资源费但不开放默认域作为正式公开入口；托管加购买域名，产生两类账目；仅购买域名或邮箱，不创建无关的 Web 运行资源或 AI 任务。购买邮箱需要可验证的域名资源，正式上线允许客户自有域名绑定或平台代购。

默认建站域名由平台提供，可为三级或四级域名，仅用于受保护测试/预览，不允许客户将其作为正式公开站点。默认预览入口和独立域名路径分别管理；没有独立域名不代表无实际运行资源。正式域名可平台代购或自有绑定，自有域名接入服务价目后定。免责声明/验证码不作为已获得法律免责的承诺。

## 运行资源订阅

客户按年购买套餐及配置，不按实际瞬时使用量、小时或退役前用了几天结算。应用运行情况用于容量管理、告警和扩容建议，不直接变成另一路按量账单。年费可覆盖已投入的开发与运维，即使客户提前停止使用，已完成的开发成本仍然存在。

配置档位需体现应用真实组成，包括 Web、worker、scheduler 等工作负载以及数据库、缓存和存储依赖。报价不能只覆盖 Web 容器，遗漏后台组件；同一资源也不能因关联多个组件而重复计算。

资源价格参考基础设施成本，由平台后台设置。供应商整机费用、K8s 可售容量及客户资源档位不是天然一一对应，需要定义成本分摊和容量余量，不能把整台服务器成本重复转嫁给每个项目。

待细化：CPU 与内存如何定义购买量；数据库是包含的能力还是可选项；持久卷、备份和额外环境包含多少；扩容差价的计算、生效和续费；缩容及退款规则。不能仅因采用 K8s 就把资源限制方式或存储产品选型当作已定案。

## 多应用项目的资源费用归属

项目负责汇总购买项；APP 或 namespace 的数量不直接决定价格。Web、worker 等组件分别覆盖实际购买的资源配置，共享数据库、存储分别计算一次。APP 按完整软件实例定义、组件表达运行单元的分层已确认。

建议账目能解释到具体服务购买项及其使用关系：

| 购买项 | 核算方式与展示建议 |
| --- | --- |
| Web、worker 等计算配置 | 按购买的配置档位与副本范围覆盖资源，年付；扩容调整对应项 |
| 数据库、缓存、持久存储 | 单独购买或明确包含在组合套餐；多个应用共享同一份资源不重复收费 |
| 域名、邮箱、公共 API | 各自服务规则产生费用，关联使用项目，不重复包含全部项目计算配置 |
| 人工或 AI 定制工单 | 按既定模式计费，区别于持续运行资源费用 |

组合示例：`项目周期基础费用 = Web 配置费 + worker 配置费 + 一份共享数据库费 + 一份共享存储费 + 选配服务费`。人工/AI 定制、域名采购等按其发生时间和规则另列账目，不能为了展示一个合计就混淆周期。若售卖组合套餐，已包含的资源不再逐项叠加收费。

项目组可用于汇总客户多个项目的账目，但分组不是新的资源消耗单位。采用单层、项目单归属，不需要多组或嵌套。客户整理分组不自动影响价格；平台行业/价格政策单独配置，移动分组不改写历史账目。业务默认项目逻辑数据库独立，同项目 APP 可共享；供应商成本池需明确各服务份额，不能在每个项目都列出整笔费用。

客户删除 APP 或退役时，资源按引用和已提示的释放规则处理，年度购买记录不变成按小时/月账目，首期不退钱。三天是最后引用释放期候选，不是退款依据；主动退役不保留占用资源的业务数据/备份，代码和配置另留。

## 外部托管数据库与存储的成本转售

用户提出未来接入 RDS 类托管数据库及第三方云存储，第三方服务成本加 20% 服务费，后台可调。此方向不意味着必须首期接入，也未选定供应商。自建资源可保留为另一供应方式；不同引擎、区域和存储能力对应不同服务规格。

`客户外部资源费用 = 按规则归属客户的第三方成本 × (1 + 服务费比例)`

当前方向为 20% 成本加价。独享供应商实例可直接归属成本；共享供应商实例承载多个项目时，先按明确的规格/容量或其他规则形成服务份额，再计算各自收费。不能将整笔共享实例费用分别乘 1.20 后收给每个项目，也不能忽略未售容量由平台承担的成本。

采购账目和客户应收分别保存，采用当期价格规则。数据库规格、存储、备份、网络传输及请求等是否包含、怎样归属需按实际供应商产品核对；不能仅对一个标价加价就认为成本已完整覆盖。

K8s 计算配置继续采用已确认的固定档位订阅。第三方可能有浮动成本，客户结算方式尚未选择：可以是含额度的固定套餐及超额规则，也可以是可归属实际成本加价；进入阶段 3 比较，不默认为客户开启无限按量费用。试运行、扩缩容、跨供应商迁移和采购结束时点也需定义，避免新旧资源重叠时账目含糊。

## 平台公共 API 与项目间协作

平台维护的新闻 API 等公共应用，资源采购属于平台服务成本；客户购买 API 使用权益，可关联客户项目，不必每位客户部署一份相同应用。平台可以另提供专属实例产品，但不能把公共订阅自动算成专属部署。

公共 API 的服务规格需表达允许使用的接口、额度和限制，计价单位、周期与超额方式另定。平台成本与全部订阅收入共同核算，不能向每个订阅客户重复转嫁整个服务实例采购费。

同一客户的评价网与内容中心通过 API 协作，是两个项目之间的使用关系；仅存在这种关系不自动产生一笔额外平台 API 费用。客户购买平台公共服务、购买另一个独立收费服务，以及自己两个应用互相调用需要区分。

以上用于保证基础与公共服务有清楚的成本和权益边界。二次开发和系统定制仍是核心销售，新增资源类型不改变产品定位。

## 人工定制与 AI 定制

人工模式流程已明确：提交任务或由自动模式转入、内部评估设置金额、系统提示价格、客户同意或拒绝、同意后执行并更新线上。金额确认类似网购改价，不包含价格协商文字；协商由客服完成，反馈不在工单内持续讨论。支付时点及状态细化见 02。

自动模式提交后按既有 AI 计费规则处理，不增加人工报价确认或每次客户验收预览的环节。内部检查后直接更新线上；判定需要人工则转换模式，转换后才进行人工金额确认。

本轮修订早期“人工模式不另计 AI”前提：无论自动、人工还是自动转人工，归属于客户项目的实际 AI 调用均记录消耗，先抵扣套餐包含用量，超过后客户付费。人工服务金额与超额 AI 积分分开说明；报价不能把同一调用已经包含并扣除后又重复收费。人员用于平台研发等不属于客户项目的调用不转记客户工单。

AI 工作流统一经 OpenRouter 调用模型。先抵扣套餐包含权益，超额调用当前的计价方向为：

`调用计价金额 = 归属该项目的实际模型调用成本 × (1 + 平台加价比例)`

`超额应扣积分 = 扣除套餐包含权益后的计价金额 × 每美元积分数`

当前比例为 20%；成本为 1 个计价单位时，客户费用为 1.20，加价部分为 0.20。这是成本加价比例，不是销售额的 20% 利润率。

技术计量建议保存模型、请求标识、输入输出与缓存等 token 用量、供应商报告成本、所属工单和采用的价格规则。不同模型及 token 类别价格不同，不能把全部 token 合并乘一个通用单价。OpenRouter 官方文档支持返回用量与费用，建议以平台账户实际扣费口径核对。[OpenRouter Usage Accounting](https://openrouter.ai/docs/cookbook/administration/usage-accounting)

用户明确按消耗收费，不以 AI 成果满意或开发成功作为扣费条件。分析、修改、验收后的继续修复、失败重试和转人工前后已产生的项目调用均消耗权益；已消耗部分不因回退或拒绝人工报价自动退还。未发生实际费用的请求不能虚构 token 费用；重复回调不得重复记同一调用。平台有验收和改善工作流质量的责任，但不将“验收没过”变成该次推理免费。

自动修复仍应有循环/预算控制，避免一直验收失败就无限花费；这是执行控制，不是结果退款政策。套餐用量耗尽后从客户充值积分扣除，充值不足时暂停新调用并提示充值，已付年费的运行服务不受 AI 余额影响。当前余额足够也不默认无限循环，具体任务上限阶段 6 设置。

添加域名、添加邮箱等固定运维操作如果由程序直接执行，不应因被封装成工作流就产生 token 费用。它们的收费归入相应服务产品，不另假定收费项目。

## 充值积分、套餐包含用量与测试赠送

确定采用预充值积分消费，不再比较按任务付款或事后账单。推荐初始比例为 **1 USD = 100 积分**，即 1 积分对应 0.01 USD 计价价值。充值 10 USD 得 1000 积分；超额 AI 实际成本 1 USD、加价 20% 时扣 120 积分。比例是平台产品设计选择，不是法币汇率；其他充值币种折算与渠道未选。历史充值与订单保存当时规则，不用后来换比例改写余额价值。

支持积分小数，内部按精确金额累计，不能把每次很小的调用都向上取整到 1 积分。积分不是 token 数，token 用量、供应商实际成本、套餐抵扣和应扣积分分别可解释。OpenRouter 的实际账户扣费可作为调用成本依据，不用估算输出字数替代成本。[OpenRouter 用量计量](https://openrouter.ai/docs/cookbook/administration/usage-accounting)

| 权益 | 用途与边界 |
| --- | --- |
| 充值积分 | 客户真实充值余额，用于正常购买/消费，不能混入测试赠送 |
| 年付套餐包含 AI 用量 | 已购买正式服务内包含的开发用量，正式项目可使用，超出后扣充值积分；不是新客测试积分 |
| 新客测试赠送 | 后续公开获客体验权益，永远只用于测试，不转为真实余额，不支付正式套餐或正式域名/邮箱 |

首期面向熟客，包含用量由后台按合作约定配置，不继续讨论复杂赠送频率、结转、促销或防批量注册模型。正式套餐内包含用量与公开新客试用不能合称一个无限制的“免费额度”。后台可配置固定项目服务费、包含 AI 用量和超额费率；中介仍是普通客户。模型成本预算可作内部计量方案，授予策略细则后续成熟再设计。

未来由测试赠送开通的部署只支持受保护预览，不能绑定任何正式域名上线，包括客户自有域名。平台保留撤销测试权益及销毁测试部署的权利，用户应明确其可随时终止、不作生产/业务数据保留承诺；具体限额、期限、滥用处置和正式购买衔接后置，不能据此删除客户已付费正式资源。绑定限制必须是资源/服务资格校验，而不是仅在向导隐藏按钮。

客户或价格客户组可作为合作政策的匹配目标，客户自行整理的项目组仍不自动改变价格。未来可预留不同退役结算政策；首期仅启用年付不退，不实现按月折价退款逻辑。

## 首期熟客试用与系统外差额处理

用户最终明确首期只由深度合作的既有中介客户使用，属于测试和试运营；客户仍使用普通账户。长期公开网站、SEO/广告引流与面向散户的目标不变，但不把公开陌生客户的完整商业服务要求同时视为首期验收前提。

沿用既有合作的年度项目套餐价，为客户配置固定项目服务费，结合资源和选配项形成谈好的合计。套餐可覆盖初始开发、运维和包含 AI 用量，不必把开发价独立收取。年费 1200 的示例包含已经完成的开发，使用一个月就按 100 计费退款会使开发收入不足；首期不采用这种结算。

首期不提供系统内退款功能或按月/按小时折价引擎，提前退役释放资源但不退年费。特殊退款或多退少补双方系统外处理，建议后台保留人工备注及订单关联，不覆盖原收费记录或伪造自动退款。消费模式为预充值积分，实际充值渠道与人工入账方式另定。

开通异常优先人工排查并修复，是否退款由既有合作双方系统外处理。将来公开经营时，付款后开通失败的客服申请退款路径再细化；不做无条件自动一键退款。支付/供应商结果不明仍先核对，避免重复采购、开通或扣款。渠道手续费归属尚未决定。

人工价格被拒绝时停止该次改动，不终止有效套餐。AI 技术失败先保持或恢复可用版本并回执失败，实际已消耗调用仍扣包含权益/充值积分。AI 消耗收费与人工明确交付约定、基础服务可用性是不同事项，不能把所有服务都解释成单纯 token 交易。

用户原则上希望所有服务按年付款及结算，域名/邮箱也按年，不将 VPS 灵活计费模式作为平台默认。未来可按客户或价格客户组例外配置退役结算政策；按月折价仅作未启用扩展候选，不作为首期标准，也不要求为此拆分整个年度开发价。

公开经营时的退款条款需符合经营主体、服务地区和客户性质对应的适用法律；当前地区事实仍缺。首期不建设退款模块是产品范围决定，不作为排除法定权利的声明。

## 年度变更与到期权益

扩容、增加 APP 和符合条件的计算减配属于现有项目配置变更；存储缩小可能是另一个迁移任务。建议分别记录原/新价、剩余周期、服务生效及结果，具体差价如何收退或下周期生效待定，技术上能减配不意味着必须承诺立即现金退款。

退役释放计算、数据库、卷、运行数据与相关占资源备份，不保留原业务；仅留代码、启动环境配置、依赖/构建说明等轻量可重建材料，不因保留 Git 就保留 PVC 或全部镜像。低成本代码归档属于有意保留的例外。重新部署以代码初始化新业务环境，不恢复数据、不计算退役前后的退款差额；具体重新部署的订单操作以后从简定义，不据此启用年内按月退款。已购买域名和邮箱仍按各自年度服务独立管理。

到期前邮件提醒；未续费到期后停止外部访问，业务数据最多保留一周。提醒日期、保留起点和截止时刻、期间运行成本、续费恢复、备份清除及之后重新部署的收费规则继续细化。域名、邮箱、API 分别管理到期及采购承诺，不因运行服务到期自动全部退款或注销。

## 域名价格

采购来源为 Gname，按域名采购成本加平台服务费定价。后台可调整服务费参数；按固定额、比例或不同后缀分别设置的方式待定。

域名注册、续费和转移是不同业务动作，具体价格及可提供范围另定。客户自有域名绑定与平台代购也分别记录，不能因“添加域名”自动推断需要采购或产生采购账目。

后台调整价格时应明确对新订单与已有域名续费的影响；注册前需完成可用性和价格确认，执行失败或采购结果不明的对账规则后续制定。

## 企业邮箱与账号池

共享服务使用 Migadu 账号池；更高收发需求可申请独享 Migadu 账号，通过人工工单准备。账号注册、购买和池准备目前不能假定全部自动完成；已有有效账号上的域名和邮箱开通可逐步封装为固定流程。

用户举例为供应商 90 美元、共享池约 100 个域名、向客户收费 10 美元。保留该运营设想，持续服务按包年方向，零售 10 美元的计价对象仍待细化。2026-10-10 核对官方价目，Mini 列价为 90 美元/年；该外部价格是本轮参考，正式运营按届时供应商价目和实际采购记录维护。[Migadu Pricing](https://www.migadu.com/pricing/)

Migadu 的额度按整个账号计量，池内域名和邮箱共同消耗收发与存储容量。因此“100 个域名”是平台拟定的分配参数，不是每个域名都获得一个供应商套餐，也不是官方保证可以承载任意使用强度的容量。客户零售价与共享池批发成本应分别保存。[Migadu 账号额度说明](https://www.migadu.com/pricing/)

持续邮箱服务按包年方向；仍需细化零售计价单位、允许的域名与邮箱数量、收发与存储额度、扩容或升级条件，以及共享转独享的服务衔接。10 美元示例的计价对象尚未确定，不能在此自动定为每域名每年。具体限额需核对供应商可执行能力。

## Cloudflare 等供应商账号池

Cloudflare 账号目前由人工注册和准备。平台需要录入可用账号、配置引用、容量或使用状态及资源绑定，再按明确政策分配客户域名和应用入口。

分组分配用于减少单个供应商账号的故障、信誉问题或停用影响其他客户的范围。发现不合规客户时的处置与隔离政策后续制定，账号池不能保证客户之间完全不存在供应商层面的关联风险。

项目业务分组、价格分类和供应商分配各自保存用途，不预设三者一一对应。Cloudflare 账号池和 Migadu 账号池也不能合并成一个笼统的客户分组；分配规则、凭据引用、维护和人工补充需要独立表达。

## 后台价格参数与历史账目

后台调整定价参数是明确要求，以下是待细化的参数分类，不是已冻结的界面或数据库字段：

| 参数类别 | 示例 |
| --- | --- |
| 资源规格及订阅价 | CPU、内存、数据库能力、存储容量、年价、扩容差价规则 |
| AI 服务 | 当前 20% 加价比例、允许模型、任务预算、套餐包含用量和超额积分；新客测试赠送细则后置 |
| 域名服务 | 采购成本、服务费方式、注册与续费分别定价 |
| 邮箱服务 | 共享与独享规格、零售价、周期、客户额度及池容量 |
| 差异定价 | 客户/价格客户组政策、固定项目服务费、包含用量；退役默认不退费，例外结算模式仅预留 |
| 供应商成本 | 采购价、有效日期、成本分摊依据 |
| 外部托管资源 | 当前 20% 服务费方向、引擎/区域/规格、共享份额、包含额度及浮动成本规则 |
| 公共 API 产品 | 周期、接口权益、调用额度与超额方式，具体参数待定 |

建议价格规则版本化，订单、人工报价和用量结算保存当时的规则、金额与服务范围。后续调价或移动分组不修改已形成的历史账目；已有订阅下一周期怎样适用新价需明确规则。

年度套餐、域名、邮箱、人工工单和超额 AI 可分别解释收费项，通过充值积分消费。可向客户展示套餐合计，无需把开发/运维拆成小时用量；充值、消费、包含用量抵扣和测试权益分别记录。多币种、充值渠道与续费操作后续细化，不据此提前决定数据库。

## 成本核算与阶段指标

客户售价与平台成本分别核算：资源采购和闲置容量、存储备份、域名与邮箱供应商费用、AI 调用、人工评估沟通和开发、平台研发运维及获客。共享资源有分摊，不能把某一次采购当作某一个客户的全部成本。

`周期订单贡献 = 同周期确认收入 - 可变交付与托管成本`

贡献未扣除全部研发、获客和管理固定成本，不能直接当作净利润。年付服务及一次性工单用一致的周期口径比较，避免把全年收款与单月成本相减。

首期核心商业指标建议包括有效改动任务数、人工金额同意比例、定制收入与订单贡献、人工与 AI 投入、需求实现情况、上线成功、返工及后续新增任务。需求摇摆与追加造成的额外工时也需观察，评估固定工单需求是否改善原有亏损。基础应用体验是否带来定制需求应记录，不能只用托管项目数衡量核心成功。

基础服务配套记录成本覆盖情况、固定运维成功率与节省工时、供应商池容量、故障及售后工时。基础收费覆盖的成本范围和分摊口径需明确，不能仅覆盖主机商账单却忽略其运行维护投入。首期有限自动开发与人工并存，不能把“全部订单无人工开发”设为验收要求。

首期自动 AI 工作流应衡量调用成本、赠送消耗、付费转化、预算超限、重试、自动转人工比例、直接上线成功、回退及客户收费。不同服务采用对应指标，数据任务不要求都有网站预览，也不将客户验收确认作为所有任务的完成前提。

## 下一轮细化

本轮已明确年付套餐、预充值积分、实际 AI 消耗计费、退役不退费与代码归档，不再把公开赠送细则、小时计费或按月退款列为首期阻塞。下一轮核对首期少量必要流程参数和范围，再进入阶段 4 的平台业务模块/数据责任以及工作流/Git 专题；规格、渠道和自动任务清单可留对应设计阶段细化。