990 篇博文 含有标签「insider」

你的 RAG 管道在回答单一事实问题时表现出色。问它"我们的退款政策是什么？"它每次都能准确回答。但如果问"哪些企业版客户在合同续签后 30 天内提交了关于计费 API 的工单？"它就无能为力了。答案确实存在于你的数据中——分散在三种不同的文档类型中，通过余弦相似度无法捕捉的关系连接在一起。

这就是多跳推理问题，也是越来越多的生产级 RAG 团队在向量检索管道上嫁接知识图谱的原因。不是因为图谱又流行了，而是因为他们遇到了一个具体的准确率天花板——无论怎么调整分块大小或重新排序都无法突破。

MCP 生态已拥有 10,000+ 服务器和 9700 万次 SDK 下载量。但同时也在六十天内出现了 30 个 CVE、502 个未锁定版本的服务器配置，以及一个在十五个版本中悄悄将每封外发邮件密送给攻击者的供应链攻击。可组合性的承诺——「只需再接入一个 MCP 服务器」——是真实的。但它带来的依赖蔓延也是真实的，大多数团队在深陷集成债务之后才发现其代价。

如果你在 npm 上构建过生产系统，你一定看过这部电影。MCP 生态正在加速重演同一剧情，只不过这次的「包」拥有对你机器的 shell 访问权限和生产系统的凭证。

在AI工程领域，有一种持久的信念：一个平庸的LLM应用和一个优秀的LLM应用之间的差距，归结于提示词的精心打磨。团队雇佣"提示工程师"，对措辞进行数十次A/B测试，花好几周纠结"你必须"是否比"请确保"表现更好。与此同时，检索管道输入的是垃圾上下文，没有输出验证，错误处理策略是"希望模型能搞定"。

数据讲述了一个不同的故事。典型LLM应用的前五小时提示词工作带来大约35%的提升。接下来的二十小时带来5%。再接下来的四十小时？大约1%。那些早期认识到这条曲线并将精力重新导向系统设计的团队，始终优于那些持续打磨提示词的团队。

大多数团队发现自己依赖模型的方式，和你发现承重墙的方式一样——试图拆掉它的时候。停用邮件到了，你在配置中替换了模型标识符，然后你的应用开始返回自信、格式优美、却微妙错误的答案。没有报错，没有崩溃，只是信任在缓慢流失，需要数周才能察觉，数月才能修复。

这就是模型下线悬崖：强制迁移揭示出你"模型无关"的系统其实从未无关过的那一刻。你的提示词、输出解析器、评估基线、用户的期望——所有这些都在悄悄地校准到即将按照别人的发布节奏而改变的行为特性上。

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% 相对崩溃。而且这还是 最佳 模型。这种差距并不会随着模型变大而消失。它在高资源语言中会缩小，但在其他语言中依然很大。