本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

- 我的帖子已经打上 开源推广 标签： 是

- 我的开源项目完整开源，无未开源部分： 是

- 我的开源项目已链接认可 LINUX DO 社区： 是

- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是

- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

github.com

GitHub - WILLOSCAR/codex-pro-bridge

Contribute to WILLOSCAR/codex-pro-bridge development by creating an account on GitHub.

Introduction

前一版本的初版主要解决的是一件事：让 Codex 和 Web 端的 GPT Pro 围绕同一个任务进行多轮接力，避免每一轮都要重新解释代码背景和前面已做出的决策。对于单向的算法 review、代码重构，或者单个双向通信的小项目，这套方法已经够用了。当时的设计是：一个 bridge thread 对应一项任务，再绑定单独的一个 Codex session 和一个 GPT conversation，从而沿着同一条主线进行时间积累。

在使用过程中发现，同时又听取了各位佬友的建议，真实的科研项目通常是多个会话对应同一个 project。在一个本地的 codebase 里面，可能同时在写论文、跑实验、review 代码、设计架构、看论文设计 idea，其间还掺杂着一些随手提的临时问题。在这种情况下，Web 端往往是通过 ChatGPT Project 的形式存在，下面会放着不同用户的对话和一些长期的资料。原来的 bridge thread 只能保证单个任务不串线，但无法感知这些任务属于同一个更大的项目，也无法让多个对话稳定地共享项目背景，最后还是需要人脑去记住这种一对一或一对多的联系。

所以，这次新增了 project 模式：

- 小项目仍然可以使用原来的 standalone 形式

- 真实且复杂的科研项目，则可以用现在这种 project 模式

Motivation

从科研项目的角度出发，或者说从一个比较需要多个文件支撑的大项目出发，真正需要的共享内容，通常不是某一轮临时上传的代码，而是一些项目本身需要遵从的 Brief、术语表、PRD、研究边界、架构决策，以及一些算法设计等长期不会频繁变化的上下文（这些上下文是相对固定的，并按照 V0.1 开始逐步演变迭代）。

如果这些内容在每个对话中都重新上传，不仅重复，而且非常不优雅，不同的对话也很容易拿到不同的版本。但如果把所有任务都塞进同一个对话，上下文又会被撑爆，不同功能之间也会产生 overlap。

平时我自己更倾向于让每一个 session 都有一个独立的用途。因此，这一版 project 的核心目标，其实就是把“共享的项目上下文”和“独立的任务时间线”分开：

- 本地一个仓库最多绑定一个 bridge project（这是一个逻辑项目）。

- 一个 bridge project 最多又绑定一个 ChatGPT project。

- 同一个 project 下面可以有多条 task thread。

- 每个 thread 继续负责一个明确的任务和自己的 GPT conversation。

这样既不会把不同的任务揉成一团，也不需要每条对话都从零开始。

在具体实现上，我还是希望大部分时候只要告诉 Codex 现在想做什么，而不是手动去选择一套工作流。意图识别这一块，我觉得直接让 Codex 本身来做就 OK 了。这样既保留了原有的使用方式，让 Codex 自己去判断，同时用户也可以显式地使用 prompt 跟它说明。

Method

这次新增的 Project 模式并没有改变原来任务时间线的交互逻辑，因此小项目、临时 Review，或者只需要聊一轮的问题，依然可以使用原来的模式。

如果一个 Codebase 下面已经有了论文、实验、代码 Review、架构设计等多条长期任务，就可以把本地仓库绑定到一个已有的 ChatGPT Project。绑定之后，一些长期的共享内容就可以作为 Project 的 Source 放进那个 Project 里。

不同任务之间依然各自使用不同的 Task Thread：写论文是一条 Thread，Review 代码是一条 Thread，讨论架构也可以是另外一条 Thread。同一项工作的后续迭代，就有点类似于一个树形结构：你把 Project 当成一个根节点，每个根节点下面都有不同的任务路线，不同任务路线之间可以随意切换

Discussion

- 本来还想做一些跟 memory 相关的事情，但是感觉 Codex 本身的一些 memory 以及 ChatGPT Project 里面的这种跨 session memory 已经很好。我觉得可以适当利用它本身提供的能力，这样它在回复中就自然而然带了 memory。至于我们自己的 memory，我觉得更倾向于在本地去做一些设计。

- 题外话：Codex App 本身的一些功能好像更新得太勤了，原来左侧好像有 Chat 的UI功能，现在好像又没有了。现在触发模式好像变成在对话框里 @，然后指定 Conversation。

Ref

- [v0.1] codex-pro-bridge 让 Codex 和 GPT Pro 围绕同一个任务多轮接力，不再丢失上下文