我一直在使用在 Reddit 上找到的这个提示来编辑我的博文。过去，我曾尝试编辑工作流程，将我的 Twitter 想法转化为博客文章，但大多数模型只会重写整个帖子。我的写作方式听起来不像我，人们很容易看出它是由人工智能编写的，尽管大多数想法都是我自己的想法。但这个提示有点不同。它只会修复拼写错误和语法，添加过渡词，如果有多余的单词，它会删除它们。 有时它会犯错误。例如，当我写一篇关于印度人工智能资助的文章时，有一行关于唐纳德·特朗普的内容，它重写了该行以表明唐纳德·特朗普不是总统，这非常可疑。第一次有人问我是否使用 ChatGPT 来写作，我没有。我知道一个更简单的方法是最终阅读《Word Power Made Easy》和《Wren and Martin》等书籍，但让我们面对现实吧，我现在太老了。而且我太懒了，不想提高我的写作水平。 好吧，现在回到重点。
我在想，既然我有这个提示并且效果很好，我希望有一种方法可以“收藏”或“固定”这个聊天选项卡。然后，我可以继续将我的 Twitter 帖子和原始想法转储到其中，而不是在 Apple Notes 中保留提示并每次将内容复制并粘贴到新的聊天中。过去，我给模型提供了更多后续指令，以获得我想要的确切结果。一次尝试并不能成功。我必须不断尝试和改进它，多次执行相同的过程。这意味着每次我使用编辑流程时，我都必须再次给出指示。我会重复自己。 我想，如果我可以“收藏”它，比如“固定”它，那么访问左侧边栏上的这个编辑器就会容易得多。但这就是事情，这就是我想做的。 在设计某些东西时，你必须同时考虑用户（我）和 ChatGPT (OpenAI)。因此，我想收藏我的聊天，因为这样我可以更轻松地固定这些工作流程并继续对话。但我们从 ChatGPT 的角度来思考一下。为什么他们还没有添加“固定聊天”按钮？第一个问题是：ChatGPT 如何看到我们的聊天记录？ 它们是否像 WhatsApp 上的独立消息（一条消息带有一些回复）。 – Slack 上的消息线程（可以在一个主题上进行多个相邻讨论的线程）。 – 一对一的聊天窗口，就像 WhatsApp 上的联系人一样，该联系人拥有您所有对话的永久历史记录。 作为一家公司，他们关心用户想要什么，但他们也希望引导用户按照他们想要的方式行事。
现在，让我们假设我与任何聊天产品交互的框架是 – 一次性聊天（大部分）。
- 在工作流程中，我使用模型充当特定的人，我的编辑，我的营养师，我的顾问，我的陪练伙伴。我是否将我的聊天命名为这些人？去找他们来完成我的工作。 还有频率是怎样的？用户最终是否创建他们的工作流程，与他们进行专门的聊天，或者他们是否将每次聊天视为独立聊天。
人们说，未来将由代理来完成这项工作，并且会有单独的代理工作流程。但目前智能体与大脑的模型相同，具有功能调用的能力，并且具有更长的记忆力。
我们假设大多数用户不会很快转向代理平台，而是依赖普通的聊天应用程序。
OpenAI 是否打算让聊天持续很长时间，让用户返回同一个聊天？这就是固定/喜欢聊天的时候。这种方法的问题是，随着聊天时间的延长，基础模型的性能会变差。上下文窗口增加。模型忘记了。正常人可能不会责怪上下文大小的增加，而是可能会责怪聊天 GPT 本身并说它不够好。
甚至服务用户的成本，即推理成本，也会随着输入代币数量的增加而变得更高。每个额外的令牌都需要更多的计算。 WhatsApp 聊天、Slack 频道被固定，因为用户希望以更简单的方式访问它们并继续聊天。 在这里您可能不想继续聊天。
你会如何解决这个问题？很长一段时间以来，我一直想知道当您在 Claude 上进行编码项目时，让用户转移到新聊天的最佳用户体验是什么。
通过 Claude 项目，您可以共享更多上下文，可以上传文件，并且当您提供额外的上下文时，模型会表现得更好。
然而，挑战在于，过了一会儿，克劳德反复提示你开始新的聊天。
目前，人们已经找到了解决方案，例如要求模型本身解释并给出当前聊天窗口的摘要，然后复制粘贴摘要作为他们必须开始的新聊天的上下文。 但这很耗时。而且不够直观。 人们可能不会写出正确的提示来总结聊天，而且我们知道该模型可能无法准确总结之前的讨论。因此，问题是，在哪里构建摘要器？您如何改进这个工作流程？
理想情况下，在良好的工作流程中，随着聊天窗口的增长而修复模型性能下降的解决方案应该需要用户的输入。 如果我正在从事编码项目，我可能希望聊天窗口继续下去。翻阅过去的聊天记录并不容易。中途离开并开始新的聊天并不有趣。同一项目有多个聊天窗口。 是的，你可以分解你的工作。创建较小的任务。为每项任务打开聊天室。转到新聊天以进行下一个聊天。但它又不是最优的。 我不希望克劳德反复提示我开始新的聊天。 我们怎样才能有单一的观点呢？ 每个聊天都有一个唯一的标识符（聊天 ID），当您开始新的聊天时，它将被视为一个全新的会话，上下文仅限于该特定对话，而不是该项目的整个聊天历史记录。但如果有一个中间层来更无缝地管理这种转变呢？
它将是一个自动摘要层。
想象一个系统，用户可以在单个长格式聊天中继续工作，但在幕后，对话会定期总结和存储。当 Claude 建议重新开始时，系统可以生成摘要，使用新的聊天 ID 在后台启动新的聊天，附加摘要，然后向前传递压缩的上下文，而不是打开新的聊天。这样，模型可以保留相关信息，而不会淹没其上下文窗口，并且用户不必担心管理多个聊天会话。
这种方法可以显着改善用户体验——保持对话流畅，同时确保模型性能保持稳定。
虽然这是一个高层次的想法，但看看 Claude 和 OpenAI 如何考虑解决这个问题将会很有趣。