Twitter AI 编程 - 2026-05-26¶
1. 人们在讨论什么¶
1.1 Antigravity CLI 的叙事已从发布转向迁移与上手 🡕¶
最强的一组讨论，不再只是 Google 新产品发布本身，而是如何把现有工作流迁移到 Google 的新承载层上。Google 通过官方开发者账号，把 Antigravity 2.0 作为更大范围开发者更新的一部分来发布；与此同时，信息流很快被长篇教程、迁移串帖，以及针对“Antigravity 是在扩张还是要被放弃”这一困惑的纠偏帖填满。一个重要变化是，AI 编程赛道的竞争看起来不再只是“谁的模型最好”，而更像是“谁的终端工作流能在不打断用户习惯的前提下吸收一次迁移”。
@googledevs 宣布（117 个赞、5 条回复、8,582 次浏览、27 次收藏）称，Google 已发布 Gemini 3.5 Flash 改进版和 Antigravity 2.0，并将后者作为用于构建本地智能体的 CLI。回复对标题本身的兴奋度反而不高，更多聚焦于实际准备度：有人问这款 CLI 能否用于生产环境，而不只是演示；也有人说，本地智能体工具终于打磨到了值得认真测试的程度。
@minchoi 阐述（33 个赞、15 条回复、5,321 次浏览、13 次收藏）把这次发布描述为 Google 在终端场景对 Claude Code、Codex 和 Grok Build 的回应。被引用的 Antigravity 帖子把产品定位说得很明确：同一套承载层、同一批模型，但适配到了命令行，并支持用户自己的快捷键、主题和工作流。回复则进一步点明了真正的市场问题：如果模型差距已经不大，那么承载层和切换成本本身就成了产品。
@RoundtableSpace 发文（63 个赞、7 条回复、47,584 次浏览、55 次收藏）分享了一份时长四小时的 Antigravity 教程，这比又一条发布帖更能说明问题。通常只有当用户准备把工具真正落地使用，而不只是围观时，才会出现这种长度的教程需求。
@LyalinDotCom 提问（29 个赞、15 条回复、3,106 次浏览、4 次收藏）讨论了如何让 Google One 用户更顺畅地从 Gemini CLI 迁移到 Antigravity CLI，并引用了对 ACP 支持、更强无头模式、子智能体和 Gemini CLI 扩展的需求。这是数据集中对迁移缺口最直接的表述。
@ravikiran_dev7 疑惑（59 个赞、46 条回复、1,313 次浏览、3 次收藏）发问说，Antigravity 看起来动静不大，是不是要被关停。回复纠正了这种解读，表示实际情况恰恰相反：Google 正在加码投入，把 Gemini CLI 并入 Antigravity CLI。
讨论洞察： 回复并没有把这次动作视为一次顺滑升级，而是集中在缺失的无头功能、扩展能力对齐、生产级可靠性，以及如果承载层除了换个 UI 外没有额外价值，团队是否真的会切换。
与前一天对比： 5 月 25 日的讨论还集中在 Antigravity 更低价的档位和配额重置；5 月 26 日则深入了一层，转向迁移机制、教程，以及用 Antigravity CLI 替换 Gemini CLI 时的操作摩擦。
1.2 定价、限额和策略控制，对承载层选择的影响已不亚于能力 🡕¶
信息流里依然在谈能力，但越来越多的具体证据来自管理层面：组织级模型规则、被耗尽的会话额度、使用积分截图，以及“20 美元预算到底该买哪款工具”的讨论。AI 编程的对话如今明显已经不只是如何把输出拉满，也包括如何控制支出和模型访问权限。
@lochan_twt 声称（626 个赞、21 条回复、254,432 次浏览、109 次收藏）称，Microsoft 正在取消内部的 Claude Code 许可证，把团队迁回 GitHub Copilot；帖子还把这件事和 Uber 公开谈到的“AI 支出越来越难以证明合理”联系在一起。回复很快分成纠正派和强化派，这一点本身就值得注意：社区争论的不只是承载层偏好，还有成本控制，以及这一变化到底意味着热情下降，还是产品选择变窄。
@DrNassiriAfshar 反驳（4 个赞、1 条回复、2,626 次浏览）称，这并不是禁用 AI，而是出于内部自用验证、成本和安全统一的考虑，转向 Copilot CLI。@trengriffin 认为（1 个赞、341 次浏览）则表示，如果 Opus 仍通过企业 API 用量付费，那么切换承载层未必会减少对 Anthropic 的支出。合在一起看，当天围绕 Microsoft 的讨论，与其说形成了一套已被证实的事实链条，不如说更像是围绕承载层经济学的相互争议。
@GHchangelog 报道（5 个赞、983 次浏览、3 次收藏）称，GitHub Copilot 的模型规则已进入面向企业所有者的公开预览。相关 GitHub 更新日志 表示，企业现在可以把特定 Copilot 模型分配给特定组织，而不再只能依赖企业范围内的单一默认模型，这让成本与合规控制直接进入管理端界面。
@HarshithLucky3 报道（48 个赞、5 条回复、2,286 次浏览、3 次收藏）称，即便只是一个简单的前端任务，Codex 的限额也掉得太快。回复随后转向套餐管理策略：有人说 Grok Build 处理同样的工作量时没有被限流，另一人则明确希望能有一款“subscription bench”，用来长期衡量不同订阅的使用表现。
@KaiXCreator 提问（28 个赞、44 条回复、1,956 次浏览）在 Claude、Codex、Cursor、Antigravity 和 GitHub Copilot 之间发问：20 美元预算花在哪款工具上最值。最高赞回复否定了“只能选一个赢家”的框架，转而描述了一套混合栈：OpenCode、DeepSeek、Claude、ChatGPT、Gemini 和 Manus 各自负责不同任务。
讨论洞察： 回复持续反对对单一工具的忠诚，更倾向于组合使用、明确分析瓶颈，并依赖管理端控制，而不是默认某一个高级承载层就该包办所有任务。
与前一天对比： 5 月 25 日已经出现了配额痛点和对高级模型倍率的焦虑；5 月 26 日则出现了更硬的治理证据：Copilot 模型规则、被耗尽的 Codex 会话，以及连业余用户的预算讨论都被表述为资源分配问题。
1.3 模型之上的持久层，正以提示词、记忆、自动化和遥测的形式落地 🡕¶
最可信的构建者活动，并不是直接挑战 Claude Code、Codex、Copilot 或 Antigravity，而是在它们之外包上一层可复用提示词库、持久化 Markdown 记忆、NotebookLM 自动化和端点遥测。这是一个很强的信号：市场认为承载层已经稳定到足以继续叠加，下一层杠杆点在其上方。
@_vmlops 强调（11 个赞、2 条回复、541 次浏览、4 次收藏）提到 OpenAI 为 Codex 提供的即用型提示词库，并认为真正有价值的不是单行提示词片段，而是项目工作流和自动化——这些东西也可以迁移到 Claude Code、Cursor 和其他智能体上。一条回复把这个观点说得更尖锐：只有当提示词库像一份团队可以按自身技术栈改造的检查清单时，它才真正有意义。
@awakecoding 提问（6 个赞、2 条回复、593 次浏览）呼吁为 Copilot 的审查智能体单独提供一份自定义指令文件，而不是和普通 Copilot 工作共用同一套指令。相关 GitHub Docs 页面 证实，Copilot 已经支持仓库级指令、路径级指令和 AGENTS.md 文件，因此缺少一个明确区分“仅用于审查”的界面就显得更突出了。
@PawelHuryn 认为（1 个赞、144 次浏览、2 次收藏）称，可学习层不只是一个 skill 文件：数据、假设、规则和流程应该在 Claude Code、Codex 和 Cowork 之间一起演化。相关 PM Brain 仓库 则把这变成了一个产品：一个面向产品经理、基于 Markdown 的第二大脑，把假设、决策、利益相关者和摄取来的材料保存在本地，而不是藏在不可见的记忆层里。
@GithubProjects 分享（9 个赞、630 次浏览、6 次收藏）notebooklm-py，仓库 README 表示，它通过 Python、CLI 和智能体集成暴露 NotebookLM 的能力，供 Claude Code、Codex 和 OpenClaw 使用，并提供网页界面不具备的研究自动化、产物下载和导出路径。
@jqdsouza 表示（5 个赞、3 条回复、115 次浏览）称，在 Google 宣布迁移后，Agent Beacon 已经加入对 Antigravity CLI 的支持。Agent Beacon 仓库 把它描述为一层本地遥测：它可以捕获 Claude Code、Codex CLI、Cursor、Copilot CLI、Antigravity CLI 以及其他承载层中的提示词、工具使用和文件编辑，再把标准化事件转发到本地仪表板或 SIEM 流水线。
@MichaelGannotti 认为（8 个赞、5 条回复、160 次浏览）称，多智能体编程的真正瓶颈不是 Git 机制，而是语义一致性；而在并发智能体之间共享世界模型的最佳现有模式，是 AGENTS.md 文件、skills 和结构化记忆。
讨论洞察： 实际讨论反复强调的是一致性，而不是巧思。提示词库需要可适配，记忆需要本地化且可检查，多智能体系统需要共享状态模型，而不是追逐基准榜单。
与前一天对比： 5 月 25 日强调规则、skills 和记忆正在成为新优势；5 月 26 日则显示这些想法已经以提示词包、Markdown 大脑、NotebookLM 桥接器和跨承载层遥测的形式产品化。
2. 什么让人感到沮丧¶
迁移说明仍然落后于发布宣传¶
严重程度：高。@LyalinDotCom 提问（29 个赞、15 条回复、3,106 次浏览、4 次收藏）讨论了 Google 需要修补什么，Gemini CLI 用户才会真正迁移到 Antigravity CLI；被引用的串帖直接点名了缺失项：ACP 支持、更强的无头模式、子智能体和扩展兼容性。@ravikiran_dev7 展示（59 个赞、46 条回复、1,313 次浏览、3 次收藏）则显示，发布后的沉寂会多快演变成“是不是要关停”的传言，而 @googledevs 下的回复问的也不是演示效果，而是这款 CLI 是否已经具备生产可用性。用户当前的应对模式很明显：他们转向长教程、迁移串帖和社区纠偏，因为迁移路径仍然解释不足。这个方向值得做产品，因为摩擦来自高意图的现有用户，而不是随手看热闹的人。
限额和积分管理会在任务完成前打断工作¶
严重程度：高。@HarshithLucky3 展示（48 个赞、5 条回复、2,286 次浏览、3 次收藏）称，一个简单的前端任务也可能比预期更快耗尽 Codex 限额，回复随即转向谨慎用套餐、改用其他承载层，以及对订阅基准产品的需求。@KaiXCreator 曝光（28 个赞、44 条回复、1,956 次浏览）则从购买者视角提出了同一个问题：20 美元预算到底该买哪款工具。就连 @BlaineGrant85 包括 这样一条低曝光抱怨（1 个赞、1 条回复、15 次浏览、1 次收藏）里，也能看到当前会话额度已全部用尽的截图、4.11 美元的月度花费计量、45 美元的批量积分购买选项，以及在此前 20 美元账单之后剩余 15.89 美元的余额。人们目前的应对方式是把任务分散到多个订阅上、额外购买积分，或者针对特定工作负载切换承载层。这个方向值得做，因为这种痛点会持续出现，而且会直接打断任务。
多智能体编程仍缺少可靠的协调层¶
严重程度：中。@MichaelGannotti 认为（8 个赞、5 条回复、160 次浏览）称，难点不在并行执行本身，而在于多个智能体同时触碰同一代码库时如何保持语义一致。他举的例子都很具体：智能体各自做出在语义上互相冲突的修改；Git 能解决合并，却解决不了世界模型漂移；上下文窗口则成了协调上限。如今的应对模式是 AGENTS.md 文件、skills、结构化记忆，以及非常明确的任务分道。这个方向值得做，因为它指向的是比一次性模型回归更深的基础设施缺口。
3. 人们希望存在什么¶
给审查智能体单独的指令文件，而不是共用一套指令界面¶
@awakecoding 提问（6 个赞、2 条回复、593 次浏览）希望为 Copilot 审查指令提供专用文件，而不是和普通 Copilot 工作复用同一套指令界面。GitHub 文档已经覆盖了仓库级自定义指令、路径级指令和 AGENTS.md 文件，因此剩下的诉求不是泛泛的可定制性，而是让审查行为拥有更清晰的作用域隔离。机会：直接。
更好的配额预测和跨套餐使用基准¶
最强烈的未满足需求，是一种能在会话结束前告诉人们任务成本的监测能力。@HarshithLucky3 下方要求“subscription bench”的回复，以及 @KaiXCreator 下的预算选购讨论，都指向同一缺口：用户想要一种中立方式，比较不同套餐和承载层在现实任务中的单位美元产出，而不只是看营销说法。机会：直接。
能保留扩展、无头模式和习惯的迁移套件¶
@LyalinDotCom 下被引用的迁移串帖，明确点出了从 Gemini CLI 交接到 Antigravity CLI 时缺失的无头支持、扩展、ACP 和子智能体。人们不是想看又一支发布视频，而是想要一种能把既有工作流尽量无损带到新承载层上的方法。机会：直接且具竞争性。
移动优先的 vibe coding 工作流¶
@aditiitwt 提问（17 个赞、18 条回复、188 次浏览）质问，为什么 vibe coding 的讨论最后总是落在 Web 应用，而不是 Android 或 iOS 构建上。这个帖子体量不大，但互动与浏览的比例足够高，足以把它看成真实挫败，而不是玩笑。这里看起来更像是对更好移动端脚手架、测试闭环和部署支持的实际需求，而不只是情绪表达。机会：直接，但仍在萌芽期。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Antigravity CLI / Antigravity 2.0 | 编程智能体 / CLI | (+/-) | 终端原生承载层、同模型连续性强、教程需求旺盛，并有明确的 Gemini CLI 迁移路径 | 无头模式缺口、扩展兼容性疑问和生产可用性质疑持续出现 |
| GitHub Copilot / Copilot CLI | 编程助手 / 承载层 | (+/-) | 企业模型规则、广泛部署面、可复用工作流案例多 | 面向审查的定制仍显不足，部分采用也被表述为治理驱动而非偏好驱动 |
| Claude Code | 编程智能体 | (+/-) | 在能力、记忆层和工作流质量的讨论里仍是参照系 | 预算与治理争论持续围绕它展开，尤其是在企业场景 |
| OpenAI Codex | 编程智能体 | (+/-) | 可复用提示词库、社区势头强，也是购买讨论中的重要参照 | 用户反映限额消耗快于预期，需要谨慎管理套餐 |
| notebooklm-py + NotebookLM | 研究自动化 / 知识层 | (+) | 把 NotebookLM 变成兼容 Python、CLI 和智能体的研究流水线，并补上网页界面没有的导出能力 | 仓库明确提示其依赖未文档化的 Google API，可能失效或被限流 |
| PM Brain | 记忆 / 工作流层 | (+) | 以本地 Markdown 记忆保存多个承载层共享的假设、决策和利益相关者信息 | 仍是早期产品，需要有意识的结构化和人工维护 |
| Agent Beacon | 安全 / 遥测 | (+) | 跨承载层端点可见性，支持本地仪表板和 SIEM 转发，并已适配 Antigravity CLI | 更偏向安全和 IT 运维，而非个人日常生产力 |
总体来看，口碑最好的是那些能让承载层更“耐久”的工具：记忆层、遥测，或者能够跨模型变化继续工作的研究自动化。一旦工具迫使用户承担迁移工作、处理隐性的限额管理，或面对不清晰的审查行为，满意度就会下降。最主要的迁移模式并不是从工具 A 干净利落地切到工具 B，而是多栖：人们同时保留多个承载层，把它们分配给不同任务，并且越来越多地按照控制界面和策略旋钮来评判它们，而不只是比较模型质量。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| notebooklm-py | teng-lin | 通过 Python、CLI 和智能体集成暴露 NotebookLM 能力 | NotebookLM 的网页界面把研究者和智能体想以编程方式使用的自动化与导出路径藏了起来 | Python、CLI、未文档化的 NotebookLM API、Claude Code、Codex、OpenClaw | 已发布 | 仓库 |
| PM Brain | @PawelHuryn | 为产品工作构建本地 Markdown 第二大脑 | 团队需要持久、可检查的决策、假设和利益相关者上下文，而不是短暂的会话记忆 | Markdown、Claude Code skill、本地文件、配套 skill 模块 | Beta | 仓库 |
| Agent Beacon | Asymptote Labs | 捕获本地智能体承载层中的提示词、工具使用和文件编辑 | 随着智能体工作流扩散到 CLI 和 IDE，安全与 IT 团队需要一致的端点可见性 | Go、本地仪表板、JSONL 遥测、SIEM 集成、hook 适配器 | 已发布 | 仓库 |
@GithubProjects 分享（9 个赞、630 次浏览、6 次收藏）把 notebooklm-py 介绍为 NotebookLM 接入编程智能体工作流的桥梁。仓库描述非常具体：批量下载、音频和视频产物、测验、抽认卡、思维导图和研究智能体，都可以通过 Python、CLI 或智能体集成来使用。这是今天最清楚的例子，说明 AI 编程构建者正在扩展相邻的知识工具，而不是再造一个通用代码聊天产品。
@PawelHuryn 写道（1 个赞、144 次浏览、2 次收藏）称，可学习层的范围大于单个 skill 文件；而 PM Brain 仓库把这进一步明确成了产品论点：用 Markdown 文件夹保存持久上下文、来源标签和重复性的清扫循环，而不是依赖看不见的记忆技巧。这一点之所以重要，是因为它让“记忆层”变得可检查、可迁移，能在 Claude Code、Codex 和 Cowork 之间携带。
@jqdsouza 表示（5 个赞、3 条回复、115 次浏览）称，Agent Beacon 已经加入对 Antigravity CLI 的支持。这体现出一种重要的构建模式：不是取代承载层，而是在承载层不断变化时，确保安全和 IT 团队的可观测性界面保持稳定。
三个项目反复呈现出同一种构建模式：用持久上下文、研究自动化或运维遥测包裹现有智能体生态，而不是正面去赢下智能体竞赛。
6. 新动态与值得关注的内容¶
搜索关注度看起来仍集中在重度用户身上¶
@RealNickMugalli 认为（2 个赞、2 次转发、826 次浏览）称，Opus 4.5 发布后，Claude Code 的搜索热度大约上升了 100 倍，而 Codex 随后跟上，但存在滞后。附图并不是广义劳动力市场的衡量指标，而且他还明确把它和“所有劳动者日常 AI 使用率的自报数据（明显更低）”做了对比。因此，这更适合作为一个方向性信号：AI 编程的使用强度看起来仍集中在相对少数的一批重度用户身上。
安全工具几乎在承载层变动发生的同时作出反应¶
@jqdsouza 指出（5 个赞、3 条回复、115 次浏览）称，在 Google 宣布迁移后，客户已经开始询问 Agent Beacon 是否支持 Antigravity CLI，而最新版本的答案是支持。这一点很重要，因为它说明企业运维对新承载层的适应，时间尺度几乎与构建者和重度用户同步。
7. 机会在哪里¶
[+++] 面向多承载层团队的迁移、配额预测和策略控制 ——第 1 节显示，Gemini CLI 到 Antigravity CLI 的迁移已经演变成文档和能力对齐工作；第 2 节则显示，Codex 限额、使用积分和 Copilot 模型规则已经进入日常决策。最强的机会，是做一层控制层，帮助团队同时迁移、计量和治理多个承载层。
[++] 持久工作流记忆与面向审查的专用指令层 ——第 1.3 节、第 3 节和第 5 节都指向同一缺口：人们想要可复用提示词、范围清晰的审查行为，以及能跨越模型和承载层变化而留存、且可检查的长期上下文。
[++] 多智能体编程系统的协调工具 ——Michael Gannotti 关于编排的论点，以及 AGENTS.md 式协调方式的兴起，都表明在共享世界模型、语义冲突检测和智能体间协调界面上存在中等强度机会。
[+] 移动原生的 vibe coding 技术栈 ——证据还较薄，但 Android 和 iOS 方向的缺口已经足够清晰，可以视作一个正在浮现的机会：更好的移动端脚手架、测试闭环和部署工具。
8. 要点¶
- Antigravity 的竞争叙事现在讲的是迁移，而不只是发布日的新鲜感。 Google 的官方更新很快被教程、迁移串帖，以及 Gemini CLI 用户提出的能力对齐问题盖过。（来源）
- 预算与治理界面正在变成日常产品界面。 Codex 限额截图、20 美元工具选购讨论和 Copilot 模型规则，都说明用户在更明确地管理支出和模型访问。（来源）
- 最强的新产品是在现有智能体外再包一层，而不是取代它们。 notebooklm-py、PM Brain 和 Agent Beacon 都是在现有承载层之外补上自动化、记忆或遥测。（来源）
- 可复用指令和持久上下文仍然建设不足。 对 Copilot 审查指令的需求、PM Brain，以及围绕 Codex 提示词库的讨论，都指向对可限定范围、可复用、可检查上下文的需求。（来源）
- 一些重要缺口仍然是非常基础的工作流缺口。 信息流里依然没有对移动优先 vibe coding 给出有说服力的答案，也没有提供除手动分道之外的多智能体语义协调方案。（来源）