578 篇博文 含有标签「insider」

大多数团队发布第一个 AI 功能时都会使用最好的模型，因为演示（demo）就是在那上面跑的，而且没人有时间深入思考。接着第二个功能也用了同样的模型。然后是第三个。六个月后，每个功能的每次调用都指向了前沿层级（frontier tier）——而账单比实际需要的数额高出五到十倍。

令人不安的事实是，你的生产系统处理的 40%–60% 的请求根本不需要前沿级别的推理。它们只需要称职的文本处理。而购买称职的文本处理服务的成本要低得多。

2021 年，GPT-3 的价格是每百万 token 60 美元。到 2026 年初，同等性能的模型只需 0.06 美元。三年内降价 1000 倍。与此同时，企业 AI 支出增长了 320%——从 115 亿美元攀升至 370 亿美元。而在 AI 上花费最多的那些组织，恰恰正是从价格下降中受益最大的那批人。

这并不矛盾。这就是杰文斯悖论（Jevons Paradox），而它正在侵蚀你的 AI 预算。

你的模型写出了一份详细、结构清晰的分析报告。每个句子在语法上无懈可击，内部逻辑自洽。它引用的具体事实也都是准确的。然而结论却是错误的——不是因为模型缺乏得出正确结论所需的信息，而是因为它在开始推理之前就已经决定好了答案。

这不是幻觉。幻觉是模型凭空捏造事实。伪造问题更为隐蔽，在生产系统中也更难被发现：模型先得出结论，再构建一条听起来合理的证据链来支撑它。事实是真实的。综合分析却是谎言。

你的 AI 系统正在自信地回答关于一个已经不存在的世界的问题。不是因为模型坏了，不是因为检索失败了，而是因为每个生产环境的 AI 应用内部都有三个独立的时钟在以不同的速率运转——而没有人把它们同步起来。

这就是三时钟问题：墙上时钟（wall clock）、模型时钟（model clock）和数据时钟（data clock）各自运行在自己的时间线上。当它们发生偏移时，你得到的系统在技术上正常运行，但在实质内容上以错误日志永远无法捕捉的方式出错。

大多数构建 AI 代理的团队都在为成功而设计。他们衡量成功率，为代理自主处理 90% 工单而欢呼雀跃，然后在 UI 角落放一个"点击此处覆盖"按钮来应对剩余的 10%，之后便一走了之。

这个按钮不是安全网。它是一种包装成功能的责任。

失败模式不是代理崩溃，而是名义上负责的人类在崩溃发生时无法接管。AI 逐渐吸收了任务——每次一个工作流，每次一个边缘案例——直到过去处理这些任务的操作员已经六个月没碰过它，失去了上下文，却被迫应对一个他们已经无力管理的实时状况。这就是温备问题，它会悄无声息地积累，直到某次事故将其暴露出来。

你的监控仪表板一片绿色。响应时间看起来正常。错误率接近于零。然而你的用户却在提工单投诉垃圾回答，你的 agent 正在做出自信满满的错误决策，你的客服队列里塞满了与任何基础设施告警都不相关的投诉。

欢迎来到在生产环境中依赖 LLM API 的独特地狱。这是一个能在返回完美健康的 200 OK 的同时让你翻车的上游服务。

每个曾将模块委托给外包的工程师都知道那种感觉：代码交回来了，测试通过了，演示也能跑——但你完全不知道它到底好不好。你没有写它，你不完全理解其中蕴含的决策，而你即将进行的审查更像是走过场而非真正的实践。现在把这种动态乘以你代码库中每一个AI辅助的提交。

AI委托悖论很容易表述，却很难逃脱：你最需要用来评估AI生成工作的技能，恰恰是你停止亲自动手后退化最快的技能。这不是未来的风险，而是正在发生的事实，在那些拥抱AI编码工具的工程组织中已经可以量化测量。

大多数团队对待 CLAUDE.md 的方式和对待 README 一样：写一次，然后忘掉它的存在，最后疑惑为什么什么都不好使。但 CLAUDE.md 不是文档。它是你的代码库和每一个接触它的 AI agent 之间的 API 契约。写对了，每一次 AI 辅助的提交都遵循你的架构。写错了——或者更糟，让它腐化——你实际上是在每次会话中让你的 agent 变得更笨。

AGENTbench 研究在 12 个代码库中测试了 138 个真实编码任务，发现自动生成的上下文文件实际上降低了 agent 的成功率，甚至不如完全没有上下文文件。三个月积累的指令，其中一半描述的代码库已经面目全非，不会指导 agent——它们会误导 agent。

你的 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%。那些早期认识到这条曲线并将精力重新导向系统设计的团队，始终优于那些持续打磨提示词的团队。

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

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