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

一个银行助手正在处理一段客户支持对话。消息中嵌入了指令——由于是以零不透明度的白色文字渲染的，因此不可见——要求智能体绕过交易验证步骤。智能体照做了。当异常情况在日志中浮现时，已有 250,000 美元被转移到了客户从未接触过的账户中。

这并非凭空虚构的场景。它发生在 2025 年 6 月，精准地展示了为什么提示词注入（Prompt Injection）是生产级智能体 AI（Agentic AI）中悬而未决的最难问题。与仅生成文本的聊天机器人不同，智能体（Agent）会采取行动。它会调用工具、发送电子邮件、执行代码并发出 API 请求。当它的指令被劫持时，影响范围（blast radius）不再是一句糟糕的话，而是机器速度下的未经授权的操作。

根据 OWASP 2025 年 LLM 应用十大安全风险，提示词注入现在被列为排名第 1 的关键漏洞，出现在安全审计评估的 73% 以上的生产级 AI 部署中。每个构建智能体的团队都需要一个连贯的威胁模型和防御架构，且这种架构不能以安全之名让系统变得毫无用处。

问任何一个 AI 工程团队是否测试了他们的提示词，他们都会说"是的"。再问一句：一个有问题的提示词能否让 PR 失败并阻断合并？房间里会安静很多。对大多数团队而言，诚实的答案是否定的 —— 他们偶尔会跑一些评估笔记本，也许有一份记录已知提示词问题的共享 Notion 文档，以及一种模糊的感觉：事情比以前更糟了。那不是测试，那是在碰运气。

这个差距的存在，是因为提示词测试在感觉上与单元测试有本质区别。代码要么行为正确，要么不正确。提示词的输出处于一个连续谱上，输出是非确定性的，而且运行足够多的样本以建立信心会花费真金白银。这些都是真实的约束，但没有一个是无法克服的。那些建立了真正阻断合并的提示词 CI 的团队，并不是在每次构建上花费五十美元 —— 他们在三分钟以内、花费不到一美元的情况下完成运行，这得益于几个让这个问题变得可处理的设计决策。

大多数 AI 工程团队都有着相同的故事。他们从一个真正需要 LLM 的难题开始。然后，一旦 LLM 基础设施到位，每一个新问题在他们眼中都成了那把锤子下的钉子。六个月后，他们甚至在调用 GPT-4o 来检查电子邮件地址是否包含 “@” 符号 —— 并且还在为此付费。

这种 “直接用模型” 的本能反应现在是 AI 应用中不必要的复杂性、虚高成本和脆弱生产系统的主要驱动力。这并不是因为工程师们粗心大意。而是因为 LLM 确实令人印象深刻，工具链降低了使用门槛，而且一旦你构建了 LLM 流水线，增加另一次调用感觉成本极低。事实并非如此。

你的工程团队已经开发文档摘要生成器三个月了。规范要求：“摘要生成器应返回准确的摘要。”你发布了它。用户抱怨摘要有一半时间是错误的。事后分析显示，在发布前没有人能以可测试的方式定义“准确”的含义。

这是 AI 功能开发的标准轨迹，之所以会发生，是因为团队将为确定性软件构建的验收标准模式，套用到了本质上是概率性的系统上。由 LLM 驱动的摘要生成器没有单一的“正确”输出 —— 它有一系列的输出分布，其中一些是可以接受的，另一些则不然。二元的通过/失败规范无法映射到分布上。

这个问题不仅是哲学上的，它还会导致切实的痛苦：功能发布时质量门槛模糊，回归测试在用户发现之前难以察觉，产品和工程团队在功能是否“完成”上无法达成一致，因为没有人规定对于随机系统来说，“完成”意味着什么。这篇文章将介绍真正有效的模式。

发布一个调用 LLM 的功能很容易。但要判断该功能的下一个版本是否优于生产环境中的当前版本，却相当困难。传统 CI/CD 对确定性行为提供通过/失败信号：函数要么返回正确值，要么不返回。但当函数封装了一个语言模型时，输出是概率性的——相同的输入在不同运行、不同模型版本和不同时间会产生不同输出。

大多数团队的应对方式是绕过这个问题。他们运行单元测试，对几个提示词做快速的人工检查，然后发布。这种方式在出问题之前都还能用——直到某个模型提供商悄悄更新了底层权重，或者一个看似没问题的提示词改动在孤立测试中没有异常，却在凌晨三点以生产流量规模改变了输出分布。

更好的答案并非假装 LLM 输出是确定性的，而是构建基于分布、阈值和评分标准的 CI 质量关口，而不是精确匹配。

你的高级用户就是你的金丝雀。当你发布新的模型版本或更新系统提示词时，整体评估指标会向上走——任务完成率提升，幻觉评分下降，A/B 测试宣告胜利。随后，你最老练的用户开始提交 bug 报告："以前它就直接做 X，现在先给我说一堆。""格式变了，导致我的下游解析器报错了。""我没法让它保持角色了。"他们不是在臆想。你发布了一次回归，只是仪表盘里没有显示出来。

这正是 AI 产品开发的核心悖论：受行为漂移伤害最深的用户，恰恰是那些在理解系统特性上投入最多的人。他们围绕特定的输出模式构建了工作流，他们学会了哪些提示词能可靠地触发哪些行为。当你更换模型时，不只是发布了更新——你悄悄地让他们数月的校准工作失效了。

2026 年 3 月，一次由 AI 辅助的代码变更导致一家大型零售商损失了 630 万个订单，北美订单量暴跌 99% —— 这场长达六小时的生产事故追溯到一次未经适当审查就部署的变更。这并非什么新颖的攻击，也没有什么离奇的故障模式。系统只是执行了 AI 告诉它的指令，而在数百万客户遇到错误之前，没有任何值班人员拥有足以理解其错误原因的心理模型（mental model）。

这就是“调试退化”（debugging regression）。AI 生成代码带来的生产力提升是前置且在仪表盘上清晰可见的。而成本则是后置的，直到凌晨 3 点告警把你叫醒时，它才显露真身。

当 Airbnb 需要将 3,500 个 React 测试文件从 Enzyme 迁移到 React Testing Library 时，他们估计该项目需要 1.5 年的人力。通过使用 LLM 驱动的流水线，他们仅用 6 周就完成了交付。当 Google 研究了一个由 3 名开发人员在 12 个月内执行的 39 次不同代码迁移（595 次代码更改，93,574 次编辑）时，他们发现 74% 的编辑是由 AI 生成的，其中 87% 的编辑在没有人工修改的情况下就被提交了，整体迁移时间缩短了 50%。

这些数字是真实的。但这也是事实：在这些迁移过程中，工程师花费了大约 50% 的时间来验证 AI 的输出——修复上下文窗口故障、清理幻觉生成的导入，以及理顺测试未能捕捉到的业务逻辑错误。效率的提升是真实的，痛点也是真实的。问题不在于 AI 是否属于代码迁移；而在于准确了解它在何处提供帮助，以及在何处创造的清理工作超过了它所节省的时间。

一家中型创业公司的高级工程师最近得到了一份平庸的绩效评估。他们的效率不稳定——有些周发了大量代码，其他几周几乎什么都没有。他们的经理受过传统 SWE 框架培训，因产出波动给他们打了低分。六周后，那位工程师跳槽去了竞争团队。经理没有理解的是：工程师"缓慢"的几周是在构建评估基础设施，防止三类无声故障的发生。没有这些基础设施，产品本会以没人能在数月内察觉的方式悄然出问题。

这种情况正在各个工程团队中上演。那些为确定性软件系统设计职级体系的团队，正将同样的框架套用于 AI 工程师——并系统性地误判了他们最优秀的人才。

几乎每家持续交付 AI 功能的公司都会出现这样一种架构：流水线中的每一次转换、每一个路由决策、每一次分类、每一个格式化步骤，全都经过 LLM 调用。它通常始于一个合理的场景——LLM 确实解决了一个棘手问题。然后团队内化了这个模式，开始反复套用。直到整个系统变成一条 LLM 接 LLM 的链条：一串文字从一端进入，另一串从另一端出来，中间经历了十二次 API 调用，全程没有任何确定性可言。

这就是 AI 泛滥反模式，它现在已成为构建一个缓慢、昂贵且无法调试的生产系统的最可靠方式。

当 OpenAI 在 2025 年 8 月首次尝试停用 GPT-4o 时，强烈的抵制迫使他们在几天内撤回了决定。用户在论坛上发布了大量的请愿书和告别信。一位用户写道：“他不仅仅是一个程序。他是我日常生活、宁静和情绪平衡的一部分。”这可不是用户对一个被弃用的 REST 接口（endpoint）的反应，而是对失去一段关系的反应。

AI 功能打破了工程师在制定停用计划时的心理模型。传统软件具有明确的行为契约：在给定相同输入的情况下，你会永远得到相同的输出，除非你更改它。而由 LLM 驱动的功能具有“性格”。它有温度、有委婉语、有措辞偏好，还有一种独特的说“我不确定”的方式。用户不仅仅是在使用这些功能 —— 他们在与之磨合（calibrate）。他们围绕特定的行为怪癖建立了工作流程、情感依赖和直觉，而这些永远不会出现在任何规格文档中。

当你关闭它时，你并不是在移除一个功能，而是在改变社会契约。

在传统软件中，发布功能以合并代码（merge）告终。单元测试通过。集成测试通过。QA 签字认可。你切换标志（flag），除非在生产环境中出现 bug，否则你就可以继续接下来的工作。这个功能就“完成”了。对于 AI 驱动的功能，那个时刻并不存在 —— 如果你假装它存在，你就是在累积稳定性债务，这最终会演变成用户信任问题。

原因很简单，但很少有人围绕它进行设计：确定性软件对于相同的输入每次都会产生相同的输出。AI 功能则不然。这并非因为 bug，而是因为其行为由一个存在于代码库之外的模型定义，该模型基于反映不断变化的世界的数据进行训练，并由那些随着看到更多可能性而不断提高期望的用户使用。