你客户的 App 刚刚迎来了史上最好的一个月。注册量翻了三倍，你搭建的工作流运转顺畅，创始人欣喜若狂。然后平台账单来了：超出套餐额度两百万工作单元，按每千个三十美分计费。这是在 119 美元套餐之上的 600 美元超额费用——而如果你的合同写着固定月费中"包含托管",那 600 美元就从你的利润里出，而不是客户的预算里出。他们的成功刚刚变成了你的亏损，而你工作范围里没有任何一条预见到这一点。
这就是 2026 年经营无代码代理公司的核心定价风险。Bubble 按用量计费，Webflow 对带宽和内容量计量，而且两者都会定期调价。固定费用假装这些成本是可预测的。它们不是。活下来的代理公司把平台支出当作它本来的东西：一笔从供应商流出、经过你的账本、流向客户的转嫁成本——你真正的收入是加价和管理费，从来不是那笔报销款本身。
Bubble 在 2026 年究竟怎么向你收费
Bubble 的标价看起来温和。按年付费时，网页版套餐为：Starter 每月 29 美元，Growth 119 美元，Team 349 美元，另有 0 美元的免费档和按需报价的企业版。按月付费更贵：分别为 32 美元、134 美元和 399 美元。但套餐费只是大多数生产账单中最小的一部分。真正的计量器是工作单元。
每个付费套餐都包含每月工作单元额度：Starter 175,000 单元，Growth 250,000，Team 500,000。免费档包含 50,000，但无法部署正式上线的 App。工作单元衡量服务器工作量——数据库查询、工作流运行、API 调用、页面加载、文件操作——而不同操作的消耗差异巨大。一次简单的页面加载大约消耗半个到两个单元；一次复杂的查询可能消耗 10 到 50 个。一个工作流频繁触发或查询未优化的 App，在流量看起来还不怎么样的时候就可能烧光 Starter 的额度。
额度用完后，不含任何附加档的超额费率是每 1,000 单元 0.30 美元。一个月多用一百万单元——对一个后端工作流密集的增长中 App 来说轻而易举——就是 300 美元。预购工作单元档位能大幅降低单价，在最大档位可低至每 1,000 单元约 0.10 美元，但你必须在用量激增之前购买档位，而且档位本身就是每月的承诺。
有三个机制让这对代理公司格外凶险。第一，用量确实很难提前预测；两个用户数完全相同的 App，根据工作流的搭建方式，工作负载可能相差一个数量级。第二，超额默认开启，Bubble 会在额度用到 75% 和 100% 时给账户所有者发邮件——但如果账户由你的代理公司持有，那封邮件发给你，而不是用户制造了激增的客户。第三，关闭超额并不能优雅地封顶账单：App 在达到上限时下线，直到重新开启超额、购买档位或下一个周期开始为止。"网站宕机是因为我们撞上了没人盯着的用量上限"不是你想跟客户进行的对话。
Webflow 形状相同，只是计量器不同
Webflow 不用工作单元，但从代理公司的角度看，它的定价具有同样的波动特征：适中的基础费加上随客户成功而变动的计量器。
2026 年 5 月，Webflow 把旧的 CMS 和 Business 网站套餐合并为单一的 Premium 套餐：按年付费每站点每月 25 美元（按月 39 美元），涵盖 300 个静态页面、20,000 个 CMS 条目和 50 GB 带宽。每月 15 美元的 Basic 套餐涵盖自定义域名和 10 GB 带宽，但完全没有 CMS。超出所含带宽的部分作为付费附加项出售，最高 2.5 TB——所以客户的病毒式发布或一个图片视频流量沉重的季度，会直接转化成更大的 Webflow 账单。
而且网站套餐只是三张账单之一。用于设计协作的工作区套餐、额外的设计师席位、额外语言以及电商交易容量都单独计费，叠加在每站点费用之上。一个客户要求"就再加一种语言"或"再给两个编辑权限"，就是在要求你扩大一个按量计费的技术栈——而如果你的合同报的是"网站加托管"的单一固定月费，每一个这样的"可以"都在蚕食你的利润。
两个平台也都会调价。Bubble 在 2026 年 10 月调整了 Starter 定价；Webflow 在年中重组了整个网站套餐阵容。任何把今天的平台价格嵌入其中的多月固定报价，都是在赌供应商会原地不动。这个赌已经输了好几年了。
合同错误：把计量成本捆绑进固定费用
失败模式几乎总是同一句话，埋在一份提案或主服务协议里：一个"包含托管"的固定月费。对客户来说，这读起来简单明了。实际上，它让你的代理公司成为供应商价格波动的承保人——你收取固定保费，吸收无限的计量下行风险。
关于代理公司项目的行业报道称，典型的 Bubble 项目费用在 20,000 到 250,000 美元之间，并指出了具体的利润陷阱：当你交付客户 App 后，客户的业务成功了，用量上升，要么客户支付他们从未预算的更多费用，要么代理公司吸收涨幅。在模糊范围上定固定价格，本来就是软件服务中代理公司与客户纠纷最常见的来源；在固定价格里再塞进一张第三方计量账单，会把每一次用量激增都变成一次重新谈判。
同样的陷阱在低一层的 AI 和自动化工作中也会出现：那些把 API 和 token 成本捆绑进固定预留金的代理公司会发现，供应商调价一夜之间就变成自己的亏损。平台支出的行为跟 token 支出完全一样：第三方计量、由客户驱动、不受你控制。具备这三个属性的成本不属于固定费用。它们属于转嫁条款。
捆绑还有第二个更隐蔽的成本：它把数字对客户藏了起来。一个从没看过工作单元趋势的客户，没有理由批准本可以削减用量的优化工作——重构浪费的查询、把重逻辑移到后端工作流、在激增前购买工作单元档位而不是事后支付原始超额。透明的转嫁计费把用量变成你们双方共同关注的共享仪表盘，这是唯一一种让优化工作自己卖自己的安排。
解决办法：把平台支出变成转嫁成本
转嫁成本是代理公司代表客户支付的费用——供应商订阅、用量账单、许可费——这些费用会转开给客户，或按成本、或加收手续费。这个概念在代理公司会计中是标准做法：客户自己的成本流经你的账本，而不成为你的收入。应用到无代码平台，有三种可行模型。为每个客户在 App 上线前以书面形式选定一种。
模型 1：客户持有供应商账户并直接付费。 客户创建自己的 Bubble 或 Webflow 账户，绑定自己的卡，拥有套餐、档位和超额。你的代理公司作为协作者或访客编辑被邀请进入。这是最干净的方式——计量账单从不接触你的账本——也是拥有自己财务团队的大客户的合适默认选项。已知的缺点：客户有时为了省钱在套餐档位上投入不足，造成性能瓶颈和触及上限的宕机，然后由你来诊断和解释。如果选择这个模型，在交接文档中写明最低档位建议，并加一条条款说明低于该档位运行的风险由客户承担。
模型 2：代理公司付费并按成本加价转开。 你持有供应商账户，用自己的卡支付平台账单，每月向客户开具准确平台支出的发票外加手续费——通常是转嫁金额的 10% 到 20%，这是大多数代理公司用来覆盖供应商管理、对账和垫付资金的区间。这个模型适合想要一张发票、零供应商管理负担的小客户。你的合同必须写明加价百分比、开票节奏，以及——关键的是——供应商涨价自动转嫁。没有最后这句话，每一次 Bubble 或 Webflow 调价都会重新打开你的定价谈判。
模型 3：带用量上限和超额条款的捆绑关怀计划。 你报一个固定月费，包含规定上限以内的平台支出——例如"包含 Growth 套餐以及每月最多 150 美元的工作单元超额"——超过上限的部分按成本加价转开。这给客户正常月份的预算可预测性，同时把激增风险留在它该在的地方。上限必须同时写明套餐档位和美元超额额度；没有数字的"包含托管"就是模型 0，正是你想逃离的陷阱。
无论选择哪种模型，工作说明书中都应包含五条条款：谁持有供应商账户、登记的是谁的卡；谁支付超额和档位升级，以及在多少美元阈值以上购买档位需要书面批准；转开支出的加价百分比；随发票每月发送的用量报告，显示额度、消耗和趋势；以及客户认可供应商标价变化自动转嫁而无需修改合同。第五条是代理公司最常忘记、日后最需要的一条。
正确记账：报销款不是你的收入
一旦平台支出流经你的代理公司，记账就必须让它与你实际赚的钱保持清晰分离。假设 Bubble 为某客户 10 月的超额向你的卡收取 300 美元——一百万额外单元，每千个 0.30 美元——你向客户转开 345 美元：300 美元按成本加 15% 手续费。你从这张发票获得的真实收入是 45 美元，而不是 345 美元。把全部 345 美元记为收入会虚增你的营收顶线，抬高任何基于收入的税务或估值计算，并让随后的退款或信用变成收入冲减，而不是它本来的样子：客户资金流经而已。
会计准则也同意这一点。根据 ASC 606，主要责任人与代理人的框架询问你在服务转移给客户之前是否控制该服务。你不控制 Bubble 的计算资源或 Webflow 的带宽——供应商控制——所以对于转开的平台支出，你的代理公司是代理人，正确的列报是净额：加价作为服务费收入，报销款通过配对的转嫁科目轧平。具体来说，保持两对账户：转嫁收入与转嫁支出配对，服务费收入单独列示。转嫁这对科目每月应大致轧平至零，视时间差而定；加价留在服务费收入里，你的利润率在那里衡量。
这是它在纯文本会计中的样子。代理公司用自己的卡支付 Bubble 的 300 美元超额费用，然后向客户开具 345 美元的发票：
2026-10-01 open Assets:Checking:Operating USD
2026-10-01 open Assets:Receivable:Client-Acme USD
2026-10-01 open Expenses:Passthrough:Bubble-WU USD
2026-10-01 open Income:Passthrough-Reimbursement USD
2026-10-01 open Income:Fees:Hosting-Markup USD
2026-10-31 * "Bubble" "October WU overage, client Acme app, 1M units at 0.30 per 1K"
Expenses:Passthrough:Bubble-WU 300.00 USD
Assets:Checking:Operating -300.00 USD
2026-10-31 * "Acme Corp" "October platform reimbursement plus 15 percent hosting admin fee"
Assets:Receivable:Client-Acme 345.00 USD
Income:Passthrough-Reimbursement -300.00 USD
Income:Fees:Hosting-Markup -45.00 USD梳理一下逻辑。第一笔交易把供应商收费记为转嫁支出，而不是你自己的软件成本——把它放在普通运营费用里，正是让你的成本基数显得臃肿、利润率显得单薄的错误。第二笔交易拆分客户发票：300 美元与报销款科目抵冲，与支出轧平至零，只有 45 美元加价落入服务费收入。如果客户对超额有争议或 Bubble 发出信用抵扣，调整只影响转嫁那对科目，你的申报收入永远不动。文档对这种账户结构模式有更深入的介绍，Fava 会把转嫁那对科目渲染成独立的一块，让你每月一眼确认它轧平至零。
两个记账习惯能让这套做法持续下去。第一，每月按客户核对平台支出，同时对照供应商发票和你的转开账单——用量仪表盘偏离发票的频率比你想象的高，你跳过核对的那个月，就是某个档位悄悄续订的月份。第二，永远不要让客户的平台余额跨季度挂在你卡上；每月按与你的服务费相同的付款条件开转开发票，因为一个未转开的 600 美元超额费在费用里越积越久，就是一笔你从未同意提供的无息贷款。
你的下一步：审计你已经签下的合同
这周就翻出你现有的主协议和工作说明书，搜索制造这个风险的那句话：任何附在固定数字上的"包含托管"变体。对每一份，检查它实际描述的是三种模型中的哪一种——客户付费、加价转开、还是带上限的关怀计划——以及五条条款是否齐全：账户持有人、超额责任、加价百分比、月度用量报告，以及供应商价格变化的自动转嫁。大多数代理公司会发现至少一个客户在无上限的捆绑里，至少一份合同对调价只字未提。
然后按续约顺序修复它们，从 App 增长最快的客户开始——下一次激增就落在那里。把新建项目从第一天起就转向客户持有的账户或明确的转开条款，把用量仪表盘放进月度发票，让计量账单做它该做的事：随客户的成功起落，由客户预算承担，而你的利润始终是你自己的。
