Compact-Bench：AI builder 恢复会话后，能接着把产品做完吗？

AI builder 可能记得应用名称，也能准确描述你要的功能，却从错误的位置重新开工。10 月 22 日首次提交、10 月 28 日修订的 Compact-Bench 论文，为这种挫折提供了更明确的检验方式：同一个智能体，一次带着完整会话继续工作，一次只带着替代历史的摘要，最后分别完成了什么？

如果你是不懂代码、需要分多次会话做完应用的创始人，这个问题很实际。项目保存成功，摘要读起来也通顺，并不能证明明天会从今天已经验证过的位置接着做。你可能又要花一轮解释之前的决定，看着已经否决的方案重新出现，或发现所谓“完成”的功能根本没有验过。

我们的建议是，把续工能力当作一种可观察的交付能力来选择和管理。在交出更大里程碑之前，先让 AI builder 依据一份有证据的简短交接记录，接着完成一个尚未做完的功能。本文提供交接单、演示方法，以及区分必要探索和无谓返工的办法。这些是我们提出的产品管理建议，并非亲测结论。我们阅读了论文和官方文档，没有测量任何商业平台的失败率。

1. 这项研究改变了创始人该问的问题

Compact-Bench 的配对设计让代码仓库保持相同状态，再比较完整历史和仅有摘要两种情况下的续工结果。任务评估覆盖 35 个修复任务；另有两条评估线，分别研究 146 段会话中的重复细节，其中 143 段真实、3 段模拟，以及 106 条生产压缩链中的连续压缩。作者发现，保留了相关字符串，未必保住了把任务做完所需的进展。这是作者在特定编码实验中的观察，不能当作你的 AI builder 的可靠性数据。

由此更值得问供应商的是：“请演示项目中断之后，怎样继续朝同一个验收结果推进。”相比之下，“模型上下文有多大”不足以帮助你决策。更大的窗口可能推迟压缩，却没有回答恢复会话后能否看到正确文件、理解尚未解决的决定，或者发现证据对应的是旧版本。

这也不意味着要求智能体永远不重复步骤。真实开发本来就需要重读代码、重查假设。关键是让开工位置清楚可见：哪些部分已经实现？哪些已经演示？还有什么没有验证？下一步要做什么？观察到什么新情况后，应该改变这一步？

有了这些问题，也更容易看清一条漂亮进度汇报的含义。“预约流程基本完成”把好几种状态装进了一句话：页面可能已经有了，但可用名额仍来自示例数据；邮件可能已经起草，但送达还未检查。创始人无需逐行读代码，也可以要求把这些状态分开。

把论文当作检查续工能力的理由，不要把它直接变成供应商排名。研究预算下的代码修复，与托管平台保存完整项目，是不同的系统。可以借用的是问题和比较原则；产品是否适合采用，仍要看你自己的工作流证据。

2. 分清文件保存、上下文记忆和已验收进度

上下文窗口是模型一次调用中能考虑的材料。上下文压缩是把较长的工作历史替换为较短的表示。检查点是系统保存下来、可能用于续跑或恢复的状态。这些都在描述机制，并不自动意味着某个产品里程碑已经验收。

创始人要分清三个层面。第一层是项目本身，包括文件、数据、设置和集成。第二层是智能体目前如何理解这个项目。第三层是你保留的实际验证记录。项目已经变了，理解却没更新，智能体就可能自信地沿着错误前提继续做；理解即使准确，没有验收记录，你也无法知道“完成”究竟是指实现了，还是已经验证。

LangGraph 的持久化文档区分了单条线程内的图状态检查点，以及跨线程使用的数据存储。这说明保存状态有明确范围，并不意味着所有平台都保存项目的所有方面。应向自己的 builder 问清：保存项目具体包含什么，新会话还要重新还原什么？

以预约应用为例，文件里可能已有取消页面，摘要写着取消功能已实现，上次演示却只证明按钮能打开弹窗。这三件事可以同时成立，而用户真正需要的结果仍未完成。缺失的证据是：确认取消后，名额是否释放，用户是否能看到预期结果。

还要把稳定的项目约定与不断变化的续工记录分开。Claude Code 的记忆文档说明，持久指令和自动积累的笔记属于上下文，并不是强制执行的配置。类似地，“沿用现有设计系统”适合放在长期项目指引里；“预览 B 中取消弹窗能打开，但名额释放尚未验证”应该放在当前进度记录里。把两者塞进一份越来越长的记忆文档，只会让过期状态更难发现。

3. 跟着一个未完成功能，看中断会带来什么

设想一位创始人正在用 AI builder 制作小型工作坊预约服务。客户选择场次、预订名额并收到确认。现在要增加取消功能，取消后名额应重新开放。builder 已经添加弹窗，也接好了接口，但预览中还没有证明名额变化正确。创始人需要离开，于是暂停工作。

不合格的交接可能是：“取消功能已实现，接下来润色并部署。”下一次会话很可能顺理成章地去调整文案、间距和发布流程。问题在重启之前就发生了：进度汇报把“代码已经存在”提升成了“功能已经完成”。即使压缩完整保留了这句话，也会把后续工作带离那个尚未检查的关键点。

有用的交接应写成：“预览 B 已有弹窗和取消接口。已经演示打开及关闭弹窗。确认取消后，名额变化尚未验证。下一步使用测试预约执行取消，再检查该场次的可用名额，之后才讨论部署。”它指向一个能观察的缺口，也把下一步与这个缺口连在一起。

再加入一个变化：暂停期间，队友修改了名额处理逻辑。旧交接即使句句曾经正确，现在也不够了。恢复后的 builder 必须比较项目版本，重新核实相关证据。交接单的作用是引导检查，不能强迫系统沿着已经过期的计划机械执行。

另一种情况是外部结果不确定。假设取消请求超时了，交接就必须明确写“结果未知”，并指向那条测试预约。未经检查就重复请求，可能干扰测试，或重复发送后续通知。“没有开始”和“已经请求、结果未知”是不同状态，下一步也应不同。

这个场景完全是假设，并非客户案例或平台测试。它说明该选择怎样的未完成功能来演示续工能力：一个看得见的界面、一项需要保存的状态变化，以及一个尚未解决的验证点。纯粹调整外观的任务，很难暴露 builder 能否跨过真实依赖、保住工作进度。

4. 结束会话前，填好这张续工交接单

下面是一份供创始人使用的记录，不是运行时数据结构，也不保证模型一定遵从。把它保存在项目里，链接到下一次仍能打开的证据。每份交接单只对应一个功能或紧密相连的一小段工作，不要把整段聊天复制进去。

“已否决方案”尤其要写准。“永远不要使用前端状态”是没有依据的泛化；“版本 A 仅在前端维护的名额刷新后不正确”，才是可以保留的观察。它能防止无谓重试，也没有禁止未来采用真正解决问题的新设计。失败经验应帮助减少重复，而不是变成拒绝新证据的死规则。

证据可以是一段短录屏，也可以是预览链接加可复现的操作说明，或注明版本的测试报告。单张截图也许能证明弹窗存在，却证明不了名额已经释放。证据必须适合所支持的判断。技术协作者可以附上自动化检查，创始人仍需要能理解的用户结果说明。

不要在交接单里放密钥、私人客户资料或原始访问令牌。使用测试记录，必要时指向有访问控制的系统。标明最后更新时间，更新过期状态，不要把相互矛盾的汇报不断堆在下面。同时保留可追溯的历史。目标是一份简短、有效的当前进度说明，而不是另一份每天早晨还需要创始人总结的长文档。

5. 扩大里程碑之前，先看一次续工演示

在测试环境和可恢复的项目副本里开始。选定未完成的功能，保存当前版本，展示已经能工作的部分，指出尚未解决的检查项，然后在结束会话前填好交接单。不要让恢复后的会话倒过来编写一份“之前应该验证过什么”的回顾。

接着使用平台日常支持的方式恢复工作。它可能保留原聊天、生成摘要，也可能新建一个与项目关联的会话。先让 builder 确认当前版本，说出下一项待验证问题，并说明交接以后项目是否发生变化，然后才继续开发。这样检查的是你真正会使用的体验，而不是在最后一刻把全部答案重新塞进提示词的特殊演示。

观察接下来的行为，不要只听开场说明。它有没有读取相关的最新状态？有没有保住已能工作的部分？有没有调查那个未完成的检查项？是不是又要求你重复已经记录的产品决定？是否在没有新证据的情况下，重新采用已否决方案？摘要说得很好、实际却做错了方向，续工能力仍未得到证明。

如果想作公平比较，可以请技术协作者确认平台是否支持从同一保存状态建立两个隔离副本：一个保留通常的历史，一个走平台支持的交接或压缩历史路径。保持任务和可用工作时间相近。这里借用的是论文的比较原则，不是声称复现 benchmark。若无法隔离初始状态或控制历史，就把结果称作工作流观察，不要估计“压缩导致了多少损失”。

公开代码仓库提供了运行工具，并将任务完成与细节保留分为不同评估线。数据卡目前也说明了冻结历史和匹配的仓库快照。技术团队可以进一步阅读这些材料，研究如何复现。创始人不必先跑完整套研究，才有资格要求产品演示；通过本文建议的演示，也不代表通过了论文 benchmark。

6. 衡量无谓返工，也给合理复核留出空间

重新打开一个文件，不一定是在浪费时间。文件可能变过，先前观察可能不完整，重新检查也可能恰好是最稳妥的下一步。判断返工要看原因和后果，否则团队反而可能压制那些让项目更可信的核查。

可以使用四个实用类别。时效核查，检查过去的证据现在是否仍适用；必要探索，调查新出现的不确定性；信息重建，重新拼回本应已经可用的信息；回归修复，修复续工时破坏的已验证行为。这是我们提出的管理分类，不是 Compact-Bench 测量过的标签。

每次会话记录经过的时间、能取得的实际平台用量、创始人重新解释所花的时间，以及最终验收的结果。另行标出信息重建和回归修复。一轮会话即使用了更少积分，如果创始人必须从头还原任务历史，总成本仍可能更高；反过来，多花时间核查已经变化的集成，也可能非常值得。

不要制造虚假的精确性。除非团队已经选定合理的规划假设，否则无需给创始人时间强行标一个时薪。分钟数、实际收费和完成的检查项可以分别比较。以后如果要折算到一个总数，应展示采用的假设，也保留原始各项，让其他人能按自己的取舍作判断。

计算完成比例时，把所有尝试过的续工都放进分母。中途放弃、被阻断的会话也要记录原因，不要因为 builder 没有给出最终答复就删掉。还要分清“builder 说完成”“创始人看到结果”“具备发布条件”三个事件。一次续工可以成功产出已验证的测试结果，同时发现应推迟上线的问题。

小规模演示能帮助采购判断，却无法可靠估计罕见故障。在交出更大的里程碑前，应在不同工作上重复观察，例如带存储状态的功能、需求已经变化的功能、工具结果不确定时的中断。根据产品选择场景，不要宣称随意规定的测试次数就能认证可靠性。

7. 依赖检查点之前，问清它到底能恢复什么

同样叫“检查点”，背后的含义可能不同。有的恢复聊天，有的恢复代码，有的两者都恢复；数据库变化、项目外配置、其他服务里的操作可能不在范围内。让供应商用普通语言列出：恢复以后什么会回来，什么仍保留现在的状态。

Claude Code 的检查点文档就是一个具体例子：恢复会话与恢复代码有不同选项，文件跟踪也存在边界，例如仅由 shell 命令修改的文件。这是该工具自己的文档边界，不能推广到所有托管 builder。你的平台需要给出自己的恢复范围。

对于代码项目，Git status可以展示已跟踪文件的差异和未跟踪文件。预览看起来没问题，不能替代“哪些改动实际已经保存”的核查。Git revert通过新的提交撤销先前提交的改动，但不会撤回客户邮件，也不会恢复所有外部系统。创始人应该请协作者解释恢复方案，而不是照着通用教程运行可能丢弃改动的清理命令。

运行时续跑也有相关边界。LangGraph 的中断文档说明，恢复时节点可能重新执行，外部影响需要相应处理。所谓幂等性，就是重复执行一个操作，也不会在预期效果之外再多产生一次影响。因此，“接着做”必须分清是在重建一个页面，还是又发一封通知、提交一次付款请求、再写一条记录。

回到假设的预约应用。恢复昨天的文件，并不能回答超时期间取消请求是否完成。再次请求之前，先检查测试预约的权威记录。对于真实产品，要明确谁有权限核查外部影响，谁负责修复。创始人的交接单可以指向证据，却不能替代底层恢复机制。

这不意味着每个原型都要自建编排系统。更实际的做法是让首次演示可逆，并且不要把“代码恢复”当成整个业务已经回滚。

8. 按实际能力，约定合适的交付方式

如果 builder 能依据最新证据接续功能，解决未完成的检查项，又保住已有行为，可以逐步扩大它的责任，让它承担用户旅程中下一小段边界明确的工作。交接单继续跟随里程碑保存，换人或换会话时，也能看明白进度。

如果文件能保存，但智能体每次都需要你重新解释，就把工作包拆短，由创始人维护进度单。对小产品来说，这仍可能是能接受的工具。取舍在于：你购买的是实现辅助，更多协调工作还留在自己手里。预算和排期应反映这份工作，而不是默认系统具备自主续工能力。

如果平台连项目版本都无法确认，或分不清已实现与已验证，就暂时让它处理草稿和隔离实验，并要求在测试项目中展示缺失的能力。不要因为销售演示成功接着改了一个简单页面，就迁移真实业务流程。

如果续工反复破坏已验收行为，先缩小功能边界、改善验收证据，再考虑增加模型预算。更贵的模型或许有帮助，但里程碑本身含糊时，它也无法替你建立“完成”的定义。反过来，交接单写得再好，也修复不了恢复了错误项目状态的平台。

有些工作不需要完整套用这套方法。一次性生成、没有存储状态的落地页草稿，可能只需保存版本并检查外观。长期运行、有外部集成且多个依赖尚未完成的应用，则需要更扎实的续工证据。真正的区别是丢失工作位置会付出多少代价，与创始人懂不懂代码无关。

与外包团队或同事合作时，还要写清责任：谁更新交接单，谁确认版本，谁验收续工结果？builder 可以起草记录，但决定能否进入下一里程碑的判断，应由对交付负责的人核实。这样，智能体自己写的进度汇报才不会成为它自己的验收证明。

9. 把续工能力放进下一个产品里程碑

下一次构建时，先选一个你能观察完成结果的功能，用日常语言写清用户最终要做到什么。让 builder 展示当前版本，把“已经存在的改动”与“已经演示的行为”分开。保留最少但足够有用的证据，再指明一项尚未解决的检查。

暂停之前填好交接单，放在下次会话能够访问的位置。结果未知的操作继续明确标成未知。通过平台支持的方式保留可恢复状态，必要时请人协助。回来以后，先检查当前状态，再开始新改动。

续工结束后，仍按同一个用户结果验收，把必要复核与信息重建、回归修复分开记录。证据过期就更新证据，需求改变就公开调整里程碑。如果 builder 无法继续，也把这次失败保留在交付记录里，不要用一份漂亮回顾把它覆盖掉。

是否扩大 builder 的责任，应根据这些观察结果决定。你需要的是能把工作继续推进、同时让人看明白进度位置的工具。Compact-Bench 让这个问题在今天更值得问；决定下一步投入的证据，则要来自你自己的项目。

参考资料

1. Compact-Bench 论文 v2
2. Compact-Bench 公开代码
3. Compact-Bench 数据集与发布说明
4. LangGraph：持久化
5. LangGraph：中断与恢复
6. Claude Code：检查点
7. Claude Code：项目记忆
8. Git：status
9. Git：revert