Twitter AI 编程 - 2026-06-25¶
1. 人们在讨论什么¶
1.1 Codex 开始显露出公司级执行层的样子 (🡕)¶
最清晰的主题，是 Codex 正在从软件工程扩展成知识工作的通用执行界面。4 条保留下来的内容支撑了这一点：OpenAI 员工分享了按部门划分的使用数据，一则外部总结带出了论文层面的增长数字，另一位 OpenAI 员工则列出了已经交给 Codex 的日常非工程任务。
@thsottiaux 分享了（516 点赞、76 回复、30,759 浏览、54 收藏）一张图片，显示 Codex 在 OpenAI 输出中的占比已升至工程部门的 99%、财务的 91%、招聘的 89% 和法务的 88%；而被引用的 OpenAI 帖子 则表示，这个工具已经被用于公司内部更长周期、跨职能的工作。
@Hesamation 总结了（4 点赞、2 回复、1,540 浏览、3 收藏）公开论文 《The Shift to Agentic AI: Evidence from 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 app 的发布。
与前日对比：6 月 24 日已经把 Codex 看得不只是一个纯粹的编程助手。到 6 月 25 日，公开的硬指标出现了：按部门划分的占比图、用户增长数字，以及长周期委派任务正在常态化的明确证据。
1.2 GitHub 继续把 Copilot 打造成智能体平台，而不只是聊天外壳 (🡕)¶
第二个主题是，GitHub 正在围绕 Copilot 补齐更多工作流基础设施，而不是只追逐某一个头部模型。3 条保留下来的内容支撑了这一点：Copilot app 成了自动化、MCP 和自定义技能的承载面；Agent Finder 把技能和 MCP 的发现做成了产品能力；Copilot CLI 则通过语言服务器拿到了通往语义代码智能的公开路径。
@github 展示了（94 点赞、10 回复、22,979 浏览、35 收藏）Copilot app 作为自动化、MCP 集成和自定义技能的入口。最有代表性的回复都很现实，而不是理想化：有人问，既然限流还是会打断工作，那这个 app 的意义到底是什么；也有人直接要求一等公民级别的 WSL 支持。
@_Evan_Boyle 发布了（70 点赞、6 回复、4,163 浏览、28 收藏）Agent Finder——一个用于在 Copilot app 内发现技能、MCP 和其他扩展的语义搜索引擎。他在后续回复中说，这个功能使用了 LLM 驱动的搜索和重排序；而另一条回复立刻抛出了信任问题：用户要怎么避开恶意技能？Boyle 回答说，目前索引还是人工策展的。
@github 宣布了（71 点赞、9 回复、13,972 浏览、20 收藏）Copilot CLI 新的 LSP Setup skill。GitHub 的公开博客文章称，这个技能会为 14 种语言安装并配置语言服务器，让 CLI 可以使用定义、引用和类型信息，而不是依赖文本搜索启发式；回复中也补充了两个现实限制：一位开发者提醒，大型项目上的 LSP 冷启动可能很慢；另一位则表示，计费变化已经把他的团队推向 Claude 和 Codex。
讨论要点：信任问题上移了一层。人们关心的已经不太是 Copilot 到底会不会生成代码，而是扩展安全、冷启动表现、Windows/WSL 兼容性，以及计费是否能让这套工作流长期可持续。
与前日对比：6 月 24 日强调的是桌面分发和 BYOK。到 6 月 25 日，讨论更偏基础设施，焦点落在发现、语义代码导航，以及把 Copilot 变成可扩展智能体运行时的具体机制上。
1.3 开发者继续把编程智能体包进相邻的操作系统里 (🡕)¶
第三个主题是，开发者正把熟悉的编程智能体界面当成其他工作类型的控制面。4 条保留下来的内容支撑了这一点：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 变成完整的视频制作系统。其公开 repo 将自己描述为围绕研究、脚本撰写、素材生成、剪辑和最终合成构建的系统，包含 12 条 pipeline、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# shell，包含多会话管理、集成终端、文件附件、diff、活动日志和权限控制。
@_jaydeepkarale 提到了（2 点赞、1 回复、252 浏览、1 收藏）Windows Copilot API，这是一个非官方的 Python bridge，可把一个已登录的 Microsoft Copilot 会话暴露成本地 OpenAI 兼容 API。其仓库明确把它定义为个人自动化用途，而不是微软官方接口。
讨论要点：这些项目都建立在同一个假设上：用户想保留自然语言、智能体优先的工作流，但他们希望把它导向视频制作、个人知识系统、桌面监督，或更低成本的本地路由，而不是等某一家供应商把所有场景都覆盖完。
与前日对比：6 月 24 日仍然更集中在记忆、可观测性和 app 表层扩张上。到 6 月 25 日，更多开发者开始把编程智能体改造成覆盖特定领域的操作系统，建立在现有客户端之上，而不是替换它们。
2. 令人困扰的问题¶
定价、配额和账号控制仍然会在工作中途打断流程¶
严重程度：高。最一致的挫败感，是人们刚想依赖某一个工作流界面时，就失去了对模型访问的控制。@buildwithhassan 表示（3 点赞、1 回复、81 浏览），Copilot 免费版和学生版已不再允许用户手动选模型，只能自动选择。@gideonfip 表示（4 点赞、1 回复、1,761 浏览），他的 OpenCode Go 月度用量上限在周期结束前 15 小时就耗尽了，只能退回到他认为并不可靠的免费模型。@github 这条帖子（94 点赞、10 回复、22,979 浏览、35 收藏）下的一条回复显示，一些用户仍然主要是从“限流会不会打断工作”的角度来看 Copilot app；而 @bdsqlsz 则称（2 点赞、1 回复、601 浏览）自己被随机封禁了一个 Pro 20X 账号，丢掉了多年的记录。人们当前的应对方式，是切换套餐、退回免费模型，或者转向非官方桥接方案。这个方向值得做，因为痛点是即时的，而且会直接打断工作流。
安全性和来源追踪仍然需要明确的护栏¶
严重程度：高。多条帖子显示，智能体工作流仍然会制造本可避免的信任问题。@samelldev 警告（3 点赞、1 回复、32 浏览），Claude Code v2.1.179 会通过默认的署名尾注把会话 URL 附加进 git 历史，截图里还给出了关闭 sessionUrl 的设置修复方法。在 @_Evan_Boyle 发布（70 点赞、6 回复、4,163 浏览、28 收藏）Agent Finder 的帖子下，最早出现的实质性问题之一，就是用户如何避免安装恶意技能或 MCP；Boyle 回答说，目前目录还是人工策展。甚至公开的 Windows Copilot API repo 也明确写着它是非官方且仅供个人使用——这本身就是一个信号，说明人们为了拿到自己想要的控制权，正在走向不受支持的路径。当前的应对方式，是关闭某些功能、依赖人工策展，并优先选择自己能审查的本地封装。这个方向值得构建，因为失败模式不是抽象的不信任，而是来源泄露、扩展信任不清，以及不受支持的绕行方案。
Windows 和环境集成仍然落后于产品宣传¶
严重程度：中到高。产品表层扩张的速度，比环境处理成熟的速度更快。@awakecoding 表示（6 点赞、2 回复、671 浏览），他已经找到了 GitHub Copilot app 在 Windows 上为什么看不到 PATH 中命令行工具的原因，并附上了公开的 GitHub issue 评论链接。在 @github 的 app 讨论串（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 则指向了 非官方的 Windows Copilot API 桥接方案，因为市场上仍然存在对 OpenAI 兼容访问的需求，而不想承担官方 API 计费。这是一个现实需求，也清楚显示出用户愿意绕开官方产品边界。机会：直接切入。
跨会话、跨工具可持续并可检查的工作流记忆¶
人们也希望，当聊天窗口切换时，存活下来的不只是消息，而是整个工作流。@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 会话、历史记录和活动能在一个桌面界面里保持可见。这个需求现实、而且已经有一定竞争，但仍然供给不足。机会：竞争激烈。
更安全、来源更清晰的扩展生态¶
第三个需求，是当智能体会安装工具、写 commit、或以更高自主性行动时，扩展系统仍然要保持可检查。@_Evan_Boyle 发布（70 点赞、6 回复、4,163 浏览、28 收藏）Agent Finder 时，最早被问到的问题之一，就是如何过滤恶意技能和 MCP，而给出的答案是人工策展。@samelldev 警告（3 点赞、1 回复、32 浏览），Claude Code 的会话标识符默认会泄露进 git 历史。这个需求现实而紧迫，并且直接关系到人们是否信任更高自主性的工作流。机会：Direct。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Codex | 编程智能体 | (+) | 公开论文和 OpenAI 员工帖子都显示出强劲的长周期、跨职能采用与技能复用 | 用户仍在报告账号封禁、配额依赖，以及部分功能预期迟迟未兑现 |
| GitHub Copilot app | 桌面智能体工作区 | (+/-) | 自动化、MCP 集成、自定义技能、扩展发现 | 限流抱怨、WSL 请求，以及 Windows 环境层面的粗糙体验 |
| GitHub Copilot CLI + LSP Setup | CLI / 代码智能 | (+/-) | 为 14 种语言增加定义、引用和类型感知导航 | LSP 冷启动可能很慢；一些团队仍把计费视为转向别家的原因 |
| Linear external agents | 工单系统运行时 | (+) | 让工单成为人类和智能体共享的执行边界 | 回复立刻追问更多模型控制选项，例如 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 的 GUI 外壳 | (+) | 增加多会话控制、终端可见性、历史、附件和 diff | 仍是早期生态工具，目前采用信号有限 |
整体满意度呈现两极化。人们喜欢那些能拓宽智能体能力边界、或让其更容易被监督的工具；但一旦这些界面把模型选择、配额边界或扩展来源隐藏起来，反对声音就会很快出现。
常见的权宜方案模式，是保留工作流、替换基础设施：使用非官方本地桥接方案、退回免费模型、给 CLI 外包一个 GUI，或把更多状态推入技能和旁路工具链，而不是依赖某一个供应商的单一界面。
迁移动态更像是“包裹智能体”，而不是“放弃智能体”。Codex、Copilot、Claude Code 和 OpenCode 仍然居中，但真正有意思的动作已经转移到 shell、bridge、记忆层和特定领域工具包上，它们改变了这些智能体被使用的方式。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| OpenMontage | calesthio | 把编程智能体变成端到端视频制作系统 | 编程智能体可以写代码，但通常会在研究、旁白、剪辑、字幕和渲染之前停下 | Python、FFmpeg、Node/Remotion、多提供商媒体流水线、500+ 个智能体技能 | 已发布 | repo |
| My Brain Is Full — Crew | gnekt | 用一组智能体管理 Obsidian vault、邮件分流和个人知识工作流 | 第二大脑式搭建如果没有智能体化组织和回忆能力，就会变成另一种维护负担 | 基于 shell 的安装器、Obsidian 工作流、支持 Claude Code、Gemini CLI、OpenCode 和 Codex CLI 的多平台能力 | 已发布 | repo |
| Cockpit | Ieuan Walker | 在 GitHub Copilot CLI 之上增加桌面 GUI | Copilot CLI 用户希望能看见会话历史、diff、终端输出，并控制多个会话 | C#、集成终端、diff 查看器、活动日志、附件支持 | Alpha | site |
| Windows Copilot API | sums001 | 把已登录的 Microsoft Copilot 会话暴露成本地 OpenAI 兼容 API | 开发者想要 API 风格访问，但不想承担官方 API 计费或切换到新的客户端界面 | Python、Playwright/浏览器会话自动化、本地 OpenAI 兼容 server | Beta | repo |
OpenMontage 是当天构建者模式里最清晰的例子。@TheWhizzAI 强调（6 点赞、6 回复、326 浏览、2 收藏），它能让 Claude Code、Copilot、Cursor 或 Codex 处理研究、脚本撰写、媒体生成、旁白和最终合成；而其公开仓库则用 12 条 pipeline、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 收藏）一个非官方 bridge，则是因为人们依然想要不换客户端、却获得 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 的 session URL 默认会被写进 git 历史，而随附截图展示了阻止这一行为所需的设置修改。这一点重要，是因为它不是理论上的供应链或隐私担忧，而是主流编程智能体工作流里一个具体、可复现的来源泄露问题。
7. 机会在哪里¶
[+++] 具备成本感知和模型可选性的智能体界面 —— 多个部分都指向同一个缺口：Copilot 低档位用户失去了模型选择，OpenCode 用户撞上月度上限，Copilot app 用户仍在抱怨限流。像 Windows Copilot API 这样的非官方桥接方案之所以会受到关注，正是因为官方访问模式仍然太僵硬。最强的机会，是在保持工作流界面稳定的同时，把模型选择、用量消耗和故障切换变得显式可控。 [++] 具备更强可见性和来源追踪的工作流外壳 —— Cockpit、Agent Finder、Copilot app，以及 Claude Code 会话泄露提醒，都指向人们需要更好的智能体监督层。中等但在扩大的机会，存在于那些能在信任破裂前，让会话、权限、扩展和 commit 来源都可检查的产品中。
[+] 面向非代码领域的智能体改装工具包 —— OpenMontage、My Brain Is Full — Crew，以及 OpenAI 员工关于杂货、报税和邮件的帖子，都表明编程智能体正在被改造成媒体、知识工作和个人事务管理的相邻操作系统。这个信号还在成形，但值得注意，因为开发者是在扩展现有智能体客户端，而不是等待新的垂直产品。
8. 要点总结¶
- 今天最强的信号是“可测量”，而不是“会营销”。 关于 Codex 的公开证据已经从轶事升级为图表和论文级采用数据，包括活跃用户增长 5 倍，以及长周期任务占比的陡峭上升。(source)
- GitHub 的竞争动作在于工作流深度。 Agent Finder、app 原生自动化，以及由 LSP 支撑的代码智能，都在把 Copilot 推向一个可扩展运行时；但回复也说明，扩展信任、Windows 粗糙体验和计费仍然决定人们会不会留下。(source)
- 只要官方访问方式太僵硬，用户就会容忍非官方 bridge。 Windows Copilot API、OpenCode 的回退行为，以及对强制自动选择的抱怨，都指向同一种需求：在不改变顶层工作流的前提下，获得更便宜、可控性更高的后端访问。(source)
- 最有意思的构建者活动，发生在智能体周围，而不是它们底下。 OpenMontage、My Brain Is Full — Crew 和 Cockpit 都是在熟悉的编程智能体外面包上新的记忆、UI 或领域控制层，而不是试图把底层模型整个替换掉。(source)