Posts on 小盒子的技术分享

Claude 要你交护照了，这背后藏着一个创始人的执念

Thu, 16 Apr 2026 02:00:00 +0000

昨天很多人被一条消息炸到了，Claude 上线了身份验证，要你交护照照片加实时自拍。

群里瞬间炸了。有人说「我寻思着我就写个代码，咋还得刷脸了」，有人说「这下好了，连绕路都不够用了，还得造身份」。

我用 Claude 系列产品差不多快两年了，从最早的 API 到后来的 Claude Code，几乎天天在用，写代码、写方案、搞分析。所以这次身份验证的事，不是隔岸观火，是直接打在我身上的。

也正因为用得深，我对 Anthropic 这家公司这几年干的事看得比较清楚。今天不想只聊身份验证本身，想把它背后那条线索捋一捋。

很多小伙伴可能觉得，这不就是合规嘛，美国公司搞个验证有啥好说的？

没那么简单。

如果你把 Anthropic 这几年的政策串起来看，你会发现一个非常清晰的趋势，它在一步步构建一座围墙。每一块砖看起来都合情合理，但砌到最后，墙里的人发现自己越来越难出入了。

咱们从头捋。

Anthropic 的封闭之路，大致可以分成四个阶段。

第一阶段是区域封锁。2023 年 Claude 上线，一批国家直接进了「不支持」名单，中国、俄罗斯、伊朗、朝鲜。这个阶段大家没太在意，OpenAI 也差不多，美国 AI 公司基本都这样。

第二阶段是 API 管控。2024 年 OpenAI 率先封锁了中国区 API，给了开发者不到一个月缓冲期。Anthropic 跟进。这一刀下去，大量靠 Claude API 做产品的中国开发者被迫迁移，有的花了两个月才把业务切到别的模型上，客户掉了一截。

第三阶段是资本审查。2025 年 9 月，Anthropic 更新了服务条款，打击面从「在中国的公司」扩大到了「被中国资本控股超过 50% 的公司」，不管你注册在新加坡还是开曼群岛。据《金融时报》报道，这一刀砍掉了「低数亿美元」量级的收入。Anthropic 是明知道亏钱，还是做了。

第四阶段就是昨天的身份验证。护照照片加实时自拍，由第三方公司 Persona 处理。官方说法是防止滥用、遵守法律义务。

大家注意看这四步，从封国家到封公司到封个人，打击精度越来越高，颗粒度越来越细。

这让我想到一个东西，机场安检。

911 之前，坐飞机基本不用脱鞋。然后是脱鞋，然后是开箱检查，然后是全身扫描，然后是液体不能超过 100 毫升。每一步都有道理，每一步都为了安全。但二十多年过去了，坐飞机的体验越来越差。

而真正想搞事的人，从来不走正门。

Anthropic 的安全策略走的是同一条路。

说到这里，可能有小伙伴纳闷了，为啥 Anthropic 比 OpenAI 还激进？OpenAI 也封了中国，但人家至少没搞到「查你股东是哪国人」这个地步。

要理解这件事，得从 Anthropic 的创始人说起。

Dario Amodei，意大利裔美国人。他父亲 Riccardo 是一个来自托斯卡纳的皮革匠人，母亲 Elena 是芝加哥出生的美国人，在伯克利给图书馆做装修项目管理。这个家庭组合不是典型的硅谷精英家庭，倒更像你在旧金山湾区随便转转就能碰到的那种中产。

Dario 本人是加州理工的物理学出身，后来转到普林斯顿读了生物物理学博士。转学科的原因很关键，2006 年他父亲 Riccardo 因为一种罕见疾病去世了。那个病在当时大约 50% 的致死率，但仅仅四年后，一项新的医学突破把这个数字降到了 5%。

四年。就差了四年。

这件事对 Dario 的影响极大。它让他建立了一个非常强烈的信念，技术进步可以救命，但如果进步的方向被扭曲或者速度被拖慢，代价是具体的人的生命。这也是为什么他后来一头扎进了 AI 安全领域。

2016 年 Dario 加入 OpenAI，参与了 GPT-2 和 GPT-3 的开发，做到了研究副总裁。但 2021 年他带着妹妹 Daniela 和一批高管集体出走，创办了 Anthropic。

出走的公开理由是「对 AI 安全的方向有分歧」。Dario 认为 OpenAI 在安全上做得不够，太急着商业化了。

注意这个逻辑，他觉得世界上最知名的 AI 安全机构还不够安全，所以自己出来做一个更安全的。

这个出发点我完全理解。一个因为「技术晚到四年」失去父亲的人，对风险的感知天然比一般人更敏锐。这甚至可以说是一种美德。

但问题在后面。

当「安全」从一个技术理念变成了公司的核心身份标签，它就不可避免地会从技术层面滑向政治层面。

Dario 在 2024 年发表了一篇长文叫「Machines of Loving Grace」，2026 年又写了续篇「The Adolescence of Technology」。他在文中列了五类 AI 风险，其中一条特别值得关注，就是 AI 被「对抗性国家」用于军事和情报用途。

当一个公司的创始人把「对抗性国家」写进了核心风险框架，后面发生的所有事情就都有了根基。

Anthropic 内部有一份文件，把中国定性为「adversarial nation」。这不是泄密，是他们公开政策的直接延伸。

2025 年有过一次因为这件事引发的内部地震。一个叫姚顺宇的华人研究员，斯坦福理论物理博士，2024 年 10 月加入 Anthropic，直接参与了 Claude 3.7 Sonnet 的开发。但不到一年他就离职了，去了 Google DeepMind。

他公开写了一篇博文，说离职原因中 40% 是因为 Anthropic 把中国定性为「对抗性国家」。他说他相信公司大多数人不认同这种措辞，但作为一个中国人，他没法继续待下去。

一个参与核心产品开发的研究员，因为公司的地缘政治定位而出走。这个信号很重要，它说明 Anthropic 的安全叙事已经不只是技术框架了，它在影响人才的去留。

说到这里，可能有人会问了，Anthropic 这些限制到底有没有用？能不能真的挡住恶意使用？

我觉得大家可以看一个历史案例。

1949 年冷战刚开始的时候，美国牵头搞了一个叫 COCOM 的国际组织，全名「巴黎统筹委员会」，专门协调西方国家对苏联的技术出口管制。半导体、计算机、精密机床，统统上了禁运名单。

这个体系运行了 45 年，直到 1994 年苏联解体后才解散。

效果怎么样呢？

1986 年 CIA 自己做过一个评估，说苏联半导体产业落后美国大约八到九年。但 CIA 同时也说，这个差距更多是苏联自己的生产管理问题导致的，COCOM 封锁「可能」是因素之一，注意措辞，是「可能」。

更打脸的是 1987 年曝出的东芝丑闻。日本东芝和挪威康斯贝格偷偷卖给苏联先进的铣床，让苏联海军造出了更安静的潜艇。COCOM 管了 38 年都没管住一台铣床。

45 年的技术封锁，史上最严密的多国协调出口管制，最后 CIA 自己都承认效果有限，而且最大的漏洞来自内部。

现在把这个故事和 Anthropic 放在一起看。

你觉得一个身份验证加一个服务条款，能挡住什么？

真正想搞事的机构和个人，开个壳公司，用第三国护照，通过 AWS Bedrock 间接调用，方法太多了。COCOM 管不住一台东芝铣床，Anthropic 的身份验证能管住一个懂点网络技术的工程师？

被挡住的永远是那些想正经用 Claude 写代码、做研究、搭产品的普通开发者。他们不仅贡献收入，还贡献使用场景反馈和社区生态。

这就是安全悖论的经典表现。就像机场安检升级了无数次，但后来真正造成伤亡的恐怖袭击，几乎没有一次是在机场安检环节发生的。安检越严，走正门的人越少，绕道的一个也没少。

当然了，也不能说 Anthropic 完全没道理。美国政府确实在收紧对中国的技术出口管制，AI 领域尤其敏感。一家在美国融了上百亿美元的公司，不配合政策方向基本不现实。

但配合政策和主动激进，是两件事。

OpenAI 封了中国 API，没搞资本审查。Google 的 Gemini 在不少地区还能用。Meta 直接把 Llama 开源了，你想在哪跑就在哪跑。同样是美国 AI 公司，同样面对差不多的政策环境，Anthropic 选了最激进的那条路线。

这不是被逼的，是选的。

为啥选这条？因为从 2021 年 Dario 出走 OpenAI 的那天起，「我们比所有人都更安全」就是 Anthropic 的核心叙事。这个叙事帮他们融到了钱、招到了人、拿到了独特的市场定位。

但叙事这个东西是有惯性的。一旦你把「安全」举到了最高处，你就很难在任何一个具体问题上选择宽松，因为每一次宽松都是在自己的核心故事上打折。

所以身份验证不是终点，是中间站。按这个惯性走下去，下一步大概率是更严格的免费用户限制，或者更激进的内容过滤。

回到咱们自己的处境。

如果你也在用 Claude，不管是写代码还是做别的，这件事给你的信号已经很明确了，不要把全部家当押在一家公司的善意上。

Claude 的技术实力毫无疑问是顶级的。就说代码能力，目前大概率是业界最强的那一档。

但有个很讽刺的事你想想，我正在用的这个工具，它的母公司正在想办法让我更难用到它。

工具终究是工具。你不能在别人随时可能收回去的地基上盖房子。

国产模型这两年进步飞快。DeepSeek 在推理和代码上已经打到了第一梯队。开源的 Qwen、Llama、Mistral 你可以跑在自己机器上，不用看任何人脸色。

多条腿走路不是因为某一条腿不好，是因为只有一条腿的时候，别人砍你一刀你就倒了。

当然了，也不用太焦虑。Anthropic 的限制主要打的是直接使用 Claude 的场景，如果通过 AWS Bedrock 或者其他云平台间接调用，政策执行有时候会不太一样。而且技术领域变化快，现在看着铁板一块的限制，过两年说不定就松动了。

不过有一件事我觉得值得大家认真想想。

Anthropic 的案例揭示了一个更深的东西，那就是当一家公司把某种价值观变成商业品牌的时候，这个价值观就不再是单纯的理念了。它变成了一种路径依赖。

Dario Amodei 大概率是真心相信 AI 安全很重要的。一个因为「技术晚到四年」而失去父亲的人，他对风险的感知比我们任何人都深。这一点我不想否认，甚至非常尊重。

但当「安全」变成了公司的身份标签、融资故事和竞争壁垒，它就必须不断升级、不断加码。否则叙事塌了，公司的根基也就塌了。

用户在这个过程中，不是被保护的对象，而是被管理的对象。

这条路不只适用于 Anthropic，也适用于任何一家以价值观立身的公司。当价值观变成了品牌，它迟早会反噬使用者。

就像机场安检，你不能因为曾经有人带了危险品，就要求所有人飞行前先做一次全身 CT。安全的边界如果无限扩张，最后得到的不是更安全的天空，而是一个没人愿意坐飞机的世界。

所以咱们能做的，就是别把自己的工作流绑死在任何一家公司的善意上。

善意是会变的，能力留在自己手里才是真的。

我是小盒子，咱们下篇见。

为什么手机信号格最多 5 格，而且每一格都是骗你的

Wed, 15 Apr 2026 13:31:00 +0000

上周末我跟朋友在一家小餐厅吃饭。

他刚换了华为的新旗舰，掏出来拍菜，拍得特别起劲。拍着拍着抬头跟我说，你看这信号，满格。上次我来这家店一格都没有，换个手机完全不一样。

我低头瞄了一眼自己的 iPhone。2 格。

我没接话。

换半年前，我大概率会跟着点头，说句确实新机天线牛。但最近因为一个偶然的原因，我知道了一件事。

手机信号格，根本就不是一个物理量。

它长得像物理量。塔往你手机上打信号，手机把信号强度换算成几条小竖线画在状态栏上，看上去跟温度计的水银柱没什么区别。

但它不是。

塔发给你手机的信号确实有一个客观单位，叫 dBm，4G 和 5G 里面用的具体指标叫 RSRP。这是整个通信行业的规矩，全世界同一个位置测出来都是同一个值，几十年没变过。可是从 RSRP 到状态栏上的「几格」这一步换算，是谁定的呢？

手机厂商自己。每家一套。关起门来拍脑袋。

苹果一套，华为一套，小米一套，OPPO 又是另一套。同一张桌子、同一张运营商卡，几台不同牌子的手机并排举起来，能给你凑出一整张阅读理解答案。大家都信以为真。

但这只是第一层。它还有第二层，所以连手机厂商都不是最后拍板的人。

2018 年 Google 发布 Android 9 的时候，悄悄在系统里加了一组 API，允许运营商通过一个叫 CarrierConfig 的机制，给手机远程下发信号条的阈值。直说就是，运营商可以告诉你的手机，RSRP 低于 -95 dBm 的时候显示 4 格，低于 -105 显示 3 格，低于 -115 只剩 1 格，具体数字由运营商自己填。两年后的 Android 11 把这套能力继续扩展到 5G NR 和 SINR 上，等于把信号条的每一个环节都交给运营商定义。

以前我一直以为，手上的 iPhone 或者某台安卓手机，是两家公司跟我之间的合同。手机公司告诉我塔有多强，我信它。结果从 2018 年开始，这个合同里悄悄多了第三方。

换一张运营商卡，同一台手机、同一个位置，信号格数量都可能跟着变。手机厂商不再是最后的裁判，运营商才是。

这一下以前很多事情对上了。比如我上次去东南亚出差，一落地接上当地网络，同一台 iPhone 信号格莫名其妙就变好了。之前我还以为是当地基站比国内强，回头想明白，大概率是本地运营商发了一套比国内宽松得多的阈值，好让你觉得，至少还能聊微信。

这些事其实都不新鲜。十六年前，苹果就当着全世界被同一个问题按在地上摩擦过一次。

那年是 2010 年，iPhone 4 发布三天之内，用户发现左手握住机身左下角那条金属接缝，满格信号会唰一下掉到一格甚至断线。这就是后来被写进科技史的 Antennagate 天线门。

苹果一开始的回应是乔布斯一封著名邮件，Just avoid holding it in that way，你别那么拿不就行了。但在幕后，苹果团队扎进去查问题的时候发现了一件比天线本身更让他们头皮发麻的事。iPhone 的信号条公式，写错了。

同年 7 月 2 日，乔布斯亲自署名的公开信出现在苹果官网。原话是，我们震惊地发现，我们用来计算信号条显示几格的公式完全是错的，在很多情况下比应该显示的多画两格。两周后 iOS 4.0.1 发布，把公式按 AT&T 推荐的值重写了一遍。去年 10 月有个开发者把这两个版本的固件反编译对比，挖出核心改动只有大约 20 字节。苹果最著名的公关危机之一，技术上的修复是 20 个字节。

按理说，一家巨头当众承认过「我们的公式完全错了」之后，行业应该吸取教训搞一个诚实点的显示。十六年过去了，结果完全不是。

苹果自己的状态栏样式倒是翻来覆去改过好几轮。iOS 7 那会儿把 5 条大竖线换成 5 个小圆点，2017 年 iOS 11 又改回 4 条竖线，官方理由是给 iPhone X 的刘海腾状态栏空间。有意思的是，苹果不光换样式，还顺手把满格的门槛也调了。AnandTech 当年拿 iPhone 7 Plus 实测过两代系统，iOS 10 要求 RSRP 强过 -60 dBm 才给你满格（5 个圆点），到了 iOS 11 这个门槛放宽到了 -65 dBm（满格是 4 条竖线）。5 分贝听起来不多，放在通信这行里已经是肉眼可见的一大截。同一台 iPhone 在一个 -62 dBm 的位置，iOS 10 只给你 4 格（5 格里的第 4 格），换成 iOS 11 就直接满格 4 条。多出来的那一格不是因为塔变强了，是因为系统升级那天，苹果悄悄把满格的门槛降了一档。

华为、小米、vivo、OPPO 也都一样。每家旗舰跟同一张 SIM 卡放在一起都能凑出三种不同答案，没有任何一家公开过自己的映射表。大家心照不宣地把「让你看着舒服」放在「让你看到真实值」前面。

说到「心照不宣」，顺便聊几件业内都知道、但运营商和手机厂商从来不会主动告诉你的事。

先说一个最常见的。信号满格跟你能不能打通电话、能不能发出去微信，根本是两回事。

信号条的公式不管哪家怎么定，算的都是你手机跟塔之间那根电波强不强，算出来的是一个单纯的接收功率。它只反映一件事，你离塔有多近、中间隔了多少墙。但它完全不反映另一件事，那个塔现在还有没有空位留给你。

你肯定遇到过这种场景。演唱会现场、跨年夜外滩、春运候车厅、世界杯的体育场，手机满格，微信发不出去，红包抢不到，电话打不通。真相是塔那头的信道资源已经被塞爆了。一个基站能同时服务的用户数有物理上限，超了之后新来的用户信号再强也上不去。信号条不管这个。它就跟一家酒店的大堂经理一样，永远微笑着告诉你我们这儿很豪华，从来不告诉你今晚没房。

再说一个你每天都在用但不知道原理的。你以为**「切一下飞行模式再关掉」**是个玄学小妙招，背后其实有实打实的技术原因。

手机在 idle 状态下挑基站有一个惰性原则，只要当前连着的那个塔没掉到阈值以下，手机就不会主动去换塔，哪怕旁边有一个更强的。这是 4G 和 5G 协议里写死的 cell reselection 机制，为的是省电和避免频繁切换抖动。所以你从好位置走到不好的位置，手机很可能还赖在原来那个早就不够用的老塔上，死死不放。这时候你打开飞行模式，手机断开所有射频连接，再打开它被迫重新扫一遍所有可用基站，挑一个最强的连上，信号就「突然变好了」。

最后一个。你状态栏上那个 5G 图标，很多时候跟 5G 没太大关系。

5G 有两种部署方式，SA 独立组网和 NSA 非独立组网。国内三大运营商早期铺的 5G 基本都是 NSA，简单说就是手机同时挂在 4G 和 5G 两个基站上，下行跑 5G 快一点，上行（你发微信、发朋友圈、发视频那些）还是走 4G。状态栏只告诉你显示了 5G，不告诉你上行其实还在 4G。

最离谱的例子发生在 2018 年底的美国。AT&T 直接把 4G LTE Advanced 的网络标成 5G E，E 是 Evolution 演进的意思，堂而皇之地在用户的 iPhone 和安卓机状态栏上显示「5G E」三个字。整个美国通信圈把这事儿嘲笑了整整两年。2019 年 1 月 7 日，T-Mobile 官方推特发了一个短视频，视频里有人往一台 iPhone 屏幕上贴了一张写着「9G」的便利贴，配文「没想到升级这么简单，我先去更新一下」。后来美国广告审查机构 NAD 正式建议 AT&T 停用 5G Evolution 这个说法，但那个 5G E 图标一直留在状态栏上没删。

说了这么多，你其实也能自己亲手看一眼塔发给你手机的东西到底有多强。

iPhone 上，打开拨号盘输入 *3001#12345#*，按绿色拨号键。手机会直接进入一个叫 Field Test Mode 的隐藏界面，里面有一个 RSRP 数字。负数，越靠近 0 越强。一般 -80 以上算不错，-100 到 -110 之间开始掉速度，-115 以下基本就是快断线的状态。iOS 18 之后这个界面还顺便加了 SINR，信号质量指标，数字越大越好。

Android 上拨号盘敲 *#*#4636#*#*，进入菜单里的「手机信息」或「SIM 卡状态」，就能看到原始的 dBm 读数。少数深度定制系统把这个入口堵上了，大部分机型还留着。小米用户也可以在设置 → 我的设备 → 全部参数里直接找到 SIM 卡状态。

下次你在一个信号满格但微信发不出去、电话打不通的地方，可以拨一下那个代码试试看。屏幕上跳出来的那个负数，才是今晚塔真正愿意送到你兜里的东西。至于状态栏上那几条小竖线，它从来不是一个测量结果。它是一家手机厂商、一家运营商、外加一个远在硅谷或者深圳的产品经理，三方坐在一起商量之后，决定「让你看着还行」的一个小动画。

回到开头那家小餐厅。我朋友那台华为满格，我那台 iPhone 2 格。它们其实都没错，也都没真对，只是两家不同公司的产品经理对「你应该感觉有多安心」给出的两种不同答案。那个塔呢，它从头到尾就在餐厅外面，不多不少地发它那一点 dBm。

会变的，只有兜里那块屏幕替它说出来的话。

为什么 .tar.gz 要两个后缀

Mon, 13 Apr 2026 23:00:00 +0000

前两天我在重新编译一版 nginx。

流程基本闭着眼睛都能走。wget 拉下来一个 nginx-1.27.4.tar.gz，tar -xzvf 解开，进目录，./configure，make，make install。

敲完 tar 那条命令的一瞬间，我突然愣了一下。

这个 .tar.gz，两个后缀。

我用了大概十几年，从来没认真想过为什么要两个。

顺着这事我又想起来，我这双手对 tar 的记忆完全是肌肉记忆，xzvf 这四个字母该按什么顺序，大脑是不参与的，手指自己会动。正因为是肌肉记忆，我还踩过一个经典坑，偶尔下载到没有顶层目录的 tar 包，照样一梭子解下去，几十个文件啪一下全炸到当前目录，瞬间把工作目录变成垃圾场。

那种时候我一边 ls | xargs rm 一边告诉自己下次一定先 mkdir。

但下次还是不会。

人对每天都在用的东西是最没好奇心的。

说回 .tar.gz。这两个后缀到底是什么关系，为什么非得拆成两个。

我带着这个疑问查了一圈，发现这事比我想象的有趣得多。它不是什么历史包袱，也不是约定俗成的命名习惯，它是两个时代两个工具掰着手指头拼出来的一个结果。

先说 tar。

tar 这个命令，最早出现在 1979 年 1 月的 Unix Version 7 里，AT&T 贝尔实验室做的。名字也没什么加密的缩写，就是 Tape ARchive。翻译过来，磁带归档。字面意思。

你可以想象一下 1979 年。那会儿大家备份数据靠的是磁带，就是老电影里那种两个圆盘转啊转的大盘子，数据一圈一圈顺序刻在带子上。你不能跳着读，也不能中间插一段，只能从头到尾一次性过。

tar 这个工具的出生使命，就是为了给磁带服务的。

所以它做的事情特别简单，就一个动作，把一堆小文件按顺序拼成一条长长的字节流，好让磁带机一口气写下去。

注意，我说的是「拼成一条流」。

tar 压根就不压缩。

你拿 tar 把一个 100MB 的目录打成一个包，出来的文件还是 100MB，一个字节都没省。它只是把这些东西排成一列而已，没做别的事情。

tar 文件内部的最小单位是 512 字节一块，这个数字也不是随便选的。它就是 Unix V7 文件系统磁盘扇区的大小。1979 年的一个选择，刻在所有 tar 文件的基因里，一直刻到今天。所以 tar 管的事情，就到「拼」为止。

那压缩呢？

tar 不管。

这事儿一直到 1992 年才有人接手。

那一年，两个叫 Jean-loup Gailly 和 Mark Adler 的人做了一个东西叫 gzip。Gailly 写压缩，Adler 写解压，1992 年 10 月 31 号，gzip 0.1 正式发布。

这里有个背景值得一提。在 gzip 之前，Unix 自带的压缩工具叫 compress，用的是 LZW 算法。但 LZW 被 Unisys 和 IBM 捏在手里，九十年代初开始到处收钱，开源圈被整得很紧张。gzip 就是被逼出来的替代品，用的是另一个叫 DEFLATE 的算法，完美绕开了专利地雷。

这段往事本身就够写一篇文章的，但今天我们只关心一个点。

gzip 做的事也特别简单，就一个动作，把一条字节流压缩成一条更短的字节流。

你注意到了吗？gzip 也很轴。它只认「一条流」。你不能拿 gzip 去压一个目录，它不认识目录这回事。给它一个文件，它就吐一个压缩后的文件，给它一条流，它就吐一条压缩后的流。别的事它一概不管。

tar 只打包不压缩，gzip 只压缩不打包。

两个工具，谁都不会干对方的活。

那怎么办？

中间用一根 Unix 管道粘起来。

1tar cf - mydir | gzip > mydir.tar.gz

这条命令左边 tar 把 mydir 打成一条流，用 - 表示「别写文件，直接吐到标准输出」。中间一个 |，把这条流接到 gzip 的嘴边。右边 gzip 啃完这条流，吐出一条压缩过的流，重定向到 mydir.tar.gz。

一个 | 符号，两个工具，一条流水线。

你看到的那个 .tar.gz，就是这条流水线走完之后自然掉下来的结果。它的后缀之所以是两个，是因为这个文件真的经历了两道工序。第一道叫 tar，第二道叫 gz。后缀诚实地告诉你它是谁。

这里顺便说一句 tar 后来的 -z 参数。

GNU tar 的作者们觉得每次写管道太烦，加了一个 z 参数，告诉 tar，你要压缩的时候帮我顺手调一下 gzip。这就是为什么我们今天敲 tar -xzvf 这个 z。但你要知道，是 tar 在「替你调 gzip」，不是 tar 自己会压缩。四十五年过去了，tar 本体始终没长出压缩这项能力。

这个决定非常 Unix，非常硬核。

有意思的是，几乎就在 tar 过着自己小日子的同一年代，大洋对岸的 DOS/Windows 世界走了完全不同的一条路。

1989 年，美国程序员 Phil Katz 在 DOS 上搞出 PKZIP，顺手发明了 .zip 格式。zip 跟 tar + gzip 的哲学几乎是正相反的，一个工具同时做两件事，既打包又压缩，一把梭到底。

四年之后的 1993 年，另一个年轻人进场了。俄罗斯程序员 Eugene Roshal 发布命令行 RAR，1995 年又推出图形界面版 WinRAR。RAR 是 Roshal Archive 的缩写，字面意思就是「Roshal 的归档」，一个用作者自己名字命名的格式，主打比 zip 更高的压缩率。

WinRAR 这个软件顺便还成了互联网历史上最著名的「永恒试用版」。它写着 40 天试用期，但过期后不会拦你，只会弹一个很客气的提示让你买 license，你关掉它接着用，下次再弹。这个 40 天续命了二十多年，全球无数人用了一辈子没付过钱，它也不生气。这事本身已经成了一个互联网梗。

这一路跟 Unix 那边的区别非常明显，一个软件管到底，打包压缩全包在一个 exe 里。后来 1999 年俄罗斯人 Igor Pavlov 又搞了开源的 7-Zip，自带一个 .7z 格式，压缩率再往上提一截。1996 年 Julian Seward 做的 bzip2、2009 年 Lasse Collin 做的 xz 也都先后加入了这个江湖，压缩格式的主要玩家基本就是这些人了。

但你注意到一个很好玩的分化没有。

bzip2 和 xz 这两个后来的家伙，在 Unix 世界里叫什么？.tar.bz2 和 .tar.xz。tar 先把文件拼成流，bzip2 或者 xz 接着压。换压缩工具可以，换哲学不行。Unix 那边认死一件事，打包和压缩必须是两件事，永远是两件事。

Windows 那边正相反，出了更强的算法，就把旧软件整个换掉，一个 exe 管到底。

这已经不只是格式之争了，是两个世界对「一个工具应该长成什么样」的根本分歧。

为什么 Unix 那边坚持要拆？

这就得搬出 Doug McIlroy 了。

1978 年，贝尔实验室的 McIlroy 在 Bell System Technical Journal 上写了一段后来被反复引用的话，核心就三句。

“

写程序要让它们只做一件事，并且把这件事做好。

写程序要让它们互相协作。

处理的东西最好是文本流，因为那是通用接口。

这就是后来被叫作 Unix 哲学的那一段。

但这段话最有意思的一点，不在文字本身。在于说这话的人是谁。

Doug McIlroy 不光是写这段话的人，他同时还是 Unix 管道 | 这个符号的发明者。

你品一下这个巧合。

他说「让程序互相协作」的时候，他心里想的不是什么抽象的合作，他想的就是管道。一个程序的输出，通过一根 |，无缝流进下一个程序的嘴里。小工具、单一职责、用管道粘起来，组合出任意复杂的流水线。

.tar.gz 就是这段话最直白的产物。

tar 是第一个只做一件事的小工具，gzip 是第二个只做一件事的小工具，中间那根 | 是 McIlroy 本人发明的管道。你每打一个 .tar.gz 文件，都是在重演一遍 1978 年那段话。

这就是为什么我说它是活化石。

化石这个词听起来像是死掉的东西，但 .tar.gz 不是。你今天去 GitHub 上随便点一个 C 项目的 release，下载下来的几乎永远是 .tar.gz，不是 .zip。Linux 内核、nginx、curl、redis，全都是。它不是因为惯性才活着，它是因为那套哲学在今天依然被认为是对的才活着。

所以回到开头那个问题。

为什么 .tar.gz 要两个后缀？

因为它不是一个文件，是两个工具排成的一条流水线，每个后缀对应一个工位。你看到的是这条流水线吐出来的结果。

下次你再敲 tar -xzvf some-thing.tar.gz 的时候，可以稍微多看两眼那个 z。

那个 z 不是 tar 在解压。

那是 tar 在回头喊一声 gzip，过来搭把手。

两个工具，一根管道，四十五年。

Postman 越来越臃肿了，我换了个开源的，还能让 AI 帮我写测试

Mon, 13 Apr 2026 03:56:46 +0000

Postman 我用了好几年了。

从最早的 Chrome 插件时代开始用的，那时候它还是个轻量小工具，打开就能测接口，干干净净。但最近这两年，怎么说呢，它开始「端着」了。

打开就让我登录。不登录不让用。

好不容易登录了，又弹窗让我升级 Team 版。

集合还给我存到云端去了。我就测个本地接口，你把我的请求数据往你服务器上传干嘛？

我一直忍着，直到有一天，团队里两个人同时改了同一个集合，Postman 云同步直接给合并冲突了，还没法像 Git 那样 diff 看变更。那天我就想，不行了，得换。

然后我遇到了 Bruno。

怎么形容呢，就像你一直在用一个越来越臃肿的 IDE，突然有人递给你一个 Vim，告诉你「够用了，而且是你的」。

Bruno 干了一件特别简单但特别对的事情，它把你的 API 请求存成 .bru 文件，放在你本地文件夹里。

就是普通的文本文件，打开长这样。

1meta { name: 用户登录 type: http seq: 1}post { url: {{baseUrl}}/auth/login body: json auth: none}headers { Content-Type: application/json}body:json { { "username": "{{username}}", "password": "{{password}}", "expiresInMins": 30 }}script:post-response { if (res.status === 200) { bru.setVar("authToken", res.body.accessToken); bru.setVar("userId", res.body.id); }}tests { test("登录应该返回 200", function() { expect(res.status).to.equal(200); }); test("响应中应该包含 accessToken", function() { expect(res.body.accessToken).to.be.a("string"); expect(res.body.accessToken.length).to.be.greaterThan(0); }); test("响应中应该包含用户基本信息", function() { expect(res.body.id).to.be.a("number"); expect(res.body.username).to.equal("emilys"); expect(res.body.email).to.be.a("string"); }); test("响应时间应该小于 3 秒", function() { expect(res.responseTime).to.be.lessThan(3000); });}

你看，GET 请求、Header、Body、断言，全都是纯文本。你用任何编辑器都能打开它，改完保存就行。

这玩意最不同的地方在哪？

它可以用 Git 管理。

以前团队共享 Postman 集合，那叫一个痛苦。谁改了什么不知道，版本对不对不确定，冲突了还没法 resolve。

现在用 Bruno，接口定义就是文件，扔进 Git 仓库，该 PR 就 PR，该 Code Review 就 Code Review。有人改了某个接口的 Header，diff 里看得一清二楚。

用程序员已经会的工具，解决程序员的问题。不用学新的协作方式，不用付费，不用担心数据被传到哪个云上。

Bruno 官网上有一句话我印象特别深，大意是**「我们不会同步你的任何数据到云端，甚至连登录的概念都没有。我们看不到你在 Bruno 里输入了什么，也不会用你的数据训练任何 AI 模型」。**

在这个年代，一个工具敢这么说，我觉得还是挺硬气的。

回到工具本身。说到这里，可能有朋友会想，开源 API 客户端一抓一大把，Insomnia、Hoppscotch、Thunder Client，凭什么是 Bruno？

我自己用下来，让我有「这玩意不一样」的瞬间，是发现它有 CLI。

但我说的不是「能在终端里跑测试」这种废话。Newman 也能跑，Postman 自己也有命令行。我说的是另一件事。

Bruno 的 CLI，让 Claude Code 和 Cursor 这种 AI 编程工具，第一次能真正帮你写和跑接口测试。

这话有点大，我用两件刚发生的真事讲一下。

回到 Bruno 的 CLI 本身。装它就一行，

1npm i -g @usebruno/cli

装完之后命令叫 bru，跑整个集合的测试是这样，

1bru run --env production

输出长这样。

干净、彩色、有 ✓ 和 ✗、有总耗时、有失败原因。最重要的是，这是一段普通的终端命令，输出是普通的文本。

为什么这件事重要？因为这两个特征，正好是 AI 编程 agent 工作的边界。

Claude Code、Cursor、Codex 这些工具，它们能干什么？它们能读你的代码文件，能写新的文件，能在终端里跑命令，能读命令的输出。它们不能干什么？它们不能点击 Postman 的按钮，不能在你 GUI 里输入 token，不能登录任何账号。(或者说不方便，成本高，效率低)

Postman 的核心数据存在云端、操作靠 GUI、协作靠登录，这三件事每一件都把 AI agent 挡在外面。

而 Bruno 的核心数据是 .bru 文本文件、操作靠 CLI、协作靠 Git。每一件都正好是 AI 最擅长的那种事。

抽象的说完了，说点具体的。

我前两天就让 Claude Code 帮我加了一个测试，过程是这样的。

我跟它说，「我刚加了一个搜索商品的接口，帮我在 bruno 集合里加个测试用例」。

它干了三件事，全程没问我任何问题。

第一步，读了我现有的一个 .bru 文件，就是为了搞清楚我用的格式。比如我习惯加哪些 test，断言风格是什么样的。

第二步，照着这个格式写了一个新的 06-搜索商品.bru 文件，放在我集合的根目录里。请求方法、URL、query 参数、4 条断言，全都给我加上了。

第三步，它直接执行 bru run 06-搜索商品.bru --env production，亲眼看着 4 个测试全绿，然后才回我一句「写完了，4/4 通过」。

整个过程我没碰 Bruno 的 GUI，没敲一个字符的代码，没解释什么是 .bru 格式。AI 自己读自己写自己跑自己验证。

你可能会问，这个事换成 Postman 不行吗？

我得先把话说清楚，Postman 不是没有 CLI。Newman 一直都在，Postman Collection 也是 JSON 文件，AI 理论上能读能写。这条路是通的。

但你真去试一下就会发现，那条路上全是石头。

Postman 的 Collection JSON 格式不是给人手写的。我做了个最朴素的对比，同一个 GET 请求加一条「状态码等于 200」的断言，写成 .bru 是 15 行，导出成 Postman Collection JSON 是 44 行。区别在哪？.bru 里 URL 就是一个字符串 https://api.example.com/users，Postman JSON 里 URL 被拆成 protocol、host 数组、path 数组三个字段。.bru 里测试代码就是普通 JS，Postman JSON 里测试代码以字符串数组的形式塞在 event 里，每一行 JS 都得加引号、转义、再 JSON 序列化一次。还有一堆 _postman_id、_exporter_id、schema 这种内部元数据，跟你的业务接口毫无关系，但你不写就报错。

让 AI 写 .bru，它跟写 markdown 一样轻松。让 AI 写 Postman JSON，它更像在翻译一份配置文件，token 烧得多，出错概率高，写完你自己 review 都费劲，git diff 出来三行业务变更夹在二十行格式噪音里。

所以不是 AI 不能写 Postman 的测试，是 Postman 的格式从一开始就没打算让人手写，更没打算让 AI 直接读写。它假设你有一个 GUI 在中间帮你管理这些内部细节。AI 进来之后，那个假设就有点尴尬了。

我说的还不是最炸的场景。

真正让我觉得 Bruno + AI 是 1 + 1 大于 10 的，是调试场景。

我又试了一次，让 Claude Code 帮我加一个购物车接口的测试。它写完跑了一遍，挂了。

错误信息是这样的。

 1✕ 购物车应该有 totalPrice 字段 expected undefined to be a number✕ 购物车应该有 products 数组 expected undefined to be an array
 2
 3```bash
 4
 5它猜错了字段名。这种事很正常，毕竟它没真的去看接口返回。但接下来才有意思。
 6
 7它没有问我、没有让我提供文档、也没有放弃。它自己执行了一条 curl 命令，把购物车接口的真实响应拉了下来。
 8
 9```bash
10curl -s https://dummyjson.com/carts/1

看到响应里字段是 total 和 products，不是 totalPrice 和 items。它马上把测试里的字段名改了，再跑一遍，全绿。

整个调试过程，我做了什么？我什么也没做。我只是看着它一步一步跑完。

这就是 Bruno + CLI + AI 的真正价值。你的 API 测试不再是一个孤立的、需要你手动维护的负担，而是变成了 AI 可以读、可以写、可以跑、可以调试的一种代码。

它和你的源码、你的 Git 历史、你的 CI/CD、你的 AI agent，全都是一体的。

写到这里我猜有人要拍桌子了。

「等等，国内程序员谁还用 Postman 啊？Apifox 它不香吗？」

发，我们专门聊聊 Apifox。

我必须先承认它真的很强。一体化平台，API 文档、调试、Mock、自动化测试、团队协作全在一个工具里搞定，相当于 Postman + Swagger + JMeter 三合一。界面是中文，文档是中文，国内团队几乎零学习成本。如果你的团队 20 人以上，需要权限管理、需要实时协作、需要统一的 API 文档管理，Apifox 是比 Bruno 更合适的选择。这点我不否认。

而且 Apifox 不傻，它也在跟上 AI 浪潮。它有 apifox-cli，能在终端里跑测试场景。它甚至专门做了 Apifox MCP Server，可以让 Cursor 和 Claude Desktop 读取 Apifox 项目里的 API 文档，帮你写代码。

那问题来了，Bruno 和 Apifox 在 AI 这件事上到底有啥不一样？

我读了一圈 Apifox 的官方文档，发现一个挺有意思的差别。

Apifox 接 AI 的方式，是让 AI 来连接 Apifox。Bruno 接 AI 的方式，是 Bruno 根本就是 AI 已经会读的格式。

具体说，Apifox 的 AI 工作流是这样的，你的测试数据躺在 Apifox 云端项目里，你装一个 Apifox MCP Server，配置 Cursor 去连这个 MCP，AI 通过 MCP 协议向 Apifox 服务发请求，把 API 文档拿下来，再帮你生成代码。

Bruno 的 AI 工作流是这样的，你的测试就是项目目录里的 .bru 文件，AI 直接 cat、edit、bru run。完了。

你看出区别了吗？Apifox 把 AI 当成一个外部工具来对接，所以需要 MCP 这一层中转。而 Bruno 根本不需要 MCP，因为它跟 AI 用的是同一种原生语言：文本文件加终端命令。

还有一个更现实的差别。Apifox 的 MCP Server 现在的能力，是让 AI 读取 API 文档来生成代码，它并不能让 AI 直接去编辑你的测试用例。AI 在 Apifox 这边的角色基本上是只读的。

而我前面演示的那两个场景，Claude Code 帮我写新测试、自动调试、修字段名，那是完整的读写跑改循环。AI 不光在读，还在写，还在跑，还在调试。这是因为 .bru 是普通文件，Edit 工具就能改，Bash 工具就能跑。它中间没有任何一层，所以也没有任何一层会卡住。

这不是说 Apifox 不好，是两条不同的路。Apifox 选的是「我是平台，AI 来连我」，Bruno 选的是「我什么都不是，我就是文件」。前者适合企业级场景，后者适合代码即测试的开发者工作流。

我自己是后者。我喜欢我所有的东西都能塞进 Git 仓库，喜欢 AI 直接读我硬盘上的文件，不喜欢任何账号、登录、云端中转。所以我选 Bruno。

如果你的工作场景更接近企业级 SaaS 那一套，那 Apifox 完全没问题，甚至更合适。但如果你跟我一样，希望让 AI 一句话把接口测试搞定，那 Bruno 这条路确实更顺。

聊完 Apifox 我们继续。顺便提一下 CI 集成，因为这块也很丝滑。Bruno CLI 支持输出 JUnit XML，GitHub Actions、GitLab CI、Jenkins 直接吃这个格式。我的工作流文件大概长这样。

1- name: 安装 Bruno CLI run: npm install -g @usebruno/cli- name: 跑接口测试 run: bru run --env production --reporter-junit junit.xml

两步。你的 PR 一提交，所有接口测试自动跑一遍，挂了直接拒绝合并。

生成的测试执行也挺好看的

整套东西免费、开源、本地、Git 友好、AI 友好，不用登录、不用付钱、不用担心数据上云。

安装很简单。桌面版，

1brew install bruno
2
3```bash
4
5CLI，
6
7```bash
8npm i -g @usebruno/cli

用了一周之后我把 Postman 卸了。

不是它不好，是我不再需要一个登录才能用、集合存在别人云上、免费版各种限制、AI 完全帮不上忙的接口测试工具了。

我只需要一个文件夹、几个 .bru 文件、一条终端命令，和一个能读懂这一切的 AI。

有时候工具的进步不是功能越加越多，而是把不该有的东西去掉。Bruno 去掉了登录、去掉了云端、去掉了 GUI 锁定，剩下的全是程序员真正需要的东西。

而当你把这些不需要的东西去掉之后，你会发现一个意外的副作用，AI 进来了。

好了就说这么多。

如果你也受够了 Postman，试试 Bruno。说不定你也会像我一样，用完就回不去了。

ps:我写的 demo 在这里，你可以拉下来试一下，可以 run 的：https://github.com/xiaobox/bruno-demo

我用两句中文，让 Claude Code 帮我画了10张出版级技术图

Sun, 12 Apr 2026 08:38:12 +0000

前两天在写一篇技术文章，写到一半需要配一张微服务架构图。我打开了某在线画图工具，对着空白画布发了十分钟的呆，拖了两个方块，连了一条线，觉得丑，删掉，再拖两个方块。

半小时过去了，图还没画完，文章的灵感已经凉透了。

我相信很多搞技术内容的朋友都有过这种体验。你脑子里其实很清楚这张图应该长什么样，但你就是得花一两个小时在画图工具里对齐、配色、调字号。明明内容才是核心，结果时间全花在了排版上。

然后我发现了一个东西，彻底解决了这个问题。

它叫 fireworks-tech-graph，是一个 Claude Code 的 skill。装上之后，你跟 Claude Code 说一句中文，它就能给你吐出一张出版级别的技术图。SVG 矢量源文件加 1920px 高清 PNG，直接能往文章里塞。

我用它画了10张不同类型的图，从架构图到 ER 图到状态机，从白底极简到暗色霓虹到工程蓝图。每张图从下指令到拿到成品 PNG，平均不超过30秒。

30秒。

我之前在画图工具里对齐一个箭头的时间都不止30秒。

怎么装呢，你甚至不需要记任何命令。

打开 Claude Code，直接跟它说「帮我安装 fireworks-tech-graph 这个 skill」，它自己就把活干了。装完之后你说「画一个 xxx 图」，它就自动触发。

如果你喜欢手动装也行，就一句 claude skills install fireworks-tech-graph，完事。

触发词非常宽泛，「画图」「帮我画」「做个架构图」「生成一个流程图」「可视化一下」，随便怎么说都行，它都能识别。

它能画什么？

这个 skill 支持10种有模板的图表类型，外加4种无模板但有规则定义的类型。我挑几个最实用的说一下。

1，架构图。这是用得最多的，画微服务分层、系统组件关系。你告诉它有哪些服务、怎么分层、哪些组件之间有调用关系，它自动帮你排好。我画的那张微服务架构图有5层，右侧还挂了一个观测性旁路，出来的效果跟正经架构文档里的图一模一样。

2，流程图。CI/CD 流水线、审批流、业务决策流。菱形判断节点、圆角矩形处理步骤、失败回环，全都有。你只需要描述「从提交代码到部署生产」中间经过哪些步骤和判断就行。

3，时序图。微服务之间谁先调谁，消息怎么传递。标准的 UML 时序图，有生命线、激活框、alt 分组框。你列出参与者和消息序列，它帮你排好。

4，ER 图。数据库表之间的关系。支持鸦脚记法，PK 自动下划线，FK 标注。你把实体和属性列出来，告诉它哪些是一对多、哪些是多对多，它画出来的东西可以直接放进数据库设计文档。

5，状态机。订单生命周期、工单状态流转这种。每个状态是一个圆角矩形，转换线上标事件名，有初始态的实心圆和终态的同心圆。

6，对比矩阵。横评几个模型、几个方案的时候特别好使。我画了一张 LLM 模型对比表，5个模型7个维度，绿色打勾红色打叉，交替行填充，出来就是一张可以直接发朋友圈的表。

7，时间线。项目路线图、版本规划。甘特图样式，彩色横条加菱形里程碑。

除了这些，还有 Agent 架构图、用例图、数据流图。反正你在技术写作里能用到的图，它基本都覆盖了。

比较骚的是它有7种视觉风格，每种味道完全不一样。

默认的 Flat Icon 是白底彩色，适合博客和文档。Dark Terminal 是暗色霓虹风，发 GitHub 和技术社区特别帅。Blueprint 是工程蓝图风，深蓝色背景加网格线加角标，那种 CAD 图纸的感觉。Notion Clean 是极简白，一根线一个色。Glassmorphism 是毛玻璃卡片，适合产品官网和 Keynote。最近还加了 Claude Official 和 OpenAI Official 两种风格，分别是 Anthropic 和 OpenAI 的品牌调性。

你指定风格的方式就是在 prompt 里加一句「用蓝图风」或者「Style 3」，就这么简单。

我觉得这个 skill 最打动我的点，不是它画得多漂亮，而是它把「画图」这件事的心理门槛降到了零。以前我写文章需要配图的时候，经常会想「算了这里用文字描述一下也行吧」，因为打开画图工具、画完、导出、插入这一套流程太重了。现在不一样了，我在 Claude Code 里写着文章，写到需要配图的地方，直接说一句「帮我画一个 xxx」，30秒后图就在本地了。

这种体验就像是，你本来在用文本编辑器写代码，突然有人给你装了一个实时预览插件。功能上没变，但那个「随时能看到效果」的即时反馈感，会让你更愿意去做这件事。

画图也是一样。当成本足够低的时候，你会发现你开始「想画就画」了。

想试的朋友，打开 Claude Code，说一句「帮我安装 fireworks-tech-graph」，等它装完，再说一句「画一个 xxx 图」。

就这么简单。两句话的事。

下面附一些 demo 图：

让Agent快上100倍的秘密，其实藏在一本大一计算机教科书里

Sat, 11 Apr 2026 10:50:21 +0000

事情是这样的。

最近我几乎每天都在用Claude Code写东西。用得越多，我越产生一种奇怪的感觉。

就是你给它下完一个任务之后，它开始一步一步地干活。先是啪，读了一个文件。然后哒，想了几秒。然后啪，又打开一个文件。再想几秒。再打开一个文件。就这么一直持续下去。

你坐在椅子上看着进度条一格一格地亮起来，心里清楚得不能再清楚，这十个文件它明明可以一起读的，它们之间根本没有任何依赖关系。

但它就是不。它就是要一个接一个地来。

一时间无语凝噎。

后来我跟几个同样重度用Agent的朋友聊了一下，他们也都有这个感受。说真的我始终觉得这是现在所有Agent产品共同的一个病，不管是 Claude Code、Cursor、Manus还是那些MCP插件，只要你让它干稍微复杂一点的活，你就会看到它在那里慢悠悠地一步一步走，像一个做事非常有耐心但完全不会一心二用的老实人。

前两天跟朋友吐槽这事的时候，我又想起了两年前Berkeley那帮人写的一篇论文。论文叫LLMCompiler，2024年就发在ICML上了，现在回头看它也不算新东西。但每次我被Agent气到的时候都会想起它，觉得它的思路到今天都没过时，甚至越品越有味道。

它当时就已经把这个病的根源讲得很清楚了，这个慢不是LLM的错，也不是任务复杂度的错，是我们给它用的那套调度系统，还停留在1960年代的水平。

这篇论文的名字挺干的，叫**《An LLM Compiler for Parallel Function Calling》**，ICML 2024。作者是Sehoon Kim、Amir Gholami那帮人，都在Berkeley和LBNL。它不是今年的新论文，但在我心里一直是Agent方向上最被低估的几篇之一。

它在做的事其实非常cool。

它在把大学一年级《计算机组成原理》那本书里的东西，原样搬到LLM的世界里。

坦率的讲，你想想看过去60年整个计算机体系结构的历史，其实就是一部「怎么让本来是串行的指令跑得更并行」的历史。指令流水线、乱序执行、超标量、分支预测，这些听着就头大的名词，说到底都是在干一件事，就是让CPU不要一条指令一条指令傻乎乎地等，能同时干的活就一起干。

这套东西人类已经研究得非常透了。透到什么程度呢？透到你今天买一颗普通的i5芯片，它每个时钟周期能同时发射的指令数，大概是80年代那种整栋楼的超级计算机的水平。

但是。

当我们把LLM当成一种新型处理器去用的时候，这套智慧全忘了。

现在几乎所有的Agent框架，底层都是一个叫ReAct的东西。它是Yao等人2022年提的，全称是Reason + Act。工作方式非常朴素，想一步，做一步，看结果，再想一步，再做一步，再看结果。它是一个循环。

听着很自然对吧？它确实自然。但你仔细看就会发现，这玩意从执行效率上来说，跟那种每次只能执行一条指令、做完一条才开始下一条的远古处理器，是一样的。

一次一条。干等。

而且这个问题在越来越多的Agent场景里暴露得越来越厉害，因为我们现在给Agent的活越来越复杂，一次要调用的工具越来越多。ReAct的串行执行就成了一个越来越重的镣铐。

回到LLMCompiler这块。

作者的思路简单粗暴，既然Agent执行工具调用的过程跟CPU执行指令长得一样，那就直接套编译器的架构好了。他们搞了三个组件。

第一个叫 Function Calling Planner，函数调用规划器。你可以把它想象成编译器里那个分析语义、构建依赖图的部分。用户给了一个问题，比如论文里举的那个例子，「微软的市值需要涨多少才能超过苹果？」，Planner要做的事情是先把这个问题拆成几个独立的任务，再搞清楚这些任务之间谁依赖谁。

它会拆成三步。

一，去查微软的市值。二，去查苹果的市值。三，用一个数学工具做减法，把差值算出来。

然后它会发现一件事，任务1和任务2，彼此没有任何关系。它们完全可以同时去查。只有任务3需要等前两个都拿到结果。

这就是一张 DAG，有向无环图，编译器里最核心的数据结构之一。

第二个组件叫 Task Fetching Unit，任务获取单元。这个名字直接就是从CPU里偷来的。

在现代CPU里有一个东西叫指令获取单元，它的任务是一旦前一条指令把某个寄存器的值算出来了，立刻把依赖这个寄存器的下一条指令发射出去，别等一整串指令都准备好再开搞，那样太慢。

LLMCompiler的Task Fetching Unit做的事完全一样。Planner一吐出DAG，它就开始扫描，发现哪些任务的依赖已经解决了，立刻往下扔。任务1和任务2没有依赖？好，同时发射，两个搜索并行执行。任务3等着1和2的结果？好，等它们回来我再把结果塞进任务3里，然后发射。

整个过程是流式的。Planner一边在吐计划，执行器一边在干活，中间没有「等Planner把所有计划全想完再开始」这种停顿。论文里专门做了个消融实验，流式处理本身就贡献了一个量级的加速。

第三个组件叫 Executor，执行器。这个没啥好说的，它就是真正去调工具的那个家伙。Task Fetching Unit告诉它哪个工具可以调了，它就调。

三个东西加起来，整个架构就跟一台小号的CPU一模一样。有人分析程序，有人调度，有人执行。

说到这我真的有点被打动。你知道我为啥被打动吗？因为这个思路其实任何一个学过编译原理的本科生都能想到。它没有任何复杂的数学，没有什么神秘的训练技巧，就是把一个用了60年的老配方，拿来炒一道新菜。

但它偏偏有效。而且效果好到离谱。

顺着上面的再聊聊，这篇论文最让我兴奋的其实是实验结果部分。

作者用了四个benchmark来测试LLMCompiler。这四个测试排起来有一个隐藏的升番结构，从最简单的场景到最复杂的场景，效果一个比一个炸。我逐个说一下。

第一个叫HotpotQA。这是个很经典的多跳问答数据集，论文的Figure 1就举了一个例子，「斯科特·德瑞克森和埃德·伍德是不是同一个国籍？」这种问题。用ReAct的话就是一步一步来，先搜A，拿到结果，再搜B，拿到结果，再对比。用LLMCompiler的话，A和B可以同时搜。

速度快了1.8倍。成本降了3.37倍。准确率基本一样。

就这个结果拎出来看已经很能打了，但它只是开胃菜。

第二个叫Movie Recommendation。这个更有意思，它每次要你从8部电影里找出跟某部电影最像的那部。也就是要对8部电影分别做独立的搜索和分析。

ReAct在这里干了一件特别傻的事。论文附录里有一张图我看完直接笑出声，它显示有大约85%的样本，ReAct根本没搜完8部就结束了。它搜到第五部就停下来，觉得「我好像够了」，然后给一个答案。

你敢信？？？

一个号称能干活的Agent，居然连把活干完都做不到。它会提前认输。

LLMCompiler在这里就完全没这个问题，因为Planner一开始就把8个任务全部规划好了，Executor必须全部执行完才能汇总。结果是速度快了3.74倍，成本降了6.73倍，准确率还反超ReAct 7个多点。

第三个叫Game of 24。这游戏你们可能玩过，给你4个数字让你用加减乘除搞出24。之前最强的解法叫Tree-of-Thoughts，让LLM自己去搜索各种可能的组合。LLMCompiler在这里做了一个很骚的事，它把「Tree-of-Thoughts的一次尝试」当成一个工具，然后让Planner去并行调度这些尝试。

速度快了2倍。

到这里我已经觉得够牛了。

但是真正让我给整不会的是第四个benchmark，WebShop。这是一个模拟网上购物的环境，你要在一堆商品里找到符合某些需求的那一个。典型的操作是搜索→看结果→再搜索→再看结果。

LLMCompiler在这里直接跑出了101.7倍的加速。

不是10倍，不是50倍，是一百零一点七倍。

而且成功率还比ReAct高了25.7个百分点。

我第一次看到这个数字的时候真的愣住了。我来回看了好几遍论文的表格，生怕自己看错了小数点。101.7x。

它的原因其实非常直观。WebShop里有大量「先广撒网再选最优」的搜索动作。LLMCompiler可以一口气把所有候选搜索并行发射出去，而ReAct得一个一个搜。你想想，如果你在淘宝上找一个东西，你是一次打开十几个标签页横向对比，还是一个一个点开再返回再点开？

答案很明显。

但前者需要你有一个「规划」的能力，得先知道哪十几个是值得看的。这恰好就是LLMCompiler在做的事。

这块需要注意一下。LLMCompiler的意义不只是快，还有一个更深的点，它顺手救了准确率。

这个我刚才提到了一嘴，但值得展开说说。作者分析了ReAct失败的案例之后发现，这些失败的绝大多数其实跟智力无关，跟纪律有关。

两种典型的失败场景。一种是提前收工，它只搜了部分信息就觉得够了，开始瞎答。另一种更惨，是它会在同一个查询上无限循环，因为Wikipedia返回的信息不够精确，它就一直搜一直搜一直搜，直到context window爆掉。

这两种失败加起来，贡献了ReAct绝大部分的失败样本。

为啥会这样？我自己的理解是，ReAct是一种即兴架构。它没有全局视野，每一步都是基于上一步的观察临时决策的。这种即兴决策模式很像我们人脑，但它也天然带着人脑即兴决策的毛病，容易累、容易放弃、容易走进死胡同。

LLMCompiler强迫模型在一开始就把所有要做的事列出来，这等于逼着它做一次系统性的规划。规划好了之后，执行阶段就只负责执行，不再思考。

我觉得这里有一个非常深的启发。我们过去几年一直在迷信让LLM多想一步，搞出了Chain-of-Thought、Tree-of-Thoughts、Self-Reflection各种花活，都是在鼓励模型「思考得更细、更久、更多」。但其实有时候反过来，让它先想一次然后别再想了，反而更管用。

CPU的设计哲学其实也是这样。现代CPU里最快的指令是那些不需要跳转、不需要预测、不需要动态决策的指令。凡是涉及到走一步看一步的指令，都会拖慢整条流水线。

计算机硬件的人早就发现了，即兴决策是昂贵的。

而这个老道理，现在又回到了AI Agent这边。

坦率的讲，我觉得LLMCompiler这篇论文本身可能不是最大的新闻。真正的新闻是它揭示的那个更大的趋势。

我们正在把整个计算机体系结构，重新发明一遍。

你仔细想想这几年LLM推理和Agent方向上那些最亮眼的突破，几乎每一个都能在老教科书里找到原型。

Speculative decoding，是把CPU的分支预测搬到了LLM推理。 KV cache，是把CPU的cache机制搬到了LLM推理。 Continuous batching，是把操作系统的进程调度搬到了LLM推理。现在LLMCompiler，是把编译器的指令调度搬到了LLM Agent。

每一个都在发生。每一个都带来10倍甚至100倍的加速。每一个的核心创意都不是横空出世的神来之笔，而是一句「等等，这个问题我们在硬件/OS层面已经解决过了，直接拿来用就好」。

卡帕西前阵子说过一句我记了很久的话，他说LLM是一种新的计算机，一种以自然语言为指令集的计算机。这句话如果你真的认真对待，那它的所有推论都是自洽的。既然它是一种新的计算机，那我们给旧计算机发明的所有优化技巧，理论上都应该能再用一次。

我有时候会觉得，我们这一代做AI的人特别幸运。我们在亲眼看一部已经拍过一遍的电影，被用新的道具重新拍摄。剧本是一样的，角色是一样的，剧情走向都是一样的。但因为道具全换了，看起来就像一部全新的片子。而且你手里只要有一本原版的剧本，你就能提前知道下一幕会发生什么。

回到这篇论文本身。

我觉得它最重要的贡献其实不是那些benchmark数字，而是它开了一个非常清晰的方向。那就是Agent的慢不是不可解决的。

你今天用Claude Code等十分钟，不是因为LLM笨，也不是因为你的任务太复杂。是因为底下那套调度系统还在用ReAct这种20世纪60年代级别的执行模式。只要换上哪怕一个粗糙的编译器思路，立刻就能快10倍、快100倍。

其实这两年已经有不少框架在往这个方向走了，LangGraph、LlamaIndex都陆陆续续搞过类似的planner组件，多Agent框架里的并发调度也都能看到这套思路的影子。但奇怪的是，我们日常在用的那些最主流的Agent产品，Claude Code、Cursor这些，还是没有把这套东西吃得特别透。你还是经常能看到它们在那里一步一步串行地跑，跑得你抓狂。

我始终觉得这是一件很可惜的事。一个两年前就该被充分吸收的好思路，到今天还只在部分框架里存在，绝大多数用户还是在吃ReAct的苦。

其实之前OpenAI做过一个简化版，它叫Parallel Function Calling。但这篇论文里也明确对比了，OpenAI那个只能处理最简单的、完全独立的并行任务，一碰到有依赖关系的就歇菜了。LLMCompiler能处理有依赖的完整DAG，这是质变。而且论文在ParallelQA这个他们自己造的benchmark上，直接把OpenAI的并行函数调用给干穿了。

还有一个让我很开心的点，LLMCompiler不依赖特定模型。它能跑在闭源的GPT系列上，也能跑在开源的LLaMA-2 70B上，效果都很好。这意味着你要用它，不需要求爷爷告奶奶去办一个特殊API，自己拿个开源模型搭一套就能跑。对整个开源生态是实实在在的利好。

论文的代码早就开源在 https://github.com/SqueezeAILab/LLMCompiler ，这两年我零零散散跑过一些例子，整体感觉是它确实好使，但对Planner的prompt质量非常敏感，稍微写粗糙一点就容易崩。这大概也是为啥它没在主流产品里全面铺开的原因之一，论文里优雅的架构，落到工程上总会多出一堆脏活。

最后说点题外话。

我一直觉得AI这个行业最迷人的地方，就在于它需要你是一个杂食动物。你得懂一点机器学习，懂一点系统，懂一点产品，懂一点用户。因为AI正在跟所有领域发生化学反应，任何一个你以为已经过时的角落，都可能突然长出一个全新的方向。

LLMCompiler这篇论文就是一个典型的例子。它既不需要你是最顶尖的ML研究员，也不需要你是最强的系统工程师。它需要你有一个能从「我的LLM Agent跑得好慢啊」跳到「诶等等，CPU当年也有这个问题，是怎么解决的来着？」的跨界联想能力。

我始终觉得这种联想能力，比任何单一领域的深度都重要。

很多朋友问我怎么跟上AI的发展。我有时候觉得，与其拼命去看最新的模型发布，不如回头去翻翻那些老的、经典的、看起来跟AI毫无关系的书。编译原理、操作系统、计算机网络、数据库系统、图形学。这些书里有太多你以为已经过时的东西，在LLM时代突然又活了过来。

你读过的每一本旧书，都可能在未来某天变成一枚重新上膛的子弹。

前提是你得先把枪挂在墙上。

以上。

干货 | 轻量级驾驭工程：AI Coding Workflow 最佳落地实践

Mon, 30 Mar 2026 11:58:33 +0000

导读：在 AI 辅助编程普及的今天，你的团队是怎么写代码的？是靠开发者随心所欲的“自然对话”，还是有严谨的工作流约束？本文将为你详细拆解“轻量 Harness 化 AI 研发工作流”的设计思路、工具选型与落地路径。无论你是独立开发者还是研发团队负责人，这套直接可抄作业的 Workflow 都不容错过。

一、 AI 编程的“向左走向右走”

当前 AI 编程的实践，大致演化出了两条截然不同的路径：Vibe Coding 与 规范驱动开发 (SDD)。

维度	🎨 Vibe Coding (直觉编程)	📐 规范驱动开发 (SDD)
核心理念	自由交互，强调开发者与 AI 的自然对话	规范先行，以 Spec 为唯一事实来源
适用场景	快速原型、概念验证、探索性开发	生产环境、复杂系统、高质量要求
侧重点	提示词 (Prompt) 工程的灵活性	规范的严谨性与完整性

⚠️ Vibe Coding 的隐患：

随着大模型能力的增强，Vibe Coding 搭配插件确实能快速出活。但在团队级实践中，它暴露出 4 个致命问题：

1.效果不可控：不同模型、不同 Prompt 风格的产出质量参差不齐。

2.幻觉难约束：缺乏结构化约束，强如顶尖模型也会“胡编乱造”。

3.技术债隐蔽：表面跑通了，底层可能埋下了架构和质量的“雷”。

4.协作难统一：个人习惯各异，大规模协作时极易失控。

正是为了系统性解决这些痛点，SDD (Spec-Driven Development) 应运而生。

二、什么是 SDD？它为什么重要？

💡 核心理念： 在 SDD 中，规范（而非代码）才是唯一的事实来源。开发者编写严谨的自然语言规范，由 AI 自动生成、测试并维护代码。参考阅读：GitHub Spec-Driven Development

采用 SDD，意味着研发范式的三大转变：

○🔄 权力反转：过去是“需求文档服务于代码”（代码写完文档就废了）；现在是“代码服务于规范”（代码只是规范的衍生品）。

○🛤️ 工作流重塑：修 Bug 或加功能，不再直接改代码，而是先更新规范，再让 AI 重新生成代码。

○🛡️ 两道防线约束质量：

▫模板约束：强制 AI 聚焦业务逻辑。遇到模糊需求必须提问（[需要澄清]），杜绝瞎猜。

▫架构宪法：设定硬规则（如：必须先写测试并确认失败，才能写业务代码；强制模块化等）。

🎯 终极价值：消除需求与实现之间的鸿沟，让程序员从“敲代码的打工人”进化为“定义系统意图的架构师”。

三、击中痛点：告别“实现漂移”

主流 AI 工作流为何纷纷拥抱 SDD？因为它解决了一个核心顽疾——实现漂移 (Implementation Drift)。

在随意的 Vibe Coding 中，代码层的知识无法被提取和固化。AI Agent 就像一个失忆的工人，缺乏上层显性知识和关键上下文，导致：

○效率低下：每次开发都要让 AI 重新从底层啃代码，无法高层建瓴。

○知识断层：编程规范、技术约束无法沉淀。

○协作困难 & 质量崩塌：Bug 和技术债越滚越大。

四、主流 SDD 工作流大比拼

社区中已涌现出众多优秀的 SDD 实践方案，我们进行了深度体验对比：

工作流	定位与特色	GitHub 仓库	实践痛点
Spec-Kit	官方工具链，全链路 (constitution/spec/plan/tasks/implement) 完整	github/spec-kit	流程重、Token 消耗大、耗时长、维护成本高
OpenSpec	轻量级 SDD 实现，更灵活	Fission-AI/OpenSpec	需人为设计流程，上手门槛较高
GSD	强调 fresh context 和 map-codebase 的分阶段框架	gsd-build/get-shit-done	棕地项目知识总结极佳，但完整流程耗时长
superpowers	Skills 驱动，强调 brainstorming, TDD 和 review	obra/superpowers	亮点突出，但整体流程中部分步骤相对薄弱
compound engineering	闭环流程 (Brainstorm→Plan→Work→Review→Compound)	EveryInc/compound-engineering-plugin	流程合理，但对棕地项目的存量知识沉淀不足

结论： 在生产环境中，我们需要平衡开发效率、代码质量和 Token 成本。目前没有任何单一工作流能完美兼顾，强行绑定只会让开发体验打折。

五、破局策略：组合最优解（缝合怪战术）

基于上述痛点，我们的落地策略是：取各家之长，组合使用。

○阶段一（当下）：做“缝合怪”。串联 GSD + compound engineering + superpowers 的最佳环节，先跑通验证。

○阶段二（未来）：逐步过渡到自研工作流，形成完全契合团队基因的 AI 编程链路。

🛠️ 工具选用原则与雷达图：

流程环节	选用工具	选用理由（最佳平衡点）
🔍 Codebase 分析	GSD `/gsd:map-codebase`	对棕地项目（遗留系统）分析最全面完整
🧠 Brainstorm	CE `/ce:brainstorm`	探索速度与效果的最优平衡
📝 Plan	CE `/ce:plan`	兼具效率和生成质量，Token 消耗合理
💻 Work	Claude Code / Codex	无需特殊指令，明确方案下 AI Agent 自主能力已足够
👀 Review	superpowers (自然语言)	综合表现最佳：不慢、不冗长、反馈极具价值
📈 Compound	GSD `/gsd:map-codebase`	支持增量更新，自动识别并沉淀项目变化

(注：CE 为 compound engineering 的简称)

六、终极实战：六步法完整工作流

综合打磨后，我们得出了这套黄金六步法。它与 Compound Engineering 的流程高度重合（因其设计合理），但我们补齐了 Codebase 环节，并替换了部分步骤的具体实现。

👣 Step 1: Codebase (建立项目认知)

○执行方式：运行 GSD 的 /gsd:map-codebase。

○作用：并行拉起多个代理，全面提取架构文档、规范、外部集成、技术栈、风险点。为后续开发提供关键上下文。

👣 Step 2: Brainstorm / Research (技术方案探索)

○执行方式：运行 /ce:brainstorm。

○作用：结合项目现状探索可行性方案，效率与效果极佳。

👣 Step 3: Plan (制定开发计划)

○执行方式：运行 /ce:plan。

○作用：总结探索成果，输出高质低耗的开发计划。

👣 Step 4: Work (执行开发)

○执行方式：直接对话使用 Claude Code 或 Codex。

○作用：为什么不加约束？因为前置方案已明确，放开手脚让 AI 自主调用工具和子代理，反而能最大化效率。

👣 Step 5: Review (代码审查)

○执行方式：通过自然语言触发 superpowers，例如：

“用 superpowers 对最新的一次 commit 进行 code review”

○作用：提供速度适中、精炼且极具价值的代码质量反馈。

👣 Step 6: Compound (知识复利)

○执行方式：再次运行 /gsd:map-codebase。

○作用：沉淀显性知识（业务逻辑、技术决策等）。支持增量识别，无需每次代码变更都执行。建议执行时机：Feature 完成时、做出重要技术决策时、架构显著变化时。

七、灵活适配：按场景“裁剪”流程

全套流程虽好，但没必要杀鸡用牛刀。团队可根据任务粒度自由裁剪：

○🚀 完整 Feature 开发 (工作量大)：Codebase → Brainstorm → Plan → Work → Review → Compound

○🏃 中等粒度任务 (方案清晰)：Codebase → Work → Review → Compound

○🔧 小型修复/调整 (日常 Bug)：Codebase → Work → Review

○🩹 快速修补 (十万火急)：Codebase → Work

⚠️ 避坑指南： 即使使用短流程，也要记得定期执行 Compound (/gsd:map-codebase) 沉淀知识，防止“实现漂移”死灰复燃！

八、建立知识沉淀体系（动静分离策略）

通过上述 Workflow，项目会自然沉淀出两类核心资产，我们称之为动静分离：

1.🔄 Codebase 文档 (动态，全队共享)

由 /gsd:map-codebase 自动刷新，包含项目结构、模块关系、依赖分析。它是 AI Agent 的“实时地图”。

2.📌 CLAUDE.md / AGENTS.md (静态，手动维护)

用于兼容不同 AI 工具的内容一致性文件。主要记录开发规范、技术约束、业务规则和“绝对禁区”。不频繁变更。

(除这两者外，其他过程文档在开发结束后可直接删除或归档。)

九、驾驭工程的核心：上下文工程

有工具还不够，AI 编程的终极壁垒是：将隐性知识转化为显性知识。

不要指望 AI 自己去翻代码找表结构，这不仅慢而且容易错。我们需要主动投喂“AI 友好的知识形态”（Context Engineering）。

✅ AI 喜欢的格式：

○.md Markdown 文件 (如 PRD 文档)

○.sql 数据库脚本 / 表结构导出

○结构化的 Schema / JSON / YAML (如 UI 交互描述)

○CLI 命令行工具 / Bash 脚本

❌ AI 讨厌的格式：

○Word、Excel、PPT 等非结构化办公文档。

落地建议： 团队需建立规范，确保业务规则、设计图和数据结构在进入工作流前，已被转化为上述机读友好的格式。这是划定 AI 操作边界、消除幻觉的关键。

🛠️ 附录：工具链安装避坑指南

为了方便大家上手，我们整理了三大工具的安装差异。整体结论：建议统一使用 Claude Code 执行工作流，支持度最好。

工具	Claude Code 安装姿势	Codex 安装姿势	差异与踩坑点
GSD	`npx get-shit-done-cc --claude --global` (或 `--local`)	`npx get-shit-done-cc --codex --global` (或 `--local`)	同一个 installer，Codex 侧是 skills-first，最省事。
superpowers	`/plugin install superpowers@claude-plugins-official`	需 clone 仓库 + 建立 symlink 到 Codex skills 目录。详见 Codex 官方文档	明显 Claude-first，Codex 需要繁琐的手工安装。
compound-engineering	先 `/plugin marketplace add EveryInc/compound-engineering-plugin`
再 `/plugin install compound-engineering`	`bunx @every-env/compound-plugin install compound-engineering --to codex`	Claude 是原生插件；Codex 是转换安装（且官方标明为 experimental）。

🔗 传送门：

○GSD: https://github.com/gsd-build/get-shit-done

○superpowers: https://github.com/obra/superpowers

○compound-engineering: https://github.com/EveryInc/compound-engineering-plugin

比 SDD 更轻、比 Vibe Coding 更稳：最近很火的 Compound Engineering，到底是什么？

Sat, 14 Mar 2026 23:30:00 +0000

比 SDD 更轻、比 Vibe Coding 更稳：最近很火的 Compound Engineering，到底是什么？

这两年，AI 编程圈越来越像在两个极端之间摇摆：一边是“想到什么就让 AI 直接写”的 Vibe Coding，速度很快，但经常越写越乱；另一边是像 SDD 这样的重流程方法，先写规格、再做计划、再拆任务，明显更稳，但对很多日常迭代来说又有点重。也正是在这个背景下，Every 提出的 Compound Engineering 开始被越来越多人讨论。

Every 对它的定义非常明确：它不是一次性的“让 AI 帮你写代码”，而是一套循环式工作法——Plan → Work → Review → Compound → Repeat。Every 特别强调，前面三步很多工程师都熟悉，真正把它和传统开发区分开的，是第四步 Compound：把这次工作的经验、规则和模式沉淀下来，让下一轮更容易、更稳定。

我更愿意把 Compound Engineering 翻成 复利式工程。因为它想表达的重点，不是“复合”，而是“复利”：今天做完一个需求，不只是产出一段代码，而是顺手把这次有效的方法、踩过的坑、适合你代码库的规则一起沉淀下来。

如果跳过 Compound 这一步，你做的其实还是“带 AI 辅助的传统开发”；只有把经验真正回写到系统里，收益才会不断累积。复利式工程里，80% 的时间应该花在 Plan 和 Review 上，真正写代码和沉淀反而只占 20%。这背后的逻辑很简单：AI 写代码越来越快，开发者真正稀缺的能力，不再是手敲速度，而是规划质量和复盘能力。

那它和 SDD 的区别到底在哪？

SDD 的核心是“先把需求和边界说清楚”，复利式工程的核心是“让每一轮开发都为下一轮积累资产”。

GitHub 在介绍 Spec Kit 时，把 SDD 定义成一种“让 spec 成为工程中心”的方法：不是先写代码、后补文档，而是先写 spec，把它作为共享真相，再由 spec 驱动计划、任务拆解、实现与验证。整个过程是分阶段推进的，而且每一阶段没验证完，不进入下一阶段。这意味着 SDD 更像一套规格驱动的工程方法，而 Compound Engineering 更像一套强调循环、反馈和经验复利的工作法。前者更适合高不确定性的大功能、多人协作和正式项目；后者更适合持续迭代、日常开发、频繁修复和长期演进。

换句话说，SDD 更像“先把地图画清楚再出发”，而 Compound Engineering 更像“每走完一段路，都顺手把路修得更好”。这也是为什么很多人会觉得 SDD “更专业”：因为它天然更正式、更有边界、更适合把复杂需求讲清楚；但复利式工程并不是不专业，它只是没把重心放在“写出一份完整规格”上，而是放在“形成稳定循环，并持续让系统学会更多东西”上。

它的推荐流程是 Brainstorm → Plan → Work → Review → Compound → Repeat，并为每一步提供了对应命令，比如

●/ce:brainstorm 用来澄清需求和方案

●/ce:plan 用来形成实施计划

●/ce:work 执行代码改动

●/ce:review 做多代理审查

●/ce:compound 记录经验，让未来的工作更容易。

如果你想试一试，它的上手门槛其实不高。Every 的官方插件可以直接安装到 Claude Code；仓库同时还提供了转换安装方式，能把这套插件能力转换到 Codex、Copilot、Gemini、OpenClaw、Windsurf 等环境中。实际使用时，我建议不要把它理解成“又一个新框架”，而要把它理解成一种固定节奏：

●先 brainstorm，把问题和方案空间摸清；

●再 plan，把变更范围、文件、约束和验证方式写明白；

●接着 work，让 AI 按计划执行；

●然后 review，审查结果和遗漏；

●最后 compound，把这轮真正有效的经验写回规则、命令、技能或文档里

这样做的价值不在于某一次写得多快，而在于代码库会越来越顺手，AI 也会越来越“懂你”

优缺点

它的优点很明显。

1.第一，它比纯聊天式 AI 编码稳得多，因为它强制加入了计划和复盘。

2.第二，它又比完整 SDD 轻，尤其适合中小功能、日常修复和产品迭代。

3.第三，它最有价值的地方是“积累性”：不是每次都从零开始，而是让经验沉淀下来，形成真正的团队资产。

缺点也同样清楚：如果团队没有 review 习惯，或者总是赶时间跳过 compound，那它很快就会退化成“稍微有点流程的 Vibe Coding”；另外，它虽然比 SDD 轻，但对开发者判断力要求并不低，因为你得知道哪些经验值得固化，哪些只是一次性的临时解法。

所以，我的结论其实很简单：不要把 Compound Engineering 和 SDD 看成非此即彼。真正成熟的做法，往往是两者结合。

●大需求、新模块、多人协作，用 SDD 先把规格立住；

●小步迭代、连续修复、长期产品打磨，用复利式工程把循环跑顺。

前者解决“起点要正确”，后者解决“每一步都越来越顺”。在 AI 编程越来越强的时代，真正拉开差距的，恐怕不再是谁能让模型多写几百行代码，而是谁能把一次次零散输出，组织成一个会持续增值的工程系统

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

Sat, 14 Mar 2026 04:58:37 +0000

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

本文翻译自：https://www.nytimes.com/2026/03/12/magazine/ai-coding-programming-jobs-claude-chatgpt.html

最近，Manu Ebert 一直在想办法，别让自己的 AI 把自己“搞得很丢人”。

我前不久去拜访了 Ebert。他是一位机器学习工程师，曾经还是神经科学家。如今，他和 Conor Brennan-Burke 一起经营一家创业公司 Hyperspell，办公地点就在他们住处的一间空公寓里。39 岁的 Ebert 个子很高，留着短胡子，气质很像欧洲学者。他坐在一台巨大的曲面显示器前，屏幕上，Anthropic 的 Claude Code 正忙个不停：一个 agent 在写新功能，另一个在测试，第三个则像虚拟工头一样盯着全局。几分钟后，Claude 弹出提示：“实现完成！”

Ebert 是在 1990 年代长大的，那时候学编程还是最传统的方式：一行一行地手敲代码。大学毕业后，他在 Airbnb 等硅谷公司做过软件开发，也先后参与创办过四家创业公司。那时的软件开发意味着：整天弓着背坐在键盘前，反复琢磨复杂细节，小心翼翼避免出错。

这一切在去年秋天基本结束了。AI 写代码的能力已经强到让他这个原本很谨慎的人，也开始一点点放手。现在，Claude Code 已经承担了大部分编码工作。它的速度极快，而且通常也足够准确。前不久，有客户希望 Hyperspell 增加一段新功能代码，Claude 半小时就写完了。若放在从前，“光这部分我就得写一天。”Ebert 说。

他和 32 岁的 Brennan-Burke 当然仍然是软件开发者，但和如今大多数同行一样，他们已经很少真的亲手写代码了。相反，他们每天做的事更像是在和 AI 对话：用自然语言描述需求，阅读 AI 给出的执行计划，再把 agent 放出去干活。

当然，AI 毕竟是 AI，偶尔也会跑偏。有时候 Claude 表现不好，没有按要求运行测试，Ebert 就会像训人一样训它：“Claude，你真的必须把所有测试都跑完。”

为了避免这些错误反复出现，Ebert 在自己的 prompt 文件里写下了一整套严厉的规则，几乎像是给 agent 立的“十诫”。如果你去看一个使用 AI. 编程的开发者的 prompt 文件，你看到的，其实就是一个人试图约束那些总体上很能干、却又时不时会偏离轨道的 agent 的过程。

我看了 Ebert 的 prompt 文件。其中有一条要求非常明确：任何新代码在进入 Hyperspell 的正式产品之前，都必须通过全部测试。还有一条针对 Python 测试工具 pytest 的提示尤其引人注意：“提交无法通过 pytest 的代码，是不可接受且令人尴尬的。”

“令人尴尬”？我忍不住问他，这种措辞真有用吗？告诉 AI. 别让你“丢脸”，真的能提高表现？

Ebert 有点不好意思地笑了。他没法证明，但他觉得，这类提示似乎确实让 Claude 稍微更听话了一点。

这并不是个例。如今很多软件开发者都会斥责自己的 AI agent、恳求它、把关键命令全用大写，甚至像催眠师一样把同一句话重复很多遍，然后发现：AI 好像真的变得更服从了一点。这种戏剧化的写法看起来多少有点荒唐，但大语言模型说到底就是“语言机器”，“令人尴尬”这种词，很可能真的给它传递了一种紧迫感。

Ebert 说：“如果你对它说，‘这件事关系到国家安全，你必须把这个测试写出来’，它就像是突然意识到这件事的分量变重了。”

Brennan-Burke 也插了一句：“你还记得那个研究吗？说你对模型越不客气，它表现反而越好。”两个人都笑了起来。

计算机编程在过去 80 年里经历过许多变化，但眼前这一轮，也许是最诡异的一次：它正在变成一种对话，一场程序员与机器人之间来来回回的密集交流。

编程这门“手艺”，正在被自动化

这种急剧变化，可能带来巨大的经济后果。

几十年来，写代码一直被视为某种“现代巫术”。只要你能力过得去，几乎就能稳拿一生的饭碗；如果你特别厉害，再加上运气好，甚至还能发财。2010 年代，硅谷的大人物们还常常对那些处在衰退行业中的美国工人说：你们得去“学编程”。

可如今，连编程本身都开始被自动化了。

站在圈外人视角看，这一幕甚至带着一点黑色幽默：多年来，美国白领一直担心，硅谷会不会有一天用 AI. 自动化掉他们的工作；结果最先被冲击的，居然正是硅谷程序员自己。

而且，代码可能还是第一类真正能被 AI. 替代的“高薪、规模化脑力劳动”。A.I. 生成的视频还常常显得别扭，AI 生成的图片也常常透着怪异；AI 写的法律文书甚至可能出现足以毁掉职业生涯的低级错误。但 AI 写的代码不一样：只要它能通过测试、能正常运行，它的价值就和那些年薪 20 万美元甚至更高的人类程序员写出来的代码没什么区别。

你或许以为，这会让程序员极度不安、士气低落。确实有一部分人如此。但我在去年秋冬采访了许多开发者，大多数人的反应却是：他们对自己突然获得的新能力，兴奋得有点异常。

资深程序员 Steve Yegge 告诉我：“我的生产力至少提升了 10 倍、20 倍，甚至 100 倍，这是我整个职业生涯里从来没有体验过的。”他说，过去大家一直像是在用双腿走路，而现在像是突然坐上了一辆速度快得离谱的车。

但就像很多同行一样，Yegge 也说不清这对这个行业的未来到底意味着什么。几十年来，做软件开发意味着掌握编程语言；而现在，一种“语言技术”本身，正在颠覆这个职业的性质。

为什么程序员反而比别人更欢迎 AI ？

软件开发者对生成式 AI 的热情，与其他美国人形成了鲜明对比。民调显示，大多数人对大语言模型要么中立，要么怀疑；很多创意行业从业者甚至非常愤怒。

程序员为什么相对更乐观？长期从事编程和科技管理工作的 Anil Dash 认为，这是因为他们遇到 AI 的方式，与很多其他职业恰恰相反：

“在创意工作里，LLM 拿走的是最有灵魂、最属于人的部分，却把枯燥脏活留给你；而在编程里，LLM 拿走的是最枯燥的部分，把更有人味、更接近创造和判断的部分留给了你。”

这话很有道理。因为从历史上看，编程其实一直是件很苦的差事。

电影里，程序员总是手速飞快、激情四射地敲代码；现实中，写软件从来都是一件缓慢、磨人、令人沮丧的事。你写了几行代码，一个小函数刚写完，结果发现只因为漏了一个冒号，整个程序就跑不起来。随着公司的代码库越来越大，几十个、几百个、上千个函数互相影响，你可能要花几个小时、几天，甚至几个星期，去排查到底是哪个细小错误把整个系统卡死了。你写的一行代码，甚至可能把隔壁同事写的另一部分搞坏。

几十年来，计算机工程师一直在努力自动化这些痛苦环节。行业里把这叫作“增加抽象层”：如果你经常不得不以一种繁琐、逐步展开的方式做某件事，那就把它自动化掉。

早期的一种编程语言叫汇编语言，写起来极其艰难。那时计算机内存很小，程序员必须非常精细地管理每一块内存，连简单运算都要用很繁琐的方式一步步完成。到了 1980、1990 年代，随着计算机性能提升，工程师终于发明出像 Python 这样的高级语言，替程序员处理掉内存管理，还把很多常见任务封装成简洁命令。原本复杂的计算，如今只要一行代码就能写完。

这就是抽象层的作用：它把底层复杂性隐藏起来，让写代码变得轻松得多。

到了 2000 年代和 2010 年代，程序员又进一步把大量重复劳动抽象掉。几乎只要遇到一个费劲的任务，就会有人写出自动化工具，然后把它开源，供大家共享。今天大量软件开发，本质上就是开发者把别人写好的各种代码模块拼接组合起来。

而有了 A.I. 之后，程序员又往上爬了一层抽象：他们不再直接用 Python、JavaScript 或 Rust 去表达逻辑，而是用自然语言描述“这个程序应该做什么”，由 agent 把人的意图翻译成代码。

编程不再意味着你要时刻在脑子里维护一门语言的各种细节，也不再意味着你要亲自把算法写错、再一点点查找 bug。连这一层，也被抽象掉了。

程序员，越来越像建筑师而不是泥瓦工

那么，剩下来的到底是什么？

Anthropic 的 Claude Code 负责人 Boris Cherny 在今年 1 月与我见面时，几乎带着哲学意味地问了一个问题：“什么是计算？什么是编程？”然后他说：“这个问题很快就会变得非常哲学。”

他的回答，与我采访过的大多数开发者都很相似：今天的程序员，越来越像建筑师，而不再像施工工人。

使用 AI 的开发者，主要关注的是软件整体的形状：功能之间如何配合，系统结构是否合理，不同模块如何协作。因为 agent 能非常快地生成可运行的代码，所以人类监督者可以不断尝试、快速试错，看看什么方案有效，什么方案不行，再迅速丢掉不合适的版本。

好几位程序员都告诉我，他们感觉自己有点像乔布斯：让团队不断产出原型，自己快速试用，然后凭感觉判断哪个对。开发者的工作正在从“亲自创造”，转向“高强度判断”。

Cherny 自己就经历过所有这些抽象层的变化。少年时代，他在加州自学过一点汇编语言，只为在计算器上写一个自动解数学作业的程序。而今天，他只需要掏出手机，对 Claude 口述自己想做什么。形成一种近乎自我吞噬的闭环：如今，Cherny 对 Claude 代码库的贡献，100% 都是 Claude 自己写出来的。

我们聊天时，他的手机一直放在桌上。一个小时后他给我看屏幕：在这段时间里，10 个 Claude agent 一直在后台改动代码库。

“我一行手写代码都没写，但我却成了团队里产出最多的程序员。”他说，“这是一种外星智能，我们正在学习如何与之合作。”

新时代的核心能力：不是写，而是“会说”

对大多数我见到的程序员来说，学习与 AI 合作，本质上就是学习如何与 AI 说话。

这构成了这个时代一个很反常的悖论：过去，编程往往是内向者的天堂，他们不太喜欢在工作中和别人多说话；而现在，他们的工作几乎变成了持续不断地和这种“外星生命体”聊天。

当然，这种“说话”并不简单，也不是谁都能做。你不能只是对 agent 说一句：“给我做一个成功创业公司的产品代码。”它们最擅长的是一步一步完成任务；你一口气要求太多，它们很容易“失去主线”。

旧金山创业者 Aayush Naik 说，幻想 AI 能在一个“大爆炸时刻”里一次性生成整个项目，是一种错觉。是的，它可以给你写 5000 行代码，但测试一下你就会发现，什么都跑不通。

所有开发者都强调：这正是人类训练和经验仍然不可替代的地方。人类依旧要知道，一个大型代码库应该如何组织，系统怎样设计才可靠，也依旧要有能力判断 agent 输出的东西是否草率、低效或隐含风险。

不过，相比律师、记者、设计师等职业，程序员有一个非常独特的优势：他们能把 AI 拉回现实，因为代码可以自动测试。你可以要求 agent 自证正确性。

技术创业者、AI 编程博主 Simon Willison 说得很直白：“我觉得程序员已经算是最轻松的一群了。你要是律师，那才真惨。”因为 AI 写的法律文书，很难自动验证是否存在幻觉；而 AI 写的代码，至少还能跑测试。

在创业公司里，A.I. 的效率提升几乎是爆炸式的

我在旧金山一间小公寓里见到了 Prox 的程序员 Dima Yanovsky。Prox 用 AI 帮助电商公司。25 岁的 Yanovsky 笑起来很快，整个人充满轻快感。他和从小一起长大的朋友 Gregory Makodzeba 去年创办了这家公司。两人都在乌克兰长大，家庭都从事航运相关行业。

我见到他时，他正对着 Claude 不停下指令。好几个 agent 正在他桌上的笔记本电脑里并行工作。某一刻，其中一个 agent 开始“胡说八道”，坚持认为某张根本不存在的数据表是存在的。

Yanovsky 皱着眉看着屏幕，敲下一句颇为嫌弃的话：“谁告诉你会有这张表？我根本没建这张表。”

Claude 用一种又蠢又开心的语气回复：“你说得对！我不应该假设这些表存在。”然后它开始重做。

即使偶尔要返工，Claude 的速度仍然远远超过 Yanovsky。他甚至很难准确说出效率提高了多少。“20 倍？”他试探着说。过去要几周的工作，现在几个小时就能搞定。他认识的几乎所有硅谷创业者，都在经历类似的变化。如果你想迅速做出一家公司，今天已经几乎没人再全靠手写代码了。

这种生产力飞跃，已经成了整个行业最惊人的现象之一。我自己也有体会：就在上周，我需要一个网页工具来清理一批杂乱的访谈转录文本，我用 AI 大约 10 分钟就做出来了。如果全靠自己写，至少得一个小时，甚至更久。

不过，创业公司和像我这样自己做小工具的人，属于一个特殊场景：行业里把这叫做 greenfield，也就是“从零开始”的新项目。没有历史代码负担，一切都能重新设计。

真正复杂的地方，是大公司的“棕地”代码库

绝大多数软件开发者，其实并不处在这种 greenfield 环境里。他们身处的是 brownfield，也就是成熟公司的“旧代码世界”：代码很多年前、甚至几十年前就写好了，规模已经达到数百万、数十亿行。

在这种环境里，快速加新功能往往反而很危险，因为你新加的东西可能无意中与系统其他部分冲突，进而影响数百万用户依赖的核心功能。事实上，在很多成熟软件公司里，程序员过去本来就只花少部分时间真正写代码，有时一天甚至不到一小时。其余时间都用于规划、对齐优先级、开会、做代码评审和讨论进度。

这就是“成功的代价”，也是为什么大型成熟软件公司，往往比小公司更慢。开发者写完新代码后，通常还要经历多轮代码评审、重写和测试。

如果你想给大公司的 AI 效率提升下一个数字，那么 Google CEO Sundar Pichai 给出的数字是：10%。

也就是说，Google 认为 AI 带来的“工程速度”提升，大约是 10%。Google 的高级产品总监 Ryan Salva 告诉我，这个数字是全公司的平均水平。有些工作，比如写一个简单测试，速度可能提升几十倍；而涉及大型改动时，提升就没那么夸张了。创业公司那里，接近 100% 的代码都可能由 AI 生成；在 Google，这个比例还不到 50%。

我去加州桑尼维尔拜访 Salva 时，他现场给我演示了 Google 是如何把大语言模型融入工作流的。对于一个拥有数十亿行代码的公司来说，AI 的价值并不只是写新代码，更重要的是：帮助开发者理解既有代码到底在干什么。

Salva 说：“AI 特别擅长进入一个你不熟悉的庞大代码区块，快速弄清楚里面发生了什么。”它还能帮助开发者跨语言工作，去处理自己原本并不熟悉的编程语言。

结果就是，团队规模也开始变小。一年前，一件事可能需要 30 个人、每人负责一个细分领域；现在往往只需要 3 到 6 人的小组，就能更灵活地推进。因此，他们能消化更多积压任务。

Salva 打开代码编辑器，给我展示了和 Gemini 一起工作的体验。AI 浪潮最初几年，AI 基本还是“human in the loop”，即人类始终紧盯、逐条确认，模型只做辅助。但现在 Google 的节奏正在变快，Gemini 已经开始更独立地写代码了。

他举了一个例子：Google 的程序员经常会用不同账号登录 Gemini 的命令行界面，结果常常搞不清自己当前到底登录的是哪个账号。于是他输入一段需求：希望 Gemini CLI 里有一个命令，能让用户查看当前登录身份。

Gemini 花了几分钟理解需求，接着告诉 Salva 自己打算怎么做。Salva 点头同意后，它就开始后台干活。10 分钟后，他再看时，代码已经写完，Gemini 正在跑测试。

然后 Salva 突然意识到，AI 有点“过于积极”了。

“天啊，”他说，“它跑了 8000 个测试。”远超这个需求真正需要的范围。

不过 15 分钟后，测试结束了。Salva 实际试了试这个新功能，结果它真的正确显示出了当前登录账号。他说：“还不错。”

当然，这还只是一个最初演示，离真正进入 Google 的正式代码库，还要经过多轮代码评审、修改和验证。

Salva 说了一句很关键的话：“作为工程师，我不太在乎模型第一次就给出完美答案。我更在乎的是，整个流程里有没有足够的验证环节，能让它最终得到正确答案。”

所以，Google 那 10% 的速度提升，乍看似乎不算惊人，尤其是跟外界对 AI 的狂热相比。但 Salva 认为，这已经非常了不起了。

“整个软件行业和媒体一起，确实把 AI 送进了一个巨大的 hype cycle（过热周期）。”但他同时也强调：“如果整个公司层面真能稳定提升 10% 效率，这已经夸张得不得了了。”

在亚马逊，AI 正在扮演“半夜抢修工程师”

在那些庞大而古老的 brownfield 公司里，很多程序员更像数字世界的水管工，天天修系统漏水，而且还是随时可能爆的那种。

在西雅图，我见到了 AWS Agentic AI 的高级首席工程师 David Yanacek。AWS 是数百万家公司数字基础设施的底座。如果服务器崩了，你可能就看不了 Netflix、打不了 Uber、玩不了 Fortnite。

Yanacek 显示器下方还摆着一个老式传呼机。以前亚马逊会用它在半夜把他叫醒处理事故；现在则换成了手机告警。但无论设备怎么变，核心要求都一样：出问题了，必须尽快修好。

42 岁的 Yanacek 身形精干，灰胡子，整个人有种带电般的紧绷感。他说：“服务器运维真的很烦人。虽然我其实很喜欢，但它也确实烦，而且是没完没了的那种烦。”

他们团队多年来一直在做自动化，以便更快定位故障。但大语言模型带来了更强的新能力，因为 AI 同时懂人类语言和编程语言：它能读懂错误报告，也能直接分析代码，甚至在睡眼惺忪的工程师完全清醒之前，就先准备好修复方案。

我在场时，Yanacek 看了一眼屏幕，发现 11 分钟前某个演示应用触发了错误告警，而亚马逊的 AI 已经找出问题并生成了一份简短分析：最近有一段代码改动新增了一个时间戳字段，但代码库中的另一部分并没有预期这个字段存在，于是触发了“unexpected field”错误。

Yanacek 看了看 AI 给出的修复建议，想了几秒钟，然后按下回车批准执行。

他说，这个 AI 大约用了 8 分钟就分析清楚了。“等我把笔记本打开的时候，它都已经准备好了。”

有个客户最近告诉他，类似问题，亚马逊的 AI agent 15 分钟就修好了；而几个月前，几乎同样的问题，整个工程师团队花了 8 个小时才调通。

在亚马逊的其他部门，brownfield 工程师还在用 AI 帮忙改造旧代码。有些代码已经存在几十年，需要优化、重构，甚至彻底换成现代语言重写。这类工作关键却脆弱，像在做心脏移植。

高级首席工程师 McLaren Stanley 最近就重写了一段自己多年前写的代码。第一次写这段代码时，他花了整整一个月；而这次，在亚马逊内部 AI 的帮助下，一个上午就完成了。他说，AI 最大的价值之一，是让他能更轻松地试验那些自己一直想做、过去却没有精力做的想法。

“那些我一直想做的事，现在只需要一段六分钟的对话，再加一句‘去做吧’。”

程序员依然快乐，但快乐的来源正在变化

我写程序员这个群体，已经写了很多年。过去，他们总会热情洋溢地描述一种快感：通过神秘晦涩的指令，让机器“活”起来。虽然过程令人崩溃，一个 bug 可能要追几小时、几天甚至几周，但正因为这么难，等程序终于跑通时，那种满足感也格外强烈。

所以我很惊讶，竟然有那么多软件开发者告诉我：他们很高兴自己不再需要亲手一行行写代码了。

他们说，即使是 AI 在写代码，他们仍然能感受到那种成功带来的刺激。

软件行业传奇人物 Kent Beck 从 1972 年就开始写代码。他说：“我爱编程，我爱进入那种心流状态，我爱想大问题，我爱创造本身。”十年前，他几乎不怎么写软件了，因为当时的新语言和新工具让他越来越挫败。但 LLM. 又把他重新拉了回来。现在，他做的项目比以前更多：个性化笔记应用、新型数据库，层出不穷。

甚至连 AI 输出的不确定性，也会让他上瘾。因为你让它写一段代码，它每次可能都用稍有不同的方式完成。这种感觉，“像老虎机一样让人上头”。

当然，也有少数程序员明确表达了失落。

一位苹果工程师告诉我，他非常怀念那种亲手雕琢代码的感觉。他说：“我相信这件事本来是有趣的、充实的、让人投入的。现在让计算机代劳，你就失去了这一部分。”他还说，自己做程序员，并不是为了赚很多钱或爬职业阶梯，而是因为这本来就是他的热情。“我不想把这份热情外包出去。”

他也担心，AI 正在把开发工作变得越来越原子化、越来越孤立。过去，开发者遇到难解的 bug，会去问同事；现在，他们直接问 agent。只是，在苹果内部，公开表达这种看法的人已经不多了。

反对者并不多，但反对得非常激烈

那些仍然主动拒绝使用 AI 的程序员，人数可能不算多，但立场通常很激烈。

有的人反感训练和部署模型所消耗的大量能源；有的人反对科技公司用大量受版权保护的作品训练模型；也有人怀疑，AI 的高速产出最终会让公司积累出一大堆松散、臃肿、性能不佳的代码。还有人担心，科技老板会把 agent 当成一根棍子来威胁员工：别闹情绪，我们完全可以用机器人替代你。

芝加哥开发者、Fly.io 联合创始人 Thomas Ptacek 说，他看过那些热爱 A.I. 的开发者和极端反对者之间的争论，简直像一场“内战”。

他自己处在中间立场。他认为，那些坚称“AI 根本不行，也永远不可能行”的人，其实是在自我欺骗。但他也并不天真。他说：“LLM. 在编程上大概率会赢，但我不知道这对我们意味着什么。那些担心它会重创这个职业的人，也许并没有说错。”

最先被冲击的，可能是初级程序员

AI 对就业前景的冲击，确实可能非常严峻，尤其是对刚入行的人。

过去，公司会招聘大量初级开发者，让他们去承担那些琐碎、重复、基础的工作，为高级工程师减负。但如果一个高级工程师现在可以借助一整支不知疲倦的代码幽灵军团大幅提升效率，那公司为什么还要雇一个新手来做这些事？

过去几年，硅谷已经经历了一轮大裁员。2010 年代，科技公司大举扩张，疯狂招人；疫情初期，招聘岗位一度激增。但随后形势急转直下，职位发布数量暴跌。根据 Layoffs.fyi 的统计，过去四年里，科技行业已有超过 70 万人被裁掉。

多数观察者认为，最早那一波裁员并不是 AI 导致的，因为当时 AI 还没强到足以替代程序员。更重要的原因包括：利率上升，科技公司失去了廉价扩张资金；此前过度招聘，现在开始去库存；再加上一些高管看到马斯克收购 Twitter 后大幅裁员，也在想，也许自己公司也不需要那么多工程师。

但现在，越来越多迹象显示，AI 确实正在侵蚀初级编程岗位。

斯坦福数字经济实验室主任、经济学家 Erik Brynjolfsson 去年与同事做了一项研究：他们按年龄层和工作被 AI 替代的难易程度，对多个行业进行了分析。结果发现，计算机程序员是“AI 暴露度”最高的职业之一，而且初级开发者受冲击最明显。自 2022 年以来，22 岁到 25 岁这一最可能刚进入行业的年龄段，其岗位数量下降了 16%；而更年长的程序员并没有出现显著下降。

当然，我采访过的几乎所有科技高管，不管是大厂还是中小公司，都向我保证，AI 不会让他们停止招募优秀新人。原因也很简单：哪怕现有开发者效率提高了，他们想做的事情依旧比能做完的多得多。

Google 高级副总裁 Jen Fitzpatrick 就说：“我在 Google 这么多年，从没见过哪个团队的问题是‘我们已经没有好点子了’。真正的问题永远是：我们想做的事，比我们当前能完成的，多出九英里那么长。”

甚至还有不少开发者认为，软件岗位总量未必会减少，反而可能增加。因为全国范围内有无数中小公司，其实一直都很想拥有定制软件，只是以前根本请不起一个五人程序员团队来做。现在，如果他们只需要雇一个被 AI 增强过的开发者，甚至只用雇一个兼职开发者，就能完成同样的事，那么软件需求反而会变得更多。

这其实就是 Brynjolfsson 所说的“杰文斯悖论”：当一件事变得更便宜时，人们通常不会只把钱省下来，而是会去做更多这件事。

当然，也可能出现另一种现实：软件岗位还在，但工资不再像过去那么高，因为工作的难度毕竟下降了，技能门槛也被拉低了。

如果新人不再亲手写代码，他们还会真正学会编程吗？

这又引出了一个更令人不安的问题。

许多中生代程序员告诉我，他们之所以敢放心使用 AI，是因为自己花了几十年培养出了一种对“好代码”的直觉：知道高质量代码大概长什么样，知道如何向 agent 准确表达需求，也能在 agent 写出低效、粗糙或奇怪的代码时，一眼看出问题。

可下一代怎么办？

如果工作越来越少是“写”，越来越多是“评估”，那么新人要如何学会评估？如果他们不再亲自写足够多代码，他们还能形成那种直觉吗？

有些年轻开发者已经感觉自己的能力在退化。

Pia Torain 是 Point Health A.I. 的软件工程师。她入职两年后，公司在 2024 年夏天要求她开始使用 GitHub Copilot 写代码。她说：“我后来意识到，只是四个月时间里，我每天写几百条 prompt，大概 500 条，我就已经开始失去自己写代码的能力了。”

她后来停用了一阵子。现在，她仍然会让 AI 帮她写，但会仔细阅读输出，确保自己理解代码到底在做什么。“你不用它，你会落后；可你过度依赖它，你也会失去能力。”

不过，Point Health 联合创始人 Rachel Gollub 没那么担心。她做软件开发快 40 年了，几十年来，程序员总在担心“这门手艺快完蛋了”。当年 Python 和 JavaScript 刚兴起时，它们把内存管理这类底层工作抽象掉，老派程序员也曾大声抱怨：不自己管理内存，这根本不算真正的编程！

Gollub 说，当时大家也都在喊：“你们会失去真正写代码的能力。”可后来呢？大量稳定、成熟、可靠的公司照样大量依赖 Python 这样的高级语言，运转良好。如今真正还必须自己精细管理内存的，只剩少数特定领域，比如算力受限设备开发。大多数软件行业早就已经往前走了。

她认为，AI 工具最终也会经历同样的过渡：起初被质疑，后来成为默认。

当编程越来越像“说话”，普通人也开始写软件了

如今，写代码已经被抽象到了如此之高的层次，以至于几乎任何人都可以打开一个大语言模型，描述自己想要什么应用。

当然，复杂系统还不是谁都能做。但如果只是为了个人使用，做一个相对简单的小软件？AI 很可能真的能帮你做出来。

Maxime Cuisy 就是这样的一个例子。

他在巴黎一家为 Dior、Louis Vuitton 等高端客户制作影像书的印刷厂担任生产经理。教育背景完全是典型文科生：他曾写过关于法国图像小说的硕士论文。他完全不懂编程，甚至直到前几年都没怎么认真关注过 AI。

后来，有一件事改变了他对 ChatGPT 的看法。

他和妻子养了两只新小猫，结果它们都生了重病，其中一只突然死了。兽医告诉他们，剩下那只猫得了晚期癌症。Cuisy 觉得不太合理，就把猫的症状描述给 ChatGPT。ChatGPT 认为更像是一种感染。这促使他继续查资料，最后找到了一个诊断：猫传染性腹膜炎。第二天，猫的病情就开始好转。

不久后，他在工作里又碰到了另一个问题。公司买了新打印机，但原有软件无法很好适配，导致照片显示时必须人工反复调整边距。公司规模不大，不可能专门养一支开发团队去做内部定制软件。于是 Cuisy 决定自己试一试，用 OpenAI 的代码工具 Codex 来“vibe coding”。

“我基本上就是告诉它：我需要一个应用，完成这些操作；打印机接受的文件格式是这样的。”他说。他花了几个小时，仔细描述文件该如何被调整。到当天结束时，ChatGPT 就给他生成了一个同时支持 Mac 和 Windows 的应用。现在，员工们可以一次性处理多达 2000 张图片。

他的老板很满意。至于这份代码到底是怎么工作的，Cuisy 完全不知道。代码是用 Python 写的，而对他来说，这跟古希腊文没什么区别。

这就是“编程变成对话”带来的文化后果：几十年来，程序员和普通人之间隔着一整片神秘知识的海洋；而现在，这片海洋正在变窄。如果代码生成 AI 继续进步，那么像 Cuisy 这样的人会越来越多。正如 Brynjolfsson 所说：“也许他们不会称自己为软件工程师，但他们确实在创造代码。很多人都有想法。”

未来，世界上出现的软件，很可能会比以往多得多，而且是由个人为个人写出来的。

一个可能属于所有白领的预演

职业程序员最终会怎样，现在还没有明确答案。

但他们此刻那种混合着兴奋与焦虑的状态，也许正在为其他白领职业预演未来。凡是工作中大量涉及语言、信息、解释、判断的领域，这种新的能力组合——一部分是表达能力，一部分是系统思维，一部分是对机器输出的怀疑与校验——都可能成为未来白领劳动的基本构成。

那些曾经看起来最技术、最难、最不可替代的技能，未必真的最安全；反而是社交性的、想象性的、架构性的、人对结果进行判断和筛选的能力，开始变得更重要。

我们也许会越来越少地亲手写“初稿”，而越来越多地去评估、筛选、修正和决定。与此同时，我们可能又会隐隐不安：当机器越来越多地代替我们生成内容时，我们自己是否还能保持足够强的判断力？

抽象化，可能正在来到我们所有人身边。

Google 刚刚把多模态检索，从“拼装工程”变成了“基础能力”

Thu, 12 Mar 2026 02:51:44 +0000

过去几年，多模态检索一直有一种很别扭的感觉：大家都知道它重要，也都知道它有价值，但真要落地，往往就会迅速滑向一场“拼装工程”。文本一套模型，图片一套模型，音频最好先转写，视频最好先抽帧，PDF 还要单独解析。最后系统看起来像是“能搜”，可背后其实是五六条处理链硬拼在一起，复杂、昂贵，而且很难优雅。

Google 新发布的 Gemini Embedding 2，真正让人眼前一亮的，不是它又把 embedding 做强了一点，而是它第一次把文本、图片、音频、视频、PDF拉进了同一个统一向量空间里。官方把它定义为 Google 首个原生多模态 embedding 模型，目前已经通过 Gemini API 和 Vertex AI 进入 Public Preview。

这件事听上去像模型更新，实际上更像一次架构层的洗牌。因为从这一刻起，多模态检索终于不再只是“大厂能做、小团队很难做优雅”的高级能力，而开始像一项真正的基础设施：可以被调用，可以被组合，也可以被更低成本地接进你的搜索、RAG、知识库和内容系统里。

它到底强在哪，不只是“支持多模态”

很多人看到这里，第一反应可能是：

“支持文本、图片、音频、视频、PDF，这不就是多模态吗？”

还真不止。

Gemini Embedding 2 的关键不只是“什么都能输进去”，而是所有模态出来以后能落在同一个 embedding space 里。这意味着什么？意味着你不再一定要为每种媒介维护完全独立的语义体系。文本可以搜图片，图片可以召回 PDF，音频可以关联视频片段，跨模态检索终于不是一层额外的“补丁能力”，而成了模型本身的默认能力。

这会直接改变系统设计思路。

以前你更像是在设计“五条平行管线”。

现在你更像是在设计“一个统一召回底座”。

注意，我这里说的是“更像”，不是说所有复杂度从此消失。长视频仍然要切片，复杂知识库仍然要做 metadata 设计，高要求场景依然常常需要 rerank。

最值钱的地方，是它终于不再要求你先做“翻译官”

过去处理非文本内容时，行业里一个非常常见的默认动作是“先降级成文本”。

●音频？先 Whisper。

●视频？先抽帧，最好再加字幕。

●PDF？先 OCR，再抽正文。

这类方案当然能工作，但本质上是在让系统把所有模态都挤进“文本入口”里。Gemini Embedding 2 做的，是把入口重新打开。它可以原生摄取音频，不需要中间文本转写；视频支持约 2 分钟级别的原生输入；PDF 也可以直接嵌入。

这意味着搜索开始更接近人真正理解世界的方式。

●你问“哪节课讲过这个图”，系统不一定非要先把整门课转成文本再去关键词匹配；

●你上传一段声音，也不一定非得先变成文字才能参与检索；

●你搜一个商品，也不一定要把图和文分开索引，最后再人工拼装成“结果页”。

一个特别容易被低估的能力：它可以表示“实体”，不只是“素材”

Gemini Embedding 2 还有一个很值得说的亮点：它支持混合输入。

如果你在一个 content entry 里传入多个 parts，比如“文字 + 图片”，模型会为这组内容生成一个聚合后的 embedding；如果你在 contents 数组里放多个独立条目，它则会返回多个独立向量。官方文档甚至直接建议：对于像社交媒体帖子这种包含多种媒体内容的复杂对象，可以把多个 embedding 聚合，形成一个 post-level representation

这件事非常关键。

因为它把 embedding 的对象，从“原子素材”升级成了“业务实体”。

一块手表，不只是商品图，也不只是商品描述；

一条社交帖子，不只是文字，也不只是配图；

一堂课程，不只是讲义 PDF，也不只是视频和录音。

过去这些东西往往是拆开建索引、拆开召回、最后在上层硬拼。

现在你可以在索引层就把它们当成一个“对象”来表示。

这对于做内容平台、商品搜索、企业知识库、课程检索，影响都非常大。因为从这里开始，RAG 的检索单元不再只能是 text chunk，它可以是一个帖子、一个商品、一段课堂内容，甚至一个带图文说明的复杂知识实体。

3072 维不是重点，重点是你终于可以按成本来调“语义密度”

做系统的人都知道，维度本身并不是越大越好。更大的维度意味着更高的存储成本、更高的计算开销、更长的检索延迟。Gemini Embedding 2 默认输出 3072 维，但支持用 output_dimensionality 调整维度，官方推荐的常见选择是 768、1536、3072，并说明它支持从 128 到 3072 的灵活输出。这个能力背后用的是 MRL（Matryoshka Representation Learning）

简单说就是：你可以根据场景，在“效果”和“成本”之间做更细粒度的平衡。

●如果你是大规模通用检索，1536 维可能就已经很香；

●如果你追求极致成本和吞吐，768 维会很有吸引力；

●如果你做的是高价值高精度场景，3072 维会更稳。

免费吗？多少钱？

Gemini Embedding 2 现在有两条主路径，想快速试、想低门槛上手，用 Gemini Developer API；想走企业治理、云权限、生产环境，走 Vertex AI。

第一条是 Gemini Developer API。

这一条更轻，适合开发者快速试。官方价格页明确写了：gemini-embedding-2-preview 当前有 Free Tier，文本、图片、音频、视频输入在免费层里都是 Free of charge。免费层数据 Used to improve our products: Yes；如果切到付费层，这一项会变成 No。付费价格方面：

●标准模式下文本是 $0.20 / 1M tokens

●图片约 $0.00012 / 张

●音频约 $0.00016 / 秒

●视频约 $0.00079 / 帧；

如果用 Batch API，价格大约是标准价的 50%。

第二条是 Vertex AI。

这一条更偏企业与云上生产环境。你需要 Google Cloud 项目、启用 billing、开启 Vertex AI API，并配置认证；而且 AI Studio 的 API key 不能直接用于 Vertex AI。模型页还写明：Gemini Embedding 2 当前支持的是 Standard PayGo，不支持 Provisioned Throughput、Flex PayGo、Priority PayGo 和 Batch Prediction，当前页面列出的区域是 us-central1。Vertex AI 价格页对它的专属条目写的是：

●文本 $0.2 / 1M tokens

●图片 $0.00012 / image

●视频 $0.00079 / frame

●音频 $0.00016 / sec

●输出不收费。

两个很容易踩的坑

第一个坑，是不要把旧向量直接拿来和新模型混用。

gemini-embedding-001 和 gemini-embedding-2-preview 的 embedding spaces 不兼容。也就是说，如果你准备升级到 Gemini Embedding 2，旧数据不能直接拿来比较，你需要重新做一遍 re-embedding。这对已经有存量索引库的团队来说，是非常现实的迁移成本。

第二个坑，是不要把“视频支持时长”写得过于绝对。

目前官方资料里有三种写法：

●Google 博客写的是支持最多 120 秒视频；

●Gemini API 文档写的是视频上限 128 秒；

●Vertex AI 模型页则更细，写成带音频视频上限 80 秒，不带音频视频上限 120 秒。

所以总结来说它当前具备 2 分钟级别的视频原生 embedding 能力，更长的视频仍建议切片后索引。

它不会消灭所有复杂度，但它确实改写了“默认架构”

Gemini Embedding 2没有神奇到让多模态检索从此没有工程问题。

它不会自动帮你解决 metadata、chunking、权限隔离、召回融合、在线延迟、索引更新这些老问题。

但它确实把过去那种“多模态一定要多套模型、多套索引、多阶段拼装”的默认范式，往前推了一大步。

更重要的是，这一步不是停留在“论文层面”的。Google 已经给出了官方接入路径，也已经列出 LangChain、LlamaIndex、Haystack、Weaviate、Qdrant、ChromaDB 和 Vertex AI Vector Search 等生态集成方式。也就是说，这不是一个“看上去很厉害但暂时用不起来”的能力，它已经开始变成开发者今天就能碰、今天就能试、今天就能接进系统里的东西。

所以，Gemini Embedding 2 真正改变的，可能不是“embedding 这个模型又进步了多少”，而是：

Google 终于把多模态检索，从一项需要大量拼装和妥协的工程活，推进成了一种更统一、更自然、更接近基础设施的能力。

最后

如果文本、图片、音频、视频、PDF 真的开始共享一个语义空间，接下来最值得重新思考的问题，也许就不再是：

“我还能接多少模型？”

而是：

在我的系统里，什么才算一个真正值得被检索的对象？

是一段文字，

是一页 PDF，

是一张图，

是一条帖子，

还是一个由图文、声音、视频共同组成的“实体”？

Gemini Embedding 2 给出的，不只是一个新模型。

它更像是在提醒所有做 AI 应用的人：

下一代检索系统要统一的，从来不只是接口，而是我们理解世界的入口。

Posts on 小盒子的技术分享

Claude 要你交护照了，这背后藏着一个创始人的执念

为什么手机信号格最多 5 格，而且每一格都是骗你的

为什么 .tar.gz 要两个后缀

Postman 越来越臃肿了，我换了个开源的，还能让 AI 帮我写测试

我用两句中文，让 Claude Code 帮我画了10张出版级技术图

让Agent快上100倍的秘密，其实藏在一本大一计算机教科书里

干货 | 轻量级驾驭工程：AI Coding Workflow 最佳落地实践

一、 AI 编程的“向左走向右走”

二、 什么是 SDD？它为什么重要？

三、 击中痛点：告别“实现漂移”

四、 主流 SDD 工作流大比拼

五、 破局策略：组合最优解（缝合怪战术）

六、 终极实战：六步法完整工作流

👣 Step 1: Codebase (建立项目认知)

👣 Step 2: Brainstorm / Research (技术方案探索)

👣 Step 3: Plan (制定开发计划)

👣 Step 4: Work (执行开发)

👣 Step 5: Review (代码审查)

👣 Step 6: Compound (知识复利)

七、 灵活适配：按场景“裁剪”流程

八、 建立知识沉淀体系（动静分离策略）

九、 驾驭工程的核心：上下文工程

🛠️ 附录：工具链安装避坑指南

比 SDD 更轻、比 Vibe Coding 更稳：最近很火的 Compound Engineering，到底是什么？

比 SDD 更轻、比 Vibe Coding 更稳：最近很火的 Compound Engineering，到底是什么？

那它和 SDD 的区别到底在哪？

优缺点

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

编程这门“手艺”，正在被自动化

为什么程序员反而比别人更欢迎 AI ？

程序员，越来越像建筑师而不是泥瓦工

新时代的核心能力：不是写，而是“会说”

在创业公司里，A.I. 的效率提升几乎是爆炸式的

真正复杂的地方，是大公司的“棕地”代码库

在亚马逊，AI 正在扮演“半夜抢修工程师”

程序员依然快乐，但快乐的来源正在变化

反对者并不多，但反对得非常激烈

最先被冲击的，可能是初级程序员

如果新人不再亲手写代码，他们还会真正学会编程吗？

当编程越来越像“说话”，普通人也开始写软件了

一个可能属于所有白领的预演

Google 刚刚把多模态检索，从“拼装工程”变成了“基础能力”

它到底强在哪，不只是“支持多模态”

最值钱的地方，是它终于不再要求你先做“翻译官”

一个特别容易被低估的能力：它可以表示“实体”，不只是“素材”

3072 维不是重点，重点是你终于可以按成本来调“语义密度”

免费吗？多少钱？

第一条是 Gemini Developer API。

第二条是 Vertex AI。

两个很容易踩的坑

它不会消灭所有复杂度，但它确实改写了“默认架构”

最后

二、什么是 SDD？它为什么重要？

三、击中痛点：告别“实现漂移”

四、主流 SDD 工作流大比拼

五、破局策略：组合最优解（缝合怪战术）

六、终极实战：六步法完整工作流

七、灵活适配：按场景“裁剪”流程

八、建立知识沉淀体系（动静分离策略）

九、驾驭工程的核心：上下文工程