DevTrendsDeveloper trends
Accent color

spacecoder-kafka /

codex-co2

重新搬回的“椅子” 过去,两个程序员想一起解决同一个问题,可以把椅子挪到同一块屏幕前。 一个人负责操作键盘,另一个人负责审视思路;遇到分歧,就停下来讨论。屏幕上的代码是两个人共同产出的成果,问题的来龙去脉,也在这一问一答中逐渐对齐。 这种协作的方法,就叫做“结对编程”。 如今,AI 俨然已经成了坐在我们屏幕另一侧的新搭档。 我们向它描述需求,让它阅读代码、分析问题,并尝试修改。在一轮轮对话之后,那条会话里逐渐积累起了整个任务的背景,包括…

LanguageJavaScriptDTData & operationsDTSoftware developmentDTAgent extensionDTAgent observabilityDTmacOSDTWindowsDTCodex

Product images

About

重新搬回的“椅子” 过去,两个程序员想一起解决同一个问题,可以把椅子挪到同一块屏幕前。 一个人负责操作键盘,另一个人负责审视思路;遇到分歧,就停下来讨论。屏幕上的代码是两个人共同产出的成果,问题的来龙去脉,也在这一问一答中逐渐对齐。 这种协作的方法,就叫做“结对编程”。 如今,AI 俨然已经成了坐在我们屏幕另一侧的新搭档。 我们向它描述需求,让它阅读代码、分析问题,并尝试修改。在一轮轮对话之后,那条会话里逐渐积累起了整个任务的背景,包括:为什么要做这个功能,哪些方案已经被否定,还有什么约束必须遵守等等。 可当后续有另外一位同事想参与进来,或接手你的工作时,事情就变得开始低效了。 我们需要把对话截图发过去,把代码复制出来,再把同事的意见转述回给 AI。对方如果想追问一句,又要等我们把问题送进去,再把回答搬回来。 AI 明明已经能够参与越来越多的执行工作了,但人与人之间的协作,仍可能被这些来回的转述给拖住。 个人的生产力被放大了,团队掌握的信息,却未必能同样顺畅地汇集到一起。 是时候,我们该重新搬回那张“椅子”了。 Codex Co² 想解决什么? 基于同一条会话的协作,正是我想用 Codex Co² 来解决的问题。 Codex Co² 的全称是 Codex Conversation Collaboration(Codex 会话协作),名字有点长,但是想做的事情很简单:让多个人参与同一条 Codex 会话,一起推进工作。 分享者可以继续在官方 Codex Desktop 中工作,只需在 Co² 里选中一条已有会话,生成邀请,发给协作者。协作者则通过浏览器打开邀请,申请加入;获准后,就能阅读共享上下文,向同一个 Agent 补充要求,并跟进它的回复。 协作者无需安装 Co²,也无需单独登录 Codex。发出的每一条消息,都会沿用分享者当前会话的工具、权限和额度。 邀请协作者 不妨看一个具体的例子。 假设有用户反馈:“任务已经处理完成,页面上的状态却一直没有变化,刷新之后才恢复。” 运营拿到 FeedbackID 后,可以先在 Codex 中分析相关的用户日志,得到初步结论:操作请求已经成功,问题可能出在页面状态的更新环节。 随后,运营就可以通过 Co² ,将这条会话分享给研发。 研发加入后,可以沿着已有的分析继续追问:服务端有没有发出状态变更通知?客户端是否收到?异常发生前,是否经历过断线和重连? 结合日志与相关代码,问题逐渐收敛:客户端在网络重连后没有恢复实时订阅,后续状态变更因此未能到达页面;而手动刷新会重新拉取数据,所以显示又恢复了正常。 到这里,一条模糊的用户反馈,才有了可以解释、可以验证的技术根因。 邀请另一协作者 但找到根因,并不意味着就走到了解决问题的最后一步。 研发可以继续让 Agent 梳理修复方案:补齐重连后的订阅恢复,并在恢复连接时校准一次状态;同时整理受影响的场景、改动范围、验证成本,以及临时处理方式,再邀请产品加入这条会话。 产品看到的,便包括了用户最初遇到的困难、运营从日志中获得的线索、研发定位根因的过程,以及不同处理方式的成本与风险。 基于这些信息,产品可以决定是否需要立即修复、如何安排版本,以及在修复上线前怎样回应用户。 运营带来现场,研发追到根因,产品决定如何推进。 不同角色的判断,在同一条会话里逐步接续。前一个人留下的分析,成为后一个人继续追问的起点,最终把一条用户反馈推进为一个有依据的处理决定。 收集分散的信息 Co² 带来的这个看起来很小的变化,恰恰对应着软件开发中一个长期存在的事实:理解一个问题所需要的信息,往往分散在不同的人手里。 产品同事知道某条看似奇怪的规则,背后对应着怎样的业务现实;测试同事知道一个偶发问题,究竟要经过哪些步骤才能复现;熟悉系统的工程师则知道,一处看似无害的改动,可能牵动哪些历史约束。 这些判断,很难仅凭一句“帮我把功能做出来”就交代清楚。 AI 能够处理的信息再多,也需要有人把这些最相关的事实带到它面前。因此,当我们讨论如何更好地使用 AI 时,更值得考虑的是:怎样让那些真正了解问题的人,更容易参与当前的工作。 Co² 尝试提供的,就是这样一个入口。 我希望它能够用在结对开发中,让另一位工程师直接参与方案讨论;用在远程排障中,让了解现场的人补充复现条件;也用在需求澄清中,让业务上的判断及时进入实现过程。 还有更多可能性 当然,Co² 目前仍是一个早期的独立实验项目。 项目代码已经在 Github 上开源,提供了 macOS 和 Windows 安装包,可以通过 Homebrew 安装后打开,也可以直接在浏览器上运行。 使用时还需要理解以下几点限制: 共享会话沿用原来的执行环境和额度,协作者的每一条消息,实际都是以分享者的身份在发送的,使用时需要注意权限控制和额度把控。 公网分享经过中继,使用普通 TLS,没有端到端加密,记得只邀请可信任的协作者,或者开启“仅内网可访问”开关; 退出 Co² 时,分享出去的邀请链接会变成不可访问,因为 Co² 设计上就是服务于当下的协作,而不是作为一个长期的入口。 如果你也正在和同事一起使用 Codex,欢迎试用,并把遇到的体验问题通过 Issue 反馈给我,一起参与 Co² 的共创。 那些曾经需要截图、复制粘贴、反复转述的环节,就是 Co² 这个工具能帮你们改进的地方。 结语 希望,我们在用 AI 来提升我们工作效率的同时,也能继续给身边的同事留出位置。 让了解需求的人、熟悉代码的人、发现问题的人,都能把各自掌握的那一部分带进来,完成一个共同的协作,这才是团队存在的意义。 曾经屏幕前的那把椅子,值得再搬近一些。

Discovery history

  1. 阮一峰周刊·用户投稿

    Oct 31, 2026 · 1 observations

Discuss this product