1956 年夏天在美国达特茅斯学院的一次研讨会上麦卡锡、明斯基、香农等人第一次正式使用了“Artificial Intelligence”这个词。从那时算起人工智能已经经历了整整 70 年。有意思的是很多非技术朋友会觉得 AI 是这两年才突然冒出来的新事物。打开手机ChatGPT、文生图、大模型编程助手一个个都像从天上掉下来的一样。但如果你把时间线拉长到 70 年会发现这个领域其实走过了一个非常曲折的轮回从早期用规则描述智能到统计学习在工业界铺开再到深度学习和预训练大模型把“智能”推到了用户面前。今天所有关于 AI 的讨论都建立在这 70 年反复试错和范式转换的基础之上。所以这篇文章不只是写一篇“科技周年纪念”。我想从开发者视角梳理这条历史线索把那些绕不开的概念讲清楚给正在学 AI 的人一条比较务实的路线也把这几年来 AI 工程化落地里最常踩的坑列出来。读完之后你会知道为什么 AI 既“老”又“新”也大概清楚自己下一步该往哪个方向投入精力。1. 一个刚刚“出圈”的老学科每当有人提到 AI 已经 70 岁了总会伴随一种疑问既然这么早就开始了为什么直到现在才感觉它真正进入生活这里的关键在于学科诞生和产品成熟之间有一条漫长的时差。1956 年达特茅斯会议上的研究者们当时的目标是让机器可以完成需要人类智能才能做的事比如推理、下棋、证明数学定理。那个阶段的主流思路很纯粹人其实是在用逻辑、符号和规则思考那机器只要也学会逻辑推理不就具备了智能吗这种思路在早期的人工智能项目里确实能跑通一些任务例如定理证明和迷宫搜索。不过这套“符号主义”路径很快碰到了天花板现实世界的知识根本无法通过人工规则完整描述。一张照片里的猫需要多少条规则才能准确识别一段自然语言里的比喻和反讽你怎么写成 if-else1980 年代之前这些问题基本没有答案。后来产业进入了一段沉寂期研究者开始反思靠手工写规则来构造智能是一条走不通的路。从 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_size0.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(promptprompt)# RAG先从知识库检索再把资料作为上下文 def handle_question_with_rag(question): docs retrieve_from_knowledge_base(question, top_k5) context \n.join(doc.content for doc in docs) prompt f基于以下资料回答问题\n{context}\n问题{question} return llm_generate(promptprompt)# 微调使用定制训练后的模型 def handle_question_with_finetuned(question): return custom_model_generate(question)一个通用的选择顺序是优先使用提示词和 RAG因为成本低、易迭代、便于回退当业务对格式、口吻、专业术语有极高要求或评估发现 RAG 方案仍然不够好时再考虑微调。微调不是简单地“用更多数据再训一遍”你需要准备高质量的监督数据还需要反复评估成本明显更高。4.2 很多人问的“AI 客服属于哪个层级”这其实是一个很典型的问题。一个完整的智能客服方案通常同时用到两层甚至三层先用 RAG 回答企业专属知识再用提示词控制语气和格式如果品牌对话风格要求极强可能还会微调一个专属模型。所以不要再把三者理解成非此即彼。它们本质上是围绕“模型”这个核心从输入侧、外部知识侧、权重侧三个方向做优化。组合使用的空间远大于单挑一种方案。5. 普通开发者和学习者现在应该怎么学 AIAI 这 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 示例具体版本以官方文档为准 requests2.31.0 python-dotenv1.0.0环境就绪后你需要立刻建立评测习惯。准备几十条覆盖典型业务场景的问题记录每次模型回答打分再迭代提示词或 RAG 方案。哪怕评测集很简单也比凭感觉调提示词可靠得多。6. 从“写代码”到“写提示词”工程边界在哪里有一个非常有意思的现象现在做 AI 应用大量时间花在“如何把问题描述清楚”上。对开发者来说这确实是一种新体验——过去是写逻辑现在是写表达。但“写提示词”并不是 AI 工程的全部。真正的 AI 应用开发还需要解决稳定性和可靠性问题。模型调用可能超时大模型可能一本正经地编造事实用户的输入可能触发意外输出这些都需要工程手段兜底。一个实用的原则是把 AI 当作一个系统中的组件而不是整个系统。它擅长处理自然语言、图像等非结构化问题输出具有概率性。你要为它设计输入输出协议、错误处理、回退机制和安全边界。真实项目的 MVP 往往不是“全部由 AI 生成”而是“AI 生成 规则兜底 人工审核”。这三者配合比迷信任何单一技术都更可靠。如果某个任务用普通代码就能稳定解决那就没有必要引入模型如果模型能明显提升体验再让模型介入同时保留回退。7. 常见误区与工程化避坑清单7.1 常见误区误区真实情况正确做法大模型就是数据库问什么都能答大模型可能一本正经地编造事实关键事实性知识用 RAG 或规则限制提示词越复杂越好冗长提示词可能增加成本和不稳定性用评测驱动提示词迭代微调能解决所有业务问题微调改变模型行为不一定能注入新知识业务知识优先选择 RAGAI 应用上线就不用管了提示词、上下文、数据变化都会影响效果建立监控和回归评估上 AI 项目必须自己训练模型多数业务直接调用成熟模型即可优先用成熟模型 数据优化提示词可以保密提示词难以真正保密核心知识依赖安全访问控制而不是提示词混淆7.2 工程化落地建议数据先行。先梳理业务数据整理问题集和评估集再决定采用什么方案。先小后大。始终用最小用例验证可行性再扩展数据和功能。留好回退。模型调用失败时要有缓存、兜底回复或转人工通道。记录样本。把失败回答、异常输入记录下来形成回归集。安全边界。涉及用户隐私、账号、权限的数据不要直接发送给模型遵循最小权限原则任何特权操作都应经过合法授权与审计。版本管理。提示词、知识库配置、模型版本都要纳入版本管理确保变更可追溯。关注成本。token 数量直接决定推理成本合理压缩上下文、控制输入长度是上线之后必须做的事。8. 写在 70 年之后历史给你的三条启示回看这 70 年AI 之所以让人感觉“昨天才诞生”是因为技术浪潮的节奏与公众认知的节奏并不同步。学科确实很老了但每一次范式转换之后眼前的产品都是全新的。第一不要神话任何单一技术。符号主义、统计学习、深度学习没有哪一个范式万能。今天的 AI 是多个阶段积累的结果未来的智能系统大概率也不是“一个大模型解决所有问题”而是多种技术协同。第二能力建立在数据与场景之上。这轮大模型的亮点很大程度上来自规模和数据的推动。对你个人或团队来说真正的护城河不是“我们用了大模型”而是“我们积累了别人没有的数据、场景理解和评测体系”。第三工程能力比调参更重要。一个能稳定运行的 AI 功能靠的是数据治理、评测闭环、监控告警、安全边界这些恰恰是普通软件工程的延伸。把基础工程能力打扎实再叠加模型能力是比盲目追逐新概念更稳的路径。70 岁的人工智能当然不算年轻但对正在学习它的人而言最好的时间就是现在。从一个最小可用的项目开始记录问题建立评测优化反馈你会比那些只看不练的人更快进入这个领域。