61 篇博文 含有标签「ai」

一份干净的 PDF、一个强大的 LLM、三十行代码。演示成功了。你提取出了发票总额、合同日期、患者诊断。利益相关方印象深刻。然后你推向生产，不到一周，流水线就在 15% 的文档上静默地返回错误数据——而没有人知道。

这就是文档 AI 的陷阱。失败模式不是崩溃或异常，而是一条在生成垃圾数据的同时仍然报告"成功"的流水线。构建生产级文档提取，与构建一个演示，是完全不同的问题——而大多数团队直到已经上线才意识到这一点。

你发布了 AI 功能。你将其内置于产品中。你编写了帮助文档。然而，六个月后，你最资深的企业用户仍然在将文本复制粘贴到 ChatGPT 中，以完成你的功能原本就能原生实现的事情。这不是培训问题。这是一个可发现性（discoverability）问题，也是当今企业软件中 AI 投资浪费最普遍的来源之一。

这种模式已有详尽的记录：49% 的员工表示他们在工作中从不使用 AI，74% 的公司难以从 AI 部署中扩大价值。但有趣的失败模式并不是那些明确抵制的后期采用者，而是那些每天打开你的产品、却从未意识到原本值得他们付费的 AI 功能就潜伏在光标一键之遥处的活跃用户。

大多数企业安全团队都有一套相当成熟的内部威胁模型：心怀不满的员工将文件下载到 USB 驱动器，将电子表格发送到个人邮箱，或者带着凭据离职。检测策略是已知的 —— DLP 规则、出口监控、UEBA 基准。这些策略没有考虑到的是这样一种场景：你给每位员工都提供了一个能够以机器速度规划、执行并掩盖多阶段操作的工具。这正是部署 AI 编程助手和基于 RAG 的文档代理的实际效果。

问题并不在于这些工具在隔离状态下是不安全的。而在于它们极大地放大了一个受攻击或怀有恶意的内部人员在单次会话中能完成的任务。内部人员事件的平均成本每年已达到每家机构 1740 万美元，83% 的机构在过去一年中至少经历过一次内部攻击。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 采纳悖论，而且它绝非偶然。

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