为什么项目上下文可能变得和源代码同样重要
Why Project Context May Become as Important as Source Code
从 ChatGPT 发布以来，我一直把它作为日常工作和思考的辅助工具。从最初的网页版本，到后来熟悉的传统聊天界面，再到 iPhone、Mac，以及进入 VS Code 的 Codex， ChatGPT 在不同工作环境中的角色正在发生分化。
很多人仍然把 ChatGPT 理解成一个 App。打开它，提出问题，得到回答，然后关闭。其实ChatGPT 正在从一个独立应用，逐渐变成一种分布在不同工作环境中的能力。网页、手机、桌面应用和 IDE 并不是同一个工具的简单复制，它们开始承担不同的工作。
以前我们打开浏览器使用 ChatGPT，后来它进入手机和电脑桌面，现在又进入代码编辑器。以后它还会更深入地进入办公软件、设计工具和操作系统。到那时，“ChatGPT 有几个版本”可能已经不是一个很重要的问题。更准确的问题应该是，AI 在哪些工作环境中出现，它在那里能够接触什么信息，又能够完成什么工作。
不同工作环境承担不同任务
我长期使用这些环境以后，越来越不愿意用“哪个更好”来比较它们。真正有意义的比较，是它们分别适合承担什么任务。
| 工作环境 | 更适合的工作 | 主要优势 |
|---|---|---|
| ChatGPT Web | 通用问答、资料查询、写作和跨设备使用 | 进入方便，适合处理范围较广的任务 |
| ChatGPT Classic | 长时间连续讨论、概念推敲和保持熟悉的聊天方式 | 简单稳定，注意力集中在对话本身 |
| ChatGPT iPhone | 随时记录灵感、语音交流、拍照和现场信息输入 | 随身可用，最接近日常生活发生的现场 |
| ChatGPT Mac | 长时间讨论、架构设计、文档整理和桌面工作 | 适合较完整的思考过程，也便于和本地材料配合 |
| VS Code 中的 Codex | 阅读项目、修改代码、调试、测试和重构 | 能进入代码库内部，直接面对工程的真实结构 |
这里所说的 ChatGPT Classic，是指以连续聊天为中心的传统使用方式，而不是强调某个固定的官方产品名称。产品界面会继续变化，但这种聊天型工作环境仍然有独立价值。
这些环境并不是竞争关系。iPhone 不适合承担大规模代码重构，但它很适合在散步或临时想到问题时记录一个产品设想。Mac 上的 ChatGPT 不一定能够像 IDE 中的 Codex 那样直接理解整个代码库，但它更适合暂时离开实现细节，讨论产品边界、系统架构和设计原则。VS Code 中的 Codex 可以检查调用关系、修改多个文件并运行测试，但当讨论进入较长的概念分析时，聊天环境往往更自然。
这不是模型能力的简单高低，而是模型所处位置的不同。一个 AI 能做什么，不只取决于它本身有多聪明，也取决于它能够看到什么、能够调用什么，以及它是否处在最适合当前任务的工作现场。
同一个项目会在多个环境之间流动
软件项目并不会始终停留在 VS Code 里面。一个想法可能最初出现在 iPhone 的语音对话中，随后在 Mac 上被整理成产品定义和架构草案，再回到传统聊天中反复推敲某个概念，最后进入 VS Code，由 Codex 对照真实工程完成实现。代码完成以后，设计结果又可能回到 Mac 上，被整理成说明文档、开发记录或文章。
因此，一个项目的实际路径可能是：
iPhone → Mac → ChatGPT Classic → VS Code → Mac
这个顺序并不固定，也不是单向的。项目会在这些环境之间反复往返。问题在于，每一次转换都可能损失信息。
在手机上形成的原始想法，到了桌面端可能只剩下一段简短摘要。Mac 上讨论出来的架构原则，进入 VS Code 以后可能没有被带进代码会话。Codex 在实现过程中发现的限制，也未必会自动回到后面的产品讨论中。每一个环境都完成了自己的工作，但如果中间结果不能有机流动，项目仍然会被切成一段一段互不完整的过程。
因此，真正需要解决的不是如何让几个 ChatGPT 界面看起来完全一样，也不是强求所有聊天记录自动合并成一个无限会话。真正需要的是问题的连续性——无论工作转移到哪个环境，项目的重要事实、决策和未完成问题都能继续存在。
Project Context 不是聊天记录的堆积
这就引出了 Project Context，也就是项目上下文。
项目上下文不是把所有历史对话原封不动地保存下来。聊天记录包含大量试探、重复、误解、临时假设和已经被放弃的方案。如果把这些内容全部带到下一个环境，信息虽然没有丢失，判断反而可能更加困难。
真正有效的项目上下文，应该保存已经稳定下来的结构，例如：
- 项目的目标、范围和非目标
- 关键术语及其稳定定义
- 已确认的架构原则和技术约束
- 重要决策，以及作出这些决策的理由
- 已经否定的方案和否定原因
- 当前实现状态、已知问题和风险
- 尚未解决的问题及下一步工作
- 重要的中间成果、测试结果和参考资料
这些内容和源代码有关，却不能被源代码完全表达。源代码告诉我们系统现在是什么样，项目上下文则告诉我们为什么把它做成这样，还准备往哪里走。
传统软件开发已经有需求文档、架构说明、设计决策记录、问题跟踪和版本控制。Project Context 并不是要取代这些东西，而是要把其中真正影响 AI 判断的部分组织成一种能够被持续读取、更新和传递的结构。它既面向人，也面向进入项目的 AI。
在代码环境中，AGENTS.md、项目 README、架构文档、开发规范和任务状态都可以承担一部分这种作用。ChatGPT 项目中的文件、说明和经过整理的结论也可以成为上下文的一部分。但 Project Context 不应被理解成某一个文件或某一个产品功能。它更像一个项目层的信息系统，文件只是它的载体。
源代码加项目上下文
过去的软件开发主要围绕源代码建立连续性。开发者更换电脑、编辑器或团队，只要代码库和版本历史仍然存在，工程就可以继续推进。
AI 加入以后，这还不够。AI 不只需要看到代码，还需要理解需求的来源、设计取舍、命名含义、哪些限制不能突破，以及当前任务在整个项目中的位置。如果这些信息只存在于某一次聊天里，一旦换了设备、界面或会话，AI 就可能重新推理一遍，甚至得出与此前相反的结论。
所以，AI 时代的软件开发逐渐变成了两条并行的连续线：
Source Code + Project Context
源代码保存可执行结构，项目上下文保存决策结构。前者使系统能够运行，后者使人和 AI 知道为什么这样运行，以及下一步应该怎样改变。
项目上下文也需要像代码一样被维护。旧决定被推翻以后，不能只增加一段新对话，还要更新当前有效结论。临时设想不能和正式决定处在同一层级。架构改变以后，相关说明和约束也要同步改变。否则，项目上下文会像长期没有整理的代码一样，逐渐产生自己的技术债务。
这也意味着，中间结果不再只是聊天过程中的副产品。一段经过确认的需求分析、一项架构决定、一次失败实验的结论，都可能成为后续工作的正式输入。它们需要有明确的落点、状态和版本，才能从 iPhone 流向 Mac，从 Mac 流向 VS Code，再从工程实现回到产品思考。
从使用工具转向组织工作
ChatGPT 进入越来越多的工作环境以后，我们面对的已经不只是一个工具选择问题。真正的变化，是人开始需要组织多个 AI 工作现场之间的关系。
有些环境负责捕捉灵感，有些负责展开讨论，有些负责形成决策，有些负责进入真实项目执行。任何一个环境都不能完整替代其他环境。它们的价值来自分工，也因此产生了协调的需要。
从这个角度看，未来的软件开发工作流不应该追求把所有事情都塞进一个聊天窗口，而应该建立一种稳定的结构，让不同环境在合适的位置接手同一个项目。切换界面没有关系，切换设备也没有关系，甚至更换模型也没有关系。真正不能不断丢失的，是项目已经形成的认识和决定。
因此，当 ChatGPT 进入不同工作环境之后，最值得管理的可能不再只是一次次对话，而是对话留下来的有效结构。源代码仍然是软件工程的核心，但在 AI 深度参与开发以后，Project Context 很可能会成为源代码之外的第二条主干。
它保存的不是程序本身，而是程序得以持续形成的过程。
参考资料
When ChatGPT Enters Different Workspaces
Why Project Context May Become as Important as Source Code
I have used ChatGPT as part of my everyday work and thinking almost continuously since it was released. My use has moved from the original web experience to the familiar chat-centred interface, then to the iPhone and Mac, and more recently into VS Code through Codex. Over time, one change has become increasingly clear. The important question is no longer simply which model is more intelligent. It is how ChatGPT takes on different roles in different working environments.
Many people still think of ChatGPT as an app. You open it, ask a question, receive an answer, and close it. That description is not wrong, but it is becoming incomplete. ChatGPT is gradually changing from a standalone application into a capability distributed across different workspaces. The web, the phone, the desktop app and the IDE are not merely copies of the same tool. They are beginning to carry different parts of the work.
We first used ChatGPT in a browser. It then moved into phones and desktop applications, and now it has entered the code editor. In time, AI will become more deeply embedded in office software, design tools and operating systems. At that point, asking how many versions of ChatGPT exist may no longer be especially useful. The better question will be where AI appears, what information it can reach there, and what kind of work it can perform.
Different workspaces, different responsibilities
After using these environments for a long time, I no longer find “which one is better?” a very useful comparison. The meaningful question is what each environment is best placed to do.
| Workspace | Best suited to | Main advantage |
|---|---|---|
| ChatGPT Web | General questions, research, writing and access across devices | Easy to enter and suitable for a broad range of work |
| ChatGPT Classic | Extended conversations, conceptual development and a familiar chat experience | Simple, stable and focused on the conversation itself |
| ChatGPT iPhone | Capturing ideas, voice conversations, photographs and information from the immediate situation | Always available and closest to where everyday experience occurs |
| ChatGPT Mac | Extended discussion, architecture design, document development and desktop work | Supports a more complete thinking process and works naturally with desktop materials |
| Codex in VS Code | Reading a project, changing code, debugging, testing and refactoring | Works inside the repository and encounters the actual engineering structure |
In this essay, “ChatGPT Classic” refers to the conventional chat-centred way of using ChatGPT. It is not intended as a claim about a permanent official product name. Interfaces will continue to change, but the conversational workspace retains a distinct value.
These environments are not competitors. An iPhone is not the right place for a large code refactor, but it may be the best place to capture a product idea while walking. ChatGPT on the Mac may not inspect a repository as directly as Codex inside an IDE, but it is often a better place to step back from implementation and discuss product boundaries, architecture and design principles. Codex in VS Code can trace calls, edit several files and run tests, while a chat-centred environment often feels more natural when the work becomes an extended conceptual discussion.
This is not simply a hierarchy of model capability. What an AI can do depends not only on how capable the model is, but also on where it is situated, what it can see, what tools it can use, and whether it is present at the right site of work.
One project moves through several environments
A software project does not remain inside VS Code. An idea may first appear during a voice conversation on an iPhone. It may then become a product definition and an architectural sketch on the Mac, return to a conventional chat for closer conceptual examination, and eventually enter VS Code, where Codex works against the real repository. Once implementation is complete, the result may return to the Mac to become documentation, a development record or an essay.
The practical path of a project may therefore look like this:
iPhone → Mac → ChatGPT Classic → VS Code → Mac
The sequence is neither fixed nor one-way. A project travels back and forth between these environments. Every transition, however, creates the possibility of information loss.
An idea formed on the phone may reach the desktop only as a short summary. An architectural principle established on the Mac may not enter the coding session in VS Code. A constraint discovered by Codex during implementation may never return to the later product discussion. Each environment may complete its own task, yet the project as a whole can still break into disconnected segments when intermediate results do not flow between them.
The real problem is therefore not how to make every ChatGPT interface look identical. Nor do we need to force all conversation history into one unlimited session. What matters is continuity of the problem. Wherever the work moves, the important facts, decisions and unresolved questions of the project must be able to move with it.
Project Context is not accumulated chat history
This is where Project Context becomes necessary.
Project Context does not mean preserving every past conversation unchanged. Conversations contain exploration, repetition, misunderstanding, provisional assumptions and discarded options. Carrying all of that into the next environment may preserve information while making judgement more difficult.
Useful Project Context should preserve the structure that has become stable:
- the goal, scope and explicit non-goals of the project
- key terms and their settled meanings
- accepted architectural principles and technical constraints
- important decisions and the reasons behind them
- rejected options and why they were rejected
- current implementation status, known problems and risks
- unresolved questions and the next work to be done
- significant intermediate outputs, test results and reference materials
These things are related to source code, but source code cannot express all of them. Source code tells us what the system currently is. Project Context tells us why it became that way and where it is meant to go next.
Software development already has requirements, architecture documents, decision records, issue tracking and version control. Project Context should not replace them. Its role is to organise the parts that materially shape AI judgement into a structure that can be read, updated and transferred continuously. It is written for both the people developing the system and the AI entering the project.
Within a coding environment, AGENTS.md, the project README, architecture documents, engineering rules and task status can each carry part of this context. Files and settled conclusions inside a ChatGPT project can also contribute. But Project Context should not be reduced to one file or one product feature. It is better understood as an information system at the project level, with files acting as its carriers.
Source Code plus Project Context
Software development has traditionally built continuity around source code. Developers may change computers, editors or teams, but the work can continue as long as the repository and its version history remain available.
Once AI becomes an active participant, that is no longer sufficient. AI needs more than code. It needs to understand where requirements came from, which trade-offs were accepted, what names mean, which constraints must not be crossed, and where the current task sits within the larger project. If this information exists only inside one conversation, moving to another device, interface or session may force the AI to reconstruct the reasoning and possibly reach a conclusion that contradicts an earlier decision.
AI-assisted software development is therefore beginning to depend on two parallel forms of continuity:
Source Code + Project Context
Source code preserves executable structure. Project Context preserves decision structure. One allows the system to run. The other allows people and AI to understand why it runs that way and how it should change next.
Project Context also needs maintenance. When an old decision is overturned, adding another conversation is not enough. The currently valid conclusion must be updated. A provisional idea should not sit at the same level as an approved decision. When architecture changes, the related explanations and constraints must change with it. Otherwise, Project Context will accumulate its own form of technical debt.
Intermediate results also become more than by-products of conversation. A confirmed requirements analysis, an architectural decision or the conclusion from a failed experiment may become formal input to later work. Each needs a clear location, status and version if it is to move reliably from iPhone to Mac, from Mac to VS Code, and from implementation back into product thinking.
From using a tool to organising the work
As ChatGPT enters more working environments, this becomes more than a choice between tools. The deeper change is that people must learn to organise the relationship between several AI-enabled sites of work.
One environment captures an idea. Another develops the discussion. Another stabilises a decision. Another enters the real project and executes it. No single environment fully replaces the others. Their value comes from specialisation, and specialisation creates the need for coordination.
The future software workflow should therefore not try to force every activity into one chat window. It should establish a stable structure through which different environments can take over the same project at the right moment. Changing interfaces should not matter. Changing devices should not matter. Even changing models should not matter. What must not be repeatedly lost is the understanding and the decisions that the project has already produced.
Once ChatGPT enters different workspaces, the most important thing to manage may no longer be each individual conversation, but the durable structure left behind by those conversations. Source code remains central to software engineering, but as AI becomes deeply involved in development, Project Context may become its second main line of continuity.
It does not preserve the program itself. It preserves the process through which the program continues to take form.
References
Discover more from Geoffrey Chen
Subscribe to get the latest posts sent to your email.