722 篇博文 含有标签「insider」

大多数工程团队在推出第一个AI智能体六个月后，会发现自己已经拥有了15个。这并非出于规划——而是因为每个团队都解决了真实问题并付诸实施。客服团队构建了分类智能体，数据团队构建了报告生成智能体，平台工程团队构建了运行手册智能体，基础设施团队又构建了三个。这些智能体之间没有共享的认证、日志、工具或评估方法。Token费用从十几个供应商账户持续流失，而没有人能告诉你哪个智能体负责哪些开销。

这一时刻，正是能够规模化AI的工程组织与不能的工程组织之间的分水岭。答案不是放慢智能体的开发——而是在熵使整合变得不可能之前，先进行一次组合审计。

AI 编程工具的 ROI 宣传在纸面上看起来无懈可击：在受控实验中，开发者完成任务的速度提升了 55%，合并的 Pull Request 数量增加了 98%，每周据称节省 3.6 小时。但当组织审视真实的交付指标——Bug 率、发布周期、故障频率——时，数字几乎没有任何变化。某些东西吸走了所有增益的时间，而它并不难找。

AI 数秒生成代码。工程师的审查速度，却和以前一样慢。

大多数工程团队对待伦理问题，就像他们过去对待安全问题一样：在功能发布之后、有人投诉之时才去处理。这种类比令人不安。2004年，SQL注入还是个"以后再修"的问题。如今，每个正规团队的CI中都有自动注入检测。AI伦理审查正处于同样的拐点——不提前建立门控机制的团队，终将以惨痛教训明白它存在的意义。

问题不在于初衷，而在于结构。安全审查有20年的标准化先发优势：OWASP清单、CVE评分、渗透测试、上线前的强制审批。伦理审查则没有这些规范。大多数团队既没有定义明确的触发条件，也没有清单、退出标准，更没有指定的责任人。结果是：一个医疗算法将黑人患者被识别为需要护理的比例降低了超过50%——不是因为工程师心怀恶意，而是因为没有人在上线前运行分组准确率分析。一个招聘模型系统性地降低了含有"女性"一词的简历排名——用历史数据训练，未经公平性审查就发布，几个月后才在生产中被发现。这些不是边缘案例，而是在伦理作为上线后没有牙齿的复选框时必然发生的结果。

你最值得信任的功能也是你最危险的 AI 部署目标。这是一个产品团队不断以惨痛代价发现的直觉相反的现实：用户最依赖的功能，那些信任深厚且自动化的功能，恰恰是 AI 引入的变异性（variance）会造成最灾难性信任损害的地方。一个新功能的失败令人失望，而一个现有功能突然变得不可预测则是一种背叛。

这就是 AI 产品改造陷阱（retrofit trap）。陷阱并不在于决定添加 AI——这通常是正确的；陷阱在于认为在成熟功能中添加 AI 比构建新功能更安全，因为你已经拥有了用户。事实上，情况恰恰相反。你花费数月或数年赢得的信任并不是 AI 实验的基础；如果实验失败，它反而会成为一种负担。

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

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

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

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

AI 平台团队最常见的失败模式不是技术问题，而是组织问题：中央平台团队成了每个产品团队将 AI 能力推上生产的必经关卡。请求队列不断增长，交付周期从几天膨胀到几周。产品团队愈发沮丧，开始拼凑非官方的绕道方案——硬编码 API 密钥、私下接入 LLM、用个人信用卡注册供应商账户。等平台团队察觉时，组织里已有一半的 AI 工作游离在任何治理体系之外。

问题不在于平台团队关心治理，而在于他们把治理实现成了审批流程，而非基础设施。

你的推荐模型在三个月前上线了。点击率增长了 18%。观看时长在不断攀升。仪表盘上一片飘绿。领导层很满意。

而你的模型正在悄悄地破坏它将用于训练下一个版本的数据。

这就是训练数据自中毒（training data self-poisoning）：一种反馈循环，其中已部署的 AI 功能会改变用户行为，其方式破坏了模型最初训练时学习的交互数据。最糟糕的是，你的标准参与度指标会告诉你一切正常 —— 直到它们失效的那一刻。

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

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

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

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

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

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

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

每个上线 AI 功能的工程团队最终都会碰到同一堵墙：财务部门要看一份证明支出合理性的表格，但你做的那份根本行不通。

问题不在于 AI 功能缺乏 ROI，而在于 AI 的经济逻辑打破了标准 ROI 模型的每一个假设——固定资本、线性成本曲线、可预期的回收时间线。把 AI 支出当作 SaaS 许可费来处理的团队，要么在上线前看到虚高的数字，要么在投产六个月后看着数字崩塌。有计划的 AI 项目（ROI 达 55%）与随意部署的项目（ROI 仅 5.9%）之间近十倍的差距，几乎完全来自于团队是否在上线之前就建立了正确的度量模型。