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