企业官网建设流程全解析

1. 2026年重新审视：大模型早已不只是"会聊天的模型"

今年我做技术选型的时候有个很明显的感受：身边越来越多的人不再问"哪个大模型聊天好用"，而是改问"这个模型能不能接进我们的业务系统"。"AI大模型"这个词从热搜名词变成了实际的生产工具，这种转变不是某一次版本升级带来的，而是整个技术栈在过去两三年里逐渐成熟的结果。

如果你现在才准备系统地理解大模型，你会发现它已经被拆解成很多具体方向：基础理论、微调训练、部署推理、Agent编排、多模态生成、上下文工程、私有化方案……每一个方向都有独立的工具链和社区生态。好消息是，入门门槛比两年前低了很多；坏消息是，信息太杂，网上到处是互相矛盾的说法，新手很容易被带偏。

我给这篇文章定了一个比较务实的目标：不聊虚的宏观趋势，只把大模型从原理到落地中间最关键的那些环节拆开讲透——包括它为什么能产生"智能感"，多模态到底进展到了哪一步，微调是不是必须做，本地部署和API调用怎么权衡，以及Agent把大模型推向"执行者"之后带来的新问题。文章里的很多结论来自我自己的项目实践和踩坑记录，不一定适用于所有场景，但至少能帮你少走一点弯路。

先说一个我认为最重要的判断：在2026年，把大模型单纯当作"聊天工具"是最浪费的使用方式。它的价值在于成为整个系统的推理中枢——前接检索、后接 API 调用、中间穿插多轮任务拆解。也就是说，真正值得研究的不是模型本身能回答得多好，而是你如何把模型嵌进一个能自动解决实际问题的链路里。后面几节我会一步步展开这条链路。

2. 底层机制拆解：Token、Transformer与规模定律如何造就"智能感"

2.1 Token化：模型眼中根本没有"文字"

很多人第一次接触大模型时最困惑的问题是：它明明是在做文字处理，为什么还能写代码、做数学题、翻译、总结？

关键在于模型的输入并不是我们理解的字符，而是 Token。Token 是文本被切碎后的基本单位，一个 Token 可能是一个完整的英文单词、一个中文词语、一个汉字的一部分，甚至是一个标点符号。模型拿到的是 Token 的 ID 序列，它从没有"看到"过任何字面含义，只是在预测"下一个 Token 是谁"。

举个例子，一句话"下雨天适合读长篇小说"，做 Token 切分后很可能变成：下雨/天/适合/读/长篇/小说。每个片段被映射成一段向量，模型对这个向量的理解完全来自训练时见过的海量上下文。所以当我们说"模型懂语义"，严格讲是"模型学会了 Token 之间在高维空间里的位置关系"。位置越接近，语义越相关——这就是 Embedding 的核心直觉。

2.2 Transformer的注意力机制：为什么长文本这么烧钱

2026年的主流大模型依然以 Transformer 为骨架，这个架构里最核心的模块是自注意力机制。它的作用是让每个 Token 在生成的时候，能够动态地"回看"输入序列里的其他 Token，计算它们的相关性权重，从而决定自己应该接着输出什么。

注意力的代价是二次复杂度：序列长度翻倍，计算量变成原来的四倍。这就是为什么"上下文长度"会成为各厂商的竞争指标——从 8K 到 32K 到 128K 再到更大的长度，每往上走一档，背后都是显存、算力和推理延迟的巨大压力。我自己实测过在 64K 上下文的项目里做流式输出，显存占用比短文本多出数倍，响应延迟也从几百毫秒涨到了几秒。

这也解释了为什么"能把长文本塞进上下文"和"能在长文本上真正用好信息"是两回事。模型可能读过你上传的两万行文档，但注意力分布会自然倾向于开头和结尾的 Token，中间关键信息经常被"稀释"。工程上常用的对策是 RAG，把检索到的相关片段精确送入上下文，而不是把所有材料无脑塞进去。

2.3 Scaling Law：为什么参数越大就越"聪明"

过去几年大模型领域最可靠的实验结论之一就是尺度定律：在模型结构固定、数据质量稳定的前提下，模型性能大体上随参数量、数据量和训练计算量呈可预测的幂律增长。简单说，只要规模继续扩大，模型在大多数任务上的表现就会持续上升，而且这个趋势可以被外推。

但尺度定律在2026年已经产生了明显分化。纯粹暴力堆参数的红利正在边际递减，现在大家更看重"有效参数"——也就是通过稀疏激活、混合专家架构等手段，让单次推理只激活一部分参数，从而在总参数量很大的同时控制推理成本。开源社区这两年特别流行的 MoE 类模型就是这个思路：总参数上千亿，但激活参数只有几十亿，单卡也能跑得动。

这里我建议基础一般的读者别被"千亿参数"这样的数字吓住。参数多不等于一定好用，实际体验和训练数据的质量、对齐水平、上下文策略的关系更大。你选型时更该看的指标是评测集上和自己业务场景接近的任务分数，而不是总参数大小。

3. 多模态的新战场：绘图、视觉理解与工业质检的真实落差

3.1 生成式多模态：绘图模型的进展与局限

多模态大模型是最近两年流量最大的方向。以绘图模型为例，从早期的扩散模型一路进化到带有控制能力的端到端生成管道，现在开源社区随手就能下载到一批效果不错的文生图模型，有些跑在消费级显卡上就能出图。

不过我在实际项目里发现，多模态生成类模型"能出图"和"能按要求出图"之间依然存在巨大的工程距离。比如产品包装设计里，AI 生成的概念图经常在文字渲染上出错，中文字符尤其明显；再比如电商场景需要保持主体特征一致，而原生生成的每张图风格漂移很大，必须借助图像参考、LoRA 定制或者局部重绘才能稳定复现。

这里有一个很实际的建议：如果你只需要稳定生成某一类特定图像，优先找做过领域微调的"垂直模型"，比如专门针对特定风格或特定物体训练的版本。通用模型的审美能力很强，但在固定约束下反而不如窄域模型听话。我自己在这个问题上反复折腾了挺长时间，最终选了垂直模型加少量 ControlNet 约束的路线，出图稳定性才真正达到交付标准。

3.2 视觉理解：检测、识别与判断之间的差距

工业 AI 领域是视觉大模型应用最被看好的地方之一，尤其是服装检测、缺陷质检这类场景。热搜里出现"像工业AI检测、服装检测这类AI是用的云联网还是单机的AI，用的什么大模型足够"，这个问题非常有代表性。

先给一个直接回答：工业质检场景目前绝大多数是本地化部署，不会把检测任务跑到云端 API 上。原因很现实——产线需要毫秒级响应、数据不能出厂、网络不稳定是一个不容接受的变量。至于"用什么大模型足够"，要分情况看：

• 如果做的是标准化产品外观检测，传统计算机视觉加定制算法依然是主流，成本低、速度快、可解释性强；
• 如果缺陷类型复杂、外观差异大、无法用规则描述，才需要考虑大模型的光学字符识别加视觉理解能力；
• 如果是开放场景的描述性判断，比如"这张图片里有没有破损、污渍、线头"，那么视觉语言模型配合提示词是最灵活的方案。

我用过几个开源视觉语言模型做缺陷分类的验证，结论是：它们对"常识性异常"的识别能力很强，比如明显的破损、形变、颜色异常，但对需要行业经验才能判断的细微缺陷（比如缝制工序里的针距问题）就力不从心。所以真正靠谱的做法仍然是先收集一批现场缺陷样本，在垂直模型上做微调，而不是指望通用模型一上来就懂你的产线。

3.3 语音与多模态融合：声音的空间化与更自然的交互

多模态并不只有图像一条路。语音交互、声音空间化处理这些方向也在快速成熟。所谓声音空间化，指的是让 AI 不仅能识别语音内容，还能判断声源方向、距离、环境回声，从而支持更自然的远场交互。这个方向在会议纪要设备、车载语音、智能家居场景里很有应用空间。

我试用过一些支持空间音频处理的方案，真实感受是：技术上已经能实现"声随人动"的效果，但工程化落地依然要处理噪音抑制、回声消除、多人重叠说话等老大难问题。大模型在语音这边的优势是语义理解更聪明了，但信号处理层面的脏活累活，依然要靠传统的音频处理链路来兜底。一个实用的经验是：别全部寄希望于一个多模态模型搞定语音全链路，前端信号处理加后端语义理解的组合仍然是最稳的架构。

4. 大模型微调实战：LoRA路径下成本可以压到很低

4.1 微调是不是必选项

很多人一上来就问"我要不要微调大模型"，我的回答通常是"先别急"。微调的目的是让模型适配特定领域的数据分布或输出格式，但它的代价是你需要准备高质量数据、维护训练环境、做效果回归，而且每次基础模型升级后你都得重新微调。

在你确认以下两种情况之一前，不建议动用微调：

• 场景需要固定的输出结构，而提示词工程无法稳定做到，比如强制模型输出特定 JSON 结构且字段含义必须完全对齐；
• 通用模型在你这个垂直领域的表现明显不足，而且你自己手里有一批高质量的真实样本，这些样本很难从公开数据里获得。

如果只是想让模型了解某些背景知识，优先考虑 RAG 把资料喂进上下文；如果只是想让语气更专业，改系统提示词就够了。微调解决的是"能力分布"问题，不是"知识补充"问题。

4.2 LoRA与QLoRA：低成本微调的原理与配置

正式做微调时，我强烈建议从 LoRA 或其升级版 QLoRA 入手，而不是全参数微调。LoRA 的核心思路是冻结原始权重，只在 Transformer 层里旁路插入低秩矩阵来学习任务差异。打个比方，全参数微调像是把整本字典重写一遍，LoRA 则是在字典旁边贴了几张小抄，记录与你任务相关的固定改写规则。

这样做最大的好处是训练参数量大幅下降。我跑过一个小规模项目，全参数微调一张消费级显卡根本装不下，但 LoRA 只要不到 10% 的显存就能完成训练。QLoRA 在这个基础上更进一步，把原始模型量化为 4-bit 后再训练，显存门槛进一步降低。

给你一个可参考的配置基线：

• 基础模型选 7B~14B 级别的开源模型；
• 量化级别 4-bit 起步，显存 24GB 可以比较从容地训练 7B 模型；
• 批次大小设为 1 或 2，梯度累积步数调到 8 左右；
• 学习率从 1e-4 起步，用余弦衰减或固定步长调度；
• LoRA 的秩建议从 8 到 64 之间尝试，秩越大可学习参数越多，但过拟合风险也越高。

我在排错时遇到过一个高发问题：LoRA 训练后出现严重过拟合，验证集分数漂亮，一到真实数据上效果崩盘。排查下来通常是对训练轮数控制得不严，以及数据集里重复相似样本太多。我后来养成了习惯：先把训练集做去重和清洗，再按 8:2 切分验证集，训练中每轮都盯验证 loss，如果验证 loss 连续两轮上升就提前停止。

4.3 数据准备：微调项目里最耗时也最值钱的环节

微调项目的成功与否，数据质量占七成以上，模型选择只占三成。很多团队迷信调参，却不愿意花时间整理数据，最后模型效果自然拉胯。

数据准备我建议按这个顺序推进：

• 原始数据收集：从日志、客服会话、工单系统里采集真实样本，越贴近线上分布越好；
• 清洗与脱敏：去除重复项、错误样本、含个人信息或敏感信息的内容，这一步也是合规要求；
• 字段对齐：整理成统一的输入输出对，输入是用户问题或待处理文本，输出是期望模型生成的内容；
• 构建难度梯度：不要只放简单样本，要刻意加入边界情况、难例、容易混淆的对比例子，让模型学会区分。

我个人的经验是，五十到一百条精心整理的高质量样本，往往比随便凑的几千条噪声数据更有价值。小数据微调的核心不是"学习新知识"，而是"调整输出风格与结构偏好"，模型的主体能力早就在预训练阶段完成了。

4.4 微调之后必须做的回归验证

微调完成后不要急着上线，至少做三层验证：

• 基础能力回归：检验模型在通用问题上的表现有没有退化，很多微调项目会破坏原有能力，这叫灾难性遗忘；
• 目标场景验证：用未参与训练的线下测试集跑一遍，看格式命中率和语义准确率；
• 对抗测试：故意构造模糊、歧义、超长、带噪声的输入，观察模型的鲁棒性。

我做过一次微调后模型确实在目标场景表现很好，但问它"1+1等于几"竟然开始答非所问的项目，就是因为训练数据里全是业务话术，把数学能力覆盖掉了。后来我混入 5% 的通用语料继续训练，这个问题才缓解。

5. 私有化部署实录：Ollama起底、Dify接入与Agent编排

5.1 本地部署模型的基本思路

企业场景里最常被问到的问题之一就是私有化部署。原因不外乎数据敏感、合规要求、离线可用和成本可控。本地部署大模型不像想象中那么难，但也远没有网上教程说得那么一键化。

我的标准路线是：先用 Ollama 这类工具做模型管理和推理服务，再通过 Dify 这类应用框架把模型接入业务流。Ollama 最大的优点是模型安装和运行足够简单，一条命令就能拉取模型并启动 OpenAI 兼容接口，很适合快速验证和内部工具。它在多模型切换、显存管理上也做了不少简化，省掉了手写推理服务的很多工作。

如果你需要更底层的控制，比如自定义采样参数、批处理优化、量化格式转换，还是得直接上 vLLM、TensorRT-LLM 这类专门的推理引擎。我的建议是：团队小、需求简单用 Ollama 起步，等吞吐量上来后再迁移到专业引擎。

5.2 部署环境实战：显存、量化与并发

讲一个很常见的代表性配置：在一张 24GB 显存的显卡上部署一个 7B 级别模型，量化到 4-bit，上下文长度设为 4K 到 8K，单卡大约能支撑几十路并发聊天请求（具体取决于输入输出长度）。如果你要部署 70B 级别模型，通常得准备两张甚至更多高端显卡，或者接受更激进的量化策略和上下文限制。

部署中最容易栽跟头的几个点：

• 显存不足会触发自动卸载到内存，速度暴跌几个数量级，表现就是响应慢得让人无法接受；
• 并发线程数设置过高会让推理引擎频繁排队，延迟反而变长；
• 上下文长度设得越长，显存占用越大，生成速度越慢，所以建议按实际需求设一个够用的值就好，没必要无脑拉满。

我在部署一台内部知识助手时，一开始把上下文开到了 32K，导致并发能力直接腰斩。后来把上下文收到 8K，配合 RAG 只把关键片段送进去，效果反而更好，并发也稳了。这是一个值得反复强调的经验：上下文长度不是越大越好，够用就行。

5.3 Dify接入本地模型：应用层的组装魔法

模型部署好只完成了第一步，真正发挥作用要搭建应用。Dify 这类平台的价值在于把 RAG 检索、提示词管理、工具调用和 Agent 编排集成在一个可视化的流程里，让团队不必从零写一套编排框架。

我接 Dify 和本地模型时踩过一个典型的坑：Dify 默认假设模型接口完全兼容 OpenAI API，但本地模型的接口在工具调用格式上经常有细微差异，比如函数调用的参数格式不完全一致。结果就是对话正常，一到工具调用环节就报错。解决办法是在 Dify 的模型配置里手动校准接口参数，或者选一个兼容性更好的模型版本。

接入完成之后，我建议先做一个最小闭环：上传几份内部文档作为知识库，在 Dify 里配置好检索策略，然后发起一轮带引用的问答。当模型能正确引用来源并给出答复，再考虑加入工具调用和 Agent 编排。

5.4 从模型到Agent：编排层带来的能力升级

本地部署的最终形态通常不是一个"聊天对话框"，而是一个能自动完成任务的 Agent。比如让模型根据用户诉求查询内部数据库、调用 API 发通知、生成报表草稿。这个过程中你需要提前为模型定义清楚工具清单、参数约束和判定规则。

这里我有一个很深的体会：Agent 的稳定性不是靠更强的模型，而是靠更严格的流程控制。模型负责的是"决定下一步做什么"，但"每一步怎么做""出错怎么回退""超时怎么处理"必须由工程代码兜底。你可以把大模型想成一个很有主见但偶尔迷糊的新员工，你需要给他明确的操作手册和报错机制，而不是任由他自由发挥。

6. Agent与多模型协作：把大模型从"回答者"变成"执行者"

6.1 Agent的核心能力：规划、记忆与工具调用

Agent 与大模型普通对话的本质差异在于：普通对话只要求模型"说正确"，Agent 要求模型"做正确"。这个转变带来三个核心模块：

• 规划：模型把一个大目标拆成若干可执行的子任务，并决定先后顺序；
• 记忆：在长流程中保存关键状态，避免每轮都像第一次对话那样失忆；
• 工具调用：根据任务需要调用外部函数、API 或数据库，并把返回结果纳入下一步决策。

这三块缺一不可。我在做会议纪要自动化项目时深有体会：如果只让模型做语音转文本和摘要，它表现不错；但要求它自动去日历里找空闲时间、给参会人发邀请、生成待办并同步到任务系统，就必须把每个环节对应的工具暴露给它。Agent 的"能动性"完全取决于你接入了多少可靠的工具。

6.2 多AI协作：一个Agent不够用怎么办

热搜里出现的"多AI协作"是另一个很值得展开的点。现实情况是，单一模型很难在所有维度做到最优：有的擅长推理，有的擅长长文档理解，有的生成代码更好。多AI协作的思路是让不同模型各司其职，由编排层统一调度。

我曾经搭建过一个相对简单的协作链路：模型 A 负责意图识别和任务分类，模型 B 负责检索和细粒度推理，模型 C 负责最终文案润色。效果上确实比单模型通吃要好，但坑也很明显：链路一长，延迟累加，成本翻倍，而且只要中间一个模型返回异常，整个流程就得处理各种分支错误。

所以我的建议是：多模型协作只在"单模型明显短板"的情况下引入，不要为了架构上的炫技而牺牲稳定性和成本。能用提示词解决的差异，优先用提示词；能用一个小模型加规则解决的，不要拉大模型进场。

6.3 上下文与记忆：Agent工程的阿喀琉斯之踵

做 Agent 类应用时，最大的痛点永远是上下文管理和记忆保持。原因前面提过：模型输入长度受限，注意力在超长文本上会退化，而且每轮工具调用返回的数据都会挤占上下文空间。

目前开源的成熟方案主要包括两类：一类是滑动窗口策略，只保留最近几轮对话摘要，更早的信息压缩成系统提示词；另一类是外部记忆库，把对话历史向量化存储，需要时检索回来。两者可以组合使用。我在实际项目中更倾向于混合策略：短期记忆用滑动窗口保持连贯性，长期记忆用向量检索按需召回。

记忆这块做得不好，Agent 就会表现出"看起来很聪明但记性很差"的状况，用户问一句"你刚才不是说要发邮件给张总吗"，模型如果对前面的对话没有可靠的记忆，立刻就会逻辑断片。工程上这是可以用流程设计规避掉的，但需要你在一开始就考虑清楚记忆周期的边界。

6.4 AI编程与测试开发：大模型正在改变研发流程

Agent 在研发领域的应用可能是目前落地最快、ROI 最明显的场景。AI 编程助手已经把"写代码"从"从零敲键盘"变成了"审查与修正生成结果"，我周边的开发团队几乎人人都装了编程插件。但我要说一个真相：AI 编程的上限和下限都取决于使用方式。如果只是把需求描述一遍让模型生成一个大文件然后直接跑，你会收获一堆隐患；如果拆成小函数、给足类型定义和接口约束，让模型补全局部逻辑，质量和效率都能提升。

AI 测试开发也是一个被低估的方向。让模型根据需求自动生成测试用例、边界条件和 Mock 数据，可以显著提升单测覆盖率。我在做一个内部工具时，让模型针对异常分支补测试代码，省掉了大量机械劳动。不过还是那句老话：生成内容必须人工审查，尤其在权限校验、金额计算、安全边界这类高风险用例上，不能拿模型的输出直接作为验收标准。

7. 选型清单与避坑心得：API、开源模型、专用模型的权衡

7.1 三类方案的真实成本对比

很多团队在选型时只盯着"模型效果"这一个维度，忽略了一个更大的成本结构。我把选型分成了三条路线：

• 闭源API路线：目前效果最好、接入最快、无需运维。成本按 Token 计费，量越大总费用越高，同时数据要出域，安全合规要求严格的场景要慎用；
• 开源模型自部署：数据完全留在内部，推理费用只和硬件电费相关，长期成本可控。但需要团队具备部署、调优和运维能力；
• 开源模型+云主机托管：介于两者之间，把模型部署在云服务商的 GPU 实例上，能保留数据边界但省去自购硬件的成本。

我的建议是：快速验证期直接选闭源 API，把产品跑通、验证需求；进入稳定期后，对高调用量场景做一次容量测算，如果月度 Token 费用明显高于同等硬件折旧成本，再考虑自部署。很多项目死在"从一开始就要自建"上——需求还没验证，光运维就拖垮了进度。

7.2 开源模型怎么选：参数、量化、许可证三个视角

开源大模型的选择已经非常多，新手容易迷路。我给自己定了三个筛选条件：

• 参数规模与硬件匹配：消费级显卡优先考虑 7B~14B 区间，有部署资源再考虑 30B 以上；
• 量化兼容性：看社区里是否已有成熟的 4-bit 或 8-bit 量化版本，避免自己从零踩量化坑；
• 许可证约束：开源不等于随便商用，有些模型仅允许研究用途，商用前务必核对许可证条款。

还有一个很容易被忽略的维度是"生态活跃度"。一个模型如果社区讨论多、教程多、周边工具多，你遇到问题时更容易搜到解决方案。反之，一个分数很高但没人用的模型，你往往会成为第一批踩坑者。

7.3 免费API与个人项目：能用，但别把命脉系在上面

热搜里反复出现"免费大模型API"，个人开发者想找免费资源完全可以理解。这些免费额度用于学习、试用、轻量级 Demo 是够的，但我不建议把它作为生产环境的唯一依赖。免费服务的稳定性、速率限制、数据使用政策随时可能变化，一旦业务做起来，你会发现"免费"往往是更贵的开始——迁移成本、兼容改造成本、数据安全风险都会冒出来。

个人项目的正确姿势其实是：先用免费额度验证产品逻辑，等技术形态稳定后评估是否自部署小型开源模型。目前开源模型的水平已经足够撑起不少个人工具的体验，而且三五百页文档的知识问答场景，一个 7B 模型完全能应对。

7.4 落地避坑清单：我在项目里遇到的五个高发问题

最后分享一个我用真金白银换来的避坑清单：

• 问题一：把评测分数当生产指标。模型在公开榜单上分数高，不代表在你的业务数据上好用，必须建自己的评测集；
• 问题二：忽略输出格式稳定性。自由生成的文本格式千奇百怪，解析起来非常痛苦，建议用约束生成或接入结构化输出；
• 问题三：不做内容安全过滤就直接上线。用户输入千变万化，模型可能被诱导输出不合适的内容，必须加入输入输出审查机制；
• 问题四：把敏感数据直接送进商用 API。哪怕是无意的，一旦数据被用于模型迭代，后续的合规隐患没法收拾；
• 问题五：低估持续维护成本。模型升级换代很快，今天部署的方案一年后就可能落伍，团队要预留模型迭代和迁移的预算。

每一条背后都是真实事故换来的教训。做技术和做业务的区别就在于，业务允许你试错，但技术上的错误可能在某个时间点集中爆发，而且后果不只是修复代码那么简单。

8. 面向开发者的下一步：提示词只是入口，系统设计才是关键

聊到这里，基本把大模型从原理到落地的关键环节过了一遍。如果你问我什么能力在未来两三年最值钱，我的答案不是"会写提示词"，而是"会设计一个以大模型为核心的稳健系统"。

提示词当然重要，它是你与模型交互的直接入口，很多时候一个精心设计的提示词比换一个更大的模型更有效。但提示词解决的是单次对话的质量，系统设计解决的是重复性、规模化、可靠性问题——如何管理上下文、如何从模型失误中恢复、如何控制成本峰值、如何评估输出质量、如何在模型版本升级之后保证业务不破裂。

我个人的学习路径是：先完整跑通一个本地模型的部署，熟悉推理、量化、显存占用这些基础概念；再做一个带 RAG 的知识问答应用，理解检索和生成的结合点；接着尝试一个最简单的 Agent，让模型调用外部工具完成任务；最后再回头研究微调和评测。每一步都有大量可复现的开源工具支撑，难度曲线是平缓的。

大模型领域的信息更新太快，任何人说自己"完全掌握"都是不现实的。真正可靠的方法论是：把基础原理吃透，然后以周为单位做小规模实验，用真实数据和真实场景验证认知。我在这个行业里见过太多被概念绕晕的团队，也见过不少靠着扎实工程把开源模型用到超出预期的案例。差距不在信息差，而在是否愿意动手、是否愿意为一个问题反复调试到稳定为止。

如果你正在做选型或者正准备搭建第一个大模型应用，我的建议很简单：从最小闭环开始，别贪大求全。先把一个环节跑通，再逐步扩展。大模型的能力随时可以调用，真正稀缺的是你对自己的业务场景足够深的理解，以及把模型能力稳定嵌进业务流程的那套工程手段。