Twitter AI 编程 - 2026-07-16¶
1. 人们在讨论什么¶
1.1 Google 的编程栈仍在公开场域里扩张，但 Gemini 3.5 Pro 的叙事变得更不稳 (🡒)¶
Google 仍然是当天最响的单一厂商叙事，但最具体的证据，不是来自已确认的旗舰模型发布，而是来自生态地图和工作流示例。4 条不同讨论串都在推同一个大方向：Google 现在已经有了一套彼此连通的编程与智能体界面，但用户仍然拿不到一个稳定、公开的判断——下一代旗舰模型到底何时落地、其已验证规格又是什么。
@LuminaXspace 发了一串 Gemini 3.5 Pro 的传闻清单：目标时间指向 7 月 17 日、底座经过重建、传闻中的 2M-token 上下文窗口、Deep Think 推理，以及更强的编程和长时程智能体表现（214 点赞、13 回复、13,942 浏览量、24 收藏）。但同一条讨论里真正重要的证据，其实是反驳：有条回复说 Google 已经否认了 2M 上下文的说法，而且发布又跳票了，所以这条内容更能说明“大家在关注什么、又有多不确定”，而不是给出已验证的产品细节。
@shubham_crazy08 认为，NotebookLM 加 Antigravity 是一组被低估的杠杆（85 点赞、8 回复、3,570 浏览量、48 收藏）。让这条帖子有用的，是它下面的回复串：他声称，这个组合能拉起面向特定任务的 NotebookLM 研究笔记本、基于本地 markdown 上下文编码定制业务 skills、从 NotebookLM 知识构建带上下文的应用，并自动触发音频或报告生成。
@yourtechgirl24 把 Google 描绘成 一整套端到端 AI 智能体生态，而不是单模型竞赛（22 点赞、16 回复、23,023 浏览量、10 收藏）。附带的信息图，是当天最清晰的产物，因为它把 Gemini、Gemma、Stitch、Whisk、NotebookLM、Gemini CLI、Antigravity、Jules、ADK、A2A 和 FileSearch API 放到了同一页上；但回复里仍然有人提醒：如果核心模型落后于竞争对手，集成度再高也补不回来。
@kenn_ronin 列了一套 每月 40 美元的已交付栈：Claude Code、ChatGPT、面向 Antigravity / Veo / Flow 的免费 Google AI Pro 访问、免费的 Grok Build / Imagine，以及免费层 Groq keys（67 点赞、34 回复、9,206 浏览量、18 收藏）。这很重要，因为它说明 Google 的智能体界面，已经被当成实用多工具组合的一部分，而不只是传闻燃料。
讨论要点： 最强的分歧，并不是简单的反 Google 情绪，而是可信度和层级关系。盯传闻的人在争执发布日期和规格，强调生态的人则收到更结构性的反驳：一整套大而全的栈，并不能自动回答 Gemini 本身是不是最好的编程核心。
与前日对比： 在 2026-07-15，讨论已经从单条 Gemini 泄露，扩展成更广的 Google 平台地图。到了 2026-07-16，这张地图依旧存在，但证据又进一步偏离了“发布是否确定”，转向生态定位和 Antigravity 的实际用例。
1.2 构建者开始偏向 eval 循环、skills 和工单式通道，而不是通用智能体 SDK (🡕)¶
当天最技术向的帖子，不是在讨论又一个模型发布，而是在讨论怎么把智能体做得更可靠：把评判和修复分开、把可复用技能打包起来，并把委派收窄到那些足够明确、能被当作工单处理的任务上。这比昨天“加固工作流”的主题更强，也更具体。
@Saboo_Shubham_ 分享了 Google 新的 coding agents 质量飞轮技能（62 点赞、15 回复、4,010 浏览量、69 收藏）。Google 的开发者文章说，这个 skill 会把智能体 QA 拆成 5 个阶段：先从 traces 或合成场景准备数据集，再运行推理、用 AutoRaters 或自定义评分标准打分、分析失败原因，并做定向修复迭代；文中还明确强调，优化器绝不会给自己的工作打分。
@gakonst 抱怨，大多数智能体 SDK 都落后于现实，并点名只有基于 RPC 的 Codex App Server 才算得上一个好用的开源模式（50 点赞、13 回复、4,084 浏览量、25 收藏）。真正让这条抱怨变得可用的，是回复区：有人主张把 sandbox、harness 和 workflow storage 分成独立层；还有人说，他们已经从自建系统迁到了 Pi ACP，再迁到 Codex App Server，因为通用 SDK 仍然覆盖不了跨线程和跨智能体通信的需求。
@boringmarketer 分享了 一个 kimi-first 技能：当 spec 已经冻结时，把编码工单路由给 Kimi Code CLI，而 Claude 继续保留规格、架构、代码审查、测试和合并审批（3 点赞、5 回复、746 浏览量、6 收藏）。仓库 README 把这套原则写得很明白：Kimi 负责吞吐，Claude 保留判断权，一旦反复失败就停止委派。
@WebStormIDE 发布了 WebStorm 2026.2，而 JetBrains 的发布文章写道，这个 IDE 现在自带原生 GitHub Copilot 集成，以及一个能跨项目携带可复用栈知识的智能体技能管理器，甚至还能导入为 Claude Code 或 Codex 预先配置好的技能（52 点赞、3 回复、2,145 浏览量）。
讨论要点： Saboo 那条讨论给出的最尖锐提醒是：证明这一步仍需要人工复核，因为智能体可能会通过某种意义上由自己塑形的 evals。更广的模式则是，人们想要的是更强的委派结构，而不是再多一层通用封装代码。
与前日对比： 在 2026-07-15，最强的纪律信号还来自 Spec Kit、MCP 工具暴露和 token 压缩技巧。到了 2026-07-16，这条模式已经成熟成可重复的产品和教条：显式打分循环、可导入技能，以及专门的编码通道。
1.3 智能体工作正在进入 Jira、外部计算后端，甚至实体控制器 (🡕)¶
第三个主题，是智能体控制界面的扩张。重要变化不只是“可以从更多地方监督智能体”，而是人们现在已经期待：智能体能留在工作流工具里继续干活、把任务派到远程算力后端，甚至借专用硬件来引导。
@github 宣布 GitHub Copilot for Jira 已正式可用（162 点赞、14 回复、37,643 浏览量、51 收藏）。GitHub 的 GA 更新日志写道，这次发布会把智能体进度流式写进 Jira issue，支持用户在同一个 draft pull request 的 Jira 聊天面板里继续发后续指令，也降低了连接 GitHub org 和 repo 的 setup 摩擦。
@ONcompute 宣布 了一个 MCP 端点，让智能体可以用自然语言发现计算提供商、编写算法、启动作业并管理存储（16 点赞、9 回复、1,400 浏览量）。这里的图片很关键，因为它们不只画出了目标架构，还给了一个具体的 Shakespeare 示例：先在免费 CPU 上跑，再切到 8× H200，这就把一句模糊的“智能体可以使用算力”主张，变成了实际执行模式。
@stufflistings 发帖称，Codex Micro 是一款售价 230 美元的 Codex 智能体控制器（25 点赞、9 回复、2,559 浏览量）。那组上手图并不只是装饰：它明确展示了专用设备本体，以及一张规格表，列出 Bluetooth / USB-C、Mac / Windows 支持、RGB 灯光、13 个机械开关、触摸传感器、旋钮编码器和平面摇杆。
讨论要点： Jira 那条讨论带来的更多是怀疑——人们担心工单 spam 和自动生成的验收标准；而 Ocean 与 Codex Micro 那两条则正好相反：它们卖的是更显式的控制、更远的执行触达，以及更少的应用切换。
与前日对比： 在 2026-07-15，最强证据还在说明，人们正从 Jira、移动端、桌面和硬件等多个界面观察智能体。到了 2026-07-16，这种扩张已经更偏运营：Jira 让智能体留在工单里，Ocean 把智能体推向远程算力，而 Codex Micro 则把智能体状态变成了一个实体控制问题。
2. 令人困扰的问题¶
证明智能体确实变好了，依然是人工活¶
严重程度：高。@Saboo_Shubham_ 分享了 一套承诺能找出智能体 bug、修掉它们并证明修复有效的工作流，但回复立刻把真实痛点收紧了：有实践者说，“证明”这一步仍然得有人盯着，因为一个会自己写或自己塑形 eval 的智能体，照样可能把自己判成通过；也有人说，真正卡住的地方，是判断修复到底算不算真的正确。Google 的博客本身也在强化这种担忧，因为它明确把优化器和评估器分开了。这条方向值得做，因为今天的权宜方案，仍然只是让人类去审最关键的前后对比结论。
通用封装层和社区插件胶水，依然显得脆弱¶
严重程度：高。@gakonst 说，大多数智能体 SDK 都“很烂”，而回复把抱怨讲得更具体：用户想要的是分开的 sandbox、运行框架和工作流存储层，以及标准化的跨线程、跨智能体通信，而不是浅层 API 封装。在另一条兼容性讨论里，@leerob 回答，Cursor 订阅可以通过 ACP 或社区插件在开放运行框架里工作（11 点赞、4 回复、2,738 浏览量、5 收藏）；但提问者马上表示，在当前 npm 安全焦虑下，不太敢装一个拿着订阅权限的随机 npm 插件。眼下看得见的应对行为，是退回厂商 CLI，或者退回更强约束的运行框架。这条方向值得做，因为集成便利性和信任，当前正直接彼此拉扯。
把智能体塞进 Jira，立刻就会引发流程噪音焦虑¶
严重程度：中。@github 宣布，Copilot for Jira 现在可以流式写入进度，并接受来自 Jira 聊天面板的后续指令（162 点赞、14 回复、37,643 浏览量、51 收藏）；但最先冒出来的回复，是拿幻觉式验收标准、自动生成的工单洪水，以及 AI 代写拖延借口来开玩笑。更新日志本身确实展示了真实的工作流价值，但公众反应也很清楚：如果智能体输出不能被强力压缩和约束，管理界面很可能会比代码质量更快积累噪音。这个方向值得做，前提是活动记录能保持可读，而不是把工单杂音越堆越多。
当人们没法调试结果时，“vibe coding” 依然像在赌博¶
严重程度：中。@kapilansh_twt 认为，vibe coding “不过是另一种赌博”（24 点赞、24 回复、349 浏览量）。回复其实并没有完全反对这句话；它们更多是在把抱怨说得更具体：当人们没搞懂怎么调试失败、或者 token 花销已经跑赢工程判断时，这件事就会像赌博。这让挫败感变得比纯粹反 AI 更可行动。这个方向值得做，因为大家给出的解决思路，是流程纪律，而不是彻底放弃这些工具。
3. 人们期望的功能¶
团队可信的独立智能体评分层¶
Saboo 那条讨论和 Google 的质量飞轮文章，指向了一个非常直接的现实需求：团队想量化智能体有没有变好，但前提是修复者不能给自己打分。@Saboo_Shubham_ 展示了 这套工作流（62 点赞、15 回复、4,010 浏览量、69 收藏），Google 的文章说优化器和评估器必须解耦，而回复里的人仍在说，证明这一步往往离不开人工判断。这里缺的，不是一个更炫的演示，而是“看起来好了”和“生产里真的变好了”之间那层信心基础。机会：直接。
从旗舰模型到编程界面再到智能体基础设施的一张连贯地图¶
围绕 Google 的几条讨论，都说明人们想要一套自己真正能推理清楚的产品层级。@LuminaXspace 发了 又一波 Gemini 3.5 Pro 传闻（214 点赞、13 回复、13,942 浏览量、24 收藏），@shubham_crazy08 展示了 一个具体的 NotebookLM + Antigravity 工作流（85 点赞、8 回复、3,570 浏览量、48 收藏），而 @yourtechgirl24 画出了 更大的 Google 栈地图（22 点赞、16 回复、23,023 浏览量、10 收藏）。现在缺的是一个稳定、公开的答案：哪一层负责哪件事、哪些能力还只是预览、哪些界面是可长期依赖的，以及工作到底如何在模型、CLI、IDE、异步编程工具和智能体框架之间流动。机会：直接。
权限边界明确、信任跳跃更少的可复用技能¶
几条帖子都在暗示，技能正在成为智能体能力的基本单元，但还没成为信任的基本单元。@gakonst 批评了 通用 SDK（50 点赞、13 回复、4,084 浏览量、25 收藏），@leerob 确认了 开放运行框架可以依赖社区插件（11 点赞、4 回复、2,738 浏览量、5 收藏），而提问者立刻就担心要装一个带订阅权限的陌生 npm 包。与此同时，@WebStormIDE 发布了 一个智能体技能管理器，把可复用知识直接做成一等产品界面（52 点赞、3 回复、2,145 浏览量）。人们需要的，是那些在运行前就能把范围、来源和访问边界说清楚的技能。机会：竞争激烈。
把成本、控制权和本地替代方案串起来的栈规划¶
眼下看得见的栈讨论，仍然主要靠手工经验和零散案例。@kenn_ronin 分享了 一套每月 40 美元的 Claude Code、ChatGPT、Google AI Pro、Grok Build 和 Groq keys 组合（67 点赞、34 回复、9,206 浏览量、18 收藏）；而 @comma_ai 反驳说，在禁用 Anthropic 之后，他们用本地的 GLM 5.2 加 OpenCode 做智能体式编程，并没有更差（30 点赞、1 回复、1,645 浏览量）。这里现实需要的是一层控制平面，能帮助团队在付费闭源工具、免费层和本地 / 开放替代方案之间做选择，而不用每次都从零散推文里重建那些取舍。机会：竞争激烈。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Google agent-evals skill | 评估工作流 | (+/-) | 给 Antigravity、Claude Code 和 Codex 提供五阶段循环：准备数据、运行推理、打分、分析失败并迭代 | 回复说证明步骤仍需人工判断，因为智能体可能会钻自写 eval 的空子 |
| NotebookLM + Antigravity | 研究 / 编排工作流 | (+) | 据称能拉起专用笔记本、编码定制业务技能、基于 notebook 上下文构建应用，并触发报告生成 | 证据仍主要来自单个实践者讨论串，尚未被广泛验证 |
| Codex App Server over RPC / Pi ACP | 智能体运行框架 / SDK 模式 | (+/-) | 实践者更偏好它而不是通用 SDK 封装，因为它更接近真实运行框架行为，也支持跨线程或跨智能体工作 | 周边 SDK 生态仍被形容成落后于当前实践的浅层编排胶水 |
| GitHub Copilot for Jira | 工作流集成 | (+/-) | 把智能体进度流进 Jira，支持在同一个 draft pull request 上继续下指令，并降低接入摩擦 | 早期回复预测会出现工单 spam、AI 评论和幻觉式工作流噪音 |
| WebStorm 2026.2 | IDE | (+) | 附带 TypeScript 7 支持、原生 GitHub Copilot，以及能导入 Claude Code 或 Codex 技能的智能体技能管理器 | 技能仍局限在 JetBrains 环境里，而且当前主要围绕 Claude / Codex 工作流 |
| kimi-first | 多智能体委派方法 | (+) | Claude 负责 specs、代码审查、测试和合并审批，把冻结 spec 的编码工作路由给 Kimi Code CLI | 只适用于 spec 已冻结之后，且 README 说明一旦反复失败就会停止委派 |
| Tabby | 自托管编程助手 | (+) | 提供 GitHub Copilot 的本地替代方案，带自包含 server、OpenAPI 接口、repo 上下文和消费级 GPU 支持 | 团队仍需自运行 server，企业功能还要额外授权 |
| Mixed $40 AI stack | 预算栈方法 | (+/-) | 一位构建者称 Claude Code、ChatGPT、Google AI Pro、Grok 和 Groq 免费层就够交付 | 比较集合带有强烈个体经验色彩，回复里也展示了许多不同搭配 |
工具组合依然很多元，而且更偏方法。@Saboo_Shubham_ 展示了 一套明确把打分和修复分开的工作流（62 点赞、15 回复、4,010 浏览量、69 收藏），而 @gakonst 认为，通用智能体 SDK 仍然抓不住人们今天实际是如何运行多线程智能体系统的（50 点赞、13 回复、4,084 浏览量、25 收藏）。@WebStormIDE 发布了 一项新能力：技能复用现在已经成了 IDE 功能，这与整体趋势一致——人们正在从临时提示词，走向可安装、可重复的操作规程（52 点赞、3 回复、2,145 浏览量）。
预算和控制权的讨论同样显眼。@kenn_ronin 分享了 一套每月 40 美元的栈（67 点赞、34 回复、9,206 浏览量、18 收藏），@comma_ai 反驳说，他们禁用 Anthropic 之后，本地的 GLM 5.2 加 OpenCode 反而更好用（30 点赞、1 回复、1,645 浏览量）；@DanKornas 则把 Tabby 说成了想要代码补全和聊天、但又不想把整个工作流交给托管助手的团队的一种自托管答案（7 点赞、2 回复、966 浏览量）。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| GitHub Copilot for Jira | @github | 把编程智能体进度流式写入 Jira issue，并让用户能在同一个 draft pull request 上发送后续指令 | 把工单上下文和智能体执行留在同一工作流里，而不是分散到多个 app | GitHub Copilot、Jira、draft PR 工作流、setup / onboarding 改进 | 已发布 | 推文 · 更新日志 |
| Ocean MCP endpoint | @ONcompute | 把智能体连到计算提供商，让它们能用自然语言写算法、启动作业和管理存储 | 把编程智能体从代码编辑扩展到远程计算编排 | 托管式 MCP 端点、Ocean 计算提供商、作业与存储管理 | 已发布 | 推文 · 端点 |
| kimi-first | @boringmarketer | Claude Code 技能，把冻结 spec 的编码工单发给 Kimi Code CLI，同时由 Claude 保留代码审查、测试和合并审批 | 把判断工作和高吞吐代码输入分开 | Claude Code、Kimi Code CLI、Fable 5、基于技能的委派 | 已发布 | 仓库 · 推文 |
| FlyAI skill | Alibaba FlyAI | 面向 Claude Code 和 OpenClaw 的旅行搜索 skill，返回结构化、可预订的 Fliggy 结果 | 让智能体能在不离开终端的情况下回答实时旅行查询 | Node.js CLI、FlyAI skill、Fliggy 库存、Claude Code、OpenClaw | 已发布 | 仓库 · 推文 |
| WebStorm 2026.2 agent skills manager | @WebStormIDE | 让团队能直接在 IDE 里安装或导入可复用的智能体技能 | 减少跨会话、跨项目反复重述技术栈约定的成本 | WebStorm、TypeScript 7、GitHub Copilot、外部技能注册表 | 已发布 | 推文 · 发布说明 |
反复出现的构建模式，是把智能体的通道收窄，而不是要求一个模型包打天下。@boringmarketer 分享了 一个仓库，几乎把“Kimi 负责敲代码，Claude 负责思考和验证”这套分工直接写死；而 README也说明，Claude 保留 specs、架构、代码审查和合并审批，Kimi 只接冻结 spec 的编码工作（3 点赞、5 回复、746 浏览量、6 收藏）。
@tom_doerr 展示了 另一种模式：用领域型 skills，把智能体的价值扩展到软件编辑之外（6 点赞、11 收藏、1,558 浏览量）。FlyAI 仓库写明，它通过 8 个搜索命令和直接预订链接，把 Claude Code 与 OpenClaw 接到 Fliggy 上，让一次智能体会话变成结构化旅行搜索界面，而不是浏览器宏。
更大的产品团队，也在以更广的范围交付同一种想法。@github 宣布，Copilot 现在会从进度流式写入到会话后的继续指挥，全程留在 Jira 里（162 点赞、14 回复、37,643 浏览量、51 收藏）；@ONcompute 宣布 了一个面向计算任务和存储的 MCP 界面（16 点赞、9 回复、3 引用、1,400 浏览量）；@WebStormIDE 宣布 了一个 IDE 原生技能管理器（52 点赞、3 回复、2,145 浏览量）。它们共同的触发条件，和报告其他部分看到的一样：团队希望智能体待在已有界面里，承担更窄的职责，并拥有更清晰的交接。
6. 新动态与亮点¶
Kimi-K3 一度成了头条级的模型对比话题¶
@arena 报告，Kimi-K3 在 Frontend Code Arena 里拿到了 1,679 分，高于 Claude Fable 5 的 1,631 分和 GPT-5.6 Sol 的 1,618 分（127 点赞、15 回复、25 引用、6,955 浏览量、8 收藏）。配套的排行榜把它从第 18 名跳到第 1 名这件事说得很具体，但最先出现的一条实质性回复又指出，图里的条形长度在视觉上夸大了这 48 分的领先，因此“基准测试结果”和“结果被如何呈现”两件事，都成了这条讨论的一部分。
本地与开放编程栈，得到了更鲜明的公开辩护¶
@comma_ai 表示，在禁用 Anthropic 之后，他们用本地的 GLM 5.2 加 OpenCode 做智能体式编程，并没有受损（30 点赞、1 回复、1,645 浏览量）。这比泛泛而谈的开源喝彩更具体，尤其是因为它同时出现在 @kenn_ronin 分享 的廉价混搭栈（67 点赞、34 回复、9,206 浏览量、18 收藏），以及 @DanKornas 推广 的自托管 Tabby server（7 点赞、2 回复、966 浏览量）旁边。值得注意的变化，不是闭源工具消失了，而是本地和开放替代方案，正在被描述成生产可用，而不只是意识形态选择。
仓库攻击演练，正在变成智能体时代运维的一部分¶
@BradGroux 报告，自己赢下了 GitHub 的《Repository Under Attack》工作坊，并附上了一份做过脱敏处理的事后报告（11 点赞、1 回复、20,281 浏览量）。帖子中的图把一整条攻击链串得非常具体：泄露的 PAT、仓库 SSH keys、恶意 npm 发布、workflow-dispatch 滥用，以及暴露的 secrets。这让当天的安全讨论，第一次拥有了明确的运营形状，而不是停留在抽象的“AI safety”语言里。
7. 机会在哪里¶
[+++] 独立的智能体评分与审批层 —— 这组数据里最强的痛点，不是模型能力不够，而是不知道智能体到底有没有真的变好。Saboo 的 agent-evals 讨论、Google 质量飞轮文章、gakonst 对运行框架的抱怨，以及 Jira spam 的回复，都在指向同一个缺口：需要一套独立系统，能给工作打分、暴露行动的真实目标，并只在证据足够可读时才请求审批。
[++] 带来源与权限元数据的可复用技能注册表 —— WebStorm 的新技能管理器、kimi-first、FlyAI，以及 Cursor / OpenCode 插件讨论，都说明技能正在成为能力的基本单元。缺的那一层是信任：团队想要的是可安装的技能，在运行前就声明自己能访问什么、由谁编写，以及何时应该停止委派。
[++] 连接工单、计算资源和本地环境的智能体控制平面 —— GitHub Copilot for Jira、Ocean MCP endpoint 和 Tabby 的自托管主张，都说明团队想让智能体在项目管理工具、远程算力和本地工作流之间来回移动，同时不丢状态，也不丢可追踪性。机会不在模型本身，而在交接与监督层。
[+] 面向多模型团队的预算感知型栈规划 —— 那条每月 40 美元的栈帖子，以及 comma.ai 关于 GLM 5.2 + OpenCode 的说法，都说明团队已经在手工拼接付费、免费层和本地工具。一个能比较成本、控制权和任务适配度的规划器，会回答越来越常见的运营问题。
8. 要点总结¶
- 最强的技术能量，投向的是让智能体可测量、可治理。 Google 的质量飞轮技能及其讨论，核心都围绕独立打分、失败分析和人工审批，而不是又一次新的自治宣称。(来源)
- 可复用技能正在成为智能体能力的一等打包层。 WebStorm 上线了 IDE 内技能管理器，kimi-first 把代码审查与编码明确拆开，FlyAI 则把旅行工作流做成了可安装的智能体技能。(来源)
- 竞争界面正在编辑器之外继续扩张。 Jira 里的进度流、通过 MCP 触达远程算力，以及 Codex 控制硬件，都说明智能体产品如今竞争的，已经是监督界面和执行界面，而不只是模型输出。(来源)
- 团队正在主动保留单一厂商智能体栈之外的替代方案。 混搭的 40 美元栈、comma.ai 的 GLM 5.2 + OpenCode 组合，以及 Tabby 的自托管主张，都说明成本控制和本地所有权，已经是编程智能体讨论的正题，而不是旁枝。(来源)