AI 任务做一半，中断后怎么继续？

让 AI 完成一个跨文件的开发任务，可能要经历理解需求、修改、测试和审查。对话中断或上下文换了一轮以后，代码还在，但“上次做到哪一步”并不一定能从最后一句话看出来。

例如 A 已完成，B 改了一半，C 依赖 B。重新开始既不能全部重做，也不能因为 B 的文件已经存在，就让 C 接着执行。

保存聊天记录或待办清单，够不够？

短任务通常够用。改动一旦涉及依赖和多轮验证，一句“已完成，测试通过”就缺少依据：测试是哪次跑的，后来有没有再改，用户确认的选择又在哪里？

可以靠版本记录和人工交接，也可以把任务状态写成可检查的文件。这个工作流选择后者，用 Markdown 保存需求决定、执行计划与结果。目标是下一次能继续判断，不是让每个小改动都生成一套文档。

需求记录保存决定和边界，执行计划承接当前要做的事；需要分版本推进时，再增加里程碑。入口文档负责导航，避免多处复制同一份约定。

目前已有校验与压力场景材料，尚未量化效率；记录是否值得维护，要看它能否减少恢复时的重复判断，而不是文件数量。

先分清“原本要做什么”和“现在做到了哪里”。前者包括任务、依赖、写入范围和验收方式，后者包括当前阶段、任务状态和恢复位置。

项目再单独保存完成回执，记录改动文件、验证命令、退出码、结果摘要和审查结论。三部分各回答一个问题：

默认假设、被拒方案和未决问题也要能找回。用户修改决定后，先更新对应记录，再判断哪些任务受影响，避免在执行总结里悄悄换掉需求。

先读取工作区，再对照状态和回执。项目的恢复处理大致如下：

A 已完成   → 看完成回执，保留已经做过的工作
B 进行中   → 核对实际改动和已有证据，继续未完成部分
C 待开始   → 等 B 满足依赖

状态写了完成，不代表旧结果永久有效。B 如果改到 A 依赖的行为，或者环境发生变化，A 的证据就需要重新评估。保留工作与检查证据是否过期，要同时进行。

代码写完和审查通过也分别记录。下次回来时，才能知道是在继续实现，还是还缺正式审查与交付步骤。

脚本可以检查记录结构。项目的校验会检查必填字段、依赖是否存在或成环、执行策略和并发参数是否一致，以及完成任务有没有必需的成功命令与审查记录。状态写入先通过这些条件，再用临时文件替换，减少半份状态残留。

但脚本不会重跑历史命令，也不知道断言有没有测到本次行为。因此仍要回看验证发生的时间、是否在最后一次修改之后、使用真实环境还是替身。

例如导入功能中的字段归一化，可以独立给输入、检查输出，逐个行为先测失败再实现；选文件与上传则需要环境验收。文档看内容、链接与构建，不为形式补单元测试。恢复时缺少原来的失败证据，就记录缺口，不必破坏已有实现重新演一次。

还要看会不会写同一个文件。两个任务可能逻辑独立，却同时修改 schema、锁文件或入口。项目在任务中声明写入范围，再结合依赖图安排串行或分批并行，检查并发数和工作区隔离配置。

实际会改哪些文件，仍由执行者判断，脚本不能从任务标题推导。各任务回到统一回执，有疑问或缺上下文的继续保留问题，不因同批其他任务成功就整批放行。分发上下文时，也保留验收、依赖、写入范围和授权条件。

小改动可以走轻量计划，只记范围、状态和证据；涉及公共接口、迁移或多个里程碑，再展开完整流程。代码与测试沿用项目结构，一次性检查工具放临时目录，文档目录保留约定和证据。