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

每个工程组织都有这样的人。他们不拥有产品，不交付用户可见的功能。但没有他们，一切都无法运转。他们是编写 ETL 管道、将数据从计费系统搬到分析仓库的工程师；是构建 Webhook 处理器、让 Salesforce 与内部 CRM 保持同步的人；是维护 API 适配层、让移动端应用能与三个从未被设计为相互通信的后端服务对话的人。

他们就是胶水工程师，而他们的工作是第一批被 AI 代理完全吞噬的软件工程类别。

每个工程团队都有这样的故事：AI 编码代理在全新项目中能产出完美代码，但在你的生产代码库中却像没有地图的游客一样跌跌撞撞。代理没有坏。你的代码库是不可读的——不是对人类，而是对机器。

几十年来，"可读性"只意味着一件事：人类开发者能否浏览这个文件并理解其意图？我们通过命名、文件大小、文档和抽象深度等约定来为这个读者做优化。但你代码库增长最快的消费者不再是入职第一周的初级工程师。它是一个 LLM 驱动的代理，每天阅读、推理和修改你的代码数千次。

越来越多的证据表明，代码库结构是 AI 辅助开发速度的最大杠杆——比模型选择更重要，比提示工程更重要，比你使用哪个 IDE 插件更重要。拥有良好结构代码库的团队在使用 AI 助手时报告迭代周期减少了 60-70%。问题不再是是否要为机器可读性优化，而是如何优化。

关于多智能体 AI 系统，有一个令人不安的事实：当你让两个或更多由 LLM 驱动的代理共享资源并同时做出决策时，它们的死锁率在 25% 到 95% 之间。不是偶尔发生。不是在边缘负载下。在使用标准提示的正常运行条件下，一旦代理必须同时协调，系统就会卡住。

这不是理论上的担忧。协调故障约占生产环境中多智能体系统故障的 37%，而没有正式编排的系统故障率在 41% 到 87% 之间。经典的分布式系统故障模式——死锁、活锁、优先级反转——又回来了，只是穿上了新衣服。

微软的 Copilot 发布时讲了一个清晰的故事：每用户每月 30 美元，生产力倍增。但实际的账单却丑陋得多。一旦将企业基础许可证成本、每个活跃用户的算力成本以及支持运维开销合并计算，微软每个用户每月亏损超过 20 美元。财务部门没有立即发现这个问题，因为这些成本挂在基础设施预算下，而不是产品损益表里。工程团队知道 Token 账单数额庞大，但没有人把这两条线连接起来。

这正是大多数 AI 团队在构建产品时不知不觉埋下的计费问题。这不是定价策略问题——那是产品决策。这是一个工程问题：你没有任何基础设施来衡量 AI 功能在每个客户、每个功能、每个请求粒度上的实际成本，而任何定价模式的运转都需要这种精度。

一套联络中心 AI 系统在验证基准上的准确率超过 90%，但主管们仍然要求客服人员手动录入笔记。18 个月后，该产品以"采用率低"为由被砍掉。这种模式在企业 AI 部署中反复上演——技术上无可挑剔却无人使用的系统，被一套根本看不见失败的指标所衡量。

问题在于，团队所度量的内容与预测产品成败的内容之间存在系统性错配。工程组织从经典 ML 那里继承了度量本能：准确率、精确率/召回率、BLEU 分、延迟百分位、评估通过率。这些指标描述的是孤立的模型行为，几乎无法告诉你 AI 是否真正有用。

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

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

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

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

大多数提示工程的努力都集中在让指令更清晰上：更精准的动词、更好的格式、更明确的约束。这确实有效——在某种程度上。但生产级 AI 系统的瓶颈往往不是指令清晰度，而是模型明明拥有相关知识和能力，却根本没有将其激活。

这就是提示工程与能力激发的本质区别。提示工程优化的是你如何提问，能力激发优化的是模型在回答时从自身权重中调取了什么。这一区别至关重要，因为两者的失败方式截然不同：提示工程失败时，你得到的是格式混乱或答非所问的回复；激发失败时，你得到的是格式完美、措辞自信，却错过了模型明明具备的洞察力的回复。

大多数团队在优化 LLM 提示词时，其实在解决一个错误的问题。他们花好几周打磨指令的措辞——调整用词、重排约束条件、改变语气——而真正的瓶颈却在于：模型其实已经知道如何完成这个任务，只是你的提示词从未触发正确的能力路径。

这就是提示工程与能力激发之间的本质区别。提示工程解决的是"如何表达你想要什么"，而能力激发解决的是"如何唤醒模型已有的能力"。这一区分至关重要，因为两者的修复方式截然不同——误判问题所在，会让你在错误的方向上白白迭代数月。

大多数工程组织发现问题的方式都差不多：AI Demo 效果不错，领导层推动更广泛的落地，于是有人决定正确的做法是建立一个专职团队来负责"AI 基础设施"。该团队获得了人员编制、路线图和加速全组织 AI 落地的使命。

十八个月后，产品团队开始提工单来部署他们的提示词。平台团队疲于奔命。那些 Demo 阶段只需几天的功能，现在要花上好几个季度才能上线。而那个最初为了加速 AI 落地而创建的团队，却成了最大的瓶颈。

这就是中心化 AI 平台陷阱——而且出奇地容易跌入其中。

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

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

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

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

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

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