今天这五个帖子来自完全不同的板块，但读下来会发现它们在绕着同一件事打转：那些没有被写进文档、没有被记录下来的上下文，到底值多少钱。
Meta 想用 AI 换掉一批人，最后没换成；Debian 在讨论要不要干脆禁掉 AI 写的代码；一张薪酬对比图被评论区证明「图上的数字什么都没说清楚」；EVE Online 面对二十年前留下的 240 万行代码；有人把大模型的词向量空间画成地形图，然后被追问这张图里有多少是真的。每一个场景里，真正起作用的东西都不在你能看到的那部分。
一、扎克伯格的 AI 换人计划是怎么内爆的
原帖：Mark Zuckerberg had a bold plan to replace Meta staff with AI. Here’s how it imploded.
路透社的一篇长报道复盘了 Meta 内部一次组织重构：高管层设想用 AI 工具把团队规模压下去，文件里甚至出现了「10X Performer」这样的说法，还打了个篮球快攻的比方 —— AI 让你能出手更多次，而且出手质量更高。七月份扎克伯格在内部全员会上罕见地承认，这次重构的时间点判断失误了。报道里还有个细节：Meta 高管去亚洲考察时，很欣赏那边一些创业公司「围绕 AI 来搭组织架构」的做法。
评论区里最值得一读的不是骂人的那些，而是一条从实际使用体验出发的分析。一位工程师说，他自己写代码时最常发生的事，是写到一半突然意识到「糟了，这个我们没考虑」，或者需要停下来找人确认一个当初没敲定的决策。而 agent 从来不会这么做 —— 它拿着一组假设一路往下跑，直到吐出结果，而那些结果往往建立在一连串错误的前提之上。
“In my usage of agents, they do not do that at all. They do not ask questions after they start. They just start with a set of assumptions and keep on trucking until they produce an output.”
— u/ericl666，原帖评论
他后面那句更狠：中途改变方向一直是他职业生涯里的超能力，而 agent 在这件事上彻底不行。跟帖里有人补充了一个更长远的担忧 —— 如果新一代工程师从一开始就不用亲手趟这些坑，将来他们靠什么去判断 AI 跑偏了、又该在哪个节点把它拽回来。
另一条评论换了个角度，把「裁员省了多少钱」这笔账重新算了一遍：
“A team’s real asset is accumulated context, who knows which system breaks how and why a decision got made in 2019, which will leave when people leave.”
— u/AgentBlackVeil，原帖评论
还有两个细节挺有意思。报道提到 Meta 内部员工敬业度调查一年掉了 20 个点，有人指出这个数字之所以吓人，是因为大多数人在这类「匿名」调查里根本不敢说实话 —— 他自己就因为打过低分被主管找去谈话，从此一律给中庸分数。另一位刚从 Meta 离职一周的员工描述了非技术部门的状态：会议被随意取消或改期，同事陆续离开导致项目自然萎缩。
我的看法是，这条新闻真正的价值不在于嘲笑某个 CEO，而在于它把一个具体的判断标准摆了出来：AI 目前擅长的是「需求已经完全明确」的那一段活儿，而在大多数真实工作里，需求恰恰是在动手过程中才逐渐清晰的。谁在做前一半，谁在做后一半，决定了这轮替代对你的影响有多大。
二、Ubuntu 拥抱 AI，Debian 却在讨论全面禁止 AI 代码
原帖：As Ubuntu embraces AI, Debian discusses banning all AI-generated code
这条标题很有对立感，但评论区第一件事就是拆台：Ubuntu 那边说的 AI 是往系统里集成语音转文字之类的功能，Debian 讨论的则是「用 AI 编码工具写出来的代码能不能提交」，两件事根本不在一个层面上。而且提案范围只覆盖 Debian 自己维护的代码，上游项目（包括已经在接受 AI 辅助补丁的 Linux 内核）不在其中。
澄清完之后，真正的辩论才开始，而且质量相当高。支持者的核心论点不是「AI 写的代码有 bug」，而是「认知外包」：当你的任务从写代码变成审代码，你对这套系统的掌握程度会不知不觉地下降，将来出问题时，调试一段自己审过的 AI 代码，和调试一段自己写过的同样错误的代码，完全不是一回事。
“Even experts of many years will go through cognitive offloading if their task becomes not ‘write the code’, but ‘review AI-generated code’, so debugging it won’t be the same as debugging even identically erroneous code that you wrote yourself.”
— u/werbliben，原帖评论
反对者的回击也不弱：写得快本身就是实打实的收益，还能顺手抓到一些你自己会漏掉的边角情况。但立刻有人接了一句我今天最喜欢的反驳 —— 如果快永远是好的，那我们平时都该开到每小时 300 英里。也有人指出，省下来的那两小时并不是白捡的，它会被「搞清楚 AI 到底写了什么、安不安全、能不能维护」重新吃掉。
而最击中开源社区痛处的，是关于「承诺」的那条：
“Even a junior dev, who struggles for hours/days over a small change, has demonstrated a commitment that they are less likely to want to waste, by contributing a non-vibe-coded PR.”
— u/alex-weej，原帖评论
这话说的是维护者视角的经济学：一个新手为了一个小改动死磕两天，这份沉没成本本身就是一种信号，说明他大概率会跟进 review、会回来修。而一个五分钟生成的 PR 没有这层保证，审查成本却全落在维护者头上。有人补充说，杀死一个开源项目的从来不是代码写得慢，而是没有真正理解代码库、又愿意长期待下去的人。
对国内团队的启发大概是：如果你在制定团队的 AI 使用规范，值得把讨论从「生成的代码质量够不够」挪到「谁为这段代码的后续负责、这个人是否真的看懂了它」。前者是个技术问题，会随模型进步而缓解；后者是个组织问题，不会。
三、美欧软件工程师薪酬对比图，被评论区拆得只剩骨架
原帖：[OC] United States vs European Software Engineer total compensation by level
一张基于 levels.fyi 数据的图，按职级对比美国和欧洲软件工程师的总包（TC）。图上美国入门级 L1 中位数约 14 万美元，欧洲同级约 5.3 万欧元。这类图每隔一阵就会火一次，而这次评论区的拆解比图本身有价值得多。
第一层拆的是「欧洲」这个词。苏黎世、伦敦、华沙、马德里被塞进同一个柱子里，这几个市场之间的差距大得离谱。楼下有人跑去算了笔账：美国薪资最高州和最低州差约 1.6 倍，而欧盟内部最高国（丹麦）和最低国（保加利亚）差约 4.5 倍 —— 也就是说，「欧洲」这个聚合比「美国」这个聚合更没有意义。评论里各国工程师报出的数字也印证了这一点：瑞典入门约 4.4 万美元、英国政府部门初级 2.8 万英镑、西班牙 2 万到 4.5 万欧元，而荷兰和德国有人报出 6.7 万欧元起步。
第二层拆的是数据来源。levels.fyi 上报数据的人本身就是「关注顶级市场行情」的那一小撮，很多普通开发者压根没听说过这个网站，拿到差 offer 的人也更不会去登记。最精辟的总结是这句：
“Software engineering isn’t one job market, it’s several markets in a trench coat.”
— u/sessamekesh，原帖评论
第三层才是我觉得最有用的，两条关于「薪水到底由什么决定」的硬道理。一条纠正了「高薪只是因为生活成本高」这个常见误解：
“…your salary is not based on the cost of living, its based on the cost of labor. People get paid assloads in the Bay Area because that’s how much it costs to get someone to work for you and not the million other software companies.”
— u/Sethyboy0，原帖评论
另一条把话说得更一般化：工程师在「技术直接带来收入增长」的公司里赚大钱，在「技术只是成本中心」的公司里赚中等钱 —— 说到底，任何职业里离收入流越近、技能越稀缺，报酬就越高。还有人从公司结构上解释了欧洲的低薪：大公司的 C-suite 基本都在美国，欧洲以中小企业为主，管理层和员工的差距没那么夸张，代价是公司长不大、也就发不出那么多钱，换来的是更强的稳定性和保障。
这套框架其实完全适用于国内。同样是写代码，在一家技术即产品的公司和在一家把 IT 当后勤部门的公司，薪酬天花板差的不是一点点，而这跟你个人技术水平的关系，可能没有你以为的那么大。看这类薪酬对比图时，与其比绝对数字，不如问一句：这个岗位离公司的收入有多远。
四、EVE Online 终于开始迁移 Python 3 了
原帖：The Move to Python 3 Begins!
《EVE Online》官方发文宣布启动 Python 2 到 Python 3 的迁移。这游戏 2003 年上线，服务端跑的是一个高度定制的 Python 2 变种，还带着自己一套异步机制，代码量约 240 万行。发帖人是位在大型主机领域干了几十年的老兵，他觉得这事儿挺好笑 —— 一个「现代」语言居然也在经历这种迁移地狱。
“I just giggle every time I see a “modern” language or platform go through this. Meanwhile, z/OS and z/VM are still happily humming along, almost old enough to apply for Medicare, and stuff I learned in the 1970s is still relevant.”
— u/SheriffRoscoe（原帖作者），原帖评论
这句话点燃了整个评论区。有人当场反驳：正因为主机那套东西向后兼容到底，所以它也永远停在那里了。也有人站在中间 —— 用惯了老 C 或 Fortran 代码库的人会说，那种「语言不会每两年改一次」的确定性其实很奢侈，工厂里的嵌入式设备、PLC 就吃这一套，而 Python 3.4 之后就不支持 Windows XP、3.8.10 之后不支持 Win7 了。
技术层面最有料的是一场关于「2 转 3 到底难不难」的对撞。有人说自己十年前迁过三四个项目，跑一遍 2to3.py 再 review 一下就完事了；立刻有人贴出真实的坑：字符串默认变成 unicode 之后，所有手写 decode/encode 的地方都得重来。
“integer division of
1 / 3 == 0is true in py2, and py3 it’s not because it returns the float result. that had cascading effects throughout multiple layers of our stack.”— u/bmrobin，原帖评论
而给这场争论收尾的是一句冷冰冰的追问：那你那几个项目里，有几个是 240 万行代码的？还有人顺势提到用 AI 做迁移的话题，引出了 bun 那次「11 天、16.5 万美元」的重写案例，底下立刻有人算账说 16.5 万美元大概只是四到六人团队一个月的成本 —— 这个对照本身比争论谁对更有信息量。
这一节对国内读者最实在的启发可能是：技术债的利息不是线性的。同一套迁移方案，在几万行代码上是「跑个脚本再 review」，在几百万行上就是一个跨年度项目。而且真正难的从来不是语法转换，是那些只在运行时才暴露、又散落在整个技术栈里的语义变化。
五、有人把大模型的词向量空间画成了一张地形图
原帖：[OC] I turned Qwen 2.5-7B’s embedding space into a terrain map. Every mountain is a word cluster.
作者把 Qwen2.5-7B-Instruct 的输入嵌入矩阵（约 15.2 万 token × 3584 维）拿出来，用 nltk 词典过滤出约一万个真实英文单词，再做词干合并，然后 UMAP 降到二维，最后用核密度估计把词的密集程度转换成海拔 —— 词扎堆的地方成了山，稀疏的地方成了海。他列了几个有意思的发现：sexual 和 financial 共享一座山；unnecessary、inefficient、inappropriate 自成一条山脉；terrible、splendid、cruel 是邻居。
难得的是作者自己先划清了边界，没有把这张图吹成「模型的思维图谱」：
“This is the static input embedding layer, layer 0, before any inference happens. It’s a fossil of the training corpus’s distributional statistics…”
— u/arianaram（原帖作者），原帖评论
即便如此，评论区还是把方法论质疑得很彻底，而且质疑得在点子上。有人指出这张图叠了三层「加工」：选哪些词本身就在制造疏密、UMAP 只保护局部结构而不太在乎全局结构、KDE 的核与参数还能自由调节平滑度。结论相当克制但也相当有力：
“…this particular plot is basically “one artists rendition” of the latent space but you could make it look very different if you wanted to and it would be just as valid.”
— u/KMFN，原帖评论
作者的回应也很坦诚：山峰确实是用原始 3584 维空间里的余弦相似度算出来的密度，不是二维投影后才有的产物，但可视化上的选择的确会影响观感。整段来回读下来相当舒服 —— 提问的人懂行，回答的人不端着。另外有两条评论值得单独拎出来：一条说这张图里真正有意思的是海岸线，也就是那些卡在两个词簇之间、哪边都不属于的词；另一条说好的研究往往从分布里的离群点和边缘样本开始，因为山峰和明显的相关性太容易先抓住你的眼睛。
这也是我想留给今天这期的收尾：无论是薪酬图、地形图，还是一份说 AI 提高了多少效率的内部报告，好看的那部分通常是被降维、被平滑、被聚合过的结果。真正的信息往往藏在海岸线上 —— 那些不好归类、不好画进图里的地方。