82 篇博文 含有标签「ai」

Slack 发现，交换了 2,000 条消息的团队以 93% 的比率转化为付费用户。这一洞见回头看似乎显而易见——活跃团队会留下来——但不那么显而易见的是工程层面的后果：Slack 围绕让团队达到这一消息数量来构建整个引导流程，而不是围绕功能演示或能力说明。他们通过使用 Slack 来教会用户 Slack。

AI 功能面临同样的问题，但更难。不存在"发送第一条消息"这样的等价物，因为能力层面是不可见的。面对空白提示框的用户对可能性没有任何直觉。这就是魔法时刻问题：你的产品拥有变革性能力，但用户在亲眼见到之前无法想象，而除非你设计好路径，否则他们永远看不到。

数据让这个问题变得紧迫。2024 年，17% 的公司放弃了大部分 AI 计划。2025 年，这个数字跳升至 42%——单年增长 147%。技术在进步；引导没有。

Cursor 在 2025 年实现了 10 亿美元营收，却亏损了 1.5 亿美元。客户支付的每一分钱都直接流向了 LLM API 供应商，工程、支持和基础设施开销无从覆盖。这不是一个规模化问题——而是一个单位经济学问题，在酿成危机之前始终隐而不见。

大多数构建 AI 功能的工程团队都在犯同一个错误：把推理成本当作一个无关紧要的小项，上线固定费率订阅，然后假设经济账迟早会算对。但它永远不会自己算对。可变推理成本的行为方式与软件中任何其他 COGS 都截然不同——一旦你最重度的用户发现了你最昂贵的功能，那些适用于传统 SaaS 的定价架构就会让你流血不止。

有一家公司每位用户每月收费 50 英镑。其 AI 功能消耗了 30 英镑的 API 费用。这意味着在支付任何一笔退款或处理任何一个流失席位之前，剩下的 20 英镑还要覆盖主机、支持和利润。他们打造了用户喜爱的产品，发展到数千名订阅者，却在不知不觉中构建了一个客户越多、亏损越多的商业模式。

这并非关于坏主意的警示故事，而是关于定价架构的警示故事——这套架构从一个下一个用户边际成本几乎为零的世界照搬而来。当你的产品需要调用语言模型时，那个世界已不再完全适用。

传统 SaaS 毛利率为 70–90%。以 AI 为核心的公司报告的数字是 50–60%——差距主要由一行成本解释：推理。当 Token 占据销售成本的 20–40% 时，标准 SaaS 打法就会失效。

你会通过一张截图发现它。

客户会把它发出来，记者会引用它，或者团队里的某个人会在晚上 11 点在 Slack 上给你发个链接。你的 AI 系统言之凿凿地给出了错误的答案 —— 错到滑稽，或者错到可能伤及他人 —— 而且现在已经公开了。

大多数工程团队花费数月时间强化他们的 AI 流水线以防这一时刻的到来，却发现他们从未计划过一旦这一时刻到来该怎么办。他们知道如何迭代评估（evals）和调整提示词（prompts）。他们不知道该由谁来发布回复推文，该回复应该说些什么，或者如何区分是一次性的倒霉样本，还是已经在生产环境中运行了数周的潜在故障模式。

这就是针对那一刻的应对指南。

一个单步可靠性为 95% 的代理听起来相当出色。但在执行 10 步任务时，成功率降至 60%；20 步时降至 36%；50 步时只剩约 8%——而这还是基于 95% 这个乐观的估计。实际数据显示，真实世界中代理每步操作的失败率接近 20%，这意味着一个 100 步的任务成功率约为 0.00002%。这不是模型质量问题，也不是提示工程问题，而是一个复合数学问题——而大多数构建代理的团队还没有真正内化这一点。

这就是委托悬崖：当你给代理的任务多增加一步时，失败率不是线性增加，而是成倍放大。

谷歌一份泄露的内部备忘录直言不讳："我们没有处于赢得这场军备竞赛的有利位置，OpenAI 也没有。"作者的论点是：用 LoRA 对模型进行微调大约只需 100 美元，开源社区可以在数月内复制闭源模型的能力，而且"我们没有护城河"。这是一位谷歌研究员在谈论谷歌自身的处境。如果世界上资源最雄厚的 AI 实验室内部都是如此，那对于押注数据优势的产品团队来说意味着什么？

诚实的答案是：大多数 AI 功能并非护城河，而是披着 UI 外衣的租用能力。但有些确实能真正复利积累——区别不在于你拥有多少数据，而在于数据真正创造防御性的特定机制条件。

你的模型在留存测试集上达到了 91% 的准确率。p95 延迟低于 200ms。与之前的规则系统相比，错误率降低了 40%。从每一个技术指标来看，这个项目都是成功的。六个月后，领导层取消了它。

这不是假设。80% 的 AI 项目未能实现预期的商业价值，而这些失败的大多数并不是由于模型性能不足。它们源于工程师所衡量的内容与决策者所能理解的内容之间的鸿沟。技术团队使用的语言，高管无从评估——在缺乏可理解信号的情况下，领导层默认持怀疑态度。

指标翻译问题并非沟通软技能，而是一门工程纪律，而大多数团队把它当作可选项，直到融资审查前夕才想起来。

你的系统平均端到端延迟为 400ms，p95 是 4.2 秒，p99 是 11 秒。在产品规格中你承诺了"亚秒级"体验。仪表盘上的每个指标看起来都很正常，直到有人问起 5% 的用户遭遇了什么——这时，你一直引以为傲的平均值才成了埋葬你的东西。

这就是 AI 功能的延迟预算问题，它与你之前解决过的问题有着本质区别。当核心组件是数据库查询或微服务调用时，p95 延迟大致可预测，并且适用标准 SRE 技术。而当核心组件是 LLM 时，响应时间的分布呈重尾特征，依赖于输入，并且部分由你无法控制的条件驱动。在制定诚实的 SLO 之前，你需要一套不同的思维模型——更别说去达成它了。

最有望从 AI 中获益的团队，往往是最晚部署 AI 的。一家能够利用 AI 实时发现用药错误的医疗机构，其 AI 采纳率仅为 39%；而一家运行 AI 代码审查的软件公司，采纳率高达 92%。两者的 ROI 差距悬殊——然而采纳率却完全颠倒。这就是 AI 采纳悖论，而且它绝非偶然。

人们的本能是将这种差距解释为规避风险、监管恐惧或官僚惰性。这些因素确实存在。但更深层的原因是结构性的：在高风险领域释放价值所需的准确率阈值，从根本上高于自主部署所能证明合理的水平，而大多数团队尚未构建出弥合这一差距的架构。

你的 AI 功能上线了。A/B 测试运行了两周。处理组看起来更好——参与度提升 4%，p 值低于 0.05。你将其全量发布。

六周后，收益消失了。参与度回到了原点，甚至更低。你的实验说了一件事；现实说了另一件事。

这不是偶发案例，而是将标准双样本 A/B 测试应用于 AI 功能时的默认结果——你没有考虑这种方法论中内嵌假设被打破的方式。这些失败模式是结构性的，而非统计性的——你可以按教科书完美地运行实验，却仍然得到错误答案。

你的团队比以往任何时候都能发布更多代码。PR 速度提升了，周期时间缩短了，积压也在减少。在管理者看得到的每一块仪表板上，一切都看起来很好。然而，每个 PR 对应的事故数量正悄悄地以每年 23.5% 的速度攀升。

这就是 AI 代码审查的悖论。AI 工具让工程师写代码更快，审查代码也更快——但最关键的缺陷正以比以前更高的比率漏过审查。这个悖论的两面相互叠加，而大多数团队并没有在衡量正确的指标来察觉这一点。

大多数线上故障的失败，并非因为缺乏工具，而是因为值班工程师在最需要的时刻无法快速获得足够的上下文。凌晨三点，工程师被一墙的触发告警惊醒，先花 20 分钟拼凑出到底哪里出了问题，再花 20 分钟判断该用哪份运维手册，等到真正开始执行修复时，故障已经持续了将近一个小时。而实际的修复动作可能只需要 5 分钟。

AI 能够将这个上下文收集窗口从 40 分钟压缩到 2 分钟以内。这才是真正摆在桌面上的价值。但"LLM 帮助值班工程师"并不是一个单一的产品决策，而是一系列决策的叠加，每一层都有其独特的失效模式，而某些失效模式的后果，远比客服聊天机器人幻觉严重得多。