你的 AI 功能满意度评分是 4.2/5，用户点赞率高达 68%，A/B 测试显示任务完成率提升了 12%。团队决定上线。六周后，用户已悄然绕开它，遇到真正重要的事情时不再使用。
这就是指标表演。你优化的是看起来像成功的信号，而不是真正的成功。你收集到的反馈来自那 8% 愿意评分的用户——偏向极度满意和极度不满的两端，对那沉默的大多数一无所知——他们发现该功能时不时不可靠，于是悄悄停止信任它了。
构建 AI 功能需要一套与传统软件不同的度量哲学。你从第一天起就埋下的信号，决定了你是否能足够快地学习并改进，还是花六个月追着一个纹丝不动的满意度分数跑。
大多数团队衡量 AI 功能质量时只问一个问题："它答对的频率有多高？"而更有用的问题其实是："答错的时候，摧毁信任的速度是否超过答对时积累价值的速度？"这两个问题的答案并不相同——只有后者才能告诉你究竟该不该发布。
存在一个可靠性下限，低于这条线的 AI 功能所造成的伤害，比完全没有该功能还要大。在这条线以下，用户在遭遇足够多的错误后会学会不信任 AI；而这种不信任会泛化——即便 AI 给出了正确答案，他们也会绕开它，最终彻底放弃使用。届时，你发布的不是一个部分有用的产品，而是一个披着功能外衣的转化率与留存率杀手。
当某家供应商宣布停用一个广泛使用的模型版本时，工程论坛上涌现出了告别帖子、请愿书和由用户撰写的迁移指南——这些用户的日常工作流都围绕着某个特定模型的行为指纹而构建。这不是软件弃用通常的走向。当你从 UI 中删除一个按钮时，用户会感到恼火。当你删除一个他们已经依赖的 AI 功能时，他们会感到失落。
这种不对称揭示了一个重要事实：弃用一个 AI 驱动的功能，从根本上比弃用传统功能更难。LLM 的行为包络——其语气、延迟特征、格式化倾向、响应长度——与功能的实际输出同样关键。用户不仅依赖 AI 做什么，更依赖它如何做。如果你的下架计划把 AI 退役当成 API 端点退役来处理，你将为这种错配付出流失代价。
有一家公司每位用户每月收费 50 英镑。其 AI 功能消耗了 30 英镑的 API 费用。这意味着在支付任何一笔退款或处理任何一个流失席位之前，剩下的 20 英镑还要覆盖主机、支持和利润。他们打造了用户喜爱的产品，发展到数千名订阅者，却在不知不觉中构建了一个客户越多、亏损越多的商业模式。
这并非关于坏主意的警示故事，而是关于定价架构的警示故事——这套架构从一个下一个用户边际成本几乎为零的世界照搬而来。当你的产品需要调用语言模型时，那个世界已不再完全适用。
传统 SaaS 毛利率为 70–90%。以 AI 为核心的公司报告的数字是 50–60%——差距主要由一行成本解释：推理。当 Token 占据销售成本的 20–40% 时，标准 SaaS 打法就会失效。
谷歌一份泄露的内部备忘录直言不讳："我们没有处于赢得这场军备竞赛的有利位置，OpenAI 也没有。"作者的论点是：用 LoRA 对模型进行微调大约只需 100 美元，开源社区可以在数月内复制闭源模型的能力，而且"我们没有护城河"。这是一位谷歌研究员在谈论谷歌自身的处境。如果世界上资源最雄厚的 AI 实验室内部都是如此，那对于押注数据优势的产品团队来说意味着什么？
诚实的答案是：大多数 AI 功能并非护城河，而是披着 UI 外衣的租用能力。但有些确实能真正复利积累——区别不在于你拥有多少数据，而在于数据真正创造防御性的特定机制条件。
大多数 AI 功能用自然语言描述需求，也用自然语言进行评估。产品经理写下"助手应当给出有帮助的回复，并避免有害内容"。工程师上线了一个 Prompt，演示时的输出看起来符合要求。团队在站会上达成共识，却在上线时产生分歧——边缘案例浮现，不同工程师对同一输出的评判各异，而"有帮助"这个词，不同评审者的理解竟有七种之多。
这不是工具问题，而是翻译问题。规格说明一直停留在抽象层面，评估标准从未被具体化。Spec-to-Eval 是一门在编写第一个 Prompt 之前，将英文需求转化为可证伪标准的方法论——提前做这件事，将从根本上改变迭代速度。
大多数 AI 产品把单个功能做对了，却把产品整体做错了。搜索返回了合理的结果，摘要表述连贯，对话助手给出了合理建议。但当用户搜索"小团队最佳方案"、在侧边栏看到推荐、向助手追问后续问题，再阅读自动生成的选项摘要——而这四者相互矛盾时——没有一个功能还能让人信任。这就是环境 AI 一致性问题：不是孤立的幻觉，而是产品层面的矛盾。
这种失败模式足够隐蔽，以至于团队往往完全忽视它。单个功能的评估指标看起来还不错。搜索团队衡量召回率和精确率，摘要团队衡量忠实度，对话团队衡量任务完成率。但没有人衡量产品各 AI 功能之间是否在讲述同一个事实的同一个故事。
这是一个按计划交付存在缺陷的 AI 功能的典型规格说明书（Spec）：“助手应准确回答客户问题并保持友好的语气。”每一位利益相关者都点头示意，产品需求文档（PRD）获得了批准。六个月后，团队在事后分析中争论 87% 的准确率是否可以接受 —— 而这是一个在发布前没有人想到要回答的问题。
这种失败并非技术性的。模型本身可能没有问题。失败之处在于直接从传统软件引入的需求格式没有为 AI 输出的核心属性留出空间：即它们是概率性的。“正确”不是一种状态，而是一个分布。你无法用一个用户故事（User Story）来定义一个分布。
大多数 AI 产品都以同样的方式走向终结。演示（Demo）很成功。测试用户赞不绝口。你发布了产品。然后，在大约三个月后，会话时长（session length）下降，功能闲置，你最活跃的早期用户开始绕过 AI，直接使用底层工具。
这不是模型质量问题，而是信任校准（trust calibration）问题。
“过度信任 → 失败 → 过度修正”的生命周期是 AI 产品采用率最可靠的杀手，而且如果你理解发生了什么，这几乎是完全可以预防的。研究已经很明确，失败模式是可预测的，设计模式也已经存在。大多数团队在看到留存曲线并想弄清楚出了什么问题之前，都会忽视这一切。
大多数 AI 团队在产品发布六周后都会遇到同样的瓶颈。最初的演示令人印象深刻，原型按时交付，早期用户也褒奖有加。然而，"足以展示" 和 "足以留住用户" 之间的鸿沟变得无法避免。团队手忙脚乱——调整提示词、更换模型、添加防护措施——但产品却几乎纹丝不动。
那些真正能快速改进的团队有一个反直觉的习惯：他们花在架构上的时间较少，而花在审视数据上的时间更多。不是仪表盘。不是汇总指标。而是对话日志中那些原始的、糟糕的、单独的失败案例。
这是一份实践指南，旨在区分快速发展的 AI 团队和停滞不前的团队。
许多用户认为 Bench 的界面直观、易用，信息布局清晰。特别是作为云端服务，用户可以随时随地访问自己的账簿，实时了解公司财务状况。不过，一些功能层面的不足也被频繁提及。例如，Bench 缺少移动端支持：用户无法通过手机上传票据等财务文件，这被认为是产品的一大弱点。另外，Bench 仅支持现金制记账，不提供权责发生制，会计需求较复杂的企业对此感到不满。尽管 Bench 能连接银行账户自动导入交易，但有用户抱怨实际操作中自动化程度不足——银行账户连接后仍需手动上传每笔交易凭证并自行分类。在报表功能上，Bench 提供的报告种类有限。有用户反映 缺少关键财务报表（如工资单汇总或供应商支出明细），实际拿到的只有利润表和年终报表，而且不同科目混在一起，使人无法确定分类是否正确。这些反馈表明，尽管 Bench 基础体验尚可，但在高级功能和易用性细节上仍有改进空间。
数据准确性方面，一些用户对 Bench 提供的账簿准确性表示担忧。有客户发现 Bench 交付的账目存在大量误分类和错误。例如，一位用户提交了所有所需文件，但两个月过去账簿仍未完成，且已完成的部分包含数以百计的分类错误。该用户连续两个月收到不准确的月度账簿，如果按这些数据报税将严重多缴税款。另一位用户直言对 Bench 在过去三年整理的账簿**“不再有信心”，因为多次发现分类不当，需要自己一再核对、逐项调整。总的来看，延迟交付和遗漏错误**是用户频繁提及的痛点。Bench 官方承诺一定时间内（如10-15天）完成历史账簿整理，但实际可能严重超时：上述用户提到原本承诺两周完成的历史账簿，近两个月都没有下文。此外，延误还影响到了报税：有用户抱怨 Bench 直到报税截止前才告知无法及时完成账簿整理，导致用户只能申请延期申报。在税务季节，高负载还导致沟通响应变慢——一位 G2 用户提到每逢报税季 Bench 回复速度会有所下降。除了账簿错误，Bench 的专业支持也出现过纰漏。比如，有用户指出 Bench 在有关 PPP 贷款减免的技术信息上多次出错，并不具备宣称的专业水准。数据和专业性的不足让部分客户对 Bench 的信任度降低，认为需要投入额外精力核实 Bench 的成果。
Bench 在客户支持和沟通方面的口碑近年大幅下滑，这是用户投诉最多的领域之一。许多用户抱怨 沟通不畅，具体表现为：负责其账户的 簿记团队成员更换频繁，内部交接不充分，导致新人接手时对客户情况不熟悉；当用户遇到问题时，往往难以及时联系到客服或负责的会计师。多位客户反馈自己的消息在工作平台上长时间无人响应，等待数周也得不到答复。有些甚至预约了支持电话却无人按约来电。同时，不止一名用户提到被不同支持人员来回推诿，收到的答复前后不一致，问题长期悬而不决。例如，一位客户无奈表示，Bench **“几乎无法联系上”**支持团队，感觉整年支付的费用就像打了水漂。还有用户分享了更糟糕的经历：在三个星期里辗转与 9 个人沟通却仍未解决一个简单问题，期间多次遇到无人回电、预约被爽约的情况。最后当该用户因不满而措辞激烈时，Bench 的负责人非但没有道歉解决，反而指责用户语言不当。总体来看，很多老客户表示 Bench 服务态度和响应速度在最近两年严重恶化，从前创业初期的用心沟通变成了如今的冷漠疏离。客户服务体验的滑坡，正在侵蚀用户对 Bench 的忠诚度。
价格和价值是用户关注的另一重点。Bench 定价不菲，基础套餐起步约为每月 $299，美金，在同类簿记服务中属于较高水平。许多用户认为 Bench 性价比不高，因为支付了高昂费用却未获得等值的服务质量。有评论指出，相比其他服务商，Bench 的价格高出大约三倍，但客户服务质量却不尽如人意。一个典型案例是，一家年收入仅 $1.5 万美元的小企业，使用 Bench 报税竟被收费 $7,500， 美金，这令用户难以接受。他直言自己“为糟糕服务付出了过高的代价”。在社交平台上，也有人坦言 Bench “并不划算”，因为如果工作完成不了或结果不准确，就算价格再低也是浪费。此外，关于收费的不满还体现在 扣费策略 上：有用户取消服务后仍被继续扣款，出现重复收费的情况。还有用户在 Bench 突然关闭后，被要求继续履行此前签署的分期付款合同，即使服务已终止，这让人觉得受到了欺骗和误导。一些用户用“骗局”这样的字眼来形容自己的遭遇。除了价格本身，涨价和推销 也引发反感。有用户感觉 Bench 近年频繁上涨订阅费用，或者在服务过程中不断推销额外的增值服务，让用户产生反感。总体而言，偏高的收费与不理想的服务成果之间的落差，导致用户对 Bench 的价值主张产生质疑。
Bench 号称将软件自动化与人工簿记相结合。在集成方面，Bench 可以连接用户的银行账户，实现交易记录的自动拉取。这对主流银行账户通常有效，但一些用户反映 Bench 对小型银行的支持不佳——某些小型银行账户难以成功链接到 Bench。即使账户连接成功，数据同步的可靠性也存在问题。用户指出 Bench 的银行连接经常掉线，需要他们重复输入网银密码来重新连接账户，非常麻烦。自动化功能方面，不少反馈表明 Bench 的承诺与现实有差距。按理说，连接银行账户后系统应自动 分类支出类别，但实际许多时候用户仍需手工介入处理。曾有客户吐槽：“所有账户都连上了，但我还是得上传每一张单据，手动分类每笔交易；我自己用 QuickBooks 做也没比这更麻烦。” 这说明 Bench 的自动分类和整理算法可能不够智能，让用户感觉不到效率提升。在第三方服务整合方面，Bench 之前将报税外包给合作伙伴 Taxfyle，一些长期用户反馈当时运转良好。然而 Bench 改为内部税务服务后，品质不升反降。有 6 年资深客户指出，新上线的内部税务团队表现不尽如人意：回复慢、错误多，导致报税严重延期。此外，Bench 不支持与其他会计软件的直接整合（毕竟它本身就是 QuickBooks 等软件的替代品），但这意味着从 Bench 切换到别的平台比较麻烦，一旦不满想迁移数据会有障碍。功能局限还体现在 记账方式 上。正如前文提及，Bench 仅支持现金制而无法处理权责发生制核算，这让有该需求的企业无法用 Bench 完成完整的财务管理。总结来看，Bench 在自动化和集成上的卖点没有完全兑现：对于很多中小企业用户而言，连接银行的基础自动化减轻了一部分工作量，但远未达到完全免操心的程度，一些必要的第三方工具（如更复杂的报表、库存/薪资系统）也缺乏衔接支持，这构成了用户使用中的一大痛点。
基于上述反馈，Bench 用户对新功能和改进也有一些共通的期待：
来自不同渠道的用户评论进一步印证了上述问题：
综合各渠道反馈，Bench.co 用户的核心痛点集中在以下方面，并据此提出相应的产品改进建议：
服务及时性和可靠性不足：从日常簿记到年度报税，Bench 多次未能按承诺及时完成工作。严重时导致用户错过法定期限，不得不申请延期，甚至遭受罚款。改进方向：产品经理应优先优化内部流程和资源分配，提高交付准时率。例如，引入进度跟踪和提醒系统，设置明确的服务SLA（服务级别协议）来确保每月结账和报税按时完成。一旦发现进度延误，要及时主动通知客户并提供解决方案，以减少用户的不安。
沟通与支持体验差：用户对 Bench 客服响应慢、沟通不专业的问题反响强烈。反馈包括难以联系到支持人员、团队内部移交不当导致答复前后矛盾等。改进方向：加强客户支持体系。具体举措可以是：为每位客户配备专属账户经理或小组，确保有人对该客户的账目全面负责；制定严格的响应时限，对于客户询问在工作时段内保证例如 24 小时内答复；改进内部知识管理，确保不同支持人员共享同一客户的信息，避免重复问询。还应培训客服人员在高压情境下的沟通技巧，以同理心和解决问题为先，而非简单敷衍或指责客户。
数据准确性与专业度不够：部分用户质疑 Bench 提供的财务数据可靠性，指出分类错误、账目不完整等问题。甚至有案例显示，如果依赖 Bench 数据报税可能会出大错。此外，Bench 团队在专业知识上也曾出现纰漏（如 PPP 政策解读错误）。改进方向：提高账务处理的准确性和专业性。可以引入更严格的质量审核流程，在月度报表出具前由高级会计师复核；运用机器学习改进自动分类算法，让常见交易科目分类更准确；针对新员工加强培训和考核，确保他们熟悉最新的财税法规。对于政策性咨询（如 PPP 贷款），应明确边界，避免在不确定时给出错误信息，可以考虑提供官方资源链 接或建议用户咨询注册会计师，以免因为错误指导而影响公司声誉。
价格与价值不匹配：不少客户觉得 Bench 收费昂贵但服务质量未达到应有水平，性价比偏低。尤其当服务出现问题时，高昂的价格更让人不满。改进方向：一方面，优化定价策略，根据企业规模和需求提供更灵活的套餐，比如针对创企的低价基础包，随着业务增长再逐步升级收费。这可以降低小客户对于高价的抗拒。另一方面，提升附加值来匹配价格，例如在高阶套餐中增加每季度财务健康检查、年度税务规划咨询等服务，让用户感到物有所值。如果 Bench 能通过卓越的服务证明其专业性和可靠性，用户对价格的敏感度也会降低。
产品功能局限：Bench 当前的功能范围无法满足一些用户需求。例如，仅支持现金制记账使其无法服务需要权责发生制核算的公司；移动端功能匮乏，用户无法通过手机完成关键操作；自动化集成不完善，用户仍需投入大量人工操作。改进方向：扩展产品功能以覆盖更多场景。优先考虑上线权责发生制记账功能模块，哪怕作为高级版选项，也能填补空白市场。加快移动应用开发，至少实现收据拍照上传、交易快速分类、报表随时查看等核心功能，迎合移动办公趋势。在自动化上，与更多银行和支付平台深化技术对接，减少账户连接中断的情况，并增加对接常用第三方工具（如电子商务平台、工资薪酬系统）的数据导入导出功能，打造更完善的财务生态。
信任和透明度：Bench 近期发生的突然关停及被收购事件重创了用户信任。一些用户因措手不及而蒙受损失，对公司未来的稳定性产生质疑。改进方向：增强业务透明度和风险管控。公司层面应制定清晰的紧急沟通预案，一旦业务出现变动（如重大财务困难或战略调整），及时通过邮件、站内通知等渠道告知付费用户可能的影响。确保用户数据安全可取：提供“一键导出”全部财务数据的功能，让用户在任何时候都能备份自己的账簿。此外，签订服务协议时增加相应条款，在 Bench 无法履约时保障客户的预付款权益（退款或由收购方继续服务）。通过这些措施，逐步重建用户对 Bench 可靠运营的信心。
综上所述，Bench.co 需要在产品和服务两个层面同步改进。产品经理应当把用户反馈的痛点转化为具体的优化项目，从提升系统稳定性、丰富功能，到改进客户支持流程、重塑定价策略，均有明确的努力方向。尤其是在当前竞争激烈的线上簿记市场，用户体验的好坏直接决定了公司的口碑和存续。只有切实解决了用户的核心痛点，提高了用户满意度，Bench 才能重新赢得小企业主们的信任，在未来的市场竞争中立于不败之地。
深入探讨区块链基础设施领导者的商业模式
Web3 基础设施公司 QuickNode 最近在 B 轮融资中筹集了 6000 万美元，估值达到 8 亿美元。即使在加密货币市场低迷时期，他们仍然保持着令人印象深刻的增长。然而，尽管人们大多关注他们的技术和市场地位，但一个关键问题仍然存在：QuickNode 究竟是如何赚钱的？
让我们来解析他们的收入模式、定价策略，以及他们如何在加密货币最具挑战性的时期实现 4 倍的年同比增长。
QuickNode 建立了一个多元化的业务，拥有四个不同的收入来源：
QuickNode 的核心业务是其节点即服务平台，分为两种类型：
自助服务计划
企业合同
这一核心业务的运作类似于 AWS 或 DigitalOcean 等云基础设施提供商，但专门针对区块链网络。定价模式遵循一个熟悉的模式：为开发者提供低价（或免费）起步，然后随着使用量的增长而扩展。
2022 年 5 月，QuickNode 收购了 NFT 分析平台 Icy Tools。此次收购：
这一战略性收购显示了 QuickNode 如何从原始基础设施扩展到更高层次的服务。
借鉴云平台的经验，QuickNode 推出了一个市场：
虽然仍处于早期阶段，但这一平台战略遵循了 Salesforce、AWS 和其他云领导者开创的成功模式——创建一个开发者扩展平台价值的生态系统。
一个常被忽视但具有战略价值的收入来源：
这一巧妙的业务发展策略有效地让区块链网络为 QuickNode 的平台扩展提供补贴，为双方创造了双赢局面。
QuickNode 的商业模式结合了高利润软件公司的几个特点：
像所有基础设施业务一样，QuickNode 受益于显著的规模经济：
订阅模式创造了可预测的经常性收入，而基于使用的组件推动了自然扩展：
QuickNode 遵循现代开发者工具的游戏规则：
QuickNode 的定价页面展示了一种复杂的方法：
开发者层（免费）
增长层（49 美元/月）
专业层（99 美元/月）
企业层（定制定价）
这种分级方法展示了经典的“好、优、最佳”SaaS 定价策略，随着客户的扩展，提供明确的价值步骤。
QuickNode 报告了几个令人印象深刻的增长指标，揭示了他们的收入模式：
最具说明性的是，QuickNode 在加密货币熊市中保持了这一增长轨迹——这表明他们的收入更多地与基础设施使用相关，而非投机活动。
展望未来，QuickNode 有几个明确的收入增长路径：
垂直扩展
企业渗透
地理扩展
为了将 QuickNode 的模型置于背景中，比较一下成熟的云基础设施公司：
| 公司 | 收入倍数（约） | 毛利率 |
|---|---|---|
| MongoDB | 13x | 70-75% |
| DataDog | 20x | 75-80% |
| Cloudflare | 18x | 75-80% |
| Digital Ocean | 3x | 55-60% |
| Alchemy（竞争对手） | 150x（报告） | 未知 |
| QuickNode | 未知，但可能为 10-20x | 估计 70-75% |
虽然 QuickNode 的确切利润率尚未公开，但他们的商业模式最类似于高利润的基础设施即服务公司。与传统托管相比，缺乏硬件管理表明其利润率类似于 Cloudflare 等软件定义基础设施提供商。
QuickNode 商业模式最令人印象深刻的可能是其经受市场周期的能力。即使在 2022 年 NFT 交易量和代币价格暴跌时，QuickNode 仍在增长。这表明：
QuickNode 的多元化收入模型展示了区块链基础设施的成熟。通过专注于基础——可靠的服务、多元化的收入来源、分级定价和企业关系——他们建立了一个无论市场条件如何都能蓬勃发展的业务。
随着区块链技术从投机转向实用，像 QuickNode 这样提供基本基础设施的公司将受益于日益增加的现实世界采用。他们能够从加密货币原生公司和主流企业中产生收入，使他们成为这两个世界之间的桥梁——并可能成为长期可持续的业务。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
