最近这段时间和不少后端、算法甚至前端同学聊天大家最焦虑的一个话题不是某个框架怎么升级而是同一句AI 发展这么快我们这些岗位到底会不会被替代。我理解这种焦虑。过去一年大模型从“聊天玩具”变成了能写代码、能查资料、能操作软件的真实生产力工具而且迭代速度越来越快。很多平时不关注技术的朋友也开始讨论“AI 会不会抢走工作”这是历史上每次技术变革都会出现的讨论背后其实是同一个疑问当自动化可以让少数人完成过去需要很多人才能做完的事情时剩下的从业者该往哪个方向走但作为一个常年写代码的技术博主我更希望大家换一个角度看待这件事。与其把“AI替代劳动力”当成一个宏观叙事去担心不如把它拆成一个具体的工程问题你能不能使用大模型 API 搭建出解决现实问题的应用能不能把模型接入业务系统能不能评估、调优、控制它的输出质量如果你能AI 对你来说就是杠杆如果你不能AI 对别人来说就是替代你的工具。这个差别完全可以通过系统学习来弥补。这篇文章我不想喊口号只想围绕“AI 工程化”这条路给出知识框架、环境搭建、完整实战代码、常见排错和一条可持续的学习路线。内容按照真实项目落地的思路来写适合有一定编程经验、想从传统开发转向 AI 应用开发的读者也适合正在规划技术学习路线的在校同学。1. AI浪潮下的技术从业者应该如何定位1.1 为什么“AI替代”会成为全员议题过去几年AI 能力的渗透路径大概是这样的早期是算法工程师用 TensorFlow、PyTorch 训练模型普通开发接触不多。后来是 AI 能力通过 API 形式开放开发者调一个接口就能实现图像识别、语音转写、文本生成。再后来是 ChatGPT 这类产品让非技术人员也能“对话式使用”AI。现在是大模型可以调用工具、操作软件、自动完成多步任务也就是 Agent 形态。关键在于最后一步。当模型不只是回答问题而是能自主规划并执行任务时它的影响范围就从“写文案”扩展到了“执行工作流”。这在技术上的体现就是 Function Calling、Agent 编排和自动化工具链的成熟。从工程视角看这其实是一个确定性很强的事情过去需要人工判断和操作的重复流程正在逐步被大模型 代码替代。这也是为什么很多岗位感觉到压力的原因——不是模型突然有了意识而是它终于可以接入真实业务系统了。1.2 从“替代焦虑”到“拥抱工具”我在文章开头说过焦虑是可以转化为技术问题的。如果你是一个后端工程师你完全可以学习如何把大模型 API 封装成服务如何设计上下文管理如何做 RAG 检索增强如何把模型输出接入现有业务系统。这些能力不会让你失业反而会让你变成团队里“能把 AI 落地”的人。如果你是一个前端工程师你可以学习如何把模型输出变成交互式应用如何做流式响应如何设计 AI 产品的体验。如果你是一个测试工程师你可以学习如何用大模型生成测试用例、分析日志、自动回归。技术浪潮从来不是平均地洗牌而是重新分配。能驾驭新工具的人效率提升后会去完成更高价值的任务不能驾驭新工具的人才会被困在重复劳动里。这句话虽然朴素但它是这轮技术变革中最真实的底层逻辑。1.3 一条可落地的 AI 工程化学习路径接下来这篇文章就会围绕下面的路线展开理解大模型 API 与传统软件开发到底有什么区别。掌握提示词工程建立对模型输出的控制感。学会 RAG让模型使用你自己的私有数据。学会 Agent 开发让模型有能力调用工具和业务流程。做好部署、监控、评估和安全管理真正把它跑在生产环境。这样一条路线不要求你从零训练模型也不需要数学博士背景而是建立在工程能力之上。对大多数业务开发来说这是性价比最高的路径。2. AI工程化需要掌握的四个核心概念2.1 大语言模型与 API 调用大语言模型Large Language Model本质上是一个“根据前文预测下一个词”的神经网络。但因为训练数据足够多、参数足够大它在对话、总结、翻译、写代码等任务上表现出了非常强的通用能力。对工程开发者来说我们不需要关心模型的内部权重只需要关心它的使用方式。目前主流的调用方式是 Chat Completions APIimport requests resp requests.post( https://api.openai.com/v1/chat/completions, headers{ Authorization: Bearer YOUR_API_KEY, Content-Type: application/json }, json{ model: gpt-4o-mini, messages: [ {role: system, content: 你是一个乐于助人的助手。}, {role: user, content: 请用一句话介绍大语言模型。} ], temperature: 0.7 } ) print(resp.json()[choices][0][message][content])很多国内模型服务也提供了兼容 OpenAI 格式的接口只需要修改base_url、api_key和model三个参数即可这大大降低了接入成本。messages是核心参数它由一组消息组成每个消息包含role和contentsystem定义助手的人设和行为规则。user用户输入。assistant模型的回答多轮对话时用于传递上下文。大模型是一个“无状态”的 API每次调用都是独立的。你需要把历史对话放在messages里传给模型它才能理解完整的上下文。这是与大模型应用开发和传统 API 开发的重要区别。2.2 提示词工程提示词工程是控制模型输出的关键技术。同样的模型提示词写得好不好输出质量可能天差地别。一个完整的提示词通常包含几个要素角色设定告诉模型它应该以什么身份工作。任务描述明确要求模型做什么。输入数据给模型提供必要的材料。输出格式说明模型应以什么格式返回结果。约束条件告诉模型不能做什么。来看一个对比示例。模糊的提示词帮我总结这段文本。清晰的提示词你是一名专业的客服工单分析员。请阅读下面的工单内容提取用户反馈的问题类别、紧急程度和解决建议。 要求 1. 问题类别只能从“网络故障、账号问题、支付问题、功能建议”中选择。 2. 紧急程度分为高、中、低三档。 3. 输出为 JSON 格式字段为 category、urgency、suggestion。 工单内容 {工单}可以看到同样是一个“总结”任务明确了角色、输出格式和约束条件之后模型输出就会变得稳定、可解析。提示词工程本身是一门需要持续积累的技能。写得多了你会慢慢建立一种直觉模型在什么时候容易跑偏需要用什么样的语气和格式去约束它。2.3 RAG让模型使用你的私有数据大模型的训练数据是有截止日期的它不知道你公司内部的业务规范、客户信息、历史工单数据。要让模型回答这些私有领域的问题主要有两种方案微调Fine-tuning用业务数据继续训练模型成本高、周期长。RAGRetrieval-Augmented Generation检索增强生成先从知识库中检索出相关资料再把资料作为上下文交给模型生成答案。RAG 是当前企业落地 AI 应用最主流的方案原因在于不需要重新训练模型成本低。数据更新即时只要更新知识库即可。可以附上引用来源方便审计和追溯。降低模型编造答案的概率因为答案基于检索到的资料。RAG 的基本流程是将知识文档切分为小块。将小块转化为向量或建立关键词索引。用户提问时将问题转化为向量与文档向量做相似度检索。将检索到的文档片段和用户问题一起拼入 Prompt。模型基于提供的资料生成答案。2.4 Agent从问答走向自动化执行如果说 RAG 解决的是“让模型知道更多”Agent 解决的是“让模型做更多”。在大模型能力之上Agent 可以自主规划任务、调用工具、分析结果并修正策略。比如一个客服 Agent可以先查询订单状态再判断是否满足退款条件。一个数据分析 Agent可以生成 SQL、查询数据库、分析结果并输出报告。一个运维 Agent可以读取日志、定位异常、给出修复方案。Agent 的技术核心是 Function Calling函数调用。模型在生成回复时不只是输出文本还可以输出一个结构化指令指明需要调用哪个函数、参数是什么。应用程序执行该函数后把结果返回给模型模型再继续生成最终回复。这一节先建立概念后面我会用一个完整案例演示 RAG 和 Agent 的实现。3. 环境准备与常用工具链3.1 基础运行环境本文的实战案例使用 Python 编写建议使用 Python 3.9 或以上版本。项目依赖不多核心包括fastapi uvicorn requests安装命令pip install fastapi uvicorn requests版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。建议使用虚拟环境隔离项目依赖python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate3.2 开发工具与 AI 编程助手在写 AI 应用时强烈建议直接使用支持 AI 编程助手的 IDE。目前 JetBrains 全家桶PyCharm、IntelliJ IDEA和 Visual Studio Code 都有丰富的 AI 插件生态。比较常见的用法是在 IDE 中安装 AI 插件通过对话方式生成代码片段。让 AI 解释报错信息、补全测试代码。用 AI 辅助重构把重复代码提取为函数。这里要提一个很重要的工程习惯AI 生成的代码一定要逐行理解后再合入。大模型擅长生成“看起来正确”的代码但其中可能存在边界条件缺失、安全问题或者依赖版本不兼容的情况。把 AI 当成结对编程的伙伴而不是可以背锅的替罪羊这是新阶段开发者的基本素养。3.3 在线模型服务与本地模型选择在真实项目中选型通常分为两条路线在线模型服务比如 OpenAI、DeepSeek、通义千问等。优点是开箱即用、效果稳定、不需要自建 GPU 环境缺点是数据会经过第三方服务需要评估数据合规要求。本地私有化部署比如通过 Ollama、vLLM 等工具部署开源模型。优点是数据不出内网适合对数据隐私要求高的场景缺点是需要硬件资源效果也不一定比头部在线模型好。开发阶段建议先用在线模型 API 快速验证业务逻辑。等产品逻辑跑通了再根据成本、隐私、性能要求决定是否需要切换到私有化部署。本文案例使用 OpenAI 兼容的 Chat Completions API你可以根据自己的模型服务调整base_url、api_key和model。4. 实战案例从零搭建 RAG 文档问答助手这一节我们实现一个完整的 RAG 应用给定一批内部文档用户问问题时系统先检索相关片段再调用大模型生成带出处参考的回答。为了控制依赖复杂度同时让代码清晰可读我们使用 TF-IDF 余弦相似度来实现一个轻量级的“检索模块”。实际生产环境中这一步通常会用向量数据库加嵌入模型替换但整体架构完全一致。4.1 项目结构设计先创建项目目录rag-demo/ ├── data/ │ └── docs/ │ ├── employee_handbook.txt │ └── reimbursement_policy.txt ├── app/ │ ├── main.py # FastAPI 服务入口 │ ├── retrieval.py # 检索模块 │ └── llm_client.py # 大模型调用模块 └── requirements.txt简单说明一下模块职责retrieval.py负责加载文档、建立索引、执行检索。llm_client.py负责与大模型 API 交互构造 Prompt解析回复。main.py负责 HTTP 接口层把前后端串联起来。4.2 准备测试文档在data/docs下创建两个测试文档。employee_handbook.txt公司员工的试用期为三个月表现优秀者可申请提前转正。 员工每周五下午需要提交本周工作总结。 年假标准为入职满一年后每年 10 天满三年后每年 15 天。 加班需要提前在 OA 系统中提交申请经部门主管审批后才算有效加班。reimbursement_policy.txt日常办公用品的报销额度为每人每月 500 元。 差旅报销需要提供发票和行程单机票和酒店需要通过公司指定平台预订。 报销审批流程发起申请 - 部门主管审批 - 财务审核 - 打款。 发票抬头必须填写公司全称否则无法通过财务审核。这些文本就是“知识库”。后面我们会看到模型如果没有检索到相关内容就无法回答这些问题一旦检索到对应片段就能给出非常准确的回答。4.3 编写检索模块app/retrieval.pyimport os import math import re from collections import Counter class RetrievalEngine: def __init__(self, doc_dir: str): self.doc_dir doc_dir self.docs [] self.doc_terms [] self.doc_freq Counter() self.doc_norm [] self._load_documents() self._build_index() def _read_files(self): files [] for f in os.listdir(self.doc_dir): if f.endswith(.txt) or f.endswith(.md): files.append(os.path.join(self.doc_dir, f)) return files def _tokenize(self, text: str): # 演示用的中文切词按相邻字符二元组切分。 # 生产环境建议换用 jieba 或嵌入模型。 text re.sub(r\s, , text.lower()) tokens set() for i in range(len(text) - 1): tokens.add(text[i:i 2]) return tokens def _load_documents(self): for path in self._read_files(): with open(path, encodingutf-8) as fp: content fp.read() terms self._tokenize(content) self.docs.append({path: path, text: content}) self.doc_terms.append(terms) for term in terms: self.doc_freq[term] 1 def _build_index(self): for terms in self.doc_terms: tf Counter(terms) norm math.sqrt(sum((1 math.log(count)) ** 2 for count in tf.values())) self.doc_norm.append(norm) def search(self, query: str, top_k: int 3): query_terms self._tokenize(query) scores [] for idx, terms in enumerate(self.doc_terms): tf Counter(terms) score 0.0 for q in query_terms: if q not in tf: continue tf_val 1 math.log(tf[q]) idf_val math.log((1 len(self.docs)) / (1 self.doc_freq[q])) 1 score tf_val * idf_val if self.doc_norm[idx] 0: score / self.doc_norm[idx] scores.append((score, idx)) scores.sort(keylambda x: x[0], reverseTrue) results [] for score, idx in scores[:top_k]: if score 0: break doc self.docs[idx] preview doc[text][:200].replace(\n, ) results.append(f来源: {os.path.basename(doc[path])}\n{preview}) return results这个模块里检索部分我用了 TF-IDF 加权和余弦相似度而不是简单的字符串匹配原因有几个TF-IDF 可以给“出现频率低但信息量大的词”更高权重。余弦相似度对文档长度不敏感更适合对比不等长文本。纯 Python 实现没有额外依赖读者可以完整理解检索原理。需要强调的是这个简单索引只适合教学演示。真实项目要用嵌入模型将文本转为向量再用向量数据库比如 Milvus 或开源的 Chroma 做相似度检索效果会好得多。但整体流程思想一致先召回候选片段再交给大模型生成答案。4.4 编写大模型调用模块app/llm_client.pyimport os import requests class ChatClient: def __init__(self): self.api_key os.getenv(LLM_API_KEY, ) self.base_url os.getenv(LLM_BASE_URL, https://api.example.com/v1) self.model os.getenv(LLM_MODEL, your-model-name) def answer(self, question: str, documents: list) - str: context \n\n---\n\n.join(documents) system_prompt ( 你是一个企业内部文档问答助手。 请根据提供的资料回答用户问题。 如果资料中没有相关信息请明确回答“资料中未找到相关信息”不要编造内容。 回答时使用中文尽量简洁并保留资料中的重要细节。 ) messages [ {role: system, content: system_prompt}, {role: user, content: f资料\n{context}\n\n问题{question}} ] resp requests.post( f{self.base_url.rstrip(/)}/chat/completions, headers{ Authorization: fBearer {self.api_key}, Content-Type: application/json }, json{ model: self.model, messages: messages, temperature: 0.2, }, timeout60, ) resp.raise_for_status() data resp.json() return data[choices][0][message][content]关于这段代码有几个关键点要说明首先temperature设为 0.2意味着模型回答会更保守、更稳定。在知识问答场景下我们通常不希望模型自由发挥而是要它严格依据资料作答。其次system_prompt中我明确写了“如果资料中没有相关信息请明确回答未找到”。这是控制幻觉最有效的手段之一。模型推理能力再强也需要明确的边界指令。4.5 编写 FastAPI 服务入口app/main.pyfrom fastapi import FastAPI, HTTPException from pydantic import BaseModel from retrieval import RetrievalEngine from llm_client import ChatClient app FastAPI(titleRAG 文档问答助手) retrieval RetrievalEngine(data/docs) chat ChatClient() class AskRequest(BaseModel): question: str top_k: int 3 class AskResponse(BaseModel): question: str answer: str references: list app.post(/ask, response_modelAskResponse) async def ask(request: AskRequest): if not request.question.strip(): raise HTTPException(status_code400, detail问题不能为空) references retrieval.search(request.question, top_krequest.top_k) if not references: return AskResponse( questionrequest.question, answer资料库中暂时没有找到相关内容。, references[], ) answer chat.answer(request.question, references) return AskResponse( questionrequest.question, answeranswer, referencesreferences, ) app.get(/health) async def health(): return {status: ok}这里用 FastAPI 暴露了一个POST /ask接口。请求体是 JSON包含question和可选的top_k。响应中除了模型生成的回答还有检索到的参考资料方便前端展示来源也方便人工审计。4.6 启动服务并验证配置环境变量export LLM_API_KEY你的密钥 export LLM_BASE_URLhttps://你的模型服务地址/v1 export LLM_MODEL你的模型名称启动服务cd rag-demo uvicorn app.main:app --reload --host 0.0.0.0 --port 8000打开另一个终端用 curl 测试curl -X POST http://localhost:8000/ask \ -H Content-Type: application/json \ -d {question: 报销的审批流程是什么, top_k: 3}预期输出大致如下{ question: 报销的审批流程是什么, answer: 根据资料报销审批流程为发起申请 - 部门主管审批 - 财务审核 - 打款。, references: [ 来源: reimbursement_policy.txt\n... ] }如果我们问一个资料库中没有的问题比如“公司食堂开放时间是什么”模型应该会回答“资料中未找到相关信息”而不是编造一个答案。这就是 RAG 相对于直接裸用大模型最大的优势。5. 进阶基于 Function Calling 的 Agent 开发RAG 解决了“知识来源”的问题但实际业务往往还要求系统“动起来”。比如用户问“帮我查订单 OD20240001 的物流状态”系统需要先调用订单查询接口再基于返回值回答用户。这就是 Agent 要解决的问题。5.1 Agent 的基本结构一个最小可用的 Agent 闭环可以拆成四步接收用户请求。模型判断需要调用哪个工具输出结构化的函数调用请求。应用执行对应函数拿到结果。把函数结果返回给模型模型生成面向用户的最终回答。这四步循环执行直到模型认为不需要再调用工具直接给出最终答案。5.2 一个简单的工具调用示例下面用伪代码描述核心流程真实实现时需要根据你的模型服务适配工具描述格式。def query_order_status(order_id: str) - str: # 实际项目中应该查询订单数据库或调用订单服务 return f订单 {order_id} 当前状态为运输中预计明天送达。 def run_agent(user_input: str): messages [{role: user, content: user_input}] tools [ { type: function, function: { name: query_order_status, description: 查询订单物流状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单编号} }, required: [order_id] } } } ] # 第一轮调用模型传入用户问题和工具描述 resp call_model(messagesmessages, toolstools) if resp.is_tool_call: # 第二步执行本地函数 result query_order_status(order_idresp.tool_args[order_id]) # 第三步把函数结果追加到 messages再调一次模型 messages.extend([ {role: assistant, content: None, tool_calls: [resp.tool_call]}, {role: tool, tool_call_id: resp.tool_call_id, content: result} ]) final call_model(messagesmessages) return final.content return resp.content用大白话解释一下模型返回的不是普通文本而是一个“我要调query_order_status函数参数是订单号”的指令。你的代码识别到这个指令后执行真实的查询函数把结果喂回模型模型再组织语言回答用户。5.3 与业务系统集成的常见模式在真实项目中Agent 通常不是孤立存在的它会和企业 OA、ERP、客户管理系统打通。比较常见的集成模式有两种。一种是插件模式把现有系统提供的 API 封装成 Agent 的工具例如请假查询、库存查询、工单创建。Agent 负责理解用户意图自动匹配工具并执行。另一种是人工审批模式当 Agent 判定某个操作具有较高风险时例如提交报销、删除数据、发送对外邮件它不直接执行而是生成一个待审批的工单推送给人类管理员确认后再执行。这两种模式的共同点是Agent 只负责理解和调用最终的业务状态变化必须走原有系统。这也是生产环境中最稳妥的落地方式。6. 工程落地中的常见问题与排查思路AI 应用开发与传统软件开发有一个很大的不同传统代码的输入输出是可预测的而大模型的输出带随机性运行环境也更复杂。这里我整理了一些高频问题方便你遇到问题时快速定位。问题现象常见原因解决思路API 请求超时网络不稳定模型推理耗时长增加超时设置使用流式输出对耗时任务做异步化回答内容与资料不符系统提示词约束不够检索召回不准确强化提示词要求“仅根据资料回答”优化检索逻辑模型输出乱改事实Prompt 中未限制模型自由发挥明确告知“若资料无答案请如实说明”降低 temperature上下文超过模型限制拼接内容过多限制检索片段数量精简文档内容使用摘要压缩接口调用报鉴权错误API Key 配置错误或过期检查环境变量确认 base_url 路径是否为 /chat/completions中文切词效果差简单字符切分无法表达语义换用 jieba 分词或直接使用嵌入模型做语义检索下面挑几个重点问题展开说。上下文长度超限是 RAG 应用最常见的坑。原始文档可能几万字你不能全部塞给模型。我的建议是先做切块每块控制在 500 到 1000 字左右检索时只取 top 3 到 5 块。如果业务文档结构复杂可以先做章节识别再按章节切分。回答幻觉是另一个高频问题。减少幻觉有两个方向一个是在提示词层面严格控制另一个是在结果层面增加验证。比如让模型把答案中每个关键信息都标注出来源编号系统再判断这个来源是否真的存在。如果关键信息没有来源就拒绝输出。还有一个容易被忽略的问题是服务稳定性。外部模型服务可能出现限流生产环境一定要做重试和降级。比如调用失败时稍等几秒重试一次连续失败时返回“AI 服务暂时不可用请稍后再试”而不是直接报 500。数据安全方面涉及敏感业务数据时建议先做脱敏处理再送给模型处理。如果数据不能出内网就必须走私有化部署不能为了省事把核心数据送到外部 API。7. 从“被AI替代”到“驾驭AI”的工程建议7.1 把 AI 能力当成基础设施而不是神秘魔法很多团队在引入大模型时容易走两个极端一个极端是认为 AI 无所不能什么需求都往上面堆另一个极端是觉得模型不可控干脆只在边缘场景使用。我更推荐的思路是把大模型看作一个“能力不那么稳定的组件”。它的优势是语言理解、知识整合、代码生成弱点是事实性弱、计算不准、上下文有限。在做系统设计时按照它的强弱项来划分职责模型负责理解和生成传统代码负责确定性计算和状态管理。这样组合出来的系统既灵活又可靠。7.2 保持业务深度与技术广度为什么我们说 AI 不会直接“替代”一个优秀工程师因为大模型现在最擅长的是处理通用任务而一个优秀工程师对自己的业务领域有多年积累知道数据哪里容易出错知道业务流程的隐藏约束知道用户嘴上说的和实际要的是两回事。这些领域知识很难通过通用模型获得需要靠人来沉淀和建模。所以我的建议是不要因为 AI 火了就丢掉业务积累也不要因为业务忙就不学 AI。两者结合才是未来最有竞争力的状态。7.3 建立自己的 AI 工程评估体系前面我们写了代码但有一个环节很多人会漏掉怎么评估一个 AI 应用到底好不好传统软件有明确的输入输出可以用单元测试来验证。但大模型输出不固定需要有独立的评估方式。最基础的做法是准备一批测试问题和标准答案每次改动提示词或检索逻辑后跑一遍测试集人工打分。打分维度可以是正确性回答是否准确。完整性关键信息是否覆盖。忠实度回答是否基于资料有没有编造。格式合规是否按要求返回 JSON 或结构化内容。当问题数量变大后可以再考虑用“大模型评估大模型”的方式让一个模型当裁判给另一个模型的输出打分。但无论如何评估集和评估流程要尽早建立起来。7.4 推荐学习路径最后给出一份我整理的推荐学习路径按顺序推进即可第一步掌握 API 调用。找一个模型服务写通一个最简单的问答程序理解 messages 和参数含义。第二步练习提示词工程。拿 10 个真实业务问题反复调整提示词直到输出稳定。学习 JSON 输出 mode让模型结果可以被程序解析。第三步实现 RAG。把内部文档切块、检索、拼 Prompt搭建一个文档问答接口这就是本文的实战内容。第四步学习 Agent 开发。从 Function Calling 入手把现有系统接口封装成工具让模型自动调用。第五步研究落地工程。关注模型部署、缓存、异步、限流、数据脱敏、效果评估以及成本控制。这五步并不是每步都要做到专家级而是每步都能动手完成一个最小的可运行项目。完成这些之后你会发现 AI 对于你来说已经从“新闻里的热词”变成了“工具箱里的一个普通组件”。技术浪潮会一直变化今天的大模型也未必是终局。但“用工程方法把新技术转变成业务价值”的这套思维方式是长期有效的。希望这篇教程能帮你在 AI 时代找到自己的技术锚点动手写起来比焦虑更有用。