企业官网建设流程全解析

大模型喊了两年多，现在最常被问的问题不是“能力有多强”，而是“到底能在哪儿真赚钱、真提效”。我陆续参与过几个行业的落地项目，也看过不少失败的案例，这里把金融、医疗、教育、制造这四个典型行业的落地实践拆开来讲。这四行覆盖了“强合规”、“强隐私”、“强个性化”、“强流程”四种截然不同的业务形态，正好能说明大模型落地的通用方法和差异化细节。无论你是想了解行业AI怎么搞的小白，还是要动手写代码的工程师，这篇都能给到可直接参考的思路和操作。

内容会沿着一条主线展开：每个行业先讲清楚业务逻辑，再给技术选型思路，最后落到可复现的实操案例。案例都会给到提示词模板和简单的代码片段，照着改一改就能跑通Demo。至于那些只讲概念不给步骤的文章，看完你还是不知道从哪里下手，这篇不会那样写。

1. 大模型行业落地，先想清楚这几件事

很多项目翻车，不是模型不够强，而是从一开始就没想清楚“到底要解决谁的问题”。行业落地的第一步不是选模型，而是把业务问题翻译成技术问题。

1.1 为什么偏偏是这四个行业

金融、医疗、教育、制造，这四行有个共同特点：数据密度高、重复性脑力劳动多、单次错误代价大。这意味着大模型带来的自动化收益非常明显，同时也意味着对准确率、可解释性和安全性的要求极高。

• 金融：合同、财报、研报、客服会话，全是文本，天然适合语言模型处理，但要严格控制合规风险。
• 医疗：病历、文献、检查报告，信息密度极大，结构化之后能直接提升诊疗和研究效率，但隐私红线不能碰。
• 教育：答疑、批改、备课，本质上是大规模的一对一服务，大模型能把边际成本打下来，但内容正确性必须兜底。
• 制造：设备手册、维修记录、质检报告散落在老师傅脑子里和文档里，大模型能把经验资产化，但要接得住工业现场的脏数据。

选这四个行业还有一个现实的理由：它们的数据形态以中文文本为主，微调、检索增强、提示工程这几条主流技术路线都能用得上。你要是非选一个纯视频理解的场景，那难度一下就上去了，不适合作为入门拆解对象。

1.2 落地三步走：需求、数据、评估

不管哪个行业，我建议都按这个顺序推：

1. 找场景：画一条业务流程，找到“花时间最多、出错最心疼、规则最清晰”的环节。比如银行的信贷审批，客户经理花大量时间看流水和合同，这个环节就适合用大模型做初审辅助。
2. 备数据：把场景相关的历史数据、文档、问答对整理出来。不需要一上来就搞“大数据”，但一定要有几十到几百条高质量的种子数据，用来做效果验证。
3. 定评估：在动手之前就定义“什么叫做好”。比如合同抽取任务，字段准确率要到99%才能上线，还是95%就能辅助人工？这个标准决定你要用多大的模型、要不要上RAG、要不要做微调。

很多团队上来就调API、跑Demo，看起来效果惊艳，但一问“这个错误率能接受吗？”，答不上来。这就是没把评估前置。

1.3 技术栈怎么选：RAG、微调还是纯提示词

这里给一个经验法则：

• 纯提示词：任务简单、规则明确、数据量小，比如“把这段文本里的日期提取出来”，直接用大模型API加提示词，成本最低。
• RAG（检索增强生成）：知识需要实时更新、答案需要引用来源、数据量大且分散，比如“根据公司制度回答员工问题”，几乎必选RAG。
• 微调：要求固定输出格式、特定领域语气、私有知识固化，比如“把病历转成结构化JSON”，微调比长提示词更稳，但需要数据准备和训练成本。

实际项目里，RAG和微调经常结合使用。我见过一个医疗项目，先用微调让模型学会输出严谨的医学术语，再外挂一个检索模块拉取最新的用药指南，效果比单独用一种好很多。

2. 金融行业：合规压力下的智能风控与文档处理

金融行业的文本处理需求极其旺盛，但它又是对“胡说八道”容忍度最低的行业。所以金融落地的基本策略是：用大模型做“阅读理解”和“信息抽取”，而不是让大模型直接做“判断”和“决策”。

2.1 金融场景选型：为什么RAG是绝对主力

银行、保险、券商每天都在处理什么？客户尽职调查报告、信贷审批材料、保险合同条款、监管政策文件。这些文档的特点是：篇幅长、版本多、更新频繁。如果靠人工读，一份几十页的授信报告要花半天，而且不同人读出来的重点还会不一样。

RAG在这种场景下几乎是唯一解。因为监管文件和内部制度必须引用原文，不能凭空生成。你问模型“这笔贷款的最高额度是多少”，它需要先去向量库里检索到对应制度条款，再基于检索结果回答，并且给出处。这样审计的时候能追溯，出了问题也能定位。

我实践下来，金融RAG项目的关键不在检索器，而在文档解析。PDF里的表格、扫描件里的印章、Word里的修订痕迹，这些都会把切块环节搞崩。所以第一步一定是把PDF转成带版面信息的文本，表格区域单独处理，再按段落和标题层级切块。

2.2 实操案例：合同关键信息抽取与质检

给你一个可以直接跑的思路。假设要抽取采购合同里的“合同编号、甲方、乙方、金额、付款条件、违约责任”。

第一步，设计输出格式，固定成JSON（JavaScript对象简谱），方便下游系统处理。提示词模板可以这样写：

你是一个合同审核助手。请从以下合同文本中抽取指定字段，严格按照JSON格式输出，不要输出任何多余内容。 字段列表： - contract_id：合同编号 - party_a：甲方全称 - party_b：乙方全称 - amount：合同总金额（数字，单位万元） - payment_terms：付款条件 - liability：违约责任 合同文本： {合同内容切片} 输出JSON：

第二步，因为合同可能很长，不能整个塞进上下文，需要先切片。简单做法是按页码切，每页一个文本块，逐块调用模型抽取，最后合并。如果字段被跨页拆分，合并时要做简单拼接，或者用一个“第二轮校验”的提示词检查字段完整性。

第三步，加一道“质检”环节。用一个更便宜的小模型或者规则脚本检查抽取结果：金额是不是数字、日期格式对不对、必填字段有没有为空。这一道防线能把错误率再压下去一个数量级。

我遇到过一个很隐蔽的问题：合同里甲方是“某某有限公司（以下简称“A公司”）”，后面正文全用“A公司”简称。模型抽出来的是“A公司”，而不是全称。解决办法是在提示词里加一句“若出现简称，请以第一次出现的全称为准”，或者用文本预处理把简称替换成全称。

2.3 金融落地避坑：幻觉与合规红线

金融场景最怕模型一本正经地编造条款。解决办法有三层：

• 第一层：凡是涉及金额、日期、主体的字段，一律用RAG或规则校验，不依赖模型记忆。
• 第二层：模型回答必须带引用来源，比如“根据《某某办法》第X条”，没有来源不展示。
• 第三层：对生成内容做分类，高风险判断（比如“建议拒绝这笔贷款”）不交给大模型，只让它做资料提取和初筛标记，最终决策由人完成。

合规方面还有一条硬规矩：敏感数据不能出内网。所以金融项目即使调云上API，也要先做脱敏，把客户姓名、身份证号替换成占位符，输出后再映射回来。更稳妥的做法是直接用私有化部署的开源模型，后面制造行业部分我再细说部署方式。

3. 医疗健康行业：隐私约束下的病历结构化与辅助决策

医疗行业的数据壁垒比金融还高，而且数据质量是公认的“脏”。电子病历里充满了中英文混杂、缩写、错别字和不规范表述。但正是这种混乱，让大模型的价值格外突出。

3.1 医疗数据的特殊性与应对策略

医疗数据有三座大山：隐私合规、术语复杂、责任归属。

隐私合规意味着绝大多数数据不能出医院。所以医疗项目首选“本地化部署”，要么用开源模型跑在内网GPU服务器上，要么直接用医院的算力平台。云端API方案几乎不可行，除非做严格的去标识化处理，而且还得过伦理审批。

术语复杂意味着通用模型直接拿来用效果不好。“心悸”“心慌”“胸闷”在临床上可能是不同的描述，但都指向心脏问题。所以需要构建一个科室级的术语词典，配合提示词让模型“基于词典映射术语”，而不是凭常识理解。

责任归属意味着模型输出只能是“辅助”，不能是“结论”。医生需要看到原始病历里哪句支持这个判断。所以医疗项目的输出格式必须设计成“原文引用+结构化字段”成对出现。

3.2 实操案例：用大模型把出院小结转成结构化数据

场景很典型：医院每天要处理大量出院小结，人工录入摘要费时费力。用大模型可以自动转成结构化JSON，直接进入科研数据库。

提示词可以这样设计：

你是病案室编码助手。请从出院小结中提取信息，输出严格JSON，字段名固定。所有诊断术语请对照ICD-10编码，无法确定时置为null，不要猜测。 字段： - admission_date（入院日期） - discharge_date（出院日期） - diagnosis（诊断列表，每项包含term和icd10） - surgery（手术/操作列表，每项包含name和icd9cm） - discharge_status（离院方式：医嘱离院/转院/死亡） - discharge_advice（出院医嘱，原文摘录） 出院小结文本： {文本} JSON输出：

实际操作中要注意，ICD-10编码不能靠模型硬编，因为编码规则太复杂，经常需要查询编码库。我的做法是：先让模型抽出诊断术语，再用术语去本地编码库模糊匹配，匹配不上再让模型根据上下文给一个候选列表，由人工确认。准确率比直接让模型给编码高不少。

3.3 落地约束：本地化部署的工程细节

如果医院要求内网部署，通常在单台或两台GPU服务器上跑推理。推荐选7B到14B参数量的开源模型，量化后显存占用在16GB到24GB之间，单张主流显卡就能跑。

部署时注意几个坑：

• 量化精度：医疗场景尽量用INT8或FP16，不要用INT4，诊断术语容易在低精度下变形。
• 并发控制：用线程池或消息队列做请求排队，不然几个医生同时用，GPU会直接OOM（显存溢出）。
• 日志审计：所有输入输出都要落日志，保留至少180天，这是医疗合规的硬要求。

我之前在一个模拟项目里用FP16跑13B模型，单卡能支持4到6个并发问答，响应时间在3秒左右，临床医生基本能接受。如果并发要求更高，就用vLLM这类推理框架做Continuous Batching，吞吐能翻两三倍。

4. 教育行业：大规模个性化答疑的性价比方案

教育场景的特点是“用户量大、问题重复度高、个性化要求强”。一个老师面对几十个学生，课后答疑根本忙不过来；而学生的提问里，约70%都是反复出现的共性问题。大模型最适合做这种事：把老师从重复劳动里解放出来。

4.1 教育场景怎么拆：答疑、批改、备课三件套

答疑是最好切入的。把课程讲义、教材、往年题库导入知识库，学生提问时先检索相关资料，再生成答案。生成时还要带着“引导性”，不能直接给答案，要分步骤提示，培养学生思考能力。

批改场景稍微难一点，尤其是主观题。我的建议是不要追求全自动批改，而是让大模型先做“预批改”，给出得分点和修改建议，老师只需要确认和微调。这样批改效率能提升一半以上。

备课场景经常被忽视，其实价值很大。老师输入“高中数学，函数的单调性，45分钟教案”，大模型能生成教学目标、重难点、例题、课堂互动问题。很多老师实测下来，备课时间能从三小时压缩到一小时。

4.2 实操案例：做一个基于RAG的课程助教机器人

这是最经典的教育落地项目。技术栈可以直接抄作业：

• 数据层：用PDFLoader或者MarkdownLoader把讲义转成文本，按标题层级切块，每个块控制在200到500字，重叠50字。
• 向量化：用开源的嵌入模型（比如中文文本向量模型）把块转成向量，存入向量数据库。
• 生成层：用户提问后，先从向量库召回Top-K块，把参考资料拼到Prompt里，让大模型基于资料回答。
• 交互层：用Gradio或者Streamlit包一个网页聊天窗口，方便老师和学生测试。

关键提示词模板：

你是{课程名}助教。请根据以下讲义内容回答学生问题。 要求： 1. 只使用讲义内容作答，讲义中没有的信息请明确说“当前资料未涉及”。 2. 回答分步骤，先给思路提示，再给详细解答。 3. 数学公式用LaTeX格式输出。 讲义内容： {检索到的内容} 学生问题： {question}

这个方案里最容易出问题的是检索质量。讲义里同一个概念可能在不同章节出现，比如“导数”既是数学概念，也是金融术语。解决方法是给每个知识块打标签，检索时先按课程名过滤，再按语义相似度排序，相关性会好很多。

4.3 知钱误区：别让模型直接给答案，要设计“苏格拉底式”引导

教育跟其他行业最大的不一样，是“答对”不等于“教好”。直接给答案会让学生失去思考过程。所以我在Prompt里专门加了一条“先给思路提示，再给详细解答”，有时还要配一个“反问”分支：如果学生问的是简单概念题，模型先反问“你觉得这个概念和之前学过的哪个知识相关？”。

这个设计实测下来，学生满意度反而更高。原因很简单，学生要的是“学会”，不是“抄到答案”。如果只是做一个答案生成器，那和搜索引擎没什么区别，也体现不出大模型的独特优势。

5. 制造业：知识库检索与缺陷分析的长尾价值

制造业听起来跟“大模型”不搭界，实际跑一圈就会发现，它是被严重低估的场景。工厂里不缺自动化设备，缺的是能把老师傅经验留下来、能把产品缺陷原因快速找出来的“老师傅AI”。

5.1 制造场景的痛点：经验沉淀难、故障排查慢、质检标准不一

制造企业最常见的痛点是：关键设备坏了，老师傅能听声音判断故障位置，但要等老师傅到场，而且他明年可能就退休了。设备维修手册有几百页，操作工翻半天也找不到对应故障码的处理办法。

这些问题的本质是“非结构化经验没有数字化”。老师傅的口诀、维修笔记、故障案例，全散落在纸面上。大模型能把这些东西变成可检索、可问答的知识库，相当于给工厂装了一个“永不退休的老师傅”。

质检环节也有大模型的应用空间。虽然工业质检主要靠视觉模型，但缺陷描述和归因分析是文本活。比如“表面出现条纹，发生在温度偏高时”，大模型可以把这些记录做聚类，找出缺陷和工艺参数的潜在关联。

5.2 实操案例：设备维修知识库问答系统

制造业知识库项目和前几个行业的RAG项目本质一样，但数据预处理有特殊之处。

维修手册通常是PDF，而且很多是扫描件。扫描件必须先做OCR（光学字符识别），推荐用PaddleOCR这类开源工具，识别表格效果比通用OCR好。识别完后要人工抽检几页，确认准确率在95%以上再做切片。

切片的时候不能按固定字数切。维修手册的“故障码”和“操作步骤”经常在一个表格里，固定字数会把表格拆碎。我建议先按表格和标题解析成结构化块，表格整体作为一块，文本段落单独切块。检索时对表格块和文本块加权，表格块的权重可以调高一点，因为故障码查询基本都落在表格里。

Prompt模板可以这样设计：

你是设备维修助手。请根据维修知识库内容回答： - 故障现象：{user_query} - 如果知识库有明确处理步骤，按步骤列出，并标注对应页码或章节。 - 如果知识库没有相关信息，请回复“知识库暂无此故障的处理记录，请上报工程师”。 - 不要编造操作步骤，涉及安全操作时提示“请先断电并佩戴防护装备”。 参考资料： {检索内容}

这里“不要编造”约束比金融场景还重要。维修操作出错可能会导致设备损坏甚至人身伤害，所以宁可答不上来，也不能瞎编。我甚至建议在代码里加一个逻辑：如果检索到的知识块与问题的相似度低于阈值，直接返回“暂无答案”，不调用生成模型。

5.3 工业知识多模态化：从文本问答到“拍个照问一嘴”

制造场景里，老师傅判断故障往往要“看一眼”。纯文本知识库覆盖不了这种情况。好在现在多模态大模型能接受图片输入，可以让工人拍一张设备照片，问“这个部位有油渍，可能是什么问题？”

实现方式很简单：接入支持图片输入的大模型API，提示词里把图片和问题一起传过去。但考虑到工厂网络和内网数据约束，更落地的做法是在端侧跑一个小模型做初步分类，只把低置信度的图片传到服务器上让大模型分析。这样既控制成本，又避免敏感工艺数据外传。

多模态的准确率现在还做不到完全替代老师傅，但作为“辅助排查工具”已经足够了。它能提供几个可能性方向，让维修工缩小排查范围，实际效果非常明显。

6. 落地避坑指南：模型选型、数据、评测与成本

最后这部分算是通用经验，前面几个行业里反复踩坑的总结。无论你做哪个方向，这几条都能帮你少走弯路。

6.1 模型选型：开源还是API，别只看效果

现在很多人一上来就选中型或大型闭源API，效果好，但行业落地往往不是效果单变量决策。

如果数据不能出域，或者预算有限且推理量巨大，那就选开源模型本地部署。7B到14B参数是行业落地的黄金区间，微调成本低、推理速度快，配合RAG在大多数业务场景里都够用。

如果需求是复杂推理、长文本理解、超强指令遵循，而且数据合规允许上云，那就选大参数API。用API时要做好Prompt版本管理和结果缓存，不然成本会失控。

我的经验是：先用API跑通效果，确认业务价值后再决定是否本地化。不要一上来就买GPU服务器，先用云服务验证。

6.2 数据飞轮怎么建：从种子数据到持续迭代

大模型项目的效果天花板不在模型，而在数据质量。最开始没有用户反馈时，需要人工标注几十条“标准答案”作为种子数据，用来调Prompt。上线后，要把用户的问题、模型回答、用户是否满意记录下来，每周人工抽看一批不满意样本，把坏case补充到评测集里。

评测集是生命线。每个行业项目都要建一个固定的评测集，包含至少100条典型问题。每次改Prompt、换模型、调检索参数，都用同一套评测集跑分，对比前后效果。没有评测集，所有优化都靠感觉，没法判断是进步还是退步。

评测方式可以分两级：

• 自动评测：用大模型当裁判，对答案的相关性、完整性、忠实度打分，速度快，能覆盖大部分case。
• 人工抽检：每周抽20条，由业务专家看，专门抓自动评测发现不了的语义错误。

6.3 成本控制的土办法

大模型落地项目做到后期，成本大头不是训练，而是推理。几个亲测有效的省钱手段：

• 缓存：常见问题直接存答案，命中后不再调用模型。很多教育项目和客服项目，缓存命中率能到30%以上。
• 模型分级：先用小模型处理简单问题，小模型置信度低时再升级到大模型。这个“级联”策略能省一半推理成本。
• Prompt瘦身：把固定不变的长指令放进System Prompt，用户查询只保留关键词，减少输入Token。
• 批量处理：离线任务（比如历史合同抽取）用异步批量处理，别用实时接口，价钱能差三四倍。

6.4 组织层面：业务方和技术方怎么对齐预期

最后说一个容易被忽视的坑。行业落地失败，很多是因为业务方期待“AI全自动完成”，技术方交付了“AI辅助人工”。这个预期落差必须在一开始就对齐。

我的做法是：正式启动前，先做一次一周的“效果验证”，拿真实数据跑几十条，让业务方亲眼看到正确案例和错误案例，一起定“可接受错误率”。这个指标一旦定下来，后面所有工作都有方向。否则你辛辛苦苦把准确率做到95%，业务方盯着那5%的错误说“不能用”，项目就黄了。

根据我个人经验，行业落地的第一准则不是“模型越大越好”，而是“场景选小、数据选精、评测选硬”。与其铺一个大而全的中台，不如先解决一个每天让人头疼的小问题。你做出第一个被业务同事主动使用的工具，后面所有资源都会向你倾斜。这一步走通，大模型才算真正在你所在的行业扎下根。