告别"上次做到哪了"：给 TRAE 装一个项目看板
借鉴 LoopX 开源项目的控制面理念，用一个命令让你的 TRAE 项目在分阶段开发中实现「关闭会话不丢状态，新开会话一秒接续」。
痛点：分阶段开发，每次开新会话都是"失忆"
如果你和我一样，习惯把项目拆成多个阶段，每个阶段新开一个会话开发——那你一定经历过：
- 新会话打开，TRAE 不知道上次做到哪了，你得先把上下文喂一遍
- 项目记忆文件越写越长，AI 读一堆过时信息才能找到"现在该做什么"
- 阻塞项、注意事项、设计规范散落在聊天记录里，换个会话就丢了
这本质上是 AI 上下文窗口是工作内存，不是长期状态。长时间跨会话的任务，不能靠"模型应该还记得"。
灵感来源： 字节跳动 OpenViking 核心贡献者黄瑞腾的开源项目 LoopX（2.1k Star），一个专为超长程 AI Agent 设计的轻量级状态内核。它的核心思路是：把目标、待办、门控、证据、配额从模型脑子里搬出来，外置成结构化控制面。
方案：三层控制面，一个命令搞定
核心设计借鉴了 LoopX 的「控制面与数据面分离」理念，把项目状态拆成三层：
/看板 命令
│
├─→ state.json ← 真相源 · 机器可读（增量更新）
├─→ boot-packet.md ← 薄启动 · 新会话入口（全量重生成）
├─→ project_summary.md ← 视图 · 人类可读（全量重生成）
└─→ project_memory.md ← 指针 + 约定（几乎不变）
| 文件 | 定位 | 更新频率 | 给谁用 |
|---|---|---|---|
state.json |
真相源，结构化状态 | 每次 /看板 增量更新 | TRAE 精准解析 |
boot-packet.md |
薄启动入口，< 500 字 | 每次 /看板 全量重生成 | 新会话 TRAE 第一眼 |
project_summary.md |
人类可读看板 | 每次 /看板 全量重生成 | 人类浏览 + AI 深度查阅 |
project_memory.md |
指针 + 项目约定 | 几乎不变 | TRAE 新会话兜底加载 |
新会话启动流程
TRAE 新会话 → 自动加载 project_memory.md → 看到指针：先读 boot-packet.md → 一眼看清 frontier + gates → 直接开干
关键设计：project_memory.md 放在项目根目录，同时同步到 TRAE 记忆目录。两个位置都有一份，确保 TRAE 不管从哪个路径启动都能加载到。
为什么这个方案更好
传统做法是把项目进度写成一段文本摘要，AI 需要通读全文自己判断哪些能做、哪些卡住了——阻塞项和注意事项混在一起，容易遗漏。
/看板 把信息拆成三个明确维度：
- frontier：现在能做什么，一目了然
- gates：什么卡住了，谁来解决
- lessons：方向有没有变，上次踩了什么坑
state.json 核心结构示例
{
"current_phase": 1,
"active": {
"frontier": [
{ "id": "todo-1-2", "title": "支付模块", "status": "ready" }
],
"gates": [
{ "id": "gate-1", "what": "需要生产密钥",
"resolve": "找管理员申请", "status": "blocking" }
],
"lessons": [
{ "type": "replan", "reason": "支付宝 SDK 文档不全，改为微信支付" },
{ "type": "self_repair", "reason": "token 刷新用异步锁，别用同步锁" }
]
}
}
每次 /看板 执行时按 phase 编号 和 todo id 去重，同一会话执行多次也不会重复追加。
怎么用
每个开发阶段结束时，执行一次 /看板 即可：
阶段 1 开发中...
│
▼
"好了，阶段 1 做完了" → /看板
│
▼
自动更新 state.json + boot-packet.md + project_summary.md
│
▼
关闭会话，开新会话
│
▼
TRAE 读到 boot-packet.md → "当前阶段 2，可以直接做 X，Y 被阻塞因为 Z"
│
▼
继续开发
自动看板规则： project_memory.md 中内置了自动提醒规则——当你说"好了"“完成了”"先这样"等结束信号时，TRAE 会主动询问是否需要执行 /看板。再也不用担心忘记存档。
完整命令
借鉴了 LoopX 哪些设计？
需要诚实地说：不是精确一一对应，有些是概念层面的简化映射，有些是做了大幅裁剪以适应分阶段开发场景。
| LoopX 概念 | /看板 对应 | 匹配度 |
|---|---|---|
| Canonical State（真相源） | state.json |
准确 — 同样是结构化真相源，视图从它派生 |
| Projection（视图） | project_summary.md |
准确 — 都是从真相源生成的人类可读视图 |
| CLI Packet（薄启动） | boot-packet.md |
概念映射 — LoopX 是每个 Turn 自动编译，我们是每个阶段手动生成，更新频率不同 |
| Frontier（可推进边界） | active.frontier |
简化版 — LoopX 还结合了 claim、lease、capability、quota 多维度计算，我们只按 ready/blocked 区分 |
| Gate（阻塞门控） | active.gates |
准确 — 都有 scope、resolve 方式和 blocked_todos |
| Evidence（完成证据） | todo.evidence |
简化版 — LoopX 要求 source、lineage、时间、新鲜度五维标注，我们目前只有 type + ref + note |
| Replan / Self-repair | lessons |
准确 — 都区分路线变更和执行修正 |
最大的差异
-
更新机制：LoopX 是每个执行回合都自动更新状态的实时看板，/看板 是每个阶段结束手动触发。关闭会话后中间状态不会自动刷新。
-
Frontier 复杂度：LoopX 的 frontier 是动态计算的——考虑了谁接手了任务（claim）、执行窗口是否过期（lease）、配额还剩多少（quota）。我们的 frontier 目前是简单的按 status 筛选，不支持并发和多 Agent 协作。
-
Evidence 深度：LoopX 的 evidence 要求明确标注数据来源、版本血缘、采集时间、新鲜度边界和适用范围。我们目前只做了简化标注。
换句话说，/看板 是 LoopX 思想的阶段性简化版——适合分阶段单人开发，但还远没到 LoopX 那种"200+ 小时无人值守不翻车"的工业级强度。
为什么不直接用 LoopX？
可能有人会问：既然 LoopX 更全还自动化，为什么还要自己做一个呢？
最直接的原因：LoopX 目前不支持 TRAE Work。
LoopX 原生适配的是 Codex App、Claude Code、Cursor、OpenCode 等运行时，没有 TRAE 的适配器。想在 TRAE 里用 LoopX，只能通过终端手动调用 loopx 命令，无法和 TRAE 的对话流程、记忆系统深度集成。
更深层的原因：两个工具面向的场景不同。
| 维度 | LoopX | /看板 |
|---|---|---|
| 目标场景 | 200+ 小时无人值守，多 Agent 协作 | 分阶段单人开发，每阶段手动切换 |
| 安装方式 | Python 3.11+，curl 安装脚本 | 零安装，一条 TRAE 命令 |
| 与 TRAE 集成 | 无原生适配，只能终端手动调用 | 深度嵌入 TRAE 记忆系统，project_memory.md 兜底加载 |
| 学习成本 | 需要理解 goal、claim、lease、quota、capability 等概念 | 一条命令，零学习成本 |
| 更新频率 | 每个 Turn 自动更新 | 每阶段手动触发 |
打个比方：LoopX 是一套完整的工厂流水线控制系统，适合管理 10 台机器 24 小时运转。/看板是工位上的任务交接白板，一个人干完一个阶段，擦掉旧内容写上新的，下一个接班的扫一眼就知道该干嘛。不是替代关系，是不同粒度的工具。
如果你需要的是建立在 TRAE 内、零配置、一条命令就搞定的方案，/看板 就够了。如果要做真正的多 Agent 无人值守长跑，那确实应该直接上 LoopX。
新项目和老项目都能用
不需要手动初始化。首次执行 /看板 时，命令会自动创建 .trae/ 目录和所有初始文件，无论新项目还是老项目。
文件结构一览
项目根目录/
├── project_memory.md ← 指针 + 约定（稳定，不随会话变化）
├── .trae/
│ ├── state.json ← 真相源（结构化，增量更新）
│ ├── boot-packet.md ← 薄启动入口（< 500 字）
│ ├── project_summary.md ← 人类可读看板
│ └── evidence/ ← 截图、日志等证据文件
如果你也在做分阶段开发，或者受够了每次新会话都要重新喂上下文——试试这个方案，欢迎反馈和改进建议。
LoopX 项目：github.com/huangruiteng/loopx