Trellis 多 CLI 协作体验：Codex、Claude Code、OpenCode 一起干活

之前用 Claude Code 写代码很爽，但一个工具做所有事，成本和时间上总有些浪费。后来试了 Superpowers，体验不错，但它在多 CLI 协作这块有点局限。最近切到 Trellis，终于实现了我想了很久的一个工作流：让不同的 AI CLI 各司其职，接力完成一个任务。

1. 为什么需要多 CLI 协作

现在的 AI CLI 选择很多：

• Codex（OpenAI）：规划能力强，思路清晰
• Claude Code：代码实现稳，上下文理解深
• OpenCode：模型选择灵活，可以切便宜模型做体力活

但问题是，它们之前各自为战。每个 CLI 都有自己的状态、记忆、任务上下文，切工具等于切大脑，前面聊的内容后面不认。

我的理想场景是：

1. Codex 做架构设计和任务拆分
2. Claude Code 写核心代码
3. OpenCode 切换廉价模型做补全、测试、格式化

这样又快又省钱，还能保持质量。

2. Trellis 是什么

Trellis 本质上是一个 AI CLI 的任务协调层。它不替代任何一个 CLI，而是让它们在一个统一的状态空间里工作。

核心能力就两点：

• 共享任务状态：你在 Codex 里做的计划，Claude Code 打开直接能继续
• 会话无缝切换：同一个任务 ID，不同 CLI 都能读写上下文

这就相当于给几个 AI CLI 搭了一个共享工作台。

3. 工作流

实际跑起来的流程大概是下面这样。

第一步：Codex 做规划

1

codex plan "实现一个支持 JWT 鉴权的用户登录系统"

Codex 会输出一个任务清单：

• 设计用户表结构
• 实现密码哈希和 JWT 签发
• 写登录/注册接口
• 加中间件做鉴权校验
• 补单元测试

我确认计划没问题后，把它提交到 Trellis 的任务空间。

第二步：Claude Code 写核心代码

1

claude code --task jwt-auth

Claude Code 直接读取 Codex 留下的任务描述和上下文，开始写核心实现。它的代码质量高，特别适合做关键路径的编码。

第三步：OpenCode 切换模型做体力活

1

opencode --model deepseek-v4-pro --task jwt-auth

这里我切了一个便宜的模型，让它去：

• 写重复的单元测试
• 生成接口文档
• 做代码格式化
• 跑 linter 修复警告

这一步成本极低，而且 OpenCode 也能看到前面两个 CLI 已经完成的代码，不会重复劳动。

4. 与 Superpowers 的对比

之前我用的是 Superpowers，它是个 Claude Code 的 Skill，主要能力是扩展 Claude Code 的上下文管理和工具调用。用了两个月，优缺点都很明显。

Superpowers 的优势

• 如果只用 Claude Code，Superpowers 的上下文管理非常细腻
• 作为 Skill 集成度高，开箱即用
• 在 Claude Code 内部的任务路由做得不错

Trellis 的优势

• 真正的多 CLI 协作：不是在一个工具里切模型，而是让不同工具干各自擅长的事
• 成本可控：Codex 做规划贵一点可以接受，但写代码和写测试可以切到更便宜的模型
• 不被单家模型绑定：今天 Claude 强，明天可能别的模型更强，Trellis 这种架构更灵活

5. 实际体验

用了 Trellis 两周，几个真实感受：

成本确实降了

以前一个中等复杂度的功能，全用 Claude Code 做，大概要消耗 2-3 美元的额度。现在 Codex 做规划（大概 $0.3），Claude Code 写核心代码（$1.2），OpenCode 切低价模型写测试和格式化（$0.2），总成本能压到原来的一半左右。

质量没有明显下滑

因为关键路径还是 Claude Code 在做，规划和审查环节也有 Codex 把关。便宜模型只负责边界清晰的体力活，出错的概率本身就不高。

切换 CLI 的摩擦很小

Trellis 的命令设计比较统一，换工具时不需要记两套完全不同的语法。任务上下文加载也是自动的，不用手动导入导出。

6. 团队协作：不只是多 CLI，还可以多人

前面说的都是一个人用多个 CLI 的场景。但 Trellis 还有一个被低估的能力：多人共享同一个任务上下文。

场景举例

我和同事一起做一个项目，我负责后端，他负责前端。以前的问题是：

• 我用 Claude Code 写的后端接口定义，他那边看不到，只能靠口头同步
• 他用 Codex 规划的前端组件拆分，我也只能等他贴给我
• 两个人各自用各自的 CLI，上下文完全割裂

用了 Trellis 之后，只要 trellis init -u 时指定同一个团队标识，我们就能共享同一个任务的上下文：

1
2
3
4
5

# 我这边
trellis init -u team-backend --claude --opencode

# 同事那边
trellis init -u team-frontend --claude --codex

然后我做完后端接口设计，提交到任务空间，他那边直接拉取就能看到接口定义，不用再手动同步。

和 Superpowers 的区别

Superpowers 是 Claude Code 的 Skill，本质上只能管一个 CLI 的上下文。它没法做到跨人的状态共享——你的会话只属于你自己。

Trellis 的 -u 参数让每个参与者有了身份标识，不同人、不同 CLI 在同一个任务空间里协作，状态是实时可见的。这一点在 Superpowers 里做不到。

7. 安装和配置

Trellis 的安装比较直接，支持 macOS、Linux 和 Windows（WSL）。

1
2
3
4
5

# macOS / Linux
curl -fsSL https://trytrellis.app/install.sh | sh

# 或者 brew
brew install trellis

装完之后需要初始化工作区：

1

trellis init

然后按提示把你常用的 CLI 绑定进去，绑定的时候需要指定用户名标识，这样 Trellis 才能正确关联不同 CLI 的会话状态：

1
2
3
4
5
6
7
8

# 交互式：检测已安装的平台并询问要配置哪些
trellis init -u your-name

# 显式：配置一个或多个平台
trellis init -u your-name --claude
trellis init -u your-name --claude --cursor --opencode
trellis init -u your-name --codex --gemini
trellis init -u your-name --pi

绑定后 Trellis 会在后台维护一个共享的上下文数据库，几个 CLI 都能读写。

8. 斜杠命令：只需记 3 个

从 Trellis 0.5.0 开始，官方走了 skill-first 设计路线：大部分动作由 auto-trigger skill 自动触发，不需要记一堆命令。以前那些 /before-backend-dev、/check-backend、/record-session、/onboard 之类的，要么迁移到了 skill / sub-agent，要么直接移除了。

现在只剩 3 个斜杠命令：

/trellis:start：开启会话

这个命令让 AI 先理解当前项目上下文：读取 .trellis/workflow.md、运行 get_context.py 获取开发者身份 / git 状态 / 活跃任务、读取 spec 索引，然后汇报当前状态并问你要做什么。

但很多平台不需要你手动跑。Claude Code、Cursor、OpenCode、Gemini、Qoder、CodeBuddy、Copilot、Droid、Pi Agent，以及启用了 hooks 的 Codex，通常会在会话开始时自动注入上下文，所以不会安装用户可见的 start 命令。只有 Kilo / Antigravity / Windsurf 这类 agent-less 平台才需要显式入口。

典型用法：

1

/trellis:start

然后直接描述任务：

1

新增用户登录功能

Trellis 会判断这是问答、小修，还是正式开发任务；不确定时它会走任务工作流，保证 sub-agent 能拿到正确 spec。

/trellis:continue：推进当前任务

这是日常最常用的命令。注意它是单个任务内的 continue，不是"切到另一个任务"或"恢复所有上下文"。AI 会看当前 task 的 task.json.status 和 workflow-state breadcrumb，再对照 .trellis/workflow.md 判断下一步该做什么。

典型流程：

1

新增用户登录功能

Trellis 自动触发 trellis-brainstorm，创建 task 并起草 prd.md。

1

/trellis:continue

PRD 确认后，进入下一步，例如填写 implement.jsonl / check.jsonl，给 sub-agent 准备上下文。

1

/trellis:continue

上下文准备好后，进入实现与检查阶段，spawn trellis-implement 和 trellis-check sub-agent。

1

/trellis:continue

sub-agent 跑完后，进入 spec 更新、最终验证、收尾阶段。

总结一下就是：以前你要记住每个 workflow 阶段该调用哪个命令，现在基本是自然语言 + continue 跑完整个流程。

/trellis:finish-work：归档任务 + 写 journal

这个命令不是用来提交功能代码的。官方明确说，只有在工作 commit 已经存在后才应该运行；如果工作区还有未提交代码改动，它会拒绝执行。

执行后会：

1. 读取 active tasks、git status、recent commits
2. 检查工作区是否还有未提交业务代码
3. 用 task.py archive <name> 归档当前 active task
4. 用 add_session.py 追加 session journal
5. 产生 bookkeeping commit，例如 chore(task): archive ... 和 chore: record journal

所以正确顺序应该是：

1
2
3

# AI 实现 + check 完成，你确认 diff
git add ...
git commit -m "feat(auth): add user login"

1

/trellis:finish-work

不要把它当成"自动帮我 commit 功能代码"的命令。它更像任务结案 / 记账 / 归档。

9. 一点局限

目前 Trellis 也不是完美的：

• Windows 原生支持还在 beta：最好在 WSL2 里跑
• 小众 CLI 支持有限：如果你用 Aider 之外的工具，可能需要自己写适配
• 初始配置比 Superpowers 麻烦：Superpowers 是 Claude Code 的 Skill，装完即用；Trellis 需要先搭协调层
• 团队协作依赖网络同步：多人共享上下文需要网络通畅，断网时只能离线单机用
• 斜杠命令精简后，部分老用户需要适应：以前的习惯命令已经迁移到 skill 或移除，需要重新熟悉 auto-trigger 的节奏

10. 总结

如果你跟我一样，手边有好几个 AI CLI 在换着用，那 Trellis 值得一试。它解决了一个很实际的问题：不让每个 CLI 变成信息孤岛。

Superpowers 适合只想深耕 Claude Code 生态的个人用户；Trellis 则更适合想把不同 CLI 拼成流水线的人，尤其是需要团队协作的场景。

3 个斜杠命令的设计也很省心：/trellis:start 开局、/trellis:continue 推进、/trellis:finish-work 收尾。大部分时候你只需要一个 continue 就能跑完整个任务流程。

我现在的默认工作流已经变成：

Codex 规划 → Claude Code 实现 → OpenCode 收尾

这条链跑顺之后，开发效率和成本都舒服了很多。加上团队协作能力，连前后端的上下文同步也省心了。