1956 年夏天，在美国达特茅斯学院的一次研讨会上，麦卡锡、明斯基、香农等人第一次正式使用了“Artificial Intelligence”这个词。从那时算起，人工智能已经经历了整整 70 年。
有意思的是，很多非技术朋友会觉得 AI 是这两年才突然冒出来的新事物。打开手机，ChatGPT、文生图、大模型编程助手，一个个都像从天上掉下来的一样。但如果你把时间线拉长到 70 年，会发现这个领域其实走过了一个非常曲折的轮回：从早期用规则描述智能，到统计学习在工业界铺开，再到深度学习和预训练大模型把“智能”推到了用户面前。今天所有关于 AI 的讨论，都建立在这 70 年反复试错和范式转换的基础之上。
所以这篇文章不只是写一篇“科技周年纪念”。我想从开发者视角梳理这条历史线索，把那些绕不开的概念讲清楚，给正在学 AI 的人一条比较务实的路线，也把这几年来 AI 工程化落地里最常踩的坑列出来。读完之后，你会知道为什么 AI 既“老”又“新”，也大概清楚自己下一步该往哪个方向投入精力。
1. 一个刚刚“出圈”的老学科
每当有人提到 AI 已经 70 岁了，总会伴随一种疑问：既然这么早就开始了，为什么直到现在才感觉它真正进入生活？
这里的关键在于，学科诞生和产品成熟之间有一条漫长的时差。1956 年达特茅斯会议上的研究者们，当时的目标是让机器可以完成需要人类智能才能做的事，比如推理、下棋、证明数学定理。那个阶段的主流思路很纯粹：人其实是在用逻辑、符号和规则思考，那机器只要也学会逻辑推理，不就具备了智能吗？这种思路在早期的人工智能项目里确实能跑通一些任务，例如定理证明和迷宫搜索。
不过，这套“符号主义”路径很快碰到了天花板：现实世界的知识根本无法通过人工规则完整描述。一张照片里的猫，需要多少条规则才能准确识别？一段自然语言里的比喻和反讽，你怎么写成 if-else？1980 年代之前，这些问题基本没有答案。后来产业进入了一段沉寂期，研究者开始反思，靠手工写规则来构造智能，是一条走不通的路。
从 1980 年代开始，方向逐渐转变为“让机器自己从数据里找规律”，这就是机器学习的来源。1990 年代统计学习在工业界有了一些实际应用，2006 年深度学习重新被研究者重视，2012 年深度学习在图像识别上大幅刷新纪录，2016 年 AlphaGo 击败人类顶尖棋手，再往后，Transformer 取代了效果更好的循环神经网络成为 NLP 的主流架构，一直到 2022 年底大语言模型产品正式面向普通用户。每一轮看起来是“突然爆发”的事件，背后都积累了多年的基础研究。
所以，“70 岁”这件事要放在两个维度上理解。模型、算法、硬件、训练方法这些底层技术，是几十年持续积累的结果；而产品化、市场教育、用户接受度，则是近几年才真正开始加速。过去 AI 更多藏在搜索、推荐、风控这些系统内部，现在被大模型产品直接推到人机交互的前台，公众感知自然完全不同。
2. 70 年的三大范式：规则、统计、深度学习
如果要把 70 年 AI 史压缩成一条主线，比较清晰的做法是把它切成三个范式：符号与规则、统计机器学习、深度学习与大模型。这三者不是简单的接力赛，而是不同阶段对“智能从哪来”这个问题的不同回答。
2.1 范式一：符号与规则（1950—1980 年代）
这一阶段的核心是“知识工程”。研究者把某一位专家的经验整理成规则，写进系统，让系统按逻辑判断问题。代表成果是专家系统，在医疗诊断、地质勘探等垂直领域有过实际部署。
可以看一个简化逻辑：
def diagnose(headache, fever, cough): if not headache and not cough: return "暂无典型症状" if headache and not fever: return "可能偏头痛" if headache and fever and cough: return "疑似感冒" return "需要进一步检查"这种写法直观、结果可解释，但问题也很明显：规则一旦多起来，维护成本急剧上升。真实场景中的专家系统动辄几千上万条规则，一个新情况进来就要补新规则，整个系统变得非常脆弱。这也为第一次 AI 寒冬埋下了伏笔。
2.2 范式二：统计与机器学习（1980—2010 年代）
与手工规则不同，机器学习试图让系统从大量样本中自动归纳模式。开发者不再逐条输入规则，而是准备数据、设计特征、选择模型、训练、评估。特征工程在这个阶段非常重要，甚至直接决定了一个模型的天花板。
下面这段代码代表了典型的传统机器学习流程：
from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split # 特征：头痛、发热、咳嗽等结构化指标 X, y = load_medical_samples() X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2) model = RandomForestClassifier() model.fit(X_train, y_train) print("accuracy:", model.score(X_test, y_test))这个范式的优势是，模型可以在比较规整的表格数据上取得稳定效果，工业界至今仍在大量使用。但它的短板同样明显：面对图像、语音、自然语言这类高维非结构化数据，人工特征设计几乎无法覆盖全局。
2.3 范式三：深度学习与大模型（2012 年至今）
深度学习的核心变化，是把“特征工程”也交给了模型自己。卷积神经网络在图像任务上的突破、循环神经网络在序列建模中的应用，逐步改变了人们对 AI 能力的认知。2017 年 Transformer 横空出世，跨序列建模能力更强；2022 年底大语言模型进入大众视野，AI 正式从实验室走进产品。
从代码体验来看，同样是识别一张图片，传统机器学习要做大量预处理和特征提取，而深度学习可以直接把原始像素作为输入，交给卷积层自动学习。这个过程带来的改变不仅是性能提升，更是工作方式的改变：过去人的主要精力放在“怎么把数据变成模型能理解的特征”，现在更多转向“怎么组织训练数据、设计模型结构和评估方案”。
2.4 三个范式的本质差异
| 维度 | 符号主义 / 专家系统 | 统计机器学习 | 深度学习 / 大模型 |
|---|---|---|---|
| 知识来源 | 人类手工规则 | 人工特征 + 数据 | 自动特征学习 + 大规模数据 |
| 主要难度 | 规则爆炸、维护成本高 | 特征工程难、样本质量要求高 | 数据、算力、调优成本高 |
| 可解释性 | 高 | 中 | 低 |
| 适用场景 | 封闭、小规模规则场景 | 表格数据、结构化场景 | 图像、语音、自然语言等非结构化场景 |
| 典型代表 | 专家系统、逻辑推理 | 决策树、SVM、随机森林 | CNN、RNN、Transformer、大模型 |
需要清醒的地方是，这三种范式没有谁被彻底淘汰。直到今天，很多工业系统的核心仍然是统计模型和规则引擎，大模型只是作为其中一个组件嵌入进来。理解这一点，就不容易产生“AI 能解决所有问题”的幻觉。
3. 本轮 AI 为什么和以前不一样
很多亲历过上一轮 AI 热潮的人，会对今天的大模型热保持谨慎。这种怀疑有道理。但也必须承认，这一轮 AI 确实带来了一些结构性变化，和 2016 年之前的深度学习热潮有明显区别。
第一个变化是规模带来的“涌现”。以前深度学习模型的参数量大多在几千万到几亿之间，而大语言模型把参数量推高到千亿甚至更高量级。当参数规模和训练数据增加到一定程度后，模型在一些任务上出现了相对小模型完全没有的新能力，比如更强的上下文理解、指令跟随、逻辑推导。虽然“涌现”在学界仍有争议，但工业界已经用产品证明了它确实存在。
第二个变化是训练方式的统一。过去做自然语言处理，要先分词、去停用词、做词向量、针对每个任务单独设计模型结构。Transformer 之后，“预训练 + 微调”变成通用路线——模型先在海量文本上学习通用语言规律，再在具体任务上做少量适配，甚至不需要微调，直接靠提示词就能完成多种任务。
第三个变化是产品形态的成熟。以前 AI 通常是藏在系统内部的模块，用户感觉不到“AI 存在”。大模型把 AI 做成了对话、创作、编程助手，直接面向用户。这带来的是真正的市场教育：技术不再是少数人的黑科技，而是人人都能试一下的日常工具。
对开发者而言，最明显的变化发生在工作流层面。以前遇到一个业务问题，第一反应是拆需求、设计数据表、写接口、写逻辑；现在，你多了一个选择——这个任务能不能用模型来处理？用什么样的输入、什么样的上下文、什么样的评测标准？传统软件工程并没有失效，而是我们的视野里多了模型、token、上下文这些新元素。
4. 今天必须分清的五个关键词：算力、数据、token、模型、场景
讨论 AI 时，很多人会被一串术语绕晕。其实这些词可以放进一个具体的工程故事里理解。
假设你正在做一个企业知识库问答功能。你需要考虑以下要素：
- 算力（Computing Power）：模型训练和推理所依赖的硬件资源。训练大模型需要高性能计算集群，推理也需要显卡。算力决定了你能否训练大规模模型，也影响线上推理成本和响应速度。
- 数据（Data）：模型学习的原料。大模型需要海量高质量文本完成预训练；业务问答的效果则更依赖你提供的数据质量，比如知识库是否覆盖业务范围、文本是不是结构清晰。
- Token（词元）：模型处理文本的最小单位。中文里可能一个字或几个字合并成一个 token，英文里一个单词可能拆成多个 token。token 数量决定了上下文窗口能容纳多少内容，也直接决定了模型的成本和上下文理解范围。
- 模型（Model）：神经网络训练得到的参数集合。模型接收 token 序列，输出下一个 token 的概率分布。不同模型的参数规模、训练数据、能力侧重各不相同。
- 场景（Scene）：业务问题本身。客服问答和代码生成的要求不同，营销文案生成和法律文本审查也不同。场景决定了你在数据、模型、提示词、评测上的取舍。
理解了这五个词，再去看大模型应用，就不会觉得它们只是一堆空洞的概念。
4.1 提示词工程、RAG 检索、模型微调，三个层级怎么分？
这是初学大模型时最容易混淆的一组概念。用一句话区分：
- 提示词工程改的是输入侧，模型不动，通过改写问题、增加上下文或示例，引导模型输出更符合预期。
- RAG 检索增强生成改的是模型外部的信息，模型也不动，但会先从知识库检索相关内容，拼进上下文，再让模型回答。
- 模型微调改的是模型权重，用业务数据继续训练模型，让模型学会特定的表达、格式或领域知识。
它们在工作层次上有本质差别：
# 提示词工程：直接调用模型，优化输入 def handle_question(question): prompt = f"你是客服助手，请简洁、准确地回答问题。\n问题：{question}" return llm_generate(prompt=prompt)# RAG：先从知识库检索，再把资料作为上下文 def handle_question_with_rag(question): docs = retrieve_from_knowledge_base(question, top_k=5) context = "\n".join(doc.content for doc in docs) prompt = f"基于以下资料回答问题：\n{context}\n问题：{question}" return llm_generate(prompt=prompt)# 微调：使用定制训练后的模型 def handle_question_with_finetuned(question): return custom_model_generate(question)一个通用的选择顺序是：优先使用提示词和 RAG，因为成本低、易迭代、便于回退；当业务对格式、口吻、专业术语有极高要求，或评估发现 RAG 方案仍然不够好时，再考虑微调。微调不是简单地“用更多数据再训一遍”，你需要准备高质量的监督数据，还需要反复评估，成本明显更高。
4.2 很多人问的“AI 客服属于哪个层级”
这其实是一个很典型的问题。一个完整的智能客服方案，通常同时用到两层甚至三层：先用 RAG 回答企业专属知识，再用提示词控制语气和格式，如果品牌对话风格要求极强，可能还会微调一个专属模型。
所以不要再把三者理解成非此即彼。它们本质上是围绕“模型”这个核心，从输入侧、外部知识侧、权重侧三个方向做优化。组合使用的空间，远大于单挑一种方案。
5. 普通开发者和学习者，现在应该怎么学 AI？
AI 这 70 年积累下来的知识量太大了，新手很容易被各种教程淹没。这里不打算给你列一门“一个月精通 AI”的空洞计划，而想根据目标区分两条路线，并给出一个尽量减少返工的顺序。
5.1 如果用 AI 做产品：应用层路线
对大多数应用开发者，建议把重心放在“应用层”而不是“训练层”。你的目标不是从零训练一个千亿参数模型，而是把现成模型组合成可靠的产品功能。
学习顺序可以这样排：
- 掌握 Python 基础，重点学数据处理和 API 调用的写法。
- 了解机器学习基础，包括分类、回归、过拟合、评估指标。
- 理解深度学习和 Transformer 的基本结构，不要求自己训练大模型，但要明白它的能力边界。
- 掌握大模型应用开发的四件套：提示词工程、RAG、微调思路、评测与监控。
- 做一个端到端项目，比如企业内部文档问答助手，包含权限过滤、日志、评测集。
这一路线的核心是“做中学”。不要等把所有理论学完再动手，先调用一个模型完成一个极简单的任务，再逐步加入业务数据和评测。
5.2 如果目标是 AI 研究或算法岗
想走算法岗，数学基础和深度学习理论就重要得多。你需要系统学习线性代数、概率论、最优化、机器学习理论、深度学习和自然语言处理。这条路线周期明显更长，而且对数学、代码、英文论文阅读能力都有要求。不要被“零基础三个月进大厂”的营销话术误导，基础研究和应用开发是两条强度完全不同的路。
5.3 “人工智能训练师”这类岗位意味着什么
这几年陆续出现了人工智能训练师、提示词工程师、RAG 工程师等岗位。它们本质上都不要求你从零发明算法，而是要求你把模型变成可用的产品系统。这类岗位的共同技能包括：数据清洗与标注、提示词设计、RAG 方案实现、模型效果评测、线上问题排查。这正好对应上一条“应用层路线”中的能力清单。
换句话说，AI 人才的需求正在从“少数研究型专家”向“大量应用型工程师”扩散。对多数技术人员来说，这是一个更现实、更值得抓住的机会。
5.4 最小环境准备
不论你走哪条路线，都需要一个干净的 Python 环境。这里给出最基础的准备方式：
python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\Scripts\activate pip install --upgrade pip# requirements.txt 示例，具体版本以官方文档为准 requests>=2.31.0 python-dotenv>=1.0.0环境就绪后，你需要立刻建立评测习惯。准备几十条覆盖典型业务场景的问题，记录每次模型回答，打分，再迭代提示词或 RAG 方案。哪怕评测集很简单，也比凭感觉调提示词可靠得多。
6. 从“写代码”到“写提示词”：工程边界在哪里
有一个非常有意思的现象：现在做 AI 应用，大量时间花在“如何把问题描述清楚”上。对开发者来说，这确实是一种新体验——过去是写逻辑，现在是写表达。
但“写提示词”并不是 AI 工程的全部。真正的 AI 应用开发，还需要解决稳定性和可靠性问题。模型调用可能超时，大模型可能一本正经地编造事实，用户的输入可能触发意外输出，这些都需要工程手段兜底。
一个实用的原则是：把 AI 当作一个系统中的组件，而不是整个系统。它擅长处理自然语言、图像等非结构化问题，输出具有概率性。你要为它设计输入输出协议、错误处理、回退机制和安全边界。
真实项目的 MVP 往往不是“全部由 AI 生成”，而是“AI 生成 + 规则兜底 + 人工审核”。这三者配合，比迷信任何单一技术都更可靠。如果某个任务用普通代码就能稳定解决，那就没有必要引入模型；如果模型能明显提升体验，再让模型介入，同时保留回退。
7. 常见误区与工程化避坑清单
7.1 常见误区
| 误区 | 真实情况 | 正确做法 |
|---|---|---|
| 大模型就是数据库，问什么都能答 | 大模型可能一本正经地编造事实 | 关键事实性知识用 RAG 或规则限制 |
| 提示词越复杂越好 | 冗长提示词可能增加成本和不稳定性 | 用评测驱动提示词迭代 |
| 微调能解决所有业务问题 | 微调改变模型行为，不一定能注入新知识 | 业务知识优先选择 RAG |
| AI 应用上线就不用管了 | 提示词、上下文、数据变化都会影响效果 | 建立监控和回归评估 |
| 上 AI 项目必须自己训练模型 | 多数业务直接调用成熟模型即可 | 优先用成熟模型 + 数据优化 |
| 提示词可以保密 | 提示词难以真正保密 | 核心知识依赖安全访问控制，而不是提示词混淆 |
7.2 工程化落地建议
- 数据先行。先梳理业务数据，整理问题集和评估集，再决定采用什么方案。
- 先小后大。始终用最小用例验证可行性，再扩展数据和功能。
- 留好回退。模型调用失败时要有缓存、兜底回复或转人工通道。
- 记录样本。把失败回答、异常输入记录下来，形成回归集。
- 安全边界。涉及用户隐私、账号、权限的数据，不要直接发送给模型；遵循最小权限原则，任何特权操作都应经过合法授权与审计。
- 版本管理。提示词、知识库配置、模型版本都要纳入版本管理，确保变更可追溯。
- 关注成本。token 数量直接决定推理成本，合理压缩上下文、控制输入长度，是上线之后必须做的事。
8. 写在 70 年之后：历史给你的三条启示
回看这 70 年，AI 之所以让人感觉“昨天才诞生”，是因为技术浪潮的节奏与公众认知的节奏并不同步。学科确实很老了，但每一次范式转换之后，眼前的产品都是全新的。
第一，不要神话任何单一技术。符号主义、统计学习、深度学习，没有哪一个范式万能。今天的 AI 是多个阶段积累的结果，未来的智能系统大概率也不是“一个大模型解决所有问题”，而是多种技术协同。
第二，能力建立在数据与场景之上。这轮大模型的亮点，很大程度上来自规模和数据的推动。对你个人或团队来说，真正的护城河不是“我们用了大模型”，而是“我们积累了别人没有的数据、场景理解和评测体系”。
第三，工程能力比调参更重要。一个能稳定运行的 AI 功能，靠的是数据治理、评测闭环、监控告警、安全边界，这些恰恰是普通软件工程的延伸。把基础工程能力打扎实，再叠加模型能力，是比盲目追逐新概念更稳的路径。
70 岁的人工智能当然不算年轻，但对正在学习它的人而言，最好的时间就是现在。从一个最小可用的项目开始，记录问题，建立评测，优化反馈，你会比那些只看不练的人更快进入这个领域。
