工具碎片
不同客户端、终端和编辑器各有入口，项目需要在人脑里重新拼回去。
SOLUTION EXPERIMENT · DEVHUB
隔几天再回来，先找回项目，不必先回忆上次在哪个工具里。
DevHub 把散在会话、分支、脚本和工具入口里的线索重新收拢到项目下面。当前版本已经能展示这套机制；它是否真的省时间，要由真实返回记录回答。
DEVHUB / PROJECT WORKSPACECURRENT BUILD / DEMO DATA
WORKFLOW 001 · 节点定位
当前节点 06共 7 个节点
把验证过的能力收进工作台
当前产品假设
对一部分多项目、多工具使用者，项目连续性可能比增加又一个入口更重要。
不同开发工具各自保存会话、配置和项目记录，但跨工具工作时仍可能需要人工重建现场。DevHub 以项目为入口，目标是比较这种恢复能否更快、更准，并让来源与边界可见。
- 已经确认
- macOS 应用已有可运行实现，覆盖项目、会话、工具、用量和本地运维。
- 仍待验证
- 尚无数据证明它稳定减少恢复时间、重复说明或跨项目错误，也没有外部用户留存证据。
问题现场
真正开始工作之前，我常常先花时间寻找上一次停在哪里。
一个项目可能先在 Codex 里规划，再到 Claude Code 里实现，随后回到终端排查。会话、配置和能力被各自的工具保存，项目本身却没有一条连续视图。
间隔几天后回来，首先要找回上次使用的工具、未完成的决定、可用技能、当前分支、端口和脚本。真正开始解决问题之前，工作现场已经重建了一遍。
DevHub 对准的正是这段恢复成本：让人从项目出发，看见状态、历史和可用入口，再选择最适合继续工作的工具。
问题地图
六种小碎片，最终打断同一条工作流。
它们单独看都不严重，叠加后却不断打断工作、隐藏成本，也让错误上下文更容易进入另一个项目。
后果：回到项目之前先找工具。
模型与订阅碎片
月费、API、额度和重置时间分散，重复购买与闲置成本很难看清。
会话与记忆碎片
历史对话留在各自平台，关键决定、失败原因和下一步无法按项目连续查看。
技能与插件碎片
Skills、MCP 和插件在不同工具里的安装、版本、权限和可用范围并不一致。
项目现场碎片
分支、工作树、脚本、端口、日志和本地服务不在会话历史里，也不在一个视图里。
上下文风险
自动汇总如果关联错误，可能把另一个项目的约束、秘密或旧判断注入当前任务。
DEVHUB 的回答
先找到项目，再选择工具。
DevHub 是一个本地 Mac 项目工作台：从同一个项目入口查看状态、历史和可用能力，再决定下一步在哪个工具完成。
项目优先
会话、工具、记忆、成本和运维入口都围绕项目组织。
本地优先
优先读取本机已有记录，不要求先把私有项目上传到新的云端。
恢复优先
衡量的不是功能数量，而是多久能开始第一条上下文正确的任务。
边界可见
明确哪些信息来自原始记录、哪些是总结、哪些仍需人工确认。
LOCAL FIRST / ONBOARDINGPROMOTIONAL COMPOSITION / DEMO DATA
SUBSCRIPTIONS / FIXED COSTPROMOTIONAL COMPOSITION / DEMO DATA
操作示意
从项目入口，到上下文与固定成本。
12 秒演示只呈现当前产品的三个界面层：项目入口、本地上下文边界和订阅视图。没有模拟点击，也不把界面展示写成使用效果。
证据边界
可运行，不等于已经有用户价值。
工程实现、使用效果和商业价值属于三种不同证据。当前页面只把已经确认的部分写成事实。
应用已有真实实现
当前开发版本可运行，项目聚合、AI 会话、工具启动、用量和本地运维都有实际界面与逻辑。
恢复项目上下文是否是核心价值
这个方向比“管理所有工具”更具体，但尚未通过持续使用和基线对照证明。
高频价值也许更窄
用户也可能只需要项目启动器、本地运维或成本视图，而不需要完整会话聚合。
外部用户是否会回来
目前没有外部留存、节省时间、减少错误、付费或推荐证据。
验证计划
先测恢复成本，再看 DevHub 是否改变它。
第一轮记录没有 DevHub 时的基线，再比较速度、正确性和重复说明量。“60 秒恢复”只是待校准的目标。
- 01
记录三次真实返回
记录项目、上次使用的工具、寻找历史的步骤、重复说明的内容和最终耗时。
- 02
连续比较十次项目恢复
覆盖至少三个项目和两种 AI 工具，对比使用与不使用 DevHub 的步骤和结果。
- 03
同时检查速度与正确性
记录是否进入正确分支、恢复正确会话、遗漏关键约束，以及是否发生跨项目误注入。
- 04
自用成立后，再邀请外部用户
邀请少量同样维护多项目、使用多种 AI 工具的人，先看他们是否会第二次回来。