Twitter AI 编程 - 2026-06-09¶
1. 人们在讨论什么¶
1.1 Claude Fable 5 将 AI 编程讨论重新拉回前沿模型经济学 🡕¶
6 月 9 日，AI 编程讨论从工作流文件和控制平面，迅速回到发布日的一个核心问题：Claude Fable 5 对长周期编程究竟带来了什么变化，以及随之而来的政策与计费权衡是什么。三条高信号内容支撑了这一主题。
@kimmonismus 辩称（771 个赞、46 条回复、104,549 次浏览、179 个书签）称，Fable 5 是软件工程领域的一次代际跃迁，并附上基准测试幻灯片，让这一判断不只是口头表态。最有价值的一页把智能体编程与知识工作得分并列展示：Claude Fable 5 在 SWE-Bench Pro 和 FrontierCode（Diamond）上的成绩分别为 80.3% 和 29.3%，Claude Opus 4.8 为 69.2% 和 13.4%，GPT-5.5 为 58.6% 和 5.7%。但一条回复立刻收窄了乐观情绪：有实践者表示，在较小规模使用中，暂时还没有感到显著提升；作者则回应称，当晚还需要做真实测试。因此，即便是偏多的讨论，也把代码库级别的验证视为尚未完成的工作。
@github 宣布（381 个赞、43 条回复、49,496 次浏览、56 个书签）称，Claude Fable 5 正在 GitHub Copilot 中逐步推出，用于长周期自主编程和知识工作任务。关联的 GitHub 更新日志 补充了推文本身仅略微提及的实际约束：此次上线是渐进式推出；该模型可在 VS Code、Copilot CLI、Copilot app、github.com、移动端、Xcode 和 JetBrains 中使用；在 Usage Based Billing 下按供应商目录价计费；并且它是 Copilot 中唯一一个要求为 Anthropic 安全分类器保留最多 30 天数据的 Claude 模型。
@Azure 表示（271 个赞、12 条回复、13,509 次浏览、34 个书签）称，同一模型也在当天登陆了 Microsoft Foundry 和 GitHub Copilot。最有代表性的回复不是庆祝，而是运维层面的抱怨：有用户回应说 Azure 里仍显示配额不可用，于是发布消息立刻变成了访问问题。
讨论洞察： 真正的分歧并不是“Fable 5 好”还是“Fable 5 坏”，而是“基准测试上的跃升有多少能在真实代码库工作中保留下来”，以及“数据保留和按量计费会如何影响信任与成本”。这些保留意见在首波回复里就出现了。
与前一天相比： 6 月 8 日的讨论主要围绕可复用技能、例程和控制平面；到 6 月 9 日，注意力转向了一次单一模型发布，以及开发者究竟能在什么地方、以什么政策和价格使用它。
1.2 GitHub Copilot App 开始更像控制中心，而不是侧边助手 🡕¶
另一个强势话题聚焦于 GitHub 围绕智能体构建的产品界面。Copilot App 不再被描述成“又一个聊天入口”，而更像是一个工作环境：并行会话、画布和持久记忆让智能体输出变得可检查。四条高信号内容支撑了这一主题。
@kdaigle 表示（30 个赞、7 条回复、6,038 次浏览、6 个书签）表示，她每天早上都会用 GitHub Copilot App 来处理“自动化任务以及围绕工作本身的工作”，晚上再为项目编程。关联的 GitHub Copilot App 发布文章 解释了这为什么重要：该应用通过统一的 My Work 视图汇总活跃会话、issues、pull requests 和后台自动化；每个会话都运行在独立的 git worktree 中；Agent Merge 会推动 pull request 完成审查、检查和合并；云端与本地沙盒则让同一套系统能检查、测试和迭代，而不只是给出代码建议。
@burkeholland 展示（37 个赞、1 条回复、1,906 次浏览、12 个书签）展示了该应用的新画布功能：它会生成一个实时界面，显示项目 worktree 以及它们与 main 分支的偏离程度。这让“画布”不再只是发布文案里的抽象概念，而成了一个用于检查智能体所管理仓库状态的具体视图。
@code_kartik 解释（5 个赞、386 次浏览、8 个书签）介绍了 GitHub Copilot 的 memory：它是一个绑定精确文件与行号引用的事实存储，会在当前分支上重新读取，并在代码变化时重写。附图把机制讲清楚了：store_memory 将结构化对象写入 Memory API/DB；读取时会根据当前分支校验引用；引用的生产结果是 pull request 合并率从 83% 提升到 90%。
@_Evan_Boyle 发布（86 个赞、8 条回复、5,391 次浏览、36 个书签）表示，他正在招聘产品和 AI 工程师加入 GitHub Copilot App 团队，并要求候选人拿出作品证明。这是一个有价值的构建者信号，因为它表明 GitHub 正把这一界面当作长期产品投入，而非一次性预览。
讨论洞察： 6 月 9 日，关于 Copilot App 最有力的证据是“可检查性”：看得见的 worktree、带引用的 memory，以及暴露实时状态的画布。信息流奖励的是机制，而不是口号。
与前一天相比： 6 月 8 日，Antigravity 承担了“工作区叙事”；到 6 月 9 日，GitHub Copilot App 也获得了类似“控制中心”的定位，但在 worktree、memory 和智能体审查上给出了更明确的证据。
1.3 Antigravity、Codex、OpenCode 和路由面板之间的访问仍然高度碎片化 🡒¶
即便 Fable 5 和 Copilot App 主导了当天讨论，市场在访问层面看起来仍然十分碎片化。人们仍在追问 Google 对应 Codex 或 Claude Code 的产品是什么，仍在手动拼接一键移动入口，也仍在尝试统一路由面板以避免频繁切换工具。五条保留内容支撑了这一主题。
@petergyang 询问（84 个赞、31 条回复、11,004 次浏览、9 个书签）询问，Google 真正对应 Codex 和 Claude Code 的产品到底是什么，以及 Antigravity 是否应该归入 Gemini。最有价值的回复并不是夸某个模型，而是指出：Antigravity 是 Google 最接近的东西，但更像是一个 IDE 方向的押注；相比之下，Claude Code 仍然在 harness 上占优——包括它如何规划、如何串联工具、以及如何从失败命令中恢复。
@Google 表示（70 个赞、2 条回复、5,838 次浏览、8 个书签）称，Search 可以结合 Antigravity 和 Gemini 3.5 Flash 构建定制生成式 UI 与交互式可视化；同一条讨论中的回复还说，Search 也可以创建信息智能体，监控主题并发送详细更新。另有 Ars Technica 报道称，NotebookLM 现在已有自己的云电脑，内嵌 Antigravity 和 100 多种软件技能，这让 Antigravity 更像一个可处理重复任务的运行时，而不只是一次性演示。
@dabit3 展示（22 个赞、2 条回复、738 次浏览、16 个书签）将 ACP 描述为一个统一视窗：通过单一选择器即可调度 Codex、Claude、OpenCode、Devin、Gemini 以及大约 40 个其他智能体。这是一个强烈的构建者信号，因为它暗示最终胜出的产品类别，可能是位于智能体之上的路由界面，而不是再多一个智能体品牌。
@thdxr 询问（67 个赞、23 条回复、11,685 次浏览、3 个书签）请在小窗口使用 OpenCode 的用户上传截图，如果感觉空间利用不佳。回复非常具体：即便在更大的屏幕上，复杂问题也会占去过多垂直空间，导致阅读空间不足；用户希望问题面板可以最小化，侧边栏也能更容易隐藏。
@petergyang 展示（35 个赞、15 条回复、3,144 次浏览、14 个书签）分享了一个九步 Shortcuts 配方，把 Codex 放到 iPhone 主屏幕上，因为官方的一键入口目前还不存在。截图让这一绕路方案显得真实，而不只是嘴上说说。
讨论洞察： 当人们问“哪个智能体最好”时，很多时候真正问的是“哪个访问层最好”：最好的工作界面、最好的路由器、最顺手的移动入口，或者最可靠的 harness 行为。
与前一天相比： 6 月 8 日已经把 Antigravity 视为一个访问层；到 6 月 9 日，Antigravity、Codex 的移动端绕路方案、OpenCode 的布局抱怨，以及 ACP 的路由方式被放进同一场讨论，碎片化因此更加明显。
2. 什么让人沮丧¶
智能体工作一旦可计量，账单就变得难以预测¶
严重程度：高。@DavidOndrej1 辩称（37 个赞、8 条回复、3,062 次浏览、16 个书签）称，GitHub Copilot 从 6 月 1 日起转向 AI Credits 后，智能体使用更像是一场账单冲击，而不再是简单订阅。他随后发布的 帖子（8 个赞、2 条回复、1,241 次浏览、3 个书签）清楚概括了这一产品变化：订阅现在买到的是一个月度额度池，agent mode、chat、多步运行和工具调用一旦超出额度池就会按量计费。附图通过对比“premium requests counted per request”和“AI Credits based on model usage”，直观展示了计费模式的变化。GitHub 自己的 Claude Fable 5 更新日志 也强化了这一点，明确写明 Fable 5 在 Usage Based Billing 下按供应商目录价计费。这个问题值得投入，因为用户已经开始寻找补贴、免费资格或替代路由，而不是相信默认账单。
访问问题仍然出现在“日常使用”本该最顺手的地方¶
严重程度：中高。@petergyang 需要（35 个赞、15 条回复、3,144 次浏览、14 个书签）显示，要从 iPhone 主屏幕启动 Codex，竟然要走九步 Shortcuts；回复立刻追问，为什么一个每天都要用的工具，还需要这么繁琐的仪式。@Azure 宣布（271 个赞、12 条回复、13,509 次浏览、34 个书签）讨论 Fable 5 在 Foundry 和 Copilot 中上线，但最醒目的回复却是在抱怨 Azure 里的 Claude 模型仍然显示配额不可用。@thdxr 整理（67 个赞、23 条回复、11,685 次浏览、3 个书签）则是 OpenCode 的布局抱怨：用户想要更多垂直空间，减少侧边栏带来的摩擦。这个问题值得投入，因为痛点发生在入口和日常操作层，而不是基准测试层。
信任与策略设置如今已成为产品体验的一部分¶
严重程度：中。GitHub 的 Fable 5 发布公告（381 个赞、43 条回复、49,496 次浏览、56 个书签）让政策本身成为发布日新闻，因为关联的更新日志写明，Fable 5 需要为 Anthropic 安全分类器保留最多 30 天的提示词和输出，而 Copilot 中其他 Claude 模型仍然是零数据保留。另一类信任问题则出现在 @code_kartik 帖子（5 个赞、386 次浏览、8 个书签）中：卖点在于 memory 锚定到文件与行号引用上，并会针对当前分支重新校验。这个问题值得投入，因为人们评估长周期智能体时，看重的不只是它们能生成多少代码，也看重是否能够解释、验证和治理它们。
3. 人们希望有什么¶
运行前的成本预测与预算感知路由¶
最强烈的需求并不只是“更便宜的模型”，而是能够在智能体运行前知道这次会花多少钱、额度池还剩多少余量，以及任务何时该被路由到更便宜的模型或另一个界面。@DavidOndrej1 直接点出了账单波动，而 GitHub 关于 Fable 5 的更新日志也从官方层面确认了按供应商定价的按量计费。这是实际需求，不是情绪宣泄。机会：直接。
一等公民级的跨设备入口¶
@petergyang 之所以亲手把 Codex 做成 iPhone 一键快捷方式，是因为官方入口缺位。与此同时，GitHub Copilot App 的发布帖描述了云端与本地沙盒，意在让会话可以随处继续。需求很明显：如果这些工具正成为全天候工作界面，它们就需要同样出色的桌面、终端和移动入口。机会：直接。
一个控制界面管理多个智能体¶
@dabit3 展示了 ACP 如何用一个选择器覆盖多个智能体，@petergyang 直接追问 Google 对应 Codex 或 Claude Code 的产品是什么，而 GitHub Copilot App 的定位本身也是一种“控制中心”论述。这里的诉求是操作层面的：在不丢失上下文的前提下，在一个地方路由、检查和比较多个智能体的工作。机会：竞争性。
面向长时运行智能体的可验证记忆与安全控制¶
当天最可信的两类信任叙事都高度依赖机制：GitHub 对 Fable 5 数据保留的披露，以及 Copilot 那种绑定文件与行号引用的 memory。开发者似乎愿意采用长周期智能体，但他们希望安全与记忆行为是可审计的，而不是“靠魔法实现”。机会：直接。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Fable 5 | 前沿模型 | (+/-) | 在长周期编程上有很强的公开基准叙事，已广泛进入 Copilot；GitHub 内部工作流还声称其工具调用和 token 使用更低 | 一上线就引发了数据保留政策和供应商定价问题；回复中对真实世界收益仍有争论 |
| GitHub Copilot App | 智能体原生桌面端 | (+) | My Work 仪表板、git worktree 隔离、Agent Merge、画布和沙盒执行，让多智能体工作变得可检查 | 仍处于技术预览期，最有力证据主要来自发布材料和早期产品演示，而不是长期使用报告 |
| GitHub Copilot / Copilot CLI | 编程助手 / 智能体运行时 | (+/-) | 覆盖 IDE、CLI、app、web 和移动端，界面触点广；memory 和审查功能也越来越明确 | AI Credits 和按量计费让重度智能体使用的支出更难预测 |
| Google Antigravity | 智能体工作区 / 运行时 | (+/-) | 正扩展到 Search、NotebookLM、SDK、CLI 和信息智能体工作流 | 用户仍在质疑它是否足够直观、足够完整，能否成为 Google 真正对应 Claude Code / Codex 的产品 |
| OpenAI Codex | 编程智能体 | (+/-) | 日常使用需求强，作为编程工具品牌辨识度高 | 移动端访问仍需笨拙绕路；人们也持续把它与其他界面搭配使用 |
| OpenCode | 开源智能体 UI | (+/-) | 迭代活跃，用户也愿意提供具体界面反馈 | 小窗口布局问题和侧边栏摩擦说明产品仍需收紧 UX |
| ACP | 多智能体路由器 | (+) | 一个选择器覆盖多个智能体后端，降低不同工具品牌之间的切换成本 | 当天的公开证据仍以产品演示为主，而不是深入技术文档 |
| Azure AI Foundry | 模型平台 | (+/-) | 与 Copilot 一样，是新前沿模型的快速落地点 | 回复里立刻就出现了配额可用性的抱怨 |
整体情绪偏务实。人们对更强的工作界面和更强的模型持积极态度，但始终通过计费、政策、访问和编排来评估它们。常见的绕路方式是把工具叠起来用：用 Copilot App 做控制中心，在已有使用习惯和信任的地方用 Codex，在 Google 已经铺好路径的地方用 Antigravity，在一个选择器很重要的地方用 ACP，在看重开放性和快速迭代的地方用 OpenCode。竞争正在从原始模型能力上移到路由、工作可见性和信任控制。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| GitHub Copilot App | GitHub | 面向智能体的桌面控制中心，用于管理会话、画布、审查、自动化和合并 | 多智能体开发工作流原本分散在不同窗口、仓库和聊天线程里 | My Work 视图、git worktrees、Agent Merge、画布、本地/云端沙盒、与 CLI/云端智能体共享运行时 | Beta | 功能页面, 发布文章, 推文 |
| ACP | @dabit3 | 为 Codex、Claude、OpenCode、Devin、Gemini 及数十个其他智能体提供统一视窗 | 开发者不想每次更换智能体后端都切换 UI | 统一选择器、多智能体桌面界面、Devin Desktop 演示路径 | Beta | 帖子 |
| 使用 Antigravity 的 Search 信息智能体 | 在 Search 和 NotebookLM 中构建小应用、追踪器和监控更新 | 持续研究和重复任务仍需要太多分散工具与手动检查 | Search、Antigravity、Gemini 3.5 Flash、NotebookLM 云电脑、100+ 软件技能 | Beta | 帖子, Ars 报道 | |
| html-video | @GithubProjects | 本地优先工作室，可用纯文本指令将 HTML、CSS 和数据转成 MP4 | 演示和制品生成往往仍需要单独的渲染供应商或手工视频流程 | 本地优先渲染器、14 个智能体后端、21 个模板、可选 AI 配乐、Apache-2.0 | Shipped | 帖子 |
Copilot App 之所以重要，是因为 GitHub 自己的描述终于与重度用户讨论智能体工作时的表述对上了：多个隔离会话同时推进，有一个地方可以统一检查，并通过审查和合并完成明确交接。Burke Holland 的画布演示把这一点讲得更具体：它展示的是一个用于查看 worktree 分歧的实时界面，而不是又一次泛泛地说“AI 可以构建应用”。
html-video 的特别之处则在于另一点：它把媒体输出当作编程智能体可以基于 HTML 和数据在本地生成的制品。附图强调了产品形态——21 个模板、14 个后端、无需 API key——因此它的独特性不在于抽象的“AI 视频”，而在于“留在智能体工具链内部的制品生成”。
反复出现的构建模式已经很清楚：人们不只是在发布新的助手，也在围绕用户已经偏好的智能体构建控制界面、重复任务运行时和制品层。
6. 新动态与值得关注的内容¶
GitHub 让 Copilot 的 memory 机制变得可理解¶
@code_kartik 总结（5 个赞、386 次浏览、8 个书签）介绍了 Copilot 的 memory：事实会和文件、行号引用一起存储，并在复用前针对当前分支重新验证。附带的架构图把这件事从口号变成了机制展示：它呈现了读取时的校验路径，并给出了生产环境中 pull request 合并率从 83% 提升到 90% 的结果。
Fable 5 的数据保留政策成了发布叙事的一部分¶
GitHub 的 发布文章（381 个赞、43 条回复、49,496 次浏览、56 个书签）及其关联更新日志明确写出了政策差异：Fable 5 需要为安全分类器保留最多 30 天数据，而 Copilot 中其他 Claude 模型仍然是零数据保留。这让治理本身也成了用户在第一天就必须评估的产品差异点。
7. 机会在哪里¶
[+++] 支出感知的智能体路由 —— AI Credits 调整、Fable 5 按供应商定价的计费方式，以及围绕订阅比价的讨论，都指向同一个缺口：开发者需要在点击“运行”前获得成本预估、预算上限和自动路由能力。
[++] 跨设备智能体工作区 —— Copilot App 的发布描述了一个持久化桌面控制中心，但 Codex 仍要靠九步 iPhone 快捷方式绕路，才能像日常移动工具一样使用。真正一致的桌面、终端和移动体验仍有空间。
[++] 可验证的长周期智能体 —— Fable 5 的数据保留披露，以及 Copilot 的引用校验 memory 架构图，都表明信任功能正在成为一等产品要求。团队想要明确的数据保留规则、可追溯证据链，以及能感知分支的 memory 验证。
[+] 位于模型之上的路由层 —— ACP 的多智能体选择器，以及持续出现的“Google 对应产品是什么”讨论，都说明围绕统一工作流整合多个智能体的控制界面，市场正在形成。
8. 要点¶
- 模型发布如今不仅看原始基准，也看政策和计费。 Fable 5 的编程性能幻灯片吸引了注意力，但 GitHub 的数据保留和按量计费条款也同样迅速塑造了讨论走向。（基准测试讨论串, GitHub 更新日志）
- GitHub 正试图掌控围绕智能体工作的控制平面，而不只是模型选择器。 Copilot App 的发布、画布演示和 memory 架构说明，都指向可检查的多智能体工作流，而不是轻量聊天助手。（Copilot App 发布文章, canvas 演示, 记忆讨论串）
- 访问层仍然碎片化到足以催生围绕它的新产品。 ACP 的统一选择器、Antigravity 向 Search 和 NotebookLM 的扩展，以及 Codex 的主屏幕绕路方案，都说明市场需要位于单一模型之上的、更干净的路由与入口。（ACP 帖子, Google 帖子, Codex 快捷方式讨论串）
- 构建者的精力正在转向控制界面和制品层。 当天最有特点、最像已交付产品的，并不是又一个聊天机器人，而是多智能体桌面控制中心、重复性信息智能体，以及本地 HTML 转视频流水线。（GitHub Copilot App, Google/NotebookLM 报道, html-video 帖子）