科技大佬给 AI 踩刹车：「垃圾手榴弹」正在拖垮效率

steve, zhang — Sat, 19 Sep 2026 19:42:21 +0000

据《财富》杂志当地时间 9 月 17 日报道，曾经把 AI 捧为「释放员工全部潜力关键」的科技行业领导者，正开始悄悄改变说法。Shopify 联合创始人兼 CEO 托比亚斯·吕特克、多邻国 CEO 路易斯·冯·安等人，都收回了此前对 AI 的激进表态。

「垃圾手榴弹」横飞

吕特克去年曾要求员工把使用 AI 当作基本要求——在申请更多资源前，先证明现有工作无法用 AI 完成。如今他却批评员工把未经检查的 AI 邮件和代码直接交出去，却不愿为粗糙的结果负责。「我们把这种东西叫作『垃圾手榴弹』（slop grenades），人们把它们互相扔来扔去。这绝对是一件坏事。」

他指出，让 AI 彻底放开手脚很容易，但滥用只会把麻烦转嫁给接收和审核工作的人。AI 本该帮助整理邮件要点，而不是把几句话扩写成浪费别人时间的长篇大论。「你自己根本没认真读，现在却要让同事来审核，他们看完会说『这个不太对劲』。你只是把工作直接丢给 AI 去做。」

多邻国也踩了刹车

多邻国 CEO 冯·安同样收回了此前的激进立场。去年他宣布公司转向「AI 优先」，员工考核参考 AI 使用情况，部分人工承包商被 AI 取代，只有团队无法自动化时才增加人手。今年 5 月接受《Fast Company》采访时，他坦言自己曾被 AI 在写作演示中的出色表现「冲昏头脑」，但真正扩大规模后才发现，AI 最终仍比不上员工的创造力。「我们可能需要写 1000 个不同的故事来帮助人们学习语言，到最后你会发现，其中 20% 完全就是垃圾。每当我们用 AI 大规模处理工作时，都必须非常小心，不能让这些垃圾混进来。」

「workslop」有了学名

研究人员把吕特克描述的现象命名为「工作垃圾」（workslop）：表面精致、看似像模像样，实际却缺乏实用内容、还需要别人返工的 AI 产出。BetterUp 实验室与斯坦福大学社交媒体实验室今年调查了 962 名美国全职办公室员工，结果超过一半（52.7%）的受访者承认把 AI 工作垃圾发给过同事，而且所在机构越鼓励使用 AI，这种情况越常见；另有 38% 的受访者称收到过这类内容，平均每月要花 3.4 小时修改。

这类产出还会伤害同事关系——一旦对方怀疑收到的是 AI 工作垃圾，就会认为发送者能力更差、也更不友善；在收到过的人里，36% 表示今后希望避免再与这些同事合作。

返工成本持续走高

成本也在攀升。去年同主题调查中，40% 的受访者称遇到过 AI 工作垃圾，平均花费 2 小时修改；今年这一数字升至 3.4 小时。按 2025 年的估算，单名员工每月修改这类内容造成的成本约 186 美元（约合 1249 元人民币），而一家拥有 1 万名员工的机构，每年因此损失的生产力成本最高可达 900 万美元（约合 6042.7 万元人民币）。

AI 进入职场已是不可逆的趋势，但「用了 AI」不等于「提高了效率」。当工具把产出门槛降到极低，真正的瓶颈反而回到了人的判断与责任：哪些内容值得发出、哪些必须自己读过再交付。大佬们集体踩刹车，提醒的正是这一点。

不用 Redis 也能扛住：Shopify 用 MySQL 重写库存预留

steve, zhang — Sun, 09 Aug 2026 13:41:52 +0000

你以为高并发的库存系统离不开 Redis？Shopify 工程团队用一次「反向迁移」给出了另一种答案：他们把库存预留系统从 Redis 搬回 MySQL，并在 2025 年黑色星期五扛住了峰值——当时平台每分钟销售额达到 510 万美元。Shopify 支撑着美国超过 14% 的电商交易。

旧方案的问题出在「两套账」。库存计数存在 Redis 里（占用就减、释放就加），但真正的库存总账在 MySQL。两步没法打包成一个原子操作，一旦顺序出错，就会出现超卖（东西卖了却没从总账扣掉）或幽灵库存（扣了却还显示占用）。Redis 也不感知多仓库库存，还得单独养一个集群。

新方案靠的是 MySQL 8 的 SKIP LOCKED 特性。核心思路是「每个可售单元存一行」，而不是「每个商品存一行数量」。一件有 10 件库存的商品就对应 10 行，预留 3 件就是一次性锁 3 行、挪进预留表。为避免行数爆炸，每个商品/仓库最多维持 1000 行可用池，不够了再由补充进程从总账补齐。SKIP LOCKED 让并发请求跳过被锁的行、直接拿别的可用行，不用排队。

几个工程细节值得记：把主键改成复合主键（店铺、商品、分组、序号），每行锁从两把降到一把；把事务隔离级别从默认的「可重复读」降到「读已提交」，避开空表补充时的间隙锁死锁；统一「先删后插」的锁顺序，消除预留与扣减路径间的循环等待；再用 UNION ALL 把一单多件的查询合并成一次往返。

最有意思的是真瓶颈不在数据库。调完表结构，吞吐量还是卡在目标线下，CPU 也没跑满。团队给每条 SQL 打上业务标签（例如「conn_tag:checkout_completion」），在数据库代理层按调用方统计连接占用时长，才发现是结账链路上的其他环节长时间霸占连接。清理掉这些长事务后，主库读操作减少 50%、事务数减少 33%。

迁移采用影子模式：Redis 和 MySQL 双写一段时间，确认无误再逐步把「真相源」切到 MySQL，并保留一键回滚。

说白了，很多「必须上 Redis」的判断，只是因为当年 MySQL 还没有 SKIP LOCKED 这类能力；如今你手上的数据库往往就够用。真正的瓶颈常常藏在代码里的连接管理，而不是引擎本身。下次想引入新中间件之前，不妨先看看现有数据库的新特性和连接画像。