678 篇博文 含有标签「ai-engineering」

Andrej Karpathy 直言不讳：AI 实验室正在"过拟合"Arena 排行榜。某头部实验室在公开发布前私下评估了 27 个模型变体，只发布了表现最佳的那个。研究人员估计，仅凭选择性提交就可以将排行榜分数人为提高多达 112%。所有人都视为基准真相的众包评估系统已经成为博弈目标——一旦成为目标，它就不再是有效的衡量标准了。

这就是古德哈特定律在发挥作用：当一个指标成为目标时，它就不再是好的指标。这一规律在经济学和政策领域已被充分理解了数十年。在 LLM 工程中，它正在实时摧毁评估套件，而构建这些套件的团队往往浑然不知。

大多数采用 AI 编程智能体的团队，都会把第一周花在争论使用哪个模型上。他们用人为设计的例子对 Opus、Sonnet 和 GPT-4o 进行基准测试，痴迷于排行榜，最终选出一个。然后他们花接下来三个月纳闷，为什么智能体一直在重建错误的抽象、忽视他们的测试策略，以及反复询问该用哪个包管理器。

问题不在模型。问题在上下文文件。

每款 AI 编程工具——Claude Code、Cursor、GitHub Copilot、Windsurf——都会在每次会话开始时读取一个项目专属的 Markdown 文件。这些文件有不同的名字：CLAUDE.md、.cursor/rules/、.github/copilot-instructions.md、AGENTS.md。但它们的目的相同：告诉智能体那些无法通过阅读代码推断出来的信息。这个文件的质量如今比背后的模型更可靠地预测输出质量。然而大多数团队只写一次、写得很糟，然后再也不碰。

大多数采用 AI 编程工具的团队都会遇到同样的瓶颈。第一个月看起来像是成功案例：PR 吞吐量上升，Sprint 速率在攀升，工程经理正在制作幻灯片准备向领导层汇报。到了第三个月，事情悄然发生了变化。事故率开始回升。资深工程师在代码审查上花费了更多时间。一个简单的 Bug 修复现在需要理解一段团队中根本没人写过的代码。生产力的提升已经消失殆尽 —— 但衡量体系从未捕捉到这一点。

问题在于，大多数团队最先关注的指标 —— 生成的代码行数、合并的 PR 数量、消耗的故事点数 —— 对于 AI 辅助开发来说是错误的衡量单位。它们衡量的是产出代码的成本，而不是持有代码的成本。AI 让产出几乎变得免费，却让持有成本保持不变。

每个部署 LLM 路由的团队都是同样的起步方式：按价格排列模型，将简单查询发送给便宜的模型，复杂查询发送给昂贵的模型，然后庆祝成本降低了 60%。六周后，有人发现合同分析准确率从 94% 降到了 79%，编码助手开始虚构不存在的 API 端点，复杂支持工单的客户满意度直线下滑——而路由仪表盘上仍然显示"质量保持 95%"。

问题不在于路由本身。问题在于，仅优化成本的路由将所有质量下降视为等同，而实际上你降级的那些查询恰恰是质量最重要的那些。

大多数 AI 功能用自然语言描述需求，也用自然语言进行评估。产品经理写下"助手应当给出有帮助的回复，并避免有害内容"。工程师上线了一个 Prompt，演示时的输出看起来符合要求。团队在站会上达成共识，却在上线时产生分歧——边缘案例浮现，不同工程师对同一输出的评判各异，而"有帮助"这个词，不同评审者的理解竟有七种之多。

这不是工具问题，而是翻译问题。规格说明一直停留在抽象层面，评估标准从未被具体化。Spec-to-Eval 是一门在编写第一个 Prompt 之前，将英文需求转化为可证伪标准的方法论——提前做这件事，将从根本上改变迭代速度。

大多数 AI 产品把单个功能做对了，却把产品整体做错了。搜索返回了合理的结果，摘要表述连贯，对话助手给出了合理建议。但当用户搜索"小团队最佳方案"、在侧边栏看到推荐、向助手追问后续问题，再阅读自动生成的选项摘要——而这四者相互矛盾时——没有一个功能还能让人信任。这就是环境 AI 一致性问题：不是孤立的幻觉，而是产品层面的矛盾。

这种失败模式足够隐蔽，以至于团队往往完全忽视它。单个功能的评估指标看起来还不错。搜索团队衡量召回率和精确率，摘要团队衡量忠实度，对话团队衡量任务完成率。但没有人衡量产品各 AI 功能之间是否在讲述同一个事实的同一个故事。

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

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

几乎每个 AI 产品在达到数十万活跃用户时都会出现一种模式：团队开始增加个性化——在每个 Prompt 中注入用户历史、偏好信号和行为数据——然后看着产品略微变好，而基础设施账单却大幅增加。当他们最终拉取日志并衡量每增加一个 token 带来的质量增量时，曲线的形状几乎总是一样的：早期增益陡峭，随后进入漫长的平台期，最后是你支付全价却只能换来微乎其微的回报。

大多数团队只有在深陷泥潭时才会进行这种分析。这篇文章将探讨为什么这个陷阱会存在，个性化在何处停止产生回报，以及在生产环境中真正有效的架构是什么样的。

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

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

Token 成本在两年内下降了 280 倍。企业 AI 账单却上涨了 320%。如果这听起来像个悖论，那是因为你还没有仔细研究按 Token 计费如何与那些真正让 AI 产品有价值的功能相互作用。

最有用的 AI 工作流——深度研究、多步推理、迭代优化、智能体工具调用——恰恰是消耗最多 Token 的。在纯按用量计费模式下，你最好的功能就是你最大的利润杀手。这不是暂时的规模化问题，而是 AI 创造价值的方式与计费方式之间的结构性错配。

这是一个按计划交付存在缺陷的 AI 功能的典型规格说明书（Spec）：“助手应准确回答客户问题并保持友好的语气。”每一位利益相关者都点头示意，产品需求文档（PRD）获得了批准。六个月后，团队在事后分析中争论 87% 的准确率是否可以接受 —— 而这是一个在发布前没有人想到要回答的问题。

这种失败并非技术性的。模型本身可能没有问题。失败之处在于直接从传统软件引入的需求格式没有为 AI 输出的核心属性留出空间：即它们是概率性的。“正确”不是一种状态，而是一个分布。你无法用一个用户故事（User Story）来定义一个分布。

AI工程领域最诱人的想法，就是通过运行第二个LLM来检查第一个模型的输出，从而让任何LLM系统变得更可靠。从理论上看，这显而易见。但在实践中，那些天真地部署这一模式的团队，往往最终面临的是2倍的推理成本和一种虚假的安全感——他们的"验证"不过是让原始模型的偏差跑了两遍而已。

做得好，双模型验证能带来真实的准确率提升：推理任务提升6–18%，RAG忠实度可测量地改善，代码正确性的问题也能被有意义地发现。做得不好，两个模型对同一个错误答案达成共识，比一个模型出错更糟糕——因为你同时也消除了不确定性信号。

这篇文章就是关于如何识别两者的区别。