在未完成的任务中，答案会突然停止，而目标、已传递的材料以及最后有用的版本，仍保留在当前的工作上下文里。当脑海里冒出“DeepSeek怎么不工作了”的念头时，如果直接重新发送同一个请求，下一次尝试很可能缺少部分原始输入，导致结果更不完整。 这种情况下，第一件要做的事不是诊断服务故障，而是创建一张独立的“继续卡片”。这张卡片的作用是固定任务现状，让你在无法访问原始会话时，也能手动回到工作中继续推进。 这个观点或许有争议，但很实用：当聊天意外中断时，应该先保存工作状态，然后再单独决定要不要重新发送请求。核心选择始终存在：如果重复发送看起来是最快的动作，那么停下来做一份手动计划，到底值不值得？ 一张能跨越会话的卡片，并不需要写得很长。它的目标是让另一位协作者，或者未来的你自己，能够快速明白：已经做了什么，接下来该做什么。 卡片应包含以下关键信息： - 任务与目标：最终需要得到什么结果。 - 材料清单：所有已经提供的输入，缺少这些就无法继续。 - 最后一个有用结果：哪些内容已经可以复用。 - 未解决的开放问题：还有哪些事项悬而未决。 - 负责人：下一步由谁来推动。 - 指定的下一步行动：具体的人工操作步骤。 - 时间状态：现在做/等待/稍后检查——哪些可以立即执行，哪些依赖重新发送，哪些需要另行验证。 为什么要先暂停？因为在固定状态之前重复相同请求，可能显著增加返工量。上述情境中，关键输入只存在于当前上下文里，新的一次尝试可能从更不完整的目标、材料或最终结果开始。 机制其实很简单：重新发送请求，回答的是“下一个消息应该是什么”；而卡片回答的是“工作如何继续”。这是两种不同的决策。如果把它们混在一起，你可能会花时间重复发送，最后仍然需要手动恢复上下文。 实际做法是：先把已知的信息都写进卡片，再做下一步决定。这样无论聊天是否中断，你的工作都不会从零开始。
热门跟贴