最近和一些做 AI 应用的朋友交流聊得最多的一句话就是 “Startups are chasing the next big thing in LLMs”。模型能力在快速迭代资本和创业者都在押注下一个爆发点但真到了技术落地环节很多团队的进展并没有想象中顺利。大家面对的是同一个问题模型选哪一个框架用哪一套先做 API 调用还是直接私有化部署知识库检索怎么做得准线上成本怎么控制得住。这篇文章不准备讨论某个具体模型发布而是从开发者视角把 LLM 应用开发这条链路完整拆开。你会看到 LLM 的核心能力边界、开发框架怎么选、环境怎么搭、一个知识库问答助手怎么从零写出来、部署时有哪些硬件和架构边界以及创业团队在技术选型时容易忽略的几个工程问题。无论你是刚接触大模型的新手还是已经在做应用落地的开发者这份内容都可以作为一份系统性的参考。1. LLM 应用开发从概念到工程的真实门槛1.1 LLM 到底解决了什么问题大语言模型本质上是“文本到文本”的生成模型。它根据输入的提示词逐 token 预测下一个最合适的 token从而生成回答、摘要、代码、翻译等内容。它擅长的是把海量文本中学到的语言模式和知识以自然语言的方式输出出来。在业务场景里这意味着很多原来需要人工完成的文本处理工作现在可以交给模型来做客服对话根据用户描述给出解答或引导。文档知识问答基于企业内部资料回答员工或客户问题。内容生产生成营销文案、产品描述、周报初稿。代码辅助代码补全、解释、单测生成、重构建议。数据抽取从非结构化文本中提取结构化字段。智能体自动化让模型调用工具、规划步骤、完成多轮任务。但这里有一个关键认知LLM 不是一个数据库也不是搜索引擎。它不会精确记住你给它的一切也不能保证生成内容一定真实。它是“基于概率的文本生成器”回答得好不好取决于模型能力、提示词设计、检索到的上下文以及你对输出的约束方式。1.2 当前 LLM 应用的主要形态目前创业团队做的 LLM 应用大概可以分成这几类第一类是对话增强型。在聊天窗口基础上加入行业知识和业务规则典型就是智能客服、销售助手、培训陪练。这类应用对检索质量要求高对回答的合规性也有很强约束。第二类是知识库问答型RAG。把企业文档、PDF、网页内容切分、向量化后存起来用户提问时先检索相关内容再交给模型生成回答。这是目前落地最多、见效最快的方向也是后面实战部分要重点演示的案例。第三类是工作流自动化型Agent。让模型根据目标自动拆解步骤、调用 API、读取数据库、操作工具最终完成一个完整的业务流程。比如自动生成周报、自动分类工单、自动完成竞品信息收集。这类应用对模型规划能力和工具调用稳定性要求很高。第四类是内容生成工具型。面向编辑、运营、设计等角色提供批量文案、图片描述、视频脚本、SEO 内容等生成能力。这类应用竞争激烈需要靠场景模板和垂直数据做出差异化。1.3 创业团队最容易忽略的三个环节很多团队在 Demo 阶段跑得很快接入一个 API、写一个 prompt、做一个聊天框看起来就“成了”。但进入生产环境之后真正消耗时间的反而是这些环节评测体系缺失。没有足够的测试问题和判断标准无法知道新版本模型是变好还是变坏也很难向客户证明回答质量。成本意识不足。每一个调用都在消耗 token长上下文、多次重试、频繁检索都会放大成本不做成本控制的项目很难盈利。安全和合规考虑滞后。用户输入会不会泄露到模型服务方模型会不会生成违规内容回答会不会包含未经授权的数据这些问题在接入前就应当有答案。这些环节不是“以后再说”的事它们决定了应用能不能从 demo 走向可交付的产品。2. 大语言模型的核心概念与能力边界2.1 什么是大语言模型大语言模型Large Language ModelLLM是一类基于 Transformer 架构、参数量达到数十亿甚至数千亿的神经网络模型。它通过在海量语料上进行预训练学习语言的统计规律和世界知识。用户输入一段文本模型会预测下一个最可能的 token并不断重复这个过程直到生成完整回答。从开发者视角看你不需要理解每一个注意力头但需要理解几个关键概念Token模型处理文本的最小单位。一个 token 可能是一个完整的英文单词也可能是一个汉字或一个子词。不同模型的 tokenizer 不一样。上下文窗口Context Window模型一次能看到的输入和输出总长度。窗口越大能处理的文档越长但显存开销和成本也会增加。Temperature控制输出随机性。值越高回答越发散值越低回答越稳定。知识问答场景通常调到 0.1~0.3。Max Tokens控制单次生成的最大长度。不是设置得越大越好因为生成的时间成本和费用都会上升。2.2 当前模型接入方式正在融合如果你观察最近一年的模型服务会发现一个明显的趋势不同厂商的 API 正在向 OpenAI 兼容格式靠拢。也就是说你只需要修改base_url、api_key和model名称很多代码可以直接复用。这对开发者是很大的利好意味着应用层不用被单一厂商绑定。本地部署的模型也可以通过 vLLM、Ollama、FastAPI 等工具暴露成兼容接口。这就形成了一种很灵活的接入方式早期验证用云端 API快速验证效果。需要私有化时把模型切到本地推理服务。应用层代码基本不变只需要修改配置文件。这也是为什么很多团队在建“模型网关”或者“模型路由层”目的就是让上层应用感知不到底层模型的变化。2.3 LLM 能做与不能做的事先把边界讲清楚可以减少很多无效尝试。** LLM 擅长的事情**文本总结、改写、扩写、翻译。从非结构化文本中抽取实体、关系、关键词。基于给定上下文做问答比如 RAG 场景。代码生成、解释、Debug 辅助。多轮对话中的意图理解和信息汇总。生成结构化输出比如 JSON、表格、Markdown。** LLM 不擅长的事情**精确计算四则运算容易出错复杂逻辑最好把计算交给代码。实时信息训练数据有截止时间需要接入搜索或数据源。事实核对模型会“自信地胡说”也就是幻觉。超长精确记忆即使上下文窗口够大模型也容易在长文本中遗漏细节。多跳推理步骤较多、逻辑链条较长的任务失误率会明显上升。理解了这些边界你在做技术方案时就会更理智能检索的不要让模型硬背能计算的不要让模型心算能代码处理的不要把逻辑交给 prompt。3. 技术栈与开发框架选型3.1 自建模型、调用 API 还是开源模型私有化创业团队第一个要决定的事情就是模型从哪里来。调用云端 API 是起步最快的方式。优点是不需要 GPU 成本不用关心模型部署可以快速验证产品方向。缺点是长期看 token 成本会随调用量增长同时数据会经过第三方服务部分行业客户不接受。开源模型私有化适合对数据安全要求高的场景比如金融、政务、医疗、企业内部知识管理。国内可以选择的开源模型也比较多比如 Qwen、DeepSeek、ChatGLM、Yi 等系列各有不同的参数规模和授权协议。私有化的代价是硬件投入、运维成本和持续的模型调优投入。自建模型训练是成本最高、周期最长的路径除非你的团队有很强的算法基因和充足的预算否则不建议创业初期选择这条路线。我的建议是产品验证阶段用 API跑通之后再根据客户需求决定是否私有化。模型层做抽象让切换成本降到最低。3.2 常见 LLM 开发框架盘点框架选择没有绝对标准按团队技术栈和业务类型来选择更合理。LangChain / LangGraphLangChain 是最早火起来的 LLM 应用编排框架封装了模型调用、提示词模板、记忆、工具调用、Agent 等模块。LangGraph 是它的升级方向用图的方式来编排复杂流程更适合需要清晰控制流程的 Agent 应用。适合有一定开发能力、需要深度定制逻辑的团队。LlamaIndex专注于数据索引和检索增强生成对 RAG 的支持非常细致适合做知识库、文档问答这类以检索为核心的应用。如果你主要在做“给模型加知识”这件事可以重点关注它。Dify / FastGPT这两个是开源的可视化 LLMOps 平台提供完整的 Web 界面可以拖拽配置工作流、知识库、模型接入、日志查看。适合产品团队快速搭建 MVP或者给非技术成员配置运营后台。Dify 更偏向通用 LLMOpsFastGPT 在知识库问答和在线客服场景使用很广。Semantic Kernel微软出品的 SDK支持 C#、Python、Java和微软生态结合紧密适合 .NET/Java 背景的企业级团队。Spring AIJava 生态的 LLM 应用框架如果你所在团队以 Java 为主想让 LLM 能力和 Spring Boot 项目结合可以关注这个方向。3.3 框架选型决策表业务场景推荐方向理由快速验证 Demo / 给客户演示Dify / FastGPT可视化配置搭建速度快知识库问答 / 文档检索LlamaIndex索引和检索能力深度更强复杂 Agent 编排LangGraph流程控制明确适合复杂逻辑企业级 Java 团队Spring AI与 Spring Boot 集成顺畅私有化模型推理vLLM 自建 API 服务推理吞吐高兼顾性能和成本内部工具链集成云厂商 SDK LangChain生态成熟资料多无论选哪个框架都要意识到框架是工具不是护城河。真正决定应用质量的是你的数据质量、流程设计、评测机制和工程化水平。4. 环境准备与模型接入4.1 开发环境本文的实战案例以 Python 为例建议使用 Python 3.10 及以上版本。你需要准备Python 3.10建议使用 venv 创建虚拟环境。一个可用的大模型 API或本地启动的兼容 OpenAI 格式的服务。一个向量化用的 Embedding 模型接口。代码编辑器和终端。创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate pip install openai1.30.0版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。4.2 通过 API 调用大模型无论你使用的是哪家模型服务只要接口兼容 OpenAI 格式代码结构都差不多。以 Python 为例import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1), ) resp client.chat.completions.create( modelyour-chat-model, messages[ {role: system, content: 你是一个知识库问答助手回答尽量简洁准确。}, {role: user, content: 什么是大语言模型的上下文窗口}, ], temperature0.2, ) print(resp.choices[0].message.content)关键点解释LLM_API_KEY和LLM_BASE_URL建议通过环境变量或配置中心管理不要硬编码在代码里。model名称要根据你申请到的服务填写不同服务商命名不一样。temperature0.2适合知识问答减少随机性。messages列表用于传多轮对话系统提示词可以约束回答风格。如果你使用本地部署的模型只需要把base_url指向本地服务的地址例如export LLM_BASE_URLhttp://localhost:8000/v1 export LLM_API_KEYnot-needed这种方式把应用和模型服务解耦底层模型随时可以替换。4.3 Embedding 模型与向量化RAG 应用里除了对话模型还需要一个 Embedding 模型用来把文本转换成向量。Embedding 模型的作用是让语义相近的文本在向量空间里距离更近。调用方式也很简单def get_embedding(text: str): resp client.embeddings.create( modelyour-embedding-model, inputtext, ) return resp.data[0].embedding需要注意Embedding 模型和对话模型通常是两个独立的模型需要分别开通或部署。不同 Embedding 模型的向量维度不一样常见的有 256 维、768 维、1024 维、1536 维等。你在存储向量时要注意维度的一致性。5. 完整实战手写一个知识库问答助手5.1 需求分析知识库问答是 LLM 应用里落地价值最明确的方向。它的核心流程是用户提出一个问题系统先从知识库中检索出最相关的几段内容再把这些内容拼进提示词让模型基于给定资料生成回答。为什么不能直接把整篇文档塞给模型文档可能超过上下文窗口长度。无关内容会干扰模型回答质量。每次把全部文档作为上下文成本会非常高。所以 RAG 的标准流程是先切分再向量化然后检索最后生成。5.2 系统设计完整流程如下用户问题 ↓ 文本向量化Embedding ↓ 向量相似度检索Top-K ↓ 拼接检索结果 问题 ↓ 大模型生成回答 ↓ 输出结果对应到工程实现需要完成这几个模块文档加载读取本地文本文件。文本切分把长文本切成固定大小的块块与块之间保留重叠。向量化调用 Embedding 接口为每个文本块生成向量。索引存储把向量和文本保存在内存中生产环境建议用向量数据库。检索计算用户问题的向量与所有文本块向量的余弦相似度取 Top-K。生成把检索到的文本块和用户问题组装成 Prompt调用对话模型。5.3 项目结构与依赖我们建一个简单项目目录结构如下rag_demo/ ├── requirements.txt ├── config.py ├── main.py └── docs/ └── sample.txtrequirements.txt内容openai1.30.0我们先在docs/sample.txt里放一段公司产品介绍或技术文档作为知识库数据来源。这里以一段示例文本为例你可以替换成自己的文档。5.4 核心代码实现先看config.py统一管理模型配置import os LLM_API_KEY os.getenv(LLM_API_KEY, ) LLM_BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) CHAT_MODEL os.getenv(CHAT_MODEL, your-chat-model) EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, your-embedding-model) CHUNK_SIZE 500 CHUNK_OVERLAP 50 TOP_K 3 TEMPERATURE 0.2然后写main.py完整代码如下import os from openai import OpenAI from config import ( LLM_API_KEY, LLM_BASE_URL, CHAT_MODEL, EMBEDDING_MODEL, CHUNK_SIZE, CHUNK_OVERLAP, TOP_K, TEMPERATURE, ) client OpenAI( api_keyLLM_API_KEY, base_urlLLM_BASE_URL, ) def get_embedding(text: str): 生成文本向量 resp client.embeddings.create( modelEMBEDDING_MODEL, inputtext, ) return resp.data[0].embedding def split_text(text: str, chunk_size: int CHUNK_SIZE, overlap: int CHUNK_OVERLAP): 按固定长度切分文本保留重叠区间 chunks [] start 0 while start len(text): end start chunk_size chunk text[start:end] chunks.append(chunk) if end len(text): break start end - overlap return chunks def cosine_similarity(vec_a, vec_b): 计算两个向量的余弦相似度 dot sum(x * y for x, y in zip(vec_a, vec_b)) norm_a sum(x * x for x in vec_a) ** 0.5 norm_b sum(x * x for x in vec_b) ** 0.5 if norm_a 0 or norm_b 0: return 0.0 return dot / (norm_a * norm_b) def build_index(doc_path: str): 加载文档、切分、向量化返回文本块列表和向量列表 with open(doc_path, encodingutf-8) as f: text f.read() chunks split_text(text) vectors [] for i, chunk in enumerate(chunks): print(f正在向量化第 {i 1}/{len(chunks)} 个文本块...) vectors.append(get_embedding(chunk)) return chunks, vectors def search(chunks, vectors, query: str, top_k: int TOP_K): 检索与问题最相关的文本块 query_vec get_embedding(query) scored [] for i, vec in enumerate(vectors): score cosine_similarity(query_vec, vec) scored.append((score, i)) scored.sort(reverseTrue) top_indices [idx for _, idx in scored[:top_k]] return [chunks[idx] for idx in top_indices] def generate_answer(query: str, context_chunks): 基于检索结果生成回答 context \n\n.join(context_chunks) prompt f你是一名知识库问答助手。请根据下面的资料回答问题。 如果资料中没有相关内容请明确回答“资料中未找到相关内容”不要编造。 资料 {context} 问题{query} 回答 resp client.chat.completions.create( modelCHAT_MODEL, messages[ {role: system, content: 你是一个严谨的知识库问答助手。}, {role: user, content: prompt}, ], temperatureTEMPERATURE, ) return resp.choices[0].message.content def main(): doc_path docs/sample.txt if not os.path.exists(doc_path): print(请先在 docs/ 目录下创建 sample.txt) return print(1. 开始构建索引...) chunks, vectors build_index(doc_path) print(f索引构建完成共 {len(chunks)} 个文本块。) while True: query input(\n请输入问题输入 exit 退出).strip() if query.lower() exit: break print(2. 正在检索相关内容...) context_chunks search(chunks, vectors, query) print(3. 正在生成回答...) answer generate_answer(query, context_chunks) print(\n 回答 ) print(answer) if __name__ __main__: main()5.5 运行验证与结果说明运行前先设置环境变量export LLM_API_KEY你的API密钥 export LLM_BASE_URL你的模型服务地址 export CHAT_MODEL你的对话模型名称 export EMBEDDING_MODEL你的向量模型名称然后运行python main.py预期流程是程序读取文档并切分文本块。逐个文本块调用 Embedding 接口生成向量。进入交互式问答环节。你输入问题后程序检索最相关的 3 个文本块。模型根据检索内容生成回答。这个实现只用了openai一个依赖适合理解 RAG 的原理。生产环境通常会把向量存到 Chroma、Milvus、Qdrant、pgvector 等向量数据库用批量 embedding 提升索引速度并用异步调用减少用户等待时间。6. 部署形态与硬件边界LLM 必须本机部署吗6.1 “ComfyUI 与 LLM 必须在同一台电脑上么”的类似问题经常有人在技术群里问ComfyUI 与 LLM 必须要在同一台电脑上么这个问题本质上是关于“资源部署边界”的疑问。ComfyUI 是 Stable Diffusion 生态里的节点式工作流工具依赖 GPU 做图像生成。LLM 应用可能是调用云端 API也可能是在本地起一个模型推理服务。两者并不是同一类软件也没有“必须同机”的强制关系。关键在于你采用哪种部署形态。如果 LLM 应用只是调用云端 API那么 ComfyUI 在本地跑LLM 在云端跑完全没问题。如果 LLM 也在本地部署那么 ComfyUI 和本地 LLM 服务可以在同一台机器也可以分别部署在不同机器通过网络互相访问。如果两个都是云端服务更不需要关心所谓的“同一台电脑”。判断依据是三个因素算力资源是否足够、网络是否连通、数据是否允许跨机传输。6.2 本地 GPU 部署的适用场景本地部署 LLM 主要为了解决数据安全或长期成本问题。但本地部署并不是免费的它需要硬件投入和运维成本。以常见的开源模型为例7B 参数模型量化后大约需要 6GB~10GB 显存配合一定内存可以跑起来。14B 参数模型通常需要 16GB 以上显存。70B 参数模型需要 40GB 以上显存或者多卡并行。具体数值会因量化方式、上下文长度、部署框架而不同以你的实际测试为准。这里想强调的是本地部署的底线不是“能装”而是“能用”。单用户测试和多人并发是两个完全不同的量级。如果团队早期没有足够的 GPU 资源用云端 API 是更稳妥的选择。等验证了产品需求、有了真实客户付费再考虑用开源模型做私有化交付这个顺序更符合创业团队的资源约束。6.3 远程 API 本地应用的混合架构在实际业务中更常见的架构是“混合模式”桌面端或 Web 端应用部署在企业内网。LLM 推理统一走内部模型网关网关背后可以是云端 API也可以是本地 GPU 集群。企业知识库、业务数据库和文档存储保持在内网只有脱敏后的文本片段会发送到模型服务。图像生成类工作流比如 ComfyUI根据资源情况部署在独立的 GPU 机器上与应用服务器分开。这种架构的好处是每个组件可以独立扩缩容互不影响。图像生成吃 GPU聊天问答吃 API 配额知识库检索吃 CPU 和内存它们不应该被绑在一台机器上。所以回答开头那个问题时很简单LLM 应用不需要和 ComfyUI 在同一台电脑上重要的是你的模型服务、应用服务和图像生成服务之间网络互通以及数据流转符合业务合规要求。7. 常见问题与排查思路7.1 高频问题排查表问题现象常见原因解决思路调用 API 报 401/403API Key 配置错误或权限不足检查环境变量是否正确确认账号有对应模型权限请求超时网络问题或模型响应时间长设置合理超时时间先缩短 context 再测试中文回答出现乱码或截断输出长度不够或 prompt 指令不明确增大 max_tokens明确要求“用中文回答”回答不基于资料产生幻觉检索结果相关性差优化切分方式、调整 Top-K、更换 Embedding 模型本地模型显存不足模型太大或并发太高使用量化版本、减小上下文长度、增加显存Embedding 维度不一致切换了不同模型向量库存储了旧向量统一 Embedding 模型重新向量化原有文本用户输入包含敏感信息没有做输入脱敏或权限控制在应用层增加内容过滤和脱敏处理生成结果不稳定temperature 太高降低 temperature 到 0.1~0.37.2 系统化排查思路遇到 LLM 应用问题建议按“输入 → 检索 → 生成 → 输出”四个环节来排查先确认问题是不是由用户输入引起的比如输入了不支持的语言、包含无关指令。再看检索结果检查召回的内容是否和问题相关。如果检索就不相关后续生成大概率也不对。然后看 Prompt 组装检查上下文是否被截断、格式是否正确、指令是否清晰。最后看模型输出判断是格式问题、长度问题还是内容正确但表达不符合预期。排查中最推荐的调试方法是“逐层打印日志”。尤其是 RAG 应用一定要把“最终发给模型的 Prompt”打印出来。很多时候问题不在模型而在检索结果和 Prompt 拼接质量。8. 创业团队切入 LLM 的方向与最佳实践8.1 值得关注的切入方向回到文章标题Startups are chasing the next big thing in LLMs。那么对创业团队来说哪些方向更值得尝试垂直行业的 RAG 应用。通用问答已经被大厂覆盖但某个细分行业的专业问答仍然存在信息差。比如医疗文献解读、法律条款检索、金融研报分析、设备维修手册查询。这类场景门槛在于领域数据的整理和知识体系的构建模型本身反而不是壁垒。Agent 驱动的业务流程自动化。企业里有大量重复性、跨系统的流程比如售后工单处理、合同初审、简历筛选、库存对账。Agent 可以调用现有系统 API把原来需要人工往返操作的事情自动化。这个方向的核心不是模型能力而是流程设计、工具接入和异常处理。LLM 评测与可观测性工具。随着更多企业使用 LLM评测需求会越来越强烈。怎么做回归测试、怎么做线上质量监控、怎么评估 RAG 检索质量这些都是可以产品化的方向。数据侧服务。很多企业有文档但文档混乱、格式多样、更新频繁没法直接做 RAG。提供数据清洗、结构化抽取、知识库构建服务也是一个务实的切入点。8.2 需要谨慎的方向有几个方向创业团队要特别谨慎重复建设“通用大模型”。基础模型训练对资金、算力和算法人才要求极高头部玩家的优势和规模效应非常明显。除非有特别独特的资源否则不建议正面竞争。只做“套壳”应用没有数据或渠道壁垒。单纯把 API 包一层 UI没有差异化数据、没有独占渠道、没有深的业务流程绑定很容易被大厂的功能更新覆盖。忽略商业化闭环。LLM 应用的 token 成本是刚性的如果用户付费意愿不高或者客单价无法覆盖调用成本商业模式很难成立。早期就投入私有化部署。在没有验证需求前购买 GPU 服务器、组建模型运维团队会严重消耗创业公司的现金储备。8.3 工程化建议第一Prompt 也要做版本管理。把 prompt 放到配置中心或代码仓库里每次修改记录变更原因。不要散落在代码各处更不要只在线上临时调试。第二RAG 的质量取决于数据治理。文本切分方式、数据更新机制、文档去重、权限控制这些都需要认真设计。建议每次数据更新后对检索效果做一次回归验证。第三输出结构化降低集成成本。要求模型输出 JSON 而不是纯文本可以让下游系统更容易解析。注意设置合理的response_format约束并对解析失败做兜底。第四统计成本和延迟。每个请求记录模型名、输入 token 数、输出 token 数、耗时和错误码。成本上涨通常是突发的比如某个用户上传了超长文档触发大批量 embedding没有监控很难及时发现。第五建立最小评测集。准备 20~50 个典型问题每次换模型、改 prompt、改检索参数时都拿同一批问题跑一遍人工或自动判断回答质量。这个最小评测集能帮你避免“改坏了自己都不知道”的情况。第六重视安全边界。用户输入发送到外部模型前要脱敏模型输出展示给用户前要过滤敏感内容系统 prompt 里要约束“只基于资料回答不编造”。企业内部使用时还要按最小权限原则控制知识库的访问范围。9. 下一步学习路线如果你刚刚开始接触 LLM 应用开发建议按下面的顺序往下深入先理解 RAG把本文的代码多跑几遍改改文本切分长度、调整 Top-K感受不同参数对回答的影响。再学习 Agent了解函数调用Function Calling、工具定义、多步规划做一个能查天气、能查数据库的小 Agent。接着深入评测学着建立评测集用客观指标评估回答质量而不是只靠肉眼判断。然后研究部署优化了解 vLLM、Ollama、量化推理搞清楚本地部署的性价比边界。最后关注 LLMOps学习模型网关、Prompt 管理、日志追踪、成本监控把应用做到生产可用。方向判断比模型选择更重要。模型会持续迭代框架会不断变化但一个团队对业务场景的理解、对数据质量的把控、对工程细节的认真程度才是真正能沉淀下来的竞争力。现在去写代码、建评测、记录每一次实验结论比讨论“哪个模型更强”更有价值。 LLM应用开发全指南：从概念到RAG实战
最近和一些做 AI 应用的朋友交流聊得最多的一句话就是 “Startups are chasing the next big thing in LLMs”。模型能力在快速迭代资本和创业者都在押注下一个爆发点但真到了技术落地环节很多团队的进展并没有想象中顺利。大家面对的是同一个问题模型选哪一个框架用哪一套先做 API 调用还是直接私有化部署知识库检索怎么做得准线上成本怎么控制得住。这篇文章不准备讨论某个具体模型发布而是从开发者视角把 LLM 应用开发这条链路完整拆开。你会看到 LLM 的核心能力边界、开发框架怎么选、环境怎么搭、一个知识库问答助手怎么从零写出来、部署时有哪些硬件和架构边界以及创业团队在技术选型时容易忽略的几个工程问题。无论你是刚接触大模型的新手还是已经在做应用落地的开发者这份内容都可以作为一份系统性的参考。1. LLM 应用开发从概念到工程的真实门槛1.1 LLM 到底解决了什么问题大语言模型本质上是“文本到文本”的生成模型。它根据输入的提示词逐 token 预测下一个最合适的 token从而生成回答、摘要、代码、翻译等内容。它擅长的是把海量文本中学到的语言模式和知识以自然语言的方式输出出来。在业务场景里这意味着很多原来需要人工完成的文本处理工作现在可以交给模型来做客服对话根据用户描述给出解答或引导。文档知识问答基于企业内部资料回答员工或客户问题。内容生产生成营销文案、产品描述、周报初稿。代码辅助代码补全、解释、单测生成、重构建议。数据抽取从非结构化文本中提取结构化字段。智能体自动化让模型调用工具、规划步骤、完成多轮任务。但这里有一个关键认知LLM 不是一个数据库也不是搜索引擎。它不会精确记住你给它的一切也不能保证生成内容一定真实。它是“基于概率的文本生成器”回答得好不好取决于模型能力、提示词设计、检索到的上下文以及你对输出的约束方式。1.2 当前 LLM 应用的主要形态目前创业团队做的 LLM 应用大概可以分成这几类第一类是对话增强型。在聊天窗口基础上加入行业知识和业务规则典型就是智能客服、销售助手、培训陪练。这类应用对检索质量要求高对回答的合规性也有很强约束。第二类是知识库问答型RAG。把企业文档、PDF、网页内容切分、向量化后存起来用户提问时先检索相关内容再交给模型生成回答。这是目前落地最多、见效最快的方向也是后面实战部分要重点演示的案例。第三类是工作流自动化型Agent。让模型根据目标自动拆解步骤、调用 API、读取数据库、操作工具最终完成一个完整的业务流程。比如自动生成周报、自动分类工单、自动完成竞品信息收集。这类应用对模型规划能力和工具调用稳定性要求很高。第四类是内容生成工具型。面向编辑、运营、设计等角色提供批量文案、图片描述、视频脚本、SEO 内容等生成能力。这类应用竞争激烈需要靠场景模板和垂直数据做出差异化。1.3 创业团队最容易忽略的三个环节很多团队在 Demo 阶段跑得很快接入一个 API、写一个 prompt、做一个聊天框看起来就“成了”。但进入生产环境之后真正消耗时间的反而是这些环节评测体系缺失。没有足够的测试问题和判断标准无法知道新版本模型是变好还是变坏也很难向客户证明回答质量。成本意识不足。每一个调用都在消耗 token长上下文、多次重试、频繁检索都会放大成本不做成本控制的项目很难盈利。安全和合规考虑滞后。用户输入会不会泄露到模型服务方模型会不会生成违规内容回答会不会包含未经授权的数据这些问题在接入前就应当有答案。这些环节不是“以后再说”的事它们决定了应用能不能从 demo 走向可交付的产品。2. 大语言模型的核心概念与能力边界2.1 什么是大语言模型大语言模型Large Language ModelLLM是一类基于 Transformer 架构、参数量达到数十亿甚至数千亿的神经网络模型。它通过在海量语料上进行预训练学习语言的统计规律和世界知识。用户输入一段文本模型会预测下一个最可能的 token并不断重复这个过程直到生成完整回答。从开发者视角看你不需要理解每一个注意力头但需要理解几个关键概念Token模型处理文本的最小单位。一个 token 可能是一个完整的英文单词也可能是一个汉字或一个子词。不同模型的 tokenizer 不一样。上下文窗口Context Window模型一次能看到的输入和输出总长度。窗口越大能处理的文档越长但显存开销和成本也会增加。Temperature控制输出随机性。值越高回答越发散值越低回答越稳定。知识问答场景通常调到 0.1~0.3。Max Tokens控制单次生成的最大长度。不是设置得越大越好因为生成的时间成本和费用都会上升。2.2 当前模型接入方式正在融合如果你观察最近一年的模型服务会发现一个明显的趋势不同厂商的 API 正在向 OpenAI 兼容格式靠拢。也就是说你只需要修改base_url、api_key和model名称很多代码可以直接复用。这对开发者是很大的利好意味着应用层不用被单一厂商绑定。本地部署的模型也可以通过 vLLM、Ollama、FastAPI 等工具暴露成兼容接口。这就形成了一种很灵活的接入方式早期验证用云端 API快速验证效果。需要私有化时把模型切到本地推理服务。应用层代码基本不变只需要修改配置文件。这也是为什么很多团队在建“模型网关”或者“模型路由层”目的就是让上层应用感知不到底层模型的变化。2.3 LLM 能做与不能做的事先把边界讲清楚可以减少很多无效尝试。** LLM 擅长的事情**文本总结、改写、扩写、翻译。从非结构化文本中抽取实体、关系、关键词。基于给定上下文做问答比如 RAG 场景。代码生成、解释、Debug 辅助。多轮对话中的意图理解和信息汇总。生成结构化输出比如 JSON、表格、Markdown。** LLM 不擅长的事情**精确计算四则运算容易出错复杂逻辑最好把计算交给代码。实时信息训练数据有截止时间需要接入搜索或数据源。事实核对模型会“自信地胡说”也就是幻觉。超长精确记忆即使上下文窗口够大模型也容易在长文本中遗漏细节。多跳推理步骤较多、逻辑链条较长的任务失误率会明显上升。理解了这些边界你在做技术方案时就会更理智能检索的不要让模型硬背能计算的不要让模型心算能代码处理的不要把逻辑交给 prompt。3. 技术栈与开发框架选型3.1 自建模型、调用 API 还是开源模型私有化创业团队第一个要决定的事情就是模型从哪里来。调用云端 API 是起步最快的方式。优点是不需要 GPU 成本不用关心模型部署可以快速验证产品方向。缺点是长期看 token 成本会随调用量增长同时数据会经过第三方服务部分行业客户不接受。开源模型私有化适合对数据安全要求高的场景比如金融、政务、医疗、企业内部知识管理。国内可以选择的开源模型也比较多比如 Qwen、DeepSeek、ChatGLM、Yi 等系列各有不同的参数规模和授权协议。私有化的代价是硬件投入、运维成本和持续的模型调优投入。自建模型训练是成本最高、周期最长的路径除非你的团队有很强的算法基因和充足的预算否则不建议创业初期选择这条路线。我的建议是产品验证阶段用 API跑通之后再根据客户需求决定是否私有化。模型层做抽象让切换成本降到最低。3.2 常见 LLM 开发框架盘点框架选择没有绝对标准按团队技术栈和业务类型来选择更合理。LangChain / LangGraphLangChain 是最早火起来的 LLM 应用编排框架封装了模型调用、提示词模板、记忆、工具调用、Agent 等模块。LangGraph 是它的升级方向用图的方式来编排复杂流程更适合需要清晰控制流程的 Agent 应用。适合有一定开发能力、需要深度定制逻辑的团队。LlamaIndex专注于数据索引和检索增强生成对 RAG 的支持非常细致适合做知识库、文档问答这类以检索为核心的应用。如果你主要在做“给模型加知识”这件事可以重点关注它。Dify / FastGPT这两个是开源的可视化 LLMOps 平台提供完整的 Web 界面可以拖拽配置工作流、知识库、模型接入、日志查看。适合产品团队快速搭建 MVP或者给非技术成员配置运营后台。Dify 更偏向通用 LLMOpsFastGPT 在知识库问答和在线客服场景使用很广。Semantic Kernel微软出品的 SDK支持 C#、Python、Java和微软生态结合紧密适合 .NET/Java 背景的企业级团队。Spring AIJava 生态的 LLM 应用框架如果你所在团队以 Java 为主想让 LLM 能力和 Spring Boot 项目结合可以关注这个方向。3.3 框架选型决策表业务场景推荐方向理由快速验证 Demo / 给客户演示Dify / FastGPT可视化配置搭建速度快知识库问答 / 文档检索LlamaIndex索引和检索能力深度更强复杂 Agent 编排LangGraph流程控制明确适合复杂逻辑企业级 Java 团队Spring AI与 Spring Boot 集成顺畅私有化模型推理vLLM 自建 API 服务推理吞吐高兼顾性能和成本内部工具链集成云厂商 SDK LangChain生态成熟资料多无论选哪个框架都要意识到框架是工具不是护城河。真正决定应用质量的是你的数据质量、流程设计、评测机制和工程化水平。4. 环境准备与模型接入4.1 开发环境本文的实战案例以 Python 为例建议使用 Python 3.10 及以上版本。你需要准备Python 3.10建议使用 venv 创建虚拟环境。一个可用的大模型 API或本地启动的兼容 OpenAI 格式的服务。一个向量化用的 Embedding 模型接口。代码编辑器和终端。创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate pip install openai1.30.0版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。4.2 通过 API 调用大模型无论你使用的是哪家模型服务只要接口兼容 OpenAI 格式代码结构都差不多。以 Python 为例import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1), ) resp client.chat.completions.create( modelyour-chat-model, messages[ {role: system, content: 你是一个知识库问答助手回答尽量简洁准确。}, {role: user, content: 什么是大语言模型的上下文窗口}, ], temperature0.2, ) print(resp.choices[0].message.content)关键点解释LLM_API_KEY和LLM_BASE_URL建议通过环境变量或配置中心管理不要硬编码在代码里。model名称要根据你申请到的服务填写不同服务商命名不一样。temperature0.2适合知识问答减少随机性。messages列表用于传多轮对话系统提示词可以约束回答风格。如果你使用本地部署的模型只需要把base_url指向本地服务的地址例如export LLM_BASE_URLhttp://localhost:8000/v1 export LLM_API_KEYnot-needed这种方式把应用和模型服务解耦底层模型随时可以替换。4.3 Embedding 模型与向量化RAG 应用里除了对话模型还需要一个 Embedding 模型用来把文本转换成向量。Embedding 模型的作用是让语义相近的文本在向量空间里距离更近。调用方式也很简单def get_embedding(text: str): resp client.embeddings.create( modelyour-embedding-model, inputtext, ) return resp.data[0].embedding需要注意Embedding 模型和对话模型通常是两个独立的模型需要分别开通或部署。不同 Embedding 模型的向量维度不一样常见的有 256 维、768 维、1024 维、1536 维等。你在存储向量时要注意维度的一致性。5. 完整实战手写一个知识库问答助手5.1 需求分析知识库问答是 LLM 应用里落地价值最明确的方向。它的核心流程是用户提出一个问题系统先从知识库中检索出最相关的几段内容再把这些内容拼进提示词让模型基于给定资料生成回答。为什么不能直接把整篇文档塞给模型文档可能超过上下文窗口长度。无关内容会干扰模型回答质量。每次把全部文档作为上下文成本会非常高。所以 RAG 的标准流程是先切分再向量化然后检索最后生成。5.2 系统设计完整流程如下用户问题 ↓ 文本向量化Embedding ↓ 向量相似度检索Top-K ↓ 拼接检索结果 问题 ↓ 大模型生成回答 ↓ 输出结果对应到工程实现需要完成这几个模块文档加载读取本地文本文件。文本切分把长文本切成固定大小的块块与块之间保留重叠。向量化调用 Embedding 接口为每个文本块生成向量。索引存储把向量和文本保存在内存中生产环境建议用向量数据库。检索计算用户问题的向量与所有文本块向量的余弦相似度取 Top-K。生成把检索到的文本块和用户问题组装成 Prompt调用对话模型。5.3 项目结构与依赖我们建一个简单项目目录结构如下rag_demo/ ├── requirements.txt ├── config.py ├── main.py └── docs/ └── sample.txtrequirements.txt内容openai1.30.0我们先在docs/sample.txt里放一段公司产品介绍或技术文档作为知识库数据来源。这里以一段示例文本为例你可以替换成自己的文档。5.4 核心代码实现先看config.py统一管理模型配置import os LLM_API_KEY os.getenv(LLM_API_KEY, ) LLM_BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) CHAT_MODEL os.getenv(CHAT_MODEL, your-chat-model) EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, your-embedding-model) CHUNK_SIZE 500 CHUNK_OVERLAP 50 TOP_K 3 TEMPERATURE 0.2然后写main.py完整代码如下import os from openai import OpenAI from config import ( LLM_API_KEY, LLM_BASE_URL, CHAT_MODEL, EMBEDDING_MODEL, CHUNK_SIZE, CHUNK_OVERLAP, TOP_K, TEMPERATURE, ) client OpenAI( api_keyLLM_API_KEY, base_urlLLM_BASE_URL, ) def get_embedding(text: str): 生成文本向量 resp client.embeddings.create( modelEMBEDDING_MODEL, inputtext, ) return resp.data[0].embedding def split_text(text: str, chunk_size: int CHUNK_SIZE, overlap: int CHUNK_OVERLAP): 按固定长度切分文本保留重叠区间 chunks [] start 0 while start len(text): end start chunk_size chunk text[start:end] chunks.append(chunk) if end len(text): break start end - overlap return chunks def cosine_similarity(vec_a, vec_b): 计算两个向量的余弦相似度 dot sum(x * y for x, y in zip(vec_a, vec_b)) norm_a sum(x * x for x in vec_a) ** 0.5 norm_b sum(x * x for x in vec_b) ** 0.5 if norm_a 0 or norm_b 0: return 0.0 return dot / (norm_a * norm_b) def build_index(doc_path: str): 加载文档、切分、向量化返回文本块列表和向量列表 with open(doc_path, encodingutf-8) as f: text f.read() chunks split_text(text) vectors [] for i, chunk in enumerate(chunks): print(f正在向量化第 {i 1}/{len(chunks)} 个文本块...) vectors.append(get_embedding(chunk)) return chunks, vectors def search(chunks, vectors, query: str, top_k: int TOP_K): 检索与问题最相关的文本块 query_vec get_embedding(query) scored [] for i, vec in enumerate(vectors): score cosine_similarity(query_vec, vec) scored.append((score, i)) scored.sort(reverseTrue) top_indices [idx for _, idx in scored[:top_k]] return [chunks[idx] for idx in top_indices] def generate_answer(query: str, context_chunks): 基于检索结果生成回答 context \n\n.join(context_chunks) prompt f你是一名知识库问答助手。请根据下面的资料回答问题。 如果资料中没有相关内容请明确回答“资料中未找到相关内容”不要编造。 资料 {context} 问题{query} 回答 resp client.chat.completions.create( modelCHAT_MODEL, messages[ {role: system, content: 你是一个严谨的知识库问答助手。}, {role: user, content: prompt}, ], temperatureTEMPERATURE, ) return resp.choices[0].message.content def main(): doc_path docs/sample.txt if not os.path.exists(doc_path): print(请先在 docs/ 目录下创建 sample.txt) return print(1. 开始构建索引...) chunks, vectors build_index(doc_path) print(f索引构建完成共 {len(chunks)} 个文本块。) while True: query input(\n请输入问题输入 exit 退出).strip() if query.lower() exit: break print(2. 正在检索相关内容...) context_chunks search(chunks, vectors, query) print(3. 正在生成回答...) answer generate_answer(query, context_chunks) print(\n 回答 ) print(answer) if __name__ __main__: main()5.5 运行验证与结果说明运行前先设置环境变量export LLM_API_KEY你的API密钥 export LLM_BASE_URL你的模型服务地址 export CHAT_MODEL你的对话模型名称 export EMBEDDING_MODEL你的向量模型名称然后运行python main.py预期流程是程序读取文档并切分文本块。逐个文本块调用 Embedding 接口生成向量。进入交互式问答环节。你输入问题后程序检索最相关的 3 个文本块。模型根据检索内容生成回答。这个实现只用了openai一个依赖适合理解 RAG 的原理。生产环境通常会把向量存到 Chroma、Milvus、Qdrant、pgvector 等向量数据库用批量 embedding 提升索引速度并用异步调用减少用户等待时间。6. 部署形态与硬件边界LLM 必须本机部署吗6.1 “ComfyUI 与 LLM 必须在同一台电脑上么”的类似问题经常有人在技术群里问ComfyUI 与 LLM 必须要在同一台电脑上么这个问题本质上是关于“资源部署边界”的疑问。ComfyUI 是 Stable Diffusion 生态里的节点式工作流工具依赖 GPU 做图像生成。LLM 应用可能是调用云端 API也可能是在本地起一个模型推理服务。两者并不是同一类软件也没有“必须同机”的强制关系。关键在于你采用哪种部署形态。如果 LLM 应用只是调用云端 API那么 ComfyUI 在本地跑LLM 在云端跑完全没问题。如果 LLM 也在本地部署那么 ComfyUI 和本地 LLM 服务可以在同一台机器也可以分别部署在不同机器通过网络互相访问。如果两个都是云端服务更不需要关心所谓的“同一台电脑”。判断依据是三个因素算力资源是否足够、网络是否连通、数据是否允许跨机传输。6.2 本地 GPU 部署的适用场景本地部署 LLM 主要为了解决数据安全或长期成本问题。但本地部署并不是免费的它需要硬件投入和运维成本。以常见的开源模型为例7B 参数模型量化后大约需要 6GB~10GB 显存配合一定内存可以跑起来。14B 参数模型通常需要 16GB 以上显存。70B 参数模型需要 40GB 以上显存或者多卡并行。具体数值会因量化方式、上下文长度、部署框架而不同以你的实际测试为准。这里想强调的是本地部署的底线不是“能装”而是“能用”。单用户测试和多人并发是两个完全不同的量级。如果团队早期没有足够的 GPU 资源用云端 API 是更稳妥的选择。等验证了产品需求、有了真实客户付费再考虑用开源模型做私有化交付这个顺序更符合创业团队的资源约束。6.3 远程 API 本地应用的混合架构在实际业务中更常见的架构是“混合模式”桌面端或 Web 端应用部署在企业内网。LLM 推理统一走内部模型网关网关背后可以是云端 API也可以是本地 GPU 集群。企业知识库、业务数据库和文档存储保持在内网只有脱敏后的文本片段会发送到模型服务。图像生成类工作流比如 ComfyUI根据资源情况部署在独立的 GPU 机器上与应用服务器分开。这种架构的好处是每个组件可以独立扩缩容互不影响。图像生成吃 GPU聊天问答吃 API 配额知识库检索吃 CPU 和内存它们不应该被绑在一台机器上。所以回答开头那个问题时很简单LLM 应用不需要和 ComfyUI 在同一台电脑上重要的是你的模型服务、应用服务和图像生成服务之间网络互通以及数据流转符合业务合规要求。7. 常见问题与排查思路7.1 高频问题排查表问题现象常见原因解决思路调用 API 报 401/403API Key 配置错误或权限不足检查环境变量是否正确确认账号有对应模型权限请求超时网络问题或模型响应时间长设置合理超时时间先缩短 context 再测试中文回答出现乱码或截断输出长度不够或 prompt 指令不明确增大 max_tokens明确要求“用中文回答”回答不基于资料产生幻觉检索结果相关性差优化切分方式、调整 Top-K、更换 Embedding 模型本地模型显存不足模型太大或并发太高使用量化版本、减小上下文长度、增加显存Embedding 维度不一致切换了不同模型向量库存储了旧向量统一 Embedding 模型重新向量化原有文本用户输入包含敏感信息没有做输入脱敏或权限控制在应用层增加内容过滤和脱敏处理生成结果不稳定temperature 太高降低 temperature 到 0.1~0.37.2 系统化排查思路遇到 LLM 应用问题建议按“输入 → 检索 → 生成 → 输出”四个环节来排查先确认问题是不是由用户输入引起的比如输入了不支持的语言、包含无关指令。再看检索结果检查召回的内容是否和问题相关。如果检索就不相关后续生成大概率也不对。然后看 Prompt 组装检查上下文是否被截断、格式是否正确、指令是否清晰。最后看模型输出判断是格式问题、长度问题还是内容正确但表达不符合预期。排查中最推荐的调试方法是“逐层打印日志”。尤其是 RAG 应用一定要把“最终发给模型的 Prompt”打印出来。很多时候问题不在模型而在检索结果和 Prompt 拼接质量。8. 创业团队切入 LLM 的方向与最佳实践8.1 值得关注的切入方向回到文章标题Startups are chasing the next big thing in LLMs。那么对创业团队来说哪些方向更值得尝试垂直行业的 RAG 应用。通用问答已经被大厂覆盖但某个细分行业的专业问答仍然存在信息差。比如医疗文献解读、法律条款检索、金融研报分析、设备维修手册查询。这类场景门槛在于领域数据的整理和知识体系的构建模型本身反而不是壁垒。Agent 驱动的业务流程自动化。企业里有大量重复性、跨系统的流程比如售后工单处理、合同初审、简历筛选、库存对账。Agent 可以调用现有系统 API把原来需要人工往返操作的事情自动化。这个方向的核心不是模型能力而是流程设计、工具接入和异常处理。LLM 评测与可观测性工具。随着更多企业使用 LLM评测需求会越来越强烈。怎么做回归测试、怎么做线上质量监控、怎么评估 RAG 检索质量这些都是可以产品化的方向。数据侧服务。很多企业有文档但文档混乱、格式多样、更新频繁没法直接做 RAG。提供数据清洗、结构化抽取、知识库构建服务也是一个务实的切入点。8.2 需要谨慎的方向有几个方向创业团队要特别谨慎重复建设“通用大模型”。基础模型训练对资金、算力和算法人才要求极高头部玩家的优势和规模效应非常明显。除非有特别独特的资源否则不建议正面竞争。只做“套壳”应用没有数据或渠道壁垒。单纯把 API 包一层 UI没有差异化数据、没有独占渠道、没有深的业务流程绑定很容易被大厂的功能更新覆盖。忽略商业化闭环。LLM 应用的 token 成本是刚性的如果用户付费意愿不高或者客单价无法覆盖调用成本商业模式很难成立。早期就投入私有化部署。在没有验证需求前购买 GPU 服务器、组建模型运维团队会严重消耗创业公司的现金储备。8.3 工程化建议第一Prompt 也要做版本管理。把 prompt 放到配置中心或代码仓库里每次修改记录变更原因。不要散落在代码各处更不要只在线上临时调试。第二RAG 的质量取决于数据治理。文本切分方式、数据更新机制、文档去重、权限控制这些都需要认真设计。建议每次数据更新后对检索效果做一次回归验证。第三输出结构化降低集成成本。要求模型输出 JSON 而不是纯文本可以让下游系统更容易解析。注意设置合理的response_format约束并对解析失败做兜底。第四统计成本和延迟。每个请求记录模型名、输入 token 数、输出 token 数、耗时和错误码。成本上涨通常是突发的比如某个用户上传了超长文档触发大批量 embedding没有监控很难及时发现。第五建立最小评测集。准备 20~50 个典型问题每次换模型、改 prompt、改检索参数时都拿同一批问题跑一遍人工或自动判断回答质量。这个最小评测集能帮你避免“改坏了自己都不知道”的情况。第六重视安全边界。用户输入发送到外部模型前要脱敏模型输出展示给用户前要过滤敏感内容系统 prompt 里要约束“只基于资料回答不编造”。企业内部使用时还要按最小权限原则控制知识库的访问范围。9. 下一步学习路线如果你刚刚开始接触 LLM 应用开发建议按下面的顺序往下深入先理解 RAG把本文的代码多跑几遍改改文本切分长度、调整 Top-K感受不同参数对回答的影响。再学习 Agent了解函数调用Function Calling、工具定义、多步规划做一个能查天气、能查数据库的小 Agent。接着深入评测学着建立评测集用客观指标评估回答质量而不是只靠肉眼判断。然后研究部署优化了解 vLLM、Ollama、量化推理搞清楚本地部署的性价比边界。最后关注 LLMOps学习模型网关、Prompt 管理、日志追踪、成本监控把应用做到生产可用。方向判断比模型选择更重要。模型会持续迭代框架会不断变化但一个团队对业务场景的理解、对数据质量的把控、对工程细节的认真程度才是真正能沉淀下来的竞争力。现在去写代码、建评测、记录每一次实验结论比讨论“哪个模型更强”更有价值。