企业官网建设流程全解析

1. 为什么技术人需要一份7天AI扫盲计划

最近连续被好几个朋友问起类似的问题：Agent到底怎么挂工具？RAG和微调该先学哪个？DeepSeek、Llama、GPT这类模型名字满天飞，是什么关系？还有不少做测试、做产品的朋友，说团队里AI工具都上了，但自己除了会用聊天窗口，别的环节基本插不上嘴，心里慌得很。

说实话，我特别理解这种"知道自己落后了，但不知道从哪里补"的状态。AI这几年变化太快，快到你今天刚看懂"大模型能对话"，明天它已经能写代码、做视频、当数字员工了。各种新词——Agent、多模态、工作流、评测集、量化、推理框架——像一堆拼图碎片撒在桌子上，没有一张总览图，你很难想象它们是一幅什么样的画。

所以我一直觉得，对技术从业者来说，缺的不是更多教程，而是一份结构化的"扫盲路线图"：把那些被频繁提到、但很少有人讲透的概念，按依赖关系逐个拆开，再用动手实验把它们串起来。这也是我写这份指南的初衷。如果你日常写代码、做测试、设计产品，或是在企业里负责技术选型，但对AI的理解只停留在"用过ChatGPT"这个层面，这篇内容就是给你准备的。

为什么强调"7天"？因为长假是技术人最难得的整块时间。没有晨会打断，没有生产故障，没有需求评审，你可以连续几天保持一条完整的学习主线，这是碎片时间做不到的深度状态。我的建议是每天投入2到3小时，不贪多，但绝不间断，7天下来基本能把AI领域的地图摊开看一遍。

七天大概这样分配：第1到2天学模型底层逻辑（GPU、参数、Token、Transformer、训练流程），把"地基"打牢；第3到4天学AI Agent与AI编程，这是技术人最快产生生产力的入口；第5天学测试开发与工程部署，搞清楚模型从实验到上线之间的路；第6到7天集中在图像、视频、短剧、建站和AI工作流这些应用层方向，感受AI在内容侧的爆发力。别怕哪天学不完，每部分我都会给出"最简可行路径"。

2. 第1~2天：先把模型核心逻辑看清楚

2.1 GPU、参数、Token——三个天天见但容易被误解的词

很多初学者上来就学Transformer，结果越学越懵。我建议先别碰数学，先把三个高频词的真实含义搞明白，因为后面所有概念都建立在它们之上。

先说GPU。大模型之所以需要GPU，不是因为"AI必须用显卡"，而是因为模型训练本质上是海量矩阵乘法。CPU像10个顶级专家，适合处理复杂但量少的任务；GPU像一万个流水线工人，每单个工人水平一般，但人多力量大，特别适合并行计算。大模型一次算的就是上亿个矩阵元素，靠CPU一个个算，训练一版得按年算，换GPU集群能压到按周按月算。所以你在技术文章里看到的"A100""H100""显存""CUDA核心"这些词，本质都是在描述"这批流水线工人的数量、速度和临时仓库大小"。

再说参数。参数就是神经网络里所有可训练权重，可以理解为模型记忆和知识的载体。一个模型有多少参数，大致决定了它"见过多少世面"。1750亿参数的GPT-3当年震撼业界，现在700亿参数的开源模型已经很常见，DeepSeek这类大模型还用了MoE（混合专家）架构，把参数拆成多个"专家模块"只激活其中一部分，既保留了容量，又控制了推理算力。需要提醒的是，参数越大不代表每个任务都更强，小模型在垂直场景里用LoRA微调后，照样能吊打大模型的通用表现。

最后说Token。Token是模型读写的基本单位，不是"字"，而是"词元"。中文场景下，一个字通常对应1个到2个Token，英文一个常见单词大概1个Token，代码里一个长变量名可能被拆成好几个Token。这个概念直接关系到API计费，也关系到你能输入多少内容。我见过不少人很困惑"同样字数，为什么有的模型按字数计的这么贵"，其实厂商按Token计费是行业惯例，你写一段中文提示词，消耗的Token数量大概是字数的1.3到1.8倍，写代码时翻倍也不意外。

这三者的关系可以用一个不太严谨但好理解的比喻概括：GPU是计算火力，参数是弹药存量，Token是每次射击消耗的子弹。训练时要把弹药备齐，推理时每开一枪都要消耗子弹，GPU火力越猛，单位时间能打的子弹越多。

下表可以帮你快速建立一个量级感：

2.2 Transformer、预训练、微调——三个概念解开"AI怎么学会说话"的谜题

把基础词搞定之后，就可以看模型的核心机制了。现在的LLM几乎无一例外基于Transformer架构，这个词你肯定见过无数次，但它在讲什么？

简单说，Transformer里的"注意力机制"回答了一个核心问题：在一个句子里，哪些词和哪些词存在关联？而且这个关联不是局部的——"小明因为没带伞，所以浑身湿透"这句话里，"伞"和"湿透"虽然隔得远，但在深层网络里它们会建立很强的关联权重。用生活经验类比，注意力机制就是你在读一段话时，眼睛会不自觉地来回扫视关键信息，而不是只盯着离自己最近的词。这项技术的突破在于，它比老一代RNN/LSTM能捕捉更长的依赖关系，而且天然适合并行计算。

有了架构，模型还需要"学习过程"来获得能力。整个过程大致分三阶段：

第一阶段叫预训练。模型拿海量文本（几乎等于半个互联网）做一件事：预测下一个Token。看到"今天天气"，训练目标是补出"真不错"。听起来简单，但当你用几百亿个句子反复做这件事，模型就会在参数里沉淀出语法规则、常识甚至初步推理能力。这个阶段成本极高，通常需要数千张GPU同时跑数周到一个多月，这也是为什么预训练基本都是大厂或大团队在做。

第二阶段叫监督微调，简称SFT。预训练只是让模型"会说"，但不代表"会聊天"或"懂指令"。SFT阶段用大量人工写好的"问题-标准答案"对，让模型对齐人类的问答习惯。你可以理解成预训练阶段像让一个孩子从零开始理解世界，SFT阶段则是教他"别人问问题时应该怎么得体地回复"。

第三阶段叫RLHF，基于人类反馈的强化学习。SFT之后模型已经像模像样，但还会出现"一本正经胡说八道"或"回答不符合人类偏好"的情况。RLHF的做法是再训练一个"打分模型"，让它给模型的输出质量打分，然后用强化学习去微调模型，让高分行为出现的概率不断上升。这一步做得好不好，直接决定了你用的模型"好不好用"——同一技术底子，对齐质量差的模型，用起来就像"能力不错但情商很低的人"。

还有一个高频词是上下文窗口。它指模型一次能处理的最大Token范围，可以类比为"工作台面大小"。台面太小，处理长文档时长文档开头的信息就已经"滑出桌面"被遗忘了。如今主流动线已经有32K到128K甚至更大，但实际用下来你会发现，不是越大越好——长上下文会显著增加算力成本和响应延迟，而且模型对中间部分内容的关注度往往不如开头结尾。这个特性在后续做长文档分析时极其重要，后面几天会反复用到。

2.3 从DeepSeek到开源闭源——模型选型要看什么

第2天后半段，建议学习任务从"概念"切换为"看模型"。现在市面上模型极多，如果不加筛选地去追，每天都很焦虑。其实选模型就像招人，你得先明确岗位需求、预算和可管理性。

一个模型通常可以从三个维度评估：参数规模、数据训练质量、对齐程度。同一参数规模的模型，训练数据的中英文占比、代码质量、专业知识覆盖不同，实际表现会天差地别。DeepSeek之所以在开源圈火，一部分原因就是它在中文能力和数学推理上做得很扎实，同时把很大规模的参数做成了高性价比的架构。你不需要去背所有模型名，但至少要能分清：哪些是闭源托管型（只能通过API调用），哪些是开源可自部署型（可以下载权重到自己的GPU上来跑）。

对个人开发者或中小企业，选型有一个比较务实的策略：优先选API成熟、生态好的模型做原型验证；有私有化需求、数据敏感或推理量极大时，再考虑开源模型自部署。不要一上来就"我要本地跑大模型"，本地部署的隐性成本远不止买卡——还有运维、升级、监控、防攻击。如果你一个人单干，这很可能成为时间黑洞。

关于上下文安全的提醒：部署模型时要额外注意输入输出内容的合规性，尤其是涉及个人信息或版权内容时，尽量使用企业内部或经过合规评估的服务，避免直接上传敏感数据到不明接口。

到了这里，第1到2天的量已经比较扎实了。你在脑海里应该有一幅图：模型就像一个巨型函数，GPU决定它跑多快，参数决定它记得多少，Token决定它每次读多少字，Transformer是它的内脏结构，预训练和微调是它从小到大被教育的过程。接下来第3到4天，我们把视角从模型本身转向它的使用方式——Agent和AI编程。

3. 第3~4天：AI Agent与AI编程——技术人最快形成生产力的入口

3.1 AI Agent：不是聊天机器人，是"会自己干活的实习生"

AI Agent是这几年热度暴涨的词，很多热词都与它相关。但要注意，Agent不是一个具体模型，而是一个系统架构。一个标准Agent由四部分组成：模型（大脑）、工具（手脚）、记忆（资料库）、规划（拆解能力）。

我习惯拿"实习生"来类比。你给一个实习生布置任务："帮我把这10份合同里的金额提取出来做成表格。"得力实习生会怎么做？他会先判断任务类型（规划），打开Excel和PDF阅读器（调用工具），按你之前提到的格式要求整理（记忆），过程中遇到模糊项再向你确认（多轮交互），最后交付一份表格（结果输出）。Agent做的事情结构上完全一样，它的大模型负责推理判断，通过代码或API调用外部工具，把任务拆成多个步骤逐步执行，并在过程中保存中间状态。

技术圈流行的ReAct模式就是这种思路的工程化表达：推理（Reason）→行动（Act）→观察（Observation）→再推理，形成一个循环。举个例子，用户问"北京今天适合户外跑步吗"，Agent先拆解为"获取北京今天的天气"，调用天气API拿到数据，再看空气质量指标，然后结合空气质量指数和温度给出结论，而不是直接凭大模型的记忆编一个答案。

Agent还有一个不能忽略的分支叫多AI协作。简单说就是多个Agent扮演不同角色协同工作，有人做方案，有人做审查，有人做执行落地。团队里可以定义"产品经理Agent""开发Agent""测试Agent"，通过任务队列和状态共享来协作。我的经验是，多Agent不是人越多越好，它的核心价值是"隔离职责+并行探索"，否则多个Agent共享同一个上下文，很容易互相干扰。真正有效的协作模式，是每个Agent有独立的任务描述、输出格式和交接标准，最后有个汇总Agent收口。

工程上大家关心的一个问题是"AI Agent如何扛住并发"。如果只是个人用，直接调API就好；但如果要做成服务，就得考虑模型API的限速、任务队列的削峰填谷、上下文分段存储、失败重试和超时控制。这就引出一个关键原则：Agent干活不是越大越好，而是越"小"越好——你可以把一个大任务拆成多个子Agent，每个处理一个环节，中间用消息通信，而不是把所有内容都塞进一个超长上下文里硬扛。异常重试时，也要保证"上一次做到哪一步了"能被记录，否则Agent一崩溃又从第一步开始，客户体验会很差。

3.2 提示词工程：AI编程和一切AI应用的第一生产力

如果说Agent是"AI如何自主干活"，那提示词工程就是"人类如何准确指挥AI"。这个能力在编程场景里效果最直观——你给模型喂一段代码上下文和一串指令，它返回你实现代码。很多人觉得"AI写代码不靠谱"，大部分原因是提示词太粗糙。

一个高可用编程提示词的模板，通常包含：角色设定、目标描述、技术约束、输入输出格式、相关示例、验证标准。拿"给某个接口写单元测试"举例，差的提示词是："帮我写测试。"好的提示词是："你是资深测试开发工程师。请为以下Python函数编写pytest单元测试，覆盖正常输入、边界值、异常输入三种场景，使用mock模拟外部依赖，测试函数命名为test_开头，最后给出覆盖率预估。"同一个模型，后者返回的代码可用率会高出一大截，这不是玄学，而是因为模型的解码过程本质上是一次"条件概率采样"，你的上下文越清晰，它落在"正确答案"附近的概率就越高。

关于AI编程，我的实操建议是三条：第一，小步走。别让AI一口气生成一个完整模块，先让它生成一个函数或一个类，你看过没问题后再继续下一块。第二，把报错信息喂回去。很多人在AI生成代码报错后只会说"这不行，重新写"，其实把完整的traceback贴回去，AI往往能自己发现问题。第三，让AI先写测试。先要求它生成测试用例，再生成实现代码，这个流程对保证质量有很大帮助。

踩过不少坑之后，我的总结是：AI编程提升的是你的编码速度下限，而不是上限。它适合帮你处理CRUD、工具函数、配置文件和琐碎算法；但在涉及架构设计、性能瓶颈、复杂业务规则时，你依然需要自己深入理解。把AI当成一位极其熟练但需要你验收的"结对编程伙伴"，而不是一个全自动外包——这个心态转变，才是效率真正提升的开始。

3.3 大模型选型与私有化场景的补充

在第3天或第4天，建议花一点时间了解大模型的私有化部署。很多公司一上来就说"我们要本地化部署大模型"，但落地时才知道要面临什么：显存规划（7B模型做4bit量化大概需要6到8G显存，70B模型即使量化也需要至少48G以上，还得预留推理时的KV缓存），推理框架选择（vLLM这类速度优化引擎几乎是标配），以及GPU运维成本。如果只是个人开发调试，用云厂商的API显然是更经济的选择。

有一个经验公式可以辅助判断：如果日均请求量低于几万次，API按量计费通常比自建GPU集群便宜；等到调用量大到一定程度，自建才可能划算。这个判断标准虽然没有精确到个位数，但能帮你避免最常见的资源浪费。

如果决定自建，我建议按这个顺序做：先选一个开源家族的中等体量模型（如7B到14B量级），在单卡或双卡环境跑通推理，再用LoRA去做领域微调。LoRA的核心思想是"不改变原有的大模型权重，只额外训练一小部分低秩矩阵参数"，显存需求低，训练也快，非常适合个人和中小团队微调专属行为。工程上常见误区是一来就想全量微调大模型，不夸张地说，光显存就足够劝退大多数小团队。先用LoRA把流程跑通，再评估效果，资源花得更值。

4. 第5天：AI测试开发与工程部署——模型能用不算完，交付才算完

4.1 AI测试开发到底测什么

我见过太多团队，模型选好了、Agent框架搭好了、提示词调了几十版，上线前却发现"效果不可控"。问题出在测试环节。传统软件开发有清晰的需求、断言、预期结果，AI系统最大的难点是"没有标准答案"，同一个问题，模型每次回答都不完全一样，怎么测？

AI测试开发的第一个任务，是建立评测集。你至少要准备三类数据：一是黄金标准集，包含几百到几千条"输入-期望表现"的样例，用来做回归测试；二是边界测试集，包含长文本、空输入、特殊符号、多语言混合等极端情况；三是对抗性测试集，专门用来发现模型的逻辑漏洞。建立评测集后，每次改动提示词、换模型版本、更新知识库，都要在同一套评测集上重新跑一轮，输出可比对的结果。

评估指标是第二个核心知识点。自然语言任务常用BLEU、ROUGE这类指标来衡量生成文本和参考文本的相似度，但它们只反映字面重合，不完全等于语义正确；代码生成常用pass@k指标，就是生成k个代码候选里有多少能通过测试用例；基于LLM的评估（用大模型给大模型打分）也越来越普遍，适合主观性较强的回答。无论选哪种指标，都要在项目一开始就定义清楚，否则后面每次改动都靠肉眼观察，很容易"感觉变好了"但实际效果并不稳定。

第三个值得关注的方向是AI在测试开发中的应用。AI可以自动生成测试用例、识别代码变更的影响范围、定位可疑报错、生成测试报告。这个场景落地相对容易、ROI也比较高，特别适合已经有一定自动化测试基础、但测试用例维护成本高的团队。

这里有一点需要强调：AI全流程的合规审查不能省。尤其在生成面向真实用户的文本或图片时，必须做安全内容过滤与版权风险排查，不能直接把模型的原始输出搬到线上。大模型本身没有价值观判断能力，它更像一面反映训练数据特征的镜子，你在测试阶段就要考虑输出内容的合法合规性，并通过过滤层、人工抽检等手段兜底。

4.2 推理、量化、RAG与微调——工程化部署的入门词汇

第5天的后半段，核心是搞懂模型从"训练/微调完成"到"服务上线"之间的工程链路。三个词必须掌握：量化、推理框架、RAG。

量化很好理解，就是把模型参数从高精度（比如FP16）压缩到低精度（比如INT8/INT4），相当于把高分辨率照片压缩成清晰度略低的版本，文件小了，加载快了，同时画质只损失一点点。量化能让7B模型在消费级显卡上跑起来，但代价是可能轻微降低输出质量。实际工程里通常先跑FP16版本确认效果，再对比量化版本，质量损失可接受才上量化。

推理框架推荐了解vLLM，它最大的特点是PagedAttention——把KV缓存按页管理，提高显存利用率，并把连续请求做连续批处理，吞吐量比朴素实现有明显提升。如果你只是个人用，用Ollama这类简单工具就够了；如果要面向业务，vLLM几乎是必备选项。

RAG是检索增强生成。你在向模型提问时，先从外部知识库检索相关文档片段，把它们和你的问题一起放进上下文，让模型基于这些资料作答。它与微调的边界很多人分不清，我用一句话总结：RAG是给模型一副眼镜，让它看到外部资料再回答；微调是改变模型本身的思维习惯。知识库经常变就优先RAG，行为模式需要稳定变化就考虑微调，两者搭配使用也是个常见做法。

工程化部署还要关注输入输出安全与内容审核。在做ChatBot或面向公众的AI应用时，建议在模型前面加一层可配置的过滤模块，对输入和输出都做明文拦截，比如PII（个人身份信息）脱敏、内容合规审查。这层工作在项目初期就要设计好，不要等上线被用户投诉了再补。

5. 第6~7天：图像、视频、短剧、建站与AI工作流——看见AI内容生产的全貌

5.1 图片与视频生成，从原理到落地

AI扫盲到第6天，适合接触视觉内容生成。这部分的爆点感最强，技术人也最容易产生好奇。先解释原理：主流的AI绘画模型本质是扩散模型，它学习的不是"画画的规则"，而是"从噪声还原图像"的能力。训练时，把一张清晰图片逐步加噪声变模糊，直到完全变成随机噪声点；反向过程则教模型从噪声里逐步"去噪"，恢复出结构完整的图像。生成时输入文字提示词，模型在噪声里一步步刻画轮廓、细节和色彩，就像雕塑家从一块石头里凿出人像。

提示词和模型机制的配合是重点：文字先被CLIP编码器转换成向量，作为生成的条件控制信号，再引导去噪过程。这也是为什么你改一个字，画面可能完全变样的原因。在实际操作中，关键词权重、负向提示词（告诉模型"不要出现什么"）、采样步数和种子值，都会影响成图质量。稳定扩散生态里的LoRA模型可以用少量图片微调出特定角色或画风，这直接催生了很多AI漫剧等内容形态。

视频生成比图像难一个量级，因为它不仅要保证画面质量，还要保证时序一致，也就是下一帧和上一帧的人物、场景对得上。目前的落地路径大致分两类：一是文生视频（输入文字直接生成短视频），二是图生视频（给一张图让它动起来）。前者适合生成概念短片，后者适合控制角色一致性，做短剧分镜。影视赛道里的AI短剧，本质上就是用"AI生图+图生视频+语音合成+剪辑脚本"串起来的流水线，重点不在每个单帧多惊艳，而在角色一致性、叙事节奏和镜头连贯性。

首次尝试的话，别贪多，我建议按"10秒短视频"为目标：先用AI生成一个稳定角色图，再让这个图"动起来"，配上旁白和背景音，就是一个可发布的素材。角色一致性方面，可以固定种子值、训练专属LoRA或使用同一参考图，这几种方式各有优劣，选你顺手的先跑通。

5.2 热门AI工具、建站与AI工作流

第7天收敛到"生产力"层面。先花半小时浏览热门AI网站的分类：对话助手类（通用问答、代码生成）、图像与设计类、视频生成类、音频音乐类、工作流自动化类、建站工具类。不需要每个都注册，每个分类选一个代表性工具，体验一下，建立"这个工具能干什么"的认知图景就够了，具体好不好用等真实需求出现时再判断。

AI建站是一个非常容易上手且成就感极高的项目。你可以用AI生成站点文案、产品描述、视觉素材和页面布局，再用建站工具把它们组装起来。核心流程一般是：先用提示词生成品牌定位和文案框架，再用AI图像工具生成LOGO与配图，接下来在页面里填充内容并做移动端适配，最后借助AI完成基础SEO优化。这一整套下来，一个企业展示站从零到上线用不了半天，放在5年前这是做不到的。

AI工作流是目前很值得投入学习的概念。它的本质是把"提示词+工具调用+规则判断"拆成可编排的节点，让AI在多个环节里按固定路径处理数据。比如一个周报自动化工作流：先从数据库拉取本周工单数据，再由LLM生成摘要，接着按模板生成邮件草稿，最后发送到指定渠道。节点式工作流的好处是稳定、可控、可追踪，特别适合企业内部流程自动化。

多AI协作在工程上如何落地，前面已经提过核心原则。这里再补充一点：在实际工作流里，多AI协作常常表现为"主从模式"——主Agent负责任务理解、拆解、决策和验收，子Agent各自负责具体任务（读文件、写SQL、做数据分析等），最后由主Agent汇总结果。多个模型也可以协同工作，比如用大模型做规划和总结，用小模型做分类和抽取，既省成本又有不错的效果。凡是涉及时间敏感的任务，都要在中间加入"人工确认节点"，别让Agent在无人监管时连续执行有外部副作用的操作（比如删表、发邮件、支付）。这是从工程事故里总结出来的教训。

6. 实操中踩过的坑与避坑清单

6.1 常见问题速查表

7天扫盲过程中，你大概率会遇到这几类问题。我把常见现象、原因和解决思路整理成一张表，方便你直接对照：

6.2 扫盲执行的三点个人经验

整套7天走下来，有几个感触分享给你，这些是教程里很难写到的内容。

别试图在第一天就把本地环境装好。模型部署、SD WebUI、Agent框架这些工具链配置问题层出不穷，很可能花掉你一整个晚上却还在看进度条。正确做法是先用在线API和云端ComfyUI这类平台把原理跑通，等到第5天再回头处理本地环境，这时候你已经知道每一步的目的是什么，排错效率完全不同。

做笔记的方式也很关键。不建议你大段摘抄概念，而是建立一个"AI名词关键词-一句话解释-我的类比-实际应用场景"四列笔记。我自己的经验是，每接触一个新概念，先按自己的话写一个解释，再想一个生活化例子，这比背所有定义都牢固。后面几天不断有知识交叠，笔记越记越薄，你的理解反而越来越厚。

最后一条，留一天不用电脑。第6天晚上或第7天下午，把工具关掉，拿纸笔把7天学过的概念画成一张关系图：GPU、Token、Transformer、预训练、微调、Agent、RAG、量化、工作流……这些词之间的箭头是什么？谁能替代谁？谁依赖谁？这个过程能过滤掉"听过但没懂"的部分，让知识真正长在自己身上。

我个人最深的体会是：AI扫盲的最大障碍不是信息不够，而是信息过剩。技术人习惯了"尽可能多学"，但在AI领域，贪多反而容易陷入焦虑。与其每天追新模型新闻，不如把这条路线跑完——当你理解了Agent为什么需要工具调用，为什么有上下文限制，为什么需要评测集，为什么有的需求适合RAG有的适合微调，你面对任何新AI工具时，看到的就不再是黑盒，而是一套你已经熟悉的结构加上一层新外壳而已。那个"AI跟我无关"的距离感，就是这么消失的。