AI 应用构建器的定价，取决于什么算作工作

对于每周 100 次提示词迭代，最便宜的套餐通常是每条提示词周边工作计得最少的那一个。在知道重试、规划步骤、测试运行、部署，以及后台运行的智能体是否都触及同一个计量标准之前，标出的月费几乎说明不了什么。

我见过团队用订阅价格除以 100 条提示词来比较套餐。这个算术很整齐，也很不对。改按钮文案的提示词和重构数据库的提示词，对输入的人来说都只算一条消息，但产生的账单可能完全不同。诚实的比较要先从工作负载台账开始，再把每家供应商的计费规则套用到同一份台账上。

本文使用的是假设的价格目录，并非任何具名供应商的实际价格。目的在于给你一套计算方法，在购买前可以把它替换成真实的套餐条款。

相同的提示词数量，可能藏着三种不同账单

用户消息数量衡量的是对话，而不是算力或已完成的工作。积分套餐通常计量模型活动，任务套餐计量供应商定义的工作单元，固定套餐则在一定边界内出售使用权。即使应用和每周 100 个请求完全相同，这些边界也会带来不同总价。

假设一位创始人每周提出 70 项小型界面改动、20 项涉及多个文件的改动，以及 10 项构建或部署改动。可见数量是 100。实际上，构建器可能会检查代码仓库、制定计划、多次调用模型、运行测试、修复失败的编辑、重新构建应用，并在聊天回复出现后继续运行智能体。一个套餐可能对每次模型调用收费，另一个会把整套流程算作一个任务。订阅套餐可能包含这些工作、设置上限，或将其中一部分列为超额费用。

买家经常混淆的正是这一点：一次迭代是用户作出决策的周期，而可计费事件是卖方选择计量的任何事项。把两者当成同义词，会让定价页面最模糊的套餐占便宜。等团队把应用交给平台后，看似便宜的套餐也可能变得昂贵。

比较时，应使用每月 4.33 周的系数，而不是假定每个月都有四周。每周 100 次迭代会变成每月 433 次迭代。这个小修正就增加了 33 次迭代，尚未计算任何重试或后台任务。

一份有用的报价请求会请供应商对工作分类，而不只是估算总价。请问：什么会启动计量？何时停止？失败运行是否计费？自动重试是否计费？界面显示回复已完成后，哪些工作还会继续？未用额度能否滚存？答案决定账单。

打开计算器前，先定义一份工作负载

根据你实际预期的工作建立一个有代表性的一周，然后在比较套餐前固定下来。如果针对每种定价模式改变工作负载，你测试的就是营销文案，而不是价格。

在这个计算示例中，我使用以下每周工作负载：

• 70 项小改动，每项消耗 1 个积分单位
• 20 项多文件改动，每项消耗 3 个积分单位
• 10 项构建或部署改动，每项消耗 5 个积分单位
• 25 次重试运行，平均每次消耗 2 个积分单位
• 35 次后台运行，共消耗 45 个积分单位

100 次请求的迭代在首次执行时消耗 180 个假设积分单位。重试增加 50 个。规划、索引、测试和部署工作增加 45 个。每周总计 275 个单位，平均每月为 1,190.75 个单位。

在按任务计费下，同一活动呈现出另一种形态。它每周会产生 100 次用户发起的任务、25 次重试任务和 35 次后台任务，共 160 个事件，每月 692.8 个事件。692.8 个是否全部计费，取决于合同对任务的定义。

将成功和失败的工作分开记录。只根据可见错误消息得出的失败率，会漏掉静默修复、自动模型回退和重新运行的测试。如果平台提供用量导出，它比聊天记录更有说服力，因为一条聊天回复可能合并了多次智能体运行。

选取包含日常混乱的一周：一条不清楚的提示词、一次依赖冲突、一项因无关原因失败的测试，以及一次部署修复。完美的演示周得出的预算，只能维持到真正开发开始前。

不要为了自我保护而夸大工作负载。应在计算观察到的基准后，再单独增加波动预留。将基准和预留分开，才能看清一个套餐是因正常工作而昂贵，还是因为你为繁忙月份买了保险。

积分包会对构建器内部的活动收费

当平台的单位价格低、未用积分能保留足够久、构建器很少需要修复时，积分包成本较低。当一个简单请求分散成用户看不见的多次模型调用时，成本就会上升。

积分不是标准单位。它可能代表 token、模型调用、智能体步骤、秒数，或加权混合指标。供应商也可能对快速模型和能力更强的模型收取不同积分。除非两个平台以相同方式定义消耗，否则比较两个积分包的积分数量没有意义，而这种情况很少见。

以一个 500 单位、价格 30 美元的积分包为例，为假设工作负载定价。每月需求为 1,190.75 单位。由于积分包不可拆分，买家需要三个包，支付 90 美元。如果积分不会过期，月底账户会剩下 309.25 单位。实际已消耗工作每单位成本约为 7.56 美分，尽管积分包标价是 6 美分，因为买家不得不购买未用容量。

滚存会改变结果。如果剩余的 309.25 单位能保留，次月可能只需购买两个包，而不是三个。经过数个稳定月份，平均成本会接近标价。如果积分按月过期，滞留余额就是价格的一部分，绝不能从模型中漏掉。

模型选择可以改变消耗，而无需改变提示词数量。如果平台将复杂编辑分配给积分系数为四倍的模型，最难的十个请求可能主导整张账单。要问清分配是否自动、事后能否看到、以及能否设置上限。一个失败并重试两次的低价模型，成本可能高于一次成功的高能力模型。

积分包适合不规律的项目，因为有工作发生时才付费，前提是积分有足够的有效期。对于自由试验的团队，它更难做预算。计量表会改变行为：人们可能把无关请求合并为过大的提示词、避免测试，或为了省积分而接受较差的输出。这些选择通过损害应用来降低账单。

尴尬的问题是，后台工作是否应消耗积分。它确实会消耗资源，因此收费有合理性。问题出在买家无法预测或停止它时。公平的评估应检查界面是否展示每一项后台收费，以及消费限额是否能在余额归零前停止新工作。

按任务计费取决于任务从哪里开始、在哪里结束

如果一个价格覆盖整次尝试，包括规划、模型调用、测试和修复，按任务计费可能是最便宜的模式。如果每个内部操作都变成一个新任务，它可能最昂贵。

对台账中的每个已启动事件套用每次 0.14 美元的假设费率。每月 692.8 个事件，四舍五入到美分后成本为 96.99 美元。尽管定价页面上的 14 美分看似很小，这仍高于 90 美元的积分包结果。

现在只改合同中的一句话：仅对 433 次用户请求的迭代收费，而将重试和后台工作包含在每个任务内。月成本降至 60.62 美元。应用没有任何变化，改变的是任务边界，而这个边界带来了 36.37 美元的差额。

按完成任务计费还需要另一个定义。如果一次运行改动了文件却部署失败，平台算完成任务了吗？如果用户拒绝结果并要求修正，这是新任务还是延续？供应商需要规则来防止一笔费用涵盖无限工作，买家也需要能够从活动日志中复现的规则。

“比较每条成功提示词的成本”这一常见建议并不对，因为成功往往由用户自行报告。用户会接受部分结果、拆分大型请求，也会手动修正输出。每次记录成功的低成本，可能掩盖数小时的清理工作。应比较每项已接受改动的成本，以团队会合并、部署或以其他方式保留结果的时点为准。

当单位对应人们能理解的事物时，任务定价在预算方面有优势。团队估算 400 项已接受改动，比估算数百万 token 更有把握。如果产品把索引、规划、测试和部署标为独立任务，这个优势就会消失。在把该单位视为稳定之前，先查看真实账单或用量导出中的事件名称。

还要问清并发如何计算。两个智能体同时运行可能缩短耗时，却让任务启动次数翻倍。一个生成测试智能体的后台修复，可能算一次、两次，或完全不算。账单遵循计量标准，而不是墙上时钟。

固定订阅只会在包含边界内获胜

若月费包含全部 433 次用户迭代、108.25 次重试启动和 151.55 次后台启动，固定订阅在这个工作负载下成本最低。只要任何类别不在订阅范围内，就应先加上它的费用，再宣布固定套餐更便宜。

使用一个每月 79 美元的假设套餐，其中包含最多 600 次交互和重试运行，以及 200 次后台运行。示例每月产生 541.25 次交互和重试运行，以及 151.55 次后台运行。两项都在范围内，因此成本维持在 79 美元。在这些假设下，固定定价优于 90 美元的积分包和 96.99 美元的已启动任务套餐。

“无限”这个词在电子表格中不该有任何价值。应把它替换为实际的合理使用阈值、并发限制、模型限制或降速规则。如果供应商不说明边界，就建模低用量和高用量两种情形。只有在无边界解释下才显得便宜的套餐，没有给你可靠价格。

固定套餐也会产生阶梯式成本。599 次包含运行时，多一次可能不花钱。达到 600 次后，下一次运行可能触发超额费用或迫使你升级套餐。至少绘制三个工作负载水平：安静月份、预期月份和发布月份。只看预期情形会掩盖订阅跳档的位置。

当计费跟随用户而不是工作时，席位很重要。一个人的 79 美元套餐，若必须有四个席位就是 316 美元，即使团队共享同样的 433 次迭代。不要假设允许共享账户。应为需要审核提示词、批准部署或检查用量的人定价。

固定费用能鼓励健康的试验，因为每个失败想法不会产生可见的小额收费。它也可能把浪费藏起来，直到平台限制账户。用量可见性依然重要。你需要知道智能体是否在循环，以及发布月份是否会越过包含边界。

年度折扣应最后才纳入计算。先找出按月条款下最便宜的模式，再计算折扣和承诺成本。为一个三个月后被弃用的工具支付十个月，并不是节省。

重试应属于基准，而不是脚注

重试是正常开发工作，因此假定首次输出完美的价格比较不适合采购。真正有用的数字是重试放大系数：总尝试次数除以请求的迭代次数。

示例中，100 次请求迭代对应 125 次交互尝试，重试放大系数为 1.25。这不代表 25% 的提示词只是失败。有些请求需要澄清，有些编辑通过了代码检查却偏离意图，也有些失败来自工具或依赖。只要套餐对另一次尝试计量，计费影响就相同。

用一个两人都能一致执行的规则来衡量重试：当用户拒绝或修复前一次输出后，再次提出同一预期结果时，就算一次重试。真正的新需求不算重试。自动重试要单独标记，因为用户可能根本看不到它们。

小型试点应包含你预计会困难的任务。如果只测试落地页文案和颜色变更，重试率对数据库迁移、身份验证、状态管理或移动端构建几乎没有说明力。让每个候选方案至少处理一项高风险改动，并检查活动记录。

重试对不同模式的影响如下：

• 积分计费通常对每次尝试消耗的资源收费。
• 已启动任务计费通常会在重试生成事件时对每次尝试收费。
• 按完成计费可能吸收失败尝试，取决于它的完成规则。
• 固定计费会吸收重试，直到达到包含上限或合理使用控制。

不要把免费重试当成完整答案。应询问重试是否使用相同模型、自动回退是否消耗独立额度，以及免费重试窗口会保持多久。即使工作显然相同，第二天早上提交的修正也可能变成新任务。

还有人的重试成本。如果用户必须监督每次修复，一个套餐可能美元成本很低，注意力成本却很高。试点期间跟踪每项已接受改动所需的审核分钟数。不必把这段时间硬塞进平台账单，但应把它列在账单旁边，以免低价掩盖糟糕的工作流程。

后台智能体是看不见的放大器

后台智能体工作必须单列一行，因为它可能在用户看到回复后继续运行。代码仓库索引、规划、依赖检查、测试、构建监控、部署和修复智能体，都可能在不新增聊天消息的情况下消耗预算。

示例每周分配 35 次后台运行和 45 个积分单位。这些数字是刻意公开的假设，应替换为试点的用量记录。如果供应商只提供一个合并总数，可在关闭可选自动化的情况下运行一次相同提示词，再开启自动化运行一次。差额只是估计，不是证据，但比把这些工作当作免费更好。

规划模式值得特别关注。规划可能通过及早发现冲突来减少昂贵的失败实现，也可能在每个小编辑前增加一个付费步骤。应分别在小改动和大改动上测试。合适的策略可能是对模式变更和多文件工作使用规划，而对文案编辑跳过规划。

索引具有不同的成本形态。首次扫描代码仓库可能很昂贵，后续增量更新成本却很低。如果一周试点包含初始索引，可能夸大稳态成本。如果生产代码仓库大得多，也可能低估成本。应将设置消耗和经常性消耗分开。

测试和部署不是可选的浪费。为了符合积分额度而关闭它们，只是把故障发现转移给用户。请为你打算运行的安全流程定价，包括保护它的检查。基于禁用测试的比较，回答的是错误的业务问题。

Koder.ai 支持规划模式、部署和托管、快照和回滚，以及源代码导出，因此试点可以观察这些工作流程环节，而不是只为聊天消息定价。套餐名称和价格仍需在当前产品界面中核实，因为这里的网站上下文只说明了层级，没有说明其当前额度。

如果产品允许，可以设置后台预算，但不要把上限与可预测性混为一谈。上限通过停止工作来防止超额支出。智能体等待更多容量时，应用仍可能错过发布。应同时记录财务限额和运营后果。

让每个候选方案通过同一份台账

台账能让比较可复现，并在账单争议发生前暴露合同中的模糊之处。每一行应描述一个计量事件，并提供足够背景，以便映射到积分、任务和订阅额度。

在试点期间复制并使用以下 CSV 表头：

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

将事件类型和结果分开记录。一次后台测试可以成功完成，而请求的改动仍未被接受。如果把这些事实压缩成一个状态，就无法检验供应商的完成任务规则。

每周结束时，计算四个数值：

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

然后在不改变行记录的前提下套用套餐条款。对于假设价格目录，计算如下：

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

电子表格还应显示滞留积分、剩余包含容量和下一个价格边界。示例中的胜出套餐还剩 58.75 次交互运行和 48.45 次后台运行。这点余量不足以应对部署工作翻倍的发布周，因此团队应在承诺前计算这种情形。

请供应商审阅一页匿名台账。不要问哪个套餐最便宜，而要问每一行会如何分类。书面分类比销售估算更有用，因为你可以将其与第一张账单对照。

波动比标价更重要

示例结果是固定订阅 79 美元、积分包 90 美元、已启动任务计费 96.99 美元。这个排序只适用于所述的价格目录和工作负载。重试处理方式或包含后台工作的微小变化，都可能颠倒排序。

计算每一对方案的盈亏平衡点。若未用积分没有未来价值，79 美元的固定套餐会在每月需求需要三个或更多 30 美元积分包时胜出。如果滚存能让买家用完每个单位，按每单位 6 美分计算，79 美元约等于 1,316.7 个积分单位。低于这一用量时，完全用掉的积分成本更低。

与每次 0.14 美元的已启动任务相比，79 美元约等于 564.3 个事件。预期的 692.8 个事件超过这个点。但如果任务套餐只对 433 次请求迭代收费，它的成本为 60.62 美元，反而胜出。一个定义再次比标题费率更重要。

不要假装估算精确，应运行敏感性情形。对于这个工作负载，将重试放大系数从 1.10 改到 1.50，后台工作从每周 20 个事件改到 60 个，并根据供应商披露的合理系数调整复杂编辑消耗。你不需要几十个情形，只需要能改变决策的少数变量。

将现金流和锁定风险与单位成本分开考虑。积分包可能保留灵活性。月度订阅在你仍处于边界内时提供可预测上限。年度订阅以灵活性换取折扣。源代码导出和快照可以降低离开构建器的成本，但不能让迁移免费。导出的应用仍需可用的构建、基础设施，以及能维护它的人。

用量不确定的创始人应偏向风险清晰可见的模式。即使预期月度总价略高，这也可能意味着选择可长期滚存的积分包。工作稳定且已测量的团队，可以购买额度中间位置附近的固定套餐。任务套餐适合能够清晰映射到已接受结果，并将修复工作包含在任务内的工作。

不要根据示例中的胜出者做选择。应先将每个假设费率和额度替换为你能指明出处的条款，再将每项工作负载假设替换为试点观察结果。

让计费模式通过验收测试

当另一个人能够根据台账和套餐条款复现月度总额时，定价模式才适合做决策。如果计算依赖销售人员事后解释一个内部任务，这个模式就没有通过测试。

使用这份简洁的验收清单：

1. 记录 100 次有代表性的请求迭代，或记录包含每种主要工作类型的较小样本。
2. 标记重试、自动重试、规划、测试、构建、部署和其他后台运行。
3. 将每个事件映射到供应商的积分、任务或包含额度规则。
4. 使用相同的 4.33 系数，计算预期月份、安静月份和发布月份的总额。
5. 保存套餐条款，并将第一张真实账单与预测进行比较。

在试点前设定容忍度。例如，你可以调查任何比预测高出 10% 以上的总额。这个百分比是管理选择，不是行业标准。它的作用是在事件历史仍然存在时促使你进行审查。

如果实际用量超过预测，找出责任所在的行类别。更多已接受工作不同于更多重试。更多计划内的部署运行不同于智能体循环。补救办法可能是升级套餐、收紧智能体策略、写出更清晰的提示词，或进行计费更正。单一总额无法告诉你是哪一种。

在前三个计费周期中，将台账放在账单旁边，因为安静的试点可能漏掉批量任务、发布工作和自动修复。因此，每周 100 次迭代最便宜的模式是有条件的，但决策不必模糊。按照明确的示例，79 美元的固定订阅胜出。按成功范围界定的任务计费下，同样的工作成本为 60.62 美元，任务计费胜出。积分包在用量较低或波动较大，且滚存能防止浪费时胜出。写下什么算数，衡量隐藏工作，让账单证明承诺。