1. 国庆第1天：搭好世界观——大模型、token 与训练推理
1.1 大模型到底“大”在哪里：参数量的意义
先说一个我经常在群里被问到的问题：“大模型是不是就是把很多文章塞进电脑里，然后你说一句它回一句？”这个理解方向是对的，但离真相还差一个关键概念——参数量。
所谓参数量，你可以把它想成模型脑子里“可调节旋钮”的数量。7B、70B、671B 这些数字，指的是模型拥有几十亿到几千亿个这样的旋钮。训练的过程，就是拿着海量文本，一遍遍调整这些旋钮，让模型面对“用户说了前半句，后半句最可能是什么”这个问题时，预测得越来越准。一个 7B 模型拥有的旋钮，大概相当于你办公桌上翻不完的几十本技术手册；而一个 600B 级别的模型，基本就是一座小型图书馆。旋钮越多，模型能记住的“常识模式”越丰富，但代价也很直接：训练成本、推理延迟、显存占用全部跟着膨胀。
这里有个常见的误解：模型不是“记住了文章原文”，而是“从文章里提炼出了统计规律”。所以它才能回答“给代码起个变量名”这种它没见过的具体问题，也能在你给的一段特殊文本里模仿出风格。理解这一点，你就不会再问“为什么模型不能保证 100% 准确”这种问题了——它不是数据库，它是一台规律推理机。
1.2 训练、微调与推理：三个环节千万别混淆
很多技术人看 AI 资料时，总是被“预训练”“微调”“推理”三个词绕晕。我建议你把它们想成“上大学”和“上岗工作”的关系：
- 预训练（Pre-training）：花大量算力，让模型读遍互联网级别的文本，获得通用语言能力和基础知识。成本最高，普通团队基本不碰。
- 微调（Fine-tuning）：基于预训练好的底座，用特定领域的数据做“岗前培训”，让模型更懂某一类任务，比如让模型从“什么都聊”变成“专门帮你写 SQL 的助手”。
- 推理（Inference）：模型真正上岗，接收用户输入，逐词生成回答的过程。这是你日常调用 API 时实际发生的环节。
把这三个环节分清后，很多概念就能自动归位了。比如“LoRA”“Q-LoRA”这类词，本质上是微调阶段的低成本技巧——只调整一部分旋钮，而不是全部重训，就像给资深员工做一次短期专项培训，不用重新上大学。“GGUF”“量化”则属于推理阶段的优化手段，讨论的是如何让模型在上岗时跑得更快、吃更少内存。
1.3 token、上下文与幻觉：评价模型的基本功
聊 AI 绕不开的一个基础单位叫 token。你可以把它理解成“模型眼里的字词碎片”。中文里，一个 token 可能是一个字、一个词，甚至是一个标点；英文里可能是一个单词的一部分。模型一次能处理的 token 数量，就是“上下文窗口”——窗口越大，它能一次读完的文章越长。
“幻觉”这个词现在大家应该都听过了，指模型一本正经地编造不存在的事实。它本质上是因为模型在做概率预测，而不是查证事实。技术人在设计 AI 产品时，永远要假设模型会犯错，所以才会引出后面讲到的 RAG、工具调用、人工审核兜底等手段。这也是为什么我说第1天只需要把“模型是猜下一个词概率的机器”这句话刻在脑子里，后面所有概念都有了锚点。
2. 国庆第2天：学会对话——提示词、上下文窗口与 RAG
2.1 提示词工程不是“念咒语”，是写需求文档
“提示词工程”这几年被讲得神乎其神，甚至有人把它包装成“魔法咒语”。我的看法比较朴素：提示词的本质，是把你对任务的完整需求，用模型最容易理解的方式写清楚。你给实习生布置任务时，只说“写个方案”和说“你是技术方案架构师，请针对一个 50 人的内部 AI 知识库项目，输出包含预算、里程碑、技术选型的三页方案，用 Markdown 格式，关键假设单独列一节”，得到的结果能一样吗？提示词工程就是这个逻辑。
具体到实操层面，有几个技巧是验证过非常有效的：
- 给模型一个角色和背景：“你是一名熟悉 Spring Boot 的 Java 工程师”会比直接提问得到更贴合语境的回答。
- 把关键约束写进去：输出格式、受众、篇幅、禁忌，越是硬性要求越要写清楚。
- 用少样本示例（Few-shot）：给模型一两个输入输出的范例，它会立刻模仿你的格式，这比你把格式要求用文字描述五遍还管用。
还有一个经常被提到的高级技巧叫作思维链（Chain-of-Thought），本质是鼓励模型“分步思考”再给出答案。它对数学题、逻辑推理类任务特别有效，原理是让模型把中间推理过程显式地写出来，降低跳步出错的概率。你可以在提示词里直接加一句“请先列出你的分析步骤，再给出最终结论”，效果立竿见影。
2.2 上下文窗口的真相：不是越大越好
现在很多模型动辄宣传“百万级上下文窗口”，听起来很厉害，意思是你能把一本几百页的书直接丢给它。但实际用下来你会发现几个问题：第一，窗口拉长后模型对中间内容的注意力会稀释，开头和结尾被记住的概率远高于中段，这就叫“Lost in the Middle”；第二，超长上下文的处理速度和成本都会显著上升。
所以负责任的做法是：不要盲目贪大，而是学会“只给模型必要信息”。我见过不少团队做 AI 应用时，把一堆历史文档全部塞进提示词里，结果回答质量反而下降、费用却涨了不少。更好的方案是结合向量检索，先找出和当前问题最相关的 3-5 段内容再喂给模型，这就是 RAG 的核心思路。
2.3 RAG：让模型学会“查资料”而不是“瞎编”
RAG 全称是 Retrieval-Augmented Generation，检索增强生成，是目前企业落地 AI 应用时最常用、最稳妥的技术方案之一。它的原理非常简单：模型回答问题前，先去外部知识库（比如公司内部文档库、专业数据库）里检索相关内容，把检索结果连同用户问题一起作为输入，再让模型基于这些素材生成答案。
一个生活化类比是这样的：你让一个刚入职的实习生直接回答客户的专业问题，他很可能答错或者支支吾吾。但如果允许他先翻公司知识库，找到相关制度或案例，再照着整理一份答复，正确率会高得多。RAG 就是给模型配了一个“可以查资料的助手”。它没有改变模型的参数，却有效缓解了幻觉问题，也让回答能够引用具体来源。这也是为什么我建议所有刚接触 AI 工程的人，第一个亲手实现的项目选 RAG，而不是一上来就搞训练。成本低、见效快、能直观感受到“搜索引擎+大模型”的组合拳有多强。
3. 国庆第3天：搞懂 Agent 与多 AI 协作——AI 从“问答”进化到“干活”
3.1 Agent 到底是什么：记忆、规划、工具一个都不能少
你在网上会看到各种 Agent 的定义，有的说得很玄乎。如果非要我用一句技术人听得懂的话来概括：Agent 就是“让大模型不只是输出文字，而是能根据目标制定计划、调用外部工具、根据结果迭代调整”的程序系统。
拆开来看，一个完整的 Agent 系统通常包含四块：
- 大模型底座：负责理解任务、做决策、生成中间步骤。
- 规划能力：把一个大目标拆解成若干个可执行的小步骤。比如“帮我调研一下竞品”，它不会直接写一段报告，而是先规划“搜索竞品信息→整理产品定位→分析优劣势→生成对比表格”。
- 工具调用：通过 API 去访问搜索引擎、数据库、代码执行环境、第三方应用。这是 Agent 和普通聊天机器人最本质的区别——聊天机器人只会说，Agent 会做事。
- 记忆：包括短期记忆（当前任务上下文）和长期记忆（用户偏好、历史行为，通常存在向量数据库或外部存储里）。
我实操过的最简单一个 Agent 案例是“客服助手”：用户问“我的订单到哪了”，Agent 先调用订单查询 API 拿到物流状态，再调用售后政策检索工具确认退货规则，最后把这些信息组织成一段自然语言回复。整个过程不需要人为编排每一步，全靠模型自己判断什么时候调用什么工具。
3.2 多 AI 协作：让一群 Agent 分工干活
当单个 Agent 越来越成熟，大家自然开始琢磨一个新的方向：能不能让多个 Agent 协作完成更复杂的任务？这就是“多智能体协作”或者“多 AI 协作”的由来。这个概念听起来新，但思路其实很古老——它就是软件工程里的“模块化分层设计”，只不过模块变成了会自己思考的 AI。
我在实际项目中跑过多智能体协作，最稳妥的模式是“主从编排”：一个 Orchestrator（编排者）Agent 负责任务拆解和分发，把子任务交给多个 Worker（执行者）Agent，执行完成后由 Critic（评审者）Agent 汇总检查。例如生成一份行业报告时，资料收集 Agent、图表生成 Agent、文字撰写 Agent 同时开工，最后由主控 Agent 统一整合格式。这种模式的好处是每个 Agent 职责单一，出问题时容易定位；坏处是调用链变长，token 消耗和总耗时都会上升。
还有另一种“自由讨论”模式，让多个 Agent 互相辩论，某个“裁判 Agent”在后续收敛结论。这种模式在创意发散、头脑风暴类场景中有奇效，但在工程落地中稳定性较差，目前我建议只在实验场景用。
3.3 工作流与智能体训练：一个新方向带来的启发
和“多智能体协作”相伴而生的词是“AI 工作流”（Workflow）。工作流和 Agent 的区别，我倾向于这样表述：工作流是确定性的流水线，步骤是预设好的，每个环节该干什么写得清清楚楚；Agent 则拥有临场判断能力，可以在执行中决定下一步动作。实际工程中，最优解往往不是二选一，而是“工作流为主线、Agent 做关键决策点上的灵活处理”，既保住了可控性，又保留了智能性。
最近圈子里还有个值得关注的方向——DeepSeek 公开的 AI 智能体训练新方法，核心视角是把智能体放进真实工具环境中，通过“完成任务的结果反馈”来强化学习，而不是只靠人工标注的对话示例。这相当于告诉行业：智能体不应只学会“聊天时怎么接话”，更应学会“在真实操作中怎么尝试、怎么从错误里恢复”。我自己的体会是，这条思路直指多智能体系统不稳定性的根源——模型没有在真实环境中见过“工具报错、参数返回异常”这类情况，自然处理不好。如果你打算深入 Agent 方向，可以把“环境反馈驱动的智能体训练”当作一个重点话题持续跟进。
4. 国庆第4天：动手落地——模型部署、AI 编程与工程实践
4.1 模型部署的三种姿势：API 调用、本地部署、私有化集群
概念扫盲进行到第四天，你会发现脑子里已经有很多名词了，但还缺一个“从理论到工程”的桥梁，这就是模型部署。
绝大多数情况下，你其实不需要自己部署模型，直接调用云厂商的模型 API 是最省事的方案。注册账号、拿 Key、写几行代码调接口，性能、稳定性、多模态能力全部由服务商兜底，按量计费。适合个人开发者和绝大多数创业团队快速验证需求。
如果涉及数据隐私、成本敏感或离线场景，本地部署就变得有吸引力了。你可以用开源模型（比如 7B、14B 量级的模型）配合推理框架，跑在自己的 GPU 机器上。这里必须提一个关键技术名词——量化。简单说，量化就是把模型参数从高精度浮点数“压缩”成更低精度的数字，比如从 FP16 压缩到 INT4，代价是极轻微的质量损失，收获是显存占用降低到原来的四分之一左右、推理速度显著提升。这就解释了为什么很多人用消费级显卡就能跑起一个不错的本地大模型。不过你要有心理准备：本地部署只是“能跑”，距离“好用”还有很大距离，工程细节多得足以消耗掉整个假期。
第三类是私有化集群部署，服务企业内部多个业务线，涉及 GPU 集群调度、推理服务框架、负载均衡、监控告警、模型灰度更新，这已经进入 AI 基础设施的范畴。普通技术人员了解前两种就够了，第三种更多是架构师和平台团队需要操心的事。
4.2 模型微调的现实意义：为什么大多数项目不需要
明白了部署，紧接着就会遇到另一个高频问题：“我们要不要用业务数据微调模型？”我的回答经常让提问者意外：大多数情况下，不需要，先做 RAG。
原因很实在：微调擅长改变模型的“行为风格”和“输出格式”，比如让模型学会用你的产品口吻说话、按照公司规定的格式生成文案；但它不擅长给模型注入新的“知识”。想通过微调让模型记住几万条企业内部制度，那是既昂贵又低效的做法——用 RAG 检索外部知识库，既便宜又能随时更新。
如果你确实有微调需求，也要记住几条实操经验：微调数据集的质量远比数量重要，几百条精心清洗、人工审核过的高质量样本，往往强过几万条从日志里直接抽出来的脏数据；微调前先分出一部分数据做验证集，防止“训练时表现很好、测试时效果暴跌”的过拟合问题；微调后必须做回归测试，确保模型在原有能力上没有明显退化。这些经验都是我用真金白银的 GPU 算力换来的。
4.3 AI 编程、AI 测试开发与 AI 产品经理：三个被重塑的技术角色
如今“AI 编程”已经不算什么新鲜词了。Cline、Cursor、GitHub Copilot、通义灵码等工具，本质都是把大模型嵌入 IDE（集成开发环境）中，辅助生成代码、解释代码、写单测、重构逻辑。我实际使用下来的感受是：AI 编程工具对“熟练开发者”的提效最明显，它能快速补齐模板代码、写胶水层、生成测试用例，但还不能独立承担复杂架构设计——因为架构决策依赖大量上下文和隐性经验。你越懂代码，越能看出 AI 写的代码哪里有问题，所以“AI 取代程序员”这种说法，至少目前还太早。
“AI 测试开发”也在同步升温。传统测试人员写自动化脚本需要手动定义用例，现在可以让模型根据接口文档自动生成测试用例；接口返回异常时，模型还能辅助分析日志、定位可疑代码块。我见过最惊艳的一个实践，是用大模型把上千条历史缺陷报告聚类成若干根因模式，直接指导研发团队优化代码——这种“测试数据挖掘”的能力，对普通脚本来说是做不到的。
还有一个角色被热词榜反复点名：AI 产品经理。这个角色最核心的能力根本不是写提示词，而是定目标和设边界——想清楚这个 AI 功能到底服务谁、解决什么问题、用什么样的评测指标判断好坏（比如准确率、采纳率、用户留存率），然后再去协调模型选型、数据准备、评测反馈这些环节。如果你是从技术转岗，我的建议是先从“给 AI 项目搭评测基线”入手，因为可量化的评测体系是整个 AI 产品迭代的地基。
4.4 Spring AI：Java 技术栈里的一股清流
聊到工程实践，Java 技术栈的同学应该对 Spring AI 这个名字不陌生。简单说，它就是 Spring 生态为“接入大模型”提供的一套统一抽象层，让 Java 开发者不用被迫切换到 Python 生态，用熟悉的 Spring Boot 风格去对接不同模型提供商的 API，封装了提示词模板、结构化输出、向量数据库集成、Agent 编排等一大堆常见能力。
打个比方，它之于大模型就像当年 Spring JDBC 之于数据库：你可能不在乎底层用 MySQL 还是 Oracle，只需要一个统一的模板方法来执行 SQL。Spring AI 解决的就是“今天接这家模型、明天换那家模型”时的适配成本问题。对于企业内部有大量 Java 遗产系统的团队，这是一个非常实际的落地选项。当然，如果你是从零开始的新项目，未必非要选它，选型时还是要结合团队技能树和具体场景权衡。
5. 国庆第5天：看清生成式 AI 的版图——图片、视频、声音
5.1 AI 图片生成原理：扩散模型一次讲清
如果你只记住一个词，那就是“扩散模型”。它的思路可以类比成“逆向打码”：训练时，给清晰图片逐步叠加噪声，直到变成满天星一样的纯噪点图，这就是“前向过程”；然后训练一个神经网络，学习“把噪点图一步步还原成原图”，这就是“反向过程”。等模型学会了去噪，你给它一张完全随机的噪点图，它就能“脑补”出一张全新图片。再通过文字引导（也就是提示词），模型就能根据“一只戴着草帽的柴犬在沙滩上”这样的描述，生成对应画面。
理解了这个原理，你就会明白几个常见现象：为什么 AI 生成的细节容易出错——因为去噪过程是概率性的，它对“手有几根手指”这种精细结构并不总能建模清楚；为什么多次生成同一个提示词结果不一样——因为起始噪点是随机的，每次生成的“起点”都不同；为什么提示词里加“8k、高清”不一定有用——“高清”本质是对画面质感风格的引导，而不是真的能提升分辨率。
5.2 AI 视频生成与画质修复：从生成到“把老素材救活”
视频方向的热度是今年才彻底爆发的。文生视频的基本框架，可以理解为在图像扩散模型的基础上增加了时间维度——不仅每帧画面要合理，帧与帧之间还要保持物体一致性和运动连贯性。AI 视频工具生成的素材，现在还很难做到大量角色、复杂剧情的长镜头稳定，但作为短视频素材、创意分镜预览已经完全够用了。
我更想聊的是“AI 视频修复”这个更务实的方向。以 Topaz Video AI 这类工具为例，它利用 AI 模型对视频做超分（把低分辨率提升到高分辨率）、去噪、去隔行、补帧（让画面更流畅）。老电影、老录像、早年用手机拍的糊视频，放进去转一圈，出来的画面清晰度能发生质变。做这件事不需要特别强的技术背景，但对硬件有一定要求——超分模型在 GPU 上跑得快很多，CPU 跑一条十分钟的素材可能要熬一个通宵。我修过几段上世纪九十年代的家庭录像，那种“把模糊记忆里的人和事重新看清”的体验，确实能让人直观感受到 AI 在创作之外的实用价值。
5.3 AI 声音空间化：从“能说话”到“能定位”
语音合成大家很熟，TTS 技术让机器朗读文字早就普及了。但“AI 声音空间化”是一个更有趣的方向：它不只是让 AI 用音色说话，而是让声音在三维空间中有明确的位置和移动轨迹。你在 VR 里听到有人从左边走过来，声音应该从左耳渐入、从右耳淡出，同时随距离变化响度和混响——这就是空间音频的概念，而 AI 可以自动完成声场建模，而不需要人工手动摆位。
应用场景也很清晰：在线会议时让不同发言者的声音分布在房间不同方位，避免一群人挤在“单声道”里相互干扰；影视制作里低成本实现 5.1、7.1 甚至杜比全景声的混音；虚拟主播直播时根据观众互动位置调整声音方位。这波技术还催生了一批“声音克隆”产品，用几分钟样本复刻一个人的音色——作为技术方向很有潜力，但这类应用涉及声音肖像权问题，我一直建议只在明确授权范围内使用，边界意识得刻在骨子里。
6. 国庆第6天：看懂 AI 应用热点——短剧、旅游、建站与内容安全
6.1 AI 短剧、漫剧与 AI 旅游：热闹背后的共同逻辑
最近“AI 短剧”“AI 漫剧”频繁出现在热搜里，圈内还有个说法叫“AI 短剧迟早要出片”。理解这波趋势，你只需要把它拆成一条生产流水线：剧本用大模型生成，分镜脚本用文生图生成关键画面，再用图生视频让画面动起来，配音交给语音合成，最后用传统剪辑软件拼装。这套流程把原本需要几十人协作的影视生产压缩到几个人甚至一个人的工作量，制作成本下降了两个数量级。
同样火热还有“AI 旅游”方向。它不是简单的“AI 帮你订机票”，而是把旅行攻略、行程规划、实时信息、个性化推荐结合在一起：你告诉 AI 你的天数、预算和偏好，它生成路线；旅途中随时问它“附近有哪些不用排队的本地菜馆”，它能结合实时数据给出建议。这类应用的共同模式，我总结成一句话：生成式 AI + 行业知识 + 场景化交互 = 一个新应用。无论是短剧、旅游，还是 AI 建站（用 AI 自动生成企业官网、落地页），底层逻辑都是在重复这个公式。
6.2 为什么 AI 会“不愿回答”：对齐与内容安全的真相
网上经常有人抱怨“这个 AI 怎么这也不让问、那也不让答”，甚至有人专门搜“无限制”“无审核”之类的关键词。作为一个 AI 工程领域的从业者，我想从技术层面把这件事讲清楚。
模型之所以在某些话题上表现出“拒绝”，核心原因在于对齐（Alignment）——也就是在训练和发布环节，开发团队会通过基于人类反馈的强化学习（RLHF）等技术，让模型的回答尽量符合安全规范、法律法规和社会公序良俗。这被设计成模型内部策略的一部分，所以在面对某些高危指令时，模型会主动拒绝，而不是尝试回答。这和“审核”是两码事，审核是发布平台在内容传播时的把关，而对齐是模型自身在生成前的行为约束。
作为技术人员，更应该明白这样一个朴素道理：任何面向公众的 AI 产品都必须处理内容安全边界问题，这不是 AI 产业独有的，而是所有内容平台从第一天起就要面对的成本和责任。越早理解并拥抱这套机制的人，越能够在 AI 应用设计阶段就把合规风险纳入架构，而不是产品上线后再补救。
6.3 技术人面对“限制”的正确姿势
把这些天听到的“无限制 AI”“无审核聊天”等热词放在一起看，你会发现其中隐藏着一个一眼就能看穿的陷阱：完全无约束的 AI 能力，天然会被滥用。在今天这个时间点，不管是为了个人职业安全，还是为了企业合规经营，都不应该把自己的技术和产品建立在绕过内容安全机制的基础上。你要是真在项目里动了这个念头，我劝你先想清楚：你是要对业务负责的工程师，不是找刺激的测评博主。
正确的姿势，是把这个话题转化成正面技术课题：如何设计更精准的内容安全策略，让模型在“不过度拒绝”和“守住底线”之间找到平衡；如何通过提示词策略和模型微调，让 AI 在敏感领域用专业、友善、可信任的方式回应。能把这些做好的工程师，未来几年在各个行业都会是稀缺资源。这也是我坚持在假期扫盲内容里专门开一节讲安全边界的初衷。共勉。
7. 国庆第7天：扫盲之后的地图——如何继续长线学习
7.1 涟漪学习法：一个概念生出一串概念
七天扫盲到这里，你脑子里应该已经有一张比较完整的概念地图了。但现实的 AI 圈每天都在产生新方向，从语音交互到具身智能，从推理优化到端侧模型，根本学不完。这时候最忌像无头苍蝇一样每天追着热点跑。我自己惯用的一个笨办法叫“涟漪学习法”：每接触一个新概念，先把它丢到已有知识框架里定位，再顺藤摸瓜找出与它相邻的三五个概念，逐个攻破。
举个例子，你今天看到“Agent”这个词，涟漪扩散出去会牵扯出“工具调用（Function Calling）”“规划与反思”“长期记忆”“环境反馈强化学习”等一串概念；再顺着“环境反馈”，又会碰到“RLHF”“偏好优化”“模拟环境”等更底层的技术。每这样扩散一轮，你脑内地图上的节点就会增多一圈，而且每个新节点都有据可依、有上下文可挂靠。学得越多，后面再吸收新概念的速度就越快——这就是扫盲型学习的复利效应。
7.2 个人 AI 工具箱：从“收藏了”到“跑通了”
这七天我一直在强调动手的重要性。扫盲最后一天，建议你花时间给自己搭建一套最小的个人 AI 工具箱，不需要多豪华，够用就行：
- 一个模型 API 账号：选一个主流大模型厂商，完成注册并跑通一次调用。
- 一个代码环境：本地装好 Python 和必要的库，或者直接用在线 Notebook 环境也行。
- 一个 RAG 小项目：准备一份自己的文档（比如你的技术笔记），做一次“提问→检索→生成”的完整链路。
- 一个 Agent Demo：用一个现成的 Agent 框架，让模型学会调用至少一个外部 API（比如查天气、查汇率）。
- 一个评测脚本：给自己做的应用写一个最基础的自动评测，记录几个固定的测试问题，每次改完版本都跑一遍。
别小看这些“玩具级别”的项目。我带过不少人从“看了很多资料”到“真正入门”，所有成功案例都有一个共同特征：在假期里跑通过至少一个端到端的小应用。收藏夹里的东西永远只是仓库，能跑起来的代码才代表你真懂了。
7.3 节后 30 天路线：从工具用户到方案设计者
节后回归正常工作节奏，你可以按这样一个 30 天路线继续爬坡：前十天，把假期搭的小工具结合工作场景做一次改造，比如用 RAG 思路给自己的团队做一个内部知识问答机器人；中间十天，关注评测和优化，把机器人从“能答”提升到“答得稳”，建立一批评测集、压低幻觉出现率；最后十天，尝试做一次技术分享，把你这一个月的实践过程整理成文档或分享给同事——输出是最好的输入，你讲得明白，才是真明白。
再往后，如果你对模型训练感兴趣，可以开始系统看微调和强化学习的入门课程；如果你对产品更感兴趣，可以尝试从商业角度评估一个 AI 功能的投入产出比。走到这一步，你已经不是一个“看热闹”的人了，而是一个有自己判断框架的 AI 实践者，比那些还在收藏各种概念清单的人领先了整整一个身位。
最后分享一个个人习惯：每年这种长假期，我都不会给自己排太满的计划，每天两三个小时足够。AI 这东西，越追越觉得追不完，但只要你把地图画出来了，以后每次看到新词，做的动作只是“定位、挂靠、延展”，而不是“从头再来”。这个假期，跑通一个 Hello World 级别的 AI 应用，比收藏一百篇文章都值。祝你玩得开心，代码跑得通。
