Twitter AI 编程 - 2026-07-14¶
1. 大家在讨论什么¶
1.1 Agent 工作开始具备实时交接与执行中检查(🡒)¶
当天最具体的发布,关注点是如何监督已经在运行的工作,而不只是再开启一轮聊天。GitHub 将远程 Copilot CLI 会话接入 Mobile 通知,并在 Copilot 应用中加入了执行中的安全审查。Antigravity 的团队命令依然高度可见,但相关回复对这项公告的新意提出了质疑。
@github 宣布(66 个赞,4 条回复,30,371 次浏览)发布了 GitHub Mobile 对远程 Copilot CLI 会话的实时通知,包括进度更新、需要输入时的提示,以及返回会话日志的入口。图片展示了预期的介入点:一条关于远程“修复身份验证漏洞”任务的手机通知,被标记为“需要输入”。

@GHchangelog 发布(12 个赞,1 条回复,2,079 次浏览)发布了 /security-review 在 Copilot 应用中的公开预览。GitHub 表示,这个命令会审查当前变更,找出高置信度发现,并标注严重性和置信度,覆盖注入、XSS、不安全数据处理、路径遍历和弱加密等类别,同时补充现有的代码扫描和密钥扫描。
@testingcatalog 重点介绍(274 个赞,13 条回复,23,844 次浏览)提到 Antigravity 的 /teamwork-preview,其引用的官方帖子描述了并行规划、构建和验证。截图确认这是一个一等团队命令,但有人在回复中表示自己数月来一直在使用它,因此现有证据只能支持它当前曝光度很高,不能有把握地认定这是项新能力。

讨论洞察: 关键张力不在于人们反对 Agent,而在于他们能在哪里观察并介入。Antigravity 的回复质疑的是发布口径,而 GitHub 的 Mobile 界面则把“需要输入”明确做成了一种控制状态。
与前一天的比较: 前一天对 Agent 团队运作的关注仍在延续,但证据开始转向面向用户的监督界面:手机通知,以及编辑器内的安全检查。
1.2 团队正在把模型组合成不同角色,而不是只选一个赢家(🡕)¶
从业者把模型选择描述为任务路由问题。一则一手经验更倾向于让较小模型处理基础和中等复杂度工作;另一则则在自定义扩展中,把规划、实现和审查分配给不同 Agent。
@burkeholland 报道称(57 个赞,10 条回复,3,715 次浏览)讲述了作者在 GitHub Copilot 中使用 GPT-5.6 Luna 承担大量工作,包括 UI 工作,而作者原本以为自己已经不再需要较小模型。附带的 Copilot 截图显示,一项主题变更任务从规划和文件搜索推进到已修改文件计数和渲染预览;作者随后又把这番肯定收窄到基础和中等难度任务。一条回复补充说,更高的推理强度可能会抹平速度和成本优势;另一条则提到,持续积累的对话记录和项目上下文也有价值。

@davis7 描述(23 个赞,4 条回复,554 次浏览)介绍了一个自定义 Pi 扩展:由 Claude Code 子 Agent 研究 API 设计,由 Codex 子 Agent 负责实现,再由 Claude Code 子 Agent 审查简洁性和正确性。作者称动态工作流这一层还不够成熟,并表示可能需要桌面应用;这也有效地区分了一个可运行的个人工作流与一款完成的产品。
讨论洞察: Luna 这条讨论支持的结论,比“较小模型取代前沿模型”要窄得多:人们看重它们处理日常工作的能力,但上下文连续性、推理设置和价格仍然决定选择。
与前一天的比较: 昨天的讨论强调并行编排;今天最突出的新细节,则是由不同模型支撑的 Agent 之间开始出现角色分工。
1.3 产品趋同正在带来导航与连续性问题(🡕)¶
这一天还暴露出一个产品设计层面的代价:当聊天、编程和自主工作被折叠进同一个界面时,导航和连续性会成为问题。这并不是抽象的品牌抱怨:回复里点名提到了移动端与桌面端行为不同,以及项目或历史记录无法在不同模式之间顺畅迁移。@emollick 对比(99 个赞、18 条回复、7,321 次浏览)指出,Claude 的 Home/Code 与 Chat/Cowork 选项,对应着 OpenAI 的 ChatGPT Work/Codex 划分,而且不同网站上的划分又不一样。在回复中,@simonw 表示,移动端 Chat 与 Work 的差异是实质性的,而桌面端 Codex 与 Work 的区别只是表面上的;另一条回复则称,在一种模式下创建的 Projects 不会出现在另一种模式中。一位使用 Claude Cowork web-beta 的用户则给出了反例,称其网页端与桌面端 UI 是一致的。
@signulll 认为(80 个赞、14 条回复、8,020 次浏览)认为,把 Codex/“ChatGPT Work”并入 ChatGPT 是一次明智的分发动作。回复意见分化:一位读者为这次合并辩护,认为它是必要的;另一位则表示,这样做会丢失聊天记录,也让纯聊天场景的体验变差。
讨论洞察: 分发与可用性正在朝相反方向拉扯。回复表明,用户确实需要从聊天顺畅交接到工作流,但并不希望模式边界把历史记录或资产藏起来。
2. 什么最让人沮丧¶
工作模式割裂,连续性丢失¶
严重程度:中等。核心抱怨并不是聊天和智能体工作并存,而是用户无法预判某项能力或其历史记录到底归属于哪里。@emollick 记录(99 个赞、18 条回复、7,321 次浏览)指出,不同产品和不同界面上的 Home、Code、Chat、Cowork、Work 与 Codex 标签彼此冲突;回复则提到移动端存在实质性差异,以及项目会按模式分隔。@signulll 将其定义为(80 个赞、14 条回复、8,020 次浏览)将 Codex/ChatGPT 的整合视为一种分发策略,但有回复称这会导致聊天记录丢失,并让纯聊天使用变得更差。讨论中可见的应对方式,是停留在能保留任务上下文的那个界面;没有证据表明目前已有完整的跨模式解决方案。这值得投入开发,因为它影响的不只是偏好,更关系到任务发现与连续性。
强大的浏览器上下文伴随着明确的信任边界¶
严重程度:高。@PablitoPool 分享(689 次浏览、3 次收藏)介绍了一个 OpenCode bridge,可调用真实 Chrome 配置文件中的标签页、会话、历史记录、书签、截图、页面文本以及 Chrome DevTools Protocol。其 README 使用本地 native-messaging host 和轮换 bearer token,但也明确警告用户:由于它访问的是真实配置文件而非隔离浏览器,因此只能在受信任的本地工作流中运行。实际缺口在于,如何在已认证的浏览器上下文之上实现安全、可检查的委派。在当前设计里,便利性与暴露风险是绑定在一起的。这值得投入开发,因为在现有设计下,二者不可分割。
模型路由不断变化,使用限额仍然难以理解¶
严重程度:中等。在 @burkeholland 的 Luna 报告 下方,一条回复(57 个赞、10 条回复、3,715 次浏览)称,自己在另一个模型下把重置次数耗尽后,随后又收到了 3 次额外重置;另一位回复者则认为,更高的推理强度会让 Luna 更慢,而且也没便宜多少。@jumperz 表示(12 个赞、5 条回复、695 次浏览)称,自 GPT-5.6 发布以来,Codex 限额已被反复重置;这只是单个用户的观察,并非经核实的产品政策。目前可见的应对方式,是手动监控重置情况,并切换模型或推理设置。这值得投入开发,方向应是提供透明的跨模型预算与重置可见性。
3. 人们希望出现什么¶
从聊天贯穿到自主工作的单一连续工作空间¶
这些讨论并没有提出正式的功能请求,但展示了一个现实需求:从对话开始,把任务交给工作流,监督执行过程,再返回时不丢失历史记录或资产。@emollick 披露(99 个赞、18 条回复、7,321 次浏览)指出,Chat、Work、Codex、Home、Code 与 Cowork 之间存在令人困惑的重叠;一条回复还称 Projects 会按模式分开。@github 新增(66 个赞、4 条回复、30,371 次浏览)展示了对远程 Copilot CLI 会话进行移动端干预的需求,这正是这一生命周期中的一个环节。对于执行长任务的用户来说,这一需求既现实又迫切;局部解法已经存在,但跨界面的统一连续性模型仍然缺失。机会:直接。
具备作用域权限的可复用智能体能力¶
供给侧最强的回应,是可复用的技能、插件和桥接工具,但它们的权限边界仍然是按工具分别定义的。@koruneko32767 指向(215 次浏览,2 个书签)Microsoft 的 Power Platform 技能市场,其插件覆盖多个开发环节;除广泛的自动批准外,还记录了更安全的允许列表做法。@PablitoPool 分享(689 次浏览,3 个书签)这是一个可保留会话上下文的浏览器桥接工具,但同时警告称,它只应在受信任的本地环境中使用。实际需求是让这类可移植能力在运行前就声明自己可访问的文件、服务和浏览器状态。机会:竞争型。
清晰的预算与推理模式控制¶
围绕 Luna 的讨论表明,更便宜、更小的模型也能有用,但其价值会随推理强度、项目上下文和重置可用性而变化。@burkeholland 报道称(57 个赞,10 条回复,3,715 次浏览)给出了其在 UI 和常规任务上的积极结果,回复中则补充了成本方面和上下文连续性方面的注意事项。该讨论串的一条回复还提到,出现了意料之外的额外重置。实际需求是:在任务开始前就能看到模型选择、推理设置、预期预算和剩余额度;现有证据表明,目前依然主要靠人工观察,而不是统一的控制界面。机会:直接。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 倾向 | 优势 | 局限 |
|---|---|---|---|---|
| Copilot CLI + GitHub Mobile | Agent CLI 与移动端监督 | (+) | 手机实时通知、进度更新、需要输入的提醒,以及返回会话日志的路径 | 此次发布解决的是监督问题,而非跨界面的完整任务连续性 |
Copilot 应用 /security-review |
编辑器内安全审查 | (+) | 高置信度发现、严重性/置信度标注,以及针对当前更改的可执行修复建议 | 公开预览阶段;重点在安全审查,而非更广泛的代码质量 |
| GitHub Copilot 中的 GPT-5.6 Luna | 编码模型 | (+/-) | 一手报告称,其在基础/中等难度任务和 UI 工作上速度很快 | 更高的推理强度可能缩小其速度/成本优势;现有上下文也会影响切换 |
| Pi 扩展 | 多智能体编排 | (+/-) | 在 Pi、Claude Code 和 Codex 之间分派研究、实现和审查工作 | 个人扩展;作者称工作流打磨尚未完成,TUI 限制仍然存在 |
| Power Platform 技能 | 插件市场 | (+) | 面向 Power Platform 工作负载的官方可复用技能、智能体和命令 | 权限配置依然影响重大;广泛自动批准会授予机器级访问权限 |
| OpenCode Chrome Bridge | 浏览器控制桥 | (+/-) | 通过扩展和本地桥接访问真实配置文件中的标签页、会话、历史记录、截图和 CDP | 可触达已认证的浏览器上下文;README 将安全使用范围限定为受信任的本地工作流 |
| Supabase + Vercel + Claude Code | 生产应用工作流 | (+) | 为非工程师构建者提供预览 PR、预览数据库、共享数据,以及一套可复用的技术栈 | 需要经过工程化设计的工作流,才能让快速构建保持一致且安全 |
整体反馈从对更可观测控制界面的积极认可,到对权限、成本和 UI 碎片化的谨慎不等。迁移模式并不是从一个供应商简单切换到另一个供应商:@davis7 使用(23 个赞,4 条回复,554 次浏览)会针对研究、实现和审查使用不同智能体,而 @burkeholland 使用(57 个赞,10 条回复,3,715 次浏览)则表明,人们会把原本似乎需要更大模型的工作交给更小的模型。常见的变通方式包括按角色分流、手动跟踪重置次数,以及尽量把工作保留在能维持上下文的界面内。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Expert AI Developer Skills | @jggomezt | 为编码智能体提供可复用技能、行为规则、SDLC 工作流、sidecar 和后端插件 | 让质量门禁、测试规则、分支安全和安全检查成为可复用能力,而不是每次都重新提示 | Markdown 技能/规则/工作流;Python 后端;MCP 集成 | 已发布 | 仓库 |
| Power Platform Skills | Microsoft | 面向构建 Power Platform 应用与自动化的智能体插件市场 | 为 Copilot 和 Claude Code 提供适用于受支持企业工作负载的任务专用技能和命令 | React、TypeScript、Vite、Expo、Node.js、PAC CLI、MCP | 已发布 | 仓库 |
| OpenCode Chrome Bridge | @PablitoPool | 让 OpenCode 通过本地桥接控制真实的 Chrome 配置文件 | 保留已认证的浏览器上下文,而不是在无头会话中重新创建 | Chrome MV3 扩展、Node.js 原生主机、本地 HTTP 桥、OpenCode 插件、CDP | 已发布 | 仓库 |
| Pi 多智能体扩展 | @davis7 | 由 Pi 主导、可按不同角色调用 Claude Code 和 Codex 子智能体的系统 | 在同一工作流中协调研究、实现和审查 | Pi、Claude Code、Codex、Effect v4 | Alpha | Author |
Copilot app /security-review |
GitHub | 审查未提交或进行中的更改,寻找高置信度安全发现 | 将有针对性的漏洞检查提前到编码循环中 | GitHub Copilot app | Beta | 发布说明 |
这些项目体现出相同的构建模式:围绕现有智能体封装一种可操作能力,而不是替换智能体本身。@jggomezt 展示(2 个赞,2 条回复,75 次浏览)将技能、规则、工作流和 sidecar 辅助组件打包成一套方案;而 @koruneko32767 分享(215 次浏览,2 个收藏)则是一个官方市场,把同一理念映射到 Power Platform 任务上。Chrome bridge 是另一种相关但不同的回应:它为代理补上了原本缺失的有状态外部上下文,而它自身的警告也让信任边界成为产品的一部分。
生产环境中的参考案例是 delight.ai 的工作流:其案例研究称,20–25 个 Supabase 项目通过 Claude Code pull requests、Vercel 预览环境、Supabase 预览数据库和共享的 Prisma monorepo,为 200 多个应用提供支持。@supabase 报道称(6 个赞,2 条回复,804 次浏览)表示,这套配置让这家拥有 220 名员工的公司能够在不抽调工程师离开核心产品的情况下持续交付;案例研究还称,一名 AI 工程师搭建了安全与一致性保障层。
6. 新动态与值得关注的进展¶
在当前编码界面内进行安全审查¶
@GHchangelog 宣布(12 个赞,1 条回复,2,079 次浏览)表示,/security-review 已在 GitHub Copilot 应用中进入公开预览。其 发布说明 明确提到,会提供高置信度发现项及其严重程度和置信度、可执行的修复方案,并聚焦检查当前变更。值得注意的是,这把一项面向安全的代理能力,变成了代码合入前可按需执行的检查。
面向远程 CLI 工作的移动端干预¶
@github 宣布(66 个赞,4 条回复,30,371 次浏览)表示,GitHub Mobile 可以就远程 Copilot CLI 的进度和所需输入通知用户,然后带他们返回日志界面。图片中的“需要输入”通知让这一产品主张变得具体:异步工作仍然会在某些刻意设置的节点需要人工关注。
7. 机遇所在¶
[+++] 跨界面任务连续性 — 综合证据表明,聊天/工作模式之间存在混淆,相关产物可能无法跨模式流转,而手机端层面的干预点也刚刚出现。一款能够在聊天、桌面、远程会话和移动端之间保留任务历史、产物、权限和审批状态的产品,将满足直接的运营需求。
[++] 受权限控制的上下文桥接 — OpenCode Chrome Bridge 展示了利用实时浏览器会话的需求,而它自身关于受信任本地环境的警告,也说明经过身份验证的状态需要可检查的权限范围、可见的访问日志和撤销机制。可复用技能市场也进一步强化了对明确工具权限的同类需求。
[++] 模型路由与预算遥测 — Luna 讨论串和 Pi 的角色路由工作流表明,团队选择模型时看重的是任务角色、推理水平、现有上下文、速度和成本,而不是单一基准。一个能在代理启动前估算并落实这些权衡的控制层,将能回应重置和可见性方面的顾虑。
[+] 面向非工程师构建者的生产防护机制 — delight.ai 的案例研究把快速的 AI 辅助构建,与 PR 预览、预览数据库、共享数据以及由工程团队负责设计的工作流结合起来。机遇在于,将这些防护机制打包成产品,提供给那些希望增加构建者、又不想让生产环境访问失控的团队。
8. 要点¶
- 当前可见的前沿,是监督代理工作,而不只是启动它。 GitHub Mobile 现在会提示远程 CLI 的进度以及卡住所需的输入,而 Copilot 应用也已具备进行中的安全审查。@github 宣布(66 个赞,4 条回复,30,371 次浏览);@GHchangelog 宣布(12 个赞,1 条回复,2,079 次浏览)。
- 多智能体实践正演变为角色路由。 一套定制的 Pi 工作流将研究和评审交给 Claude Code,将实现交给 Codex;另一位 Copilot 用户则表示,会让较小的模型处理 UI 和常规任务。@davis7 描述(23 个赞,4 条回复,554 次浏览);@burkeholland 报道(57 个赞,10 条回复,3,715 次浏览)。
- 上下文连续性如今已成为产品约束。 在关于 ChatGPT/Codex 和 Claude 产品界面的讨论回复中,用户提到两者在移动端的表现存在明显差异,项目会因模式不同而被拆分,聊天记录也会丢失。@emollick 对比(99 个赞,18 条回复,7,321 次浏览);@signulll 指出(80 个赞,14 条回复,8,020 次浏览)。
- 开发者正在围绕智能体交付工作流层。 公开项目提供技能、市场插件、浏览器上下文和评审检查;最强的生产案例则在同一套模型辅助工作流中加入了预览环境和共享数据。@jggomezt 提出(2 个赞,2 条回复,75 次浏览);@supabase 报道(6 个赞,2 条回复,804 次浏览)。