你保存了所有运行记录，为什么项目还是停在昨天？

事情是这样的。

你昨天让 Codex 查了一个登录问题。它读了十几个文件，跑了测试，改了三处代码，最后留下了一大段总结。今天重新打开项目，你能看到完整对话、终端输出、Git diff、测试日志，甚至连每一次失败都还在。

记录很全。

可当你准备继续时，还是会卡在同一个问题上。

现在到底该接着修，换一个假设，还是这件事其实已经完成了？

我有时候觉得，这可能是 AI 编程最容易被忽略的一种浪费。不是 Agent 没有干活，也不是我们什么都没保存。恰恰相反，东西保存得太多了。多到昨天发生的一切都在，唯独今天该做什么不在。

日志能证明过去发生过什么，却不会自动替你生成下一步。

聊天记录、命令输出和文件变化都属于执行历史。它们很重要，因为没有这些东西，我们只能靠印象判断。但历史如果只停在归档层，它就像飞机的黑匣子，出了问题以后可以回看，却不能直接告诉驾驶员下一秒该把机头转向哪里。

项目需要的不是更大的黑匣子，而是一块导航仪表。

同一份历史，只有在被压缩成一个当前决定时，才会开始推动项目。

这个决定通常只有三种，继续、调整、完成。

继续，是目标还成立，路径也大致成立，只是执行在一个清楚的位置中断了。昨天的测试已经排除了数据库连接，问题收敛到登录回调，那么今天就从回调开始，不需要重新调查整个认证系统。

调整，是新证据推翻了原来的判断。你以为按钮失效是前端状态没刷新，真实浏览器却证明请求根本没有发出。那就别让 Agent 沿着旧假设继续加日志。把被否定的假设写清楚，再把下一次动作改成检查点击事件和请求触发链。

完成，是结果已经成立，而且证据足够支撑停止。代码合并了不一定算完成，测试绿了也不一定算完成。可如果用户路径走通、最终产物能用、外部回执也在，继续修改反而可能把已经闭合的结果重新打开。

你想想看，这三种决定看起来很简单，可绝大多数执行历史里偏偏没有它们。

Agent 会告诉你它读了什么、改了什么、测了什么。终端会保留命令。Git 会保留 diff。它们都在忠实记录活动，却没有谁天然负责回答，现在应该继续、调整还是完成。

这个判断仍然属于你。

我非常理解为什么很多人不愿意做这一步。刚结束一轮执行时，人已经有点累了。文件改了，测试跑了，眼前还有下一件事。最自然的动作就是把窗口一关，心里想一句明天再接着看。

可明天真正昂贵的，往往就是这个再看一遍。

你会重新浏览对话，重新读 diff，重新猜测最后一个失败是否重要。有时 Agent 也会重新调查已经排除的路径。十分钟、二十分钟就这么过去了。更麻烦的是，你可能在没有察觉的情况下换掉目标，把昨天接近完成的修复扩成一次新的重构。

所以我更愿意在每轮结束时留下一张很短的行动卡。

不是写一篇复盘，也不是把日志再总结一遍。只写五行。

本轮想得到什么结果。

实际观察到了什么。

目标与结果之间还差什么。

现在的决定是继续、调整还是完成。

下一次打开项目时，第一步做什么。

这五行里，最容易被写成废话的是最后一行。

继续调查不算动作，优化体验也不算动作。一个能接住的下一步，应该小到可以直接开始，又完整到能产生新证据。检查登录回调是否收到 code，可以开始。用真实账号走通登录并保存回执，也可以开始。全面检查认证系统，就又把方向交回了执行过程。

拿前面的登录问题来说，一张真正能接棒的行动卡，大概会是这样。

本轮目标，修复用户完成授权后仍回到登录页的问题。

实际观察，浏览器点击登录后没有发出回调请求，数据库连接和服务端会话检查已经通过。

剩余缺口，尚未确认点击事件为什么没有触发请求。

当前决定，调整。停止沿着会话过期的假设继续排查。

下一步，在真实页面监听点击事件和网络请求，确认断点发生在事件绑定还是请求构造。

你会发现，这几行没有重述整个认证架构，也没有把所有测试名称抄一遍。可它保留了会改变下一次选择的东西。目标没有丢，两个已经排除的方向没有丢，旧假设为什么失效也没有丢。下一次 Agent 一进来，就知道该在哪个位置动手。

这才是压缩，而不是删减。

删减只是把历史变短。压缩要保留判断需要的信息，并丢掉不再影响行动的噪音。

很多总结看起来很短，其实没有被压缩。像是完成相关修改、测试基本通过、后续继续观察。每句话都很顺，放到任何项目里也都成立。问题就在这里，它没有当前位置，也没有下一次动作。换一个 Agent 读到以后，还是得重新打开 diff 和日志，才能猜出相关修改究竟是什么。

一个很好用的检查方法，是想象明天接手的人只能看这张卡，不能先翻完整对话。

他能不能在半分钟内说出这轮要得到什么结果？

能不能区分已验证事实和仍待验证的猜测？

能不能知道哪些路径不要重走？

能不能直接执行第一步？

如果其中一个答案是否，那不是要求你把整段历史贴回来，而是在提醒你补上真正缺失的证据。

说真的，这个区别很重要。我们很容易把信息不足理解成信息太少，于是下意识增加上下文。可影响接力的往往不是材料数量，而是材料之间没有优先级。一个两千行的终端日志，可能不如一句真实浏览器没有发出请求有用。因为后者直接改变了下一次检查的位置。

这块需要注意一下，行动卡不是为了把每次工作都包装成成功。

有时候最有价值的记录恰恰是，原假设被证伪了，当前没有修好。坦率的讲，这比一句已经完成但没有证据的总结可靠得多。失败如果留下了被排除的路径和新的检查动作，它仍然在减少未知。相反，成功如果没有留下最终证据，下一次就还得重做验收。

执行历史真正有价值的地方，不是证明我们很忙，而是减少下一次判断需要重新支付的成本。

说到这里，很容易想到航海日志。船长记录天气、位置、航向和异常，不是为了把每一朵浪花都保存下来。日志最重要的作用，是让下一班值守的人知道船在哪里，航向有没有改变，什么风险刚刚出现。

软件项目也一样。

每一条终端输出都是浪花。每一个 diff 都是船身发生的变化。真正决定能不能接班的，是当前位置、已确认事实、未闭合风险和下一次动作。

这也解释了为什么保存所有聊天，并不等于保存项目进展。聊天能还原讨论，运行记录能还原过程，项目记忆能保留稳定事实。但要让项目继续移动，还差最后一次压缩，把过去压缩成今天可以执行的决定。

这三类东西其实可以各自待在合适的位置。

原始聊天和终端输出留作可查证的执行历史，需要定位细节时再回看。

五行行动卡放在当前环节旁，负责把下一次工作直接接起来。

那些跨越很多任务仍然成立的事实、已经确认的决定和反复出现的模式，才值得进入长期项目记忆。

不是每一条日志都要升格成经验，也不是每一次失败都要写进长期规则。保存越多，下一次检索的噪音就越大。真正会被复用、而且已经有当前证据支持的内容，才值得长期留下。

怎么说呢，这有点像整理旅行行李。原始历史是家里的储物间，什么都可以保留。行动卡是今天背在身上的小包，只放这一段路会用到的东西。长期记忆则像证件和常用药，换一段行程仍然重要。

把三者混在一起，就会出现两个极端。要么新会话背着所有家当出门，走两步就被上下文压得分不清重点。要么为了轻量什么都不带，走到半路才发现已经验证过的事实又要重新支付一次。

好的接力既不失忆，也不负重过度。

SoloMap 把路线图环节、Agent 对话、执行记录、验证结果和交接放在本地项目旁边，不是为了让你拥有更多历史页面。更重要的是，让一次执行结束后仍然能回到原来的环节，看到这一棒跑到了哪里，再决定继续、调整还是完成。

Agent 可以帮你整理证据，也可以根据历史提出下一步候选。但它不应该偷偷替你改掉产品方向。历史提供依据，方向仍然由你掌握。

还有一个特别容易混淆的地方。

时间顺序不等于行动顺序。

运行记录通常按时间排列，先执行了哪条命令，后修改了哪个文件，最后哪项测试失败。可下一次行动需要按判断的重要性排列。最后发生的事情不一定最重要，真正重要的可能是中间那条把原假设否掉的浏览器证据。

如果只按时间从后往前看，你很容易把最后一条输出当成结论。行动卡则逼着你重新问一次，哪条证据改变了选择，哪个缺口还挡在结果前面。

这也是为什么它不能完全由自动摘要代替。摘要擅长把长内容变短，却不一定知道哪一个取舍最值得保留。你可以让 Agent 先拟一张卡，再亲手确认决定与下一步。整个动作可能只花一分钟，但这最后一分钟把项目的方向权从历史堆里拿了回来。

我是真的觉得，这一分钟很值。

如果你想马上试一次，不需要迁移整个项目，也不用先整理过去半年。

选一个不关键、但最近被中断过的任务。先打开它最…[truncated 21 chars]