企业官网建设流程全解析

过去一年，我身边越来越多人开始把“大模型”从聊天窗口里搬出来，落到真正的业务和产品里。有人用 GPT-4o 写接口、做翻译、处理 JSON 字段；有人本地部署一套私有模型服务公司内部知识库；还有人已经摸到了微调和多模态的门槛——大模型的应用和工具，早就不是少数人的玩具。这篇文章就围绕“应用”和“工具”这两个核心，把从模型选型、部署方式、RAG 知识库、微调实战到多模态与 Agent 的完整链路整理一遍。

不管你是刚接触大模型的新手，还是已经跑过几个 Demo 但没打通生产环境的工程师，这篇文章都按“先选型、再部署、然后接业务、最后优化”的顺序来讲。内容包括可照抄的本地部署命令、Dify/FastGPT 接入本地模型的配置方法、微调数据样例和训练参数、常见问题排查表，以及我在实际项目中踩过的一些坑。

1. 先从“选模型”开始：每一类任务都有自己的最优解

1.1 大模型不是只有一种，“通才”和“专才”要分开用

很多人第一次接触大模型，以为全世界只有 Chat-GPT 和 Claude 两个入口。真进入应用层之后你会发现，大模型早已分成了好几个流派：通用对话、数学推理、代码生成、多模态理解和图像生成。选错类型的模型，后面的所有工作都是在给它“擦屁股”。

举个例子：如果你要做客户工单分类，一个 7B 参数量的 Qwen 模型就够用，速度和成本都漂亮。但如果你要做一个数学解题助手，让 Qwen-7B 硬上效果就差得多，这时候要么用推理增强模型（如 DeepSeek-R1 系列），要么得配合思维链提示词，甚至要走微调路线。

我习惯把选模型拆成三个维度：

• 能力：这个任务对推理、知识、代码、视觉、语言的要求到底有多高？普通文案生成和复杂业务推理，对模型能力的要求差两个级别。
• 成本：调用一次 API 多少钱？自建的话需要多少显存？能不能用量化模型压到单卡可跑？
• 控制：数据能不能出内网？业务方是否要求模型权重完全私有化？这直接决定了走 API 还是本地部署。

市面上主流模型的定位差别很大。GPT-4o、Claude 系列适合复杂 Agent 任务和高质量内容生成；DeepSeek-V3、Qwen 系列在中文场景性价比很高；Llama 3 是开源生态里被上游框架支持最全的选择。还有一类容易被忽略的 Embedding 模型（比如 BGE、text-embedding-3），RAG 知识库检索的效果好不好，一半靠它。

1.2 参数规模、上下文长度和量化等级，三个数字怎么看

选型时绕不开三个指标：参数量、上下文长度、量化等级。很多新手只看参数量，其实上下文长度对应用的影响更直接。

参数量决定了模型的知识容量和推理能力，但 7B 和 70B 之间的差距不是线性的，并不是参数越大就一定越适合你。7B 模型在单张消费级显卡上能跑，70B 级别的模型即使做了 4bit 量化，也至少要两张 24GB 显存的卡。实际项目中，我见过很多业务直接用 7B 模型就能扛住 80% 的场景，关键是提示词和工程方案要设计到位。

上下文长度是另一个容易踩坑的点。大模型的上下文窗口就像它的“工作记忆”，窗口越大，单次能塞进来的资料越多。做 RAG 知识库、长文档总结、JSON 字段翻译这类任务，上下文不够就得很费劲地切块、分段。现在主流模型普遍支持 8K 到 128K 以上的上下文，但要注意“支持”和“用好”之间还有很大距离，超过一定长度后注意力会衰减，输出质量明显下降。

量化等级解决的是“跑不跑得动”的问题。FP16 精度下，7B 模型大约需要 14GB 显存；4bit 量化后只需要 4GB 左右。这就让很多 16GB 显存的笔记本也能本地跑模型。代价是输出质量稍微下降，但实测下来绝大多数业务场景根本感知不到差异。

提示：选型的顺序应该是“任务 → 模型能力 → 部署方式 → 量化和参数微调”。不要反过来，手上有什么卡就迁就什么模型，这样业务会被硬件绑架。

2. 部署方案全景：API 便捷，本地可控，各取所需

2.1 API 路线的正确姿势：免费 API、限流与请求格式

API 路线最大的优势是省事。不用管显卡、不用管模型权重、不用管推理框架，注册账号拿 Key 就能调。现在很多平台都提供免费 API 额度，足够个人开发和测试用。但我在项目里实际用下来的体会是：免费 API 的限流策略通常很严格，并发稍高就给你 429 错误，生产环境千万别把宝押在免费接口上。

调用大模型 API 时，绝大多数平台都兼容 OpenAI 的请求格式。这意味着你写好的代码，只需要改 base_url 和 api_key，就能从一个模型切到另一个模型。项目里我一般会在代码层封装一层统一的模型调用接口，后面换模型、加模型都方便，不需要改业务代码。

请求格式的核心是三个字段：model（模型名）、messages（消息列表）、max_tokens（最大输出长度）。消息列表里有 system、user、assistant 三种角色，system 用来设定人设和规则，user 是用户输入，assistant 是模型历史回答。很多新手只把 user 消息传进去，忘了设计 system 提示词，效果自然打折扣。

实际项目中还需要注意两个细节。一是超时时间要设置合理，复杂任务模型响应可能超过 30 秒，前端要有对应的等待机制。二是输出长度要主动控制，尤其是做批量翻译、JSON 解析时，不限制 max_tokens 很容易出现截断，返回一段不完整的 JSON，程序直接解析报错。

2.2 本地部署：从 Ollama 到 vLLM，不同场景不同工具

本地部署大模型，核心目标只有一个——把模型权重拿在手里，数据不出内网。我最早是从 Ollama 入手的，它把模型下载、加载、API 服务三个步骤封装成了三条命令，极其适合新手和原型验证。

安装完 Ollama 之后，拉取模型并启动服务只需要两步：

# 拉取一个 7B 模型（以 Qwen 为例） ollama pull qwen2.5:7b # 运行模型并启动本地 API 服务（默认 11434 端口） ollama serve

然后你就可以用任何兼容 OpenAI 格式的客户端来调用了：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好，请做自我介绍"}] }'

Ollama 适合单机、低并发、快速验证。但如果你要做高并发的生产服务，就得换 vLLM 这类推理框架。vLLM 的核心能力是 PagedAttention 显存管理，能把显存利用率提上去，吞吐量比原生加载高好几倍。部署方式也不复杂：

pip install vllm vllm serve Qwen/Qwen2.5-7B-Instruct --gpu-memory-utilization 0.9 --max-model-len 8192

Windows 上还有一个很适合入门的选择是 LM Studio。它是图形界面，下载模型、配置参数、启动本地服务都靠点鼠标完成。尤其有意思的是，Visual Studio 2022 可以直接连接本地 LM Studio 跑的模型来辅助生成代码。我在 Windows 上做 C# 开发时用过这个组合，代码补全的回答延迟很低，数据完全本地，不用担心代码片段外传。

还有一个 AirLLM 值得一提。它通过分层加载和 CPU offload，在只有 4GB 显存的机器上也能跑起几十 B 参数量的模型。速度肯定不快，但应急验证是够了。

2.3 私有化部署的硬件账：显存计算和 GPU 选型

本地部署最大的拦路虎是硬件。我见过很多人兴冲冲下载了一个 70B 模型，跑起来之后发现 4090 都带不动，又灰溜溜换回 7B。先把显存账算清楚，再做决定。

显存需求有个粗略公式：显存占用 ≈ 参数量 × 每参数字节数。FP16 精度下每参数占 2 字节，INT8 占用 1 字节，4bit 量化占用 0.5 字节。所以：

• 7B 模型 FP16 需要约 14GB 显存；
• 7B 模型 4bit 量化需要约 4GB 显存；
• 70B 模型 4bit 量化需要约 35GB 显存。

再加上 KV Cache（占上下文长度有关的显存）、CUDA 上下文本身的占用，实际需求还要再上浮 10% 到 20%。

GPU 选型方面，NVIDIA 的生态最成熟，CUDA、vLLM、Pytorch 全支持。AMD NPU 笔记本和一些国产加速卡这两年也在推进本地大模型推理，但坑比较多，不少推理框架要魔改才能跑。除非你就是为了折腾，否则生产环境我还是推荐老老实实用 NVIDIA。

注意：量化不是万能的。4bit 量化后的模型虽然显存需求降了一大截，但输出质量、生成长度、推理速度都会受影响。如果业务对输出质量要求很高，优先考虑加显存，而不是把模型压得太狠。

3. RAG 与知识库：把模型接进业务数据的关键玩法

3.1 为什么说 RAG 是比微调更优先的选项

大模型有一个天生的短板：它的知识截止在训练那一刻，你公司的内部流程、最新产品文档它一概不知道。想让模型“懂业务”，有两条路：RAG 和微调。

RAG 的思路很直接——不改变模型权重，而是在每次提问时，先从你的文档库里检索出相关内容，把检索结果连同原始问题一起塞给模型，让模型基于这些资料来回答。它的优势在于：数据更新即时、不会破坏模型原有能力、出问题可追溯来源。

我个人的经验是：能上 RAG 的场景，尽量先上 RAG，别急着微调。原因很简单，微调的试错成本太高，数据准备、训练调参、效果评估，一套下来周期按周算。而 RAG 方案里，文档更新是即时的，哪儿写得不好，改文档就行，不用重新训练模型。

3.2 从文档到答案：RAG 的五个核心步骤拆解

RAG 不是一个大模型就能搞定的，它是一条流水线。完整链路包括：文档加载 → 文本切分 → 向量化 → 向量存储与检索 → 生成回答。

文本切分（chunk）是整条链路里最容易被低估的环节。切得太碎，语义被拆得七零八落，检索召回的自然就不是完整信息；切得太粗，单块里面塞进太多无关内容，模型回答容易被噪音带偏。我在项目中常用的策略是：按标题层级切分文档，每个 chunk 控制在 300 到 800 字之间，相邻 chunk 之间保留 10% 的重叠。这样既保留了上下文连贯性，又不会让单次检索带进太多无关内容。

向量化就是用一个 Embedding 模型把文本变成一个大数组，两个文本的相似程度通过数组的余弦相似度来算。Embedding 模型的选择也很关键，中文场景我用 BGE 系列比较多（比如 bge-large-zh-v1.5），效果稳定，而且开源可以本地跑，便于数据不出内网。

生成环节就是把“原始问题 + 检索出的相关片段 + 严格的提示词约束”打包发给大模型。提示词里要明确告诉模型：只依据提供的资料回答，资料不足就说不知道，不要瞎编。

3.3 Dify 和 FastGPT 接入本地模型的完整配置

现在很多人做知识库已经不用从零写代码了，Dify 和 FastGPT 这种开源工具把 RAG 编排做成了可视化流程。它们的共同点是都支持接入本地模型。

以 Ollama 部署的 Qwen2.5 模型为例，在 Dify 里接入只需要几步：

1. 确认 Ollama 服务已经启动（ollama serve）；
2. 在 Dify 的“设置 → 模型供应商”里选择 Ollama，填写 API 地址http://localhost:11434；
3. 配置对话模型为qwen2.5:7b，Embedding 模型为bge-m3或其他已拉取的向量模型；
4. 创建知识库，上传文档后系统会自动做切分和向量化；
5. 在应用编排里关联知识库，设置召回模式（我一般先用“向量召回 + 关键字召回”混合模式），就能开始提问测试了。

FastGPT 的接入逻辑类似，它更强调工作流的可视化编排。有一点要注意：FastGPT 对接 Ollama 时，有些版本对模型返回格式有要求，如果出现接入后无响应的情况，先去后台日志看 Ollama 那边有没有收到请求，优先排查网络连通和模型名称是否匹配。

我自己的习惯是先用 Dify 快速搭一个知识库 Demo，确认业务效果，再决定要不要在生产环境自研 RAG 流程。原因很简单——Dify 解决“能不能用”的问题，而自研解决“用得好不好”的问题。前期用现成工具验证价值，后期再针对性能优化，这个顺序比一上来就造轮子合理得多。

3.4 知识抽取、JSON 翻译这类“脏活”怎么做

RAG 不只能做问答，很多看起来不搭界的任务，其实本质都是“检索 + 生成”。我在项目中经常遇到两类场景：知识抽取和 JSON 字段翻译。

知识抽取方面，现在有一个比较实用的开源框架叫 OneKE，它专门用大模型从非结构化文本里抽取实体、关系、事件等结构化知识。比如你喂它一份产品需求文档，它能自动抽出“功能模块”、“依赖关系”、“验收标准”，直接灌进知识图谱或者关系型数据库。这类框架的价值在于把大模型从“聊天对象”变成了“数据加工机器”。

JSON 字段翻译是另一个高频需求。业务方手里有一大批 JSON 配置文件，字段名字是英文，注释是中文，要翻译成另一种语言。直接丢给大模型翻译整段 JSON，模型很容易把结构改坏。我的做法是：先用程序把 JSON 解析成字段名: 字段值的扁平结构，让模型只翻译字段值，最后再用程序恢复 JSON 结构。这样即使模型输出稍微不规范，也不会破坏整个文件。

这些“脏活”有一个共同的技巧：把任务拆小。不要试图一次让模型解决完一个复杂问题，把问题拆成模型每一步容易完成的小任务，效果和稳定性都会好很多。

4. 微调实战：用数据“教”模型说行话

4.1 微调和 RAG 的边界：什么场景必须微调

虽然我在前面说“能上 RAG 就上 RAG”，但确实存在非微调不可的场景。最典型的是：模型需要学习特定“行为风格”或者“领域知识已经内化在参数里”才能完成任务。

举个例子，你要做一个电商客服助手。RAG 方案可以让模型查到具体的退货政策、优惠规则，但当用户问“帮我写一段售后安抚话术”时，模型还是不知道怎么说得像个资深客服。因为这是表达风格的迁移，不是信息检索能解决的。这时候微调的价值就出来了：用几千条优秀客服的对话样例，让模型学会客服该有的语气、结构、问题处理路径。

微调的另一个价值是压缩提示词。如果你发现每次调用都要塞一大段 system prompt 才能让模型表现出理想行为，考虑把这些“规则”灌注进模型权重里，让调用变得更简单、更稳定。

我给团队的决策判断标准很简单：需要事实性回答 → 用 RAG；需要风格和行为模式 → 用微调。两者不是互斥关系，生产环境往往是两者叠加。

4.2 LoRA 和 QLoRA：消费级显卡也能微调大模型

一说到微调，很多人先被显存劝退了。但 LoRA 技术出现之后，微调门槛大幅下降。LoRA 的原理是用一个小矩阵去模拟大模型权重更新量，训练时只更新这个小矩阵，不动原始大模型权重。这样原来需要 100GB 显存的 7B 全量微调，LoRA 只需要 16GB 左右的显存；再用上 4bit 量化（QLoRA），7B 模型的微调甚至能在 10GB 显存的显卡上完成。

我常用的微调框架是 PEFT（Parameter-Efficient Fine-Tuning）配合 Transformers。核心训练脚本结构大概是：

from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer # 加载模型（可开启 4bit 量化） model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-7B-Instruct") tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct") # 配置 LoRA lora_config = LoraConfig( r=16, # 秩，越大能力越强，显存占用越大 lora_alpha=32, # 缩放系数 target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, ) model = get_peft_model(model, lora_config)

关键参数里，r决定 LoRA 矩阵的秩，常见设置 8 到 64。秩太小学不到东西，秩太大会过拟合。lora_alpha是缩放系数，比值lora_alpha / r越大，微调的影响越强，一般保持 2 倍左右比较稳。训练轮数不需要太多，我见过很多新手把 epoch 设成 10，结果模型直接过拟合，反而比基座模型更差。

4.3 高质量数据标注：指令微调的数据格式与样例

微调效果七成靠数据。DeepSeek 开源过一套数据标注样例，核心格式是instruction / input / output三段式。instruction描述任务，input是具体输入，output是期望输出。

以“抽取出差报销单关键信息”为例，一条训练样本长这样：

{ "instruction": "提取出差报销单中的关键信息，输出 JSON 格式。", "input": "出差人：张三，部门：技术部，时间：2025年3月12日到14日，地点：上海，交通费：高铁往返共860元，住宿费：两晚共1200元，补贴标准：每天80元。", "output": "{\"出差人\":\"张三\",\"部门\":\"技术部\",\"日期\":\"2025-03-12至2025-03-14\",\"城市\":\"上海\",\"交通费\":860,\"住宿费\":1200,\"补贴\":240}" }

标注数据时最常犯的错是数据风格单一。如果 1000 条训练样本里全是同一模板的输入，模型学到的是模板匹配，而不是任务能力。我给团队的要求是：每类样本至少涵盖 10 种变体，句子结构、名称、数值格式都要有变化。宁可样本量少一点，也要保证覆盖度。

另外，质量比数量重要得多。50 条高质量样本人人都能看懂，1000 条低质量样本只会把模型教坏。数据清洗阶段就要建立抽检机制，每次标注完，随机抽 10% 的样本人工复核。

4.4 微调过程中踩过的坑：过拟合、遗忘和评测

微调项目的成败，很多时候在评测环节就决定了。我看到太多团队花了两周微调，效果好不好全靠“感觉”，这完全是浪费。

先说过拟合。微调模型在训练集上的 loss 降得很漂亮，但一上真实业务就原形毕露，这基本上就是过拟合。判断方法很简单：准备一个验证集，训练过程中每个 epoch 都跑一遍验证集 loss。验证集 loss 开始回升的节点，就是最佳停靠点。我一般会在验证指标最好的 epoch 附近再训练一到两轮，然后取平均值做早停。

再说灾难性遗忘。微调让模型学会了新风格，却忘了通用能力。这在大模型微调里尤其明显。避免的方法有两个：一是控制训练步数，不要贪多；二是在训练数据里掺 5% 到 10% 的通用指令数据，让模型“复习”常识。

评测体系建议包括三类：业务场景的真实样例（30 到 50 条）、通用能力基准（常识问答、改写、总结各几条）、对抗性输入（故意刁难、乱写格式）。每轮训练完都跑一遍，横向对比基座模型和上一轮模型的差异，用表格记录分数，这样模型选型才有依据。

5. 多模态、Agent 和工具生态：大模型能做的事比聊天多得多

5.1 语音、视觉和图像生成：多模态模型的应用进展

多模态是今年最热闹的赛道。语音方面，讯飞的实时语音转写大模型已经能做到流式识别加前端适配，部署在本地后可以在会议系统里做实时字幕和纪要。视觉理解方面，GPT-4o、Qwen-VL 这类模型能看懂截图、流程图、UI 设计稿，我在项目里用它们做 UI 自动化测试的视觉断言，能自动识别页面异常。

图像生成领域，Z-Image Turbo 这类开源绘图模型值得关注。它的特点是出图速度快，适合做批量配图和电商素材生产。模型文件下载后可以通过 API 方式跑，配合提示词模板，可以实现“参数化出图”——业务人员设定风格和主体，程序自动生成一批素材图。

多模态模型的应用有个通用心得：要把不同类型的内容拆成不同 pipeline。比如做内容审核，先让视觉模型检测图片是否合规，再让文本模型检测文字描述，最后汇总结果。不要指望单个多模态模型一把梭把所有类型都处理到位。

5.2 从单模型到智能体：AI Agent 的核心工作方式

AI 智能体（Agent）是大模型应用的高级形态。它的核心不是“回答问题”，而是“完成任务”。一个 Agent 系统通常包含：任务规划（把目标拆成子任务）、工具调用（调用搜索引擎、数据库、代码执行器等）、结果验证（检查自己的输出是否满足要求）、以及异常处理。

我在项目里实践过的比较靠谱的 Agent 模式是工作流式编排：先用大模型做意图识别，再根据意图调用不同的工具，每个工具的结果返回给大模型做下一步决策，最后大模型汇总输出。这种模式比“让模型自由发挥”的 AutoGPT 模式稳定得多，适合生产环境。

工具调用靠的是什么？是函数调用的准确率。大模型需要知道自己有什么工具、每个工具的参数是什么、什么时候该调用。这方面业界现在重点推 MCP（Model Context Protocol）标准协议，它统一了大模型与外部工具之间的交互方式。就连游戏引擎 UE5.6 也配套了官方的大模型 MCP 接入，开发者可以用自然语言让模型生成蓝图脚本、控制场景物件，相当于用聊天的方式写游戏逻辑。

5.3 提示词工程仍然是最低成本的生产力

工具生态再怎么进化，提示词工程依然是基本功。我见过太多人花大力气部署模型、做微调，结果问题出在提示词没写好，白白浪费算力。

结构化提示词的核心是“给模型明确的边界”。一段可用的提示词应该包含：角色定义、任务目标、输入格式约定、输出格式约束、边界说明。比如让模型做翻译，我会把 JSON 字段翻译的提示词写死成模板，要求输出必须是合法的 JSON，字段顺序不能变，遇到无法翻译的内容保留原样。

提示词的调试也有方法论。不要凭感觉改，每次只改一个变量，对比输出差异，记录哪个改动的效果最好。迭代几轮之后，你会沉淀出一套适合自己业务场景的提示词模板库。

实操心得：项目里我会把所有提示词模板集中放在一个配置文件里，用版本号管理。这样模型换了、参数调整了，都能快速回溯哪一版提示词效果最好。提示词和大模型一样，都要当代码来对待。

6. 常见问题与排查技巧实录

6.1 从部署到调用的高频问题速查表

做了一年多大模型应用，我整理了下面这些高频问题的排查方法和解决思路。表格里只列最常见的情况，完整细节还得分场景去查。

6.2 模型安全：当心大模型投毒和来路不明的权重

随着大模型部署普及，“模型安全”已经是一个不能跳过的话题。大模型投毒（Data Poisoning）指的是攻击者在模型训练数据或者开源模型权重里植入恶意行为，让模型在某些特定输入下输出有害内容、泄露隐私或者被后门控制。

在实际操作中，最直接的风险是下载来路不明的模型文件。我在团队里定了几条硬规矩：尽量从官方仓库下载模型权重，下载后核对模型的 SHA256 hash 是否官方一致；不对来路不明的第三方微调模型做生产部署；数据集同样要排查，尤其要注意训练数据里是否被塞入了恶意注入样本。

大模型的输出安全同样要纳入工程链路。生产环境里，模型的回答不要直接透传到用户端，建议加一层内容审核。这层审核既可以用规则拦截（敏感词、格式校验），也可以用另一个模型做二次判断。不要嫌多此一举，线上出过一次安全事故，成本远高于多部署一个审核模块。

6.3 模型测评：跑分网站可以参考，但别迷信

大模型市场鱼龙混杂，每周都有新模型号称“屠榜”。我的建议是：跑分网站（比如各种榜单和竞技场）可以作为初筛参考，但绝不能作为最终选型的唯一依据。

跑分本质上是在特定测试集上的表现，和你的业务场景不一定匹配。我见过某个模型在通用榜单上排名很低，但在中文长文本总结任务上表现极佳。反过来也有榜单前几名在垂直业务上水土不服的情况。

更可靠的评测方式是自建评测集。从你的业务数据里挑 50 到 200 条真实样例，构成一个覆盖主流程的测试集合。用同一套输入分别跑候选模型，对比输出质量、延迟、成本三个维度。评测结果记录成表格，这才有参考价值。

免费 API 的测评也容易踩坑。有些免费接口会偷偷降级模型或者混入低配版本，你测出来的效果和付费版本完全不同。如果项目要上生产，一定用付费账号跑一遍真实场景，别拿免费额度做最终决策。

最后再分享一点我的体会

做了一年多的大模型项目，我自己最大的感受是：这个领域的信息密度极高，但很多东西不需要一开始就全掌握。你不需要第一天就懂微调原理，也不需要第一次接触就搭多模态 Agent 系统。最务实的路径是：从 API 调用开始，理解提示词；然后折腾本地部署，吃透显存和量化；接着搭一套 RAG 知识库，把模型接进业务数据；最后才考虑微调和 Agent 化。

每一步之间都有清晰的依赖关系，前一步没有跑通，后一步花再多时间也是白搭。我见过不少团队，一上来就上 70B 模型 + 微调 + Agent 全家桶，结果方案越来越复杂，效果反而被一个简单清晰的 RAG 系统甩出几条街。

如果你现在正准备上手，我建议就从手头一个具体的小任务开始——比如“让模型自动从邮件里抽取待办事项”，或者“搭一个公司内部文档问答机器人”。先把它跑通，再慢慢摊开来看这整张大模型的应用地图，那时候你会发现自己已经站在门槛里面了。