44 篇博文 含有标签「ai」

一家中型项目管理公司的产品副总裁，花了三个季度的工程团队路线图来构建 AI 助手。上线六个月后，每周活跃使用率只有 4%。问她为什么要做：「竞争对手发布了一个，董事会问我们什么时候跟上。」这是一个用产品战略包装起来的恐慌决策——而且这种情况现在到处都是。

4% 不是个例。一个客户成功平台在四个月后，AI 生成通话摘要的采用率是 6%。一个物流 SaaS 添加了 AI 路线优化建议，点击率 11%，实际操作率 2%。一个 HR 平台推出了 AI 政策问答机器人，火了两周，然后跌落至 3% 后趋于平稳。这个规律已经稳定到可以命名了：发布 AI 功能，眼看它被忽视，十八个月后悄悄下线。

默认的解释是 AI 不够好。有时确实如此。但更多时候，模型没有问题——用户压根就没找到这个功能。

过去三年，工程团队上线的AI功能数量超过了此前十年的总和。但他们几乎没有下线过任何一个。德勤的研究发现，2025年有42%的公司放弃了至少一个AI项目——相比前一年的17%大幅上升——每个被废弃项目的平均沉没成本高达720万美元。然而，那些留在生产环境中的功能往往比被砍掉的更具破坏性：它们缓慢侵蚀用户信任，积累每月复利的技术债，并消耗本可用于有效工作的工程资源。

这种不对称是结构性的。AI功能上线会带来公告、利益相关方的兴奋和团队荣誉。而退场则被视为失败的承认。因此，糟糕的功能不断积累。解决之道不是意志力，而是一套决策框架——让退场成为一种正常、可预期的工程结果，而非组织危机。

你的监控看板显示延迟升高，错误率小幅上升，然后归于平静。用户已经在 Slack 里投诉了。你的 AI 功能有四分之一的响应在产生幻觉，而这些幻觉在你的告警系统眼中看起来完全正常。等你找到原因——两小时前上线的一个提示词里改了六个字——一场你的 Runbook 从未预料到的慢燃事故已经结束了。

这就是在生产环境中运营 AI 系统的核心挑战。这些故障模式真实存在、危害显著，却对传统工具完全隐形。一个在悄悄产生幻觉的 LLM，从外部看和一个运行正常的 LLM 毫无区别。

你的模型通过了公平性审查。人口统计学平价（demographic parity）在可接受范围内，机会均等指标（equal opportunity metrics）看起来很干净，审计报告也被贴上了绿色的勾，进入了 Confluence。三个月后，一名记者拿出的屏幕截图显示，你的系统对某一人口群体的贷款批准率仅为另一群体的一半——而你发布前的那些数据在技术层面一直都是准确的。

这就是偏差监控的缺口。发布前的公平性测试是根据运行测试时存在的数据集来验证你的模型的。但在生产环境中运行的 AI 系统并不处于那种静态的世界中。用户行为会发生变化，人口分布会产生偏移，特征相关性会演变，而那些在发布时无法衡量的差异可能在几周内演变成严重的失效模式。能够捕捉这些问题的系统，在当今大多数 ML 技术栈中都是缺失的。

演示进行得很顺利。试点运行了六周，展示了清晰的成果，与会的利益相关者印象深刻。然后，什么都没有发生。三个月后，项目悄悄被搁置，构建它的工程师转向了其他事情，公司的AI战略变成了一张写着"探索机会"的幻灯片。

这就是扼杀AI项目的模式。不是技术失败，不是模型能力不足，甚至不是预算问题。技术本身确实有效——研究一再表明，约80%进入生产的AI项目达到或超过了预期目标。问题在于那70-90%从未走到那一步的项目。

最迫切需要 AI 编程帮助的团队，通常并不是那些正在构建全新服务（greenfield services）的团队。他们往往正在维护 2012 年产出的 50 万行 Rails 单体应用，或是处理过数十亿笔交易的 COBOL 支付系统，亦或是架构师早在三次收购前就已离职的微服务网格。在这些代码库中，一个位置不当的重构就可能引入隐蔽的数据损坏漏洞，而这些漏洞往往在三周后的生产环境中才会浮现。

而这恰恰是目前的 AI 编程助手（agents）失败得最惨烈的地方。

令人沮丧的是，这种失效模式在爆发前是隐形的。AI 助手生成的代码可以通过编译，通过现有测试，并在审查中看起来非常合理。问题往往出现在预发环境（staging）、深夜的批处理作业，或者是某个客户在月份特定日期才会触发的边缘情况中。

当欧盟 AI 法案的透明度义务于 2026 年 8 月 2 日正式生效时，每个为欧盟用户生成合成内容的系统都需要为该内容标注机器可读的溯源信息。大多数构建 AI 产品的工程团队对此有模糊的认知，但真正搭建好所需基础设施以实现合规的团队寥寥无几——而在那些已经实施的团队中，相当一部分只完成了监管要求的一半。

面对"AI 内容溯源"这一命题，业界的主流应对方式是指向 C2PA（内容溯源与真实性联盟标准），然后宣布问题已解决。C2PA 固然重要——它真实存在，正被 Adobe、Google、OpenAI、索尼和三星采用，是业内最接近通用标准的方案。但仅凭 C2PA 实施并不足以满足欧盟 AI 法案第 50 条。它无法在你的 CDN 中存活，也无法阻止恶意行为者为篡改内容生成"可信"的溯源记录。

本文将探讨生产环境中 AI 内容溯源的真实需求——技术栈、失效模式，以及让团队措手不及的合规漏洞。

你的团队在六个月前发布了一项由 AI 驱动的摘要功能。采用率停滞在 8% 的用户。模型调用每月耗资 4,000 美元。构建该功能的工程师已经调到了另一个团队。现在，模型提供商正在涨价。

所有的直觉都在告诉你：砍掉它。但事实证明，停掉一个 AI 功能要比停掉任何其他类型的功能都难得多——大多数团队都是在退役过程中，当合规问题开始出现、核心用户开始反抗时，才以惨痛的方式意识到这一点的。

这是一份在发布功能之前就应该存在的指南，但在你盯着那些明显指向退出的使用率图表时，它最为有用。

大多数 AI 产品团队都会遇到这样一种场景：某位领导层成员询问新的文案生成模型是否比旧的好。团队运行了评估套件，准确率数据看起来不错，于是发布了模型。三周后，营销团队悄悄换回了旧模型，因为新模型“听起来不对劲”。准确率指标是真实的，只是他们衡量错了对象。

这就是 AI 品味问题。只要你的输出是主观的——文案创作、设计建议、创意内容、语气调整、风格推荐——它就会出现。当没有客观的基准事实（Ground Truth）时，传统的机器学习评估框架会给你一种虚假的自信。而大多数团队对于该如何应对并没有系统性的方案。

一家大型保险公司的 AI 系统正在拒绝理赔申请。人工审核这些决定后，发现其中 90% 是错误的。这家保险公司的工程团队构建了性能出色的模型，MLOps 团队有完善的部署流水线，数据科学家有严格的评估指标。但这一切都无济于事，因为在董事会层面，从来没有人回答过这个问题：对于影响病人能否获得治疗的 AI 决策，我们可接受的失败率是多少？

这个缺口——功能正常的技术系统与缺失的高管决策之间的鸿沟——正是 AI 治理在实践中最常出现问题的地方。结果是：组织同时在生产环境中运行 AI，却暴露在从未正式承认的责任风险之下。

在 2024 年底，OpenAI 的 o3 系统在 ARC-AGI 基准测试中获得了 75.7% 的分数——这是一个专门为抵抗优化而设计的测试。AI 研究界欢欣鼓舞。但从业者仔细观察后发现：o3 使用了该基准测试 75% 的公开训练集进行训练，且最高算力配置使用的资源是基准线的 172 倍。这并不是伪装成分数的能力突破，而是伪装成能力突破的分数。

这就是评估悖论（Evaluation Paradox）。一旦某个基准测试成为团队优化的目标，它就不再能衡量其最初设计的目的。古德哈特定律（Goodhart's Law）——“当一个衡量指标变成目标时，它就不再是一个好的指标了”——虽然是在 20 世纪 70 年代的经济政策中提出的，但它却极其精准地描述了 AI 基准测试的现状。

大多数个性化系统是围绕一个飞轮构建的：用户进行互动，你学习他们的偏好，你展示更好的推荐，他们从而进行更多互动。随着数据的积累，飞轮转得越来越快。问题在于，飞轮需要速度才能产生升力——而新用户完全没有速度。

这就是冷启动问题。而且它比大多数团队在首次发布个性化功能时所认识到的更为危险。一个新用户在到达时没有任何历史记录，没有信号，通常还带着怀疑的先验预期：“AI 并不了解我。”你大约有 5 到 15 分钟的时间来证明并非如此，否则他们就会形成一种定论，决定他们是否会留得足够久，以产生那些能让你真正帮助到他们的数据。如果这个窗口期表现糟糕，高达 75% 的新用户会在第一周弃用产品。

冷启动问题不是数据问题，而是初始化问题。工程上的问题是：在缺乏历史记录的情况下，你应该注入什么？