Claude 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。安全的边界如果无限扩张，最后得到的不是更安全的天空，而是一个没人愿意坐飞机的世界。

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

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

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

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 所说：“也许他们不会称自己为软件工程师，但他们确实在创造代码。很多人都有想法。”

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

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

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

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

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

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

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

OpenAI 开源 Symphony：AI 不再只是写代码，而是开始接管“工作流”

Sat, 07 Mar 2026 11:39:53 +0000

最近跟业界一些朋友交流，不少公司正在做内部软件开发的 AI 自动化流程系统，正好这两天，OpenAI 在 GitHub 上低调开源了一个很值得认真看的项目：Symphony。

如果只看名字，你很容易把它理解成“又一个多 Agent 编排框架”；但只要认真读完 README、SPEC.md 和参考实现里的 WORKFLOW.md，你会发现它真正想解决的，根本不是“让 AI 会写代码”，而是另一件更大的事：

如何把软件研发中的“工作”，交给一套可以持续运行、可隔离、可调度、可回收、可观测的系统去推进。

这就是 Symphony 最重要的定位。官方原话非常值得细品：

它会把项目工作转成 isolated, autonomous implementation runs，让团队从“监督 coding agents”转向“管理 work”。README 里的 demo 也很直白：Symphony 盯着 Linear 看板拿任务，拉起 agent 处理 issue，回传 CI 状态、PR review 反馈、复杂度分析和 walkthrough 视频，最后在被接受后安全落 PR。

很多人第一次看到这里，会本能地把它和 Copilot、Cursor、Claude Code 之类工具放在一起比较。但我觉得，真正准确的比较方式不是“谁代码写得更强”，而是：谁更接近一个面向研发现场的执行系统。 Copilot 类产品解决的是“我写代码时，旁边有个聪明助手”；Symphony 想解决的是“我有一堆 issue，能不能让系统自己取单、分配环境、拉起 Agent、推进状态、处理失败、保留上下文，并把结果交回给我验收”。这已经不只是“辅助编码”，而是开始触碰软件交付流水线本身。

一、Symphony 到底是什么？

从 SPEC.md 看，Symphony 的定义非常清晰：它是一个 long-running automation service。在当前规范版本里，它会持续从 issue tracker 读取工作（v1 里明确是 Linear），为每个 issue 创建独立 workspace，并在这个 workspace 里运行 coding agent session。规范还特别强调了它要解决的四类问题：

1.把 issue 执行变成守护式工作流

2.把每个任务隔离到独立 workspace

3.把工作流策略放回 repo 内的 WORKFLOW.md

4.以及为多任务并发运行提供足够的 observability。

这段定义很重要，因为它一下子把 Symphony 和大量“Agent Demo”拉开了距离。它不是一个写几个 prompt、串几个工具的 toy project，也不是一个单轮任务脚本。它有轮询、有调度、有状态机、有重试退避、有 workspace 生命周期、有运行期事件、有恢复逻辑。换句话说，它的思维方式更像一个 orchestrator，而不是一个单纯的 agent wrapper。

更关键的是，SPEC 还专门写了一个“重要边界”：Symphony 是 scheduler/runner 和 tracker reader。这句话很克制，也很专业。它的意思是，Symphony 的职责重点不是替你定义所有业务流程，而是负责任务编排、执行承载和状态协调；而 ticket 状态变更、评论、PR 链接等写操作，通常还是由 coding agent 借助工具在运行时完成。也就是说，它不是一个万能 PM 系统，而是一层面向软件交付的 agent orchestration 壳。

二、它为什么比“会写代码”更进一步？

因为真正麻烦的，从来不是 AI 能不能生成一段代码，而是几十个任务并行推进时，系统怎么不失控。

Symphony 在这方面做得非常工程化。它有明确的内部状态机：Unclaimed、Claimed、Running、RetryQueued、Released。它还定义了 run attempt 的阶段：准备 workspace、构建 prompt、拉起 agent 进程、初始化 session、流式执行 turn、结束、成功、失败、超时、卡死、被 reconciliation 取消。它甚至规定了每次 poll tick 到来时，先 reconciliation，再校验配置，再拉候选 issue，再按优先级分发，最后通知 observability 消费者。

这套设计背后的思想可以概括成一句话：

不要先问“怎么让 Agent 跑起来”，而要先问“怎么避免它跑重、跑错、跑飞”。

比如 candidate selection 里就有一条很像真实研发现场的规则：如果 issue 还处于 Todo，而它依赖的 blocker 还没进入终态，那就不要派发。排序也不是瞎来，而是按 priority、创建时间、issue 标识顺序稳定分发。失败之后也不是简单重试，而是区分正常退出后的短延迟 continuation retry 和异常退出后的指数退避重试。这样的设计，明显已经不是“写代码助手”的思路，而是“任务执行系统”的思路。

三、每个 issue 一个 workspace：这是 Symphony 最值钱的工程细节

如果你只让我挑 Symphony 里最关键的一点，我会选这个：per-issue workspace。

SPEC 写得非常清楚：

每个 issue 的 workspace 路径都必须位于配置的 workspace root 之下；coding agent 只能在该 issue 的 workspace 里执行；workspace 目录名必须净化；还支持 after_create、before_run、after_run、before_remove 等 hooks。工作区会跨运行复用，但终态 issue 可以在启动或状态变更时清理。

**为什么这个设计这么重要？**因为一旦没有隔离，Agent 系统很快就会碰到三个问题：上下文污染、任务互相踩踏、失败后难以恢复。Symphony 的思路很像给每个工单都分配一个独立工位，Agent 只能在自己的工位里思考、改代码、跑测试、记录状态。哪怕它中途失败了，下次重试回来，也可以在同一个 workspace 上继续，而不是重新失忆。

这也是为什么我说 Symphony 更接近“工程执行系统”而不是“聊天式 Agent”。聊天系统强调对话连续；Symphony 强调的是任务连续性。这两个东西，根本不是一个层级。

四、WORKFLOW.md 才是灵魂：把 Prompt 升级成 repo 内契约

Symphony 很聪明的一点，是它没有把流程硬编码进平台，而是把策略收回到仓库里。SPEC 规定 WORKFLOW.md 由 YAML front matter 和 Markdown prompt body 组成，运行时会解析出 config 与 prompt template；很多核心行为——轮询间隔、workspace root、并发限制、hooks、agent 参数——都来自这份 repo-owned contract。

参考实现里的 WORKFLOW.md 更是把这种思想写得非常彻底。它规定了 issue 在不同状态下该怎么流转：

●Todo 要立即切到 In Progress，然后找或建唯一的 ## Codex Workpad 评论，再开始分析与实现；

●Human Review 阶段不再改代码，只轮询 review 结果；

●进入 Merging 后必须走专门的 land 技能，不能直接 gh pr merge。文档还要求把单个 workpad comment 当作进度和交接的唯一真相源，并且把 out-of-scope 改进拆成新的 Backlog issue，而不是在当前任务里偷偷扩 scope。

这件事的意义非常大。它意味着团队以后真正需要打磨的，不只是“怎么写 prompt”，而是“怎么把流程、约束、验收标准、状态流转、回退机制，写成一份和代码一起版本化的工程契约”。这比 prompt engineering 更接近组织能力。

五、为什么参考实现偏偏选了 Elixir？

这不是噱头，反而是我觉得 Symphony 最有工程味的地方之一。

GitHub 仓库当前语言分布里，Elixir 约占 94.9%；README 也直接写了 Why Elixir?：因为 Elixir 运行在 Erlang/BEAM/OTP 之上，很适合监督长时间运行的进程，并且支持在不停止活跃 subagents 的情况下做 hot code reloading。

这和 Symphony 的问题形态是高度匹配的。一个普通 Web 请求可能几十毫秒就结束，但一个 coding agent 处理复杂任务时，可能会持续很久，还要接收事件、处理重试、维持会话、更新状态、暴露观测数据。BEAM/OTP 擅长的，恰好就是这种长生命周期、并发多、失败要可控隔离的系统。OpenAI 官方没有在 README 里展开讲 supervision tree 这些词，但它给出的理由已经足够说明方向：Symphony 不是在追求“AI 生态默认语言”，而是在追求“最适合承载 agent orchestration 的运行时”。

六、真正的前提不是更强模型，而是 Harness Engineering

如果说 Symphony 讲的是“如何调度 Agent”，那 Harness Engineering 讲的就是“怎样让 Agent 值得被调度”。

OpenAI 在官方文章里把这件事说得很重：他们构建的产品里，应用逻辑、测试、CI、文档、可观测性和内部工具，全部由 Codex 写出；而人类工程师的角色，从直接写代码，转向设计环境、明确意图、构建反馈回路。文章里那句“Humans steer. Agents execute.”，几乎可以看作整个 Symphony 时代的软件工程宣言。

也正因如此，README 才会明确写：Symphony 最适合已经采用 harness engineering 的代码库。意思很简单：如果你的仓库没有可靠测试、没有清晰边界、没有稳定构建入口、没有可验证的反馈回路，那么再强的 Agent 也只是更快地在混乱里打转。Symphony 的价值，不是替代工程纪律；恰恰相反，它会把工程纪律的重要性放大十倍。

七、它的边界也必须讲清楚

一个成熟的技术判断，不能只讲想象力，不讲边界。

Symphony 现在仍是一个工程预览版，README 明确写了适用于 trusted environments；SPEC 也写了 approval policy、sandbox policy、operator confirmation posture 都是 implementation-defined，不同实现可以高信任，也可以更严格。它当前规范版本只定义了 Linear 作为 tracker，至于更多 issue tracker 适配器，还是 TODO。参考实现虽然带可选 Phoenix observability 服务和 JSON API，但整个项目还远没到“所有团队直接开箱上生产”的阶段。

所以，最稳妥的结论不是“研发彻底无人化已经到来”，而是：

OpenAI 正在把 AI Coding 从“单点能力演示”推进到“工程系统形态演示”。

这一步，比单纯再出一个更强的代码模型，更值得关注。

结语

如果一定要用一句话概括 Symphony，我会这样说：

它不是在教 Agent 如何写代码，而是在教团队如何把“软件交付”本身改写成一套可执行、可编排、可观测的系统。

过去，AI 是工程师的副驾驶；现在，Symphony 展示的是另一种可能：工程师不再盯着每一行代码，而是站到更高一层，去设计流程、约束环境、设定验收标准，然后管理一批持续运行的 agent 去推进工作。真正的变化，不是“AI 会不会写 CRUD”，而是“软件组织会不会因此改写自己的工作方式”。

这，才是 Symphony 最值得认真读的地方。

一文讲透 GoF 的 23 种设计模式之工厂方法

Fri, 27 Feb 2026 23:00:00 +0000

一文讲透 GoF 的 23 种设计模式之工厂方法

工厂方法（Factory Method）是创建型模式

定义

用一句话概括工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。它让类的实例化推迟到了子类。

简单工厂

了解工厂方法模式前，我们先了解下简单工厂，既然叫简单工厂，那自然很 “简单”。

它的核心思想非常直接：专门定义一个类（包揽大权），通过接收不同的参数，用 switch 或 if-else 来决定创建并返回哪一种具体的产品实例。

假设我们在开发一个 AI 应用，需要根据不同场景创建不同类型的 AI Agent（比如负责对话的 Agent，和负责处理数据的 Agent）。

第一步：定义产品的共同接口和具体实现

 1⚡ java片段// 1. 抽象产品
 2public interface AIAgent {
 3 voidexecuteTask();
 4}
 5
 6// 2. 具体产品 A：聊天助理
 7publicclass ChatAgent implements AIAgent {
 8 @Override
 9 publicvoidexecuteTask() {
10 System.out.println("ChatAgent: 正在与用户进行自然语言对话...");
11 }
12}
13
14// 2. 具体产品 B：数据分析助理
15publicclass DataAnalysisAgent implements AIAgent {
16 @Override
17 publicvoidexecuteTask() {
18 System.out.println("DataAnalysisAgent: 正在提取并分析核心数据...");
19 }
20}

第二步：创建“简单工厂”类

 1⚡ java片段// 3. 简单工厂类 (通常使用静态方法)
 2publicclass AIAgentFactory {
 3 
 4 // 根据传入的类型参数，决定实例化哪个具体的 Agent
 5 publicstatic AIAgent createAgent(String agentType) {
 6 if ("chat".equalsIgnoreCase(agentType)) {
 7 return new ChatAgent();
 8 } elseif ("data".equalsIgnoreCase(agentType)) {
 9 return new DataAnalysisAgent();
10 } else {
11 throw new IllegalArgumentException("未知的 Agent 类型: " + agentType);
12 }
13 }
14}

第三步：客户端调用

 1⚡ java片段public class Client {
 2 public static void main(String[] args) {
 3 // 客户端不需要知道 ChatAgent 和 DataAnalysisAgent 是怎么被 new 出来的
 4 // 只需要告诉工厂：“给我一个 chat 类型的 Agent”
 5 AIAgent agent1 = AIAgentFactory.createAgent("chat");
 6 agent1.executeTask();
 7
 8 AIAgent agent2 = AIAgentFactory.createAgent("data");
 9 agent2.executeTask();
10 }
11}

结合代码，我们可以很直观地看到它的特点：

●优点（省事、解耦）：客户端彻底和具体的实现类解耦了。你不需要在业务代码里到处写 new ChatAgent()，把“创建对象”的脏活累活全交给了工厂。

●缺点（牵一发而动全身）：它严重违反了“开闭原则”（对扩展开放，对修改关闭）。假设我们现在要引入一个新的 CodingAgent（写代码助手），除了要新建产品类，你必须去修改 AIAgentFactory 里面的 if-else 代码。一旦产品种类极其庞大，这个工厂类就会变得非常臃肿且难以维护。

正是为了解决简单工厂“违反开闭原则”的这个致命缺点，才演进出了工厂方法模式（把这一个大工厂，拆成了一个个不用改代码、只需新增的具体小工厂）。

工厂方法模式的结构与角色

工厂方法模式主要包含四个角色：

●抽象产品 (Product)：定义产品的统一接口。

●具体产品 (Concrete Product)：实现抽象产品接口的具体类。

●抽象工厂 (Creator)：声明返回产品对象的工厂方法。

●具体工厂 (Concrete Creator)：重写工厂方法，返回具体的实例化产品

Java 代码实现

1. 定义产品（大模型客户端）

 1⚡ java片段// 抽象产品：统一的大模型调用接口
 2public interface LLMClient {
 3 String generate(String prompt);
 4}
 5
 6// 具体产品 A：Claude 客户端
 7publicclass ClaudeClient implements LLMClient {
 8 private String modelVersion;
 9 
10 publicClaudeClient(String modelVersion) { this.modelVersion = modelVersion; }
11
12 @Override
13 public String generate(String prompt) {
14 return"[Claude " + modelVersion + "] 思考并返回结果...";
15 }
16}
17
18// 具体产品 B：OpenAI 客户端
19publicclass OpenAIClient implements LLMClient {
20 private String endpoint;
21 
22 publicOpenAIClient(String endpoint) { this.endpoint = endpoint; }
23
24 @Override
25 public String generate(String prompt) {
26 return"[OpenAI API] 处理输入并返回结果...";
27 }
28}

2. 定义创建者（核心：业务骨架 + 工厂方法）

这里是关键：AgentWorkflow 不是一个纯粹的“工厂类”，它是业务类，工厂方法只是它的一部分。

 1⚡ java片段// 抽象创建者：Agent 工作流骨架
 2public abstract class AgentWorkflow {
 3
 4 // 核心业务逻辑：定义了标准的处理流程（这其实也是个模板方法）
 5 publicvoidprocessTask(String taskContext) {
 6 System.out.println("=== 1. 解析任务上下文，提取关键信息 ===");
 7 
 8 // 【灵魂所在】：这里调用工厂方法，拿到一个产品对象。
 9 // 父类在此刻完全不知道自己拿到的是 Claude 还是 OpenAI。
10 LLMClient client = createLLMClient();
11 
12 System.out.println("=== 2. 请求大模型进行推理 ===");
13 String result = client.generate(taskContext);
14 
15 System.out.println("=== 3. 结果后处理并落库 ===\n" + result + "\n");
16 }
17
18 // 【工厂方法】：将实例化具体产品的职责，推迟到子类去实现
19 protected abstract LLMClient createLLMClient();
20}

3. 定义具体创建者（子类重写工厂方法）

 1⚡ java片段// 具体创建者 A：基于 Claude 的工作流
 2publicclass ClaudeAgentWorkflow extends AgentWorkflow {
 3 @Override
 4 protected LLMClient createLLMClient() {
 5 // 这里封装 Claude 特有的复杂初始化逻辑（比如加载凭证、设置代理等）
 6 System.out.println(" -> [工厂方法] 正在初始化 Claude 客户端环境...");
 7 return new ClaudeClient("3.5-Sonnet");
 8 }
 9}
10
11// 具体创建者 B：基于 OpenAI 的工作流
12publicclass OpenAIAgentWorkflow extends AgentWorkflow {
13 @Override
14 protected LLMClient createLLMClient() {
15 System.out.println(" -> [工厂方法] 正在构建 OpenAI 客户端环境...");
16 return new OpenAIClient("https://api.openai.com/v1");
17 }
18}

4. 客户端调用

 1⚡ java片段public class Client {
 2 publicstaticvoidmain(String[] args) {
 3 String task = "编写一段 Python Web 框架对比报告";
 4
 5 // 场景 1：启动基于 Claude 的 Agent 工作流
 6 AgentWorkflow claudeWorkflow = new ClaudeAgentWorkflow();
 7 claudeWorkflow.processTask(task);
 8
 9 // 场景 2：切换为基于 OpenAI 的 Agent 工作流
10 AgentWorkflow openaiWorkflow = new OpenAIAgentWorkflow();
11 openaiWorkflow.processTask(task);
12 }
13}

如果你回看之前的例子，你会发现这个 Demo 解决了一个架构设计上的核心痛点：控制反转 (IoC) 的雏形。

在 AgentWorkflow 这个父类中，业务主流程已经被彻底固化并复用（processTask 方法）。如果在未来，业务需求要求你接入一个全新的本地开源模型（比如 DeepSeek），你不需要修改任何现有的主流程代码，只需要：

●新建一个 DeepSeekClient（实现 LLMClient）。

●新建一个 DeepSeekAgentWorkflow，重写 createLLMClient() 方法返回这个新 Client。

这才是工厂方法模式真正强大的地方：它是为了让高层模块（业务骨架）能够独立于底层模块（具体产品）的创建而存在，从而支撑起大型框架的扩展性。 JDK 里的 Iterable 接口和它的 iterator() 方法，本质上就是这种工厂方法模式的经典体现。

什么时候用?

●你写的“父类流程”需要创建某种对象，但父类不该/不想知道具体类是谁（框架留扩展点的典型方式）。

●你希望通过继承覆写来扩展“产物类型”，让调用方不动、流程不动。

一些具体的场景：

●框架扩展点：工厂方法很常见于“框架规定流程、业务方覆写创建”的场景（你写子类接入框架）。

●Spring 的 FactoryBean：它的语义就是“这个 bean 不是普通 bean，而是用来生产另一个对象的”，并且暴露的是 getObject() 创建出来的对象。

●Java ServiceLoader：通过 SPI 在运行时发现/加载实现类，属于“把具体实现延迟到运行时配置/部署”的一类机制，和“解耦创建与使用”的目标一致。

注意模式的命名

我们回头看一下这个模式为什么叫 Factory Method，而不是干脆叫 Factory ? 这个命名是有讲究的。

核心原因在于：这个模式的灵魂是一个“方法”，而不是一个“类”。

1.“工厂 (Factory)”是一个通俗的广义概念：

在日常沟通中，只要一个类的主要职责是造对象，我们都叫它工厂（比如前面提过的“简单工厂”，它就是一个充斥着 if-else 的具体类）。

2.“工厂方法 (Factory Method)”强调的是面向对象中的“多态”与“继承”：

在 GoF 的定义中，创建对象的逻辑并不是封装在一个独立的、包揽大权的“工厂类”里，而是定义在了一个普通业务类（Creator）的内部，作为一个抽象方法存在。

●这个模式的精髓是：父类定义业务骨架，把其中“需要实例化具体对象”的那一步，挖空成一个方法（也就是 Factory Method）。

●具体的实例化工作，推迟（Defer）到了子类去重写这个方法来实现

全程0人工写代码！干掉低级码农的不是大模型

Tue, 24 Feb 2026 03:46:39 +0000

全程0人工写代码！干掉低级码农的不是大模型

在当前全行业的 AI 辅助编程浪潮中，大多数工具仍停留在“交互式伴游”阶段，而支付巨头 Stripe 却打造了一套完全无人值守的端到端代码智能体——“小黄人”（Minions）

小黄人是一个独立打工的“数字员工”。目前的惊人数据是：在 Stripe 内部，每周有超过 1300 个由小黄人完全生成的 Pull Requests（合并请求）被成功合并。这些代码在最终阶段会经过人类审查，但其中不包含任何人类编写的代码。

更具挑战的是，Stripe 的代码库高达数亿行，主要使用较冷门的带有 Sorbet 类型的 Ruby 语言，且包含大量 LLM 根本没见过的大型内部自研库。此外，这些代码每年要处理超过 1 万亿美元的支付量，合规与容错要求极高。

Stripe 是如何让 LLM 驾驭如此庞大且复杂的企业级代码库的？核心答案在于极其强大的定制化工程脚手架。

以下是小黄人能高效运转的四大核心技术拆解。

1 极致标准化的预热沙盒（Devboxes）

要让全自动 Agent 大规模并行工作，绝不能让它们跑在开发者杂乱的本地笔记本上。Stripe 的解法是直接复用为人类工程师打造的云端开发机（Devboxes）。

●10 秒极速“热启动”：这些 Devbox 是 AWS EC2 实例。Stripe 预先配置并预热了一个资源池，里面已经克隆好了巨大的 Git 仓库，预热了 Bazel 构建缓存和类型检查缓存，甚至启动了持续运行的代码生成服务。因此，只要 10 秒钟，小黄人就能拿到一台随时可以运行测试和修改代码的机器。

●免弹窗的完全提权：为了让小黄人在后台静默运行，它需要无缝执行各种 Shell 命令。因为 Devbox 运行在与生产资源和外部互联网隔离的 QA 环境中，爆炸半径被严格限制，所以系统敢于跳过人类权限确认弹窗，给予小黄人完整的执行自由。

●解决并发冲突：如果用本地环境，并发运行多个 Agent 需要处理复杂的 git worktrees（这在 Stripe 的庞大代码库中无法扩展）。而在云端，工程师可以轻易地同时为 6 个不同的任务启动 6 个分配了独立 Devbox 的小黄人，实现物理级别的完美隔离

2 “蓝图”编排（Blueprints）：将大模型装进确定性的盒子里

常规的 Agent 往往采用开放的循环机制，任由 LLM 自己决定下一步调什么工具，这极易导致出错和浪费 Token。 Stripe 创造性地引入了**“蓝图”（Blueprints）**状态机机制。蓝图将整个工作流视为一张图，将 LLM 的创造力与确定性的系统代码交织在一起：

●确定性节点 vs Agent 节点：在蓝图中，像“实现具体任务”或“修复 CI 失败”是让 LLM 自由发挥的 Agent 节点；但是，像“运行配置好的 Linter”或“推送 Git 变更”则是完全不调用 LLM 的纯代码确定性节点。

●底线兜底：这意味着小黄人无法绕过代码格式化等硬性规范。把大模型“关进受控的盒子里”，不仅极大地节省了 Token，还从系统层面提高了整体可靠性。各团队甚至可以编写自定义的蓝图，来处理复杂的、LLM 辅助的代码库迁移任务

3 极其克制的上下文投喂：规则文件与 Toolshed

面对上亿行代码，如果把所有全局规则都塞给大模型，上下文窗口瞬间就会被撑爆。

●按目录生效的局部规则：Stripe 几乎只使用作用于特定子目录或文件模式的规则文件。他们巧妙地复用了人类工程师为 Cursor 编写的规则格式。这样，工程师在日常开发中沉淀的最佳实践，小黄人（以及 Claude Code）在遍历文件系统时就能直接动态读取并学习。

●MCP 工具棚（Toolshed）：小黄人通过模型上下文协议（MCP）获取网络信息（工单、文档、代码搜索等）。Stripe 建立了一个包含近 500 个内部与 SaaS 工具的中央服务器 Toolshed。但为了防止 Agent 分心，系统每次只会为小黄人精心挑选一个“小巧而高度相关”

4 反馈左移（Shifting Feedback Left）：极速纠错循环

无人值守 Agent 成功的关键在于能否实现自我闭环修正。Stripe 为其构建了多层极速反馈循环：

●5 秒内的本地验证：在小黄人把代码推送到 CI 之前，Devbox 上的后台守护进程会通过启发式算法自动运行相关的 Linter 和类型检查。这个本地节点耗时不到 5 秒，让小黄人在本地极速完成语法纠错。

●克制的 CI 测试轮数：Stripe 的 CI 拥有超过 300 万个测试用例。推送到 CI 后，系统会运行相关测试，并自动应用已有的修复脚本（Autofixes）。如果还有未修复的错误，报错会发回给小黄人。但为了平衡算力成本、时间与边际收益，小黄人最多只被允许进行 1 到 2 次的 CI 循环试错。之后无论成败，都会将其移交给人类处理，防止其陷入昂贵的死循环

给我的启示

基于 Stripe 公开的这些技术细节，我得出了以下几点关于 AI 研发提效的深刻感悟：

1.“对人类工程师有益的基础设施，对 LLM 同样有益” 这是 Stripe 整个小黄人项目最核心的哲学。Stripe 并没有为了做 AI Agent 去凭空造一套新基建，而是直接将 AI 接入了他们多年打磨的 Devbox 环境、Pre-push hooks 和自动化测试管线中。这给所有企业的启示是：AI Agent 的天花板，取决于你现有工程基础设施的底座。如果你的人类工程师本地环境经常崩溃、缺乏单测覆盖率、文档陈旧，那么大模型也一样会在这些泥坑里寸步难行。过去在人类开发者体验（Developer Productivity）上的每一分投资，都会在 AI 时代转化为巨大的复利回报。

2.放弃追求纯粹的“全能 Agent”，用“蓝图”管控不确定性目前业界过度迷恋让一个 Agent 自主解决所有问题。但 Stripe 的蓝图（Blueprints）设计极其务实：能用一行 Bash 脚本或 Linter 稳定解决的问题（如代码格式化、Git 提交流程），就绝对不让 LLM 消耗 Token 去“推理”。在企业级生产环境中，**混合架构（确定性代码逻辑 + 局部受控的 LLM 节点）**才是保证系统高可靠性（SLA）的唯一出路。

3.工程师的日常工作流正在被重塑，在 Stripe，触发小黄人的方式极度符合人体工程学：工程师可以直接在 Slack 的讨论线程里@小黄人，或者在内部的“CI 间歇性失败（Flaky test）”工单中点击一个按钮启动它。我们可以预见，未来的高级工程师将越来越像一个“包工头”：他们在值班（On-call）时并行启动几十个小黄人去处理琐碎的 Bug，自己则专注于审查 PR、设计架构，以及维护和编写能够指导小黄人的局部规则（Cursor rules）。工程师不再逐行敲击代码，而是定义意图并管理基础设施。

参考

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2

Claude on 小盒子的技术分享

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

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 正在扮演“半夜抢修工程师”

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

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

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

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

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

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

OpenAI 开源 Symphony：AI 不再只是写代码，而是开始接管“工作流”

一、Symphony 到底是什么？

二、它为什么比“会写代码”更进一步？

三、每个 issue 一个 workspace：这是 Symphony 最值钱的工程细节

四、WORKFLOW.md 才是灵魂：把 Prompt 升级成 repo 内契约

五、为什么参考实现偏偏选了 Elixir？

六、真正的前提不是更强模型，而是 Harness Engineering

七、它的边界也必须讲清楚

结语

一文讲透 GoF 的 23 种设计模式之工厂方法

一文讲透 GoF 的 23 种设计模式之工厂方法

定义

简单工厂

第一步：定义产品的共同接口和具体实现

第二步：创建“简单工厂”类

第三步：客户端调用

工厂方法模式的结构与角色

Java 代码实现

1. 定义产品（大模型客户端）

2. 定义创建者（核心：业务骨架 + 工厂方法）

3. 定义具体创建者（子类重写工厂方法）

4. 客户端调用

什么时候用?

注意模式的命名

全程0人工写代码！干掉低级码农的不是大模型

全程0人工写代码！干掉低级码农的不是大模型

1 极致标准化的预热沙盒（Devboxes）

2 “蓝图”编排（Blueprints）：将大模型装进确定性的盒子里

3 极其克制的上下文投喂：规则文件与 Toolshed

4 反馈左移（Shifting Feedback Left）：极速纠错循环

给我的启示

参考

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

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

四、主流 SDD 工作流大比拼

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

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

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

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

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