今天这五个帖子里，有三个都在绕同一个问题打转：效率提升之后，那部分多出来的价值到底归谁。老板有老板的算法，分析师有分析师的焦虑，连买车的人都在算同一笔账。剩下两个则是纯粹的技术乐趣——一条要跑 62 秒的 CPU 指令，和一场关于文档格式的经典口水战。
Meta CTO：AI 让你效率翻倍，那就把活也翻倍
Meta 的 CTO 公开表示，员工借助 AI 获得的生产力提升，应该用来完成更多工作，而有人提议把省下的时间换成额外休假日，他直接评价为「非常蠢」。这话在 r/technology 上瞬间点燃了评论区。
最集中的反问只有一句：那薪酬涨不涨？有人算得很直白——如果 AI 让你效率翻倍，最后唯一真正翻倍的只有工作量。但评论区没有停留在情绪上，几条冷静的回复把逻辑讲透了：工资从来不是按你创造的价值定价，而是按「别人愿意用多少钱做同样的活」定价，一旦所有人都能靠 AI 干两倍的活，市场基准就是两倍产出配原来的薪水。也有人搬出股权论——RSU 会随公司估值一起涨，所以理论上员工是分到了红利的——这条被踩得很惨，但反驳它的人给出的证据更有说服力：计算机普及的时候也没见工资跟着生产力曲线走。
“If AI makes you twice as productive, somehow the only thing that gets doubled is the workload.”
— u/consumersguide，原帖评论
“how much employers pay is based on how much others are willing/capable of doing the work for. if all employees are capable of doing 2x the work magically, then the expected output is 2x with the same wages.”
— u/charging_chinchilla，原帖评论
这套逻辑对国内读者应该并不陌生。真正值得警惕的不是「多干活」本身，而是 AI 把交付基准线整体抬高之后，原来那个「按时完成就算合格」的锚点会悄悄消失。有条评论说自己花了近二十年才遇到一位认同「早干完就多派活」终将导致 burnout 的老板——这句话之所以能获得高赞，恰恰说明它有多稀缺。
分析师第一次用上「接进数仓的 AI」，然后开始怕自己废掉
一位老派数据分析师换到大厂后，第一次用上和数据仓库、语义层深度打通的 AI 工具：描述需求，它自己找表找字段、推断 join、写并执行 SQL、检查空值和分布、还帮你校验结果。他形容体验「离谱地好用」，随即冒出两个问题——我会不会因此手废了？以及，这对数据岗意味着什么？
评论区的回答意外地统一而且清醒。第一条被顶起来的观点是：公司里把 AI 用得最好的那个人，恰恰是原本功底最扎实的人，因为只有他知道什么输出该接受、什么地方该纠偏。有人举了个特别典型的例子：同事每天把格式完全相同的 PDF 丢给 ChatGPT 转表格，结果时好时坏，却从没想过让 AI 直接写一个确定性的 Python 脚本——区别不在提示词，而在你脑子里有没有那前几步的方法论。另一派回答则直接重构了提问的前提：你是在把自己定义成「写 SQL 的人」，而不是「数据分析师」。也有人诚实承认真的会退化——不是分析能力，而是面试白板上手写查询的肌肉记忆，一段时间不练就明显生疏。最扎心的一条担忧来自一位非数据领域的资深从业者：AI 帮资深者跳过的那些「枯燥的开头部分」，恰恰是初级员工唯一能长出高级能力的地方。
“Anecdotally, the person who uses AI the most efficiently at my company is the one who knew the most beforehand, so they better understand what outcomes to accept and how to steer AI since they’ve already done these things before.”
— u/Kawhi_Leonard_，原帖评论
“You are framing your job as being a SQL programmer and not a data analyst. SQL is just a tool to extract and manipulate data.”
— u/jejasin，原帖评论
顺带一提，评论里还有个容易被忽略的细节：好几个人羡慕的其实不是那个 AI，而是「有一个能用的语义层」。有人吐槽自己待过的公司每个指标都有四五个版本，谁也说不清区别——在这种数据底子上接 AI，只会让错误答案生成得更快。这大概是对国内很多团队最实际的提醒：AI 提效的前置条件是数据治理，顺序反了就是加速踩坑。
有人在给「最慢的汇编指令」排名，冠军跑了 62 秒
一个叫 Assembly Hall of Shame 的项目在比谁能让单条 CPU 指令跑得最慢，榜首的成绩是一条指令耗时 62 秒。r/programming 的讨论迅速从「这也行」转向了「这到底算不算作弊」。
技术上的解释很有意思：这些极慢指令大多不是 CPU 本身算得慢，而是走了 MMIO——内存控制器把外设的寄存器映射进了 CPU 地址空间，于是一条普通的读写指令实际上在等最慢的那条总线。有人因此觉得这偏离了主题，充其量是在找慢 I/O；反驳的一方则说，人家并没有直接把核心关掉，只是让其他核心去疯狂挤占同一条通道，把它排到队尾——重点是全程都用「正常操作」堆出了这个结果。真正让这件事从趣闻变成正事的是另一条评论：SMM（系统管理模式）的安全性依赖「所有核心同时进入或同时退出」，实现上通常会加一个约 40 亿周期、也就是差不多一秒的超时保护，前提假设是「没有指令能跑那么久」——而这个榜单正好证明了这个假设不成立，攻击者可以把某个核心卡在一条超长指令里。榜单里还有更阴间的条目，比如 split lock：不仅自己奇慢，执行期间还会锁死整条内存总线，让所有其他核心一起陪跑；有人在 VFIO 虚拟化环境里就撞上过，Linux 默认的 split lock 检测反而把 Windows 客户机拖到蓝屏。
“I would never have guessed that 62 seconds for a single instruction was possible without outright cheating like disabling the core it’s scheduled on. Incredible stuff.”
— u/HighRelevancy，原帖评论
“So better add a 4,000,000,000 cycle (or ~1 wall second) timeout, right? No instruction could possible take that long, right? … Wrong!”
— u/KittensInc，原帖评论
这类「无用之用」的项目常常比正经 benchmark 更有价值：它们专门去撞那些写在注释里的隐含假设。「一条指令不可能跑超过一秒」听起来天经地义，但只要写进了超时逻辑，它就是一个可以被攻击的边界条件。做工程久了会有种直觉——每一个你觉得「不可能发生所以不用处理」的分支，早晚都会有人专门造出那个场景给你看。
Python 该不该像 Rust 一样统一 docstring 格式
发帖人羡慕 Rust：文档注释统一用 Markdown，连 # Errors、# Panics 这样的小标题都是约定俗成的，所以 docs.rs 能给任何一个 crate 自动生成文档站，LSP 也只需要处理一种格式。反观 Python，NumPy 风格、Google 风格、若干种 reST 变体并存，他的提议是：定一个 Markdown 标准，让 PyPI 能自动建文档站。
评论区第一时间甩出了 PEP 287——2002 年就有的官方文档字符串规范，至今仍是 active 状态，「有标准」和「大家照着做」显然是两回事。紧接着是必然出现的 XKCD 927 梗（想统一 14 种标准的结果是产生第 15 种），但这次的反驳挺有说服力：pyproject.toml 和 PEP 751 都证明了 Python 是能收敛标准的。真正的分歧在落地路径上——有人质问「你打算去把全世界已有项目的 docstring 都改一遍吗」，发帖人的回应是这可以做成 opt-in，就像当年类型标注用 py.typed 标记一样，没人被强制迁移。还有一条冷静的长期视角：Rust 现在格式统一只是因为它还年轻，Markdown 也不会是最后一种标准，语言要么停止演化，要么接受标准漂移。
“You gonna go and update all the docstrings in every Python project ever written to match your new standard? Good luck with that.”
— u/Exnixon，原帖评论
“There’s no reason to force everyone to update, just like the addition of type hints didn’t force everyone to update their signatures.”
— u/denehoffman（原帖作者），原帖评论
这场争论现在多了一层新意义：docstring 已经不只是给人看的了。LLM 和各类代码 agent 读代码时，格式统一、结构可预测的文档字符串直接决定了它们能不能正确理解一个 API 的错误行为和边界条件。type hints 当年靠 opt-in 慢慢渗透，最后几乎成了现代 Python 的默认写法——docstring 标准化如果真要推，大概率也只能走这条路。
马力从没这么便宜过，可大家想要的是便宜的车
一位网友用 EPA 燃油经济性数据库里近 7 万个车型版本做了个指标：用上市价除以马力。换算成 2026 年的币值后，1992 年的中位数是每马力 261 美元，2026 年是 176 美元——便宜了 32.6%，而汽车的其他一切成本都在往反方向走。
评论区几乎没人质疑数据，但所有人都在质疑这个指标本身衡量的是不是大家关心的东西。最高赞的一条说得很到位：现代车更强、更省油、科技配置更多，这些没人否认；问题是消费者宁愿把这些东西砍掉一部分，换一个整体更低的价格。围绕「那为什么车厂不造便宜车」的追问，一位自称在大车厂做高级工程师的网友给了产业侧的答案：利润率低的车型就没有研发投入，便宜车必然配置更差，而每次真有便宜车上市，嘴上喊着要的人总能找出五条理由不买它。还有人补充了一个容易被忽略的经济学细节——爱买便宜二手车的人根本不进新车市场，但二手车只能由新车变来，需求信号从一开始就传不到生产端；以及，砍掉一个中控屏也许能省 100 美元，但为此多开一条产线配置的固定成本，靠那点需求根本摊不平。
“I think everyone can agree you get more tech, efficiency, and power out of modern vehicles. The complaint is that they’d rather take some of that out and pay less altogether”
— u/hawkeyes007，原帖评论
“Cars with less profit margin will have less development, cars that cost less will have less features.”
— u/Usedtissue_Gaming，原帖评论
这是一个很好的「指标陷阱」样本：单位马力价格确实在下降，结论在数学上完全成立，但它默默假设了消费者买车是在买马力。做数据分析时最容易犯的错，往往不是算错，而是选了一个自己算得出来、却不是用户真正在意的分母。这条经验放在产品指标、KPI 设计上同样成立——很多「持续向好」的曲线，只是分母选得聪明而已。
今天这几个帖子摆在一起，最耐人寻味的还是那条隐线：效率提升本身几乎从不自动惠及创造它的人，从打工人到分析师到买车的消费者，多出来的那部分价值最终流向哪里，取决于议价能力和衡量标准由谁定义。而这，恰恰是技术讨论里最少被讨论的部分。