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

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

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

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

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

你的 AI 功能上线时赢得了满堂喝彩。三个月后，用户正在悄悄绕过它。你的仪表板依然显示绿色——延迟正常、错误率平稳、可用性完美。但满意度评分在下滑，工单里开始出现"AI 行为怪怪的"，曾经能处理 70% 咨询的功能现在勉强应付 50%。

这就是 AI 功能衰退：AI 驱动的功能逐渐退化，原因不在于模型变更或代码缺陷，而在于底层世界在它脚下悄然变化。不同于传统软件会以堆栈追踪的方式失败，AI 功能是无声退化的。系统在运行，模型在响应，输出在交付——只是它不再是用户所需要的了。

你团队中的一名初级工程师刚刚在一周内交付了三个功能。而你的资深工程师只完成了半个。仪表板显示初级工程师的效率是资深工程师的 6 倍。仪表板在撒谎。

这就是 AI 技能反转 —— 一种度量错觉。AI 编程助手让初级工程师在表面指标上看起来生产力惊人，却掩盖了更深层次的问题。功能交付得更快了，但架构却在退化。PR 成倍增加，但系统的连贯性却在瓦解。那些比起判断力更相信仪表板的组织，正在助长错误的行为，并流失掉正确的人才。

大多数 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 技术债务是复合增长的。一个默默退化的提示词会产生污染评估的训练信号，这会误导你下一轮提示词修改，进而进一步侵蚀用户体验的质量。等有人注意到时，三层假设已经在底下腐烂了。