那是一个普通的周末。那是一个普通的阴天。那是一次普通的机会，我们出去玩，去街上转悠。

但我至今忘不了出那个地铁口时的场景。

那是一座普通的地铁站出口。那是一个普通的路口。那是一个普通的广场。普通到和我在合肥上课、在哈尔滨参加活动时下车的感觉都一样。

呵，我在哈尔滨都没有做过地铁。

我其实不知道为什么我会记得这个场景。我甚至都不知道它为什么会躺在我的备忘录里成为一篇待写的手记。

但它就普普通通的在那儿。

于是我就普普通通的写了。

事情的背景是我在b站偶然刷到一条影评家对某篇奥斯卡奖电影的痛批。我一直觉得，游戏和电影这两种媒介之间存在着一种微妙的不对称。同样是娱乐，同样逐渐被承认为新兴艺术形式，电影拥有从《电影手册》到三大电影节的完整批评体系，而游戏——尤其是那些明明具有电影般叙事表达力的作品——似乎始终没有得到应得的严肃对待。

这里需要先做一个区分：我说的并不是那些以竞技和换皮为核心的长线运营作品；如果我记得写了的话，关联阅读里应该会有一篇，讲的就是我对游戏本质不同的看法。我想说的是，这些作品和那些以营收为生命线的手游，根本不是一个物种。那些游戏的本质是用劳动密集的美工，流水线式的亚文化换长期稳定的氪金流水；而我想说的是，像星际拓荒那样从大学毕设到现象级，像无人深空那样一次买断十年更新的手作经典。游戏本身天然带着空中更新的动态和初体验震撼的静态感，而我们讨论的就是那些不同于电影那样一锤子买卖的长期作品，也不至于流水换流水的买断生意。

但问题在于，不管这类游戏多引人深思，批评界仍然会下意识地将它归入"游戏"这个大类，和长线运营或者罐头游戏放在一起讨论。电影的媒介从一开始就自带艺术属性，再烂的商业片也是艺术；反观游戏界，哪怕游戏再好、玩家基数再多，却迟迟没有严肃客观的批评体系建立起来。很多时候，游戏媒体被那些高营收的抽卡手游和大厂堆料的工业罐头的宣发预算绑架，变成了导购渠道；而在学术界，整个环境依然没有把游戏批评当成一门正经的学问。

从一段聊天记录说起

前阵子我把 迷走深空：碎舰师 安利给了一个朋友。这款游戏的开场有一首童声念的诗：

每天走进工作区，

辛勤劳作挣所需，

我向上天常祈祷，

愿父归来乐陶陶，

若有一日他归尘，

但求福伴后继人。

我问他，你觉得为什么这段诗要用童声？

朋友说，他有一种末日感。

我没有满足于这个答案。这个游戏的环境是太空，特点是科技，但它的背景真的是未来吗？我觉得不是，是过去。与其说它是未来科技巨头垄断一切，不如说是换了皮的封建剥削。LYNX公司把碎舰包装成宏大事业，而求职者连基础服务都负担不起。所谓克隆提取技术，说明里白纸黑字写着，该过程会摧毁你的原始身体。在童声里，唯一暂时逃过一劫的，是还没有劳动能力的孩子。朋友说那是末日，我说那更像一种绝望与无力，只不过坐标轴被拉大了而已。我们甚至停下来讨论，用末日这个词描述感受到底准不准。不是抬杠，而是想警惕语言本身对思维的扭曲。

后来我又看到一条网上评论：在切割船板的时候，听到那德州风味的木吉他，衬在深空的白噪音上，时不时被焊枪的声音盖过去，心里的情绪真的难以言喻。音乐表层处处是科技、未来、太空的进步，内里却是和现实相近、甚至倒退回奴隶制和封建时代的社会关系。

我想说的是，以上这些，就是游戏评论。没有人布置作业，没有评分，没有稿费，两个玩家加上一个匿名网友，在深夜里做的事情，和影评人的拉片、文本细读、主题阐释，没有任何本质区别。

玩家社区的评价从来不是单一的。有人从叙事层面切入，像我和朋友聊碎舰师那样，把游戏当成文本分析它的隐喻和意识形态。有人关注玩法设计，讨论关卡结构是不是自洽，机制有没有传达它想传达的东西。有人在意音乐和美术的整体氛围，就像那位网友注意到木吉他和白噪音的叠置。还有人纯粹从个人情感出发——"我有一种末日感"——这本身就是一种非常真实的批评直觉，只是没有被打磨成学术语言而已。

问题是，这种多元的、自下而上的评价体系，始终没有被正视为"批评"。它被当成"感想"、"心得"、"测评"——好像只要是从玩家嘴里说出来的，就不配被叫做"批评"。

这些文字的质量，就我个人而言，很难给出中肯的评价。但我自认为这些至少满怀玩家心血的东西，不应该只能屈尊于诸如 Steam 小黑盒这样的宣发平台，和"优化不行""闪退""建议打折再买"的评论混在一起。我们其实早就在做游戏批评了。只是我们没意识到自己在做这件事，整个行业也没意识到。而始于 UGC（User-generated content）但不止 UGC，是我接下来想说的期许。

学术界为什么还没正视这件事

电影有影评体系，这不是天上掉下来的。它是一百多年来，学术界、媒体、产业三方慢慢建起来的。大学里有电影研究专业，学术期刊上有电影理论论文，电影节上有专门的批评单元，《电影手册》这种刊物可以靠纯学术话语影响一代导演。

游戏呢？游戏研究在绝大多数高校里根本不存在，或者被塞在"数字媒体""交互设计"这类专业下面当一门选修课。你很难找到一个叫"游戏批评学"的学科方向。更重要的是，学术界对游戏的理解本身就存在分裂：一部分人把它当软件工程在研究，另一部分人把它当社会现象在观察，真正从"游戏作为一种艺术媒介"的角度去严肃分析其交互叙事、视听语言和机制隐喻的研究，少之又少。

这不完全是学术界的问题。游戏这个媒介本身就比电影复杂——电影是线性的、被动的，你分析镜头、叙事、表演就行。游戏的核心是交互，玩家的行为本身就是内容的一部分，传统的"作者-作品-观众"分析框架根本套不上去。批评的方法论得重新发明，这太难了。

但更难的是另一个原因：游戏行业太赚钱了。这句话听起来像夸，但其实是阻碍。

电影行业也赚钱，但电影有一套独立于票房之外的艺术认证机制。一部文艺片票房惨淡，不影响它在戛纳拿奖，不影响影评人认真对待它。与此同时，主流的游戏评测生态被商业逻辑彻底绑定了。你需要明白一个关键事实：营收占比和玩家基数、产品质量完全是两码事。那些以叙事和艺术表达为核心的优秀作品，玩家群体极其庞大，每年产出的高质量作品数量也不少。但那些抽卡手游、长线网游营收太高了，厂商的宣发预算极其夸张，游戏媒体得罪不起大金主——否则连提前评测的资格都没了。所以大多数游戏媒体最后都变成了导购或宣发渠道，很难沉下心做严肃的、甚至带点批判性的艺术评论。

玩家社区的习惯也加剧了这个问题。主流话语里，游戏讨论更常见的是通关攻略、剧情梳理、bug吐槽、版本强度排行。这些当然有价值，但它们不是批评。我们很少看到有哪个玩家社区会把一款游戏像影迷拉片那样逐帧拆解，去分析它的关卡设计如何隐喻、交互叙事如何传达主题、音画语言如何制造反差。不是没人做，而是没有形成气候，没有形成体系。

所以现状就很尴尬：玩家自己做的批评散落在碎片里，学术界还没真正下场，而最有钱的媒体在做导购。三个层面都在各自的轨道上跑，没有交汇，没有合力。

路在何方

路在脚下

但我不是一个悲观的人。回到我和朋友的那段聊天。

那天晚上，一个普通玩家对另一个普通玩家，用几千字拆解了一款游戏的政治隐喻、叙事结构和音乐设计。没有稿费，没有发表平台，没有任何功利目的。他就是有话想说。

这就是 UGC 的力量。当产业和学术都还没准备好正视游戏批评的时候，玩家自己已经开始了。Steam 评论区、知乎、B 站、个人博客、播客——这些散落在各处的文字和声音，其实就是游戏批评的原始形态。以Steam评论为例。它是UGC，是用户生成内容，本质上是大众化的。但它的机制设计很巧妙：推荐与不推荐的二元判断降低了写作门槛，但评论本身没有字数上限。一个玩家可以写三百字短评，也可以写三千字长文。更重要的是，"有价值"投票机制让真正有洞见的评论浮上来，而不是像社交媒体那样纯粹比拼转发量。

它们当然不完美。质量参差不齐，缺乏编辑把关，很容易被情绪和阵营对立裹挟。但它们的价值在于，它们证明了游戏批评的需求是真实存在的。不是"玩家需要有人告诉他们值不值得买"，而是"玩家需要有人帮他们把玩完游戏之后那些说不清的感受，变成能说清的语言"。

我和朋友做到了这一点。Steam 上那些长评也在帮更多人做到这一点。

所以路在脚下——个人的表达自由，Steam 评论区，这些就是我们已有的东西。它们不应该是游戏批评的终点，而是起点。每一个认真分析一款游戏的玩家，都在为这个领域添一块砖。

路在远方

但如果只停留在 UGC 层面，游戏批评永远只能是散兵游勇。正如 Steam 的"有价值"投票很容易被"有用/搞笑/钓鱼"等情绪性二选一投票扭曲，真正的长文批评往往被笑话评论踩在脚下。

我们需要的远方是什么？

第一，独立的批评平台。这不是说再做一个游戏评分网站，而是需要一些真正独立于厂商之外、以批评本身为核心价值的阵地。它可以是媒体，可以是学术期刊，可以是一个社区。关键是它的评价体系不以流量和带货为导向，而是以批评的深度和独立性为标准。这个平台能不能商业化我不确定，但它至少需要拥有说真话的权力和传播力。TGA现在是最有影响力的行业盛典，但它的核心定位仍然是商业秀和玩家狂欢，缺乏真正独立、严肃、只探讨交互内核和视听语言的批评维度。这不是说TGA不好，而是说批评需要另一种生态。

第二，学术界应该入场。我知道这句话说出来容易，操作起来很难——没有学科基础、没有师资、没有方法论。但所有学科都是从零开始的。电影研究在 1950 年代之前也没什么像样的学术地位。当足够多的高质量作品出现了，当足够多的玩家已经开始自发地做分析了，学术界再装看不见，就有点说不过去了。

游戏不是没有值得研究的东西。《星际拓荒》的叙事结构与认知哲学，《死亡搁浅》的连接机制与社会隐喻，《冰汽时代》的对话系统与意识形态批评，《碎舰师》的劳动异化与音乐反差——这些东西的深度，不输给任何一部被写进论文的电影。

游戏作为一种交互媒介，其叙事方式、机制隐喻、视听语言和情感传达方式，都与电影有本质差异，不能简单套用电影理论。学界需要发展出真正适用于交互媒介的批评方法论——如何分析一个关卡设计的政治隐喻？如何评价一种交互机制对玩家共情的操控？如何理解玩家行为本身作为"文本"的批评价值？这些问题比传统影视批评复杂得多，但也正因为复杂，才更需要严肃的学术投入。

第三，也是最难的：行业需要接受批评。这不是说厂商要"虚心听取玩家意见"——那是客服逻辑，不是批评逻辑。我指的是，整个行业需要承认，游戏可以被严肃地、甚至尖锐地批评，这不会伤害游戏的价值，反而会提升它。就像电影行业已经学会的那样，被骂的艺术片也是艺术片。《明日方舟：终末地》的流水线系统做得稀烂，但却能给只玩抽卡二游的玩家“我也能玩自动化”的信心，给抠抠搜搜的男大原价入库《幸福工厂》的勇气。任何作品都不可能做到十全十美，但一针见血的批评绝非贬损，而是对热爱的事物日臻完美的期许。

结语

前几天我又听了一遍《碎舰师》的原声。还是那把木吉他，还是精切器那令人发毛的金属气化声，还是拉出反应堆后定时熔毁的 Tension Remix。

我突然想到一件事：那种音乐里读出来的"过去和未来都不值得想象"，其实也可以反过来理解。正因为两头都不行，所以路只能在脚下，只能在现在。

游戏评论的路也是一样。往回看，没有百年积淀的影评传统可以照搬。往前看，成熟的批评平台和学术体系还远没有成型。但往回和往前都不重要。重要的是现在——Steam 上那些长评还在被写出来，私聊窗口里还有人在认真分析一首童声诗，播客里还有人花两个小时讨论一款独立游戏的叙事设计。

这些就是路。这些已经是路了。从UGC到产业化，中间隔着的不是能力的鸿沟，而仅仅是承认的延迟。深夜的聊天记录不会被收进任何选集，但它们是真实存在的批评现场。等学术界回头的那一天，他们要做的大概不是从零开始建造，而是为已经发生的一切正名。

只是我们还需要更多人承认，这条路值得走。

又做梦了。 上次做一个让我有回忆的梦还是是梦到自己变成了mc里的玩家，在似乎是跑酷地图的一个世界里开神龙套乱飞；也是我在那次梦醒来之后用语音完整地记下了梦到的内容（也许会放上来），并萌生了写一篇讨论梦的博客的想法。谁知录音积压在备忘录还没来得及写，就又做了另一个梦。既然刚醒，脑子里或许还残留着一点做梦的思维模式（甚至回忆之前的梦也更熟悉一些），就一鼓作气把这篇手记写了吧。

===

其实近年来，我感觉到我的做梦频率并不如从前高。或许是因为过去的记忆犹如近大远小般被压缩显得密度更高，但我觉得学业压力的上涨使得我少有彻底放松休息的机会才是主要原因。在还热乎的记忆里，几乎每次做梦都是在那种可有可无的睡眠中，比如午睡或是下午/晚上提早睡，睡到晚上睡觉前就醒。听说做梦是在浅层睡眠期间，也许正是因为这种是“额外”的睡眠，大脑比晚上睡觉时更活跃，所以更容易做梦？我不确定。但总而言之，最近我甚至拿会不会做梦来判断我睡得足不足——至少对于我，连续忙活了好几天，倒头就睡的那种睡眠是不会伴随梦的。希望以后我都能睡饱，“做个好梦”吧。

突然想到一则故事。一段甜腻酸臭的爱情，一方生命所剩无几而另一方青涩笨拙（酸臭在这儿）地回应；入夜时分，后者每每向前者道晚安，前者都应以“好梦”；直到那最后一次，前者再无遗憾的口中道出的“晚安”似是在宽慰自己的长眠。但凡借力生命价值的桥段往往都能博取泪花一片；但无论如何，也许这正说明梦是尚有变数，而晚则落定当安吧。

那么我究竟梦到了什么呢？尚能想起来的部分就只有（尤其是开头已经不太记得了）：熊孩子干坏事被我抓到把柄，但直到惊动记者发布会家长仍在事不关己地游荡；而当我迫使身为大领导的家长站到台前，他却在台下记者反应过来前便大事化小小事化了借口忙碌遁走了。气极的我跑出会场，才发现地下（物理）会场上方的校园里正举行国庆或是什么仪式——又是形式主义盖过实干？无奈的我在校园里转悠，转到道路左侧的人行连廊中断的一处左转弯路段，道路两旁的施工围栏遮挡着本就尘土飞扬的视野，时常驶过的大车使我心惊胆战。最后我不得不伸出右臂不停挥舞，毕竟撞到手臂总好过撞大运咯~吧。好容易到了下一段人行连廊入口，师傅满口答应我会向上汇报这段缺失，但我远去时又说只是底层反馈并不抱太大希望。想来可笑：我当时感到一阵寒意，原来随处可见的学生会办传送阵营造了直达天听的假象，但本以为是学生会核心的传送目的地或许只是一个对外联络处；我都没有反应过来，为什么都随处可见传送阵了还没发现是梦啊喂！直到我醒来才发现，原来以为嗓子哑了喊不出来是因为梦中没能真正喊出口而缺少喊叫时喉咙的感觉反馈。

不过我发现，做梦时经常会感觉到环境无比熟悉，清醒后才会发现有太多的不合理。这也许是梦的本质决定：本就是自己脑海中的场景拼接而成，刚刚用过来构造场景的记忆自然会感觉无比熟悉。

有时就是这样：越是实际可行的建议越容易被否决。倒也不必归咎于可行的建议持有更大的利益冲突，我更倾向于解释为过分可行的建议会给“利益相关方”更大的即时冲击，而留有讨论余地不仅能让他人有时间接受，更能使“我认为合理”的方案在讨论中成熟为“大家都能接受”的。

也许我并没有说清楚我梦到了什么，但这个问题的答案或许已经无关紧要。且不论对梦的内容尚且清楚同时已经清醒的时间往往只有刚醒过来的那十几分钟；上文那样一字不落的描述下来我想也其实并没有人多感兴趣：究其根本梦本就是不可描述的存在啊。人与人之间的交流依赖语言，而为保持高效在语言之外的许多内容便要仰赖基于个人经验的联想了。现实生活中的交流尚且无碍：大家都生活在地球上，有着相似的环境感知，因而语言之外的不言自明所指尚且相仿；然而在一切皆有可能的梦境，基于现实生活的联想便成人际交流间最大的阻碍。尤其是像我这样不善表达，日常交流中都要常常依靠“你应该懂我意思吧”的人，首段mc那样的描述已经是我以为最有效的表达了。

何况为什么要搞清楚一切的意义呢？我上次还在想，也许在mc中畅游是对自由的渴望，抑或对生活不满的映照？但回顾刚才梦到的，似乎并不是处处都有相应的现实写照吧。又是意义！又有人要骂虚无主义了。这只是手记，何必事事上纲上线呢。

所以梦究竟是什么呢？借用AI对话的管理，就是大脑偶尔单开一个会话吧；AI随时重置，人生不能重来。愿你在这花花世界，也能安心归家，做个好梦。

嘿嘿，我又来喷前端了~

背景信息是大家现在在看的这个博客（Mix Space + Shiro）在 LLM 越来越贵的现在被原开发者 @Innei 从闭源 Shiroi 到直接弃坑变 Yohaku，前后端同步更新加上不再维护的 Shiro 仍然小bug不断，迫使我不得不自己 fork 大型魔改。然后在被各种缓存和优化问题拍打得体无完肤后，我忍不了了：

SSR 的背景

React 变成 Vercel 的技术壁垒的破事儿也众所周知了，这里不再赘述；我们就简单说说 SSR 是怎么把你和 Vercel 强绑定的。

计算

Vercel 的核心卖点之一是分布式渲染——你的 SSR 请求被扔到离用户最近的边缘节点上执行，TTFB 短，渲染快。这给了你一个错觉：好像不需要怎么优化缓存，反正每次请求都是边缘节点实时渲染，快得很。

但问题在于，这个"快"是 Vercel 的基础设施在扛，不是你的代码在扛。一旦你离开这套体系，SSR 的 CPU 压力立刻变成单点瓶颈——一台机器上跑 Node，每个请求都要完整渲染一遍 React 组件树，QPS 一高就开始排队。分布式渲染把计算压力分散到了全球几百个边缘节点上，而你自己部署就是把这些压力全堆到一两个源站上，差距不是线性的，是指数级的。

你以前不用操心的事情，现在全都要自己操心。

网络

Vercel 的边缘网络是它真正的护城河。用户在任何地方访问，都能就近命中一个 POP 节点，TLS 握手在毫秒级完成。这个网络基础设施不是你买两台 ECS、挂个 Nginx 就能复现的。

SSR 的场景特别吃网络延迟——因为每次请求都要回源渲染，不像纯静态资源可以提前推到 CDN。所以"边缘计算"对你来说不只是计算在哪里跑的问题，更是用户到你的服务器之间的网络路径有多短的问题。你自己部署 Node，用户在广东访问你北京的机房，RTT 30-50ms 起步，加上 SSR 渲染时间，TTFB 直接破百毫秒。

Vercel 卖的不是算力，是算力+网络的一体化交付。你离开它，这两个都得自己补。

开发

自带 CI/CD、一键部署、Preview Deployment、域名自动配 HTTPS…… 这些开发体验确实是 Vercel 的早期优势。但说实话，到 2024 年了，GitHub Actions + Docker + 任意容器平台的组合已经足够成熟，CI/CD 不再是什么稀缺能力。这个曾经的主要卖点，现在已经不构成绑定的理由了。

真正的绑定还是在计算和网络这两层——你的代码架构是按 SSR 设计的，部署时就绕不开"谁来分布式渲染"和"谁来边缘加速"这两个问题。

SSR 的历史

当年的 “SSR”

传统 Perl、JSP、ASP.NET，以至不那么老的 PHP、Django——哪个不是服务端渲染？服务器收到请求，拼好 HTML，扔回浏览器，完事。

这套东西跑了十几年，没有人管它叫"SSR"。因为它就是唯一的前端模式，不需要一个名字来和别的模式区分。

SSR 这个词本身不是什么新概念，它是被 React 生态重新发明出来的营销词汇。

Node 前期 SPA 的坑

然后 Node.js 来了，React/Vue 来了，SPA（Single Page Application）来了。浏览器下载一个 JS bundle，在客户端渲染整个页面，路由切换不刷新，体验丝滑。

但 SPA 的坑很快暴露：

• 首页白屏：浏览器要先下载几百 KB 的 JS bundle，然后执行，然后才渲染出页面。JS bundle 没下载完之前，页面是空的。用户盯着白屏等，体验极差。
• SEO 直接死掉：爬虫拿到的 HTML 是个空壳 <div id="root"></div>，内容全靠 JS 执行后才有。Google 爬虫虽然能执行 JS，但抓取效率和权重评估都受影响，百度更别提了。
• 无 JS 环境直接爆炸：禁用 JS、爬虫不支持 JS、低端设备 JS 执行慢，老旧 WebView 没法更新——这些场景下 SPA 就是白板。

这时候大家回头一看：哎？PHP 那套跑得不是挺好的吗？于是 SSR 又被请回来了。

后 SPA 时代的 SSR

Next.js / Nuxt.js 横空出世，提出了"现代 SSR"的概念：首屏在服务端渲染 HTML，之后在客户端 hydrate（水合），接管后续交互变成 SPA。 同构 JavaScript——一套代码既跑在服务器上也跑在浏览器上。

听起来完美：SEO 有了，首屏速度有了，SPA 的交互体验也保住了。

但，代价是什么呢？

1. 技术上越来越重：同一份组件，服务器跑一遍生成 HTML，浏览器再跑一遍做 hydration——等于做了两遍渲染。hydration 本身也有不小的 CPU 开销，低端设备上尤其明显。

2. 同构模糊了运行时的边界：你写的是"一套代码"，但它跑在两个截然不同的环境里。这个抽象在初期确实省事，但一旦你需要精细控制——哪段逻辑只在服务端跑、哪个组件不要水合、哪个 hook 在两端行为不同——心智模型立刻就裂开了。

这不是 SSR 这个模式的问题，而是"既要 SSR 的首屏和 SEO，又要 SPA 的交互体验"这个缝合过程本身的成本。技术演进到这里，复杂度自然会上来。

终极大坑：过度追求同构

前面说了性能层面的代价，但我想说的核心问题是认知成本。

同构的卖点是"一套代码跑两端"。前期开发确实快——你写一个组件，服务端渲染 HTML，客户端水合接管，看起来自然而然就 work 了。

但两端的环境本质上就是不同的。你强行用一层抽象去抹平差异，等于在中间塞了一个巨大的"假装它们一样"的胶水层。

一旦你需要做任何精细控制：

• 这段逻辑只在服务端跑（直接查数据库）
• 这个组件不要水合（纯展示，省 CPU）
• 这个组件水合但它的子组件不要
• 这个 hook 在服务端和客户端行为不一样
• 服务端和客户端渲染结果不一致导致 hydration mismatch（排查起来极其痛苦，错误信息模糊）

你就裂开了：你不再只是写 React 组件，你得时刻清楚"我现在写的这段代码，到底在哪个运行时里、什么时候被执行、被执行几次"。这个上下文切换的负担非常大。

对比传统 PHP 模式：后端就是后端，前端就是前端，各写各的，边界清晰。你优化的时候不需要考虑"这段代码会不会在另一个运行时里产生副作用"。简单粗暴，但认知成本可控。

同构用抽象帮你省了初期的胶水代码，代价是把复杂度转移到了运行时行为的不确定性上。一旦你需要精细控制，这层抽象就从"帮你省事"变成"挡你的路"。这也是为什么后来 React Server Components、Astro（默认不水合、显式标记才水合）这些新方向都在试图把这个代价降下来——让同构从"默认全开"变成"按需付出"。

不只是客户端和服务端的同构有问题，Node.js 本身也有这个倾向。 前端开发写 JS，后端开发也写 JS，全栈门槛确实降低了。Node.js 本身作为一个服务端运行时，和浏览器共享了 JS 语言层，但网络 API、文件系统、进程模型、模块系统全都不一样。全栈 JS 的全栈在于只需要会一个语言的语法就能写两套完全不同的系统，但在 AI 接管底层语法实现的当下，这层优势正在变得日益薄弱。

本质上这是一个"前期开发效率 vs 后期优化复杂度"的权衡。同构用抽象帮你省了初期的胶水代码，但把复杂度转移到了真正理解运行时行为的不确定性上。

如何去 Vercel 化

浅层：换边缘计算提供商

换个地方继续受同样的苦。阿里云函数计算、AWS Lambda——本质上还是 Serverless 那套，只是换了个厂商。你确实摆脱了 Vercel，但你仍然面临：

• 冷启动问题（Next.js 镜像不小，冷启动几百毫秒到几秒）
• 成本不可控（SSR 请求时长 × 调用次数，流量上去了费用可能远超预期）
• 需要定制化适配（函数计算有自己的 handler 模式，不是直接 next start）

深层：换设计思路

真正的问题不是"谁来替我跑 SSR"，而是你到底需不需要 SSR。这才是真正的解法。别 all-in xxx.js 全栈了——

前后端分离

后端该用 Go/Java/Python 就用，做你擅长的事——API、鉴权、数据库。Next.js/React 退回到它真正擅长的领域：前端。

动静态分离

如果你的内容是公开的、需要被搜索引擎索引，那 SEO 是硬需求。但一个纯内容展示的页面，为什么不直接静态生成？上 CDN 直接缓存，零回源，全球秒开，不比 SSR 香多了？

如果你的内容是动态的、高度个性化的，这确实是实时渲染的主场，但这类页面（个人中心、推荐流）恰恰是不需要 SEO 的，用 CSR SPA 就完事了。

只有你的内容两者各占一半：公开的、需要被搜索引擎索引；但又实时更新，不想让陈旧数据留太久——那SSR确实是唯一的解药——当且仅当你完全看不上（找不到地方学）PHP/Django 这种稍显老旧但仍旧坚挺的框架的时候。

前后端分离不是倒退，是把复杂度放到它该在的地方。 后端老老实实写 API，前端按需选择渲染策略，就不会把所有东西塞进一个同构的 SSR 框架里，然后在hydration mismatch 和缓存策略的泥潭里挣扎。

结语

SSR 不是原罪，但在错误的地方过度使用同构全栈架构是。别被 Vercel 的丝滑体验惯坏了——等你真要把项目迁出来的时候，才会发现那些"理所当然"的能力背后，是你一个人根本复制不了的基础设施；全量 SSR + 全栈同构，就是前期的神、后期大坑。

终于抽出空来写一篇个人对当下AI时代观察的综述。这篇文章的目的是给对AI一知半解，但愿意抽出空来专心了解的人——比如高考完不久的我那些同学们——一篇系统化、深入浅出的认知对齐；但只要你愿意相信，我的观察并不烂大街，便大可以放心的往下看。 这篇文章分为三个部分：

1. AI是什么：AI的本质和历史渊源
2. LLM哪儿来的：2023年以来LLM的爆火
3. Agent怎么用：如今agent如何重构我们的生产生活

AI是什么

Mark I 感知机

AI 的历史可以追溯到 1958 年 Rosenblatt 的 Mark I 感知机。

它由弗兰克·罗森布拉特（Frank Rosenblatt）于 1958 年在康奈尔航空实验室（Cornell Aeronautical Laboratory）完成，由 400 个光电元件组成一个 20×20 的“视网膜”阵列作为输入，通过可调电阻（电位器）来模拟可变的突触权重，由一组“关联单元”和“响应单元”组成输出，最终由一个电流计给出分类结果。通过人工调节电位器的电阻值（左拧拧右拧拧，哪边能让电流计更偏向正确的一侧就往哪边拧一点），罗森布拉特发现对于字母识别二分类任务，这组器件总能达到明显高于 50% —— 不是瞎猜 —— 的正确率。尽管 1969 年，马文·明斯基（Marvin Minsky）和西摩尔·帕珀特（Seymour Papert）在《感知机》一书中证明了单层感知机（Single Layer Perceptron, SLP）只能解决线性可分问题（比如无法解决 XOR 问题），Mark I 感知机的出现仍然是证明了 AI 可行的一个重要里程碑。

多层感知机（Multi Layer Perceptron, MLP）

接下来是理论研究：

1989 年 George Cybenko 和 1991 年 Kurt Hornik 等人通过泛函分析严格证明了：只要 MLP 包含至少一个具有足够多神经元的隐藏层，并使用合适的非线性激活函数，它就可以以任意精度逼近任何连续函数。这个定理在数学上证明了 MLP 的潜力：即 MLP 可以拟合任何函数。

函数

但等等，为什么是函数？AI 看起来并不是随便画的函数图像啊？

要回答这个问题，我们可以想想 AI 的特征：每个 AI 都可以被抽象为在特定的输入下，求得输出的方法，即输入与输出的映射关系。高中数学告诉我们，函数就是定义域到值域的映射关系。换言之，设计一个 AI，除了解决输入（预处理）和输出（后处理）问题，唯一需要做的事情就是找到那个符合我们要求的函数。怎么找？基于精确代码的符号主义知识库专家系统给出了解析式，由此诞生了入机感十足但确实算 AI 的“上个年代的人工智能”。而不追求可解释性，追求暴力美学的数值法，交出了训练 MLP 的答案。

反向传播 （Backpropagation, BP）

怎么训练？首先你要有数据。仍然是高中数学，使用统计学方法可以从给定的数据中找出变量间的关系，而在 MLP 里，我们初始化（怎么初始化？你就权当是随机吧；这个话题单开一篇文章都讲不完，暂且按下不表）一组参数后，便得到了一个——你别管它能输出啥——模型：只要输入数据，就能输出答案。现在我们唯一要做的就是把它输出的答案变成正确的。

你怎么知道输出的答案正确与否？为了用上数学方法，我们不能肉眼盯着每个输出噪声——会瞎的，信我。我们需要另外一个损失函数，输入模型的输出（预测输出）和应当的输出（Ground Truth），输出他们的差异（损失，Loss）。怎么设计？你就权当是做差吧，这不重要（仍然写不下）。

接下来就很简单了——对每组数据，我们都希望损失尽可能小。

怎么办？仍然是高中数学：求导。不过这里不太一样：具体来说，我们对模型的每个参数求偏导，然后根据它（按学习率）稍微动一点每个参数（梯度下降），再换一组数据重复上述流程。学习率决定了每次动多少——动多了训练更快但容易过拟合（失去泛化能力，针对训练数据效果好但对没见过的数据抓瞎）；动少了训练很慢浪费算力。不断调整参数，我们就能逼近我们想要的函数。

当然，实际情况比这复杂得多——模型不一定只是 MLP，损失函数可能是另一个模型，梯度下降不一定只按这组数据的梯度，学习率可能是动态的，甚至为了找出模型的具体样子（超参数），我们可能先随机（蒙特卡洛搜索）试不同的搭配……加之随机性，训练模型甚至被戏称为炼丹。但这些都不重要。重要的是，我们已经有了一个模型，现在我们可以往上安输入输出了。

尽管我预言，未来的大模型会像现在的网站开发一样，变成人人皆可训练的基础元件，但现在，还是让我们看看别人做过些什么吧。

LLM（Large Language Models，大语言模型） 哪儿来的

LLM 的出现

LLM 的出现是标志着 AI 从专用组件（垂直领域）变成通用智能的另一个重要里程碑。得益于廉价劳动力积累的大规模数据和老黄发力的算力提升，我们得以尝试将训练数据扩大到史无前例的规模。当规模达到艾伦·图灵（Alan Turing）在他 1950 年的著名论文 《Computing Machinery and Intelligence》（提出图灵测试的那篇）中预测实现能通过“模仿游戏”的机器智能需要的十亿（10^9）级时，我们得到了轰动一时的 GPT-3.5。事实上这个说法并不完全准确：GPT-3.5 的参数量还要高上一个数量级，而且也没有那么聪明。但图灵的预言惊人地准在于：如今能对话的 LLM，的确至少得是十亿级的参数量。我们姑且当他是浪漫的巧合吧~

然而，OpenAI 带来的不止是 GPT。之所以闭源模型且自称 “Open”，是因为他们公开的论文（Scaling Law, Kaplan et al. 2020）证明了这条路是可行的：于是 LLM 开始井喷。

LLM 的发展

这个章节的后半部分有点 SOTA (State of the AI) 的感觉（时效性很强），因此我全删了。有兴趣的可以翻翻 Artificial Analysis 的评测之类的东西获取最新信息；我们这里就讲点“历史”故事吧。

闭源 LLM

OpenAI 尽管自诩 “Open”，但实际上从来没有开放过自家商业模型的权重；后来推出的 oss 性能仍与商业模型相差甚远，尤其是持续迭代的当下，开场即终章的 oss 系列根本无法与十天半个月出新的开源系列竞争。然而，OpenAI 也确实做到了某种意义上的 “Open”：不同于传统学界的惯用做法，他们开放了自己的论文，任何人，只要能访问互联网，都可以合规地获取阅读Scaling Law 的论文。尽管这并没有什么用：有财力训练大模型的人不差订阅期刊的钱；而普通人也并不需要读（可能也不一定读得懂）这些论文。然而，事实上的确在此之后，LLM开始井喷：如果 OpenAI 将其作为商业机密，开源复刻或许不会那么快；但大家看到了可信可复现的数据，证明到达一定的规模模型便可产生通用智能，于是大家敢于投入资源，很快便有了性能拉胯的 Bard (大换血后改名 Gemini)和我们接下来的主角：LLaMA (Large Language Model Meta AI)。

开源 LLM

首先澄清一点，开源 LLM 并不是从数据到检查点到模型的全套开源，而是指模型的最终状态开放使用。唯一开放过中间检查点的是小红书的 dots.llm，但过拟合了没人用；指令微调数据则大多是商业机密。

OpenAI 的 ChatGPT 推出后，Meta 仰仗雄厚的财力迅速跟进，开源（权重）了 LLaMA (1), 2, 3, 然后 4 就亖了（也许是因为杨立昆（Yann LeCun，法国人）推崇“更好的算法”结果分散了精力导致应用体验不佳？）。

LLaMA 2 仍不支持中文，社区少量后训练微调效果也没有严谨验证，因此尽管 LLaMA 已成开源界基线，国内却鲜见应用；中国的大模型大多从开源起步，加之本土数据优势，同时期的 Qwen 一经推出便迅速吸纳了大量用户；诸如 DeepSeek 的低价策略甚至反向对海外市场造成了不小的冲击（虽然笔者看着 DeepSeek 母公司幻方量化庞大的 A100 保有量以及业务性质仍然对当时相比智谱阿里等并无明显优势的 V3 系列对金融市场造成的动荡的根因表示怀疑，毕竟狂吹的比如 MoE 技术“创新”法国的 Mistral 早就推出过了）。

同时期：

• 专注节省存储便于本地部署的llama.cpp系列兴起，并受到了广大玩家欢迎

这里特别强调玩家是因为llama.cpp系列推理框架并发性能和计算效率相比生产级推理框架相距甚远。

本地部署AI模型这条路大概这样：

• 有 AI 界的 GitHub 之称的 Hugging Face 惨遭众所周知——HF 官方甚至还在第一时间检查了自己的基础设施，但像 Space 这种免备案可交互网页托管是无论如何都无法合规化的。尽管如此，Space 提供的从模型到应用的转变，仍然是基础模型取得突破后，我们下一节的主角——

聊天应用

基础模型只能用于概率预测补全，而想要与之交互就要明确：我要补全的是对话内容（-chat）；更进一步说，即指令微调（-instruct）。这一时期，AI 的应用以聊天工具为主，且由于模型仍然不大，存储的事实知识有限，因而更偏向于非事实性问答；然而，许多人没有意识到这一点，因此当越来越多人踩了坑之后，幻觉这一不明觉厉的名词诞生了。进而，我们尝试改进，例如强制先搜索相关知识，然后注入上下文再由 LLM 生成回答（RAG）。这一时期，我们看到 LangChain 等框架的涌现，然而过度的抽象化导致开发成本不降反升。据笔者观察，如今仍在使用此类框架的，更多是当时唯一选择的存量代码，而非刻意的技术选型。尽管如此，这仍标志着新的产品形态的诞生：智能体。

智能体（早期）

早期的智能体我泛指所有强制进行上下文注入，而非提供裸模型的问答的对话应用。此时智能体尚未脱离对话这一交互形式，但系统提示词里的工作流动态的上下文注入已使其脱离了纯概率预测的范畴，进而催生了一波提示词工程热（卖课的赚到了 AI 的第一桶金）。然而强制的上下文注入仍然使得模型并无法自主选择所要查询的内容；很多时候模型甚至难以区分自己的上下文是查询到的还是用户指定的抑或是系统提示词，并由此导致了提示词注入攻击等草台班子问题。因此我们希望将工具调用的决策权卸载给模型，而这随着模型对原生工具调用的支持逐渐普及得以实现；这进一步使得 LangChain 等智能体框架的实际应用意义下降。然而工具调用本身却仍没有一个统一的标准，直到模型上下文协议得到广泛应用，标志着协议层面的通信设计日趋成熟；压力给到工具的设计本身。

Agentic

如今 开源的 闭源的 Lock in 的 BYOK 的 智能体工具一大堆，本地的 上云的 执行环境数不胜数；商业化的兴起反过来印证了一个事实：AI已经从玩具，走向真正的生产力工具了。

随之而来的便是焦虑：如果 AI 把我干的事情都干了，那我干啥？这个问题我已经听到过无数个版本了；共性是：都是从财经媒体/博流量的自媒体，或是各种“别人”的角度，刻意制造的焦虑，而非亲身体验。

答案也很简单：

1. 它没这能力。硬要佐证的话，AA（Artificial Analysis） 的 Omniscience Hallucination Rate 和 Accuracy 几乎是正相关可以算一个——模式匹配的本质使得无关模型大小，训练数据的设计就决定了越敢于自主决策的模型越不知道自己在干嘛；
2. 它没你便宜。很讽刺的一件事，AI 原本是为了替代人类工作而发明的；而如果用 AI 工作反而更贵，在动物保护组织保护牛保护马不保护牛马的当下，为什么还要用 AI 呢？然而事实如此：即使在战略要求低价吸引用户的当下，比肩高级程序员的 AI 也将向你要求比肩高级程序员的开支。那么，在流程、合规性、版权等方面仍有隐性成本的背景下，何不雇用体制成熟的人类员工呢？因此听到 Anthropic 呼吁暂停 AI 研发时，我的内心毫无波澜，甚至有一丝想笑：如果这话是开源社区提出来的，哪怕是 LeCun 这种致力于下一代架构的，或许还值得认真对待；商业公司？哪有永恒的敌人，只有永恒的利润。

这也就是所谓人口红利可笑的一面：看似人人享福的机遇，实则不过是人人受压迫的大棒之下的甜枣。

这好吗？因人而异，取决于你的价值选择。至少对博主来说，答案是肯定的。

何况，Agentic 时代，AI的本质是共享经济。为什么这么说？模型提供商需要你的数据后训练微调，代理工具需要你的使用反馈优化提示词设计，社区需要你的宣传将 AI 工具介绍给更多人...一切数据都会回流到推理服务商手上（何况很多人并不接理论上更隐私的 API 而是用户协议都不看就直接用终端 APP），而主动上交隐私甚至是促进模型迭代的必要条件！不止 Claude Code，所有智能体代理都是相应模型提供商开发的效果最好。有人说这只是因为针对性优化的提示词；但反过来想，这何尝不可能是特调的后训练微调？细思极恐。

当然也不必过于悲观，正是在重复劳动逐渐被替代的背景下，我们才得以进一步提升自己的能力；换言之，AI的发展呼吁我们下一章的主角：新文科

Agent怎么用

新文科

首先叠个甲，我不是文科生，以下是我自己脑子想想的我切实感到自己的局限，展望未来的个人观点。

其次，我们下面讨论的新文科，不是教育界现在已经在推的、形式主义化为文科加编程的新文科，而是有重新定义技术的野心，有踏出艺术的勇气的新新文科。

行业现状

这并不是（是？）空穴来风：当 AI 走向应用层的逆转不可阻挡，能力需求的多元化日益显著。拿一个人人都能做，没人能做好的需求举例，提示词工程里，计算机科学背景的以结构化思维和链式推理设计解决基础的智能问题，然而还有一类创意写作、戏剧、心理学背景的以传统工科训练覆盖不到的叙事结构、情感节奏、文化语境能力解决终端用户更看重的语气问题。大量纯工科出身的 AI 产品经理，卡在"技术能做什么"而跳不出"用户为什么需要"；而真正以修辞学/情感色彩差异化的的产品，在基础工作由AI接管的当下反而打出了差异化竞争的王牌。

教育对齐

既然行业有人才缺口，我们自然把目光投向高等教育。

AI伦理与治理（最成熟）

基于与已有法学伦理学的强关联，这一领域的响应最快、落地最多。例如：

响应的也往往是头部学府，例如：斯坦福的 CS 181W: Computers, Ethics, and Public Policy、清华的 AI伦理课程、中国政法大学等法学院校的AI与法律模块。

数字人文与计算社会科学（正在扩张）

这是人文学科“主动拥抱”AI的路径：

同样，人大、武大、南大等已有"数字人文"本科方向或硕士项目；国外UCLA、UCL的数字人文项目更是标杆。

底层认知重构（最前沿但最小众）

这是更深层的对齐——不满足于"AI+某个具体人文学科"，而是追问"大模型改变了人类认知和知识生产的底层逻辑"：

这类课程尽管难以建制化，主要散落在哲学系、认知科学系的专题研讨课中，缺乏系统性的专业设置；但也最触及人与 AI 关系的核心。

前进阻力

然而，更多高校管理层对生成式AI的理解仍停留在“防作弊”层面，而即使有范式变革的远见，也往往面临能贯通技术与人文的双栖师资极度稀缺和学术惯性和行政壁垒导致跨学科课程难以开设的困境。

更何况在就业压力下，学生的选课策略同样是高度功利的，“AI伦理”不如“Prompt Engineering”好写进简历；人文学科课程在AI热潮中反而容易被边缘化，成为可有可无的点缀。

那，我们能做什么呢？

仍然叠甲：每个人的习惯不同，适合自己的就是最好的；下面只是分享一下博主自己使用的经验，仅供参考。

明确能力边界

首先，要认清AI的能力边界。

简单举几个例子：不要指望没带工具的聊天里给出的信息永远是正确的，不要指望支持光学字符识别的VLM看得出来中文和日文字体的区别，不要指望支持长上下文的模型在几十万行代码之间保留相同的注释风格。

我不可能在上面枚举出所有技术限制；授人以鱼不如授人以渔，要想在指派任务时反应得过来会不会触及什么底层限制，最好的办法就是对AI的底层机制有一定的了解。例如，知道基于自回归的模型（尤其是不开思考时）不可能根据后面的生成调整前面的回答，基于分词的LLM不可能数得清strawberry里有几个r，诸如此类。

分层划定功能

其次，要善用别人特调过的工具。我一般分三类：

承担审阅责任

最后，记住：AI会犯错，永远审阅它的结果。如果有大纲或计划之类的东西，读它确保AI理解了你在干什么；如果是代码或文本，不光要能过编译或读得通，你也得看一遍逻辑有没有暗病；如果涉及事实信息，要么同时用多个模型比较回答是不是大差不差，要么自己上网搜索/拿着权威资料确认一遍。

结语

AI 的故事讲完了，但 AI 的发展仍在继续；生态的日新月异，产品的飞速迭代都要求我们持续学习。谨以此文献给每个愿意听我掰扯的人，我们下篇博文，再见。

Gen AI 时代，抗拒AI是愚蠢的，滥用AI是可耻的。为了规范AI使用边界，本博客中的文章可能标有如下标签：

• AI-ASSISTED：本文间接包含AI生成内容作为人工写作的参考，如果存在错误则即使不用AI博主也会在这里犯错（说不定错的更离谱），可放心食用；
• AI-REFINED：本文为博主完成草稿后全篇由AI润色的产物，除博主能力所限外还可能存在LLM幻觉导致的错误和文风一股入机味，但应该无伤大雅~
• MAN-MADE：本文为博主纯手搓；
• 目前没有直接包含AI生成内容的计划——想看这种东西为什么不直接把想看的当提示词发给AI让它生成呢？

博主郑重承诺：我们不制造电子垃圾，任何标签均为如实声明

环境变量是什么

环境变量（Environment Variable）：操作系统提供给进程的键值对。进程启动时继承父进程的整个环境，可用于配置程序行为、传递路径信息等。常见如 HOME、USER、SHELL、LANG。

PATH：最核心的环境变量，告诉 Shell 在哪些目录中按顺序搜索可执行文件。敲一条命令时，Shell 挨个扫 PATH 里的目录——先找到的就执行，后面的不再查。

动态库搜索路径：程序运行时查找共享库（Linux .so、macOS .dylib、Windows .dll）的机制。逻辑与 PATH 类似但机制因平台差异极大，是最容易踩跨平台坑的领域。

我什么时候会用到它

抛开应用程序主动用它传配置不谈，最常用的场景就是手动安装命令行工具。处于某些原因我们不想用包管理器或安装器安装程序时（它们通常会帮你配置好环境变量）而是直接下载一个压缩包的可执行文件使用时，我们要告诉 Shell 在哪里找到我们下载的可执行文件，即配置环境。通常情况下，只需要将可执行文件所在的目录添加到 PATH 环境变量里即可。那么，怎么添加？——

怎么读

环境变量的读取范围分四层，搞不清这个是"设了但不生效"的第一大原因：

同名变量在多层设置时，层级越窄优先级越高： 进程级 > Shell级 > 用户级 > 系统级）

这里的行为，与其说是平台特定，不如说是 Shell 特定：比如，如果你在 Windows 上用 Bash，那其实更应该参考 Linux 的设置。

为什么写文件可以修改环境变量？这是 Shell 的设计机制：Shell 启动时会按一定规则运行特定的初始化脚本，而作为所有命令的入口，所有的 Shell 都设置了的环境，相当于就是整个用户/系统的环境。

特例：

• Linux /etc/environment 是用户登录时由 PAM 读取的，格式为 KEY=VALUE
• macOS /etc/paths 只管 $PATH，每行一个路径，不是 KEY=VALUE 格式；/etc/paths.d/* 同理（每个文件一行一个路径）

Shell 的 Login / Non-login——Linux/macOS 最大的坑

Shell 启动方式决定它读取哪些配置文件，这直接决定你的环境变量在哪个文件里写才能生效：

bash 读取顺序

bash 的 Login Shell 优先级列表 ~/.bash_profile > ~/.bash_login > ~/.profile 诞生于 Unix 历史的“兼容期”，它是为了解决多流派 Shell 用户的迁移问题，而非让你把三个文件都用上。

1. ~/.profile 是 Bourne Shell (sh) 的老祖宗标准： 在当年，所有 Unix 系统的默认 Shell 都是 sh，大家都把环境变量写在 ~/.profile 里。直到今天，如果你用的是 Ubuntu，它的底层系统默认 Shell 是 dash，dash 启动时依然只认 ~/.profile。
2. ~/.bash_login 是对 C Shell (csh) 的妥协：当年有一大批写 ~/.login 的 csh 用户转投 Bash，为了照顾他们的习惯，Bash 加了这个支持。
3. ~/.bash_profile 是 Bash 的“亲儿子”：Bash 诞生增加了很多 sh 不支持的高级语法（比如数组、特殊的字符串处理）。如果用户把这些高级语法写进 ~/.profile，当系统其他组件用 sh 或 dash 读取这个文件时，就会直接报错。

为什么设计为互斥隔离（只读找到的第一个）？ 如果 Bash 依次把这三个全读一遍，往往会引发灾难（比如环境变量 PATH=...:$PATH 被重复追加三次、打印了三次登录欢迎语、或者因为语法不兼容报错）。在 Bash 开发者的视角里：

如果你写了专属的 .bash_profile，我就按你的来；如果你没写，我就去看你是不是习惯用 .bash_login；如果你连这都没写，那我就去读最普通的 .profile 保底。千万别读两次。

但这导致了一个巨大的痛点：用户必须在 login 和 non-login 两个文件里维护两套配置。为了解决这个问题，现代的 Linux 发行版（如 Ubuntu, CentOS, Debian）在默认给用户生成家目录（从 /etc/skel/ 拷贝）时，动了一个非常聪明的“手脚”——强制桥接。现代发行版真实的 Login Shell 读取顺序变成了一个嵌套链条：

1. bash 加载 /etc/profile -> 遍历并 source /etc/profile.d/*.sh （用于配置系统级环境变量）和去读 /etc/bash.bashrc
2. bash 去找并读取 (~/.bash_profile > ~/.bash_login > ~/.profile) -> 去读 ~/.bashrc

然而，想象如下情景：

1. 系统默认只有 ~/.profile（里面包含了调用 bashrc 的桥接代码）。
2. 你为了配置环境变量，上网随便搜了一篇教程，自己新建了一个 ~/.bash_profile 文件并在里面写了 export PATH=...。
3. 灾难发生：由于 Bash 的优先级是 ~/.bash_profile > ~/.profile，你的 Login Shell 发现了你新建的文件，就不会再去读系统的 ~/.profile 了。
4. 结果：你新建的文件里没有那段“桥接代码”，导致你的 ~/.bashrc 彻底被 Login Shell 抛弃，以前在 bashrc 里配的所有别名（alias）和变量在 SSH 登录时全部失效。

因此，上网查教程时要特别小心，尤其是你发现它在用>>（流追加符）这种看似无害的东西修改配置文件时，因为你永远不知道它究竟是简单的追加还是默默新建了一个优先级更高的配置。

zsh 读取顺序（macOS Catalina+ 默认）

zsh 无论是否 login，都读 ~/.zshrc，所以 zsh 下环境变量只需放在 ~/.zshrc 就够了——比 bash 简单得多。

怎么写

Windows

Windows GUI 程序改完环境变量后不会自动感知，需要重启该程序。虽然系统会广播 WM_SETTINGCHANGE 消息，但很多程序忽略此消息。可能可以通过重启程序或重新登录生效，但既然都是 Windows 了，最可靠的方式还是重启系统。

Linux

为什么有 /etc/profile 还要 /etc/profile.d/？

系统包更新可能覆盖 /etc/profile ，但 /etc/profile.d/ 下的文件独立存在不受影响。/etc/ 下很多配置其实都有 xxx 和 xxx.d/ ——以便分离默认配置和用户配置。

GUI 应用（从桌面环境启动的）不读 ~/.bashrc。

它们的进程由 display manager (如 GDM) 创建，继承的是 systemd 用户会话环境。给 GUI 应用设环境变量的正确方式：

# ~/.config/environment.d/my-vars.conf  (systemd 用户环境)
JAVA_HOME=/usr/lib/jvm/java-11
PATH=/home/you/.local/bin:${PATH}

此目录下的 .conf 文件格式同 /etc/environment（纯 KEY=VALUE），由 systemd-user 启动时读取，仅对 GUI 应用生效。

macOS

macOS Catalina (10.15) 起默认 Shell 从 bash 改为 zsh。

旧版升级后，~/.bash_profile 里的配置在新终端中完全不生效。迁移：把 bash 配置搬到 ~/.zprofile（login 级）+ ~/.zshrc（interactive 级）。

macOS 的 PATH 机制独特。

不在 /etc/environment 里（此文件不存在），而是用 /etc/paths + /etc/paths.d/。加系统级 PATH 目录的正确做法：

# 加一个文件到 /etc/paths.d/
sudo tee /etc/paths.d/homebrew <<EOF
/opt/homebrew/bin
EOF

注意这里用 tee 而非流重定向符，是因为 sudo 只管命令运行权限，而流是由 Shell 处理的——用 sudo 不就是因为 Shell 权限不够嘛。你要用 sudo sh -c 'echo /opt/homebrew/bin >> /etc/paths.d/homebrew' 也是一样的。

GUI 应用（从 Dock/Launchpad 启动）不继承 Shell 环境变量。

macOS 的 GUI 应用由 launchd 启动，launchd 的环境来自系统级配置，不读 ~/.zshrc。给 GUI 应用设环境变量的正确方式：

launchctl setenv KEY value
launchctl unsetenv KEY

PATH 设置最佳实践

各平台追加 PATH 的安全写法

# Linux/macOS — 在 ~/.bashrc 或 ~/.zshrc 中
export PATH="$HOME/.local/bin:$PATH"    # 前置（优先使用个人版本）
export PATH="$PATH:/opt/some-tool/bin"  # 后置（系统版本优先，仅补充）

# Windows PowerShell — 用户级永久追加
[Environment]::SetEnvironmentVariable(
    "PATH",
    [Environment]::GetEnvironmentVariable("PATH", "User") + ";C:\Tools\Bin",
    "User"
)

动态库搜索——跨平台差异最大的领域

三平台机制速览

Windows DLL 搜索顺序

Windows 的 PATH 同时管可执行文件搜索和 DLL 搜索.

这是独一无二的：PATH 里加个目录，不光影响命令查找，还影响 DLL 加载。PATH 越宽，DLL 搜索范围也越宽，可能加载到错误版本 DLL（DLL Hell 的根源）。这也是为什么 Windows 下按个 Tab 会冒出来一堆不能直接运行的.dll.

SafeDllSearchMode 开启时（Windows Vista+ 默认）：

SafeDllSearchMode 关闭时（仅旧系统），当前目录排在 PATH 前面——这是安全隐患。

最佳实践：DLL 放在应用程序自己的目录下——这是搜索顺序第一位，最可靠且不影响其他程序。尽量不要依赖 PATH 来找 DLL。 这也就是为什么 Windows 下 FFmpeg 那么容易出问题：FFmpeg 的协议使其经常没法再分发，只能手动补齐。

Linux 动态库搜索

搜索顺序：

设置方法：

LD_LIBRARY_PATH 应当只临时使用。

LD_LIBRARY_PATH 不应永久写入 Shell 配置。它会覆盖 ldconfig 缓存和默认路径，可能导致系统工具加载到错误版本的库（比如你的 LD_LIBRARY_PATH 里有个旧版 libssl，系统 curl 就可能加载它然后崩掉）。

RPATH vs RUNPATH 行为不同。

RPATH 在 LD_LIBRARY_PATH 之前搜索（可被 RPATH 覆盖），RUNPATH 在之后搜索（LDLIBRARYPATH 可覆盖 RUNPATH）。现代 binutils 默认用 RUNPATH。如果你需要编译时路径覆盖环境变量，要显式用 -Wl,--disable-new-dtags（强制 RPATH）——但这通常不是你想要的。

$ORIGIN 是一个特殊的 rpath 值，展开为可执行文件所在目录。

用于可移植部署（可执行文件和库放同一目录树），但 $ORIGIN 必须写进 rpath 字面量，不能在 Shell 里展开——gcc 命令中要写成：

gcc -Wl,-rpath,'$ORIGIN/lib'  main.c  # 单引号保护 $ORIGIN 不被 Shell 展开

macOS 动态库搜索

搜索顺序：

macOS 的 @ 路径魔术——这是理解 macOS 动态库的关键：

macOS 的设计哲学：库的搜索路径编译进库本身（install name），而不是依赖环境变量。库的 install name 通常形如 @rpath/libfoo.dylib，加载时 dyld 用主程序的 rpath 列表展开 @rpath 为具体目录。

设置方法：

Homebrew 安装的库使用绝对路径 install name（/opt/homebrew/lib/libfoo.dylib 或 /usr/local/lib/libfoo.dylib），Homebrew 在编译时通过 -rpath 让可执行文件能找到它们。如果你手动编译程序链接 Homebrew 库，必须传：

gcc -L/opt/homebrew/lib -Wl,-rpath,/opt/homebrew/lib main.c -lfoo

漏了 -rpath 就能编译但运行时找不到库——这是 macOS 上 dyld: Library not loaded 报错的第一大原因。

install_name_tool 是 macOS 独有的神器：

可以修改已编译 .dylib 的 install name 和已编译可执行文件的 rpath，不需要重新编译：

# 修改库声明自己的路径
install_name_tool -id @rpath/libfoo.dylib libfoo.dylib

# 修改可执行文件中对某库的引用路径
install_name_tool -change /old/path/libfoo.dylib @rpath/libfoo.dylib myapp

# 给可执行文件追加 rpath
install_name_tool -add_rpath /opt/homebrew/lib myapp

经验交流：每个平台的环境和动态库问题都有大量隐坑，尤其是 Windows 的 DLL 搜索顺序和 macOS 的 install name 体系——如果你有踩坑经验或补充，欢迎评论区分享。

是什么

本系列博文旨在解决就事论事解决问题不全面系统，翻书查教程冗长且可能过时的痛点，将凝练的知识系统性地组织起来，供入门用户建立认知框架，高级用户预知经验坑点。

为什么

博主深受其害：

• 碎片化搜答案：一个自以为是特例的报错，翻了半天社区讨论终于修好了，长舒一口气顺手清了浏览历史，结果没过几天同方向的问题又出现了，本可以复用的基础搜索又得全部重来；
• 硬啃完整教程：想用个项目，结果单开一个网页的 Wiki / Documention 翻半天找不到要用的点，回 GitHub 文档仓库一搜发现压根没写，定睛一看原来维护者在 issue 里说 not-planned

对于低频场景，稍微花点时间跳读一下可能无伤大雅；但当连自己都注意到了经常在做无用功，那不妨跟我一起总结经验教训。

怎么办

• 聚焦坑点：不再把坑点当补充，而是作为正文主要部分
• 标记时间：博文自带最后修改时间标记，可能过时的提醒你谨慎阅读

适合谁

适合：

• 速查的高级用户：直接翻目录或 Ctrl+F，找你要的那节，参数表格和命令示例都在
• 想系统了解的小白：从头读，每个参数都有解释

不适合：

• 想看保姆式教程的人：场景千变万化，要全列出来这就不是速查表了；但根因殊途同归，本系列博文尽管没法告诉你怎么做但至少尽可能教会你为什么；

• 只想要不二法门的人：授人以鱼不如授人以渔，适合的才是最好的，天天看杠精叫嚣“诶你这个通用解决方案不如我在我自己特定场景下调整过的在我自己的特定场景下的表现更好”有意思吗？与其给你个大多数时候够用的通用解决方案，不如教会你怎么针对自己的特定场景优化。

说在最后

作为经验交流，博主个人的经验总是有限的，在这里也鼓励大家在评论区讨论分享自己的经验之谈。

谁应该看这篇文章？

适合：

• 速查的高级用户：直接翻目录或 Ctrl+F，找你要的那节，参数表格和命令示例都在
• 想系统了解的小白：从头读，每个参数都有解释，假定你不熟悉命令行

不适合：

• 想抬杠的：关于哪种编码器在哪种内容下 VMAF 更高，这个问题没有金标准。根据信息论的基本原理，不可能存在一种编码既无损画质又极低码率——一切都是 trade-off，只能对特定视频源做 VMAF 实测才能得出有效结论。如果你热衷这类深度分析，出门左转这篇文章更适合你：视频压缩深度测试（知乎）

• 只盯着存储成本的人：除了存储成本，还有——编码时间成本（压个视频让电脑满载几百个小时值不值）、解码平台限制成本（目标设备不支持AV1还得转回来再看）、编解码电费成本（显卡满载的功耗感人）、调参时间成本（每种不同的视频源都得反复测 VMAF 和调参）。存储是成本，这些也是成本，甚至还有你看这篇文章本身的时间成本，都应该考虑在内。

为什么用 FFmpeg CLI，而不是 GUI 工具？

市面上有很多 GUI 封装工具——小丸、格式工厂、ShanaEncoder、HandBrake、FFmpegFreeUI 等等，它们的本质大多是给 FFmpeg 套了个图形界面，把你在界面里选的参数翻译成 FFmpeg 命令在后台运行。尽管并非所有 GUI 工具都基于 FFmpeg（例如 HandBrake 部分功能直接调用显卡厂商 SDK），但功能上大差不差。

GUI 工具的问题：

• 参数覆盖不全：GUI 不可能把 FFmpeg 所有参数都列出来，总有你需要但界面没有的选项
• 停更风险与沉没成本：很多小工具停更了你就傻了，学会的操作逻辑也迁移不走；FFmpeg 本身几乎不可能停更，它已经是音视频处理领域的基础设施级的存在了，掌握了就是你的
• 自由度受限：脚本化、批量处理、条件判断，CLI 天然支持，GUI 永远差一口气

并不是说 GUI 工具不好，它们的确很方便（我自己也经常用 LosslessCut）；但掌握 FFmpeg CLI 之后，GUI 工具对你来说就指是"便利品"，而不是"必需品"，你永远有托底的杀手锏。

安装 FFmpeg

请直接参考官方指南 Download FFmpeg

如果用包管理器装，环境变量应该会自动配好，直接运行 ffmpeg 就可以；如果直接下载静态构建手动安装，记得手动添加环境变量或把命令中的 ffmpeg 改成相应路径。

验证安装： 打开终端或命令提示符，输入 ffmpeg -version，能看到版本信息就成功了。

一、基础概念

在输参数之前，有几个概念必须搞清楚。

1.1 容器格式 vs 编码格式

我们平时说的"MP4 文件"，严格来说由两层组成：

• 容器格式（封装格式）：文件的"外壳"，即文件扩展名所代表的格式。常见的有 .mp4、.mkv、.mov。容器负责把视频流、音频流、字幕流"装在一起"
• 编码格式：视频流本身的压缩标准。同样是 .mp4 容器，里面的视频流可能是 H.264，也可能是 H.265，或者 AV1

"这是个 MP4"只说明了容器，没说明编码。用 ffprobe（FFmpeg 三件套之一，和 ffplay 一样应该会一起装好）可以直接查看文件的元信息。

1.2 编码格式与编码器

编码格式只是标准，编码器才是执行者（按照标准把视频数据实际编码出来）。

常用对照表：

带 lib 前缀的是纯软件编码器（用 CPU 计算），其余为硬件编码器（调用显卡内专用编解码单元）。

关于显卡编码速度的常见误解：显卡的"3D 游戏性能"与视频编码速度几乎无关。NVIDIA 的 NVENC 编码单元是独立的专用硬件——4060 和 4090 在单个编码任务上速度基本一致，因为两者都只有一两个 NVENC 单元，是 NVENC 单元数量和代际决定速度，而不是 CUDA 核心数量。

1.3 码率（比特率）

码率 = 视频每秒传输的数据量，单位是 kbps（千比特/秒）或 Mbps（兆比特/秒）。

• 1080p 普通内容（教程、生活录像）：1-3 Mbps 通常够用
• 1080p 高动态游戏录屏：3-6 Mbps
• 4K 内容：8-20 Mbps

1.4 像素格式

• yuv420p：8bit，兼容性最广，几乎所有设备都支持
• yuv420p10le：10bit，色彩过渡更细腻，低码率下反而质量可能更好（不平滑的色彩过渡本身就是高频噪声会浪费码率），用 HEVC/AV1 且设备兼容时推荐

二、命令行基础语法

2.1 命令的基本结构

ffmpeg -i 输入文件.mp4 [各种参数] 输出文件.mp4

• ffmpeg：调用 FFmpeg 程序
• -i：input 的缩写，指定输入文件，后面跟文件路径
• 各种参数：每个选项都是 -参数名 参数值 的格式
• 最后一个路径（没有 - 开头的参数在前）通常是输出文件

2.2 反斜杠换行（bash / PowerShell）

ffmpeg -i 输入.mp4 \
  -c:v hevc_nvenc \
  -c:a copy     \
  输出.mp4

行末的 \ 表示"这行还没写完，下一行是接续"。这只是为了让很长的命令看起来更清晰，效果完全等同于写成一行。

Windows CMD 中不能用 ` 换行，要用 ^；Powershell 要用 ``，且前面要由空格；本文示例统一用 bash 格式，Windows 用户请自行替换，或者不换行直接写成一行。

2.3 环境变量

# bash 写法（Linux / macOS / Git Bash）
export VIDEO="https://example.com/video.mp4?sign=abc123xyz"
ffmpeg -i "$VIDEO" 输出.mp4

# PowerShell 写法
$VIDEO = "https://example.com/video.mp4?sign=abc123xyz"
ffmpeg -i "$VIDEO" 输出.mp4

export VIDEO="..." 是 bash 中设置变量的写法。之后用 $VIDEO，shell 会自动把它替换成那段 URL，避免重复输入。这个变量只在当前终端窗口的会话中有效，关闭窗口就消失了。

2.4 指定使用哪块 GPU

CUDA_VISIBLE_DEVICES=1 ffmpeg -i 输入.mp4 -c:v hevc_nvenc 输出.mp4

CUDA_VISIBLE_DEVICES=1 是一个临时环境变量，写在命令前，只对这条命令生效。它告诉 CUDA 只把编号为 1 的 GPU（编号从 0 开始）暴露给这个进程，FFmpeg 就只能用那块显卡。多卡机器分配任务时使用。

三、最基础的输入输出

3.1 查看文件信息

ffprobe 文件.mp4

FFProbe 会打印输入文件的元信息（分辨率、帧率、编码格式、时长、码率等），然后退出。这是快速查看文件信息的常用方式。

3.2 直接转封装（不重新编码）

ffmpeg -i 输入.mkv -c copy 输出.mp4

• -c：codec，指定编码器
• copy：对该流直接复制（不重编码）
• 速度极快，因为只是换了个容器"壳"，但仅适用于目标容器兼容源编码的情形，否则会报错。

3.3 覆盖已有文件

ffmpeg -i 输入.mp4 -c:v hevc_nvenc -c:a copy -y 输出.mp4

• -y：如果输出文件已存在，直接覆盖，不交互询问。不加这个参数时，FFmpeg 会停下来问你要不要覆盖

3.4 指定编码器

ffmpeg -i 输入.mp4 -c:v hevc_nvenc -c:a copy 输出.mp4

• -c：codec，指定编码器
• :v：video，对视频
• :a：audio，对音频
• copy：对该流直接复制（不重编码）

3.5 指定码率

ffmpeg -i 输入.mp4 -c:v hevc_nvenc -b:v 2M -c:a copy 输出.mp4

• -b：bitrate，指定码率
• 2M: 2Mbps，M 大写

四、时间裁剪与剪切

这是高频操作，和编码参数无关，单独讲清楚。

4.1 时间参数说明

-to 和 -t 的区别：-ss 30 -to 120 等于 -ss 30 -t 90，结果一样（从 30s 到 120s，共 90s），但逻辑语义不同，按需选用。

4.2 关键帧剪切（快，不精确）

ffmpeg -ss 30 -i 输入.mp4 -to 90 -c copy 输出.mp4

-ss 放在 -i 前面：FFmpeg 先快速 seek 到靠近 30s 的关键帧，然后再开始解码。由于关键帧不一定恰好在 30s，实际起点可能略早几秒。

-c copy 直接复制流，不重新编码，速度接近瞬间完成，适合快速提取片段。

4.3 重编码剪切（精确，较慢）

ffmpeg -i 输入.mp4 -ss 30 -to 120 -c:v hevc_nvenc -c:a aac 输出.mp4

-ss 放在 -i 后面：FFmpeg 从头解码，精确丢弃前 30s，起点精确到帧。代价是需要重新编码，速度相应变慢。

适合场景：本身就要重压缩的任务（剪切和二压合并成一步，不需要先切再压）。

建议：如果本来就要二压，直接用 -ss（放 -i 后）同时做剪切和压缩，一步到位。如果只是想快速切片段留着，用 -c copy，秒出结果，精度够用就行。

五、视频参数

5.1 分辨率缩放

ffmpeg -i 输入.mp4 -vf "scale=-2:1080" 输出.mp4

• -vf：video filter，视频滤镜，后面跟引号包裹的滤镜表达式
• scale=-2:1080：缩放滤镜
  • 第一个值 -2：宽度自动计算，保持原始宽高比，且结果能被 2 整除（编码器要求）
  • 第二个值 1080：目标高度 1080 像素
  • 写 scale=1920:1080 则强制指定宽和高（不保证宽高比）
  • 写 scale=1280:-2 则固定宽，高度自动算

5.2 帧率

ffmpeg -i 输入.mp4 -r 30 输出.mp4

• -r：设置输出帧率（Frames Per Second）。不加 -r 则保持输入帧率

5.3 像素格式

ffmpeg -i 输入.mp4 -pix_fmt yuv420p10le 输出.mp4

• -pix_fmt：pixel format
  • yuv420p：8bit，兼容性最好，保守推荐
  • yuv420p10le：10bit，HEVC/AV1 推荐

六、音频参数

6.1 直接复制音频（最推荐）

-c:a copy

源文件音频质量没问题的情况下，优先复制，无质量损失，而且快。

6.2 重新编码音频

ffmpeg -i 输入.mp4 -c:a aac -b:a 128k 输出.mp4

• -b:a 128k：音频目标比特率 128 kbps

常用音频编码器：

6.3 选择特定音轨

ffmpeg -i 输入.mkv -map 0:v:0 -map 0:a:1 -c copy 输出.mp4

• -map：手动指定要输出哪条流
  • 0：第 1 个输入文件（从 0 计数）
  • v:0：该文件的第 1 条视频流
  • a:1：该文件的第 2 条音频流（比如日语音轨）
• 不加 -map 时，FFmpeg 自动选每种类型中"最佳"的一条

七、码率控制模式

这是视频编码最核心的部分，直接决定画质和文件大小。

7.1 CRF 模式（CPU 编码器专用）

ffmpeg -i 输入.mp4 -c:v libx265 -crf 24 -c:a copy 输出.mp4

• -crf：Constant Rate Factor，恒定质量因子
• 数值越小画质越好文件越大，越大越糊越小
• 推荐范围：

重要：CRF 是 CPU 软件编码器专用，GPU 硬件编码器不支持 -crf。

7.2 CQ 模式（NVENC 的恒定质量）

ffmpeg -i 输入.mp4 -c:v hevc_nvenc -rc:v vbr -cq:v 28 -b:v 0 -c:a copy 输出.mp4

• -rc:v vbr：rate control，码率控制模式，vbr 是可变码率
• -cq:v 28：NVENC 的恒定质量值（类似 CRF，但数值对应关系不同）
• -b:v 0：目标码率设为 0，配合 CQ 使用，表示不额外限制码率

CQ 与 CRF 的对应关系（近似）：

libx264 -crf 24  ≈  h264_nvenc   -cq 28~30
libx265 -crf 24  ≈  hevc_nvenc   -cq 28~30
libsvtav1 -crf 34 ≈ av1_nvenc    -cq 34~36

⚠️ 最常见的误区：根据 CPU 编码 -crf 24 的经验，在用 GPU 编码时也选 -cq 24。这相当于 CPU 的 -crf 18（画质极好但文件极大），被误以为"GPU 编码出来的文件比 CPU 还大"——其实只是 CQ 值选错了。

7.3 Global Quality（Intel QSV）

ffmpeg -i 输入.mp4 -c:v hevc_qsv -global_quality 24 -c:a copy 输出.mp4

• Intel QSV 的恒定质量参数，取值逻辑与 CPU CRF 更接近（24 对 24）

7.4 QP 模式（AMD AMF）

ffmpeg -i 输入.mp4 -c:v hevc_amf -qp_i 28 -qp_p 28 -c:a copy 输出.mp4

• -qp_i：I 帧（关键帧）的量化参数
• -qp_p：P 帧的量化参数，通常与 -qp_i 设相同值

7.5 VBR 码率模式（有明确码率上限时）

ffmpeg -i 输入.mp4 -c:v hevc_nvenc \
  -rc:v vbr -b:v 2M -maxrate 3M -bufsize 5M \
  -c:a copy 输出.mp4

• -b:v 2M：视频目标码率 2 Mbps
• -maxrate 3M：最大码率上限，峰值不超过 3 Mbps
• -bufsize 5M：缓冲区大小，控制码率波动幅度（建议设为 maxrate 的 1.5-2 倍）
• 注意：M 必须大写，小写 m 在某些情况下不生效

八、NVENC 高级参数详解

以下参数针对 NVIDIA 显卡编码（hevc_nvenc / av1_nvenc）。

8.1 编码预设与调优

-preset p7 -tune:v hq

• -preset：编码速度预设，p1（最快）到 p7（最慢/最优质）。越慢压缩效率越高，同等画质文件更小。日常推荐 p4（平衡）到 p7（质量优先）
• -tune:v hq：调优目标为高质量（High Quality）；ull 是超低延迟（直播场景）；lossless 是无损

8.2 多遍编码

-multipass 2

• -multipass 2：两遍编码，第一遍分析，第二遍编码，压缩效率更高。编码时间增加约 30-50%，但文件更小或画质更好

8.3 前瞻帧数

-rc-lookahead 32

• -rc-lookahead：向前预看多少帧来辅助码率分配决策。范围 0-32，值越大压缩越好，速度越慢，推荐设 32

8.4 自适应量化（AQ）

-spatial-aq 1 -temporal-aq 1 -aq-strength 10

• -spatial-aq 1：空间自适应量化，开启（1）后，根据画面区域复杂度分配码率——纹理丰富的地方多给，大面积纯色的地方少给
• -temporal-aq 1：时间自适应量化，根据帧间运动量分配码率——运动剧烈的帧多给
• -aq-strength：AQ 强度，范围 1-15，推荐 8-12；值过高会导致码率分配失衡

8.5 GOP 结构

-g 300 -bf 4 -b_ref_mode 2

• -g 300：GOP 长度（关键帧间隔），每隔 300 帧放一个关键帧。GOP 越短，跳转越精确但压缩效率略降；推荐设为帧率 × 10（30fps 就设 300，60fps 就设 600）
• -bf 4：B 帧数量，范围 0-4。B 帧通过参考前后帧提升压缩效率，设 4 是上限
• -b_ref_mode 2：B 帧参考模式，2 是金字塔模式，压缩效率最高，推荐

8.6 分块多单元编码

-split_encode_mode 2

• -split_encode_mode 2：尝试调用多个 NVENC 编码单元（如 4090 有两个单元）。但实际调用几个取决于 FFmpeg 调度，不保证双倍速度

8.7 HEVC 10bit Profile

-c:v hevc_nvenc -profile:v main10 -pix_fmt yuv420p10le

• -profile:v main10：使用 HEVC Main10 Profile，支持 10bit 输出，必须配合 -pix_fmt yuv420p10le 使用

九、硬件加速平台

NVIDIA NVENC

# HEVC 10bit，质量优先
ffmpeg -i 输入.mp4 -c:v hevc_nvenc -pix_fmt yuv420p10le -profile:v main10 \
  -preset p7 -tune:v hq -rc:v vbr -cq:v 28 -b:v 0 \
  -multipass 2 -rc-lookahead 32 \
  -spatial-aq 1 -temporal-aq 1 -aq-strength 10 \
  -g 300 -bf 4 -b_ref_mode 2 \
  -c:a copy 输出.mp4

# AV1（需要 40 系及以上显卡）
ffmpeg -i 输入.mp4 -c:v av1_nvenc -pix_fmt yuv420p10le \
  -preset p7 -tune:v hq -rc:v vbr -cq:v 34 -b:v 0 \
  -multipass 2 -rc-lookahead 32 \
  -spatial-aq 1 -temporal-aq 1 -aq-strength 10 \
  -g 300 -bf 4 -b_ref_mode 2 \
  -c:a copy 输出.mp4

代际说明：16/20/30 系是第七代 NVENC；40 系是第八代，新增 AV1 硬编；50 系是第九代，速度略有提升。AV1 硬编是 40 系的重要分水岭。

Intel Quick Sync (QSV)

ffmpeg -i 输入.mp4 -c:v hevc_qsv -preset medium -global_quality 24 -c:a copy 输出.mp4
ffmpeg -i 输入.mp4 -c:v av1_qsv  -preset medium -global_quality 28 -c:a copy 输出.mp4

AV1 硬编需要 Intel Arc 独显或 Ultra 100 系列（14 代之后）核显。

AMD AMF

ffmpeg -i 输入.mp4 -c:v hevc_amf -preset balanced -qp_i 28 -qp_p 28 -c:a copy 输出.mp4
ffmpeg -i 输入.mp4 -c:v av1_amf  -preset balanced -qp_i 32 -qp_p 32 -c:a copy 输出.mp4

AV1 硬编需要 RX 7000 系列独显或 Ryzen 7000 系列的 700M 核显（如 7840H 的 780M）。

Apple VideoToolbox（macOS）

ffmpeg -i 输入.mp4 -c:v h264_videotoolbox 输出.mp4
ffmpeg -i 输入.mp4 -c:v hevc_videotoolbox -profile:v main10 输出.mp4

M 系列芯片支持 H.264 和 HEVC 硬编。AV1 编码支持情况视 FFmpeg 版本而定，请查阅对应版本文档。

十、hev1 与 hvc1：播放兼容性的那个坑

HEVC 视频在 MP4/MOV 容器中有两种打包标签，影响播放兼容性：

• hvc1：参数集（SPS/PPS）内联在容器 Sample Entry 中，视频开头一次性写入
• hev1：参数集可散布在码流中，每隔一段重复

FFmpeg 默认生成 hev1。 如需改为兼容性更好的 hvc1：

ffmpeg -i 输入.mp4 -c:v hevc_nvenc -tag:v hvc1 -c:a copy 输出.mp4

• -tag:v hvc1：强制将视频流的 codec tag 设为 hvc1

各平台兼容情况：

来自实际踩坑的建议：视频要在 iOS/Safari 播放，或者上传到 Web 播放器，加 -tag:v hvc1。用 hevc_nvenc 等硬件编码器有时会自动用 hvc1，用 libx265 软编默认是 hev1，最稳是显式指定。

十一、URL 作为输入，以及为什么不建议 URL 输出

11.1 URL 输入

ffmpeg -i "https://example.com/video.mp4?sign=abc123&token=xyz" 输出.mp4

为什么 URL 必须加引号？ URL 中常含 ?、&、= 等字符，在 shell 里有特殊含义（& 表示后台运行命令）。不加引号，shell 会在 FFmpeg 看到这个 URL 之前就把它"拆解"，导致参数传错或命令直接出错。

规则：URL 永远加双引号。

使用环境变量存储 URL（避免反复复制粘贴超长签名链接）：

export VIDEO="https://your-server.com/path/to/video.mp4?sign=very_long_token_here"
ffmpeg -i "$VIDEO" -to 120 -c:v hevc_nvenc -c:a copy 输出.mp4

注意 "$VIDEO" 也要有引号，防止变量本身展开后的内容被 shell 解析。

11.2 为什么不建议 URL 输出

FFmpeg 写入 MP4 文件时，必须在编码完成后回到文件开头写入 moov box（元数据，包含帧索引等信息），这个操作需要输出目标支持随机写入（seek）。

WebDAV 等网络存储协议通常不支持 seek 写入，会导致写入失败，或者输出的文件能写进去但无法正常播放。

结论：

• 输入：URL 可以用，注意加引号
• 输出：强烈建议输出到本地文件，完成后再上传。如果一定要直出，可以改用 MKV 格式（MKV 对 seek 要求更低），但兼容性不如 MP4

十二、视频变速

12.1 视频加速 / 减速

ffmpeg -i 输入.mp4 -vf "setpts=0.5*PTS" -c:a copy 输出.mp4

• setpts：修改视频帧的显示时间戳（Presentation TimeStamp）
• setpts=0.5*PTS：时间戳乘以 0.5 → 视频 2 倍速
• setpts=2.0*PTS：时间戳乘以 2 → 视频 0.5 倍速（慢动作）
• 规律：setpts = (1 ÷ 目标倍速) × PTS

12.2 音频加速 / 减速

ffmpeg -i 输入.mp4 -c:v copy -af "atempo=2.0" 输出.mp4

• atempo=2.0：音频 2 倍速
• atempo=0.5：音频 0.5 倍速
• ⚠️ atempo 取值范围是 0.5-2.0，超出范围需要串联多个：

# 4 倍速音频（超出范围，串联两个 atempo）
-af "atempo=2.0,atempo=2.0"

12.3 音视频同步变速

ffmpeg -i 输入.mp4 \
  -vf "setpts=0.5*PTS" \
  -af "atempo=2.0" \
  -c:v libx265 -crf 24 \
  输出.mp4

同时调整音视频速度，保持同步。注意变速后视频流发生了改变，不能用 -c:v copy。

十三、视频拼接与合并

13.1 文件列表拼接法（推荐）

新建文本文件 list.txt：

file '片段1.mp4'
file '片段2.mp4'
file '片段3.mp4'

ffmpeg -f concat -safe 0 -i list.txt -c copy 输出.mp4

• -f concat：使用 concat 解复用器，按列表顺序读取文件
• -safe 0：允许列表中使用相对路径（默认出于安全只允许绝对路径）
• -c copy：直接复制流，不重编码，速度极快

前提：所有片段的编码格式、分辨率、帧率必须完全一致，否则拼接结果会花屏或音视频不同步。格式不一致时，去掉 -c copy 改为指定编码器重新编码，代价是时间更长。

13.2 filter_complex concat 滤镜（格式不一致或需要重编码时）

ffmpeg -i 片段1.mp4 -i 片段2.mp4 -i 片段3.mp4 \
  -filter_complex "[0:v][0:a][1:v][1:a][2:v][2:a]concat=n=3:v=1:a=1[outv][outa]" \
  -map "[outv]" -map "[outa]" \
  -c:v hevc_nvenc -cq:v 28 -rc:v vbr -b:v 0 -c:a aac \
  输出.mp4

• -filter_complex：复杂滤镜图，支持多输入处理
• [0:v][0:a]：第 1 个输入文件的视频流和音频流（方括号是标签，用于在滤镜图中引用）
• [1:v][1:a]：第 2 个输入文件……以此类推
• concat=n=3:v=1:a=1：拼接 n=3 段，输出 v=1 条视频流和 a=1 条音频流
• [outv][outa]：给滤镜输出命名，供后续 -map 引用
• -map "[outv]" 和 -map "[outa]"：选这两条流作为最终输出

13.3 时长不同时的对齐处理

场景：音频比视频短，补静音至视频时长

ffmpeg -i 视频.mp4 -i 音频.mp3 \
  -filter_complex "[1:a]apad[a]" \
  -map 0:v -map "[a]" \
  -shortest \
  输出.mp4

• apad：对音频末尾填充静音
• -shortest：以最短流为准截断输出，防止无限延伸

场景：填充到指定时长

-filter_complex "[1:a]apad=whole_dur=300[a]"

• whole_dur=300：音频填充/截断到恰好 300 秒

场景：视频比音频短，补黑帧

ffmpeg -i 视频.mp4 \
  -vf "tpad=stop=-1:stop_mode=black" \
  -af "apad" \
  -c:v libx265 -crf 24 \
  输出.mp4

• tpad=stop=-1:stop_mode=black：在视频末尾补充黑帧（-1 表示无限补，配合 -shortest 或音频时长决定何时停止）
• stop_mode=clone：改为复制最后一帧（冻结画面）

十四、VMAF 质量评估

VMAF（Video Multimethod Assessment Fusion）是 Netflix 开发的视频质量客观评估标准，模拟人眼感知，分数 0-100，95 分以上通常认为肉眼几乎无法区分与原片的差别。已内置在 FFmpeg 中，无需额外安装。

14.1 基本用法

ffmpeg -i 压缩后.mp4 -i 原始视频.mp4 \
  -filter_complex "[0:v][1:v]libvmaf=model=version=vmaf_v0.6.1:log_path='vmaf_log.txt':n_threads=20" \
  -f null -

• [0:v]：被测视频（压缩后）
• [1:v]：参考视频（原始），顺序不能搞反
• model=version=vmaf_v0.6.1：使用内置的 1080p 模型
• log_path='vmaf_log.txt'：结果写入日志文件
• n_threads=20：用 20 线程并行计算（设成你的 CPU 核心数即可）
• -f null -：不生成任何输出文件，只运行滤镜计算

14.2 4K 内容使用 4K 模型

-filter_complex "[0:v][1:v]libvmaf=model=version=vmaf_4k_v0.6.1:log_path='vmaf_log.txt':n_threads=20"

14.3 帧对齐问题

如果测出异常低的分数（比如平时都是 95 分，突然跳到 70 分），多半是帧没有对齐。在两个 -i 前各加 -r 帧率 强制同步：

ffmpeg -r 30 -i 压缩后.mp4 -r 30 -i 原始视频.mp4 \
  -filter_complex "[0:v][1:v]libvmaf=model=version=vmaf_v0.6.1:log_path='vmaf_log.txt':n_threads=20" \
  -f null -

另外，两个视频必须帧数和时长相同，建议测试前用 -to 裁剪到相同长度。

十五、完整命令参考

15.1 1080p HEVC 二压（NVENC，质量优先，兼容性标签）

ffmpeg -i 输入.mp4 \
  -vf "scale=-2:1080" \
  -c:v hevc_nvenc -pix_fmt yuv420p10le -profile:v main10 \
  -preset p7 -tune:v hq \
  -rc:v vbr -cq:v 28 -b:v 0 \
  -multipass 2 -rc-lookahead 32 \
  -spatial-aq 1 -temporal-aq 1 -aq-strength 10 \
  -g 300 -bf 4 -b_ref_mode 2 \
  -split_encode_mode 2 \
  -tag:v hvc1 \
  -c:a copy \
  -y 输出.mp4

15.2 1080p AV1 二压（NVENC 40 系，质量优先）

ffmpeg -i 输入.mp4 \
  -vf "scale=-2:1080" \
  -c:v av1_nvenc -pix_fmt yuv420p10le \
  -preset p7 -tune:v hq \
  -rc:v vbr -cq:v 34 -b:v 0 \
  -multipass 2 -rc-lookahead 32 \
  -spatial-aq 1 -temporal-aq 1 -aq-strength 10 \
  -g 300 -bf 4 -b_ref_mode 2 \
  -split_encode_mode 2 \
  -c:a copy \
  -y 输出.mp4

15.3 HEVC 码率上限模式（适合有明确码率要求的场景）

ffmpeg -i 输入.mp4 \
  -c:v hevc_nvenc -pix_fmt yuv420p10le \
  -preset p7 -tune:v hq \
  -rc:v vbr -b:v 2M -maxrate 3M -bufsize 5M \
  -multipass 2 -rc-lookahead 32 \
  -spatial-aq 1 -temporal-aq 1 -aq-strength 10 \
  -c:a copy \
  -y 输出.mp4

15.4 URL 输入，剪前 2 分钟，降至 720p

export VIDEO="https://your-server.com/path/video.mp4?sign=token_here"

ffmpeg -i "$VIDEO" \
  -to 120 \
  -vf "scale=-2:720" \
  -c:v hevc_nvenc -pix_fmt yuv420p10le \
  -preset p4 -tune:v hq \
  -rc:v vbr -cq:v 28 -b:v 0 \
  -c:a copy \
  -y 输出_720p.mp4

15.5 精确剪切并二压（起点帧精确，-ss 在 -i 后）

ffmpeg -i 输入.mp4 \
  -ss 00:01:30 -to 00:05:00 \
  -c:v hevc_nvenc -pix_fmt yuv420p10le \
  -preset p7 -tune:v hq \
  -rc:v vbr -cq:v 28 -b:v 0 \
  -c:a copy \
  -y 片段.mp4

15.6 关键帧快速剪切（秒出，不重编码）

ffmpeg -ss 00:01:30 -i 输入.mp4 -to 00:03:30 -c copy -y 片段.mp4

15.7 双 GPU 同时跑两个任务

# 终端 1（使用 GPU 0）
CUDA_VISIBLE_DEVICES=0 ffmpeg -i 视频A.mp4 \
  -c:v av1_nvenc -rc:v vbr -cq:v 34 -b:v 0 -preset p7 \
  -c:a copy -y 输出A.mp4

# 终端 2（使用 GPU 1）
CUDA_VISIBLE_DEVICES=1 ffmpeg -i 视频B.mp4 \
  -c:v av1_nvenc -rc:v vbr -cq:v 34 -b:v 0 -preset p7 \
  -c:a copy -y 输出B.mp4

15.8 VMAF 对比参考（草稿示例中的参数）

ffmpeg -i 参考视频.mp4 -i 被测视频.mp4 \
  -filter_complex "[0:v][1:v]libvmaf=model=version=vmaf_v0.6.1:log_path='vmaf_log.txt':n_threads=20" \
  -f null -

十六、常见问题与坑点

❌ 报错：Impossible to convert between the formats

完整错误：Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scale_0'

原因：-pix_fmt p010le 与 scale 等滤镜不兼容

解决：把 -pix_fmt p010le 改为 -pix_fmt yuv420p10le

❌ 输出到 WebDAV 失败 / 输出文件损坏无法播放

原因：MP4 写入完成后需要 seek 回文件头写 moov box，WebDAV 不支持 seek 写入

解决：

1. 输出到本地，完成后手动上传（最稳）
2. 改用 MKV 格式输出（对 seek 要求更低）
3. 使用 rclone mount 并确认挂载方式支持 seek

❌ HEVC 在 Safari / iOS 不播放

把 -tag:v hev1 改为 -tag:v hvc1（或显式加上 -tag:v hvc1）

❌ 拼接后音视频不同步

• 检查各片段帧率是否一致，不一致先用 -r 统一
• -c copy 拼接要求时间戳连续，如果各片段来源复杂，改为重新编码
• 最稳方案：拼接时不用 -c copy，同时编码，代价是时间更长

❌ CQ 模式下文件比预期大很多

• 检查 CQ 值是否选错（参考上方 CRF/CQ 对应表）
• 加 -maxrate 和 -bufsize 限制峰值码率
• 检查 -b:v 0 是否有加（不加的话 NVENC 可能以默认码率为目标）

十七、参数速查表

持续更新。后续可补充：字幕烧录、色彩空间转换（HDR→SDR）、批处理脚本、更多滤镜参数等。

Composed by：Ryan Joseph Karazija/Andrew Scheps/Mike Lindsay

Wake
Heavy pulse
Bloody eyes
Sweaty clothes

New routine
That I've learned
To understand and know

Play my tricks
Fragile mind
Rest your head
On me

Shut my eyes
I'm not here
There must be some mistake

Don't be so serious
(×4)

Watch your words
Turn to dust
As we forget
As we move on

Still
I refuse
To let you slip away

Don't be so serious
(×4)

Magnets
(×n)