Q03 · 项目重入 · WORKFLOW 001
隔几天再回来，怎样准确恢复一个 AI 开发项目？
恢复不是找到最后一段对话。它要把正确项目、分支、未完成决定、关键约束、可用入口和下一步重新放回同一个工作现场。
当前决定
当前选择
先记录没有新工具时的恢复基线；只有免费方法反复失效，才增加新的工作台。
展开选择理由
速度和正确性必须一起看。几十秒打开错误分支、旧会话或另一个项目的约束，并不是更好的恢复。
Q03 / 决策地图TRIGGER → LAYERS → ONE ACTION
我的当前实验
为什么这样选
DevHub 先作为比较对象，不作为预设答案。
展开经历与判断依据
当前开发版本尝试从项目入口聚合会话、工具、记忆、用量和本地运行信息。这个机制可以通过脱敏界面展示，但“聚合了”不等于“恢复正确”。
在比较前，我需要先记录不用 DevHub 的自然流程：找了哪些地方、重复说明了什么、多久开始有效工作、有没有进入错误分支或遗漏约束。
当前可以确认展开记录
DevHub 已有项目、会话、工具、用量和本地运维相关实现与演示界面。
仍然不能确认展开记录
它是否持续缩短恢复时间、减少重复背景和跨项目误关联，以及外部用户是否会再次使用。
下一次自然返回项目时
下一步怎么做
不改流程，先记一次真实的恢复过程。
一条真实记录比十条功能想象更能说明问题在哪里。
- 01
记下离开项目多久、上次使用哪个工具，以及这次要完成什么。
- 02
记录你依次打开的文件、会话、终端、分支和脚本。
- 03
在第一条上下文正确的有效动作发生时停止计时。
- 04
标出重复说明、遗漏约束、错误分支或跨项目信息。
继续还是停止
恢复基线会决定 DevHub 应该继续、收窄，还是停止。
完整 Workflow 会把这次实验放回整个工具选择路径，而不是把产品当作结论。
回到 Workflow 001 的 DevHub 实验