578 篇博文 含有标签「insider」

Andrej Karpathy 在 2025 年初创造了"氛围编程"（vibe coding）一词，描述一种编程风格："完全沉浸在氛围中，拥抱指数级增长，忘记代码的存在。"你用自然语言描述需求，AI 生成代码，然后直接发布。这感觉像是一种超能力。然而不到一年，数据开始讲述一个不同的故事。

METR 的一项随机对照试验发现，有经验的开源开发者在使用 AI 编码工具时效率降低了 19%——尽管他们预测自己会快 24%，事后仍然认为自己快了 20%。CodeRabbit 对 470 个 GitHub Pull Request 的分析发现，AI 协作编写的代码包含的重大问题是人工编写代码的 1.7 倍。Anthropic 对 52 名工程师的研究显示，AI 辅助的开发者在自己代码库的理解测试中得分低了 17%。

你的 A/B 测试框架是为按钮和横幅颜色而生的。它假设当你向用户展示变体 B 时，变体 B 每次的行为都相同。这个假设是如此根本，以至于没有人费心去明说它。然而对于 AI 功能而言，这个假设完全是错的。

当处理本身是非确定性的——当同一个提示每次请求都会产生不同的输出时——你试图测量的方差被你无意中制造的方差所掩盖。大多数团队都是经历了惨痛教训才意识到这一点：本应在一周内达到显著性的实验跑了一个月；周二看起来显著的结果到周四又逆转了；而"获胜"的变体在推广到 100% 流量后却毫无提升。

这不是一个小小的统计干扰问题，而是实验平台的工作方式与 LLM 驱动功能的实际行为之间的结构性错配。

每个 DevOps 团队都有一套凭据轮换政策。大多数团队已经针对其服务、CI 流水线和数据库实现了自动化。但当你部署一个持有跨五个不同集成的 API 密钥的自主 AI Agent 时，那套轮换政策就变成了一个地雷。Agent 正在执行任务中——分拣 Bug、更新工单、发送 Slack 通知——突然它的 GitHub 令牌过期了。进程看起来很健康。日志显示没有崩溃。但无声无息地，一切都不再起作用了。

这是无人从 DevOps 映射到 AI 的凭据轮换问题。传统的轮换假设工作负载是可预测的、由人管理的，并且具有清晰的边界。自主 Agent 打破了每一个这样的假设。

你的 AI 功能三个月前上线了。DAU 在增长。会话时长在攀升。仪表盘一片绿色。但这里有一个让人不舒服的问题：你的用户到底是在真正采用这个功能，还是仅仅在容忍它？

大多数团队用衡量传统产品功能的相同指标来跟踪 AI 功能采用——日活跃用户数、会话时长、功能激活率。当功能表现是确定性的时候，这些指标运作良好。点击按钮，得到结果，衡量参与度。但 AI 功能有本质区别：它们的输出是变化的，价值是概率性的，用户通过反复接触建立信任（或不信任）。标准指标不仅无法捕捉这一点——它们还在积极地误导你。

你为文档编辑器推出了一个 AI 驱动的摘要功能。采用率很高——第一周就有 40% 的用户激活了它。你的产品经理在 Slack 上写了一条庆祝消息。两个月后，平均会话时长下降了 25%，协作编辑量减少，你的高价值用户正在悄悄流失。没有人将这些趋势与那个闪亮的新功能联系起来，因为跟踪摘要功能的仪表板显示的全是绿色指标。

这就是 AI 功能自相残杀：当 AI 快捷方式解决了用户的即时问题，同时摧毁了让你的产品值得付费的参与循环。这是当今产品开发中最隐蔽的失败模式之一，因为跟踪功能本身的每个指标看起来都很健康，即使产品级别的指标正在衰退。

AI 功能发布中存在一个重复出现的模式：演示（demo）惊艳全场，功能正式上线，两周内发生了一些灾难性的事情。不是宕机——那些很容易捕捉。而是一些更微妙的事情：模型自信地生成错误信息，成本飙升到预期三倍，或者在真实负载下延迟激增导致功能无法使用。团队手忙脚乱，功能被悄悄禁用，大家一致同意“下次做得更好”。

问题不在于演示做得不好。问题在于演示成了唯一被重视的测试。

你的 Sprint 回顾涵盖了那些常见问题：不稳定的测试、某人一直推迟的数据库迁移、用胶带勉强粘合的 API 端点。但如果你正在交付 AI 功能，代码库中最昂贵的债务恰恰是那种没人会写在便利贴上的。

传统技术债务是线性积累的。你走了捷径，之后为此付出利息，等痛苦到了一定程度再重构。AI 技术债务是复合增长的。一个默默退化的提示词会产生污染评估的训练信号，这会误导你下一轮提示词修改，进而进一步侵蚀用户体验的质量。等有人注意到时，三层假设已经在底下腐烂了。

你的 AI 产品在评估套件中获得了 82% 的分数。你向 40 个国家发布了产品。三个月后，法国和德国用户报告的质量与英语用户相似。印地语和阿拉伯语用户则悄悄停止了使用该功能。你的综合满意度评分几乎没有波动 —— 因为英语用户主导了指标池。悬崖一直都在。你只是没有测量它。

这是大多数发布多语言 AI 产品的团队都会遇到的典型情况。质量差距并非微乎其微。像 QwQ-32B 这样的最先进模型，在英语推理基准测试中分数为 70.7%，但在斯瓦希里语中则下降到 32.8% —— 这是 2025 年测试的最佳模型在性能上的 54% 相对崩溃。而且这还是 最佳 模型。这种差距并不会随着模型变大而消失。它在高资源语言中会缩小，但在其他语言中依然很大。

你的 Agent 在预发布环境中运行完美。它调用正确的工具，推理多步骤计划，并返回精心打磨的结果。然后生产环境来了：地理编码 API 在 7 步计划的第 3 步超时，LLM 在句子中间返回不完整的响应，而你的 Agent 自信地编造数据来填补空白。直到客户发现，没有人注意到。

LLM API 调用在生产环境中有 1-5% 的失败率——速率限制、超时、服务器错误。对于每个任务进行 10-20 次工具调用的多步骤 Agent，这意味着相当比例的任务至少会遇到一次故障。问题不在于你的 Agent 是否会遇到故障，而在于你是否曾经测试过它遇到故障时会发生什么。

每家在构建多 Agent 系统的公司最终都会发现同一个令人不安的事实：他们的 Agent 并没有反映技术架构图，而是反映了组织架构图。

处理客户入职的 Agent 与管理计费的 Agent 协调不好——不是因为技术限制，而是因为构建它们的团队之间本来就不怎么沟通。

康威定律——系统设计会映射构建它的组织的沟通结构——已经有五十年历史了，但从未像现在这样切中要害。在 AI Agent 时代，这条定律不仅适用，而且被放大了。当你的"系统"是一个由自主 Agent 组成的网络在做决策时，每一个组织接缝都会成为潜在的故障点：上下文丢失、交接中断、Agent 各自为局部指标优化而相互冲突。

大多数将"差分隐私"视为合规复选框的团队实际上并没有得到保护。他们在流水线的某个环节添加了噪声——也许是在微调时添加到梯度上，也许是在检索时添加到查询嵌入上——然后得出结论认为问题已经解决。合规文档写着"已启用 DP"，工程团队继续前进。

他们没有做的是：定义 epsilon 预算、核算系统将服务的每一次查询所消耗的预算，或者验证其隐私损失是否受到有效约束。在实践中，"我们添加了噪声"与"我们拥有有意义的隐私保证"之间的差距，正是大多数现实世界 AI 隐私事件发生的地方。

本文就是关于这个差距的：差分隐私对 LLM 实际承诺了什么，这些承诺在哪里失效，以及团队做出的工程决策——通常是隐性的——如何决定他们的 DP 部署是真正的保护还是表面文章。

每个 AI 产品的融资演示文稿（Pitch Deck）里都有同一张幻灯片：更多用户产生更多数据，数据训练出更好的模型，进而吸引更多用户。这就是数据飞轮。它听起来像是一台关于产品质量的永动机。在最初的几个月里，它确实奏效了——准确率攀升，用户很满意，各项指标都在持续向好。

然而，在大约第三个月的时候，曲线趋于平缓。模型不再有实质性的提升。标注队列在增长，但准确率几乎没有波动。你的团队仍在收集数据、仍在重新训练、仍在发布新版本——但飞轮已经悄然停滞。

这并非罕见的失败模式。研究显示，40% 部署 AI 模型的公司在第一年内会经历明显的性能衰减，高达 32% 的生产评分流水线在六个月内会遇到分布偏移（Distributional Shifts）。飞轮的崩溃并非伴随着巨响，而是在低语中腐朽。