44 篇博文 含有标签「engineering」

大多数工程师将 LLM 质量回归视为提示词工程问题或模型能力问题。他们会重写系统提示词、尝试更新的模型，或添加少样本示例。他们很少检查每次 API 调用顶部静静躺着的三个数字：temperature、top-p 和 top-k。但这些默认值正在悄然改变模型产出的每一个响应，错误的调参会导致输出方差——团队往往数月内都把锅甩给模型，直到意识到罪魁祸首不过是一个从未动过的配置值。

这不是入门教程。如果你在生产环境中运行 LLM——用于信息抽取管道、代码生成、摘要，或任何输出流入真实系统的任务——以下是你在智能调参之前必须理解的机制与权衡。

大多数 AI 团队都会对其落地页进行无障碍审计。但几乎没有人对聊天界面本身进行审计。这种差距并非源于懒惰 —— 而是因为工具根本不存在。WCAG 2.2 没有针对流式内容的成功标准，没有针对非确定性输出的标准，也没有针对逐个 token 传输的指南。这意味着目前每个将响应流式传输到 <div> 中的 AI 产品都处于合规灰色地带，同时破坏了很大一部分用户的体验。

这并不是一个微不足道的边缘情况。盲人和低视力用户报告称，寻求信息是他们使用 AI 的首要场景。患有诵读障碍、ADHD 和认知障碍的用户正积极尝试使用 AI 工具来减轻阅读负担 —— 而默认的实现模式却实际上让情况变得更糟。

大多数采用 AI 代码审查器的团队都会经历同样的阶段：最初的兴奋，伴随着大量看似有用的标注问题，然后逐渐演变成完全忽视该机器人。几个月内，工程师们已经形成了一种在不阅读 AI 评论的情况下直接将其关闭的肌肉记忆。工具仍在运行，评论仍在出现，但没有人再根据它们采取行动了。

这不是工具问题，而是衡量标准的问题。团队在部署 AI 代码审查时，从未定义过什么是“净收益”——如果没有这个基准线，告警疲劳最终会胜出。

你的内容审核服务返回 {"severity": "MEDIUM", "confidence": 0.85}。下游计费系统将 severity 解析为枚举值 ["low", "medium", "high"]。一次模型更新后，服务偶尔开始返回首字母大写的 "Medium"。没有任何部署发生，没有 schema 变更。集成在生产环境中悄然崩溃，整整六天无人察觉——因为所有 HTTP 状态码都是 200。

这是 LLM 支撑服务 API 契约的根本问题：表面看起来像 REST API，但底层行为是概率性的。标准契约工具假设确定性。当这个假设被打破时，它是悄无声息地崩溃的。

Cursor 在 2025 年实现了 10 亿美元营收，却亏损了 1.5 亿美元。客户支付的每一分钱都直接流向了 LLM API 供应商，工程、支持和基础设施开销无从覆盖。这不是一个规模化问题——而是一个单位经济学问题，在酿成危机之前始终隐而不见。

大多数构建 AI 功能的工程团队都在犯同一个错误：把推理成本当作一个无关紧要的小项，上线固定费率订阅，然后假设经济账迟早会算对。但它永远不会自己算对。可变推理成本的行为方式与软件中任何其他 COGS 都截然不同——一旦你最重度的用户发现了你最昂贵的功能，那些适用于传统 SaaS 的定价架构就会让你流血不止。

一家医疗初创公司从某个主流前沿模型迁移到了同一供应商提供的新版本。结果是：为了恢复功能对等（feature parity），耗费了 400+ 个工程小时。新模型每次响应生成的 token 数量是原来的五倍，抵消了预期的成本节省。它开始提供未经请求的诊断建议——这带来了合规性风险。而且它破坏了下游的所有 JSON 解析器，因为它把响应包裹在了 Markdown 代码块语法中。同一供应商，不同的模型，却是推倒重来。

这就是供应商抽象税（provider abstraction tax）：它不是切换供应商的成本，而是不为此做规划所产生的累积成本。它不是一次性的迁移事件，而是一个持续的消耗——你在升级三周后发现的行为退化、无法跨模型迁移的提示词工程工作，以及因为某个供应商分别计算输入和输出 token 的速率限制而导致静默失败的重试逻辑。直接在单一供应商之上构建系统的团队会无形中积累这种债务，直到收到弃用通知或价格变动通知时，账单才会一次性结清。

一个团队花了三周时间集成一个基础模型，将收到的支持工单分类到不同的路由类别中。该模型在测试中达到了 87% 的准确率。他们发布了。六个月后，一名工程师注意到 70% 的工单在主题行中包含产品名称，而一个简单的查找表就能以 99% 的准确率处理这些工单。LLM 正在处理那困难的 30%，而在其余时间里则在胡言乱语。

这并非一个少见的故事。之所以会发生这种情况，是因为团队将“使用 LLM”作为首选的实现方案，而不是最后的手段。解决方法是设立一个强制性的关卡：在被允许构建 AI 版本之前，你的 AI 功能必须先输给一个笨规则。

一个单步可靠性为 95% 的代理听起来相当出色。但在执行 10 步任务时，成功率降至 60%；20 步时降至 36%；50 步时只剩约 8%——而这还是基于 95% 这个乐观的估计。实际数据显示，真实世界中代理每步操作的失败率接近 20%，这意味着一个 100 步的任务成功率约为 0.00002%。这不是模型质量问题，也不是提示工程问题，而是一个复合数学问题——而大多数构建代理的团队还没有真正内化这一点。

这就是委托悬崖：当你给代理的任务多增加一步时，失败率不是线性增加，而是成倍放大。

你的系统平均端到端延迟为 400ms，p95 是 4.2 秒，p99 是 11 秒。在产品规格中你承诺了"亚秒级"体验。仪表盘上的每个指标看起来都很正常，直到有人问起 5% 的用户遭遇了什么——这时，你一直引以为傲的平均值才成了埋葬你的东西。

这就是 AI 功能的延迟预算问题，它与你之前解决过的问题有着本质区别。当核心组件是数据库查询或微服务调用时，p95 延迟大致可预测，并且适用标准 SRE 技术。而当核心组件是 LLM 时，响应时间的分布呈重尾特征，依赖于输入，并且部分由你无法控制的条件驱动。在制定诚实的 SLO 之前，你需要一套不同的思维模型——更别说去达成它了。

最有望从 AI 中获益的团队，往往是最晚部署 AI 的。一家能够利用 AI 实时发现用药错误的医疗机构，其 AI 采纳率仅为 39%；而一家运行 AI 代码审查的软件公司，采纳率高达 92%。两者的 ROI 差距悬殊——然而采纳率却完全颠倒。这就是 AI 采纳悖论，而且它绝非偶然。

人们的本能是将这种差距解释为规避风险、监管恐惧或官僚惰性。这些因素确实存在。但更深层的原因是结构性的：在高风险领域释放价值所需的准确率阈值，从根本上高于自主部署所能证明合理的水平，而大多数团队尚未构建出弥合这一差距的架构。

你的团队比以往任何时候都能发布更多代码。PR 速度提升了，周期时间缩短了，积压也在减少。在管理者看得到的每一块仪表板上，一切都看起来很好。然而，每个 PR 对应的事故数量正悄悄地以每年 23.5% 的速度攀升。

这就是 AI 代码审查的悖论。AI 工具让工程师写代码更快，审查代码也更快——但最关键的缺陷正以比以前更高的比率漏过审查。这个悖论的两面相互叠加，而大多数团队并没有在衡量正确的指标来察觉这一点。

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

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