Twitter AI Coding - 2026-06-03¶
1. 人们在讨论什么¶
1.1 智能体管理器变成了集成枢纽，而不再只是独立 IDE 功能 🡕¶
最强的 Antigravity 信号已经不再是“有一个智能体优先的 UI”。而是管理器界面现在必须协调多种模型、多种界面和外部工具。三条留存条目支持了这一主题。
@kevinhou22 解释了（255 次点赞、45 条回复、14,884 次浏览、97 次收藏）为什么 Antigravity 把 IDE 和 Agent Manager 拆开。该讨论串称，这个类别已经从自动补全走到聊天、走到智能体、再走到多智能体，如今用户管理的是分布在 IDE、Agent Manager、SDK 和 CLI 里的“几十个、甚至上百个智能体”，而不是待在某一个编辑器里。
@FlutterDev 分享（70 次点赞、3 条回复、3,019 次浏览）了一场关于用 Antigravity 和 Flutter 构建应用的 Google I/O 回放。公开的 Flutter Antigravity 文档 现在推荐审查驱动开发、Dart 和 Flutter 扩展、MCP server 设置以及智能体式热重载，这让围绕管理器的讨论从大会承诺变成了有文档可循的应用开发工作流。
@PDBeurope 展示（6 次点赞、1 条回复、711 次浏览、9 次收藏），PDBe MCP Servers 不仅适用于 Antigravity，也适用于其他兼容 MCP 的客户端。公开的 PDBe MCP Servers README 同时包含 Antigravity 的 raw-config 和 Codex CLI 示例，这使协议层能够在不同编程界面之间迁移。
讨论要点： kevinhou22 讨论串里最有价值的回复，要求一个更强的监督模型来分发更便宜的子智能体，并要求 Antigravity IDE 与 Agent Manager 之间实现会话同步。大家要的不是更好的自动补全，而是更好的编排。
与前日对比： 6 月 2 日让管理器界面本身成为故事主角；6 月 3 日则补上了集成文档、MCP 可移植性，以及针对跨界面状态和混合模型路由的具体需求。
1.2 Codex 进一步走向角色专属的应用构建，但首批实现看起来仍较粗糙 🡕¶
第二个主要主题是，Codex 正在突破工程本身的边界，而用户也立刻开始给这些新界面的 UX 和可靠性做压力测试。五条留存条目支持了这一主题。
@Nikitont 总结（12 次点赞、3 条回复、123 次浏览、5 次收藏）了 6 月 2 日的 Codex 更新：6 个新插件、Sites，以及面向分析、设计、销售和财务工作的注释功能。这一点之所以重要，是因为当天其余证据显示，这些主张已经被用进真实工作流，而不只是停留在发布帖里。
@CiscoAI 表示（27 次点赞、1 条回复、69,230 次浏览），App Builder 会把 Codex 直接带进 Cisco Cloud Control，让客户和合作伙伴能用自然语言为自己的环境构建定制应用。这是 Codex 正在变成内部应用界面、而不只是编程助手的最清晰企业信号。
@IShmool 汇报（4 次点赞、2 条回复、104 次浏览）了一个用 Wix Headless Codex 插件搭建摩托车商店的案例，其中包含 20 个商品、35 张 AI 生成商品图、来自 Wix Blog API 的博客内容、购物车与结账流程、CRM 工作流，以及 PageSpeed 成绩：性能 96、可访问性 100、最佳实践 100、SEO 100。它最鲜明的角度在于运营层面：“周二早上，店长打开 Wix Dashboard 就能自己管理一切。不需要终端。”
@_simonsmith 认为（6 次点赞、224 次浏览、4 次收藏），Codex 的 Creative Production 插件对于风格板来说设计过度。附图展示了他提出的替代方案：把 6 张低保真 GPT Image 2 输出排进一个简单的 HTML 网格里，他表示这比当前重度依赖本地 server 的流程更快。
@Adidotdev 发帖称（6 次点赞、3 条回复、63 次浏览），Codex 推出 Sites 的同时，Codex 本身也在降级。状态页截图显示 ChatGPT 和 Codex 的错误率都在上升，这把发布兴奋感立刻转成了对可靠性的怀疑。
讨论要点： 反对意见并不是说 Codex 应该继续只做编程工具，而是说新的角色专属工作流需要比首批实现更快的批量操作、更简单的编辑界面，以及更可靠的上线质量。
与前日对比： 6 月 2 日围绕插件和 Sites 充满发布公告；6 月 3 日则补上了具体的企业和电商构建案例，同时也出现了同日批评，认为这些新界面推出得过于仓促。
1.3 支出治理成为 AI 编程产品栈的一部分 🡕¶
最强的商业讨论聚焦的不是原始模型质量，而是成本控制、积分和路由层。六条留存条目支持了这一主题。
@GHchangelog 宣布（19 次点赞、4 条回复、1,877 次浏览），GPT-4.1 已在所有 GitHub Copilot 体验中弃用。链接的 GitHub changelog 推荐改用 GPT-5.5，并表示 Copilot Enterprise 管理员可能需要通过模型策略才能开放它，这让模型选择变成了治理问题，而不只是偏好问题。
@tekbog 抱怨（33 次点赞、6 条回复、940 次浏览），Copilot 的这次变更让它“简直没有任何理由”再优于替代品，因为 token 定价涨了。一条回复又补充说，享受旧政策的老用户虽然仍在旧系统上，但额度更少、实际成本更高，这让抱怨从一般不满变成了明确的预算问题。
@acadictive 表示（12 次点赞、5 条回复、253 次浏览），他们在不到 3 天内就烧完了 Copilot 的月度 token。截图显示 Copilot Pro+ 已用满 100%，还配置了额外预算，重置日期被推到了 7 月 1 日。
@4ster_light 展示（1 条回复、33 次浏览）了学生档位的第二个预算例子：只经过一天轻度的智能体式编程，200 点内含 AI 积分就已经用掉了 139 点，截图还把 1.38 美元的用量归因给 GPT-5.4 mini。
@yashgogri1 发布（27 次点赞、1 条回复、143 次浏览）了按员工和按用例划分、带支出上限和模型路由的 API key。仪表板截图展示了 proj-data-pipeline、ci-eval-runner、sandbox-yash 和 agent-prod-worker 的独立预算，使这个方案非常具体。
@F2aldi 分享（2 次点赞、2 条回复、198 次浏览）了 Tokscale 这个跨运行框架的成本跟踪器。它的截图显示 91 亿 token、5.11K 美元总支出、216.35 美元的最佳单日，以及针对 Cursor、Codex CLI、OpenCode、Claude Code 和 Hermes Agent 的筛选器——这正是用户说自己缺少的那种可见性。
讨论要点： 这条信息流不只是抱怨定价，而是已经开始围绕定价生产出新工具层：仪表板、按 key 预算，以及把智能体使用保持在经济可承受范围内的模型路由。
与前日对比： 6 月 2 日暴露了配额焦虑和发布日价格冲击；6 月 3 日则把它具体化为积分耗尽截图、重置日期和新的治理产品。
1.4 团队正在把 AI 编程正式化为可复用的操作系统，而不是一次性提示词 🡕¶
最后一个主要主题是，把可重复的操作者实践编码成系统：计划、技能、记忆、后台任务，以及按角色选择模型。三条留存条目支持了这一主题。
@mvanhorn 发布（73 次点赞、12 条回复、8,292 次浏览、107 次收藏）了一条“我所知道的每一个 Agentic Engineering hack”讨论串，把计划文件当成机器输入，而不是文档。帖子推荐 /ce-plan、语音输入、4-6 个 cmux 标签页、从 Claude 把任务路由到 Codex、保存转录记录、建立记忆存储，并把任何重复任务都变成可复用技能。当有人在回复里问他们为什么不去读计划时，回答是：“那会拖慢你。”
@nixxin 记录（9 次点赞、8 条回复、3,460 次浏览、9 次收藏）了一个月来用 Hermes 在 Raspberry Pi 上构建系统的经历：Honcho 记忆、Tailscale、WhatsApp 和 Telegram、OpenRouter 与 OpenAI 访问、用 Gemini 做记忆抽取，以及按智能体角色选择不同模型。一条回复解释说，WhatsApp 集成会把选定的 WhatsApp Web SQLite 交互读入智能体记忆，这让整个栈比泛泛的“我做了个智能体”更具体。
@kitlangton 表示（18 次点赞、2 条回复、487 次浏览、7 次收藏），OpenCode 已经可以生成后台子智能体，而一个新的 PR 还会让同步任务也能转到后台。后续那条提到 terminal-control 的回复，展示了演示背后正在浮现的模式：智能体越来越多地被接上终端、后台任务，甚至其他智能体。
讨论要点： 人们现在正在围绕 AI 编程标准化控制平面——计划、记忆、转录记录、标签页和后台执行——而不是把每次会话都当成一段全新的聊天。
与前日对比： 6 月 2 日强调的是桌面路由器和管理器式产品；6 月 3 日则展示了个人如何把同样的思路组装成自己的 AI 工作操作系统。
2. 令人困扰的问题¶
按量计费的积分现在像个不断移动的靶子¶
严重程度：高。@GHchangelog 宣布（19 次点赞、4 条回复、1,877 次浏览）Copilot 全面弃用 GPT-4.1；@tekbog 抱怨（33 次点赞、6 条回复、940 次浏览）token 定价已经抹掉了继续留下来的理由；@acadictive 表示（12 次点赞、5 条回复、253 次浏览）他们不到 3 天就耗尽了 Copilot 月度额度；@4ster_light 则展示（1 条回复、33 次浏览）学生档位账号在轻度使用一天之后就只剩 61 点积分。人们的应对方式是增加明确的控制层，例如 @yashgogri1 发布（27 次点赞、1 条回复、143 次浏览）的按 key 预算和路由，以及 @F2aldi 分享（2 次点赞、2 条回复、198 次浏览）的 Tokscale 遥测。这一问题值得构建，因为抱怨已经变成运营层面且立刻可感，而不是理论讨论。
新的角色专属界面仍带着本可避免的可靠性与 UX 问题上线¶
严重程度：高。@Adidotdev 发帖称（6 次点赞、3 条回复、63 次浏览），Codex Sites 上线时 Codex 本身却处于降级状态，截图显示 Codex 和 ChatGPT 的错误率都在升高。@_simonsmith 认为（6 次点赞、224 次浏览、4 次收藏），Creative Production 插件设计过度，因为一个简单 HTML 页面加低质量批量生成图片，就能更快做出可用的风格板工作流。@Nikitont 总结（12 次点赞、3 条回复、123 次浏览、5 次收藏）了更广泛的插件、Sites 和注释发布，这使这些粗糙边角的影响不再只是一次性 bug。人们的应对方式是缩小范围、用更简单的组合绕过官方插件流程，并让智能体工作保持可审查。这一问题值得构建，因为真正的瓶颈是工作流时间和信任，而不是视觉打磨。
智能体仍在隐藏质量债，而不是消除它¶
严重程度：高。@Pragmatic_Eng 引用（1 次点赞、1 条回复、143 次浏览）了 Dax Raad 的说法：AI 智能体会在代码里埋“地雷”，因为它压低了工程师原本会对走捷径感到危险的那种警觉。@AIHighlight 分享（9 次点赞、824 次浏览）了一篇对 Carnegie Mellon《TheAgentCompany》基准测试的总结，显示即便是测试中最强的智能体，自主完成任务的比例也只有大约 30%。公开的 Flutter Antigravity 文档 对审查驱动开发的推荐，也指向同样的应对模式：让人工审批环保持可见，因为输出量并不等于值得信任的工作。这一问题值得构建，因为今天的问题不是智能体每次都会失败，而是它们能够产出貌似合理的结果，同时压低了人类本会感到的那些预警信号。
3. 人们期望的功能¶
具备预算感知的访问控制与路由¶
人们要的并不只是抽象意义上的更便宜 AI，而是明确责任人、硬性上限，以及自动路由到仍能完成任务的最便宜模型。@yashgogri1 发布（27 次点赞、1 条回复、143 次浏览）了带支出上限的按员工和按用例 API key，而 @F2aldi 分享（2 次点赞、2 条回复、198 次浏览）了 Tokscale，用来让多种编程运行框架里的 token 消耗变得可见。@acadictive 抱怨自己几天内就用完 Copilot（12 次点赞、5 条回复、253 次浏览），以及 @4ster_light 表示学生档位只剩 61 点积分（1 条回复、33 次浏览），都解释了为什么这个需求显得如此紧迫：人们还没觉得自己真正做了多少工作，就已经撞上了限制。机会：直接。
跨 IDE、管理器与子智能体的共享状态¶
围绕 @kevinhou22 那条帖子（255 次点赞、45 条回复、14,884 次浏览、97 次收藏）的回复，不仅要求 Antigravity IDE 和 Agent Manager 之间会话同步，也希望有更强的监督模型来调度更便宜的子智能体，这让一条产品讨论串直接变成了清晰的未满足需求。@mvanhorn 在实践中描述（73 次点赞、12 条回复、8,292 次浏览、107 次收藏）和 @nixxin 在实践中描述（9 次点赞、8 条回复、3,460 次浏览、9 次收藏）的那些栈，也说明了原因：规划、执行、记忆和消息传递早已分散在多个界面里。机会：直接且有竞争性。
以审查为先、可进行精细修改的编辑界面¶
人们想要的是在不重跑整个工作流的情况下，看到并修改智能体输出中的小块内容。@_simonsmith 认为（6 次点赞、224 次浏览、4 次收藏），Codex 的 Creative Production 插件应当依赖低质量批量生成和一个简单 HTML 页面，而不是更重的本地 server 流程；公开的 Flutter Antigravity 文档 也推荐审查驱动开发和智能体式热重载，理由相同。这是一个实际需求，而非愿景诉求：用户不是在要求更多生成，而是在要求更安全的迭代。机会：直接。
面向日常工作任务的基准测试与护栏¶
围绕质量的讨论不断要求一种能衡量真实工作、并能捕捉隐藏失效模式的系统。@AIHighlight 总结（9 次点赞、824 次浏览）了《TheAgentCompany》，把它当作当前智能体距离完全自主仍相去甚远的证据；@Pragmatic_Eng 则引用（1 次点赞、1 条回复、143 次浏览）Dax Raad 的话，指出智能体会把危险的捷径隐藏起来，直到更晚的时候才暴露。这一需求非常实际：团队想要一种方式，在问题流入生产环境或维护阶段之前，就捕捉静默的质量衰减。机会：直接。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Google Antigravity 2.0 + Flutter | 智能体管理器 / 应用工作流 | (+/-) | 智能体优先界面、审查驱动开发、MCP 支持、智能体式热重载、文档化的 Flutter 流程 | 用户仍在要求 IDE-管理器同步和混合模型子智能体控制 |
| PDBe MCP Servers | MCP 集成 | (+) | 具备明确 Antigravity 和 Codex 配置示例的可移植领域工具 | 仅适用于结构生物学工作流，且仍需要配置 |
Compound Engineering (/ce-plan, cmux, skills) |
工作流方法 | (+) | 把计划变成可复用的协调工件，并支持并行标签页、语音、路由和技能 | 属于高级用户配置；如果用户跳过权限控制，默认做法风险较高 |
| Hermes + Honcho memory stack | 自托管智能体栈 | (+/-) | 持久智能体、按角色选模型、消息集成和 Raspberry Pi 部署 | 配置繁琐，且需要反复试验模型与 token |
| OpenCode | 开放式智能体运行框架 | (+/-) | 后台子智能体、可黑客化的控制界面和终端自动化 | 质量参差不齐，用户谈论的仍是 PR 和粗糙边角，而非成熟打磨 |
| Codex 插件 / Sites / 注释 | 插件 / 应用构建界面 | (+/-) | 将 Codex 扩展到内部应用、电商、风格板和精细修改 | Sites 上线时的降级和插件 UX 投诉削弱了信任 |
| GitHub Copilot 模型策略 + AI 积分 | IDE / 模型访问层 | (-) | 覆盖广、模型选择器和企业策略控制 | GPT-4.1 弃用、积分消耗过快，以及围绕重置日期做预算主导了整体情绪 |
| Merge Gateway | 路由 / 治理 | (+) | 按用户和用例设置预算，并路由到最合适且最便宜的模型 | 又增加了一层团队必须采用和维护的控制层 |
| Tokscale | 成本遥测 | (+) | 跨运行框架查看 token、支出、连续使用天数以及最佳/最差日 | 只提供可观测性；能解释支出，但本身不降低支出 |
整体评价务实而不讲忠诚度。@mvanhorn 展示（73 次点赞、12 条回复、8,292 次浏览、107 次收藏）出高级用户愿意在多种工具之间混用方案、语音、路由和记忆；@nixxin 则展示（9 次点赞、8 条回复、3,460 次浏览、9 次收藏）了自托管栈里的同样模式。@tekbog 抱怨（33 次点赞、6 条回复、940 次浏览）以及 @acadictive 汇报（12 次点赞、5 条回复、253 次浏览）的快速配额耗尽，解释了为什么像 @yashgogri1 发布（27 次点赞、1 条回复、143 次浏览）的 Merge Gateway，以及 @F2aldi 分享（2 次点赞、2 条回复、198 次浏览）的 Tokscale 这类治理层，会如此清晰地击中需求。迁移模式很明确：在一个界面里规划，在另一个界面里做长时间执行，用 MCP 提升可移植性，再在其上叠加明确的预算可见性。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Merge Gateway 按 key 预算 | @yashgogri1 | 创建按员工和按用例划分、带支出上限和模型路由的 API key | 团队看不清是谁在消耗智能体预算，也不知道该由哪个模型处理哪类任务 | Gateway、Anthropic/OpenAI 路由、编程智能体集成 | 已发布 | 推文（27 次点赞、1 条回复、143 次浏览） |
| PDBe MCP Servers | @PDBeurope | 把 PDBe API 和搜索能力以 MCP 工具形式提供给 AI 客户端 | 领域工作流需要在智能体界面里直接访问数据，而不是手动复制粘贴 | Python、uvx、MCP、PDBe API/Search、可选 Neo4j 图谱 | 已发布 | 推文（6 次点赞、1 条回复、711 次浏览、9 次收藏） / 仓库 |
| Cisco App Builder | @CiscoAI | 让客户和合作伙伴能够在 Cisco Cloud Control 中用 Codex 构建定制应用 | 内部应用很难快速适配到具体企业环境 | Codex、Cisco Cloud Control | Beta | 推文（27 次点赞、1 条回复、69,230 次浏览） |
| Wix Headless 摩托车商店 | @IShmool | 用产品、AI 图片、内容、结账和 CRM 构建并管理一个电商站点 | 小团队希望无需重度终端工作流，也能得到可部署店铺 | Codex 插件、Wix Stores、Wix Blog API、AI 图像生成、结账、CRM | 已发布 | 推文（4 次点赞、2 条回复、104 次浏览） |
| Tokscale | @F2aldi | 跟踪多种智能体运行框架里的 token 用量与成本 | 开发者无法知道自己的日常 AI 工作流究竟花了多少钱 | 仪表板、Cursor、Codex CLI、OpenCode、Claude Code、Hermes Agent | 已发布 | 推文（2 次点赞、2 条回复、198 次浏览） |
@yashgogri1 发布（27 次点赞、1 条回复、143 次浏览）了 Merge Gateway 这一预算与路由层，而 @F2aldi 展示（2 次点赞、2 条回复、198 次浏览）了它旁边的遥测层 Tokscale。模式已经很清楚：构建者正在填补按量计费编程智能体制造出来的治理缺口，在模型 API 之上再加一层责任归属、上限和成本可见性。
第二种构建模式则是保留原有领域系统或控制平面，再把智能体嵌进去。@CiscoAI 展示（27 次点赞、1 条回复、69,230 次浏览）了 Cisco Cloud Control 内部的 Codex；@IShmool 展示（4 次点赞、2 条回复、104 次浏览）了 Wix Headless 店铺工作流中的 Codex；@PDBeurope 展示（6 次点赞、1 条回复、711 次浏览、9 次收藏）了通过 MCP 把 PDBe 数据访问带进 Antigravity 和 Codex。反复出现的触发因素并不是泛泛的 AI 热情，而是想缩短从既有工作流到可用交付物之间的路径。
6. 新动态与亮点¶
TheAgentCompany 把可靠性缺口量化了¶
@AIHighlight 分享（9 次点赞、824 次浏览）了一篇对 Carnegie Mellon《TheAgentCompany》基准测试的总结，附带论文摘要写道，在一个模拟软件公司里，测试中竞争力最强的智能体也只能自主完成大约 30% 的任务。值得关注的不只是这个数字，而是摘要把日常浏览、编程、程序执行和同事沟通都描述成仍远未解决的问题，同时还公开发布了代码、数据、环境和评估。
Tokscale 让新一代智能体栈里的 token 消耗变得可见¶
@F2aldi 分享（2 次点赞、2 条回复、198 次浏览）了 Tokscale，仪表板截图展示了 91 亿 token、5.11K 美元总支出、216.35 美元的最佳单日、129 个活跃日，以及 Cursor、Codex CLI、OpenCode、Claude Code 和 Hermes Agent 的筛选器。这一点之所以重要，是因为它把“AI 编程变贵了”从一种情绪，变成了团队可以比较、预算和优化的可度量运营问题。
7. 机会在哪里¶
[+++] 具备预算感知的智能体网关 - 第 1、2、4、5 节的证据都指向同一个缺失层：Copilot 积分耗尽、GPT-4.1 向 GPT-5.5 的策略切换、Merge Gateway 和 Tokscale，都说明原始模型访问现在需要围绕它加上责任归属、路由和硬性预算控制。
[+++] 以审查为先的智能体输出质量控制 - 第 1、2、3、6 节的证据异乎寻常地一致。Flutter 文档推荐审查驱动开发，@_simonsmith 主张（6 次点赞、224 次浏览、4 次收藏）进行更精细、也更适合批量处理的编辑，@Pragmatic_Eng 引用（1 次点赞、1 条回复、143 次浏览）了 Dax Raad 对隐藏“地雷”的警告，而 @AIHighlight 分享（9 次点赞、824 次浏览）的基准测试则证明，完全自主仍然遥远。
[++] 跨界面与跨模型的共享编排 - @kevinhou22 帖子下要求（255 次点赞、45 条回复、14,884 次浏览、97 次收藏）同步状态和不同监督/子智能体模型的回复，再加上 @mvanhorn 描述（73 次点赞、12 条回复、8,292 次浏览、107 次收藏）与 @nixxin 描述（9 次点赞、8 条回复、3,460 次浏览、9 次收藏）的多界面栈，都表明需求很强。这一机会之所以只是中等而非顶级，是因为这个空间已经非常拥挤，而且变化很快。
[+] 垂直协议包与嵌入式应用构建器 - PDBe MCP Servers、Cisco App Builder 和 Wix Headless 店铺都展示了同一种模式：保留原有领域系统或控制平面，再把智能体带进去。这个方向正在浮现，但尚未完全验证，因为每个垂直领域仍需自己搭建信任、集成和审查层。
8. 要点总结¶
- 产品竞争正在移到编辑器之上。 @kevinhou22 认为（255 次点赞、45 条回复、14,884 次浏览、97 次收藏），用户正在跨多个界面管理几十个甚至上百个智能体，而 Antigravity、Flutter 和 PDBe 的证据都把重点指向编排与可移植性，而不是编辑器锁定。
- Codex 的扩张是真实的，但第一批角色专属工作流仍需要更简单和更可靠。 @CiscoAI 展示（27 次点赞、1 条回复、69,230 次浏览）了 Cisco Cloud Control 内部的企业应用构建，而 @_simonsmith 则认为（6 次点赞、224 次浏览、4 次收藏），其中一个新的 Codex 插件工作流本该大幅简化。
- 定价现在是工作流设计约束，而不是采购脚注。 @acadictive 表示（12 次点赞、5 条回复、253 次浏览），他们几天内就用满了 100% 的 Copilot 预算；而 @yashgogri1 发布（27 次点赞、1 条回复、143 次浏览）了一层能够路由并限制支出的控制层。
- 胜出的团队正在围绕模型构建流程。 @mvanhorn 发布（73 次点赞、12 条回复、8,292 次浏览、107 次收藏）了一套以计划和技能为核心的操作手册，而 @nixxin 记录（9 次点赞、8 条回复、3,460 次浏览、9 次收藏）了一个带记忆和消息系统的多模型自托管栈。
- 可靠性主张会越来越取决于真实工作基准测试。 @AIHighlight 分享（9 次点赞、824 次浏览）了《TheAgentCompany》的证据，显示测试中最强的智能体也只能自主完成大约 30% 的任务。