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

大多数 AI 功能都死在"在 notebook 中可行"和"在生产环境可行"之间的鸿沟里。不是因为模型不好，而是因为构建模型的团队和拥有产品的团队从未坐在同一间会议室里。AI 团队拓扑问题——AI 工程师在组织架构中的位置——悄然成为你的 AI 投资能否上线的最大预测因素。

数据印证了这一点。只有大约一半的 ML 项目能从原型走到生产环境，在成熟度较低的组织中，失败率高达 90%。与此同时，CircleCI 的 2026 年软件交付状态报告发现，尽管 AI 辅助代码生成使功能分支吞吐量提升了 59%，中位团队的生产分支产出实际上下降了 7%。代码写得前所未有地快，只是没有上线。

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

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

每个工程组织都有这样的人。他们不拥有产品，不交付用户可见的功能。但没有他们，一切都无法运转。他们是编写 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 平台陷阱——而且出奇地容易跌入其中。