企业官网建设流程全解析

人工智能这个学科今天已经70年了。1956年夏天，美国达特茅斯学院的一场暑期研讨会，第一次把“人工智能”这个词当成一个独立的科学研究方向确定下来。约翰·麦卡锡、马文·明斯基、克劳德·香农、纳撒尼尔·罗切斯特等一批研究者坐在一起，想回答一个很朴素的问题：机器能不能像人一样完成学习、推理、识别、理解和决策。这个问题到今天仍然没有完整答案，但围绕它已经长出了一整套技术体系，从学术概念变成算法、算力、数据、模型、场景串起来的工程学科。

这篇文章适合几类人看：正在学人工智能基础、准备大作业或者论文的学生；想转行做人工智能开发、需要判断提示词工程、RAG检索、模型微调怎么选的人；在企业里要落地本地部署和客服机器人等应用的工程师；还有做教育、培训和通识科普的老师。70年这个节点并不是让你去背一串历史年表，而是适合重新梳理一遍：哪些东西已经过时了，哪些能力真正值得投入，哪些坑是你迟早会踩到的。

1. 达特茅斯会议解决的不只是命名，而是把“机器能否思考”变成可验证问题

1.1 从哲学猜想走向学科化

人工智能的“孕育期”其实很长。早在1950年，图灵就提出了著名的图灵测试，把“机器能不能思考”转化成“机器能不能在对话里伪装得像人”。但图灵测试说到底还是一种思想实验，没有一套共同术语，也没有一个稳定的学术共同体。

真正让这个方向被“建制化”的，是1956年的达特茅斯会议。麦卡锡等人提出的研究计划里，明确写到了语言、神经网络、抽象思维、创造力等方向，打算用一次长会把这些话题硬生生合并成一个学科。会议实际规模不大，参与者大概十多人，讨论也没有像今天的论文那样有严密实验数据支撑，很多内容停留在构想阶段。但它的意义在于：人工智能不再是某个人文学科里的思辨话题，而是一个可以被机器学习、知识表示、问题求解、自然语言处理等子方向拆解的研究领域。

所以今天庆祝70周年，真正值得纪念的不是某次会议本身，而是“可验证”这三个字。此后的几十年里，所有人工智能话题都必须落到数据、实验、评测指标上。你说一个系统聪明，不能只靠感觉，要给样本、给结果、给对比。这种工程思维从学科建立第一天就刻进去了。

1.2 早期远没有今天“智能”，但已经埋下所有关键问题线索

如果你现在去翻20世纪60年代的资料，会发现很多公开报道用词非常夸张，比如预言十年内机器就能解决常识推理问题。实际结果显然没有兑现。60年代到80年代，人工智能经历过好几次低谷，学界管这叫“人工智能的冬天”，原因高度一致：算力不够、数据太少、问题被过度简化。

但早期研究者留下的问题清单，今天依然有效。

• 如何让机器理解语言，而不仅仅是匹配关键词。
• 如何让机器学习规则，而不是靠人一条条写死。
• 如何评估机器输出的好坏，避免自说自话。
• 如何在有限资源下做实时推理。

这些问题到当下并没有消失，只是被Transformer、大数据、GPU这些基础设施暂时压住了。你学人工智能导论时，如果只看前沿技术而忽略这些基础问题，很容易把“模型很强”误当成“问题已经解决”。

1.3 别把70年理解成一条笔直的上升线

我建议把这个学科的发展看成一条波浪线。每隔十到二十年，就有一次能力跃迁，但紧接着往往是大量重复和泡沫。

比如2012年深度学习进入公众视野，图像识别准确率大幅提升，很多项目一拥而上，后来发现落地难度远比想象大。再比如2022年之后大语言模型爆发，大家又开始觉得什么都能做，结果真实业务里还是要处理幻觉、成本、数据隐私、效果评估这些麻烦事。

这种认知很重要。你不会因为在纪念节点看了一篇总结文章就突然掌握人工智能。真正有效的学习方式，还是找一个具体场景，从最小任务跑起来。

2. 70年发展绕不开的四个支柱：算力、数据、模型、场景

2.1 先记住几个基本名词

最近很多讨论都集中在人工智能涉及的算力、token、数据、模型、场景等名词解释上。这些词看起来基础，但越到后面越容易混淆。

• 算力：做神经网络训练和推理所需要的计算资源。常见形态是显卡GPU、服务器集群，云端也可以按租用。训练大模型要靠大规模算力，日常做实验则一张普通显卡也够。
• 数据：模型学习的原材料。文本、图片、语音、代码、表格都可以是数据。数据质量直接决定模型能力上限。
• 模型：一套把输入映射成输出的数学结构，包括网络结构和训练得到的参数权重。大模型指的是参数量很大的神经网络模型。
• 场景：你真正想解决的业务问题，比如智能客服、内容摘要、图像分类、语音转写。同样一个模型，在不同场景下要做的工程处理完全不同。
• token：大语言模型处理文本时，并不直接按“字”读取，而是把文本切分成一个个token。一个token可能是一个汉字、一个英文词的一部分，也可能是标点符号。上下文长度的上限、API计费价格，通常都按token计算。

把这些概念串起来理解：你想做一个人工智能客服，得先有一个模型，模型需要数据训练或微调，推理时需要算力，而token是计量输入输出的基本单位，最后要放在“客服咨询”这个具体场景里看效果。

2.2 为什么四个支柱缺一个都不行

在实际项目里，这四样东西常常被当成相互独立的采购项。有人先把服务器买好，再开始找数据；有人拿到模型就塞进业务，完全没有评测标准。结果就是钱花了、系统上线了，效果却很难看。

我的经验是，它们之间强耦合。数据决定了模型能学到什么，场景决定了数据怎么清洗和标注，算力决定了模型规模上限和推理速度，模型反过来又决定你要准备多少数据、调多少参数。

举个例子：做一个高并发客服机器人，你选了大参数模型，推理速度可能跟不上；换小模型，回答质量又不够。这时候要调整的可能不是模型本身，而是场景设计，比如先做意图分类，再只对复杂问题调用大模型。这种折衷在教科书里很少讲，但在生产环境中最常见。

2.3 算力不是越大越好，太小也能入门

很多人一听到人工智能就想到昂贵的服务器集群。其实入门阶段，大部分实验用普通开发机能完成。你不需要训练一个几十亿参数的模型，而是先下载一个开源的小模型，在本地跑通一次推理，观察输出质量和运行时间。

如果机器配置低，就把输入文本缩短，把并发数调小，把批处理数量调成1。能跑通之后，再判断是否需要升级到云端显卡或者更高配置。资源的边界，应该由具体任务的数据量来决定，而不是别人说“这个模型需要多少卡”就照搬。

3. 从学科到工程：提示词工程、RAG检索、模型微调到底怎么选

3.1 三个层级的能力边界

现在很多人都在问，人工智能客服到底属于提示词工程，还是RAG检索，还是模型微调。这个问题的前提是搞清三个层级分别解决什么问题。

一句话总结：提示词工程最便宜，适合快速试探；RAG检索补的是“知识”，用于模型没见过的资料；微调改的是“能力与风格”，用于稳定输出。三者也可以叠加使用，先用RAG找到资料，再通过提示词约束回答，实在不行才考虑微调。

3.2 落地顺序：先跑最小闭环

我见过不少团队一上来就选模型微调，理由是“通用大模型回答太泛”。但我更建议把这个顺序反过来。

第一步，先用现成模型加详细提示词，把你期望的回答格式、语气、边界条件写清楚。这一步可能只需要几十条样例，成本和耗时都很低。跑完你会发现，至少一半问题已经解决了。

第二步，如果回答里经常出现编造、过时或者答非所问，而这些问题又集中在特定资料范围内，再上RAG检索。把产品说明、售后文档、常见问题整理成库，按问题检索相关片段。

第三步，只有当提示词和检索都解决不了，比如模型对某个专业术语的理解始终不对，或者输出格式始终不稳定，才去准备微调数据集。微调数据通常需要几百上千条，要包含输入和期望输出，还要注意数据风格一致。

3.3 判断误区：不是越高级就越好

提示词工程看上去比微调“低端”，但实际价值不小，因为它能快速暴露模型的边界。你自己设计一次提示词就会发现，模型输出不稳定的来源很多，包括指令含糊、示例太少、输出格式没约定、上下文过长导致关键信息被稀释。

RAG检索看起来高大上，真正做出来之后也会遇到糟糕的效果，比如检索到了错误片段、相关度排序不理想、多轮对话里上下文重复。微调更不是万能药，它解决不了领域知识缺失，也解决不了模型本身能力不足。如果模型在基础推理上就不行，微调很难凭空创造能力。

所以选层级不能按“听起来高级”来选，而要看任务失败样本最集中在哪层。

4. 人工智能学习路线与职业准备：从导论课到训练师考试

4.1 给初学者一条不绕远的路

我经常遇到有人问人工智能学习路线，但其实这个方向并没有一条全行业统一的路线。比较稳妥的路径是：

1. 先学人工智能基础，比如机器学习、深度学习、常见算法和评价指标。这里不需要推导所有数学公式，但至少要理解损失函数、梯度下降、训练集和测试集这些概念。
2. 再学大语言模型的基本用法，包括提示词设计、上下文窗口、token成本、幻觉问题。
3. 然后选一个方向深入，比如数据处理、模型微调、RAG检索、模型部署或接口开发。
4. 最后做一个完整的小项目，把数据准备、模型选型、推理测试、结果评估串起来。

初学者最容易犯的错误是跳过第一步，直接去看最新的论文和框架。结果论文读了不少，很多概念却对不上。如果你没有时间，就记住一句话：先能在本地跑通一个小模型，再谈底层原理。

4.2 大作业和毕业设计怎么选方向

人工智能专业的大作业和毕业设计，理想状态不是做一个很大很炫的功能，而是把一个很小的任务做完整。

比如做一个文本摘要工具，看起来功能简单，但你需要考虑数据从哪里来、文本格式怎么清洗、摘要长度如何控制、模型生成太慢怎么办、评测时看准确率还是看可读性。这些问题拆开之后，工作量足够撑起一个像样的项目。

选方向时可以按“数据可得性”来定。如果手里没有真实业务数据，就去选公开数据集比较丰富的方向，比如文本分类、图像识别、命名实体识别。如果自己有一批特定领域的资料，那非常适合做RAG检索类项目，因为数据本身就是你的竞争力。

做项目时至少留三分之一时间写文档和做测试。很多同学代码写得很快，但一问效果如何、失败率多少、换一条输入会怎样，就答不上来。这一点在面试和预推免机试里会被放大。

4.3 面对机试、训练师考试和职业认证时怎么准备

如果你要参加南大人工智能学院的预推免机试，或者准备人工智能训练师三级理论考试，重点不是刷多少道题库，而是每天坚持手写或者实现一个小程序，保持对输入输出的敏感度。

机试这类考核，往往不会考很偏的题目，更看重你能不能把成熟模型用对。常见考核点包括：

• 理解数据集的类别分布，会不会做简单统计和可视化。
• 会不会划分训练集、验证集、测试集。
• 能不能判断模型过拟合，并给出简单解决方案，比如正则化、早停、数据增强。
• 会不会分析分类报告里的准确率、召回率、F1值。

人工智能训练师这个职业，不同省份和机构定义不完全一样，但核心能力通常围绕数据标注、数据处理、模型训练评估、场景化应用展开。理论复习时与其死记硬背，不如找一份真实标注任务，从标注规范、样本筛选、一致性检查到训练效果验证全部走一遍。

这里有一个常见误区：证书本身不等于能力。面试官更关心的是你排查问题的方式，以及你能不能解释为什么某个方案能成立。

5. 从纪念文章到动手实验：低配置设备可以做哪些人工智能本地部署

5.1 本地部署之前先确认三件事

热搜里经常出现“人工智能本地部署”，也有人提到通义万象这类可本地体验的工具。本地部署的最大价值不是让你省云费用，而是数据可控、可离线实验、方便调试。

开始之前先确认三件事：

• 操作系统是什么，Windows、macOS还是Linux，不同平台依赖安装方式差别很大。
• 显卡型号和显存多大，这会直接决定能跑多大模型。没有独立显卡也能跑CPU推理，但速度更慢。
• 内存和磁盘是否足够，大模型文件经常几个GB到几十个GB，下载前先看剩余空间。

初学者建议先找一个几百MB到几GB的小模型，不要一上来就跑几十B的大模型。低配置机器能不能跑，答案通常是“能跑，但要把任务调小”。

5.2 最小验证顺序：启动、单条、批量

我一般会按三个步骤做本地部署验证，顺序不要颠倒。

第一步，先验证模型能不能加载。很多报错来自依赖版本不匹配，比如某个库要求Python版本在哪个区间，而你装的是另一个。这里要养成看错误的习惯，把日志里第一条报错复制到搜索工具里，而不是直接问“为什么跑不起来”。

第二步，跑一条最简单输入，比如“你好”。观察输出是否正常、响应耗时多少。如果这一步不对，基本不用考虑优化效果，先把环境调通。

第三步，再跑真实场景的几条数据。把输入放在一个文件里，逐条读取并按批次推理，输出保存成文件。批量处理时要注意输出命名，不能所有结果都写到同一个文件名里，否则后一条会覆盖前一条。

5.3 低配置跑通的常见坑

低配置环境下最容易出问题的，不是模型质量，而是资源耗尽和路径权限。

如果程序运行到一半卡住，先看CPU和内存占用。显存不够时，适当降低 batch size，把每次喂给模型的样本数调成1，通常能解决问题。还要检查输出目录是否有写权限，很多“找不到文件”的错误，其实是目录不存在。

推理速度慢是正常的，不要一开始就怀疑代码有bug。可以先统计十条数据的平均耗时，再估算批量总耗时。如果实在太慢，换更小的模型或者降低输入长度。凡是涉及token的地方，都要注意别把超长文本全部塞进上下文，先截断或分段。

5.4 本地部署通义万象或其他模型时的通用判断标准

如果你下载的是通义万象这类支持本地体验的模型，跑通之后要判断两件事。

第一，输出是否符合任务要求。问答类任务看回答是否完整、有没有明显编造；图像生成类任务看尺寸、风格、内容是否符合预期。

第二，资源占用是否可接受。本地部署成功不等于适合持续运行。如果跑一次需要大量内存，或者长时间满载，那就要换成更轻量的方案或考虑云端。

本地部署的意义在于让你看清模型真实行为，而不是成为一个“下载完就跑”的收藏行为。跑通过一次之后，你才能判断提示词改哪里、是否还要接RAG检索。

6. 人工智能素养不再只是程序员的事：教师、训练师、普通用户各补什么

6.1 教师和通识课堂里的“道法术器”

最近有一个说法叫“道法术器，教师人工智能素养”，把它用在教学上很合适。

• “道”是理解人工智能为什么奏效，知道它基于数据统计，不是魔法。
• “法”是理解使用边界，知道什么场景该用，什么场景不该用。
• “术”是掌握提示词、检索、验证这些具体方法。
• “器”是会用现成工具和平台，比如智能助手、通义万象、代码工具等。

如果只讲工具操作，学生换了工具就不会用；如果只讲理念，又落不了地。更值得做的是把每次课程任务设计成一个完整链路：提出问题，收集数据，运行模型，判断输出，修正方案。

6.2 普通用户不要忽略人工智能偏见和幻觉

人工智能偏见不是只有搞研究的人才关心的事。当模型训练数据里某些内容占比过高或过低，输出就会偏。做产品时，一旦忽视了这种偏斜，可能让一部分用户长期得不到合理回答。

普通用户更常见的体验是“模型一本正经地编答案”，这叫幻觉。模型生成的内容看起来流畅，却不代表事实正确。无论是查资料还是写代码，都要养成交叉验证的习惯，尤其涉及新闻、法律、医学信息时。

这不是劝你不用人工智能，而是告诉你要把模型当成助手，不是当成事实来源。

6.3 工程师要补的工程素养

对工程师来说，人工智能素养还包括可复现和可观测。代码能跑通只是最低要求。你需要知道：

• 模型输出有没有日志，能不能回溯某一条结果。
• 系统是否记录token消耗和耗时，方便估算成本。
• 输入数据有没有版本控制，避免改了一版数据训练出来的模型无法复现。
• 有没有设置失败重试和超时，批量任务不会因为一条脏数据中断。

这些内容在论文里不写，但你在真实项目里迟早会遇到。越早建立工程规范，后面踩的坑越少。

7. 70年节点上，我建议你重新校准的几件事

7.1 不要陷进概念泥潭

现在名词太多了，提示词工程、RAG检索、模型微调、Agent、多模态、自动规划。每天都有新概念出现，每个都看不完。我的建议是没必要追着每个名词跑，抓住一组稳定概念：输入是什么、输出是什么、数据从哪来、模型怎么选、效果怎么判断。

很多看起来复杂的问题，拆开之后会发现只是某两个基本概念的组合。比如“人工智能客服”，本质就是意图识别加生成式回答；“论文润色助手”，本质是长文本处理加风格转换。

7.2 别被“完全模型”这类宣传词带节奏

偶尔能看到类似“全国智能车总决赛人工智能完全模型”这类说法。大部分时候，“完全模型”不是一个标准术语，更可能是宣传包装。真正判断模型能力，要看评测集、测试数据和实测结果。

如果你要做智能车、无人机或自动化等项目，记住真实场景比排行榜更重要。某个模型在公开数据上表现好，不代表它能处理特殊光照、残缺输入或边缘情况。

7.3 从一个小任务做到生产可用

70年来，人工智能最大的变化不是某些神奇功能突然出现，而是大量功能从“能用”变成“稳定可用”。对你个人而言，最重要的不是懂多少理论，而是能不能把一个任务稳定做完。

我建议你设定一个非常小的目标：拿到一批文本，让模型生成摘要，输出固定格式，连续跑50条不崩。等这50条跑完，再继续处理错误样本、调提示词、检查结果格式。这个小闭环，会帮助你理解大部分人工智能工程要点。

如果你已经能把这样一个小任务做到稳定，再去看大模型微调、RAG检索、并发部署和系统架构，都会轻松很多。

7.4 保持持续学习的节奏，但别自责

人工智能学科已经70年，进步速度不是匀速线性的。你不需要什么都懂。更合理的策略是：选择一条主线持续深入，同时用少量时间关注周围的变化。今天学一点本地部署，明天了解一点检索增强，后天做几道训练师题目，三个月后回头看，你会发现自己的判断力已经明显提高了。

真正值得长期练的，不是背概念，而是“给一个实际问题，你能不能快速提出最小验证方案”。这个能力，会让你在这个快速变化的领域里始终有位置。