面对 AI 的冲击很多开发者的第一反应是愤怒愤怒 AI 生成的代码质量差愤怒 AI 抢走了初级岗位愤怒技术变化太快让人喘不过气。但我最近在项目实战和团队协作中越来越清楚地感受到愤怒只会让人停在原地焦虑却能推着人往前走。焦虑的本质是你意识到“事情在变化我需要做点什么”而愤怒的本质是你希望“事情别变化最好回到从前”。把焦虑转化为具体的行动才是 AI 时代开发者最该掌握的能力。这篇文章我不想只讲心态而是想用一套可落地的技术实践带你走一遍“从焦虑到行动”的完整路径理解大模型的核心概念、搭好本地 AI 开发环境、从零写一个可运行的 AI Agent、了解 Java 生态里的 Spring AI最后梳理工程落地中的常见问题和最佳实践。无论你是刚接触 AI 开发的新手还是想把手头项目 AI 化的后端工程师这篇文章都能给你一条清晰、可复制的学习与实战路线。1. 为什么是“焦虑”而不是“愤怒”1.1 AI 冲击下开发者的两种反应每次技术变革都会把开发者分成两类。一类人选择愤怒。他们看到 AI 生成的代码有 Bug就得出“AI 不行”的结论看到 AI 工具在局部任务上表现平平就认为整个方向都是泡沫。愤怒让人产生一种短暂的安全感——仿佛只要否定 AI自己的技术栈就不会过时岗位就不会被替代。另一类人选择焦虑。他们承认 AI 在很多任务上确实比自己快承认有些工作内容会被重新定义但同时他们也在问一个关键问题既然 AI 这么强我该学什么、做什么才能让它变成我的杠杆我属于后者。坦率地说2023 年大模型刚火起来的时候我焦虑到失眠。但后来我发现焦虑本身不是坏事它说明你的认知边界被打破了而打破认知边界是学习的第一步。1.2 把焦虑转成行动从“旁观者”到“使用者”消除焦虑最有效的方法不是继续刷新闻而是动手写代码。当你真正把一个大模型 API 调到自己的项目里当你写出的 Prompt 稳定地解决了某个业务问题当你看着自己搭的 Agent 自动完成多步任务时焦虑就会慢慢变成掌控感。这种掌控感不是来自“我会背概念”而是来自“我真的跑通了一个东西”。因此本文的实操重点会围绕以下能力展开理解大模型应用开发的核心概念Token、Prompt、RAG、Agent、Function Calling。在本地搭建一套可用的 AI 开发环境哪怕只是调用开放 API。用 Python 从零写一个支持工具调用的 AI Agent 示例。了解 Java 开发者如何用 Spring AI 快速接入大模型。掌握 AI 项目上生产环境时的常见坑点和最佳实践。下面我们直接进入技术环节。2. AI 时代开发者需要理解的核心概念在写代码之前先把 AI 开发中最常用到的一组概念讲清楚。这些概念不多但每个都直接关系到你能否写出可靠的应用。2.1 大语言模型与 Token大语言模型Large Language ModelLLM本质上是一个根据前文预测下一个词的概率模型。你输入一段文本模型逐字更准确地说逐 Token生成后续内容。Token 是模型处理文本的最小单位。一个 Token 可以是一个词的一部分、一个完整单词或一个标点符号。不同模型的 Tokenizer 不一样中文通常一个字或几个字会被拆成多个 Token。为什么开发者需要关心 Token因为 Token 直接决定了API 调用成本按 Token 计费上下文窗口上限模型一次能接收和输出的文本总量响应速度Token 越多生成越慢。举个直观的例子一份 1000 字的中文文档可能对应 1500 到 2000 个 Token。如果你要把它完整塞进 Prompt就要提前估算 Token 消耗。# 简单估算 Token 数量的示例实际以模型 Tokenizer 为准 def estimate_tokens(text: str) - int: # 中文场景下粗略按 1 个汉字 ≈ 1.5 Token 估算 # 英文场景下粗略按 1 个单词 ≈ 1.3 Token 估算 chinese_chars sum(1 for ch in text if \u4e00 ch \u9fff) other_chars len(text) - chinese_chars return int(chinese_chars * 1.5 other_chars * 0.3) text 人工智能正在改变软件开发的方式 print(estimate_tokens(text))注意这段代码只是帮助你建立直观感受真实场景请使用模型对应的 Tokenizer 库或者 API 返回的 usage 字段。2.2 Prompt、System Prompt 与上下文窗口Prompt 就是你给模型的输入。大模型应用开发的大部分工作都是在设计和管理 Prompt。一个规范的 Prompt 通常包含几个部分System Prompt系统提示词定义模型的角色、任务边界、输出格式。对开发者来说这是最值得花时间优化的部分。User Prompt用户提示词用户实际输入的内容。上下文内容可能是从数据库、文档或工具返回结果中拼装出来的参考材料。这里的关键认知是模型本身没有记忆每次调用都是独立的。你看到的“多轮对话”不过是开发者把历史记录拼进上下文再传给模型。messages [ {role: system, content: 你是一名资深的 Python 开发工程师回答要简洁、准确优先给出可运行的代码。}, {role: user, content: 如何用 Python 读取一个 JSON 文件} ]系统提示词写得好不好对输出质量的影响非常明显。很多开发者抱怨“AI 回答太啰嗦”“AI 总是跑题”其实问题多半出在 System Prompt 没有约束好。2.3 RAG、Agent 与 Function Calling接下来是三个在工程中高频出现的概念。RAGRetrieval-Augmented Generation检索增强生成当模型不知道你业务中的私有知识时先把相关内容检索出来拼进 Prompt再让模型基于这些内容回答。简单说就是“先查资料再回答问题”。Agent智能体在大模型基础上赋予模型“感知 → 决策 → 行动”的能力。比如模型判断需要查天气就调用天气查询工具拿到结果后再组织回答。Function Calling函数调用让模型输出结构化的 JSON告诉开发者“我打算调用哪个函数、参数是什么”然后由你的代码真正执行函数。这是实现 Agent 的关键机制。这三者的关系可以这样理解RAG 解决“知识不够”的问题Function Calling 解决“光说不做”的问题Agent 是把它们串起来的执行框架。3. 环境准备把 AI 开发工具链装进本地3.1 基础环境说明本文示例以常见环境为例具体版本请根据你的项目实际情况调整。操作系统Windows / macOS / Linux 均可编程语言Python 3.10包管理工具pip 或 conda开发 IDEVS Code / PyCharm / IDEA 均可Java 环境Spring AI 示例需要JDK 17建议在动手前先确认本机 Python 和 Node.js 环境。后面所有 Python 示例都建议在虚拟环境中运行避免污染系统环境。# 创建虚拟环境 python -m venv .venv # 激活虚拟环境 # Windows .venv\Scripts\activate # macOS / Linux source .venv/bin/activate3.2 模型 API 与本地模型的选择动手开发 AI 应用第一步是选择模型来源。常见的选型有方案优点注意事项国内大模型 API如通义千问、文心一言、智谱、DeepSeek 等访问稳定、中文效果好、文档完善各平台鉴权方式略有差异OpenAI 兼容接口生态成熟、工具链丰富需要确认网络环境与合规要求本地部署开源模型如 Qwen 系列、Llama 系列数据不出内网、隐私可控需要 GPU 资源、部署运维成本高大多数刚开始接触 AI 开发的读者建议优先使用 API 方式。等业务稳定了再根据成本和安全需求决定是否私有化部署。3.3 IDE 中的 AI 插件工欲善其事必先利其器。当前主流的开发 IDE 基本都支持 AI 插件PyCharm / IDEAJetBrains AI Assistant或者安装 Continue 等开源插件。VS CodeGitHub Copilot、Continue、Cline 等。Cursor基于 VS Code 的 AI 优先编辑器适合喜欢极致 AI 编程体验的开发者。AI 插件的核心价值不是替你做决定而是减少重复劳动。比如生成单元测试、解释陌生代码、批量重命名等场景AI 插件确实能明显提速。4. 实战案例从 Prompt 到可运行的 AI Agent这一节我们动手写一个完整的 AI Agent。功能很简单用户问“北京天气怎么样”Agent 先调用天气查询工具再把查询结果整理成自然语言回答。整个项目只用 Python 标准库和openaiSDK不引入重型框架便于你理解底层原理。4.1 创建项目结构ai-agent-demo/ ├── .env ├── requirements.txt ├── main.py └── tools.py4.2 添加依赖# requirements.txt openai1.30.0 python-dotenv1.0.0安装依赖pip install -r requirements.txt4.3 编写工具函数先写一个模拟天气查询工具。真实项目中这个函数会调用第三方天气 API 或读取内部数据源。# tools.py import json def get_weather(city: str, date: str 今天) - str: 模拟天气查询工具。 实际项目中可以替换为真实天气 API 调用。 # 这里只是演示返回值不要当真 mock_data { city: city, date: date, weather: 晴, temperature: 18~26℃, wind: 东南风 2 级, humidity: 45% } return json.dumps(mock_data, ensure_asciiFalse)# main.py import os import json from openai import OpenAI from dotenv import load_dotenv from tools import get_weather load_dotenv() # 初始化客户端 client OpenAI( api_keyos.getenv(API_KEY), base_urlos.getenv(BASE_URL), ) # 一个简单的模型名实际请替换为你所用平台的模型 MODEL_NAME os.getenv(MODEL_NAME, qwen-plus) def run_agent(user_input: str): messages [ { role: system, content: 你是一个智能助手。当用户询问天气时你必须调用 get_weather 工具获取数据再结合工具结果回答用户。回答要简洁自然。 }, {role: user, content: user_input} ] # 第一轮请求让模型判断是否需要调用工具 response client.chat.completions.create( modelMODEL_NAME, messagesmessages, tools[ { type: function, function: { name: get_weather, description: 查询指定城市在指定日期的天气情况, parameters: { type: object, properties: { city: {type: string, description: 城市名如 北京}, date: {type: string, description: 日期如 今天、明天} }, required: [city] } } } ], tool_choiceauto, ) response_message response.choices[0].message # 如果模型没有要求调用工具直接返回回答 if not response_message.tool_calls: print(模型回答, response_message.content) return # 解析工具调用 tool_call response_message.tool_calls[0] function_name tool_call.function.name arguments json.loads(tool_call.function.arguments) print(f模型决定调用工具{function_name}参数{arguments}) # 执行真实工具 function_result get_weather(**arguments) print(f工具返回{function_result}) # 把工具结果拼进消息历史做第二轮请求 messages.append(response_message) messages.append( { role: tool, tool_call_id: tool_call.id, content: function_result, } ) # 第二轮请求让模型根据工具结果组织最终回答 second_response client.chat.completions.create( modelMODEL_NAME, messagesmessages, ) print(最终回答, second_response.choices[0].message.content) if __name__ __main__: run_agent(北京今天天气怎么样)4.4 配置环境变量# .env API_KEY你的_API_Key BASE_URLhttps://你的模型服务地址/v1 MODEL_NAMEqwen-plus如果不确定 API Key 和 Base URL 怎么填请查看你所选模型平台的官方文档。不同平台的鉴权方式可能不同但openaiSDK 的调用方式是兼容的。4.5 运行与验证python main.py预期输出类似模型决定调用工具get_weather参数{city: 北京, date: 今天} 工具返回{city: 北京, date: 今天, weather: 晴, temperature: 18~26℃, wind: 东南风 2 级, humidity: 45%} 最终回答北京今天天气晴朗气温在 18~26℃ 之间东南风 2 级湿度 45%整体感觉比较舒适。这个示例虽然简单但完整演示了 AI Agent 的核心链路模型接收用户输入判断需要调用工具模型输出结构化的工具调用指令我们的代码真正执行工具函数获取结果工具结果返回给模型模型整理成用户可读的回答。这就是 Function Calling 的完整闭环。理解了它你就理解了当前大部分 Agent 产品的基本原理。5. 从手写 Agent 到框架化开发5.1 Java 开发者用 Spring AI 快速接入Python 生态有 LangChain、LlamaIndex 等框架Java 生态目前最值得关注的是 Spring AI。它把大模型接入整合进 Spring Boot 的开发模式对于已经使用 Spring 的后端团队上手成本很低。下面是一个极简示例演示如何用 Spring AI 实现流式对话。!-- pom.xml 核心依赖 -- dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version1.0.0/version /dependency注意Spring AI 版本迭代很快不同版本 API 存在差异。这里展示的是最常见用法具体版本请以官方文档为准。// MainController.java RestController public class MainController { private final ChatClient chatClient; public MainController(ChatClient.Builder builder) { this.chatClient builder.build(); } GetMapping(/chat) public String chat(RequestParam String message) { return chatClient.prompt() .system(你是一名 Java 后端开发专家回答要简洁直接。) .user(message) .call() .content(); } }Spring AI 的价值在于它提供了统一的ChatClient接口屏蔽了不同模型厂商的 API 差异。如果你的团队已经在使用 Spring Boot接 AI 能力时优先考虑 Spring AI 是很合理的选择。5.2 为什么不建议一上来就上框架很多新手一接触 AI 开发就直接学 LangChain结果被各种 Chain、Agent、Memory 概念绕晕。我的建议是先手写一遍底层的 API 调用理解模型交互的基本逻辑再上框架。理由很简单框架抽象度高出了问题你很难定位是哪一层引入的手写一遍后你再看框架文档大部分概念都能对上号实际工作中很多场景根本不需要框架直接调 API 反而更灵活。先会“用”再会“省”学习路径更稳。6. AI 工程实践中的高频问题与排查思路AI 应用开发和传统后端开发有一个明显区别错误可能来自模型本身也可能是你的代码问题。下面整理几个高频问题。问题现象常见原因解决思路模型返回内容不稳定同一问题答案不同温度参数过高Prompt 约束不足降低 temperature在 System Prompt 中明确输出格式调用报context_length_exceeded输入 Token 超过模型上下文窗口压缩历史消息截断过长的文档用摘要替代全文Function Calling 返回 JSON 解析失败模型输出的参数内容不合法或者模型不支持该工具确认模型版本是否支持工具调用加 try-except 兜底中文回答啰嗦、不准确Prompt 里没有约束语言和风格在 System Prompt 明确“用中文回答控制在 100 字以内”请求超时生成 Token 太多或网络延迟高设置max_tokens上限开启流式输出增加超时时间成本增长过快每次请求携带大量历史消息定期清理历史设置消息条数上限对长文本做摘要6.1 处理模型输出的不确定性大模型不是纯函数同一输入可能返回不同输出。这是概率模型的固有特点不是 Bug。为了减少不确定性可以采取几种手段把temperature调低比如 0.1 到 0.3让输出更稳定在 Prompt 中给出期望的输出模板关键业务在输出后加一层规则校验比如用 Pydantic 做结构校验。6.2 上下文爆炸问题在 Agent 多轮对话中历史消息会不断累积很快超出窗口限制。常见的处理策略只保留最近 N 轮对话把历史对话做摘要只保留摘要关键信息抽到结构化字段中管理。下面是一个简化的历史消息裁剪策略def trim_messages(messages: list, max_messages: int 10): if len(messages) max_messages: return messages system_msg messages[0] recent messages[-(max_messages - 1):] return [system_msg] recent这个策略简单但很实用始终保留 System Prompt同时只传最近的对话。7. AI 项目落地的工程最佳实践7.1 模型选型与成本控制不要一上来就选最强模型。强模型通常意味着高成本和慢响应。推荐的做法是简单任务分类、抽取、格式化用轻量模型复杂推理代码生成、多步分析用强模型在 Prompt 中设计分支逻辑根据任务难度动态路由。成本控制方面要关注三个指标输入 Token 数Prompt 越长成本越高输出 Token 数限制max_tokens避免模型长篇大论缓存命中率部分平台支持 Prompt 缓存重复内容能省成本。7.2 提示词工程与版本管理提示词是 AI 应用的核心资产应该像代码一样管理。建议把 Prompt 模板放在与代码分离的配置文件里不要硬编码在代码中对提示词做版本管理方便回滚建立测试集每次修改 Prompt 后跑一遍回归。以下是一个简单的 YAML Prompt 模板# prompts/weather_agent.yaml system_prompt: | 你是一个天气助手。 你的任务是根据用户输入和查询结果给出简洁回答。 规则 1. 必须基于工具返回的数据回答。 2. 如果不确定请如实说明。 3. 回答使用中文不超过 50 字。# 加载 YAML 模板的示例 import yaml with open(prompts/weather_agent.yaml, encodingutf-8) as f: config yaml.safe_load(f) system_prompt config[system_prompt]7.3 安全与合规必须守住的底线这里要特别强调几条 AI 工程的安全原则不要在生产环境用真实用户数据随意调用外部大模型 API。如果涉及敏感信息先做脱敏处理。对模型输出做内容安全过滤。模型可能生成不合规内容生产环境必须有审核兜底机制。密钥绝不能硬编码在代码中。使用环境变量或配置中心管理 API Key。工具调用必须做权限校验。Agent 能调用的 API应该是白名单里的最小权限集合。所有涉及用户信息的 AI 功能要遵循最小化原则只传完成任务必要的数据。# 从环境变量读取 API Key而不是硬编码 import os api_key os.getenv(AI_API_KEY) if not api_key: raise RuntimeError(AI_API_KEY 未设置请在环境变量中配置)7.4 可观测性与效果评估传统开发用日志、链路追踪排查问题AI 应用还要加一层评估能力。推荐至少做这几件事记录每次请求的 Prompt、返回结果、耗时、Token 用量对关键业务提前准备测试用例集定期评估输出质量建立人工抽检机制因为自动评估很难完全替代人。# 一个简单的最小化日志记录思路 import time import json def log_ai_request(model, prompt, response, usage): entry { timestamp: time.time(), model: model, prompt_length: len(prompt), response_length: len(response), prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens, } with open(ai_requests.log, a, encodingutf-8) as f: f.write(json.dumps(entry, ensure_asciiFalse) \n)7.5 工程上的降级与兜底AI 服务不是永远稳定的网络抖动、限流、模型接口异常都可能发生。生产环境必须设计降级策略调用超时或失败时重试 1 到 2 次重试仍失败返回预设的兜底话术对依赖 AI 的核心链路考虑引入开关紧急情况下可以快速切换为人工处理模式。# 带重试和兜底的调用示例 def call_llm_with_fallback(prompt: str, max_retry: int 2): for attempt in range(max_retry 1): try: return client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], ).choices[0].message.content except Exception as e: print(f第 {attempt 1} 次调用失败{e}) if attempt max_retry: return 抱歉当前服务暂时不可用请稍后再试。8. 给开发者的 AI 学习路线建议如果你的目标是在 AI 时代保持竞争力下面这条学习路线可以作为参考。第一阶段会用1 到 2 周学会使用主流 AI 对话产品辅助写代码、写文档学会使用代码 IDE 的 AI 插件理解 Prompt 的基本技巧。第二阶段会接2 到 4 周掌握调用大模型 API 的方法理解 Token、上下文窗口、System Prompt会写一个带工具调用的最小 Agent像本文第 4 节那样。第三阶段会做4 到 8 周掌握 RAG 的基本链路文档加载 → 切分 → 向量化 → 检索 → 生成学习一个框架Python 侧可选 LangChain / LlamaIndexJava 侧选 Spring AI把一个自己熟悉的业务场景用 AI 重做一遍。第四阶段会调持续迭代建立 Prompt 回归测试集优化成本与响应速度深入理解微调Fine-tuning与模型评测。整个过程中最重要的是保持“做出来”的节奏。每学一个概念都争取写出一个可运行的最小示例。9. 写在最后回到开头的题目为什么焦虑比愤怒更有用因为只有焦虑才会让你真的去下载那个 SDK、去申请 API Key、去读官方文档、去写第一个 Agent。愤怒不会带来这些行动它只会让你和新技术之间隔着一堵墙而这堵墙是你自己砌的。AI 时代真正值得担心的不是 AI 太强而是你习惯了用情绪代替行动。今天的你不必一下成为 AI 专家但要确保每周都能往这个方向迈一步。哪怕只是把本文的 Agent 示例跑通你都已经和昨天的自己不一样了。下一步你可以尝试把这个天气助手的示例改成你熟悉的业务场景比如查数据库、查订单状态、调内部接口。当你体会到让模型替你做事的快感时焦虑自然就被掌控感取代了。