企业官网建设流程全解析

最近这段时间，和不少后端、算法甚至前端同学聊天，大家最焦虑的一个话题不是某个框架怎么升级，而是同一句：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 工程化学习路径

接下来这篇文章，就会围绕下面的路线展开：

1. 理解大模型 API 与传统软件开发到底有什么区别。
2. 掌握提示词工程，建立对模型输出的控制感。
3. 学会 RAG，让模型使用你自己的私有数据。
4. 学会 Agent 开发，让模型有能力调用工具和业务流程。
5. 做好部署、监控、评估和安全管理，真正把它跑在生产环境。

这样一条路线，不要求你从零训练模型，也不需要数学博士背景，而是建立在工程能力之上。对大多数业务开发来说，这是性价比最高的路径。

2. AI工程化需要掌握的四个核心概念

2.1 大语言模型与 API 调用

大语言模型（Large Language Model）本质上是一个“根据前文预测下一个词”的神经网络。但因为训练数据足够多、参数足够大，它在对话、总结、翻译、写代码等任务上表现出了非常强的通用能力。

对工程开发者来说，我们不需要关心模型的内部权重，只需要关心它的使用方式。目前主流的调用方式是 Chat Completions API：

import 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和content：

• system：定义助手的人设和行为规则。
• user：用户输入。
• assistant：模型的回答，多轮对话时用于传递上下文。

大模型是一个“无状态”的 API，每次调用都是独立的。你需要把历史对话放在messages里传给模型，它才能理解完整的上下文。这是与大模型应用开发和传统 API 开发的重要区别。

2.2 提示词工程

提示词工程是控制模型输出的关键技术。同样的模型，提示词写得好不好，输出质量可能天差地别。

一个完整的提示词通常包含几个要素：

• 角色设定：告诉模型它应该以什么身份工作。
• 任务描述：明确要求模型做什么。
• 输入数据：给模型提供必要的材料。
• 输出格式：说明模型应以什么格式返回结果。
• 约束条件：告诉模型不能做什么。

来看一个对比示例。

模糊的提示词：

帮我总结这段文本。

清晰的提示词：

你是一名专业的客服工单分析员。请阅读下面的工单内容，提取用户反馈的问题类别、紧急程度和解决建议。 要求： 1. 问题类别只能从“网络故障、账号问题、支付问题、功能建议”中选择。 2. 紧急程度分为高、中、低三档。 3. 输出为 JSON 格式，字段为 category、urgency、suggestion。 工单内容： {工单}

可以看到，同样是一个“总结”任务，明确了角色、输出格式和约束条件之后，模型输出就会变得稳定、可解析。

提示词工程本身是一门需要持续积累的技能。写得多了，你会慢慢建立一种直觉：模型在什么时候容易跑偏，需要用什么样的语气和格式去约束它。

2.3 RAG：让模型使用你的私有数据

大模型的训练数据是有截止日期的，它不知道你公司内部的业务规范、客户信息、历史工单数据。要让模型回答这些私有领域的问题，主要有两种方案：

• 微调（Fine-tuning）：用业务数据继续训练模型，成本高、周期长。
• RAG（Retrieval-Augmented Generation，检索增强生成）：先从知识库中检索出相关资料，再把资料作为上下文交给模型生成答案。

RAG 是当前企业落地 AI 应用最主流的方案，原因在于：

1. 不需要重新训练模型，成本低。
2. 数据更新即时，只要更新知识库即可。
3. 可以附上引用来源，方便审计和追溯。
4. 降低模型编造答案的概率，因为答案基于检索到的资料。

RAG 的基本流程是：

1. 将知识文档切分为小块。
2. 将小块转化为向量（或建立关键词索引）。
3. 用户提问时，将问题转化为向量，与文档向量做相似度检索。
4. 将检索到的文档片段和用户问题一起拼入 Prompt。
5. 模型基于提供的资料生成答案。

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\activate

3.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.py：

import 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, encoding="utf-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(key=lambda x: x[0], reverse=True) 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.py：

import 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": f"Bearer {self.api_key}", "Content-Type": "application/json" }, json={ "model": self.model, "messages": messages, "temperature": 0.2, }, timeout=60, ) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"]

关于这段代码，有几个关键点要说明：

首先，temperature设为 0.2，意味着模型回答会更保守、更稳定。在知识问答场景下，我们通常不希望模型自由发挥，而是要它严格依据资料作答。

其次，system_prompt中我明确写了“如果资料中没有相关信息，请明确回答未找到”。这是控制幻觉最有效的手段之一。模型推理能力再强，也需要明确的边界指令。

4.5 编写 FastAPI 服务入口

app/main.py：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel from retrieval import RetrievalEngine from llm_client import ChatClient app = FastAPI(title="RAG 文档问答助手") 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_model=AskResponse) async def ask(request: AskRequest): if not request.question.strip(): raise HTTPException(status_code=400, detail="问题不能为空") references = retrieval.search(request.question, top_k=request.top_k) if not references: return AskResponse( question=request.question, answer="资料库中暂时没有找到相关内容。", references=[], ) answer = chat.answer(request.question, references) return AskResponse( question=request.question, answer=answer, references=references, ) @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_URL=https://你的模型服务地址/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 闭环可以拆成四步：

1. 接收用户请求。
2. 模型判断需要调用哪个工具，输出结构化的函数调用请求。
3. 应用执行对应函数，拿到结果。
4. 把函数结果返回给模型，模型生成面向用户的最终回答。

这四步循环执行，直到模型认为不需要再调用工具，直接给出最终答案。

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(messages=messages, tools=tools) if resp.is_tool_call: # 第二步：执行本地函数 result = query_order_status(order_id=resp.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(messages=messages) return final.content return resp.content

用大白话解释一下：模型返回的不是普通文本，而是一个“我要调query_order_status函数，参数是订单号”的指令。你的代码识别到这个指令后，执行真实的查询函数，把结果喂回模型，模型再组织语言回答用户。

5.3 与业务系统集成的常见模式

在真实项目中，Agent 通常不是孤立存在的，它会和企业 OA、ERP、客户管理系统打通。比较常见的集成模式有两种。

一种是插件模式：把现有系统提供的 API 封装成 Agent 的工具，例如请假查询、库存查询、工单创建。Agent 负责理解用户意图，自动匹配工具并执行。

另一种是人工审批模式：当 Agent 判定某个操作具有较高风险时，例如提交报销、删除数据、发送对外邮件，它不直接执行，而是生成一个待审批的工单，推送给人类管理员确认后再执行。

这两种模式的共同点是：Agent 只负责理解和调用，最终的业务状态变化必须走原有系统。这也是生产环境中最稳妥的落地方式。

6. 工程落地中的常见问题与排查思路

AI 应用开发与传统软件开发有一个很大的不同：传统代码的输入输出是可预测的，而大模型的输出带随机性，运行环境也更复杂。这里我整理了一些高频问题，方便你遇到问题时快速定位。

下面挑几个重点问题展开说。

上下文长度超限是 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 时代找到自己的技术锚点，动手写起来，比焦虑更有用。