夜雨聆风摘要
抱歉标题党一下。。其实这篇文章主要想介绍下Jaade的「Project」功能。
Jaade是一个面向Claude Code、Codex、OpenCode和Cursor 的本地Agentic IDE。它的「Project」功能不是单纯的「文件夹」，而是把三件事放在一起：把相关sessions收进同一个项目；让开发者只定义目标，由agent分析、拆解和执行；把Task DAG固定成可复跑的workflow。重点不是让开发者退出现场，而是让开发者能看见每一步、审查每个结果，并在需要时恢复任何一个session。
正文
假设你今天要做一个看起来很普通、实际很容易失控的开发任务：
给一个产品加「团队邀请」功能：要先定义 API，再改后端，再改前端，最后补测试和跑构建。
如果只靠一个AI聊天窗口，这件事很快会变乱。
一个窗口里在讨论接口，另一个终端里在跑测试，第三个对话里让agent 改后端，第四个对话里又在改前端。等任务跑到一半，你会发现最难的不是让AI写代码，而是回答三个问题：
• 它现在到底在做哪一步？ • 哪些子任务已经完成，哪些还在跑？ • 如果明天继续，我还能不能找回上下文？
这就是 Jaade的「Project」想解决的问题。
Project Work tab的 Graph / Task DAG：可以看到 Project Master、多个 worker、任务状态和 Restart Workflow。
Project 不是一个更长的聊天框
我觉得Project功能最值得讲的，不是「它能开很多 agent」。
更准确地说，它把三种场景合在了一起。
第一种，是 session 文件夹。
这是最容易理解的一层。当一个需求牵涉多个 sessions 时，你不再需要在左侧列表里靠标题猜「哪个是定义接口的」「哪个是改后端的」「哪个是改前端的」「哪个是跑测试的」。Project 把它们收进同一个项目里：master session、worker sessions、terminal workers 都有共同的目标、共享说明和状态。
比如你要做「团队邀请」功能，左侧可以只看到一个 Project 入口；点进去之后，才看到 master、接口设计 worker、后端实现 worker、前端实现 worker、测试 worker、terminal worker。它先解决的是整理问题：这批 agent work 属于同一件事，不应该散落在十几个普通聊天标签里。
第二种，是 goal 驱动的执行。
这一层适合更开放的任务。开发者不需要一开始就把所有任务拆成 checklist。你可以只写目标：
我有一批训练数据，帮我设计并运行几组模型实验，比较 performance，然后根据结果决定下一步。
然后让 master session 做分析：它先判断需要哪些实验，拆成多个 worker 任务，决定哪些模型可以并行训练，哪些评估必须等训练结果出来。开发者负责确定目标和边界，agent 负责把目标变成可执行计划。
这和普通聊天最大的区别是：你不是逐条命令 agent「先跑 A 模型」「再调 B 参数」「然后比较结果」。你只说结果要什么，master 自己把目标拆成结构化任务：
• 一个 worker 做数据检查和特征分布分析。 • 一个 worker 训练 baseline 模型。 • 一个 worker 训练更复杂的模型。 • 一个 worker 做 evaluation 和指标对比。 • 一个 terminal worker 跑训练脚本、收集日志和保存结果。
第三种，是 可复跑的 workflow。
当 master 生成 Task DAG 后，这张图不只是一次性过程记录。它可以变成一个固定下来的工作流：哪些任务先跑，哪些任务后跑，哪些可以并行，哪些依赖构建或测试结果。
这对重复性工程流程尤其有用。最典型的例子是 release。
每次发版，你大概都要做同一串事：
1. 更新 changelog 和版本号。 2. 跑 typecheck、lint、test。 3. 构建 macOS / web / CLI 等产物。 4. 检查产物大小、签名、打包内容和下载链接。 5. 生成 release notes。 6. 推送 tag 或触发发布 workflow。
这类流程非常适合固化成 Task DAG。第一次跑失败，你不需要重新解释整个发布流程。修完一个节点后，可以沿着同一张 DAG 重新跑，让 workflow 从头验证一遍。对开发者来说，这就不只是「agent 帮我发了一次版」，而是「我沉淀了一套以后还能复用的workflow」。
视频 1：Project 里的 New Release workflow。Task DAG 展示了 master、已完成任务、ready 任务、running 任务和 pending 任务；同一套流程可以通过 Restart Workflow 重新跑。
这三个层次叠在一起，Project 才变得有意思：它既能收纳上下文，也能拆解目标，还能沉淀流程。
一个 master，多个 workers
在 Jaade 里，Project 更像一个小型开发现场：一组相关 sessions 被放在同一个 Project 里，其中可以有一个 master session，也可以有多个 worker sessions。
你可以让 Claude Code 当 master：
你负责实现团队邀请功能。先拆任务：一个 worker 定义 API contract，一个 worker 实现后端接口和权限校验，一个 worker 实现前端邀请表单和成员列表，一个 worker 补测试，一个 terminal worker 跑类型检查、单元测试和构建。每个任务完成后汇总证据、风险和剩余问题。
然后 master 会维护一张 Task DAG。
DAG 里的每个节点是一件具体的事：定义接口、改数据库或服务层、实现 UI、补测试、跑命令、总结结果。边表示依赖关系：比如「前端实现」必须等「API contract」之后，「完整测试」必须等「后端和前端都完成」之后。
Jaade 的 Project 默认 5 个并发 workers（可在 1–10 之间设置；terminal worker 不计入这个并发上限）。这个数字不重要，重要的是思路变了：Agent 在忙，但你不会被消息淹没
多 agent 并行最怕什么？
不是它们不够聪明，而是它们太能说。
一个复杂任务跑下来，Claude、Codex、terminal 都可能产生输出。如果所有内容都堆在同一个滚动列表里，开发者最后还是要人工翻垃圾堆。
Jaade 的处理方式是：让当前消息、当前 turn、当前任务成为焦点。
在 session 里，你可以聚焦正在发生的那一步；在 Session Overview 里，每个 turn 是独立的横向泳道。点进某个 turn，其他 turn 会隐藏到背景里，你看到的是这一轮发生了什么、用了哪些工具、读写了哪些文件、等待了哪些权限。
这听起来像一个 UI 小细节，但实际很关键。
当一个 master 正在调度 5 个 workers 时，你不需要同时阅读 5 段完整聊天。你需要的是：
• 当前哪个 worker 卡住了？ • 它卡在命令、权限、文件修改，还是外部工具？ • master 对这个结果做了什么判断？
Jaade 把 agent work 从「一大坨 transcript」拆成可以查看、可以跳转、可以恢复的结构。
Session Overview：把一小时的 agent run 变成一张地图
Project 解决的是「多条 session 怎么协作」。
Session Overview 解决的是「一条很长的 session 怎么读」。
比如一个 worker 负责实现后端邀请接口。它可能经历了这些 turn：
1. 先读已有 user/team/member 模型。 2. 跑一次搜索，确认权限和邮件发送逻辑在哪。 3. 实现 invite endpoint 和校验逻辑。 4. 跑类型检查和后端测试。 5. 根据报错再修一轮。 6. 总结 API 行为、边界情况和风险。
如果只看聊天，这就是一长串文本。
在 Session Overview 里，这些 turn 会被放到一张可缩放的画布上。你能看到时间线、每个 turn、每次命令、每个摘要节点；点进某个 turn，其他内容会退到背景里，只留下当前这一步。点击节点还能回到聊天里的原始消息。
视频 2：Session Overview 把长 session 展示成 turn、command、summary 和 timeline。
Terminal 不是外部工具，是第一方工作区
很多AI coding工具最尴尬的地方是：聊天在一个地方，真正干活还得回终端。
Jaade 不是这样。
它内置的是第一方 terminal：真实 PTY、xterm.js 渲染、tabs、split panes、scrollback 搜索、文件拖入、commit hash 跳转。你可以像平时一样跑 npm run build、du -sh、ls、release 脚本，也可以把 terminal 放在 Project 工作流里。
更有意思的是，Project 的 DAG 里不一定每个 worker 都是 agent。
有些任务就是 shell command：
跑一遍
npm run typecheck和npm run build，再用rg检查状态字段有没有遗漏引用。
这种任务用 terminal worker 更合适。它的完成状态由 exit code 决定：0 就是 done，非 0 就是 error。master 还能读取 terminal 的近期输出，把结果汇总回 Project。
这就把「AI 聊天」和「工程事实」接上了。
Agent 可以推理，但构建是否成功、产物是否存在、脚本是否退出 0，还是由终端说了算。
Terminal split panes：Jaade 内置终端作为第一方工作区，不需要在聊天、终端和文件浏览器之间来回切换。
历史不是归档，是可以继续工作的上下文
复杂任务很少一次完成。
今天 master 拆了 5 个 worker，跑到一半发现邀请权限还有一个边界情况；你去开会，回来后电脑重启；第二天你想继续，但已经忘了昨天哪个 Codex 改了接口、哪个 Codex 改了前端。
在 Jaade 里，Claude Code / Codex 自己保存下来的 session 数据，会被放进一个更容易检索和恢复的 History 入口。
History 不是「聊天记录垃圾箱」。Jaade 在这些原生 session 数据之上提供搜索和恢复接口：你可以按 agent、status 搜索和过滤。点开一个历史 session，你可以看到 transcript、相关文件变更、运行时长、模型、分支、状态，然后通过 Jaade 回到对应的 resume 流程。
这对 AI 开发非常重要。
传统聊天的上下文经常是一次性的，关掉就散了。Claude Code / Codex 已经会保存自己的 session；Jaade 做的是把这些 session 当成工作单元索引出来：它做过什么、改了什么、为什么这么做，之后都可以被搜索、打开，并从对应上下文继续。
History 搜索界面：按关键词搜索，再按 Claude / Codex / OpenCode / Cursor 过滤，找到过去的 session 并回到对应上下文。
先留一个引子：真实环境验证可以放到下一篇
写代码只是开发流程的一部分。
有些问题最终还是要去真实浏览器或桌面 App 里验证：页面能不能打开，按钮能不能点，系统权限有没有弹出来，UI 状态是不是符合预期。
Jaade 已经支持这部分能力（Computer Use / Browser Use）：让 agent 在受控授权下使用浏览器或桌面环境。不过这篇先不展开。Project 和 Session Overview 已经足够说明一个更基础的问题：当 agent 开始并行工作，开发者需要的不是更多聊天窗口，而是一个能组织任务、观察过程、恢复上下文的工作台。
真实环境验证更适合单独写下一篇。
一个完整的 Jaade Project 工作流会长什么样
把前面的东西串起来，真实使用大概是这样：
1. 你创建一个 Project，写下目标：实现团队邀请功能。 2. 你指定 Claude Code 作为 master，让它拆任务。 3. master 生成 Task DAG：API contract、后端实现、前端实现、测试、构建、汇总风险。 4. Codex workers 并行处理接口、后端、前端和测试。 5. terminal worker 跑命令，用 exit code 和输出给出事实。 6. 你打开某个 worker 的 Session Overview，看它如何从读取文件、执行命令到生成 summary。 7. 你只关注当前关键消息、DAG 状态、Overview 节点、terminal 输出和最终 diff。 8. 任务中断也没关系，History 里可以搜索、打开、恢复任何 session。
这就是 Jaade 想表达的Agentic Coding方向：
不是一个更会聊天的机器人。
而是一套可调度、可观察、可恢复、可审查的 agent 工作流。
开发者没有离场，只是从执行者变成调度者和审查者
我不太相信「AI 会自动完成整个软件项目」这种说法。
真正有用的 AI 编程工具，不应该要求开发者闭眼相信它。相反，它应该把每一步摊开：谁在做、做到了哪、改了什么、失败在哪、下一步怎么恢复。
Jaade Project 的价值就在这里。
它让一个 Claude Code 可以调度多个 Codex 和 terminal workers，一起完成一个复杂开发任务。但它没有把开发者从流程里拿掉。
开发者仍然负责定义目标、给指令、审查 DAG、看 任务进度、看 diff、决定是否提交。
Agent 多干活。
开发者看得见、管得住、接得回来。
这可能才是 AI 软件开发真正会落地的样子。
了解更多Jaade的功能: https://jaade.app，或者点击「阅读原文」
