《HN 瞎聊》#42 – 代码审查、被遗忘的小站、FFmpeg 编译噩梦
About This Episode
本期我们把代码审查的速度与信任背后的博弈拆开聊，审视 Kagi 小站功能为何让老网民抓狂，并深入 FFmpeg 8.1 的编译痛点与 AI 能否救场。三大热点交织，技术细节与人性冲突同频共振，一键点燃听感。
Chapters
Links
小雅: 老冯，你那边怎么跟战场一样？我这边 NAS 刚跑到 80% CPU，你那电子鼓又开始了？
老冯: 别提了，楼上那哥们不知道抽什么风，非说现在是他的「创作黄金期」。我这边 FFmpeg 编译到一半，突然来个「咚咚咚」，差点把我显示器震下来。
小雅: 行吧，咱今天就在这种环境下录 #42 了。反正听众也习惯了，上次还有人说咱们的背景音像「赛博贫民窟交响乐」。
老冯: 赛博贫民窟？这形容绝了。不过今天咱聊点啥？我这边刚把一个代码审查的 PR 怼回去，心情正好。
小雅: 就知道你憋着坏呢。今天主要聊三件事：第一，代码审查那些破事儿，为什么每次都能吵起来；第二，最近发现几个被遗忘的小站，内容绝了但没人看；第三，FFmpeg 编译的那些坑，我昨晚折腾到三点，差点把 NAS 扔了。
老冯: FFmpeg 编译？你这是自找苦吃。我上次为了一个特定版本的 libx264，编译环境搞了三天，最后发现是依赖库版本冲突。那感觉，就像在泥潭里打滚。
小雅: 可不是嘛，但不折腾一下，怎么对得起这颗「极客之心」？行了，废话不多说，咱今天就从代码审查开始聊，你先说说最近又遇到什么奇葩 PR 了？
老冯: 奇葩 PR 多了去了。上周有个哥们提交了一个 2000 行的 PR，改动点是「优化了一个循环条件」。我一看，好家伙，全是重构，但连个测试用例都没有。直接给他怼回去，让他拆成 10 个 PR 再来。
小雅: 哈哈，这不就是典型的「我改了点东西，你帮我看看行不行」嘛。行吧，咱们今天就从这些「代码审查的艺术」开始，慢慢聊。
小雅: 欸老冯，你刷到那个 apenwarr 的新文章没？标题巨魔 ——《Every layer of review makes you 10x slower》。
老冯: 哦，那个啊，我瞄了一眼。又是一个码农抱怨审查流程拖慢速度的老梗。
小雅: 不是老梗了！人家数据摆得明明白白：修个 bug 半小时，同事 review 要五小时，架构师审设计得一周，跨团队排期直接一个季度。
老冯: 数据？这不就是他拍脑袋得出的「每层审查拖慢 10 倍」的「规律」嘛。理论依据呢？
小雅: 理论不重要，现实就是这么扯淡！评论区有个哥们说他 review 一个函数，复杂度从 23 降到 8，还得拉着作者 pair programming 才搞定。
老冯: 嗯，这倒是真实案例。不过这哥们也太惨了，复杂度 23 的函数都敢提交 review？
小雅: 所以啊，有人就提议「shift left」—— 设计阶段就把问题解决，日常 standup 同步进度，pair programming 实时 review，PR 只剩下 lint 这种机器能搞定的事。
老冯: 理想很丰满，现实很骨感。alkonaut 那条评论说得好：架构设计不可能一步到位，真正的问题只有在实现时才会暴露。
小雅: 那你的意思是，PR review 无法避免？
老冯: 不是无法避免，是需要权衡。PR review 的初衷是防止低级错误，但现在变成了政治正确的表演。
小雅: 政治正确？你是说那些「命名不规范」、「缺少注释」的评论？
老冯: 对啊！anal_reactor 说得好：除非作者是「certified idiot」，否则 rubber-stamp 也没啥大不了的。爆炸半径有限。
小雅: 但 recursivecaveat 反驳说大部分评论是客观问题，比如缺少 debug log、注释不全。这你怎么看？
老冯: 客观问题？那得看具体情况。如果一个函数复杂度 23，光靠 debug log 能救吗？
小雅: 好，那命名呢？jffhn 和 vaylian 说命名很重要，坏命名比无知更糟。
老冯: 命名确实重要，但不能为了命名吵三天。评论区那个复杂度 23 的函数，命名再好也救不了。
小雅: 所以你的意思是，PR review 变成了形式主义？
老冯: 不完全是。真正的问题在于，PR review 变成了唯一的质量保障手段。apenwarr 也提到，这跟工厂的 QA 流程一样，检查再多遍也提升不了质量。
小雅: 那 AI 呢？现在 AI 写代码快得飞起，review 更跟不上了。
老冯: AI 就是个笑话。apenwarr 说得好：AI 生成的代码要么你自己 review 27 分钟，要么丢给同事 review 5 小时，还得被骂「懒得 review 自己的代码」。
小雅: 但 AI 不是能干大活吗？比如一个星期的项目，AI 两小时就搞定。
老冯: 然后呢？代码量太大，review 不完，切成小块，每块 review 5 小时，最后还是一周。AI 只加快了第一步，后面的流程还是卡死。
小雅: 所以 AI 并没有解决根本问题？
老冯: 对。根本问题在于「等待」。apenwarr 说得好：大部分时间不是在干活，是在等待。AI 只能加快干活的速度，不能减少等待的时间。
小雅: 那评论区有人说，干脆别 review 了，AI 生成的代码 100 倍便宜，哪怕质量只有 1%，性价比也高。
老冯: 这就是「AI Developer」s Descent Into Madness」。先是 AI 写代码快，然后发现 bug 多，再让 AI 修 bug，结果越改越乱，最后搞个 agent 框架让 AI 自动 review。
小雅: 然后呢？
老冯: 然后就疯了。apenwarr 说他好多朋友已经陷进去了，Claude Code 才火几个月，就有人走火入魔。
小雅: 所以，解决方案是什么？彻底废除 PR review？
老冯: 不是废除，是重新思考。apenwarr 提到 Deming 的质量管理理念：质量不是靠检查出来的，是靠流程设计出来的。
小雅: 也就是说，要从源头提高质量，而不是靠 review 把关？
老冯: 对。比如 pair programming、设计阶段的严格把关、日常同步进度，这些都能减少后期 review 的负担。
小雅: 但这样会不会又回到「设计一步到位」的老问题？
老冯: 所以需要平衡。设计阶段解决 80% 的问题，剩下的 20% 靠实时反馈和迭代 review 解决。
小雅: 听起来不错，但现实中能落地吗？大厂那些 CxO 整天喊「快速迭代」、「提高 LoC」，谁管你质量不质量。
老冯: 所以啊，overfeed 和 serial_dev 说得对：根源在于高层的 FOMO 和错误的指标。LoC 和 PR 数量能衡量啥？
小雅: 那你觉得，未来的趋势是什么？AI 会彻底改变开发流程吗？
老冯: AI 会改变一些东西，但不会改变根本。根本问题还是「等待」和「信任」。如果团队之间缺乏信任，再多的 review 也没用。
小雅: 所以，最终还是回到人？
老冯: 对。技术是工具，流程是手段，但人才是核心。没有信任，再好的流程也白搭。
小雅: 哎，老冯，你刷 HN 了吗？今天有个帖子特别扎心 ——《Every layer of review makes you 10x slower》。
老冯: 哦？又是哪个大佬在哭诉流程太多？我猜又是那套「每多一层审查，速度就慢十倍」的老调重弹。
小雅: 对对对！这哥们拿数据说话，说一个简单 bug 修复，30 分钟写完，同事 review 要 5 小时，架构师审设计得一周，要是跨团队还得一个季度。
老冯: 哈，我上次改个 API 文档，从提 PR 到上线花了三个月，中间还夹着两次架构评审和一次「战略对齐」。
小雅: 评论区有个哥们说得更绝，说他 review 过一个函数，圈复杂度 23，最后逼着作者一起 pair programming 才降到 8。
老冯: 这不就是「我代码写得烂，但我有理」的典型案例吗？pair programming 多好，一边写一边 review，还能顺便教教新人。
小雅: 对啊！有人就说，要是前期设计、daily standup 和 pair programming 做到位，PR review 只需要看看 lint 结果就行了。
老冯: 但也有人反驳说，架构设计不可能一步到位，真正的问题得写代码时才暴露。你总不能让架构师天天跟着你 pair 吧？
小雅: 哎，这不就是「信任」和「控制」的博弈吗？要是团队互相信任，review 就不会变成政治斗争。
老冯: 但现在 AI 代码一堆，有些人直接甩锅给 AI，自己连看都不看，reviewer 看到一堆垃圾代码能不生气吗？
小雅: 评论区有个老哥说得好，「AI 代码 100 倍便宜，但质量只有 1% 的话，那 ROI 还是翻倍的」。这不就是现在大厂的真实写照吗？
老冯: 哈哈，CxO 们最爱这种「数字游戏」，LoC 和 PR 数量上去了，KPI 好看了，实际代码质量烂成渣。
小雅: 还有人说，大部分 PR comment 都是鸡毛蒜皮的事儿，比如命名、格式，要不是作者「智障」，直接 rubber-stamp 也没啥大不了的。
老冯: 但也有人反驳说，命名很重要啊，坏命名比没命名更误导人。你总不能因为「不是所有 comment 都重要」就全盘否定 review 吧？
小雅: 哎，说到底还是「速度」和「质量」的矛盾。作者说得好，「你不能靠蛮力克服延迟」，AI 再快，review 环节还是卡脖子。
老冯: 所以啊，要么信任团队，要么信任流程，两者都信任不了的话，就只能信任「混乱」了。
小雅: 我就想问，有没有公司真的做到了「少 review 但质量高」？别光说不练。
老冯: 有啊，比如 Tailscale，作者说他们内部流程很轻量，但前提是团队足够小且信任度高。大厂嘛，还是得靠「流程」来掩盖「不信任」。
小雅: 所以结论就是，review 不是万能的，但没 review 是万万不能的？
老冯: 差不多吧。要是团队都像你我这样靠谱，review 可以少点；要是团队里有「圈复杂度 23」的大神，review 还是得严格点。
小雅: 哎老冯，你刷 Kagi 的新功能了吗？那个什么 Small Web，号称要挖掘被遗忘的小站。
老冯: 哦，那个啊，我瞅了一眼，说是要「humanize the web」，结果一看分类 ——AI、LLMs、Sysadmin，这不还是咱们程序员的自留地吗？
小雅: 对啊！评论区都炸了，说 Kagi 定义的「small web」太狭窄，就认 RSS 和最近更新的博客，那些静态的、单页的、奇奇怪怪的小站全给过滤掉了。
老冯: 啧，Sheldon Brown 那个自行车维修站你记得不？那个老哥 2008 年就挂了，网站还挂着 Google 广告续命，Kagi 这玩意儿估计直接给忽略了。
小雅: 评论区有个哥们说得好，「我真不知道 Sheldon Brown 已经去世了，还以为他网站挂广告是为了养家糊口」。这不讽刺吗？小站精神都靠广告续命了。
老冯: Kagi 这算盘打得精啊，RSS 和最近更新的博客好抓取嘛，技术上省事儿。但「small web」的精髓哪儿是这个？Geocities 那会儿，谁管你更新不更新，有意思就行。
小雅: 对对对！StumbleUpon 那会儿随便一刷，就能刷到个搞笑的 Flash 小游戏或者谁的个人主页，现在 Kagi 这分类，全是「Tech & Science」，「Programming」，「Sysadmin」，无聊死了！
老冯: 你别说，我还真怀念那些 Neocities 的小站，一堆 GIF 闪来闪去，配上 MIDI 背景音乐，现在看简直是灾难，但那时候就是觉得牛逼。
小雅: 哈哈哈，对对对！现在 Kagi 这玩意儿，连「Retro」分类都只有 78 个站，还不如我收藏夹里的 Geocities 存档多。
老冯: 人家 minifeed.net 就做得好，专门收录人工筛选的小站，不看更新频率，不看 RSS，就看内容有没有意思。Kagi 这算是偷懒了。
小雅: 但 Kagi 也有道理啊，自动化抓取总得有个标准，不然怎么上规模？人工筛选多累啊。
老冯: 规模？你见过哪个小站追求规模的？真正的「small web」就是一帮人在角落里鼓捣自己喜欢的东西，不求流量，不求更新，就图个乐。
小雅: 但现在连 Kagi 这个「small web」里，AI 和编程内容都快占一半了，这不还是大厂那套玩法吗？「Tech & Science」分类下，「AI」有 653 个站，「Programming」有 979 个，这哪儿是小站啊？
老冯: 这不就是互联网的「gentrification」吗？原本那些有意思的小角落，被资本和算法一洗，全变成了「高端社区」。
小雅: 但 Kagi 也不是完全没用啊，至少它把 RSS 重新带回了大众视野，而且还开源了。
老冯: 开源是好事儿，但这「small web」的定义要是再不改改，估计过不了多久，就剩下一堆 AI 生成的博客和编程教程了。
小雅: 哎，你说咱们是不是也该整个小站？就放点儿奇奇怪怪的东西，不更新，不做 SEO，就图个乐。
老冯: 行啊，你整个「小雅的编程噩梦」专栏，我整个「老冯的 FFmpeg 编译日记」，咱俩不求流量，不求更新，就图个乐。
小雅: 哈哈哈，说定了！到时候咱俩的站绝对不挂 RSS，不更新，就放在那儿，看看 Kagi 会不会收录咱们。
老冯: 得嘞，咱俩这就算是给「small web」精神续命了。不过话说回来，咱俩的站要是真火了，可别学 Sheldon Brown 挂广告啊。
小雅: 放心吧，咱俩要是真火了，我直接整个「打赏」按钮，支持加密货币，绝不挂广告！
老冯: 行，那咱俩这就算是约定好了。不过说真的，Kagi 这事儿也提醒咱们，互联网还是得多点儿人情味儿，少点儿算法味儿。
小雅: 嗯，不然再过几年，互联网就真成「大厂的自留地」了。咱们这些小人物，连个角落都混不上。
老冯: 所以啊，赶紧动手整咱俩的小站吧，趁着现在还有点儿「small web」的味道。
小雅: 欸欸欸，老冯，你听说了吗？Kagi 最近搞了个叫 Small Web 的东西，号称要挖掘互联网上那些「小而美」的网站。
老冯: 哦？又一个想吃「复古互联网」红利的？上次那个「回到 95 年」的项目不还是黄了吗？
小雅: 诶，别这么刻薄嘛！人家好歹是认真的，还开源了呢。说是只收录有 RSS、最近更新的博客和漫画站，想「人性化」互联网。
老冯: RSS？最近更新？这不就是变相筛掉了那些「死而不僵」的宝藏站吗？比如 Sheldon Brown 那种自行车技术网站，十年不更新但每个字都金贵。
小雅: 噗，你还真提到点上了！评论区有个哥们吐槽说，Kagi 这套标准就是「算法友好」，但完全忽略了「小网站」的精神 —— 那些奇奇怪怪的个人主页、Neocities 上的「神龛」站，甚至是……
老冯: 甚至是一个死了十几年的大佬的个人站，还挂着 Google 广告给后人续命？
小雅: 对对对！那个评论太绝了，「我一直用广告拦截器，都不知道他 2008 年就去世了，估计广告费还在给他的站续命」。
老冯: 这不就是理想主义和现实的撕裂吗？一边是「纯粹的小网站」，一边是「不更新就没流量，没流量就没钱」。
小雅: 而且更搞笑的是，Kagi 的「小网站」分类里，AI 和编程话题都快刷屏了。有人吐槽说，「这哪是小网站，这不就是 HN 的镜像吗？」
老冯: 哈哈，这不就是「算法的暴政」吗？你筛选「小而美」，结果筛出来的全是「算法喜欢的小而美」。
小雅: 不过也有人提到 minifeed.net 这种项目，说是完全靠人工筛选，不看更新频率，只看「是否真正个人创作」。
老冯: 嗯，这倒是个思路。但人工筛选得多累啊？Kagi 估计就是图省事，用 RSS 和「最近更新」当门槛。
小雅: 诶，你觉不觉得这事儿有点像咱们的播客？咱们也想做「小而美」的内容，但又怕被算法忽略，又怕被「大而全」的平台吞噬。
老冯: 哟，还挺有自知之明。不过咱们至少还能骂骂大厂，Kagi 这帮人倒好，一边说「人性化互联网」，一边把「人性化」的门槛设得死死的。
小雅: 行了行了，别酸了。要不咱俩也搞个「真・小网站」推荐专题？每期介绍一个冷门但牛逼的个人站，就当给互联网续点命。
老冯: 得了吧，你那 NAS 上的 Docker 还没搞定呢，先别操这份闲心了。再说了，咱俩推荐的站，估计又是「老冯的黑历史收藏夹」之类的玩意儿。
小雅: 靠，你还真有啊？！快发我链接！
老冯: …… 我拒绝回答。隔壁电子鼓又响了，咱俩还是赶紧录完收工吧。
老冯: 欸，小雅，FFmpeg 8.1 刚发布，你看了没？又是一堆新特性，Vulkan 啥的，听起来挺牛逼。
小雅: 看了看，但我他妈编译了一下午还是没搞定那些依赖，气死我了！
老冯: 哈哈，评论区有个哥们说得好：编译 FFmpeg 本身不难，难的是搞定那些编解码器的依赖，跟学画猫头鹰一样 —— 画两个圈就完事儿了？
小雅: 对对对！我一开始还觉得「不就是 ./configure && make 吗」，结果一堆专利编码器的坑，差点把我电脑搞崩溃。
老冯: 但你不觉得这玩意儿就是现代基础设施的「隐形英雄」吗？上层应用全靠它撑着，结果没人关心它的生存状态。
小雅: 嗯，这倒是。就像路由器一样，没人注意它，但坏了全家都得骂娘。不过老冯，你说 FFmpeg 团队为啥不学学 AviSynth，搞个脚本化的接口？
老冯: 呵，你当他们不想啊？但 FFmpeg 的核心哲学就是「万物皆 filter」，脚本化反而限制了灵活性。你见过哪个大厨用菜谱脚本炒菜的？
小雅: 切，你这比喻烂透了。大厨至少有标准化的食材供应链，FFmpeg 的「食材」全是乱七八糟的编解码器，还他妈有专利坑。
老冯: 行行行，不扯这个。说点实在的 ——8.1 版本的 Vulkan 优化你试了没？ProRes 编解码现在都能用 GPU 跑了，延迟低得吓人。
小雅: 试了试，但我那破显卡跑起来跟烧烤一样。不过 JPEG - XS 这个编解码器挺有意思，低延迟近无损，适合直播啥的。
老冯: 对，但带宽成本你考虑过没？JPEG - XS 虽然质量好，但码率比 H.265 高不少，适合专业场景，普通用户用不起。
小雅: 啧，又是专利和成本的老问题。说真的，FFmpeg 团队啥时候能把这些坑填上？AI 辅助开发能帮上忙不？
老冯: 有人问过这个问题，开发者回复说 AI 主要用来生成测试用例和优化代码，但核心逻辑还是得人肉写。FFmpeg 这种项目，AI 顶多当个「助理」。
小雅: 切，AI 连个编译脚本都生成不了，还好意思说「助理」。不过老冯，你说 FFmpeg 会不会有一天被大厂的「一体化解决方案」取代？
老冯: 取代？你想多了。大厂的方案都是基于 FFmpeg 二次封装的，比如 Apple 的 AVFoundation、NVIDIA 的 Video Codec SDK，背后全是 FFmpeg 的影子。
小雅: 行吧，那我就放心了。不过说真的，FFmpeg 团队也该考虑下用户体验了，别老让人觉得「编译成功就是胜利」。
老冯: 用户体验？FFmpeg 从来不是给「用户」设计的，它是给「开发者」设计的。你要简单，去用 HandBrake；你要强大，就得忍受这堆坑。
小雅: 靠，你这话说得我无法反驳。不过老冯，你说 Sovereign Tech Fund 给 FFmpeg 赞助了，这钱能不能用来雇人写个「FFmpeg for Dummies」？
老冯: 哈哈，你想得美。那钱估计都用来买服务器跑 CI 了。不过话说回来，FFmpeg 这帮人还是挺牛逼的，Coverity 扫描的缺陷密度比平均水平低 30 倍。
小雅: 行吧，算他们牛逼。但我还是觉得，FFmpeg 要是能像 Docker 一样「开箱即用」，那该多好。
老冯: 梦里啥都有。你先把你的 NAS 上的 FFmpeg 管线搞定再说吧，别等会儿又崩了。
小雅: 滚蛋！我这不是正在搞吗！等会儿录完节目我就去搞，不搞定不睡觉！
小雅: 欸，老冯，FFmpeg 8.1 都出来了，你刷到了没？
老冯: 刷到了刷到了，这不正在看 changelog 呢，Vulkan 优化又进一步了。
小雅: Vulkan 那堆玩意儿我是看不懂，但 JPEG - XS 这个低延迟编解码器听起来挺牛逼的。
老冯: 嗯，专利授权那块估计又是一堆坑，不过技术上确实有亮点。
小雅: 说到坑，评论区有个哥们吐槽编译 FFmpeg 简直是「学画猫头鹰」—— 画两个圈就叫会画了？
老冯: 哈哈，这比喻绝了。FFmpeg 本体编译确实不难，但一堆编解码器依赖一加，立马变成依赖地狱。
小雅: 我上次想编个带 libx265 的版本，结果 cmake 报错一堆，最后直接放弃用 brew 装了。
老冯: brew 装的那个版本，编解码器全给你裁剪了，用起来跟残疾人一样。
小雅: 对对对！我就想问问，FFmpeg 这么重要的基础设施，为什么用起来这么反人类？
老冯: 因为它压根不是给普通用户设计的，它是给上游开发者用的。
小雅: 那 AviSynth 那种脚本化的方式多好，为什么 FFmpeg 不学学？
老冯: 学不了，FFmpeg 的核心逻辑太复杂，脚本化会牺牲性能。
小雅: 那 AI 能不能帮上忙？比如自动生成编译配置啥的。
老冯: AI 现在顶多能帮你写写文档，真要介入编译流程，还得等个几年。
小雅: 不过话说回来，FFmpeg 这帮维护者也挺牛逼的，Coverity 扫描的 defect density 都快赶上 NASA 了。
老冯: 德国那帮人给的 Sovereign Tech Fund 估计帮了大忙，不然哪有钱搞这些。
小雅: 哎，你说 FFmpeg 要是倒了，整个互联网的视频流得崩成啥样？
老冯: 崩成一堆静态图，外加 YouTube 变成 GIF 画廊。
小雅: 哈哈，那我还是继续用 brew 装的残疾版吧，至少省心。
老冯: 省心是省心，但你永远不知道它背后少了哪个编解码器。
小雅: 算了，反正我又不用来做专业转码，能用就行。
老冯: 懒人有懒福，这不就是开源的魅力嘛。
老冯: 得了，FFmpeg 编译这破事儿，我是真服了。每次都跟玩俄罗斯方块似的，拼完一块又缺一块。
小雅: 哈哈，你这就是典型的「自己给自己找罪受」。直接用现成的 Docker 镜像不就完了？非要自己从源码编，活该受折磨。
老冯: 你懂个屁，现成的镜像能有我自己编的香？再说了，这不也是为了给 NAS 减肥吗？那些预装的玩意儿，一堆没用的依赖，占着地方不干活。
小雅: 行行行，你牛逼，你最牛逼。不过说真的，今天聊的这些东西，从代码审查到那些被遗忘的小站，感觉还挺有意思的。尤其是 FFmpeg 这坨屎山，我都想自己试试看了。
老冯: 你可拉倒吧，别到时候又来问我「为什么我的编译卡在了这里」。
小雅: 切，我才不会问你。实在不行，我就去 GitHub 找个 Issue 问问大佬。对了，想听下期的话，记得用你常用的泛用型客户端订阅一下，别老是等我提醒。
老冯: 行吧行吧，反正我也懒得去那些封闭平台折腾。RSS 一下，更新了就能收到，多省事儿。
小雅: 嗯，这还差不多。今天就聊到这儿吧，外卖都凉透了，我得去加热一下。下期有空再扯。
老冯: 得嘞，下次继续扯淡。记得把咖啡热热，别喝凉的，对胃不好。
小雅: 知道了知道了，老妈子。拜拜~