Editing an old message is the closest thing ChatGPT has to /compact, and it keeps your project chat alive
- 发布
- 09/04 08:53
- 首次发现
- 09/04 18:00
- 类型
- 开发者社区 · RSS
在ChatGPT中编辑旧消息可以有效地压缩冗长的项目聊天，防止早期决策超出上下文窗口，并避免模型自相矛盾。这种方法类似于手动压缩，它会分叉对话，将后续消息移至非活动分支。它允许用户保持相同的聊天URL和线程，同时重置模型的上下文，从而在不开始新聊天的情况下保持项目聊天的活跃。如果需要，原始讨论仍然可以访问以供参考。
Long project chats in ChatGPT die twice: first quietly, when early decisions fall out of the context window and the model starts contradicting them, then loudly at the hard cap. Starting a new chat fixes both and loses the one thing you wanted, the thread itself. This keeps the same chat, same URL, and resets the context inside it. Credit to a commenter on my context post who worked it out; I have run it daily since.
The routine:
- Start the project chat with a detailed plan as message one. Goal, architecture, constraints, conventions. This message never changes and everything gets measured against it.
- Work in bounded batches: one feature, one bug, one refactor. When a batch is validated, send this:
Write a consolidated state document for this project containing only what the next step needs: completed work, architectural decisions and why, files changed, tests run and their status, open issues, blockers, and the exact next action. Mark anything you cannot verify from the code or test output as UNVERIFIED. No discussion history, no alternatives we rejected unless they constrain the next step.
- Copy the result. Now edit message two of the chat (your first real message after the plan) and replace its content with the state document, then submit the edit.
- Continue working from there. Repeat after every validated batch.
Why step 3 works: editing a message in ChatGPT forks the conversation at that point. Everything after the edited message leaves the active branch, so the model's context becomes your plan plus the fresh state doc plus whatever you do next. The old discussion is not deleted, it lives in the branch arrows if you ever need the archaeology, but it no longer eats your window. Manual compaction, no new chat.
Rules that keep it honest:
The repo and the tests are the source of truth, never the state doc. Compaction inherits errors from the previous state as efficiently as it inherits progress, which is what the UNVERIFIED marker is for; check those against the actual code before the next batch.
Keep message one detailed. The state doc says what changed, the plan says what it should have changed toward, and the model needs both to notice drift.
Do the review cold. Before writing the state doc, paste the batch's diff into a separate chat with zero history and ask it to find the bug. The project chat has co-authored the code and will defend it; a fresh session will not.
Cost: about two minutes per batch. Payoff: a three week project in one chat that never went dumb on me, which I could not say about any long chat before this.
Does anyone have a cleaner way to do the fork? I have wondered whether editing message one itself, plan plus state in one message, holds up better over very long runs, but I have not tested it.