AI Effect与AI应用落地：从Demo到可评估的工程实践

AI Effect 并不是某个模型的名字，也不是某个新框架，而是一类普遍存在的认知现象：当一项 AI 技术真正实用化之后，人们往往不再把它看作 AI。OCR 识别、语音助手、推荐系统都经历过这个过程。工程上更有价值的判断是，大量 AI 项目的效果问题并不是出在模型本身，而是出在模型能力与系统效果的混淆上。本文从 AI Effect 这个概念出发，结合 Spring AI、AI Agent、Ollama 本地部署、AMD Ryzen AI 平台的 GPU 配置、AI 幻觉与 AI 测试、Cursor AI 编程、生成式内容应用的 Credits 管理等内容，完整梳理一条从 Demo 到可评估、可维护、可排查的 AI 应用落地路径。读完可以自己搭一个最小 AI Agent 服务，能配置本地模型并确认 GPU 是否生效，也能给模型输出建立一套可量化的评估方法。

1. AI Effect：先弄清楚“效果来自哪里”，再谈 AI 工程

1.1 什么是 AI Effect

AI Effect 可以这样理解：某项技术起初因为实现手段特殊、结果超出预期，被认为是“人工智能”。可一旦它进入生产环境、被大规模使用，人们就会说“这只是一个规则系统”“这不过是个普通算法”，于是它就从 AI 的范畴里被移除了。

这个现象不是某个团队独有的问题，而是技术普及过程中的普遍认知偏差。识别二维码、自动翻译、垃圾邮件过滤、道路车牌识别，在诞生初期都被当作前沿 AI 成果。今天很多工程师在使用这些能力时，不会强调它们属于 AI，只会把它们当作系统中的一个普通模块。

从技术传播角度看，这其实是进步。但从 AI 工程实践角度看，它引出关键问题：当一项 AI 能力被“去神秘化”之后，团队反而更容易忽略它仍然具有概率性、依赖数据分布、需要评估和兜底这些基本事实。

1.2 生成式 AI 时代的 AI Effect 变形

把 AI Effect 放到大语言模型时代，现象发生了变形。过去是“AI 成功之后不再叫 AI”，现在则反过来：一个应用只要接入了模型 API，把用户输入转发给模型，再把模型输出展示出来，就会被直接称为“AI 应用”。

问题是，真正影响用户体验的往往不在模型那一层，而在系统设计层。同样的模型，在不同的提示词、不同的工具编排、不同的上下文管理方式下，输出质量会有明显差异。把问题全部归因于模型，就会错过真正可以修复的环节。AI Effect 在生成式 AI 时代的工程含义是：不要因为产品界面看起来智能，就假定模型已经承担了全部思考工作；也不要因为一次输出不理想，就认定模型“不行”。

对应到具体项目里，需要把以下三个层次分开评估。

1.3 对 AI 应用开发的三点实际影响

实际开发中，AI Effect 会表现在三个容易被忽视的方向上。

第一，团队容易只看演示效果，不重视测试与评估。演示时模型输出正确，不代表换一批数据仍然正确。AI 应用需要像普通后端服务一样有测试集、回归验证和上线监控。

第二，团队容易低估部署与运维的复杂度。模型调用延迟、并发上限、Token 成本、内容安全、数据隐私，这些都不是模型能力本身能解决的，需要从系统架构层面设计。

第三，团队容易混淆“模型能力”和“最终效果”。一个 AI Agent 能正确回答问题，可能是模型起了作用，也可能是工具函数写得好、提示词约束得当、记忆管理正确。要定位问题，必须先有能力区分这些因素。

2. AI 应用开发的技术跨度：提示词、Agent 与 Credits

2.1 提示词工程是起点，不是全部

提示词是开发者与模型交互的第一层接口。它决定模型如何理解任务、如何约束输出、如何利用上下文。

一个适合工程场景的提示词，不只是写一句话，而是包含角色、任务、约束、输入、输出格式五部分。

你是一个电商订单助手，面向普通消费者。 任务：根据用户问题查询订单状态并给出简短回答。 约束： 1. 只有订单号以 ORD 开头时才允许查询。 2. 如果信息不足，直接说明缺少哪个字段，不要编造。 3. 回答不超过两句话。 输入：{用户输入} 输出格式：纯文本，不要使用 Markdown 标题。

这只是一个示例。实际项目的提示词会根据场景变得更长、更结构化。但提示词本身也属于代码资产，应该进入 Git 仓库，经过评审，有版本记录。否则改了一版提示词之后，出了问题无法回滚。

2.2 AI Agent 把“对话能力”变成“执行能力”

与单轮问答相比，AI Agent 的核心差异是引入了执行循环。大模型不只是生成文本，还要根据任务目标做计划、调用外部工具、读取工具结果、决定下一步动作，最后输出答案。

一个最简单的 Agent 执行流程可以这样描述：

接收用户目标 -> 拆解成子任务 -> 判断是否要调用工具 -> 调用工具并获取结果 -> 根据结果继续生成下一步内容 -> 直到满足结束条件，输出最终答案

工程上实现 Agent 并不神秘。稳定的做法是给模型提供一组带描述的函数，让模型在需要时返回特定格式的调用意图，由代码执行函数并把结果回传给模型。Spring AI 的@Tool注解就是这种模式的封装。这里要特别提醒：工具函数的质量直接影响 Agent 的可靠性。工具描述写不清楚，模型就不会正确选择调用；工具返回结构不稳定，模型在后继轮次里就无法有效利用结果。

2.3 Credits 在 AI 里指什么

很多 AI 平台把 Credits 作为计费单位，它通常表示用户调用模型接口的可消耗额度。一次对话消耗多少 Credits，一般由输入 Token、输出 Token、模型单价、额外功能叠加共同计算。不同平台的计数口径不同，有的按 Token，有的按调用次数，有的按图片数量或视频秒数。

在开发 AI 应用时，Credits 就是真实的资源成本。常见的成本控制手段包括：

• 对高频、低风险问题使用更小更便宜的模型。
• 对长上下文的会话做摘要，避免每次请求都携带完整历史消息。
• 对结果不变化的请求做缓存。
• 设置每日或单用户消耗上限，防止异常调用导致费用飙升。
• 批量生成任务放在低峰时段执行，并做好失败重试的损耗控制。

不要把 Credits 当作运营侧才关心的问题。开发阶段不记录用量，生产环境就很容易出现成本失控。

3. 使用 Spring AI 构建一个最小 AI Agent 服务

3.1 场景与选型

如果你的项目已经运行在 Java 和 Spring 技术栈上，使用 Spring AI 接入大模型会比直接拼接各家 SDK 更顺手。Spring AI 提供统一的 ChatModel、ChatClient、Tool、ChatMemory 抽象，切换模型厂商时不用重写业务代码，也能复用 Spring Boot 的配置、日志、监控能力。

本文示例使用 Spring AI 1.x 的 API。由于 Spring AI 迭代速度很快，落地前需要到 Maven 中央仓库或官方文档确认当前版本号，并核对当前版本的 API 变化。

3.2 环境准备与依赖配置

环境要求如下。

在pom.xml中引入 BOM 和模型依赖。

<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-bom</artifactId> <version>${spring-ai.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

再根据选择注册spring-ai-starter-model-openai，或者在本地模型场景使用spring-ai-starter-model-ollama。

<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-model-openai</artifactId> </dependency>

配置application.yml。

spring: application: name: ai-effect-demo ai: model: openai: api-key: ${OPENAI_API_KEY:your-api-key} chat: options: model: gpt-4o-mini

实际项目中，API Key 不要写死在配置文件里，应该通过环境变量或配置中心注入。模型名称、Base URL 也要根据你实际使用的服务调整。

3.3 最小对话调用

先写一个最基础的接口，验证 Spring AI 能否正常调用模型。

@RestController public class ChatController { private final ChatModel chatModel; public ChatController(ChatModel chatModel) { this.chatModel = chatModel; } @GetMapping("/chat") public String chat(@RequestParam(defaultValue = "你好，请介绍一下自己") String message) { return chatModel.call(new Prompt(message)) .getResult() .getOutput() .getText(); } }

启动应用后访问：

curl "http://localhost:8080/chat?message=你好"

如果配置正确，接口会返回模型生成的文本。这一步只做连通性验证，让团队确认依赖、密钥、模型服务三个环节都正常。

3.4 加入工具调用，改成 Agent

工具调用的核心是把一个 Java 方法暴露给模型。方法名和参数描述越准确，模型越容易在正确时机调用它。

创建一个订单查询工具。

@Component public class OrderQueryTool { @Tool(description = "根据订单号查询订单状态，订单号以 ORD 开头") public String queryOrder(String orderId) { if (orderId == null || !orderId.startsWith("ORD")) { return "无效订单号，请检查后重试"; } // 实际项目中这里会调用订单服务或查询数据库 return "订单 " + orderId + " 当前状态：已发货，预计3天内送达"; } }

然后通过ChatClient把这个工具注册给模型。

@Service public class OrderAgentService { private final ChatClient chatClient; public OrderAgentService(ChatClient.Builder builder, OrderQueryTool tool) { this.chatClient = builder .defaultSystem("你是一个订单助手。用户查询订单状态时，必须使用 queryOrder 工具。") .defaultTools(tool) .build(); } public String ask(String message) { return chatClient.prompt(message).call().content(); } }

这里需要理解一个关键点：工具调用并非由框架判断“该不该调用”，而是由模型根据用户问题和工具描述决定。因此工具描述必须写得足够具体，包括入参规则、返回值含义、适用条件。工具方法内部则要像普通业务代码一样处理空值、异常和非法输入。

3.5 多轮会话与记忆

Agent 的多轮交互比单轮问答更依赖会话记忆。没有记忆机制，模型会丢失前文提到过的订单号或用户偏好。

Spring AI 提供了ChatMemory接口和内存实现。简单场景可以直接使用内存版。

@Bean public ChatMemory chatMemory() { return new InMemoryChatMemory(); }

在构建ChatClient时挂载记忆。

this.chatClient = builder .defaultSystem("你是一个订单助手。") .defaultTools(tool) .defaultMemory(chatMemory) .build();

内存版适合学习和测试。生产环境应对接 Redis、数据库等外部存储，否则多实例部署时记忆不共享，重启后会话数据也会丢失。

3.6 运行验证与预期输出

启动服务后，依次执行两个请求。

curl "http://localhost:8080/chat?message=你好" curl "http://localhost:8080/chat?message=请帮我查一下订单ORD20250101的状态"

第二个请求的正常输出，应该是“订单 ORD20250101 当前状态：已发货，预计3天内送达”。判断 Agent 是否真正生效，可以观察两点：一是模型是否主动调用了queryOrder工具，二是输出内容是否来自工具返回结果。如果模型只是根据自身知识生成订单状态，那说明工具调用没有生效，需要检查工具描述和系统提示词。

注意：不要只验证程序能启动，还要验证输入、输出、异常分支和日志是否符合预期。工具调用链路的验证重点是“业务结果来自工具还是来自模型生成”。

4. 本地部署 AI 模型：Ollama 与 AMD Ryzen AI 9 HX 370 的 GPU 配置

4.1 本地部署的适用场景

本地部署 AI 模型的核心价值是数据不出域、离线可用、单位调用成本可控。对于企业内部文档问答、敏感数据分析和边缘设备场景，这是明显优势。

代价是硬件门槛。大模型的显存占用通常在数 GB 到数十 GB 之间，普通消费级设备能流畅运行的模型参数量有限。本地部署不等于“部署越大越好”，而是要根据硬件条件选择合适尺寸的模型。

4.2 Ollama 安装与基础使用

Ollama 是目前最常见的大模型本地运行工具之一。Linux 和 macOS 可以使用安装脚本，Windows 使用官方安装包。

安装完成后，拉取模型并启动服务：

ollama pull qwen2.5:7b ollama run qwen2.5:7b

模型名称和版本以 Ollama 官方库当前可用的为准。ollama run会进入交互式对话界面，也可以先退出交互，用 HTTP 接口验证服务是否正常。

curl http://localhost:11434/api/generate \ -d '{"model": "qwen2.5:7b", "prompt": "你好，请用一句话自我介绍", "stream": false}'

返回结果包含response字段，就说明本地模型服务链路已经跑通。

4.3 在 AMD Ryzen AI 9 HX 370 平台上让 Ollama 使用 GPU 的排查路径

“如何让 Ollama 使用 GPU 运行”是本地部署用户经常遇到的问题。Ollama 在启动时会检测当前系统的 GPU 和驱动，但 AMD 平台的配置比 NVIDIA 更依赖额外组件。AMD 平台通常需要 ROCm 或 Vulkan 支持，而且不同版本的 Ollama 对 AMD GPU 的支持情况有差异，不一定默认启用。

在 AMD Ryzen AI 9 HX 370 这种集成 Radeon 核显和 NPU 的移动平台上，排查顺序建议如下。

第一步，确认驱动状态。更新 AMD 官方驱动，确保核显驱动正常识别。

第二步，确认 Ollama 版本。不同 Ollama 版本对 ROCm 的集成程度不同，Vulkan 和 ROCm 的支持范围也不一样。需要到 Ollama 官方文档或 GitHub 仓库确认当前版本对 AMD GPU 的支持情况，尤其是对核显的支持。

第三步，运行模型后查看实际使用设备。

ollama ps

如果输出中显示处理器信息为 CPU，说明模型正在 CPU 上运行。此时可以尝试设置环境变量强制启用 ROCm，或者切换使用支持 Vulkan 的版本。

注意：不要默认 AMD 核显一定能跑大模型。核显共享系统内存，算力和显存带宽与独立显卡有差距，7B 模型在核显上的推理速度可能明显低于 NVIDIA 独显。具体支持情况要以当前 Ollama 和驱动版本的官方说明为准。

4.4 验证 GPU 是否真正生效

ollama ps是最直接的验证方式。它显示的字段中包含处理器信息，如果显示 GPU，说明模型已经加载到显卡；如果显示 CPU，说明使用的还是 CPU 推理。

在 Linux 下，可以用 ROCm 工具查看 GPU 占用：

rocm-smi

在 Windows 下，可以打开任务管理器或 AMD 软件，观察 GPU 利用率是否在推理过程中明显上升。

还有一个实用方法：用同一个模型、同一个问题，分别记录 CPU 模式和 GPU 模式下的推理耗时。如果 GPU 生效，首 Token 延迟和总生成时间通常显著下降。如果两者几乎没有差别，说明 GPU 没有真正参与计算。

4.5 本地模型与 Spring AI 的对接

本地模型部署好之后，可以和前面的 Spring AI 服务对接。只需要把依赖换成spring-ai-starter-model-ollama，并配置 Ollama 的地址和模型名。

spring: ai: ollama: base-url: http://localhost:11434 chat: options: model: qwen2.5:7b

这样本地模型就通过统一的ChatClient接口接入应用，业务代码不需要改动。对开发者来说，这也是一种合理的“模型替换”方式：开发环境用本地模型，生产环境用云端模型，接口保持一致。

5. AI 幻觉与 AI 测试：把模型输出质量做成可评估体系

5.1 AI 幻觉：现象与原因

AI 幻觉指的是模型生成了看起来合理、但与事实不符的内容。常见现象是模型在回答中给出了不存在的订单号、编造的 API 参数、虚构的引用来源。

产生幻觉的原因可以归结为几点：模型本质上是概率化文本生成，它没有稳定的数据库可以查询；训练数据本身可能有缺失或错误；提示词没有提供足够的事实约束；解码策略偏向流畅性，导致模型宁可“编一个顺理成章的答案”，也不愿意承认不知道。

这段判断对应到 AI Effect 上尤其明显：当模型输出流畅时，用户和开发者都容易下意识地认为内容正确。而这种信任一旦迁移到业务判断上，就会造成比普通代码 Bug 更隐蔽的问题。

5.2 评估一个 AI 应用是否合格

评估一个 AI 应用不能只看“能不能回答”，而是要看几个维度。

每个维度都应该转成具体测试用例。例如，“正确性”可以准备 100 条带标准答案的测试问题，每次版本变更后跑一遍回归。

5.3 可落地的 AI 测试方法

最基础的方法是建立回归测试集。把业务里的高频问题、边界问题、容易产生幻觉的问题统一记录下来，形成结构化 JSON 测试文件。

[ { "input": "查询订单 ORD20250101 的状态", "expected_contains": ["已发货"] }, { "input": "查询订单 ABC 的状态", "expected_contains": ["无效订单号"] } ]

编写脚本批量调用服务，再判断输出是否包含预期关键词。这种方式成本低，能快速捕获大多数回归问题。

更进一步的评估可以引入“LLM-as-a-judge”方法，让另一个模型对输出打分。但使用时要谨慎，因为裁判模型本身也可能有偏见。推荐做法是：用规则判断事实类字段，用模型判断语言质量和相关性，最终保留一定比例的人工抽检。

线上监控同样必要。至少记录空响应率、超时率、用户“继续提问”次数、敏感内容命中次数。这些指标比单次输出质量更能反映真实体验。

5.4 降低幻觉的工程手段

第一，给模型提供可信上下文。最常用的是 RAG，把用户问题与知识库中的相关片段拼接后再送给模型，让模型基于片段回答。

第二，明确告知模型“不知道时不要编造”。在系统提示词中写明：“如果信息不在上下文中，回答‘我无法从给定信息中确认’。”这不能完全消除幻觉，但能显著减少强行回答。

第三，降低解码随机性。对事实类任务，可以把 temperature 调低，比如 0.1。这只是减少随机波动，不会让模型瞬间变得绝对可靠。

第四，对结构化输出做程序校验。让模型返回 JSON 后，用 JSON Schema 校验字段类型、枚举值和必填项，不合法就触发重试或降级。

6. AI 编程与生成式内容应用：从 Cursor AI 提示词到 AI 短剧链路

6.1 Cursor AI 编程提示词的结构

Cursor 这类 AI 编程工具的价值不是“一键生成整个项目”，而是把开发者从重复性编码中解放出来。前提是开发者必须能把任务描述清楚。

一个适合工程落地的 AI 编程提示词可以这样组织：

背景：我在开发一个基于 Spring Boot 3 的订单查询服务。 目标：实现一个接口，根据订单号查询订单状态。 技术栈：Java 17、Spring Web、Spring AI。 约束： 1. 订单号以 ORD 开头，其他格式返回 400。 2. 查询结果来自数据库，不要写死。 3. 统一使用 Result 包装返回。 验收标准： 1. 单元测试覆盖正常和非法订单号场景。 2. 接口返回包含 code、message、data 三个字段。 请先生成实现方案，不要直接修改代码。方案确认后再开始编码。

这里的关键是“先生成方案，再开始编码”。直接让 AI 改大文件，往往会产生超出预期的修改。先让 AI 说明思路，开发者确认方向，能减少大量返工。

6.2 AI 生成代码的审查重点

AI 生成的代码能运行，不代表可以上线。代码审查时要重点看这几个方向：

• 依赖是否最小化，是否引入了不清楚来源的第三方库。
• 异常处理是否完整，网络超时、模型返回空、工具调用失败有没有兜底。
• 日志是否包含请求 ID 和关键参数，出问题后能否定位链路。
• 敏感信息是否泄露，API Key、密钥是否出现在日志或前端代码中。
• 是否处理了并发场景，多轮会话、共享变量、线程安全是否有隐患。
• 是否补充了测试，至少覆盖正常路径和主要异常路径。

6.3 从 AI 绘画到 AI 短剧的内容生产链路

生成式内容应用近年来从 AI 绘画延伸到 AI 视频、AI 短剧。它们背后的工程链路是相似的：需求拆解、素材生成、内容拼接、审核发布。

以一个 AI 短剧制作流程为例。

这个链路里的工程问题通常不在某个单独模型，而在于长链路的状态管理和成本控制。每个环节都可能失败，失败之后重试又会消耗 Credits，这是一个完整的业务系统设计问题，不能只在提示词层面解决。

6.4 Credits 与生成任务的成本控制

批量生成内容时，Credits 消耗会呈指数级放大。一个脚本生成几十个分镜，每个分镜生成多张候选图，每张图又要选一张做放大和再生成，一次任务可能消耗数百次调用。

控制成本可以从三个方向入手。第一，限制候选数量，每次只生成少量选项，而不是无限重试。第二，缓存已有结果，同一脚本、同一参数组合不重复生成。第三，增加人工确认节点，让生成结果进入下一环节前由人做一次筛选，避免后续环节在错误素材上继续消耗。

7. 常见故障排查与生产落地清单

7.1 常见故障排查表

AI 应用从开发到部署的故障，往往集中在模型调用、工具调用、部署配置和成本控制四个方面。下面这张表可以直接用于排错。

7.2 AI 应用生产落地检查清单

发布一个 AI 应用之前，至少确认下面这些项目已经完成。

• 配置外置化：API Key、模型名、Base URL 通过环境变量或配置中心管理。
• 日志可观测：每个请求有唯一 ID，记录入参、出参、Token 用量和耗时。
• 成本控制：设置单用户、单接口的调用上限，失败重试次数有限。
• 内容安全：生成内容有自动检测和人工抽检机制。
• 数据隐私：用户输入不进入不必要的外部服务，敏感数据脱敏。
• 版本管理：提示词、工具函数、模型版本都进入 Git，支持回滚。
• 评估回归：准备测试集，每次改动后跑一遍关键场景。
• 灰度发布：新模型或新提示词先在小流量范围验证。
• 监控告警：空响应率、错误率、延迟、成本消耗有告警阈值。

7.3 下一步学习方向

如果想把 AI 应用开发做到更深，可以参考这条主线：先熟练 API 调用和提示词编写，再学习 RAG 补齐外部知识，然后掌握 Agent 工具编排与会话管理，之后根据业务需要做模型微调或向量数据库选型，最后补上模型服务化部署和 GPU 调优。每一步都可以回到本文的核心问题上继续追问：当前系统的效果到底来自模型、提示词、工具还是数据链路。

模型能力会持续变化，工具版本也会不断更新，不变的是工程判断力。下一次再评估一个 AI 项目时，不要先问“模型够不够强”，而是先问“问题出在哪一层”。能回答清楚这个问题，AI Effect 就不会变成项目里的认知陷阱。