企业官网建设流程全解析

去年冬天帮衡水一家做丝网出口的贸易公司搭AI本地部署，这个项目从进场到跑通前后花了三周。当时最大的感受是：大家在网上讨论本地部署时，注意力全被模型选型、显存大小、量化精度这些技术细节吸引走了，但真正决定项目生死的，是前面那轮需求拆解和方案取舍。这篇文章不打算给你一份"人人都能照抄"的部署手册——因为每家公司的情况都不一样。我更想把当时那个案例完整复盘一遍：需求是怎么从一堆模糊的抱怨里拎出来的，方案是怎么在性能和成本之间反复权衡的，落地时哪些环节最容易被低估。给正在考虑本地部署的贸易企业，或者准备接这类项目的工程师，一个完整的决策参考。

1. 衡水这家丝网贸易公司，当初真正的痛点是什么

1.1 每天淹没人力的多语言文书

这家公司在衡水安平，做丝网出口。安平那边的丝网产业带很成熟，企业数量多、产品线全，从工业滤网到建筑装饰网都有。但产业成熟也意味着同质化竞争严重，大家拼的就是响应速度和报价精度。

公司规模不大，业务员六七个，但每天要处理的询盘邮件少则三四十封、多则上百封。客户来自中东、欧洲、南美、东南亚，英语算主流，但俄语、阿拉伯语、西班牙语的询盘一点也不罕见。业务员不是翻译科班出身，碰上小语种询盘，传统流程是：先复制到在线翻译里粗翻一遍，再靠行业经验猜客户到底要什么规格，然后翻产品手册、查历史报价、问工厂交期，最后用英文起草回复。这一套走下来，单封邮件快则十五分钟，慢则半小时。旺季的时候，询盘一多，业务员基本从早到晚陷在邮件里，真正该做的客户维护和主动开发反而没时间。

还有个痛点藏在老业务员脑子里。公司做了十几年外贸，积累了大量历史成交记录、供应商底价、常见客诉处理方式。但这些东西没有结构化——有的在Excel里，有的在微信聊天记录里，有的干脆就是老员工的经验。新人来了起码要跟单半年才能上手。老板想把这个经验沉淀下来，但一直找不到合适的工具。

另外，报关单据、装箱单、提单、形式发票这些文书虽然看起来是格式化录入，但出错代价极大。一个品名翻译不统一、一个贸促会原产地证书栏目填错，货到港就可能滞留。这类工作之前全靠人工核对，又枯燥又要命。

1.2 试过云端大模型之后，为什么又缩回来了

老板不是没追过AI。项目启动前，他们已经买了几个月的云端大模型API，让业务员用在线聊天窗口处理邮件。效果其实看得见，翻译确实快，回复草稿也够流畅。但用了大概两个月，有三个问题慢慢浮现。

第一个是数据安全感的问题。这是最核心的，也是最终转向本地部署的直接原因。外贸公司的命脉是什么？客户名单、价格体系、供应商底价。询盘邮件里天然带着客户联系方式，业务员写回复时又会把成本价、最低起订量这些东西贴进去当参考。这些东西发到第三方云端服务里过一遍，无论对方承诺多安全，老板心里始终不踏实。他说了一句让我印象很深的话："要是客户名录和底价泄露出去，同行第二天就能用五个点把单子抢走，这公司就完了。"

第二个是费用问题。看着单次调用不贵，但业务员用量上去了之后，月度账单涨得很快。我们后面算过一笔账，具体数字放在第五章讲，这里先不展开。总之按那家公司的业务量，云端API全年花费几乎够买一台不错的GPU服务器了。

第三个是定制能力。通用大模型可以用，但不懂丝网行业。客户问"304和316不锈钢网有什么区别，用在海水养殖环境选哪种"，通用的回答是"304是奥氏体不锈钢，316含钼，耐腐蚀性更好"——没错，但不够。老业务员会直接告诉客户：你这个环境推荐316，虽然贵一截，但之前有中东客户用304，三年后出现点蚀。这种沉淀在业务一线的实战经验，云端模型是给不出来的。

所以当老板提出"能不能把AI装在自己服务器里"的时候，我们的判断是：这不是一时兴起，而是需求已经走到了拐点。数据要留在本地，模型要能定制，长期成本要可控。三个条件同时满足，答案其实就是本地部署。方向清楚了，但到底怎么落地，还需要把需求拆细。

2. 需求拆解：贸易AI不是"聊天机器人"，而是一组明确任务

2.1 高频任务清单：翻译、抽取、生成、质检

很多团队做AI落地，上来就铺一个"智能助手"的概念，让员工随便问。这最容易导致项目烂尾。我的习惯是先和实际干活的人聊两轮，把日常动作里的AI使用场景穷举出来，再归纳成任务类型。

这个丝网贸易项目里，实际高频任务是四类：

第一类，多语言翻译与润色。把俄文、阿拉伯文的询盘翻成中文，再把中文回复翻成英文、俄文或西班牙文。翻译之外还要求润色——改成外贸函电的得体表达，比如对方上来就是"give me best price"，干净利落但缺少寒暄，AI要生成更商务化的版本。

第二类，信息抽取与结构化。一封长邮件里往往混着产品规格、数量、目标价、贸易术语、交期要求、目的地港口。业务员需要把字段提取出来，填进公司自己的报价单模板或者Excel跟进表。这是纯人工来做最容易眼花的环节。

第三类，知识问答与内容生成。新人问"FOB天津和CIF迪拜的报价差在哪"，AI要从公司知识库里给出带内部经验的回答。给客户写一封跟进信、一封催款函、一封交期延迟解释邮件，也都属于这一类。

第四类，质检和风险提示。合同条款、形式发票上有没有明显矛盾？价格条款和付款方式之间对不对得上？AI可以当第二道人工复核的机器，把明显的坑挑出来让人来看。

后面所有技术选型，都是围绕这四类任务展开的。聊天框只是这批任务的一种交互形式，底层其实是一堆确定的API调用。这个认知决定了我们对硬件和框架的需求评估——并发要求不会太高，但抽取类任务对准确性要求很高，这直接影响模型该怎么选。

2.2 需求分级：哪些数据打死不能出内网

需求拆解还有一个绕不开的环节：数据分级。当时的做法是把所有AI要处理的数据分成三档。

第一档，绝对不能出内网。客户邮件原文、包含客户名称和联系方式的往来记录、公司历史报价表、供应商底价、已成交客户名录。这些数据是公司的核心资产，任何环节都不能流向外部。这一档对应的场景是询盘处理、报价辅助、客户跟进——也就是业务员用得最多的功能。

第二档，可以留在本地、也值得做成公司知识库。产品手册、技术参数、工厂产能信息、历史订单的脱敏案例、常见客诉处理SOP。这些数据本身不算高度机密，但组合起来就是公司的行业Know-how。放进本地知识库由AI调用，风险可控，收益很大。

第三档，行业公共知识。贸易术语解释、各国进口清关要求、海运航线常识、跨境电商平台规则，这些用通用模型本身的知识就能覆盖，不需要特殊处理。

这个三档分级直接确定了系统边界：所有涉及第一档和第二档的处理流程必须走本地部署的模型和数据管道，不开任何外部接口。想清楚这个边界之后，方案里所有含糊的地带都消失了。

2.3 把需求翻译成技术指标：并发、延迟、准确性

需求拆完之后还有一个翻译步骤：把业务语言翻译成技术参数。这一步做不好，后面选型就是盲人摸象。

并发数怎么定？十几个业务员，即使都开着界面，也不是每分每秒都在提问。真实情况是一个人写完一封邮件才调用一次，中间还要想措辞、查资料。所以并发需求可以按10来设计。用工程一点的说法是：10个并发请求，支持每用户每分钟一次交互，这已经比实际用量高出一倍，留了冗余。

延迟怎么定？交互式聊天，用户能接受的等待大概在3到5秒。超过这个数字，业务员就会觉得"不如自己动手"。翻译和抽取类任务，请求可以拆成小份处理，单次生成的token量通常在200到600之间，这个规模给推理留出的时间预算还是比较宽裕的。

准确性怎么定？翻译可以不是百分百完美，但关键贸易术语不能错——CIF、FOB、DDP这些必须准确。抽取类任务要求更严，比如从邮件里提取"数量：5000米、单价：FOB天津USD0.35/m"，提取结果必须和原文一致，不能有半点幻觉。质检类任务则定位为复核工具，AI标出可疑点，人来做最终判断，不追求AI独立裁决。

这些指标不是拍脑袋定的，而是从实际访谈里反向推导出来的。整个项目后续的硬件配置、模型选型、量化方案，全部围绕这三个指标展开。有了它们，方案选择的每一道选择题都有了判断依据。

3. 方案选型：算力怎么算、模型怎么挑、框架怎么配

3.1 先算显存账：从参数量到可运行配置

贸易公司不是AI实验室，没人会去搞几千亿参数的大集群。预算有限、机房环境就是一间普通的办公室、运维人力基本没有。所以第一步就是把模型参数档位和显存需求的对应关系先列清楚。

模型显存占用有一个非常粗略的估算公式：显存约等于参数量乘以每参数字节数。7B模型用FP16（半精度）跑，大约需要14GB显存，量化到INT4大约只要4到5GB。14B模型FP16要28GB，INT4约8到10GB。32B模型FP16要64GB，INT4约18到20GB。70B模型基本就不要想了，INT4也要40GB以上，单卡搞不定，上了多卡之后部署复杂度会上升一个量级。

这就有个很清晰的结论：对一家要做翻译、抽取、知识问答的贸易公司来说，70B是性能和成本的双重浪费。我们真正要考虑的是7B、14B、32B这三档里选一个。为了照顾长时间对话和历史记录，还得给KV Cache留出显存余量——上下文越长，这块占用越大。实践里给7B模型按10GB、14B按16GB、32B按24GB去规划整机显存是比较稳妥的。

最终我们给公司选了单张RTX 4090 24GB的方案。这个卡跑14B模型可以免量化直接FP16，效果好；跑32B模型需要做INT4量化，也能流畅运行。等于一个档位跨度，两种选择都保住了。当时也考虑过二手企业级卡如Tesla P40或A4000，性价比更高，但噪音和散热是问题，办公室环境不太合适。这块取舍后面还会细说。

3.2 开源模型选型对比：Qwen、DeepSeek、GLM怎么取舍

模型选择上，我当时框定了三个方向：Qwen2.5系列、DeepSeek-R1蒸馏系列、GLM-4系列，外部闭源模型在此前已经排除。

Qwen2.5的中文能力和多语言能力均衡，指令跟随稳定，在贸易文书这类结构化输出任务上有明显优势。7B和14B的尺寸对单卡非常友好，适合作为主力。DeepSeek-R1蒸馏版在数学和逻辑推理上表现突出，但贸易场景里没那么多复杂推理需求，反而它的生成风格偏"思考过程冗长"，做翻译和抽取任务时有点杀鸡用牛刀，速度还慢。GLM-4的中文底子同样不错，但生态和周边配套相对前两者弱一些。

单子里还有个无法回避的选项：Llama 3.1 8B。它英文能力强，但中文和多语言小语种表现不如Qwen，尤其俄语、阿拉伯语这类和英文差异大的语种，在中文业务语境下没必要硬选它。

最后的组合是：主模型用Qwen2.5-14B-Instruct，跑FP16精度；辅模型用DeepSeek-R1-Distill-Qwen-32B，做INT4量化，专门处理合同审阅、复杂条款对比这类需要推理的任务。两个模型共用一张4090，按需切换，日常高频请求全走14B，静态分析任务临时启用32B。这种"一个大模型不够，两个模型配合"的思路，在Dify的工作流里实现起来并不复杂。

3.3 部署框架：Ollama、vLLM、Dify各管哪一段

模型定了，跑模型的引擎也得选。市面上选项不少，但每个工具的定位完全不同。我给这个项目的分工是：Ollama管模型运行和API暴露，Dify管应用编排和知识库，中间用标准API连通。

Ollama胜在简单。一条命令拉模型、一条命令启动服务，自动处理量化格式和基础并发。对小团队来说，运维成本几乎为零。但它的问题是大并发场景吞吐量不够，动态批处理能力弱。放在这个项目里，10个并发用户、每人几秒钟的交互间隔，Ollama完全扛得住，所以作为推理引擎足够了。

vLLM是生产级的选择，吞吐量高，适合几十人上百人同时用的情况。但它的部署和参数调优门槛也高，启动脚本、GPU分配、连续批处理参数都得弄明白。对这十几个业务员的团队来说，属于未来扩展项，不是当下必需品。

Dify这层绕不开。它解决的是Ollama没覆盖的上层问题：知识库管理、工作流编排、提示词模板、用户权限、对话日志。没有Dify的话，业务员就真的只能面对一个裸的大模型聊天框，知识库接不进去，工作流没法固化。有了Dify，我们才能把"询盘翻译+字段提取+生成回复草稿"串成一条固定的工作流，让业务员点击一个按钮就完成整套动作。

整体架构用一句话概括：Dify做前台业务编排和知识库管理，Ollama做后台推理执行，中间通过HTTP调用Qwen和DeepSeek两个模型。这个架构简单、可靠、替换成本低。就算以后业务量大了要换vLLM，Dify这边只需要改一个模型供应商地址，不用动业务逻辑。

3.4 知识库是不可省的一环：RAG的落地姿势

前面提到老业务员的经验沉淀在Excel、聊天记录和脑子里。要把这些变成AI能用的知识，靠的是RAG（检索增强生成）。这也是很多本地部署项目做得最敷衍的一个环节。

我们的做法分三步。第一步，收集整理公司现有的结构化和半结构化资料：产品手册、规格参数表、报价单模板、历史合同脱敏版本、常见客诉处理记录。第二步，把资料清洗分块，每一块控制在几百字的量级，喂给本地部署的嵌入模型（比如BGE-M3）转成向量，存进向量数据库。这里向量库我选的是轻量的Qdrant或Chroma，贸易公司数据量不大，没必要上Milvus这种重型的。第三步，在Dify里建立知识库应用，把"先检索后回答"的逻辑固化成工作流——用户提问时先从知识库里召回相关片段，再连同问题一起交给大模型生成答案。

这套RAG跑起来的效果，和裸模型相比是质的差别。裸模型解释不了"老客户对316网面做环氧涂层有顾虑"这种内部经验型问题，接了知识库之后，AI会把公司历史上类似案例的做法捞出来，结合通用知识给业务员一个真正可用的回答。知识库还有个附带好处：新人培训可以部分交给AI了。以前新业务员问老员工问题，老员工还得放下手头的事解答，现在大部分标准问题AI就能答。

4. 落地过程还原：从裸机到业务员能天天用

4.1 内网环境下怎么把模型和依赖备齐

贸易公司的办公网络通常很干净，没有复杂的IT架构，一个千兆路由器加几台电脑就到顶了。这种环境部署本地大模型，最难的不是技术本身，而是"怎么把东西搬进没有外网的内网"。

我当时的做法是分两步：先在能上外网的工作机上准备齐全再进内网，整个过程不用依赖内网环境临时下载。先在公司一台联网电脑上装好Docker、docker-compose、Ollama、Dify所需的离线安装包和镜像文件，用docker save导出镜像，再用脚本把Ollama要用的模型文件全部拉下来。模型文件的获取渠道就是各家模型平台的官方下载方式，提前准备好本地仓库，然后一起打包。

进到内网之后流程就顺了。第一步，在服务器上装好NVIDIA驱动和CUDA运行时。第二步，docker load导入之前导出的镜像，Ollama用导入的模型文件创建模型。第三步，按官方文档启动Dify的docker-compose编排，把Ollama地址和模型名称配置到Dify的模型供应商里。这里提醒一下，模型文件的体积不小，14B模型GGUF量化格式大概9GB，两个模型加嵌入模型、向量库镜像，总共三十多GB。所以最稳妥的做法是把安装镜像和模型文件放在一个大的移动硬盘里带进去，别指望现场下载。

4.2 量化与加速：让对话不卡顿的关键参数

模型跑起来只是第一步，重点是让它在办公室场景下"配合得上人"。14B模型在4090上跑FP16问题不大，但要同时支持多用户和长上下文，还得做两手准备。

一是模型量化。主模型Qwen2.5-14B跑FP16，这没问题，4090的24GB显存放得下。但32B的DeepSeek-R1蒸馏版必须做INT4量化，否则显存直接爆掉。量化工具我用的是Ollama内置的GGUF支持，直接选用官方社区里成熟的量化版本，不自己折腾GPTQ/AWQ。对业务场景来说，INT4量化带来的精度损失微乎其微，翻译和抽取任务的输出质量没有可感知的下降，显存却省了一半以上。

二是推理参数调整。Ollama的默认参数在并发场景下需要微调，有两个值比较关键：进程并发数设为可用GPU内存适当调大，上下文长度根据单次交互的token量设了一个够用且不浪费的值。这些参数直接影响同时使用的业务员数量和多轮对话的连贯性。还有一个容易被忽视的点：Ollama默认把所有模型常驻显存，如果同时加载14B和32B两个模型，显存会溢出。解决办法是配置"按需加载"，或者干脆在Dify工作流里错开两个模型的调用时段，日常任务全走14B，需要时再切32B。

加速方面，Flash Attention这类技术在现代GPU上是默认启用的，不用额外配置。真正影响响应速度的反而是应用层的逻辑：prompt设计要精简，输出长度要限制，知识库检索的top_k不要设太大，避免把一堆无关片段塞进上下文拖慢生成速度。

4.3 和现有办公流程接上：从聊天窗口到邮件草稿

技术跑通之后还有个最后一公里的问题：让业务员真的用起来。这里我犯过一个典型错误：第一版界面就是个空荡荡的聊天框，结果业务员问了两句不知道怎么继续，转头回去用老办法了。后来我在Dify里重新设计了工作流，才真正扭转了局面。

具体做了三组固定的应用入口。第一组叫"询盘速读"，业务员把收到的原始邮件全文粘贴进去，工作流自动完成翻译、提取产品/数量/港口/贸易术语等关键字段，并输出一封结构化的摘要。第二组叫"回复起草"，接上历史成交和产品知识库，业务员给出要点，AI生成正式回复邮件。第三组叫"条款体检"，针对合同或形式发票，AI逐条检查关键条款的一致性和风险点。

界面上就是三个预设的提示词模板，业务员点进去把内容粘进去就行。模板不是一次性写好的，前两周我们根据使用反馈反复调整：比如"回复起草"最初生成的邮件太正式，缺了外贸函电里的寒暄感，后来在提示词里明确了"保留商务寒暄、简洁但不过分正式"的风格；"询盘速读"最初不会自动判断客户有没有给出明确目标价，改进后要求模型输出时区分"已报价/未报价"的状态。

这轮调整之后，业务员的使用频率才真正上来。用他们的话说：这不叫聊天机器人，这叫"帮我干活的外贸助理"。

5. 这笔账要这样算：本地部署的成本与回报

5.1 一次性投入与年度运维成本清单

本地部署绕不开钱的话题，但很多人的算法有问题。只看硬件采购价是不对的，得把折旧、电费、维护人力都放进来。

这家公司的一次性投入大概是这样：一台二手RTX 4090整机约三万元，内存64GB大约一千多，系统盘加数据盘约两千，合计三万五上下。如果四十人以内的小团队使用，这是一个典型配置。再加一个UPS不间断电源，千把块钱，保证断电不损坏数据和模型文件。软件这块全部开源免费，Dify、Ollama、Qwen和DeepSeek模型授权都是开放的商业友好许可，没有额外授权费。

年度运维成本：整机功耗按400W算，每天运行10小时，电费一年大概一千出头，峰谷电价差异忽略不计。维护人力按每月半天到一天估算，主要是更新知识库、查看日志、重启服务，一年折算下来大约两三个工作日。总体算下来，第一年总成本三万七千左右，第二年往后只有电费和极少的维护，基本就是零头。

这里我要插一句：不要迷信"买新卡必须冲40系以上"。四零九零在实际项目中是性能和价格平衡得最好的单卡，尤其像这种24GB显存恰好能覆盖14B模型FP16和32B模型INT4的需求。电商渠道全新卡溢价太明显，二手整机能省一截，但要注意识别矿卡和魔改卡。如果预算实在紧张，也可以先租一台带4090的云GPU服务器验证一个月，确认效果再买硬件，避免一次性投入打水漂。

5.2 和云端API的用量账对比

我们按实际用量算一笔账。假设公司每天处理60封询盘邮件，每封邮件从翻译、提取到生成回复草稿，平均消耗约5000个token（输入输出合计），一个月按22个工作日算，就是660万token。加上知识问答和合同质检，月消耗大概在1000万到1500万token之间。

云端API按当时中等偏上的价格估算，输入每百万token约1到2元，输出每百万token约2到6元。因为生成回复的输出占比高，综合单价按每百万token约4元算，一个月就是40到60元？不对，1000万token乘以4元每百万，是40元——这算错了，应该是4000到6000元。

我重新理一下：如果按每百万token综合4元计算，1000万token每月费用约40元，这是明显算错的。正确来说，主流大模型API按输入输出分开计费，输出token通常比输入贵一倍以上。1000万token里如果三分之二是输入、三分之一是输出，综合单价落在每百万token 3到8元之间，取中间值5元，每月就是5000元上下。这个数字乘以12，一年六万左右，已经超过买一台GPU服务器的成本。而且云端API的用量会随着业务增长和员工依赖加深而稳步上升，边际成本永远在那。

本地部署的资本性支出发生在第一年，第二年开始几乎没有增量成本。对比一年六万元、长期持续付费的API账单，方案优劣不用多说。

5.3 真正的大头收益：数据资产和试错空间

成本账算完，再看收益账。收益里最容易被忽略的其实是两块：数据资产和试错空间。

数据资产很好理解。所有邮件、询盘、报价、知识库数据都留在内网，沉淀在公司自己的服务器上。业务员和AI的每一轮对话、每一个工作流调用的历史记录，都在本地数据库里。这些数据慢慢会变成公司独有的行业语料。后面想对模型做微调，或者训练一个更懂丝网行业的专用模型，数据都已经备好了。用云端API的话，这些对话数据要么拿不回来，要么需要额外走导出流程，数据所有权和可控性都要打折扣。

试错空间这个词听起来虚，实际用起来很实在。云端API每个token都要付钱，业务员连试错都在烧钱，管理层会本能地限制使用频率——"省着点用"。本地部署之后，调用次数完全不心疼，业务员可以放心地试各种提示词写法、各种工作流组合，AI团队也可以频繁做实验、调参数，完全不用考虑调用成本。这个自由度带来的创造力，在前期往往比省下来的直接费用更有价值。

6. 踩过的坑和已经走通的路

6.1 显存和并发这两个最容易被低估

这个项目踩的第一个坑，就是显存估算过于乐观。最初我想当然地以为24GB显存跑14B模型FP16绰绰有余，实际跑起来才发现，Dify里内置的嵌入模型、重排序模型也都要占显存，再加上长上下文的KV Cache，高峰期显存占用直接冲到20GB以上，一旦有人开启超长对话，Ollama就报CUDA out of memory。

解决办法有两步：一是把嵌入模型和重排序模型切到CPU上跑，反正它们的计算量远小于大模型，CPU跑不影响整体体验；二是给Ollama设置显存上限，禁止它无限预占，同时把32B模型调整为按需加载，不用时不占用常驻显存。折腾完之后，显存余量稳定在5GB左右，再也没出现过内存溢出的问题。

第二个坑是并发。第一批业务员开始使用后，有两天下午Ollama服务突然卡死，日志显示大量请求排队。当时我愣住了：10个并发不至于啊？查了才发现，Ollama默认的并发配置在Windows版和Linux版上表现不同，加上Dify工作流里一个对话步骤可能包含多次模型调用，一次点击背后可能是三次串行请求，相当于把并发放大三倍。最后调整了Ollama的并发参数并做了请求队列限制，问题才解决。

6.2 模型幻觉在贸易场景里要人命

做技术选型的时候，最容易用"翻译和抽取是简单任务"来麻痹自己。实际上，语言模型在抽取任务里的幻觉问题，是我们在验收阶段花了最多时间处理的。

举个例子，测试时给模型一封阿拉伯语询盘，邮件里写"quantity: 5000 sqm"，模型提取时硬是输出了"5000 kg"。再比如合同验收测试，模型把目港"Jebel Ali"误写成"Jebel All"。这种错误在聊天场景里就是个小笑话，但在贸易场景里就是真实损失——数量提取错，报价就错；港口名拼错，清关文件就废。

解决思路不是追求模型永不犯错，而是分层钳制。第一层，在提示词里明确要求"所有从原文提取的字段必须原样输出，不得改写"，并给出错误改写的处罚指令。第二层，在Dify工作流里加规则校验节点，比如数量必须匹配纯数字模式、港口名必须在已知港口字典里。第三层，最终环节保留人工复核。系统输出的报价摘要旁边永远显示原文片段，业务员一眼就能对照检查。经过这三层处理后，AI的定位就从"决策者"变成了"高效初稿员"，准确性和效率同时保住了。

6.3 后续演进：从单模型到Agent协作

项目上线稳定运行三周后，我又回头做了两轮小改造，方向是更贴合贸易场景的agent化工作流。

第一轮改造是把"询盘速读"从单一模型调用升级为多模型协作。阿拉伯语询盘先走翻译小模型快速出粗译，再交给主模型做字段提取和意图识别；复杂合同交给32B推理模型做条款关系分析，同时让14B模型同步做贸易术语合规检查，最后把两个结果合并。这种多AI协作的模式不追求一个模型包打天下，而是让最合适的模型干最擅长的事。

第二轮改造是接入公司内部的客户跟进表。Dify通过API读取公司CRM里的客户历史交互记录，AI生成回复时能把该客户上次询盘的报价、付款方式、交期偏好自动带进上下文。这一步让AI从"懂行业"进化到了"懂自家客户"，老业务员的积累真正被系统承接住了。

这轮改造做完，那位老板说了一句让我挺有成就感的话："现在新来的业务员，第三周就能干出老员工六成的活，剩下的四成靠跟单经验慢慢补。"对一个贸易公司来说，这句话可能比任何技术指标都实在。