企业官网建设流程全解析

过去这一周，生成式AI圈里的信息量不小。网信办发布了新一批生成式AI算法备案清单，把一个原本只停留在“听说要备案”的环节，变成了可以公开检索、对照自查的明确条目；同一时间，腾讯没有跟风再发一个类ChatGPT的对话玩具，而是直接把行业大模型摆上台面。这两条消息放在一起看，恰好勾勒出大模型从“能聊天”走向“能干活”的转折轨迹。这篇周报式的记录，会围绕备案清单到底备了什么、腾讯为什么选行业侧、以及这周热搜词背后开发者的真实需求展开，给正在做AI应用的产品、研发和技术决策者一些参考。

1. 算法备案清单公开之后，开发者该做什么准备

先说结论：备案清单这件事，不是法务单独扛的活儿，它会直接反推到你的数据管道、模型版本管理和线上日志设计。这周我看完公开信息后，第一反应是赶紧把自己手头的AI项目按清单字段过了一遍，结果发现有两处数据来源说明根本写不清楚。这个自查动作，建议所有做生成式AI服务的人都做一遍。

1.1 清单公布的字段，相当于给算法写了一份“说明书”

先回答最基础的问题：这份备案清单上是些什么信息。

从公开公示形式看，生成式AI算法备案信息会列出算法名称、算法类型、主要用途、服务提供者与备案编号等字段。你把这几栏填清楚，外界就能知道你上线的是什么能力的模型、它的用途边界在哪里、背后是哪家主体在运营。说白了，它就像给每个生成式算法发一张“身份证”，上面写的不是技术参数，而是业务边界和责任人。

很多人觉得这不过是行政公示，离写代码很远。我建议把它当成一份产品的“注册表结构”来看：你的模型叫什么、属于什么类型、部署在哪个产品、给谁提供服务，这些信息本身就要求你在产品设计阶段把用途定义清楚。这一层意义往往被忽略了——备案逼迫你把“算法要做什么”想明白，而不是先做一个大而全的模型再说。填过清单的人会有同感：一个用途说不清楚的模型，在备案表上是真的写不出东西的。

1.2 对研发流程的三个直接冲击：数据、标识、安全评估

备案对研发流程的影响，主要体现在三个地方。

第一是数据来源说明。备案要求算法提供者说清楚训练数据从哪里来、怎么处理。落到工程上，意味着训练数据里不能全是来路不明的爬虫内容，起码要有据可查。现在做RAG（检索增强生成）应用的人特别多，知识库里每一份文档的来源、授权状态、抓取时间这些元数据，以前是可有可无的，现在变成了需要维护的字段。我见过好几个团队做知识库问答时只存正文不存来源，一到要写说明材料时就傻眼。

第二是内容标识。生成式AI的内容需要可识别，这不再是一个可选项。很多AI绘画工具已经在输出图片上打水印，文本内容的隐形标识方案也在普及。别把这件事当成产品体验的负担，从工程视角看，内容溯源恰恰是后续处理用户投诉、排查问题的基础设施。没有标识机制，出了问题连从哪条链路生成的都说不清。

第三是安全评估。上线前的安全评估材料、敏感词过滤、生成内容的审核链路，在架构图里要从“以后再说”改成“默认必备”。这里我特别想说一句：那些打着“无限制无审核”旗号的生成服务，不管技术多强都走不远。合规不是束缚，它是在帮你在出问题时有退路。

1.3 备案不是审批游戏，是可回溯的工程规范

我更愿意把备案清单理解成“产品说明书”，而不是传统的“许可证”。它真正的作用不在于谁批准了你，而在于全社会都能查到你用算法在做什么。一旦出现纠纷或投诉，可以按备案信息回溯到具体算法、具体版本、具体服务场景。这意味着，算法版本管理、请求日志留存、关键输入的采样留痕，这些过去往往事后补的工程能力，现在变成了上线前就要设计好的东西。

一个很实际的例子：某个对话机器人上线后，用户投诉它生成了一段不当内容。如果没有日志和版本记录，你只能把模型下线、重训、再发一版，整个过程是黑盒。如果上线前就做了按版本留痕，能做到精准定位是哪一轮对话、哪个prompt触发的，修复和解释都容易得多。这套可回溯体系，在备案框架下其实就是标准配置。

所以我的建议是，别想着怎么把备案材料写得好看，而是把内部工程规范补齐。材料可以包装，日志和版本记录没法造假，它们才是真正的护城河。

1.4 个人开发者、开源项目与备案的边界

个人开发者也不用慌，要分清边界。如果只是离线研究、不对外提供生成服务，基本不涉及备案。但一旦你把模型封装成API、写成小程序或者做成在线工具向社会提供服务，就会有备案主体的问题。个人主体在很多场景下并不方便，所以多数独立开发者会选择挂靠公司主体，或者干脆以公司名义运营产品。

另一个常见的误区是：模型开源自查不等于服务免责。开源是代码发布层面的授权，而你对外提供服务是另一回事。只要服务面向公众，该走的流程还得走，该做的标识还得做。开源项目的维护者虽然不用替每个下游服务商负责，但如果在项目文档里提供部署和商用建议，也应该提醒使用者注意当地的服务合规要求。

2. 腾讯跳过类ChatGPT产品直接做行业大模型，背后是一套to B逻辑

这周腾讯的公开动作，把行业大模型和MaaS（模型即服务）平台直接摆了出来，没有先发一个C端对话应用。很多人的第一反应是“腾讯是不是慢了一步”，但如果你把腾讯手里的牌摊开看，会发现这条路线比发一个聊天机器人更贴合它自己的业务结构。

2.1 C端对话和B端行业模型，打的是完全不同的两场仗

类ChatGPT的C端产品，核心指标是MAU、留存、使用时长，比拼的是谁更会聊天、谁更能留住用户，烧钱烧在算力和拉新上。而B端行业模型的核心指标是交付效率、业务降本、续费率，客户关心的是你能不能解决他行业里的具体问题，而不是你的模型在公开榜单上排第几。

这两条赛道的投入逻辑完全不一样。C端对话产品需要持续做免费服务的算力投入，商业化路径却还没跑通；B端行业模型虽然交付周期长、定制化程度高，但客户是愿意为确定的效果付费的。腾讯没有在C端跟所有对手正面拼刺刀，而是把火力集中在自己更有优势的企业服务战场上，从商业逻辑上讲，这不是落后，是选边的结果。

2.2 行业大模型的落地姿势：底座、语料、工具链三者缺一不可

行业大模型不是单纯把通用模型改个名，它的标准姿势通常是三件事：选一个靠谱的底座模型，用行业语料做针对性增强，再配一套场景工具链。底座决定能力的上限，行业语料决定它对业务术语的理解深度，工具链决定它能不能真正嵌进业务流程。

举金融行业智能投研的例子。这类应用不是让模型替代研究员，而是让模型把财报、公告、研报批量读一遍，做结构化摘要和检索问答。这里模型需要理解“净资产收益率”“商誉减值”这些术语，识别财报里数据的上下文关系。光靠底座模型的通用能力不够，还得把大量合规披露文件喂进去，同时配合工具链输出带出处的分析结论。

政务和医疗场景同理。政务问答要求答案必须有政策法规出处，不能给模型自由发挥的空间；医疗场景更谨慎，很多项目宁可做得慢，也要保证每一个建议背后都有可追溯的知识依据。在这些场景里，通用模型“能聊天”的本事反而是次要的，稳定、可控、可溯源才是核心。

2.3 腾讯“跳过”对话产品是深思熟虑：它手里有的是企业入口

回到腾讯的动作本身。它手里有云、企业微信、腾讯会议、小程序这一大堆已经跑在企业客户一线的产品入口，行业大模型天然可以嵌进这些场景里。企业微信的客服机器人、腾讯会议的会议纪要、云上的文档智能处理，每一个都是行业模型现成的落脚点。

反过来说，如果腾讯先发一个纯C端的对话产品，不仅要从头拉新，还要面对已经形成用户习惯的竞品，投入产出比并不高。to B项目的经验之一是：客户最烦听你说“我们的模型多强”，他们只关心“能不能解决我的问题”。腾讯这次公开把行业大模型作为核心，相当于把话语权从参数竞争拉回到场景竞争，这个信号比发一版聊天Demo更容易被B端客户感知。

2.4 行业大模型离大规模变现，还差三个硬骨头

把话说回来，行业大模型方向虽然清晰，真正落地时还有三个硬骨头。

幻觉问题排第一。行业客户对准确性的要求比普通用户高一个量级，宁可让模型说“不知道”，也不能一本正经地胡说。实际项目里，外挂知识库做强制检索、限定输出模板、引入人工复核流程，都是常见的解法。这些工程手段并不性感，但它们是行业项目能不能交付的关键。

数据壁垒排第二。做行业模型必须有行业数据，可数据往往在客户手里，签数据授权、做脱敏清洗、确定数据边界，这些环节每一个都需要大量沟通成本。很多项目不是死在模型效果上，而是死在数据根本拿不到。

交付成本排第三。每个客户环境不一样，私有化部署、安全合规、运维支持、驻场实施，这些都会吃掉利润。腾讯发布行业大模型只是第一步，真正的竞争在后面的实施和服务环节，谁能把交付成本打下来，谁才能真正吃到这波红利。

3. 从这周的搜索热词，看开发者在折腾什么

这周的搜索热词特别有意思，量大且集中。我大概扫了一遍，做AI应用的人基本可以分成四派：部署派、微调派、接入派，还有少数已经往纵深走的工具链派。一派一派说。

3.1 部署派：本地跑大模型已经不是极客专属

“本地部署大模型让个人电脑智能化”“大模型部署”“大模型下载”这些词的热度一直居高不下，说明自部署这件事已经从极客圈扩散到了普通开发者。

这背后的直接原因是量化技术的成熟。我最近在一台16GB内存的笔记本上，用Ollama跑7B模型的4bit量化版本做本地文档问答，虽然推理速度不算快，但胜在数据不出本机。对处理合同、病历、财务数据这类敏感内容，本地部署是很有吸引力的路线，尤其在配合RAG做本地知识库时，整个链路可以做到完全离线。

给个硬件上的直觉参考：7B模型做4bit量化后，大约需要6GB显存或者16GB内存，消费级显卡就能带得动；13B模型建议显存在12GB以上；65B以上基本告别个人设备，再往上就得考虑多卡或者集群了。说实话，当下这个阶段，本地部署的价值不在于跑出多惊艳的效果，而在于让每个人都能有一个随时可用的私有模型。

3.2 微调派：给大模型灌知识，LoRA是性价比之王

“大模型微调实战”“GPU微调大模型”“大模型知识抽取框架oneke”这些热词透露出一个趋势：很多人已经不满足于通用问答，开始希望模型真正懂自己的业务。

微调最常见的路线是LoRA。它的核心思路不是把整个模型重新训一遍，而是在原模型权重旁边加一个低秩矩阵，训练时只更新这个小矩阵。好处是显存占用低，单张消费级显卡也能跑；代价是效果上限受限于基座模型本身。

一个最小可行的微调流程大致是：先准备jsonl格式的数据，一条样本包含instruction、input、output三个字段；再用开源微调工具加载基座模型，选择LoRA策略；学习率通常从2e-5左右开始，epoch先跑2到3轮，batch size能拉多大就拉多大；训练完的adapter可以合并回基座模型，也可以单独加载。

我自己的经验是，几百条高质量数据就能看到明显变化，但脏数据毁效果的速度比想象中快得多。很多人在数据清洗上偷懒，结果微调完模型反而变笨了，这不是LoRA的问题，是数据的问题。

3.3 接入派：让自家产品“长嘴”的稳妥路径

另一大批搜索词集中在“注册”“安装”“下载”“使用教程”上，这背后是想把大模型接进自家应用的开发者。我理解这种冲动，毕竟现在谁的产品里没有AI能力，好像就落伍了。

但我要给一个清醒的建议：做生产环境应用时，与其把精力花在折腾第三方闭源服务的注册和网络问题上，不如优先考虑两条路——一是使用国内可合规调用的备案大模型API，二是用开源模型自己部署。这样既免去了不稳定的烦恼，又能对数据和成本有掌控。

具体到接入方式，第一版不要做得太复杂。一个“转发后端”就够：客户端发请求给你的服务端，由服务端统一调用大模型API，再把结果返回。这样做的好处是API密钥不会暴露在前端，请求日志、限流、鉴权都能在服务端统一处理。实测下来，这个模式稳定、可控，后续想换成别的模型也只需要改服务端一个接口。

3.4 向纵深走：提示词、多模态与垂直场景分析

“大模型提示词工程与上下文工程”“多模态大模型”“如何使用大模型分析不同股票的K线图”这些词，代表了一批已经在纵深探索的人。

提示词工程的本质是上下文管理。模型能给多好的答案，取决于你给它多少有效信息，以及这些信息怎么组织。做RAG应用时，只把检索到的相关片段拼进上下文，别把整本手册都塞给模型，否则窗口浪费、输出还容易漂移。上下文工程现在越来越重要，本质上就是学会给模型“做减法”。

多模态带来的变化更直接，模型现在能读PDF里的表格、截图里的图表，这让办公自动化往前迈了一大步。至于用大模型分析股票K线，我见过做得相对靠谱的做法，都是把数据提取和指标计算交给脚本，最后把分析结果交给大模型做口语化总结，而不是让模型直接去预测行情。模型可以做解释，但数据源和计算逻辑得握在自己手里。

4. 三条落地路径怎么选，以及一套可以直接抄的配置

前面聊了趋势，落地才是关键。我把自己跑过的几条路拆开讲，给正在纠结选型的人一个参考坐标。

4.1 先别选框架，先判断你是哪种场景

很多人的第一反应是“我要微调”，但业务初期往往API调用就够用。先做场景判断，再选路径，比什么都重要。

这里面有个常见误区：一上来就选微调的人特别多，尤其是企业客户，总觉得微调才有面子。但微调的成本和运维复杂度是三条路里最高的，如果公式化的问答效果都还没验证，微调属于典型的资源浪费。我建议的节奏是：先用API或者本地部署验证业务价值，再决定要不要投更多资源做微调。

4.2 本地部署参考配置：模型规模、量化等级与显存估算

本地部署最让人头疼的就是配置问题，给三套参考配置：

• 7B模型：内存16GB或显存8GB即可，用Ollama或者llama.cpp跑，量化等级推荐Q4_K_M，单文件约4.7GB，加上上下文缓存，整体控制在10GB以内。
• 13B模型：显存建议12GB以上，推理用llama.cpp的GPU版本，量化同样选Q4档，上下文长度别拉满，影响速度。
• 70B模型：个人机器不推荐，至少需要双卡或者48GB以上内存，还得配合较好的散热和供电。

我踩过的坑是只盯着模型文件大小，忽略了上下文内存。模型跑起来时，系统内存和显存占用往往比模型文件本身大一圈，尤其是把上下文窗口拉长以后。所以算配置时，一定要在模型大小之外留出20%到30%的余量。

4.3 微调最小可行流程：从数据到LoRA一步步操作

微调的最小可行流程，按实操顺序说：

第一步，准备数据。格式用jsonl，字段就三个：instruction、input、output。数据量不需要多大，几百条高质量样本就能见效，关键在于覆盖你真实的业务问题分布，而不是重复同一个模板。

第二步，用开源微调工具加载基座模型。工具选型上，LLaMA-Factory这类项目比较省心，内置了LoRA的训练配置，不用自己手写训练循环。

第三步，设置训练参数。学习率从2e-5起步，epoch先跑2到3轮，batch size在显存允许的情况下尽量大。训练集和评测集要分开，评测集至少留20条手工构造的典型问题，用于判断效果。

第四步，训练完把adapter合并回基座模型，或者保留adapter文件单独加载。合并的好处是后续部署不依赖微调框架，直接当普通模型用。

有个容易忽略的细节：微调后一定要做通用能力回归测试。LoRA微调最常见的副作用是灾难性遗忘，模型对业务问题回答变好了，但通用常识却变差了。上线前拿十几条普通问答跑一遍，能帮你发现这个问题。另外，eval loss下降不代表业务效果一定变好，最终还是要按业务用例做评测，我遇到过loss降了但用户体感变差的情况。

4.4 API接入必调的三个参数，很多坑都从这来的

API接入看起来简单，但参数调不好，效果差一大截。三个参数我每次接入都会重点调。

第一个是温度。温度越低，输出越稳定。行业应用建议设到0.2以下，创作类场景可以调到0.8甚至更高。见过很多线上事故，就是没人动这个参数，默认温度太高，模型在客服对话里自由发挥。

第二个是上下文窗口。窗口越长，能塞进去的材料越多，但太长会导致响应变慢、成本变高。RAG场景里，只拼接检索出来的相关片段，不要一股脑把整份文档都丢进去。

第三个是系统提示词。这相当于给模型发岗位说明书。写清楚角色、输出格式、禁忌事项，效果提升非常明显。比如客服机器人，系统提示词里直接写明“只回复与订单相关问题，不要回答猜测性内容”，要比你费劲调参数管用得多。

5. 高频问题排查速查表

最后整理一份速查表，都是实战里高频出现的问题，按场景分类给出排查建议。

5.1 本地部署与运行

5.2 微调与数据

5.3 应用接入与稳定性

5.4 最后分享一个小技巧

不管走哪条路线，都先做一个10到20条问题的评测集，把业务里最典型的提问固定下来。以后换模型、调提示词、做微调，都拿同一套题跑一遍，好不好一眼就能看出对比。

我在本地部署和API之间来回切换时，这个评测集帮了大忙。有一个版本明明在通用测试里分数很高，但一跑业务评测就露馅，一看是系统提示词里的输出格式描述被模型忽略了，换了个写法才稳定下来。没有固定评测集，这种问题很难被及时发现。做生成式AI应用，感觉很重要，但度量更重要。