convex-cost

预估此应用的成本

成本意外往往源于少数几个函数读取的数据远超预期——这与 convex-advisor 针对性能标记的高读取模式相同，只是从成本角度来看。此能力让支出一目了然：它读取部署自身的字节数／文档读取证据，将其归因于相关函数，预测其随流量增长的情况，并指出成本最低的修复方案。它还遵循成本确认规范（Supabase 对付费操作的结构性确认）：任何按量计费的操作开始前，都要说明价格并获得明确同意。

工作流

1. GUARD：deploy-guard——成本读取对 dev/prod 部署只读（insights 仅适用于 cloud + 用户身份验证，不适用于预览环境）。说明目标部署。
2. GATHER：通过官方 MCP 收集支出证据：insights 用于获取字节数／文档读取事件（直接成本信号——Convex 按函数调用和带宽计费），tables 用于获取行数（表大小决定其扫描成本上限），functionSpec 用于了解函数表面。如果尚无使用量／流量，就说明这一点，并根据查询形态估算（预计会增长的表上执行 .collect()，即使今天流量为零，也会带来未来成本）。
3. ATTRIBUTE：按每次调用的字节数／文档读取量 × 实际（或用户询问的）调用量对函数排序——成本驱动因素是两者的乘积，而非其中任意一项。每次调用成本低但调用频繁的函数，可能比成本高但很少调用的函数影响更大；需展示这两个因素。
4. PROJECT：说明主要驱动因素如何随规模增长——全表 .collect() 会随表大小线性增长（数据累积会使成本不断叠加）；带索引的 .take(n) 则保持平稳。说明成本曲线的形态（“每次调用的复杂度为 O(table size)——1k 行时没问题，到了 1M 行就会产生账单”），不要给出看似精确的美元金额。
5. NAME THE CHEAPEST FIX：为每个驱动因素指出成本最低的修复方案——使用索引和 .withIndex 代替扫描，使用 .paginate／.take 代替 .collect，使用聚合组件统计数量，或缓存高频读取；并将其作为 cost 类发现发布到总线上（证据：insight 事件 + 预计增长情况），指向 convex-expert/convex-advisor 执行实际修改。
6. CONFIRM-COST：对于付费操作，如果流程包含任何按量计费的内容（购买域名、云资源配置、套餐变更），必须明确说明价格和周期性费用，并在继续之前获得明确同意——绝不能让付费操作作为副作用发生（成本确认门禁）。
7. REPORT：按排名列出当前成本驱动因素，并为每项提供证据、增长形态和修复方案；再给出直白的总结（“你的支出主要来自 messages:list 每次调用都读取整张表；为它加上索引，成本可降低约 100 倍”）。确保精度诚实：Convex 定价会变化且取决于套餐——提供相对成本／形态方面的指引，并引用定价页面获取绝对金额，不要编造总金额。

规则

• 成本 = 每次调用的数据读取量 × 调用量——始终展示这两个因素；调用频繁的低成本函数，可能比很少调用的高成本函数更贵。
• 读取部署自身的 insights／字节数读取证据来判断支出；如果尚无流量，则根据查询形态评估成本（对不断增长的表进行扫描会产生未来成本）。
• 给出增长曲线，而不是看似精确的金额：O(table) 扫描会随着数据累积不断叠加成本；带索引的访问则保持平稳。引用定价页面获取绝对金额。
• 每个成本驱动因素都要指出成本最低的修复方案，并在总线上发布 cost 类发现，指向负责修复的工具（convex-expert/advisor）。
• 对任何按量计费／付费操作都要进行成本确认：说明价格和周期性费用，并在操作发生之前获得明确同意——绝不能让其作为副作用发生。
• 对 dev/prod 部署只读（deploy-guard）；insights 仅适用于 cloud + 用户身份验证。成本分析沿用 convex-advisor 的证据，但以金钱而非延迟为视角。