前阵子清理电脑里的旧笔记，翻到一份2023年初写的生成式AI入门文档。当时费了很大力气整理，把当时主流的模型架构、prompt写法、参数调优经验都写得清清楚楚。时隔一年多再看，里面至少三分之二内容已经不能直接用了——有的模型被新版本替代，有的技巧被模型自身进化给"学会"了，有的工具干脆消失在视野里。那一瞬间我突然意识到，我写的与其说是一份指南，不如说是一份"过时指南"。但转念一想，这反而有它的价值：因为大多数关于生成式AI的教程都在追赶最新，却很少有人停下来记录"哪些东西正在过时、为什么过时、过时背后说明了什么"。这本"完整过时指南"系列，就是想把一些真实的观察、原理和教训沉淀下来。第一卷我打算从"为什么AI知识折旧这么快"讲起，聊聊哪些东西值得学、哪些注定被淘汰，以及怎样在这片快速流动的领域里找到相对稳定的立足点。
1. 生成式AI领域的"知识折旧率"：为什么指南写出即过时
1.1 一次真实的"失忆"体验：我的旧文档还能用几成
2023年初那会儿，圈内流行一套固定的生成式AI应用套路：先用某种结构化prompt把模型"框"住，再配合多轮对话来引导输出，甚至还有人专门总结了一套"角色设定+任务描述+输出格式"的万能公式。我当时把这些方法奉为圭臬，写进文档里，还在团队内部分享了好几次。但到了2023年下半年，当我重新用这些方法去调一个新发布的基座模型时，发现效果并没有想象中那样明显的提升。不是我的方法错了，而是模型本身已经足够强，不再需要那么多"人工拐杖"。类似的事情反复发生之后，我开始认真盘点：一份关于生成式AI的指南，到底能保持多久的有效期？
我粗略统计了自己笔记中涉及的内容类型，大致分了这么几类：
- 具体模型的版本信息、上下文长度、价格参数：这类信息大概每3到6个月就会变一次；
- prompt工程技巧、提示词模板：随着模型能力的升级，这类技巧的"有效期"在快速缩短，部分已经内化为模型默认行为；
- 应用层框架和工具链的选择：这类变化最剧烈，经常是一年不到就换了主流方案；
- 底层原理，比如为什么生成模型需要tokenize、为什么扩散模型要一步步去噪：这类内容反而相对稳定，认识框架没有本质变化。
这个观察让我反思：我们平时说"AI变化太快"，其实并不是所有东西都在以同一速度变化。搞清楚哪些在变、哪些不变，本身就是一种元能力。
1.2 指南的价值不取决于"最新"，而取决于"解释框架"
大多数人看指南是为了拿到一个"答案"：用什么工具、怎么写prompt、调什么参数。但生成式AI领域恰恰是一个"答案会快速过期"的地方，两三个月前的最优解，今天可能只是次优解，再过半年可能连次优都算不上。如果你的学习方式只是不断追逐最新答案，那么你永远在赶路，永远在刷新认知，却始终没有沉淀出属于自己的判断体系。
这时候，一本"过时指南"反而能帮你建立更耐用的坐标系。它记录的不是"现在该怎么办"，而是"我们曾经这样想过、这样试过、这样做过，然后因为什么原因被取代了"。这种带有时间维度的记录，比单纯罗列最新工具列表更有解释力。就好比学历史的人未必能预测明天股市涨跌，但他知道今天的格局是怎么形成的，这种纵深让我们面对新消息时多了一层从容。本系列取名为"过时指南"，正是想用这种"过时"的视角，把生成式AI领域那些容易被新鲜感掩盖的真问题摊开来看。
2. 先聊那些"还很新但已经过时"的东西：一次典型的AI知识失忆
2.1 "提示词工程"的黄金时代与它的谢幕
如果说过去一年半里哪个概念过时得最快，"提示词工程"绝对首当其冲。在早期，大语言模型的能力还不够稳定，你需要精心设计一套像"咒语"一样的prompt，才能让模型稳定地输出高质量结果。当时甚至有人靠贩卖提示词模板赚钱，一套"万能prompt"能卖出不菲的价格。我认识的一位开发者——我们姑且叫他A同学，他曾在某项目中靠一段精心调校的prompt把阅读理解准确率从40%拉到80%，那时候大家都觉得这简直是一门"手艺"。
但没过多久，新一代基座模型发布后，同样一段精心设计的prompt，效果提升不再明显，甚至有时候你把prompt写得很复杂，模型反而会被一些限制条件带偏。原因倒不难理解：模型在后续训练中已经大量"看到"类似的高质量交互范式，指令遵循能力大幅提升，原本需要你手把手教的事情，它默认就能做到七八成了。也就是说，那部分"调prompt"的技能，正在从"外挂技巧"变成"模型内置能力"。
这给了我们一个非常重要的启示：凡是试图弥补模型能力短板的外部技巧，迟早会被模型自身的迭代所吸收。你可以继续研究prompt，但眼光要放长远一些——更值得关注的是"如何定义问题"，而不是"如何把指令裹得花团锦簇"。
2.2 逐渐"工具化"的微调：从少数人的屠龙术到平台内置项
在Chat类产品刚火起来那阵，"模型微调"几乎是每个团队想要落地AI能力时的必聊选项。不少公司兴冲冲地准备私有数据，计划在开源模型基础上做领域微调。我当时也调研过几条微调路径：全参数微调、LoRA、QLoRA，以及如何构造指令数据集。说实话，单是加载模型、处理显存、设置训练参数这几步就够新手折腾好几天。可是到了后来，几家主流的模型服务平台陆续推出了"免训练定制"功能——你只要上传一批结构化资料，系统就能自动构建一个专属知识库，甚至支持用自然语言维护它。对大多数业务场景来说，这种"检索增强+定制指令"的方案已经能满足需求，真正需要动手做微调的场景大幅减少。
当然，这不代表微调没有价值。对于需要改变模型风格、行为模式、输出格式的深度定制场景，微调仍然是不可替代的手段。但如果你只是想让模型"知道"你公司的某些知识，那么基于检索增强的方案通常更轻、更快、更容易维护。这个变化其实折射出一条规律：生成式AI的能力正在被平台化、产品化，以前属于少数工程师的技能，正在逐步变成普通用户点击几下就能调用的服务。判断技术方向时，多问一句"这个能力是否正在向平台层下沉"，能帮你避开很多过度投入。
2.3 参数之美：那些曾经被反复"调优"的超参数
还有一个很有趣的过时案例，就是生成参数。早些时候，关于温度、top_p、frequency_penalty这类采样参数的调优文章满天飞。大家会根据任务类型手动设置一套"最佳参数"，比如写代码用低温保证确定性，写文案用高温增加创意性。我也曾在某个项目中，花了整整两天，扫描不同temperature取值下的生成效果，试图找出那个"完美温度"。
但现在回头看，那次调参投入产出比并不高——因为采样参数的作用，远不如任务本身的定义、上下文的质量、以及模型能力上限来得重要。许多新一代模型还在默认参数下就已经表现良好，而且平台层往往内置了基于场景的推荐配置，你甚至不需要理解top_k和top_p的区别。这并不是说参数不重要，而是说"最优参数"本身是一个不断漂移的目标，过度迷恋调参，反而容易忽略真正决定生成质量的变量：数据与指令设计。
3. 比起单词的更新，更值得抓住的是生成式AI的不变骨架
3.1 为什么"骨架"比"细节"更耐旧
写过长期运营项目的朋友应该都有体会：如果项目文档只记录"我们用了某个库的某个API"，那这份文档很快就会失效；但如果文档记录了"我们要解决某个问题，为什么选用这个方案，这个方案在什么条件下成立"，它的生命力会长得多。生成式AI的知识也一样。具体的模型版本、API接口、参数配置都是树叶，风一吹就掉；而底层的计算范式、模型架构思想、能力边界评估方法，则是树干，不容易随着季节更替。
我在整理过去一年的文章和笔记时，发现那些当初觉得"不够干货"的底层原理类内容，反而到现在依然能解释很多现象。比如我写过一篇关于注意力机制的文章，当时阅读量一般，但现在有人问我"为什么模型能理解长篇文章"，我还是会让他去看那篇。因为无论模型换了几代，loosely speaking，核心始终是"让模型学会在输入序列中关注该关注的信息"。理解这一点，你就更容易看懂为什么上下文窗口越来越长是一个趋势，也更明白"长上下文≠真正理解"，这两个概念根本没有因为新模型发布就自动划上等号。
3.2 骨架之一：Token、上下文与"理解"的边界
我们经常听到一句话："大模型理解自然语言"。"理解"这个词容易让人产生拟人化联想，实际上，模型处理的是Token，你可以把它理解成语言碎片的编号。模型本身并没有人类意义上的"世界观"，它只是根据统计规律，在给定Token序列后预测下一个Token最可能是什么。所谓"上下文窗口"，就是模型一次能"看到"的Token数量上限。很多新用户会把上下文窗口理解成"模型记忆力"，总觉得只要窗口够长，模型就一定记得所有对话内容。但从使用经验来看，长窗口并不等于高质量利用——如果输入的关键信息埋在数万字中间，模型同样会"顾此失彼"，与人类浏览超长文档时的注意力衰减很类似。
理解"Token/上下文/注意力的边界"这一组概念，你就不会被各种夸大宣传牵着走。你会自然而然地去检查：我的核心指令是否在上下文较早位置？有没有被大量无关内容稀释？是否需要对关键内容做重复强调？这种能力，不会因为某个新模型发布而失效。
3.3 骨架之二：预训练与对齐，为什么"底子好"和"听话"是两回事
另一个值得理解的不变框架是"预训练+对齐"两段式。预训练阶段，模型在海量语料上学习语言统计规律，相当于一个学生读了万卷书，拥有了庞大的知识底子；对齐阶段，则是通过指令微调、人类反馈强化学习等方式，让模型学会"如何与人类对话"。这两种能力不一定同步增长：一个博闻强记的模型，未必天然懂得"在拒绝用户的时候要礼貌"；一个特别擅长聊天的模型，也未必每个事实陈述都准确。
带着这个框架去看各种模型测评和表现差异，很多疑惑都能解开。比如为什么某个模型在百科类问题上表现出色，但在多轮对话中容易"偏题"？大概率是其对齐训练针对单轮指令做了更多优化。为什么另一个模型知识更新不快，但"边界感"很好，遇到不知道的领域会明确说不知道？这往往是负责任的对齐设计所致。当你不再把模型当作一个统一的"智力体"，而是看作"预训练底子+对齐风格"的组合物，你在选择模型和制定使用策略时就会更精准：先考察底子能不能覆盖我的知识需求，再考察对齐风格适不适合我的交互场景。
3.4 骨架之三：生成机制与"幻觉"的必然性
与生成式AI打交道，绕不开"幻觉"问题——模型一本正经地输出一段看起来可信、实际并不真实的内容。很多人第一次遇到时很震惊，以为是模型"坏了"。其实从生成机制上看，幻觉几乎是统计生成的必然副作用。模型本身不掌握"事实数据库"，它生成的是"基于上下文最可能的Token序列"；当某个片段的统计规律足够强烈，模型就会输出它，哪怕它偏离事实。
理解这一点，你会自动调整使用策略：重要事实类内容，不要依赖模型"回忆"，要让模型"查阅"——也就是把权威信息放在上下文里，或者接上检索工具；涉及专业判断的生成结果，必须由人做最终核对。这套防范意识是通用的，不管模型迭代到第几代，也不管主流产品叫什么名字，"生成概率性内容"这个本质不会变。所以，把"幻觉管理"当成一项长期能力来建设，而不是等着某个新模型来一劳永逸地解决它，这才是务实的做法。
4. 除了模型本身：那些同样疯狂变化又同样重要的周边要素
4.1 数据：真正决定上限的"燃料"
很多人聊生成式AI，注意力全放在模型上，却低估了数据的杠杆作用。说到底，模型只是一个函数，它的输出质量受限于输入上下文中给定的数据质量。同一款模型，一边喂给它结构混乱、自相矛盾的资料，另一边喂给它分类清晰、交叉验证过的知识库，生成结果能差出好几个量级。这个感受是我在某智能客服项目中得到的——初期我们只做了简单数据清洗，模型回答时不时出现口径不一的问题；后来我们把高频问题的标准答案沉淀成体系，再配合检索增强，准确率立刻上了一个台阶。那个项目用的模型中途换过好几代，但"数据治理"始终是决定体验的关键。
如果你想在自己的项目里复现这个经验，可以从三个角度入手：第一，明确"答案的来源层级"——哪些问题用标准问答库直接回答，哪些需要摘录文档片段，哪些必须转人工；第二，对文档做结构化整理，切出高质量的知识切片，并给每个切片打上必要的元信息（适用范围、更新时间、优先级）；第三，建立反馈闭环，每一次用户纠错、人工修正都不应该白白流失，它们是最好的数据资产。这三件事，跨越模型迭代、平台迁移，都成立。
4.2 算力与成本：一份容易被忽视的"隐形指南"
生成式AI应用不只是算法问题，还是工程问题。成本意识会直接影响你对技术方案的取舍。举个例子，某图像生成项目早期，为了追求效果，我们统一用大尺寸、多步数生成，效果确实好，但单张图片的成本也感人。后来在方案评审中，我们细算了各档配置的参数与成本，决定采用"小图粗选+大图精修"的两段式流程：先快速生成若干候选图，再只对筛选出来的少数候选做高分辨率精细生成。整体效果几乎没有下降，成本却省了大半。
这种"成本感知"式的工程优化，不会因为模型涨价或降价而过时。相反，模型越强大，资源开销的波动就越大，你对成本模型的理解就越有价值。建议每个做生成式AI应用的人，都建立一个简单的成本测算表，涵盖模型调用费用、存储费用、人工审核成本、失败重试成本等，并在每次方案选型时把成本作为一等公民纳入决策，而不是最后才补算。
4.3 评测：没有"结果丈量"，一切"最佳实践"都是自我感动
还有一个被严重低估的维度是评测。我见过太多团队在演示时被模型的惊艳输出所打动，就以为产品已经ready了；结果一上真实流量，各种长尾问题冒出来，体验一落千丈。评测的稀缺性不在于"跑几个测试集"，而在于你能不能定义"什么输出是好的"。生成式AI的答案往往是开放式、多样化的，"好"和"坏"之间存在大量灰色地带，传统的准确率指标并不完全适用。
我的经验是分三层建立评测基准。第一层是客观可判：比如格式是否正确、是否包含违禁词、是否在规定时间内返回；第二层是规则可判：比如关键信息是否出现、引用来源是否存在；第三层是主观感受：比如表达的流畅度、语气是否合适，这层可以借助评分量表来人工抽样。每一层跑完后都要把问题归类，反推数据对策或指令对策。这套评测框架，同样不以某个具体模型为转移，它能陪着你的项目跨越一次次的模型换新。
5. 怎样在"随时过时"的领域里保持清醒：给同行者的几条建议
5.1 刻意练习"读变更日志"：让过时成为你的信号源
在生成式AI领域，最不值得做的事情就是焦虑，最值得做的是习惯变化。一个很实用的习惯是，每当一个新技术产品发布或更新时，不要只看营销式的"重大升级"，而是专门看它的"变更日志"和"迁移指南"。这些文档往往藏着你之前依赖的某个能力被改变、被合并甚至被废弃的蛛丝马迹。阅读变更日志，本质上是在和"过时"打交道：它提醒你，旧的认知已经不再成立，新的假设正在登场。
我通常会把变更日志中影响较大的条目做摘录，并顺手更新自己的笔记体系。如果发现自己某个旧项目用到的能力被标记为"废弃"，那就主动推进迁移，而不是假装没看见。这种主动面对过时的态度，反而让技术追新这件事变得轻松——你不是在疲于奔命地追，而是在有节奏地校准方向。
5.2 建立"可迁移的经验"储备库
随着接触的项目越来越多，我发现真正能反复带走的能力，往往不在某个具体模型上。于是我做了一个分类：将经验分成"模型相关"和"模型无关"两类。模型相关部分，比如某个模型的参数字段含义、某个API的接入方式，直接跟着官方文档走就行，不值得花太多精力手写教程；模型无关部分，比如如何定义评估指标、如何设计高质量数据切片、如何做长上下文的注意力管理、如何控制生成成本与人工复核的平衡，这些才是需要投入时间沉淀的。
这本笔记我取名为"可迁移经验库"，它不看任何具体模型的脸色，只记录那些相比之下更稳定的工程原则。每当新项目需要选型，我掏出这个知识库来对照，而不是上网连夜搜最新教程，心里会踏实很多。也建议每位从业者尽早开始这样的沉淀，它不会像单一工具技巧那样快速贬值，而是随时间推移越积越厚。
5.3 跟着问题走，而不是跟着名词走
最后一条建议有点像是给自己写的座右铭：在生成式AI的潮水退去后，能留下来的不是那些追逐热词的人，而是能稳稳解决实际问题的人。每天都有新名词冒出来——智能体、多模态、RAG、微调、推理时缩放，它们每一个都对应一类真实问题的尝试性解法，而不是荣誉勋章。当你想学习一个新概念时，不妨先问自己：它到底解决什么问题？这个问题现在有多痛？如果没有它，我还有哪些替代方案？这种方法能把"追新"变成"探路"，把浮躁的资讯消费变成脚踏实地的能力建设。
本系列后续，我会接着聊图像生成、语音生成、多模态应用，以及一些更细致的工程案例。它们都会以"过时指南"的面貌出现——记录那些参数、工具和"最佳实践"如何被时间的潮水冲刷，也沉淀那些经得起换代的认知框架。如果你也愿意用这种"过时"的视角来审视自己正在做的项目，那么这本指南，也许刚开始"过时"，就已经派上了用场。
