Trellis基础教程

Trellis基础教程
空空Trellis 使用文档
让 AI 编码在团队规模上变得可靠 —— 跨 14+ AI 编码平台的团队级 AI 编码工作流框架
官方地址
GitHub - mindfold-ai/Trellis: The best agent harness.
目录
- 1. 概述
- 2. 核心概念
- 3. 安装与初始化
- 4. 目录结构
- 5. 工作流详解
- 6. 命令与技能参考
- 7. 任务管理
- 8. 编写 Spec
- 9. 平台支持
- 10. 多开发者协作
- 11. 版本管理
- 12. 真实场景
- 13. 配置参考
- 14. 常见问题
1. 概述
Trellis 是一个团队级 AI 编码工作流框架,核心解决的问题是:让 AI 编码在不同会话、不同工具、不同开发者之间保持一致和可靠。
| 核心能力 | 说明 |
|---|---|
| 自动注入 Spec | 在 .trellis/spec/ 写一次约定,Trellis 自动将相关上下文注入每次会话 |
| 任务驱动工作流 | PRD、实现上下文、审查上下文和任务状态保存在 .trellis/tasks/ |
| 项目记忆 | .trellis/workspace/ 中的日志保留上次会话内容,新会话不再从零开始 |
| 团队共享标准 | Spec 文件随仓库版本控制,一人总结的规则全团队受益 |
| 多平台统一 | 同一套 .trellis/ 核心适用于 14+ AI 编码工具 |
2. 核心概念
| 概念 | 路径 | 作用 |
|---|---|---|
| Spec(规格) | .trellis/spec/ |
项目编码约定、设计决策、模式规范,团队共享、PR 审查 |
| Task(任务) | .trellis/tasks/ |
单个开发任务的 PRD、研究、上下文清单、元数据 |
| Workspace(工作区) | .trellis/workspace/<name>/ |
开发者个人日志和跨会话笔记 |
| Workflow(工作流) | .trellis/workflow.md |
定义开发流程的阶段、路由规则、提交计划 |
| JSONL 上下文 | implement.jsonl / check.jsonl / research.jsonl |
为子代理指定该任务需要读取的 spec 和研究文件 |
| 子代理 | 平台 agents 目录 | 独立的 AI 子进程,接收 JSONL 上下文,执行实现、检查或研究 |
| 技能 | 平台 skills 目录 | 自动触发的 AI 行为模式(brainstorm、check、update-spec 等) |
3. 安装与初始化
3.1 全局安装
1 | # 需要 Node.js >= 18 和 Python >= 3.9 |
支持 macOS、Linux 和 Windows。
3.2 项目初始化
1 | cd your-project |
支持的平台标志:--claude、--cursor、--opencode、--codex、--kiro、--gemini、--qoder、--codebuddy、--copilot、--droid、--pi、--antigravity、--windsurf、--kilo。
your-name 成为你的开发者身份,并在 .trellis/workspace/your-name/ 下创建个人工作区。
3.3 初始化场景
| 场景 | 命令 | 结果 |
|---|---|---|
| 首次项目初始化 | trellis init -u your-name --claude |
创建 .trellis/ + 引导任务 00-bootstrap-guidelines |
| 添加新平台 | trellis init --cursor |
在已有 .trellis/ 上写入新平台配置,不生成任务 |
| 新开发者加入 | trellis init -u their-name |
生成入职引导任务 00-join-<slug> |
| 同一开发者新机器 | 同上 | 也生成入职任务(因为 .developer 不提交到 Git) |
| 重复运行 init | trellis init -u your-name |
交互式询问添加开发者还是完全重初始化 |
.trellis/.developer是一个 gitignored 的每台机器身份文件,绝不会提交到仓库。
init_developer.py 的逻辑是:先检查 .developer 是否存在,存在就直接退出,不干活。只有删了它,脚本才会创建新开发者的 workspace 目录。所以如果你想要在本机切换开发者需要先删除.develpoer再
trellis init -u their-name也可以直接直接改developer文件里的 name,但 workspace 目录不会自动创建——要么提前已有,要么首次工作时用 trellis init -u 初始化一次。
3.4 远程 Spec 模板
不从头写 spec,可以从远程拉取预构建模板:
1 | # 交互式选择模板 |
已有 spec 时的冲突策略:
| 标志 | 行为 |
|---|---|
--overwrite |
删除已有 spec 目录,重新下载 |
--append |
只复制不存在的文件 |
| (无标志) | 交互式提示 |
私有仓库需设置环境变量:
1 | GIGET_AUTH=ghp_xxxxx trellis init --registry gh:myorg/private-repo/specs |
4. 目录结构
1 | your-project/ |
5. 工作流详解
5.1 三阶段循环
Trellis 运行一个 3 阶段循环,由自动触发的技能和子代理驱动:
1 | ┌──────────────────────────────────────────────────────────────────────┐ |
5.2 会话启动
当 AI 会话开始时,Trellis 通过 SessionStart 钩子/插件自动加载上下文:
| 上下文 | 来源 |
|---|---|
| 开发者身份 | .trellis/.developer |
| Git 状态 | 当前分支、脏文件、近期提交 |
| 活动任务指针 | .trellis/.runtime/sessions/<session-key>.json |
| 活动任务列表 | .trellis/tasks/*/task.json |
| 工作流摘要 | .trellis/workflow.md |
| Spec 索引 | .trellis/spec/**/index.md |
| 工作区记忆 | .trellis/workspace/<developer>/index.md + 近期日志 |
对于有钩子/扩展能力的平台(Claude Code、Cursor、OpenCode 等),这一切是自动的。对于没有自动注入的平台(Kilo、Antigravity、Windsurf),需手动运行 /trellis:start。
5.3 每轮提示的工作流状态注入
在有钩子的平台上,每次用户消息都会触发轻量级的工作流状态注入:
- 解析当前会话的活动任务
- 读取
task.json.status - 从
workflow.md中匹配对应的状态块[workflow-state:STATUS] - 将状态指引包裹在
<workflow-state>标签中注入当前对话轮
5.4 任务路由
主会话根据你的输入和当前工作流状态选择三条路径之一:
| 路径 | 适用场景 | 行为 |
|---|---|---|
| 直接回答 | 简单问答、查找、聊天 | AI 回答后停止 |
| Trellis 任务 | 实现、重构、构建等代码变更 | 创建或继续任务 |
| 内联逃逸 | 你明确要求跳过 Trellis | 仅本次轮次内联处理 |
6. 命令与技能参考
6.1 命令
| 命令 | 触发方式 | 用途 |
|---|---|---|
/trellis:start |
手动(无 SessionStart 钩子的平台) | 开启会话,加载上下文,分类工作 |
/trellis:finish-work |
手动(Phase 3.4 提交之后) | 归档任务 + 记录会话日志 |
/trellis:continue |
手动 | 推进当前任务到下一步 |
在有 SessionStart 钩子的平台上,不需要手动运行
/trellis:start。
6.2 自动触发技能
| 技能 | 触发时机 | 用途 |
|---|---|---|
trellis-brainstorm |
用户描述功能/Bug/模糊需求时 | 将需求转化为任务 + prd.md |
trellis-before-dev |
开始写代码前 | 读取相关 spec,确保 AI 了解约定 |
trellis-check |
实现完成后 | 验证 + 自修复循环 |
trellis-update-spec |
发现值得记录的经验时 | 将知识写入 .trellis/spec/ |
trellis-break-loop |
解决棘手 Bug 后 | 根因分析 + 预防机制 |
6.3 子代理
| 子代理 | 限制 | 何时生成 |
|---|---|---|
trellis-research |
只读 | 需要代码库搜索/模式发现/文档查找时 |
trellis-implement |
写代码但不提交 | 需求和计划就绪后 |
trellis-check |
写代码(修复) | 验证阶段,内部运行自修复循环 |
7. 任务管理
7.1 任务生命周期
1 | create → curate jsonl → start → implement/check → finish → archive |
7.2 task.py 子命令
创建任务
1 | TASK_DIR=$(./.trellis/scripts/task.py create "添加用户登录" \ |
上下文配置
1 | # 添加 spec 文件到实现上下文 |
任务控制
1 | # 设为当前会话的活动任务 |
任务列表与归档
1 | # 列出活跃任务 |
7.3 task.json 结构
1 | { |
状态转换:
1 | task.py create → status: "planning" |
7.4 JSONL 上下文配置
task.py create 在有子代理能力的平台上会自动在 implement.jsonl 和 check.jsonl 中写入一条示例行:
1 | {"_example": "Fill with {\"file\": \"<path>\", \"reason\": \"<why>\"}. ..."} |
AI 在 Phase 1.3 阶段会将其替换为真实的 spec 和研究文件引用:
1 | {"file": ".trellis/spec/guides/index.md", "reason": "共享跨包思维指南"} |
应该放入 jsonl 的:
- Spec 文件(
.trellis/spec/<pkg>/<layer>/index.md+ 具体指南文件) - 研究文件(
{TASK_DIR}/research/*.md)
不应放入 jsonl 的:
- 代码文件(子代理在实现阶段自己读取)
- 即将修改的文件(同理)
7.5 父子任务
1 | # 方式 A:创建时直接指定父任务 |
注意:
task.json中的subtasks字段是任务内部的待办清单,与父子任务无关。父子关系通过parent和children字段管理。
7.6 任务生命周期钩子
在 .trellis/config.yaml 中配置:
1 | hooks: |
| 事件 | 触发时机 | 用途 |
|---|---|---|
after_create |
task.py create 完成后 |
在项目追踪器中创建关联 issue |
after_start |
task.py start 设置活动任务后 |
更新 issue 状态为 “进行中” |
after_finish |
task.py finish 清除活动任务后 |
通知团队、触发审查 |
after_archive |
task.py archive 归档任务后 |
标记 issue 为 “完成” |
每个钩子接收环境变量 TASK_JSON_PATH(指向 task.json 的绝对路径)。
Trellis 内置了 Linear 同步钩子示例(.trellis/scripts/hooks/linear_sync.py),支持创建、更新状态和同步 PRD 内容。
8. 编写 Spec
8.1 Spec 目录结构
trellis init 生成的默认结构:
1 | .trellis/spec/ |
frontend/和backend/不是固定的。Trellis 通过扫描.trellis/spec/下一层包含index.md的目录来发现 spec 层。你可以按包、按运行时、按职责命名。
8.2 从空模板到完整 Spec
trellis init 生成的模板标记为 “(To be filled by the team)”,是空的。填充步骤:
步骤 1:从实际代码中提取模式
1 | ls src/components/ # 组件结构 |
步骤 2:写下你的约定
1 | # 组件指南 |
步骤 3:添加代码示例
1 | #### 正确示例 |
步骤 4:更新 index.md 状态
1 | | 规范 | 文件 | 状态 | |
也可使用内置的
trellis-spec-bootstrap技能,让 AI 从实际代码库中草拟初版 spec。
8.3 Spec 编写原则
Spec 分为两类:
| 类型 | 位置 | 目的 | 内容风格 |
|---|---|---|---|
| 代码规格 | <layer>/*.md(如 backend/) |
“如何安全实现” | 签名、契约、验证矩阵、正确/基础/错误示例、必要测试 |
| 思维指南 | guides/*.md |
“写代码前要想什么” | 检查清单、问题、指向 spec 的指针 |
好的 Spec 条目——具体、可执行、有代码示例、有原因说明:
1 | #### 约定:使用 ORM 批量方法,禁止循环单行 DB 调用 |
差的 Spec 条目——没有签名、没有示例、没有原因:
1 | #### 数据库 |
8.4 Spec 更新模板
trellis-update-spec 提供多种模板,根据你学到的内容选择:
| 你学到了…… | 模板 | 关键字段 |
|---|---|---|
| 为什么选择方案 X 而非 Y | 设计决策 | 上下文、考虑的选项、决策、示例、扩展性 |
| 项目用方式 X 做某事 | 约定 | 是什么、为什么、示例、相关 |
| 某个反复出现的问题的可复用解决方案 | 模式 | 问题、解决方案、示例(好+坏)、原因 |
| 导致问题的做法 | 禁止模式 | 问题代码片段、为什么不好、替代代码片段 |
| 容易犯的错误 | 常见错误 | 症状、原因、修复、预防 |
| 非显而易见的行为 | 陷阱 | > Warning: 引用块,说明何时/如何 |
涉及基础设施/跨层工作时,需要完整的 7 节格式:
- 范围/触发 — 为什么需要代码规格深度
- 签名 — 命令/API/DB 签名
- 契约 — 请求字段、响应字段、环境变量(名称、类型、约束)
- 验证与错误矩阵 —
<条件> → <错误>表格 - 正确/基础/错误案例 — 示例输入及预期输出
- 必要测试 — 单元/集成/E2E 及断言点
- 错误 vs 正确 — 至少一个显式对比
9. 平台支持
9.1 能力矩阵
| 能力 | Claude Code | Cursor | OpenCode | Codex | Kiro | Gemini | Qoder | CodeBuddy | Copilot | Droid | Pi Agent |
|---|---|---|---|---|---|---|---|---|---|---|---|
| SessionStart 自动注入 | ✅ | ✅ | ✅ | ⚡ | ⚡ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 子代理上下文注入 | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ✅ | ✅ |
子代理 (trellis-*) |
✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 自动触发技能 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
显式 /trellis:* 命令 |
✅ | ✅ | ✅ | — | — | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
✅ = Trellis 配置且平台执行 · ⚡ = 部分支持 · ❌ = 平台不提供此事件 · — = 平台无命令原语
9.2 各平台配置详情
OpenCode
1 | trellis init -u your-name --opencode |
OpenCode 1.2.x 是完整的一类平台(钩子 + 子代理):
.opencode/commands/trellis/:start / finish-work / continue.opencode/agents/:trellis-implement.md、trellis-check.md、trellis-research.md.opencode/skills/:5 个 trellis 技能.opencode/plugins/:JS 插件(session-start.js、inject-subagent-context.js、inject-workflow-state.js)
Claude Code
最完整的自动化支持。钩子:
| 钩子 | 触发时机 | 效果 |
|---|---|---|
session-start.py |
SessionStart | 注入身份、git 状态、活动任务 |
inject-workflow-state.py |
UserPromptSubmit | 将 AI 引导向当前任务状态 |
inject-subagent-context.py |
PreToolUse (Task) | 加载 implement.jsonl/check.jsonl/research.jsonl |
Codex
需在 ~/.codex/config.toml 中启用钩子:
1 | [features] |
Codex 0.129+ 还需要在 Codex 内运行 /hooks 一次性审批钩子。
Kiro
Trellis 内容通过 .kiro/ 技能和代理文件交付。Kiro 的 Agent Hooks 是用户配置的(在文件保存、构建成功等事件触发),Trellis 不默认安装任何 Kiro Agent Hook。
Gemini CLI
.gemini/commands/trellis/{name}.toml:TOML 命令文件.gemini/skills/trellis-{name}/SKILL.md:5 个技能.gemini/agents/{name}.md:子代理定义(拉取式 prelude).gemini/hooks/session-start.py:SessionStart 钩子
无子代理平台(Kilo、Antigravity、Windsurf)
这三个平台只有工作流 + 技能,没有钩子和子代理。入口:
- Kilo:
/start.md - Antigravity: 打开
.agent/workflows/start.md - Windsurf:
/trellis-start
10. 多开发者协作
每人隔离(无冲突):
| 项 | 路径 | 说明 |
|---|---|---|
| 个人工作区 | .trellis/workspace/{name}/ |
每个开发者自己的日志和索引 |
| 开发者身份 | .trellis/.developer |
gitignored,每台机器独立 |
| 会话运行时 | .trellis/.runtime/ |
gitignored,每个 AI 会话/窗口有自己的活动任务文件 |
共享状态(通过 PR 协调):
| 项 | 路径 | 说明 |
|---|---|---|
| Spec | .trellis/spec/ |
团队约定,像代码一样 PR 审查 |
| 任务 | .trellis/tasks/ |
任务 JSON;使用 --assignee 避免冲突 |
新开发者加入已有项目时:
1 | trellis init -u their-name |
这会创建 .trellis/.developer 和 .trellis/workspace/their-name/,并生成入职引导任务。
11. 版本管理
1 | # 查看当前版本 |
模板哈希机制(.trellis/.template-hashes.json):
- 计算本地文件哈希
- 与记录的模板哈希比较
- 匹配 → 文件未被用户修改 → 安全更新
- 不匹配 → 提示用户(覆盖/跳过),或使用
-f/-s策略
破坏性变更会附带迁移清单:不带 --migrate 的 trellis update 会退出并给出说明,而非静默重命名文件。
12. 真实场景
12.1 从零开始新项目
起始提示:
1 | 我正在从零开始构建一个 B2B 仪表板。帮我设置 Trellis 用于第一周的工作。 |
工作流:
- 运行
trellis init→ 生成约 17 个默认 spec 模板 + 引导任务00-bootstrap-guidelines - 在引导任务中,与 AI 讨论产品需求和技术栈
- 创建最小的端到端任务(
task.py create),AI 进入 Phase 1 规划:trellis-brainstorm逐个问题澄清需求,迭代prd.md- 复杂任务还需写
design.md(技术设计)和implement.md(执行计划) - 策划
implement.jsonl/check.jsonl(子代理上下文清单) - 你确认规划后,
task.py start激活任务(planning→in_progress)
- AI 进入 Phase 2 执行:
trellis-implement按prd.md写代码trellis-check审查 diff + 跑 lint/测试,自修复- 可反复
/trellis:continue驱动循环(不说也行,AI 会根据task.json.status自动判断下一步)
- AI 进入 Phase 3 收尾:
trellis-update-spec将踩坑经验写回.trellis/spec/- 主会话驱动 git commit
- 执行
task.py finish→task.py archive归档任务 - 输入
/trellis:finish-work将会话摘要写入 journal
注意:新项目代码还少时无需手动填充 spec 模板,也无需使用
trellis-spec-bootstrap。等积累几轮开发、代码有了一定规模后,再用trellis-spec-bootstrap一次性从代码库分析提取 spec 更高效。
12.2 接手现有项目
起始提示:
1 | 这是一个已有仓库。先不要重构代码。 |
关键原则:
- 不要将理想标准写成已实现的代码
- 不要填充每个模板——错误的规则比空白占位符更有害
- 让 AI 为每条约定引用文件路径
12.3 交付产品功能
起始提示:
1 | 创建团队邀请功能的 Trellis 任务。 |
任务拆分(在同一 Trellis 任务下):
| 子任务 | 范围 |
|---|---|
| 产品与契约 | 邀请生命周期、角色规则、过期行为、范围外选择 |
| 数据模型 | invitations 表、token 哈希、过期、唯一性、审计字段 |
| API 和服务行为 | 创建/重新发送/撤销/接受邀请、管理员检查、幂等性 |
| 邮件副作用 | 邀请邮件模板、重新发送行为、测试邮件/模拟提供商 |
| UI 状态 | 邀请表单、待处理列表、撤销/重新发送操作、接受屏幕 |
| 跨层检查 | 从创建邀请到接受会员的端到端路径 |
12.4 重构遗留模块
起始提示:
1 | 为 src/billing/invoice-service.ts 创建一个行为保持不变的重构任务。 |
在 PRD 中明确写出行为不变量:
1 | ## 必须不变的行为 |
12.5 修复反复出现的 Bug
起始提示:
1 | 修复 SessionStart 钩子在 `str | None` 上的崩溃。用户终端的 Python 是 3.11,但钩子子进程似乎使用了更旧的版本。 |
完成标准:
- 补丁修复了报告的行为
- 回归测试在没有补丁时失败
- 根因已记录
- 存在聊天记录之外的预防机制
12.6 减少重复审查反馈
起始提示:
1 | 审查最近几个 PR 的评论,帮我将重复的工程反馈转化为 Trellis spec。 |
示例转换:
| 重复的审查评论 | 更好的 spec 规则 |
|---|---|
| “这里需要加载状态” | “每个异步提交按钮都有 idle、loading、success 和 error 状态” |
“这里不要用 any“ |
“公共组件 Props 不允许使用 any;使用显式接口或泛型” |
| “API 错误格式不一致” | “所有路由处理器通过 toApiError() 返回 ApiError“ |
12.7 团队推广
| 阶段 | 目标 | 退出标准 |
|---|---|---|
| 1 | 试点一个仓库 | 用 spec、检查和日志完成一个真实任务 |
| 2 | 捕获重复反馈 | 3-5 个审查模式成为 spec |
| 3 | 标准化任务工作流 | 开发者知道何时使用 /trellis:start、/trellis:continue、/trellis:finish-work |
| 4 | 添加平台适配 | 多个 AI 工具消费同一 .trellis/ 上下文 |
| 5 | 治理更新 | Spec 和工作流变更像代码一样审查 |
13. 配置参考
config.yaml
.trellis/config.yaml 是项目级配置文件:
1 | # 包配置(monorepo 中按包划分 spec) |
14. 常见问题
Trellis 和 CLAUDE.md、AGENTS.md、.cursorrules 有什么区别?
这些文件是有用的入口点,但往往会变成庞大的单一文件。Trellis 在它们周围添加了分层的 spec、任务 PRD、工作流关卡、工作区记忆和平台感知的生成文件。
Trellis 只适用于 Claude Code 吗?
不是。Trellis 是一个跨多个 AI 编码工具的项目层。同一套 .trellis/ 核心在 14+ 平台上通用。
Trellis 是给个人开发者还是团队的?
两者都适用。个人开发者用它来记忆和可重复的工作流。团队获得更大收益:共享标准、任务边界、可审查的上下文和平台可移植性。
必须手动写每个 spec 文件吗?
不必。很多团队让 AI 从现有代码草拟 spec,然后手工精修重要部分。Trellis 效果最好时,是你保持高信号规则明确且版本化。
团队使用会有冲突吗?
不会。个人工作区日志(workspace/<name>/)是每个开发者独立的。共享的 spec 和任务通过 PR 审查,和项目其他制品一样。
/trellis:finish-work 做什么?
- 检查工作区是否干净(无脏文件)
- 归档活动任务到
archive/YYYY-MM/ - 追加会话摘要到
workspace/<developer>/journal-N.md - 更新工作区索引
它 不是 提交代码的命令——代码提交在 Phase 3.4 由主会话驱动。
continue 命令做什么?
/trellis:continue 是任务内继续——不是跨任务的。AI 根据活动任务的 task.json.status 加上每轮注入的工作流状态面包屑,自动判断当前阶段并推进到下一步。
官方资源:
- 文档:https://docs.trytrellis.app/
- GitHub:https://github.com/mindfold-ai/Trellis
- Discord:https://discord.com/invite/tWcCZ3aRHc
- 许可证:AGPL-3.0


