夜雨聆风学习资料网

ARTICLE · 1104649

别抄工具组合:换个对话以后,AI 还能准确接着干吗?

别抄工具组合:换个对话以后,AI 还能准确接着干吗?

01|长对话卡顿,我只是换了一个对话

前段时间我在做一个复杂的产品原型。同一个 Notion 对话里已经堆了十几个阶段的讨论:业务模型改了好几版,验收标准反复调整,测试结果和修复记录也都留在里面。
页面越来越卡,每次打字都要等一下。于是我做了一个很自然的决定:新开一个对话继续。
当时我以为这只是换个窗口,顶多写一份“本次做了什么”的摘要,把进度交代一下就行。

02|新对话为什么还是接不上

结果新的对话像只接到了一张残缺的交接便签。它知道最近做过什么,却不知道完整承诺是什么、哪些方案已经作废、哪些事情还没完成。
具体出了三种问题。
第一,摘要只保存了最近一个阶段。早期答应要覆盖的范围、还没兑现的部分,以及讨论过程中已经被否决的方案,全都没有写进去。新对话于是把一些旧思路当成可选项重新提了出来。
第二,交接混淆了不同 AI 的能力边界。我让一个只能讨论的对话去寻找本地代码仓库,还让它去读两个当时根本还没创建的文件。它先尝试查找,然后才暴露出它其实访问不到那些东西。
第三,新旧标准同时留在上下文里。旧标准写着“创建项目后自动注入演示数据”,新标准已经改成“先创建空白项目,再由我主动加载演示数据”。两条都在,新对话无法只凭摘要判断哪一条才是当前决定。

03|丢掉的不是聊天记录,而是完整的工作状态

我后来才意识到:问题不在于换了哪个模型,而在于工作的真实状态仍然锁在上一段对话里。
这类交接问题发生得比想象中频繁:在同一个产品里新开对话、切换模型、长对话超出上下文被截断、从讨论型 AI 切换到能直接改文件的执行型 AI,或者换一个 AI 产品。
在这篇文章里,我把它们视为同一类问题:执行者变了,但工作不能因此失忆。我的判断标准只有一条——新的对话、模型或执行端能不能准确继承原来的状态。

04|上下文是我的资产,Agent 只是客户端

我的核心判断是:上下文是用户拥有的长期资产,Agent 只是读取和使用这些资产的可替换客户端。
这不是一个技术判断,而是一个归属判断。如果偏好、决定和工作进度都只留在某个产品的对话历史里,用得越久越难离开它;而一旦离开,新的 AI 既不认识我,也不知道事情做到哪了。
我的做法是让不同的地方各自承担一部分事实:Notion 保存跨会话的决定、背景和项目状态;代码仓库或项目文件夹保存真实产物和版本;运行环境里的配置、日志和端口,以它当时的实际情况为准。对话只承担讨论和临时执行,不负责长期保存。
这里没有工具推荐的意思。重要的不是用哪个产品,而是每类信息发生冲突时,我清楚最终以哪里为准。

05|让 AI 记得我是谁,和让 AI 知道事情做到哪了

需要保存的信息其实分两类。
一类关于“人”:身份、长期偏好、习惯、稳定的现实限制。它的作用是让 AI 不必每次都从头认识我。这类信息变化很慢,写入要克制,一次性的情绪和随口选择不该变成长期结论。
另一类关于“事”:目标、范围、进度、已经做出的决定、阻塞点和下一步。它的作用是让一件事不会因为换了窗口就重新开始。这类信息变化很快,必须及时更新,否则很容易同时存在几个互相冲突的“当前状态”。
在我的系统里,它们被整理成四类:
  • 用户画像:变化较慢的身份、能力、偏好和沟通方式。
  • 行为反馈:我对 AI 的纠正、被验证有效的做法,以及反复出现的问题。
  • 项目动态:正在推进的事项、当前阶段、阻塞点和下一步。
  • 外部引用:链接、端口、版本、配置等需要精确查找、使用前还要核对的信息。
这四类不是为了把所有对话永久留下来,而是只保留下一次协作真正用得上的内容。
信息保存下来,还要规定什么时候去查。因此,我把“之前”“继续”“还是按上次”,以及涉及项目状态、配置和版本的场景,设成回答前的检查项。这套规则能否长期减少复发仍在验证,但至少不再完全依赖我临时提醒。

06|一份真正能让新对话接手的交接单

后来我不再追求保存每一步思考,只保留一份能让新对话恢复现场的清单。它不是会议纪要,也不是“本次完成了什么”的总结,而是对当前工作状态的一次完整交接。

【新对话交接单】

任务目标:

完整范围:

当前状态:

已完成事项及证据:

未兑现事项:

已否决方案及原因:

最后可信的文件或版本:

必须由我确认的事项:

未经确认不得执行的动作:

下一步:

新对话启动语:

其中最容易被漏掉的是“已否决方案及原因”和“禁止动作”。少了前者,新对话会把旧思路重新端上来;少了后者,它可能直接去做本该我先确认的事。
还有一条补充规则:新对话不能只相信这份交接单。它还要回头核对原始规格、最终检查清单和项目进度记录。交接单是入口,不是唯一事实源。

07|这套做法的边界和成本

它解决不了所有问题。密码、Token 这类敏感凭证不应该直接写进普通知识库,最多记录它归谁管、从哪里取。价格、版本、运行状态这些会变的信息,即使保存过,使用前仍然要重新核对。信息放在外部,也不意味着每个模型都能自动读到它——还要看权限、连接方式,以及它是否真的会去查。
维护成本也是真实存在的。分类越多、规则越细,维护负担越重。我没有统计过每周花在这上面的时间,所以不想编一个数字;但可以确定的是,成本主要不在写入,而在清理过期状态、合并重复规则,以及忍住不让结构继续膨胀。
所以我的建议是从最小结构开始:一页长期信息,一页当前项目,一份交接单。先让一个真实任务跑通,再根据实际踩到的问题增加分类,而不是一上来就建十几个数据库。

08|现在就做一次换对话测试

对话可以丢,事实、证据和恢复入口不能丢。
如果你现在正在和 AI 推进一件事,可以立刻测一次:假设必须关掉这段对话,重新开一个窗口,只把你在外部保存过的内容交给新的 AI。
它能不能准确回答——我们到底要完成什么,哪些范围已经承诺,哪些工作已经完成并且有证据,哪些方案已经作废,哪些动作不能直接执行,下一步从哪里开始?
如果有一项答不上来,就先去补那一项:是根本没保存,还是放错了地方,或者旧状态没有更新。别等到对话卡顿的那一天才发现。

相关学习资料