Twitter AI 编程 - 2026-06-25¶
1. 人们在讨论什么¶
1.1 Codex 开始显现出覆盖全公司的执行层形态（🡕）¶
最明确的主题是，Codex 正在从软件工程扩展为面向知识工作的通用执行界面。四条保留内容共同支撑了这一判断：OpenAI 员工分享了部门级使用数据，一份外部总结披露了论文层面的增长数字，另一位 OpenAI 员工则列举了已经交给 Codex 处理的日常非工程任务。
@thsottiaux 分享（516 个赞、76 条回复、30,759 次浏览、54 个书签）一张图片显示，Codex 在 OpenAI 各部门产出中的占比已升至：工程 99%、财务 91%、招聘 89%、法务 88%；而被引用的 OpenAI 帖子 表示，这个工具已经被用于公司内部耗时更长、跨职能的工作。
@Hesamation 总结（4 个赞、2 条回复、1,540 次浏览、3 个书签）提到公开的 论文《迈向智能体式 AI：来自 Codex 的证据》，其中指出：2026 年上半年活跃用户增长了 5 倍；技能使用率从 3 月的 5.4% 升至 6 月的 26.6%；分配 8 小时以上任务的用户占比则从 12 月的 2.1% 升至 5 月的 25.6%。
@reach_vb 表示（46 个赞、7 条回复、3,913 次浏览、5 个书签）称，同事们已经在用 Codex 采购杂货、报税、填写表格、跟进邮件和管理财务。这一点很关键，因为它把论文里的采用数据变成了具体证据，说明编程智能体工作流正在外溢到行政事务中。
讨论洞察： 回复持续把这一转变定义为“委托工作”，而不是“更好的聊天”。该讨论串下方一条 OpenAI 回复称，2 月 Codex 应用发布后，工程之外的采用率才开始明显加速。
与前一天对比： 6 月 24 日的讨论已经把 Codex 视为不只是纯粹的编程助手。到了 6 月 25 日，则新增了更硬的公开衡量指标：分部门占比图、用户增长数据，以及长期委托任务正在成为常态的明确证据。
1.2 GitHub 持续把 Copilot 打造成智能体平台，而不只是聊天外壳（🡕）¶
第二个主题是，GitHub 正在围绕 Copilot 增加更多工作流基础设施，而不是追逐某个单一的头条模型。三条保留内容共同支撑了这一点：Copilot 应用被描述为自动化和 MCP 的承载平台，Agent Finder 把技能和 MCP 发现做成了产品界面，而 Copilot CLI 则通过语言服务器获得了通向语义代码智能的公开路径。
@github 展示（94 个赞、10 条回复、22,979 次浏览、35 个书签）将 Copilot 应用描述为承载自动化、MCP 集成和自定义技能的平台。最有分量的回复并不理想化，而是集中在实际问题上：一位用户质疑，在速率限制仍会打断工作的情况下，这个应用到底有什么意义；另一位用户则要求提供原生级 WSL 支持。
@_Evan_Boyle 宣布（70 个赞、6 条回复、4,163 次浏览、28 个书签）介绍了 Agent Finder——一个用于在 Copilot 应用内发现技能、MCP 和其他扩展的语义搜索引擎。他在后续回复中表示，它使用 LLM 驱动的搜索与重排序；另一条回复则立刻提出了核心信任问题：用户如何避免恶意技能。Boyle 回应称，目前索引暂时仍由人工策展。
@github 宣布（71 个赞、9 条回复、13,972 次浏览、20 个书签）介绍了 Copilot CLI 的新 LSP Setup 技能。GitHub 公开的 博客文章 表示，该技能会为 14 种语言安装并配置语言服务器，让 CLI 能利用定义、引用和类型信息，而不再依赖文本搜索式启发；回复里也补充了两个注意点：一位开发者警告，大型项目中的 LSP 冷启动可能很慢；另一位则表示，计费调整已经促使其团队转向 Claude 和 Codex。
讨论洞察： 信任问题上移了一层。人们不再主要担心 Copilot 能不能生成代码，而是更在意扩展是否安全、冷启动表现如何、Windows/WSL 兼容性怎样，以及计费是否足以支撑可持续工作流。
与前一天对比： 6 月 24 日强调的是桌面端分发和 BYOK。6 月 25 日则更偏基础设施，重点转向发现机制、语义代码导航，以及把 Copilot 变成可扩展智能体运行时的具体实现。
1.3 构建者持续把编程智能体封装成相邻领域的操作系统（🡕）¶
第三个主题是，构建者正在把熟悉的编程智能体界面当成其他类型工作的控制平面。四条保留内容共同支撑了这一趋势：OpenMontage 把编程智能体改造成视频制作流水线，My Brain Is Full — Crew 把智能体接入 Obsidian 和电子邮件，Cockpit 为 Copilot CLI 增加桌面外壳，而 Windows Copilot API 则把消费级 Copilot 登录转成了本地 OpenAI 兼容端点。
@TheWhizzAI 重点介绍（6 个赞、6 条回复、326 次浏览、2 个书签）将 OpenMontage 描述为一种把 Claude Code、Copilot、Cursor 或 Codex 变成完整视频制作系统的方法。公开的 仓库 介绍称，该项目围绕调研、脚本撰写、素材生成、剪辑和最终合成，构建了 12 条流水线、52 个工具和 500+ 项智能体技能。
@DanKornas 分享（8 个赞、3 条回复、1,068 次浏览、11 个书签）介绍了 My Brain Is Full — Crew。公开的 仓库 称，它使用 8+ 个智能体和 14 项技能来管理 Obsidian 仓库、搜索笔记、分拣邮件，并支持 Claude Code、Gemini CLI、OpenCode 和 Codex CLI 之间的多语言工作流。
@IeuanTWalker 构建了（4 个赞、2 条回复、655 次浏览、2 个书签）介绍了 Cockpit，一个面向 GitHub Copilot CLI 的桌面 GUI。公开项目资料显示，这个围绕 CLI 构建的 C# 外壳支持多会话管理、集成终端、文件附件、差异查看、活动日志和权限控制。
@_jaydeepkarale 提到（2 个赞、1 条回复、252 次浏览、1 个书签）介绍了 Windows Copilot API，一个非官方 Python 桥接工具，可将已登录的 Microsoft Copilot 会话暴露为本地 OpenAI 兼容 API。其仓库明确将其定位为个人用途自动化，而不是 Microsoft 官方接口。
讨论洞察： 这些项目都建立在同一个前提上：用户想保留自然语言驱动、智能体优先的工作流，但希望把它导向视频制作、个人知识系统、桌面监督或低成本本地路由，而不是等某一家厂商覆盖所有使用场景。
与前一天对比： 6 月 24 日仍主要围绕记忆、可观测性和应用界面扩展。到了 6 月 25 日，可以看到更多构建者正把编程智能体变成特定领域的操作系统，叠加在现有客户端之上，而不是直接取而代之。
2. 什么让人感到沮丧¶
定价、配额和账户控制仍会打断进行中的工作¶
严重程度：高。最持续的挫败感，是当人们想依赖某个工作流界面时，却在关键时刻失去了对模型访问的控制权。@buildwithhassan 表示（3 个赞、1 条回复、81 次浏览）称，Copilot 免费版和学生版已不再允许用户手动选模型，只能使用自动选择。@gideonfip 表示（4 个赞、1 条回复、1,761 次浏览）称，他在计费周期还剩 15 小时时就用完了 OpenCode Go 的月度额度，只能退回到他认为不可靠的免费模型。@github 展示（94 个赞、10 条回复、22,979 次浏览、35 个书签）下的一条回复说明，一些用户仍然是从速率限制的角度看待 Copilot 应用；而 @bdsqlsz 报道称（2 个赞、1 条回复、601 次浏览）则提到自己被随机封禁了 Pro 20X 账户，并丢失了多年的记录。人们的应对方式包括切换套餐、退回免费模型，或求助于非官方桥接工具。这个方向值得投入，因为痛点来得直接，而且会破坏工作流。
安全与来源仍需要明确的防护栏¶
严重程度：高。多条帖子显示，智能体工作流仍在制造本可避免的信任问题。@samelldev 警告（3 个赞、1 条回复、32 次浏览）称，Claude Code v2.1.179 会通过默认 attribution trailer 将会话 URL 追加进 git 历史；截图中还附带了关闭 sessionUrl 的设置修复方法。在 @_Evan_Boyle 宣布推出（70 个赞、6 条回复、4,163 次浏览、28 个书签）关于 Agent Finder 的讨论下，最早出现的实质性问题之一就是：用户如何避免安装恶意技能或 MCP。Boyle 回应称，目前目录暂时由人工策展。甚至公开的 Windows Copilot API 仓库 也明确说明它是非官方且仅供个人使用；这本身就是一个信号，说明人们正在通过不受支持的路径获取自己想要的控制权。人们的应对方式包括关闭相关功能、依赖人工策展，以及优先使用自己可以检查的本地封装工具。这个方向值得投入，因为失败模式并不是抽象的不信任，而是来源泄露、扩展可信度不清，以及不受支持的变通方案。
Windows 和环境集成仍落后于产品宣传¶
严重程度：中到高。产品界面的扩张速度，快于其环境处理能力的成熟速度。@awakecoding 表示（6 个赞、2 条回复、671 次浏览）称，他已经找到了 Windows 版 GitHub Copilot 应用为什么识别不到 PATH 中可见命令行工具的原因，并链接到一条公开的 GitHub issue 评论。在主帖 @github 应用线程（94 个赞、10 条回复、22,979 次浏览、35 个书签）下，另一条回复明确要求提供原生级 WSL 支持。而在 @github LSP Setup 发布公告（71 个赞、9 条回复、13,972 次浏览、20 个书签）下，一位开发者警告，大型项目中的 LSP 冷启动可能让首次有用响应延迟 40 秒甚至更久。人们只能手动调试 PATH 行为、收窄对平台支持的预期，并把语义工具视为仍需谨慎配置的组件。这个方向值得投入，因为它会在模型质量真正发挥作用前，就先在环境层面阻碍采用。
3. 人们希望有什么¶
不离开智能体界面，也能选择模型并控制支出¶
最强烈的实际需求，是在保留同一工作流界面的同时，改变其底层经济性。@buildwithhassan 表示（3 个赞、1 条回复、81 次浏览）称，低档位 Copilot 用户失去了手动选择模型的能力；@gideonfip 表示（4 个赞、1 条回复、1,761 次浏览）称，OpenCode Go 的额度限制迫使他退回到不可靠的备用模型；@_jaydeepkarale 提到（2 个赞、1 条回复、252 次浏览、1 个书签）则提到了一个非官方的 Windows Copilot API 桥接工具，因为市场上仍然存在对无需官方 API 计费即可获得 OpenAI 兼容访问的需求。这是一个非常实际的需求，而且用户已经明确表现出绕开官方产品边界的意愿。机会：直接。
跨会话、跨工具的持久且可检查的工作流记忆¶
人们还希望，工作流本身在聊天窗口变化后仍能继续存在。@Hesamation 总结（4 个赞、2 条回复、1,540 次浏览、3 个书签）提到，Codex 的技能使用率在 6 月升至 26.6%，而强度最高的用户每天会并行运行很多小时的智能体工作，这正是最容易压垮单会话记忆的使用模式。@DanKornas 分享（8 个赞、3 条回复、1,068 次浏览、11 个书签）介绍了 My Brain Is Full — Crew，把它作为面向 Obsidian 的跨平台记忆与分拣外壳；而 @IeuanTWalker 构建了（4 个赞、2 条回复、655 次浏览、2 个书签）则介绍了 Cockpit，用于在同一个桌面界面中保留多个 Copilot CLI 会话、历史和活动的可见性。这一需求很实际，也已经出现一定竞争，但仍未得到充分满足。机会：竞争性。
更安全、来源更清晰的扩展生态¶
第三个需求是：当智能体安装工具、写入提交或以更高自主性执行操作时，扩展系统仍应保持可检查性。在 @_Evan_Boyle 上线（70 个赞、6 条回复、4,163 次浏览、28 个书签）关于 Agent Finder 的讨论下，最早出现的问题之一就是如何过滤恶意技能和 MCP，而当前答案仍是人工策展。@samelldev 警告（3 个赞、1 条回复、32 次浏览）则提到，Claude Code 的会话标识符会默认泄露到 git 历史中。这一需求既实际又紧迫，并且直接关系到人们对更高自主性工作流的信任。机会：直接。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Codex | 编程智能体 | (+) | 公开论文和 OpenAI 员工帖子显示，其在长期、跨职能任务和技能复用上的采用非常强劲 | 用户仍然报告账户封禁、配额依赖，以及对功能上线节奏的不满 |
| GitHub Copilot 应用 | 桌面智能体工作区 | (+/-) | 自动化、MCP 集成、自定义技能、扩展发现 | 速率限制投诉、WSL 诉求，以及 Windows 环境上的粗糙体验 |
| GitHub Copilot CLI + LSP Setup | CLI / 代码智能 | (+/-) | 为 14 种语言增加定义、引用和类型感知导航 | LSP 冷启动可能较慢；一些团队仍将计费视为转向其他工具的理由 |
| Linear 外部智能体 | 工单跟踪运行时 | (+) | 让工单成为人类与智能体共享的执行边界 | 回复很快就要求提供更多模型控制选项，例如 BYOK |
| Claude Code | 编程智能体 | (+/-) | 在 XDA 前端对比中凭借 UX 打磨胜出；生态吸引力强 | 会话归因泄露和来源问题削弱了信任 |
| OpenCode Go / Zen | 调度框架 / 模型路由 | (+/-) | 为用户提供备用提供商和免费模型入口 | 月度上限和可靠性投诉依然明显 |
| OpenMontage | 智能体式视频制作框架 | (+) | 将编程智能体扩展到调研、脚本、剪辑、字幕和渲染 | 需要偏代码化的配置方式，且仍假定用户熟悉仓库驱动工作流 |
| My Brain Is Full — Crew | 知识 / 记忆系统 | (+) | 用多智能体、多技能外壳整合 Obsidian、电子邮件和会议 | 工作流较小众；价值取决于是否持续维护 Obsidian 风格知识库 |
| Windows Copilot API | 本地 API 桥接 | (+/-) | 借助已登录 Copilot 账户提供免费的 OpenAI 兼容端点 | 非官方、仅供个人使用，并且依赖浏览器/会话自动化 |
| Cockpit | Copilot CLI 图形外壳 | (+) | 增加多会话控制、终端可见性、历史、附件和差异查看 | 仍属早期生态工具，目前采用信号有限 |
整体满意度呈两极分化。人们喜欢那些能扩大智能体能力边界、或让智能体更容易被监督的工具；但一旦这些界面隐藏了模型选择、配额边界或扩展来源，用户也会迅速提出反对。
最常见的变通模式是保留工作流、替换基础设施：使用非官方本地桥接工具、退回免费模型、给 CLI 加一层 GUI，或者把更多状态交给技能和旁路工具，而不是依赖单一厂商的界面。
迁移的核心并不是放弃智能体，而是围绕智能体继续封装。Codex、Copilot、Claude Code 和 OpenCode 依然是中心，但最有意思的变化发生在外壳、桥接、记忆层和特定领域工具包上，它们改变了这些智能体的使用方式。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| OpenMontage | calesthio | 将编程智能体变成端到端视频制作系统 | 编程智能体可以写代码，但通常止步于调研、旁白、剪辑、字幕和渲染之前 | Python、FFmpeg、Node/Remotion、多提供商媒体流水线、500+ 项智能体技能 | 已发布 | 仓库 |
| My Brain Is Full — Crew | gnekt | 用一组智能体管理 Obsidian 仓库、邮件分拣和个人知识工作流 | 如果没有智能体式组织与召回能力，第二大脑系统本身会变成另一项维护负担 | 基于 Shell 的安装器、Obsidian 工作流，支持 Claude Code、Gemini CLI、OpenCode 和 Codex CLI 的多平台方案 | 已发布 | 仓库 |
| Cockpit | Ieuan Walker | 在 GitHub Copilot CLI 之上增加桌面 GUI | Copilot CLI 用户希望能看见会话历史、差异、终端输出，并控制多个会话 | C#、集成终端、差异查看器、活动日志、附件支持 | Alpha | 网站 |
| Windows Copilot API | sums001 | 将已登录的 Microsoft Copilot 会话暴露为本地 OpenAI 兼容 API | 开发者希望获得 API 风格访问，而无需承担官方 API 计费或更换客户端界面 | Python、Playwright/浏览器会话自动化、本地 OpenAI 兼容服务器 | Beta | 仓库 |
OpenMontage 是今天构建者模式最清晰的例子。@TheWhizzAI 重点介绍（6 个赞、6 条回复、326 次浏览、2 个书签）将其描述为一种让 Claude Code、Copilot、Cursor 或 Codex 处理调研、脚本撰写、媒体生成、旁白和最终合成的方法；公开仓库则围绕这一主张记录了 12 条流水线、52 个工具和 500+ 项智能体技能。
My Brain Is Full — Crew 则把同样的封装冲动推向了另一个方向。@DanKornas 分享（8 个赞、3 条回复、1,068 次浏览、11 个书签）将其描述为一个面向 Obsidian 和电子邮件的 8 智能体、14 技能外壳；仓库明确把聊天定义为界面，把知识库定义为持久记忆。
Cockpit 和 Windows Copilot API 的信号更弱，但同样有启发性。@IeuanTWalker 构建了（4 个赞、2 条回复、655 次浏览、2 个书签）之所以做 GUI，是因为 Copilot CLI 仍给更直观的控制留下了空间；而 @_jaydeepkarale 提到（2 个赞、1 条回复、252 次浏览、1 个书签）之所以做非官方桥接，则是因为人们仍然想在不更换客户端的前提下获得 API 风格访问。
反复出现的构建模式并不是“新的基础模型”，而是“围绕现有智能体的新外壳”：更多记忆、更强领域针对性、更好的 UI，或更低成本的路由。这直接回应了信息流中最大的两个压力：工作流连续性和访问摩擦。
6. 新动态与值得关注的内容¶
公开指标终于为智能体化转变提供了硬数字¶
最新、最重要的新证据是公开的，而不只是轶事。@Hesamation 总结（4 个赞、2 条回复、1,540 次浏览、3 个书签）提到了公开的 Codex 论文，而 @thsottiaux 分享（516 个赞、76 条回复、30,759 次浏览、54 个书签）则提到了内部部门图表。两者共同把讨论从“智能体似乎变得更重要了”推进为关于增长、长期任务、多智能体管理和跨职能使用的可量化主张。
一个具体的 Claude Code 来源泄露陷阱在真实环境中出现¶
@samelldev 警告（3 个赞、1 条回复、32 次浏览）称，在 v2.1.179 中，Claude Code 会默认把会话 URL 写入 git 历史；配套截图还展示了阻止这一行为所需的设置变更。这一点之所以重要，是因为它不是抽象的供应链或隐私担忧，而是主流编程智能体工作流中一个具体、可复现的来源泄露问题。
7. 机会在哪里¶
**+++］ 具备成本感知、可选模型的智能体入口界面**——多个部分都指向同一个缺口：低阶 Copilot 用户失去了模型选择权，OpenCode 用户触及月度上限，Copilot 应用用户仍在抱怨速率限制，而像 ［Windows Copilot API 这样的非官方桥接方案 之所以受到关注，是因为官方访问路径仍然显得过于僵硬。最强的机会，是在保持工作流界面稳定的同时，把模型选择、用量消耗和故障切换做得明确且可控。
[++] 具备更强可见性和来源追踪能力的工作流外壳 —— Cockpit、Agent Finder、Copilot 应用，以及 Claude Code 会话泄露提醒，都表明市场需要更好的智能体监督层。能在信任真正破裂前，让用户检查会话、权限、扩展和提交来源的产品，正面临中等但持续扩大的机会。
[+] 面向非代码领域的智能体改造工具包 —— OpenMontage、My Brain Is Full — Crew，以及 OpenAI 员工关于采购杂货、报税和处理邮件的帖子，都说明编程智能体正在被改造成媒体、知识工作和个人行政事务等相邻领域的操作系统。相关信号仍在形成，但值得注意的是，构建者是在扩展现有智能体客户端，而不是等待新的垂直产品出现。
8. 要点¶
- 今天最强的信号是衡量，而不是营销。 关于 Codex 的公开证据已经从轶事推进到图表和论文层面的采用数据，包括活跃用户增长 5 倍，以及长期任务占比的陡升。（来源）
- GitHub 的竞争动作在于工作流深度。 Agent Finder、应用原生自动化和基于 LSP 的代码智能，都在推动 Copilot 走向可扩展运行时；但回复也显示，扩展信任、Windows 体验粗糙以及计费方式，仍然决定用户是否会留下。（来源）
- 当官方访问过于僵硬时，用户会容忍非官方桥接。 Windows Copilot API、OpenCode 的回退行为，以及对强制自动选择的抱怨，都表明用户需要更便宜、可控性更高的后端访问，同时又不想改变顶层工作流。（来源）
- 最有意思的构建者活动发生在智能体周围，而不是它们之下。 OpenMontage、My Brain Is Full — Crew 和 Cockpit 都是在熟悉的编程智能体外再包一层新的记忆、UI 或领域控制层，而不是试图直接替代基础模型。（来源）