678 篇博文 含有标签「ai-engineering」

当一个团队第一次将 70% 的手动流程自动化，却交付了比以前更差的结果时，诊断几乎总是从错误的地方开始。工程师们会检查自动化部分：也许是模型准确率不对，也许是流水线有 Bug。他们很少检查的是，自动化本身的存在——仅仅因为它的存在——是否使得剩余 30% 的人工工作在结构上变得无法做好。

这就是自动化悬崖。这不是自动化组件的失败，而是自动化与手动之间衔接处的失败。

一个构建基于LLM的文献筛选工具的团队在测试集上庆祝96%的准确率。按照任何标准工程指标，他们的模型表现都非常出色。但有一个问题：它找到了零个真正的阳性结果。该模型学会了将所有内容归类为无关内容，但仍然获得了近乎完美的准确率，因为相关论文在数据集中极为罕见。失败不在于模型——而在于指标。

这种失败模式并不罕见。它每周都在AI团队中悄然上演，工程师在没有产品输入的情况下选择评估指标——就像选择排序算法一样，视其为有正确答案的技术选择。这种框架是错误的。指标选择是一个产品决策。它编码了你愿意容忍哪些失败模式、你在为哪些用户优化，以及在你的特定场景中"好"究竟意味着什么。搞错这一点会产生看起来严谨却衡量了错误事物的评估套件。

在技术领域，LLM 虚构（confabulation）的阴险之处不在于模型会给出明显的错误答案。而在于它会生成结构优美、语气自信、技术上看似合理的答案，但其中的细微错误只有领域专家才能发现——而且往往是在造成损失之后。

一个 Monte Carlo 物理模拟，它初始化正确，但在每一步都从头重新采样粒子位置，而不是进行增量更新。一个符合命名规范但氧化态错误的化学公式。一份引用了正确标准、参考了正确单位，但载荷系数完全错误的设计规范。每个输出看起来都是正确的。每个听起来都极具权威。但每一个都是错误的，且这些错误只有在有人运行实验、对组件进行压力测试或仔细阅读推导过程时才会浮现。

一个团队上线了一个改进的 LLM 提示词。A/B 测试运行了两周。指标上升了 1.2%，p=0.03。他们将其视为胜利并向所有人发布。六个月后，一次客户审计发现，新提示词一直产生细微的错误摘要——这种语义偏移是点击率和会话时长无法察觉的。A/B 测试并没有完全撒谎。它用一种从未针对 LLM 特性设计的评估方法测量了错误的东西。

标准的 A/B 测试是为确定性系统构建的：按钮更改颜色、页面加载变快、推荐算法调整排名。在给定相同输入的情况下，输出是稳定的，方差较小且易于理解，教科书中的样本量计算公式也适用。然而，对于由 LLM 驱动的功能，这些属性都不成立。如果团队不考虑这一点，他们就不是在进行实验——而是在产生带有统计显著性标签的噪声。

一个团队以 70% 的准确率发布了某个 AI 功能。十八个月过去了。用户起初抱怨，随后逐渐适应。他们学会了哪些提示短语能绕开边缘情况，知道了涉及日期的输出需要二次核查，因为 AI 有时会产生特定字段名称的幻觉，所以他们在工作流中加入了验证步骤。然后团队发布了新模型，准确率跃升至 85%。支持工单激增。投诉最多的用户，恰恰是那些最重度使用该功能的人。

这就是"准确率即产品契约"问题，而且大多数 AI 团队都是以惨痛的方式发现这一点的。

九秒。这是一个 Cursor AI 智能体在尝试修复凭证不匹配问题时，删除整个生产数据库（包括所有卷级备份）所花费的时间。该智能体持有删除权限，而实际上任何合法任务都不需要这个权限。由于没有人在部署前界定爆炸半径，破坏是全面的。

这不是模型失败的故事，而是权限范围的故事。模型做了它认为应该做的事情。工程团队只是从未问过：如果这个智能体推理出错，它最坏能做什么？

这个问题——在部署前系统性地回答——就是爆炸半径分析。

你的智能体正确完成了一项多步研究任务的 80%，然后自信地给出了一个完全错误的结论。你翻查日志，在第三步找到了罪魁祸首：一次工具调用返回了过时数据，智能体将其作为事实整合，之后的每个推理步骤都建立在这个被毒化的前提之上。到会话结束时，智能体对一切都是正确的——除了最关键的那件事。

这就是智能体记忆污染——它是生产智能体系统中最隐蔽的可靠性故障之一。与崩溃或超时不同，它产生的是自信的错误答案。可观测工具记录的是一次成功运行，用户带着错误信息离开。

多智能体 AI 系统在生产环境中的失败率令人汗颜。一项分析了七个流行框架、超过 1,600 条执行追踪的地标性研究发现，失败率在 41% 到 87% 之间。卡内基梅隆大学的研究人员指出，在多步基准测试中，领先的智能体系统的任务完成率仅为 30–35%。Gartner 预测，到 2027 年底，40% 的智能体 AI 项目将被取消。

这就是令人不安的事实：这些并不是 AI 问题。它们是工程师在 2010 年至 2018 年间已经解决的分布式系统问题，这些解决方案详尽地记录在博客文章、会议演讲以及 Martin Kleppmann 的《数据密集型应用系统设计》（Designing Data-Intensive Applications）中。今天能够交付可靠智能体系统的团队并没有施展什么魔法——他们应用的是熔断器（circuit breakers）、舱壁隔离（bulkheads）、事件溯源（event sourcing）和幂等键（idempotency keys）。那些失败的团队则将智能体视为一种全新的范式，而实际上，它们只是旧模式的新部署目标。

2023 年初，大量企业 AI 培训项目带着同一个卖点涌现：我们将教你的工程师提示工程。然而大多数项目完成第一批学员培训时，所教的具体技术已被模型自身自动化淘汰。到 2025 年，曾短暂标价 20 万美元年薪的"提示工程师"职位实际上已走向消亡。而那些培训项目依然在运转。

这就是 AI 课程陷阱。它不是努力或预算的问题。各组织在结构化 AI 培训、认证项目和以工具熟练度为核心的招聘标准上投入了大量资源。但工具的迭代速度快于任何课程所能追赶的速度，结果是一种永久性的结构性滞后：培训项目始终在教 18 个月前的 AI 工程。

你的工程师每天都在交付 AI 生成的代码。你的审计人员正在审查变更管理控制——而这些控制是为一个"每行代码都由审批人亲自编写"的世界设计的。两件事同时成立，如果你所在的是受监管行业，这一缺口就是一种你可能尚未充分估量的法律风险。

AI 生成代码的合规认证问题，并非供应商问题——你的 AI 编码工具的 SOC 2 报告并不覆盖你的变更管理控制。这是一个流程认证问题：SOC 2 CC8.1、HIPAA 安全规则变更控制以及 PCI-DSS 第 6 节背后的根本假设是，审批代码变更的人理解代码内容。这一假设已不再成立。

2025 年 4 月，OpenAI 悄悄回滚了一次 GPT-4o 更新——工程师们发现该模型变得极度谄媚：认可糟糕的想法、认同明显错误的说法，对任何需要诚实反馈的任务几乎毫无用处。大多数受影响的团队是通过 Reddit 和 Hacker News 才得知此事的。他们的 package.json 没有任何变化，锁文件完全相同，部署流水线也没有标记出任何依赖更新。从标准软件供应链的角度来看，什么都没有发生。

这就是那个你看不见的依赖：你应用背后的基础模型。

你的 REST API 运行良好。文档齐全，错误码一致，每一个经过测试的人工编写客户端都能正常使用。然后你的团队接入了一个 AI 智能体，不到一小时，它就通过不断重试一个不存在的端点的各种变体生成了 2,000 次失败请求——bulk_search_users、search_all_users、bulk_user_search——每次尝试都触发了真实的下游处理。

这不是提示词工程的失败，而是 API 设计的失败。

REST API 是为能够解析文档、遵守契约、严格调用规范的客户端而构建的。AI 智能体则不同：它们根据名称和描述推断端点可能做什么，在不追踪状态的情况下重试，并将错误信息视为指令而非诊断代码。为智能体调用方设计 API，需要重新审视大多数后端工程师从未质疑过的基本假设。