换个 AI 接着做，先留下一份简单的进度

补记说明：本文于 2026 年 10 月 25 日整理并首次发布。页面日期是这份经验的归档日期，历史案例与当前开放状态分别说明。

AI 助手（Agent）能帮我改代码、写文章。有时它做完一轮，只留下一句“已经完成”。过两天换个对话继续，我却还要重新问：完成的是哪一部分？有没有测？改动在哪里？现在能给别人用了吗？

这类问题问多了，我开始觉得，进度记录应该帮助下一次动手。下一位接手的人或 Agent，最好不用翻完所有聊天，就能找到继续的位置。

九月写过几十个 Agent 线程带来的中转问题。当时更关心目标该怎么留下来。现在我想把问题再往下放一层：每次停下来时，留什么，才能少讲一遍？

01 / 停下来前，留下五行

交接卡示意。每行写一个具体答案，详细日志和版本链接另附；这张图本身不代表任何任务已经验收。

一句“完成”，装不下几种不同的结果#

以更新个人站为例。文章写好了、页面能显示了、变更通过检查了、内容已经发布了，分别都可以成为一个阶段的结果。但如果汇报里只剩“完成”，下一次就得重新核对。

我更愿意把结果写得窄一点：

这样写，别人不需要先猜“完成”指的是哪一种。发现缺口，也能直接回到缺的那一步。

02 / “完成”要说清是哪一步

文章更新的阶段示例。卡片说明各自能证明什么；本地预览与检查通过都不能自动当作已发布。

进度列表里，我希望最快看见的是两件事：发生了什么变化，接下来动哪一下。

比如下面这条，是更新文章的示例记录：

结果：两篇草稿已完成，本地排版已检查；下一步：审阅正文，确定本轮发布范围。

它不需要把全部操作日志塞进列表。详细的文件位置、版本、预览和检查结果，可以放在关联材料里。列表告诉我该看哪里，材料负责让我查得下去。

如果只是写“继续优化”，我回来还是要先做一次规划。换成“检查手机宽度下的表格，再确定标题”，下一次就有了可以直接执行的起点。

有些进度听起来很完整，真正接手时却没有落点：有截图，找不到对应版本；有测试结论，不知道测的是哪次改动；有本地文件，却以为已经在服务器上。

所以交接里，我会尽量把几样东西关联起来：当前需求、改动所在的位置和版本、实际做过的检查，以及尚未核对的部分。未提交的改动也要明确留下，不能只写一个提交号就假装覆盖了所有内容。

同样值得记录的，是这一轮没做什么。例如文章仍在本地、邀请链接还没开放、同步只核对了一端。这些事实会直接影响下一次该从哪里开始。

这也是我在整理 Agent 交付方法时一直想保留的关系：需求有来源，变更有版本，验收能找到依据。页面展示的是方法和目前的实践边界，完整的团队交付链还需要真实项目继续验证。

交接材料也会过期。记下来的时候主线还没变，下一次打开时，也许已经合入了别的改动；当时还有效的入口，后来也可能暂停。

因此，“照交接继续”之前，还要核对当前文件、分支和相关结果。旧记录负责解释来路，当前现场决定现在从哪开始。

如果手边没有任何管理工具，我觉得一份短文档也能先解决问题。停下来前写五行：

需要时再补上版本与链接。先让一次交接能用，再考虑把它接进更完整的系统。

我会让这五行尽量能独立阅读。下面是一份自编的文章更新示例，可以按自己的工作替换：

目标：把一篇产品经验整理成可公开阅读的图文。
产物：正文草稿和两幅解释图，均在本次工作区。
验证：标题与元数据已检查；手机排版尚未看完。
未决：产品当前入口还要回读，正文尚未发布。
下一步：先用手机宽度检查第二幅图，再核对公开入口。

这里没有塞进账号、内部地址或整段聊天。详细依据保留在合适的私有材料里，下一位有权限时可以继续核对。公开经验文章只展示模板与判断方法，不需要把整个执行现场一起公开。

接手时我会先找到上一次留下的产物，看它是否仍然存在，再看当前版本有没有变化。已经做过的检查，如果覆盖的文件没变、前提仍成立，就保留结论；有新改动交汇时，再补相应验证。

比如上次写着“正文完成，等待公开入口”，回来发现入口已经开放，下一步就是回读并更新链接，不必从头重写文章。如果发现文章后来又改过，旧截图就只能说明旧版，不能直接贴到这次结果后面。

还要留意“待别人判断”和“自己还没动手”的区别。前者应当写清需要什么决定，后者应当留下可执行动作。都写成“待处理”，下一次就得再花时间辨认。

文章记录和工程交付可以使用同一套思路，但公开呈现的细节不同。我在个人 Agent和交付方法里展示方法，具体项目的授权、版本和未决事项仍要按各自事实核对。

我想减少的，就是换个对话后重新解释同一件事的次数。至于节省了多少时间，目前没有做对照统计。眼下更实际的检查是：下一次打开这份记录，我能不能直接开始做事。