# Trellis 真的值得用吗？一份客观评估

> 从工具对比、理论验证、实际摩擦和适用边界四个维度，给出不吹不黑的分析

---

## 先说结论

Trellis 是一个**设计理念领先、工程实现精巧的 harness 工具**，但它不是银弹。它真正解决了一些痛点，也引入了一些新的摩擦。是否值得用，取决于你的**项目复杂度**和**对流程开销的容忍度**。

---

## 一、竞品全景：Trellis 在什么位置？

### 当前 AI 编码质量控制工具的谱系

```
纯建议型 ←————————————————————————————→ 强制执行型

.cursorrules  AGENTS.md  CLAUDE.md  Aider+lint  Hooks  Cline/HIL  Trellis  Kiro
(文本建议)    (文本建议)  (文本+Hook) (反馈循环)  (硬门禁) (人工门禁) (状态机)  (spec管道)
```

### 核心对比矩阵

| 维度 | Cursor Rules | AGENTS.md | CLAUDE.md 原生 | Aider | Kiro | Tessl | Trellis |
|------|-------------|-----------|---------------|-------|------|-------|---------|
| **能否物理阻止坏代码** | ❌ | ❌ | ✅ (Hook) | 部分 (lint) | 部分 (spec) | ❌ | ✅ (workflow gate) |
| **上手时间** | 5 分钟 | 10 分钟 | 10min-数小时 | 5 分钟 | 30 分钟 | 15min/skill | 1-2 小时 |
| **每个任务的额外开销** | 无 | 无 | 无 | 无 | 中等 | 无 | **中等** |
| **跨会话连续性** | ❌ | ❌ | auto-memory | Git | Spec 文件 | 版本化 | **session pointer** |
| **动态 Context 选择** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | **✅ (JSONL)** |
| **学习闭环** | ❌ | ❌ | auto-memory | ❌ | ❌ | eval regression | **✅ (update-spec)** |
| **模型锁定** | Cursor 模型 | OpenAI | Claude | 任意 | AWS 模型 | 任意 | 主要 Claude |
| **团队适用性** | Git 共享 | Git 共享 | Git + org 级 | Git | 共享 spec | 注册中心 | spec + workspace |

---

## 二、Trellis 真正解决了什么问题

### 问题 1：AI 写代码时"不看规范"

**现象**：你在 CLAUDE.md 里写了 120 行规范，AI 还是按自己的习惯写代码。

**根因**：
- CLAUDE.md 是**全量加载**的——120 行规范里，只有 10 行跟当前任务有关
- 教程 insight #2 说的："每个 token 有 n² 的注意力计算成本"
- 不相关的 context 不仅浪费 token，还**稀释了相关信息的权重**

**Trellis 的解法**：JSONL curation——每个任务精选 2-5 个 spec 文件注入。

**这比竞品好吗？**
- 比 .cursorrules / AGENTS.md / 普通 CLAUDE.md 好很多——它们都是全量加载
- 比 Claude Code 的 `.claude/rules/` path-scoped rules 稍好——path-scoped rules 按文件路径过滤，JSONL 按**任务语义**过滤
- **Tessl 的 eval 驱动方式从另一个维度解决这个问题**——不选择"注入什么"，而是度量"注入了这些之后效果有没有变好"。Trellis 缺少这种度量。

**评分：⭐⭐⭐⭐ (4/5)** — 真正有效的创新，但缺少效果度量。

---

### 问题 2：AI 跳过规划直接写代码

**现象**：你说"加个登录功能"，AI 立刻开始写 `login.py`，没有问需求细节。

**Trellis 的解法**：工作流状态机强制 planning → in_progress，breadcrumb 在 planning 阶段只注入"去做 brainstorm"的指令。

**这比竞品好吗？**
- 比所有纯建议型工具好——.cursorrules 说"先做计划"，AI 可以无视
- 跟 **Kiro** 理念相同——Kiro 也强制 Prompt → Requirements → Design → Tasks 管道
- 但 Kiro 的批评也适用于 Trellis：**教程 insight #4 引用的 Böckeler 评论**——"简单的 bug 修复被迫走完整的 spec 流程，造成不必要的开销"

**评分：⭐⭐⭐⭐ (4/5)** — 对复杂任务有价值，但对简单任务是负担。虽然有 inline escape hatch ("直接改")，但需要用户主动判断。

---

### 问题 3："自己验自己"不可靠

**现象**：AI 写完代码说"验证通过"，但实际有 bug。

**Trellis 的解法**：implement 和 check 是独立的 sub-agent，各自带不同的 spec context。Check agent 不知道 implement agent 的"思路"，只看代码和质量规范。

**这比竞品好吗？**
- 比单 agent 工具都好——Cursor / Codex / Aider 都是同一个 agent 写+验
- 比 Cline 的人工审批互补——Cline 依赖人眼，Trellis 的 check agent 看规范
- 但 check agent 本质上还是 AI——**它不等于 CI/CD**。如果 spec 本身有盲区，check agent 也发现不了

**评分：⭐⭐⭐⭐ (4/5)** — 比单 agent 显著更好，但不能替代真正的测试套件。

---

### 问题 4：跨会话丢失上下文

**现象**：昨天做到一半，今天打开 IDE，AI 不知道继续做什么。

**Trellis 的解法**：session pointer 自动绑定到 task，下次打开时 hook 自动恢复。

**这比竞品好吗？**
- 比 .cursorrules / AGENTS.md / Aider 好很多——它们没有任何跨会话机制
- 比 Claude Code 原生的 auto-memory 更**结构化**——auto-memory 是模糊的"记住了什么"，session pointer 是精确的"你在做任务 X 的第 Y 阶段"
- **但 auto-memory 零配置**，session pointer 需要整个 Trellis 基础设施

**评分：⭐⭐⭐⭐⭐ (5/5)** — 这是 Trellis 的杀手级功能，竞品没有等效实现。

---

### 问题 5：经验教训不积累

**现象**：这次踩的坑，下次还会踩。

**Trellis 的解法**：`trellis-update-spec` 在每次任务完成后强制审视"学到了什么"，回写到 spec。

**这比竞品好吗？**
- 比几乎所有竞品好——它们都没有显式的学习闭环
- Claude Code 的 auto-memory 做了**类似但更弱**的事——自动记住偏好，但不写入结构化 spec
- Tessl 的 eval regression 从**另一个角度**做学习——度量是否退步，而非记录知识

**评分：⭐⭐⭐⭐ (4/5)** — 理念优秀，但实际效果取决于 spec 写得好不好。

---

## 三、Trellis 引入了什么新问题

### 问题 A：高启动摩擦

**Kiro 的教训**（教程 insight #4 引用）：
> "Spec-kit 生成大量重复的 markdown 文件，导致审查规范比审查代码更费力——这与 SDD 的初衷背道而驰。"

Trellis 有同样的风险：
- `trellis init` → 填充 spec（几十个 markdown 文件）
- 每个任务 → prd.md + implement.jsonl + check.jsonl + task.json
- 如果 spec 没填好 → sub-agent 写出"合格但没特色"的代码
- **spec 的质量决定了 Trellis 的价值上限**

**对比**：CLAUDE.md 写 60 行就能用。Aider 零配置。Cursor rules 放个文件就行。

### 问题 B：每个任务都有流程税

即使是中等复杂度的功能，Trellis 的完整流程也是：

```
create → brainstorm (3-8 问答) → JSONL curation → start → 
implement sub-agent → check sub-agent → update-spec → commit → finish-work
```

**保守估计每个任务增加 10-15 分钟的流程开销**（brainstorm + spec curation + commit ceremony）。

如果你一天做 5 个小任务，流程税 = 50-75 分钟。如果一天做 1 个大任务，流程税可以忽略不计。

**教程里的警告**（insight #4, Böckeler）：
> "SDD 工作流必须能适应不同规模的任务。不是所有任务都值得完整的 spec 流程。"

Trellis 的 escape hatch（"直接改"/"跳过 trellis"）缓解了这个问题，但**需要用户每次自行判断**。

### 问题 C：黑盒感

Trellis 在幕后做了很多事：
- Hook 注入 breadcrumb（你看不到注入了什么）
- Sub-agent 带着 spec 运行（你看不到它读了哪些 spec）
- Session pointer 自动恢复（你不知道它是怎么找到的）

这带来了**调试困难**：当结果不符合预期时，你不知道是 spec 的问题、JSONL curation 的问题、breadcrumb 的问题还是 sub-agent 的问题。

**对比**：CLAUDE.md 是透明的——你写什么 AI 就读什么。Aider 是透明的——你看到 lint 输出和 AI 的修复。Cline 是透明的——每一步都需要你批准。

### 问题 D：Claude 生态锁定

Trellis 声称支持 11+ 平台，但实际上：
- **Class-1 平台**（Claude Code, Cursor）：完整功能，hook 自动注入
- **Class-2 平台**（Codex, Copilot）：需要在 dispatch prompt 里手动写 task path
- **Class-3 平台**（Windsurf, Kilo）：不能用 sub-agent，只能 skill

**你的主力工具如果不是 Claude Code，体验会打折扣。**

---

## 四、跟"不用任何工具"对比

这是最重要的对比——**Claude Code 原生能力已经很强了**：

| 能力 | Claude Code 原生 | 加了 Trellis |
|------|-----------------|-------------|
| 规范注入 | CLAUDE.md + `.claude/rules/` (静态全量 / 路径过滤) | JSONL 动态精选 |
| 工作流控制 | 无（自由模式） | 状态机强制阶段 |
| Sub-agent | ✅ (Agent tool, 自由调度) | ✅ (结构化调度 + spec 注入) |
| 质量检查 | Hook (pre-commit 等) | trellis-check sub-agent + Hook |
| 跨会话 | auto-memory (模糊) | session pointer (精确) |
| 学习 | auto-memory | update-spec (结构化) |
| 任务管理 | TodoWrite (轻量) | task.py (重量) |
| 上手成本 | 写 CLAUDE.md 即可 | init + 填 spec + 学工作流 |

**核心问题：你从 CLAUDE.md + hooks 升级到 Trellis，获得的增量收益是否值得增量成本？**

---

## 五、教程理论怎么说

把教程 36 篇文章的核心洞见拿来检验 Trellis：

### 支持 Trellis 的论据

| 教程论点 | Trellis 的实现 |
|---------|---------------|
| "Harness > Model"（52.8→66.5%，LangChain 数据）| Trellis 是一个完整的 Harness |
| "Context 是稀缺资源"（n² 成本）| JSONL curation 精选 context |
| "约束即自由"（更多约束 → 更可靠的自主）| 状态机限定每步可做的事 |
| "对话会被压缩，文件不会"| task dir + spec + journal 全持久化 |
| "分离 implement 和 check 提升质量"| 两个独立 sub-agent |

### 质疑 Trellis 的论据

| 教程论点 | 对 Trellis 的质疑 |
|---------|-------------------|
| "从简单开始"（Anthropic 核心哲学）| Trellis 从第一天就是完整系统，没有渐进模式 |
| "SDD 可能放大而非解决问题"（Böckeler）| spec 维护成本 + 流程税 + 审查规范比审查代码更费力 |
| "CLAUDE.md 应控制在 60 行以内"（HumanLayer）| Trellis 的 workflow.md 有 660 行 |
| "LLM 生成的配置反而损害性能"（ETH 研究）| AI 做 JSONL curation 的质量可能不如人工 |
| "不是所有任务都值得完整 spec 流程"| 虽有 escape hatch 但需用户判断 |
| "最成功的实现用简单可组合模式，而非复杂 framework"（Anthropic）| Trellis 是一个相对复杂的 framework |

**教程本身是矛盾的**——它既论证了 harness 的价值，又警告不要过度工程化。Trellis 精准地踩在这条线上。

---

## 六、什么时候 Trellis 物超所值

### ✅ 推荐使用的场景

| 场景 | 为什么 Trellis 好 |
|------|------------------|
| **多天/多周的功能开发** | 跨会话恢复 + PRD 持久化值回流程税 |
| **有明确编码规范的团队项目** | spec 填得好 → sub-agent 产出质量高 |
| **需要独立审查的重要代码** | implement/check 分离比自审可靠 |
| **新人 onboarding 项目** | spec + workflow 降低"不知道该怎么写"的风险 |
| **反复出现同类 bug** | break-loop + update-spec 形成防线 |

### ❌ 不推荐使用的场景

| 场景 | 为什么 Trellis 不好 |
|------|---------------------|
| **日常小修小补** | 流程税远超收益 |
| **原型探索 / hackathon** | 速度优先，规范其次 |
| **规范还没建立的早期项目** | 空 spec → Trellis 变成空壳 |
| **主力工具不是 Claude Code** | Class-2/3 体验打折 |
| **独立开发者的小工具** | CLAUDE.md + hooks 足够 |

---

## 七、务实的采用策略

如果你决定试用 Trellis，建议**不要一步到位**：

### 阶段 1：只用 Spec 系统（最小化投入）

- 认真填充 `.trellis/spec/`（这是 Trellis 价值的根基）
- 用 `trellis-before-dev` skill 在编码前注入 spec
- 不走完整流程，不用 sub-agent
- **这一步就能获得 50% 的收益**

### 阶段 2：加入 Sub-agent 分离

- 用 `trellis-implement` 和 `trellis-check` 做 implement/check 分离
- 体会独立审查的效果
- 但还不走任务管理流程

### 阶段 3：启用完整工作流（仅对大功能）

- 对需要 >2 小时的功能启用完整 planning → implement → check → commit 流程
- 对 <30 分钟的任务继续用 inline 模式
- 评估流程税是否可接受

### 阶段 4：加入学习闭环

- 启用 `trellis-update-spec`
- 启用 `trellis-break-loop`
- 观察 spec 是否随时间真正改善了代码质量

---

## 八、最终评分

| 维度 | 评分 | 说明 |
|------|------|------|
| **设计理念** | ⭐⭐⭐⭐⭐ | 教科书级的 harness engineering 实践 |
| **实现质量** | ⭐⭐⭐⭐ | Python 脚本精巧，workflow.md 契约清晰 |
| **实际收益** | ⭐⭐⭐⭐ | 对复杂项目有显著价值 |
| **学习曲线** | ⭐⭐ | 概念多，需要理解状态机、JSONL、sub-agent |
| **日常摩擦** | ⭐⭐⭐ | 大任务可接受，小任务偏重 |
| **生态兼容** | ⭐⭐⭐ | 主要适配 Claude Code，其他平台打折 |
| **vs 原生能力增量** | ⭐⭐⭐ | CLAUDE.md + hooks 已能覆盖 60-70% 的需求 |

### 综合评价

> **Trellis 是目前市面上设计最完整的 harness 工具——它把教程里的理论原则一一落地为可执行的工程系统。但"最完整"不等于"最适合"。对于复杂的长周期项目，它的 session 恢复、spec 注入和独立审查是真正的差异化优势。对于日常开发，Claude Code 原生的 CLAUDE.md + hooks + sub-agents 组合已经足够强，Trellis 的流程开销可能得不偿失。**

**最务实的用法：把 Trellis 当 spec 管理系统用（阶段 1），而非全流程工作流引擎。spec 是它最稳定的价值，workflow 是它最可选的部分。**