解决 AI 编码两大痛点：失控与失忆，mattpocock/skills 和 Trellis 谁更对症

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 166 篇，AI 编程最佳实战「2026」系列第 52 篇

大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。

我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、AIOps、Milvus 向量数据库的技术实践者与开源布道者！

Talk is cheap, let's explore。无界探索，有术而行。

mattpocock/skills 与 Trellis 对比分析信息图封面

你在用 Claude Code 或 Cursor 写代码的时候，大概率碰过这两种情况。

第一种：AI 生成的代码越来越多，但质量越来越难控制。一个功能让它写，它洋洋洒洒给你造了一堆，但你不确定它是不是真的理解了需求。

改起来无从下手，删掉又舍不得。

第二种：每次开新会话，AI 就像失忆了一样。你上周跟它解释了半天的项目架构、命名规范、技术选型，今天它全都忘了。

CLAUDE.md、AGENTS.md、.cursorrules 写了几百行，但越长越没人看，最后变成一坨没人维护的巨型文件。

这两个痛点，正好对应了两个 GitHub 项目的切入点。

一个是 mattpocock/skills——TypeScript 圈子的大佬 Matt Pocock 做的 AI 编码 skill 集合，核心主张是 for real engineers — not vibe coding（给真正的工程师用，不是凭感觉编程）。

MIT 许可证，一行 npx 命令安装。

另一个是 Trellis——Mindfold 出品的 AI 编码框架，npm 包 @mindfoldhq/trellis（v0.6.6），核心主张是 An out-of-the-box engineering framework for AI coding。

AGPL-3.0 许可证，trellis init 一键初始化，适配 17 个 AI 编码平台。

我把两个项目的本地源码都拉下来读了一遍。说句实话，这两条路线解决的根本不是同一个层面的问题。

但它们恰好凑齐了 AI 编码工程化的两个方向。下面用代码说话。

1. 各自瞄准了什么问题

先看两个项目在 README 里怎么定义自己的对立面。这往往最能暴露一个项目的真实定位。

mattpocock/skills 的靶子是 GSD、BMAD、Spec-Kit 这类 AI 编码框架。Matt 的原话是：

They take away your control and make bugs in the process hard to resolve.

翻译过来：这些框架夺走了你的控制权，而且出了 bug 很难查。Matt 认为 AI 编码失败有四个模式：misalignment（目标不对齐）、verbosity（废话太多）、no feedback loops（没有反馈环）、ball of mud（代码变泥球）。

他的解法是给你一堆小而精的 skill，你自己来编排流程。这些 skill 的核心职责是：逼你想清楚再动手（grilling）、建立共享语言（domain modeling）、强制写测试（TDD）、做架构评审（code review）。

Trellis 的靶子更具体——就是 CLAUDE.md、AGENTS.md、.cursorrules 这些文件。Trellis 的 FAQ 里直说：

They tend to become monolithic.

翻译过来：这些文件容易变成巨型怪物。Trellis 认为 AI 编码的核心失败模式只有一个：every session starts from scratch（每个会话都从零开始）。

它的解法是把规范、任务、记忆全部持久化到仓库里（.trellis/ 目录），然后由框架驱动一个 4 阶段循环来编排整个开发流程。

你看，两者的对立面完全不同：

• mattpocock/skills 反对的是 框架替你做决定 → 它要还你控制权
• Trellis 反对的是 配置文件越长越没用 → 它要重新组织规范的生命周期

这两件事可以同时存在。一个人可能既嫌 BMAD 太死板，又嫌自己的 CLAUDE.md 长到没人读。这种情况下，两个项目的价值是能叠起来的。

2. 架构哲学：工具箱 vs 框架

这是两个项目最根本的差异。我用源码里的目录结构来对比。

mattpocock/skills 的整个仓库结构：

skills/
├── engineering/          # 核心工程 skill（promoted bucket）
│   ├── ask-matt          # 路由器：映射所有 skill 之间的关系
│   ├── grill-with-docs   # 对齐需求的 grilling
│   ├── to-spec           # 对话 → 规范文档
│   ├── to-tickets        # 规范 → 可执行 ticket
│   ├── implement         # 构建工作（内部驱动 /tdd）
│   ├── tdd               # red-green 循环
│   ├── code-review       # 双轴评审
│   └── ...               # 还有 10 来个 skill
├── productivity/         # 通用工作流 skill
│   ├── grilling          # 可复用的 grilling 原语
│   ├── handoff           # 跨会话上下文压缩
│   └── ...
└── personal/             # 个人配置

这是一堆独立的 markdown 文件。每个 skill 就是一个 SKILL.md，内容从 7 行到 76 行不等。没有运行时，没有 CLI 工具，没有钩子机制。

你装上之后，在 agent 里手动键入 /grill-with-docs 或 /implement 来触发。

Trellis 的项目目录结构（.trellis/ 是约定的工作目录）：

.trellis/
├── workflow.md           # 708 行的工作流定义（唯一真相源）
├── config.yaml           # 项目配置（packages、hooks、channel）
├── spec/                 # 分层规范文档（按 package × layer 组织）
│   ├── cli/backend/
│   ├── core/backend/
│   └── guides/           # 跨 package 思考指南
├── tasks/                # 活跃任务（每个任务一个目录）
│   └── MM-DD-name/
│       ├── task.json     # 状态机
│       ├── prd.md        # 需求文档
│       ├── design.md     # 技术设计
│       ├── implement.jsonl  # sub-agent 要读的 spec 清单
│       └── check.jsonl      # 检查 sub-agent 的 spec 清单
├── workspace/            # 每个开发者的会话日志
│   └── <developer>/
│       └── journal-N.md  # 会话记录（2000 行轮转）
├── agents/               # agent 定义
└── scripts/              # Python 脚本（task.py、get_context.py 等）

这不是文件集合，这是一个完整的项目管理系统。有状态机、有持久化、有脚本驱动、有 per-turn 钩子注入。

两种哲学的差异可以浓缩成一句话：

• mattpocock/skills：你是编排者，skill 是工具箱。路由器帮你找工具，但流程得你自己记住。
• Trellis：框架是编排者，你是决策者。框架告诉你当前在哪一步，你只需要回答问题。

哪个更好？取决于你的场景。

个人项目、快速原型，你想要的是灵活的 Toolkit。团队协作、长期维护的中大型项目，你需要的是能强制流程的 framework。

话说回来，这两种选择背后其实是一个 trade-off：灵活度 vs 一致性。Matt 选了前者，Trellis 选了后者。

工具箱与框架的架构哲学对比图

图 1：工具箱 vs 框架——mattpocock/skills 是散落的独立工具，Trellis 是咬合的四阶段流水线

3. 核心能力逐一对比

光看目录结构不够，得深入到具体的 skill 和机制。下面挑六个维度做源码级对比。

对齐需求：grilling vs brainstorm

两个项目都有一个逼你想清楚再动手的能力。mattpocock/skills 叫 grilling，Trellis 叫 trellis-brainstorm。

grilling 的核心契约定义在 skills/productivity/grilling/SKILL.md 里（12 行的极简 skill）：

Interview me relentlessly... Walk down each branch of the design tree. One question at a time.

关键设计：每次只问一个问题；区分 facts（查 codebase）vs decisions（问人）；不经确认不执行计划。

这个 skill 是可复用的原语——grill-me（无 codebase 场景）和 grill-with-docs（有 codebase 场景）都调用它。

Trellis 的 trellis-brainstorm skill 契约几乎一模一样——也是 relentless interview、one question at a time、区分 evidence 和 decisions。

差异在于耦合度。grilling 是完全独立的 skill，你可以在任何对话里直接触发。

brainstorm 是任务系统的入口——每次必须先 task.py create 建目录，写 prd.md，然后才开始提问。输出强制持久化到 prd.md。

换句话说，grilling 是一个可以单独用的瑞士军刀，brainstorm 是流水线上的第一个工位。

规范管理：CONTEXT.md vs 分层 spec

这是两个项目差距较大的地方。

mattpocock/skills 的规范管理很轻量。核心就一个 CONTEXT.md 文件，由 domain-modeling skill 在 grilling 过程中增量更新。

它本质是一个术语表（glossary），比如：

# CONTEXT.md 示例

- **Tracer Bullet**: 一种先打通端到端、再填充细节的实现策略
- **Deep Module**: 接口简单但实现复杂的模块设计
- **Vertical Slice**: 垂直切片，按功能而非技术层组织代码

另外还有 docs/adr/ 存架构决策记录（ADR）。但整体上没有分层规范体系——规范是局部的、术语层面的。

Trellis 的规范体系则重得多。.trellis/spec/ 按 package × layer 分层组织：

.trellis/spec/
├── cli/
│   ├── backend/          # CLI 后端层规范
│   └── unit-test/        # CLI 单元测试规范
├── core/
│   └── backend/          # 核心后端层规范
├── docs-site/
├── guides/               # 跨 package 思考指南
│   ├── code-reuse.md
│   ├── cross-layer.md
│   └── cross-platform.md
└── tech/                 # 技术选型规范

每个 index.md 都有 Pre-Development Checklist 和 Quality Check 两段。而且通过 implement.jsonl 和 check.jsonl 两个文件精确控制 sub-agent 读取哪些 spec。

不是一股脑全塞进去，而是按任务 curate（策划）相关的规范条目。

还有个 trellis-update-spec skill，在每个任务完成后强制回顾：有没有新学到的知识需要补进 spec？

spec 指导开发，开发再把新知识回写进去——一来一回，规范会越滚越准。

任务管理：外挂 tracker vs 内置状态机

mattpocock/skills 不维护自己的任务系统。to-tickets skill 会把对话转成 tracer-bullet ticket，但 ticket 存哪？

取决于你配的 issue tracker——GitHub Issues、Linear、或者 local files。

如果用 local file tracker，ticket 存在 .scratch/<feature>/issues/ 下，比较简陋。

Matt 的思路很明确：任务状态机交给专业工具管，skill 只负责生成 ticket 和定义 blocking edges（依赖关系）。

Trellis 自己造了一套完整任务系统。task.py 提供 create / start / finish / archive / list / create-pr 全生命周期管理。状态机：

planning → in_progress → archived

每个 task 有独立目录（tasks/MM-DD-name/），里面是 prd.md + design.md + implement.md + research/ + 两个 jsonl 文件。

支持 parent/child task tree（--parent 参数）、per-session active-task 指针、生命周期 hooks（after_create / after_start / after_finish / after_archive）。

说实话，读到 after_finish 这种 hook 的时候，我意识到 Trellis 已经不是在解决 AI 编码的问题了，它在解决 AI 辅助的软件项目管理问题。

跨会话记忆：handoff vs journal

两个项目都意识到 AI 失忆这个问题，但解法差异很大。

mattpocock/skills 的 handoff skill 做法很简单：压缩当前对话成一个 markdown 文件，在新会话里手动引用。靠人主动触发，不维护日志。

Trellis 的做法重得多。add_session.py 自动把每次会话记录到 journal-N.md，每个开发者有独立 workspace（.trellis/workspace/<developer>/）。

Journal 有 2000 行上限，超出自动轮转到下一个文件。每个开发者还有 index.md 做个人索引。

关键差异：主动 vs 自动。handoff 是你要记得做，journal 是框架替你记。前者轻但有遗漏风险，后者全但不省 token。

实现与检查：文档约定 vs sub-agent 调度

这个维度最能体现两个项目的控制哲学。

mattpocock/skills 的 implement skill 只有 15 行（skills/engineering/implement/SKILL.md）：

# implement

Build the work. Drive /tdd internally. Check in periodically. 
When done, run /code-review. Commit.

就这几句话。它告诉你用 /tdd 做 red-green 循环，完成后跑 /code-review（双轴评审：Standards + Spec，用 parallel sub-agents 避免互相污染），然后提交。

不限制 git 操作——你随时可以 commit、push、merge。

Trellis 的 trellis-implement 是一个 sub-agent 定义。它：

1. 禁止 git commit/push/merge——sub-agent 不能碰 git
2. 读取 implement.jsonl + prd.md + design.md + implement.md
3. 实现完后由 trellis-check sub-agent 对照 spec 逐项核查 + 跑 lint/typecheck/test
4. 有递归守卫：sub-agent 内部不能再 spawn 同类 sub-agent
5. commit 由主会话驱动，分批提交（work commits → archive commit → journal commit）

trellis-implement 的调度 prompt 必须以 Active task: <task path> 开头，确保 sub-agent 知道自己在为哪个任务干活。

对比下来：mattpocock/skills 的 implement 更像一份编码纪律清单——告诉你该怎么做，但不拦着你。

Trellis 的 trellis-implement 是一个受约束的执行单元——能做什么、不能做什么、读什么、不读什么，全部定义清楚。

平台兼容性：单平台 vs 17 平台适配

这是 Trellis 碾压性优势的维度。

mattpocock/skills 主要面向 Claude Code。有 .claude-plugin/plugin.json 清单，通过 symlink 机制（scripts/link-skills.sh）勉强支持 ~/.claude/skills 和 ~/.agents/skills。

没有多平台适配层。如果你用 Cursor 或 OpenCode，得自己想办法。

Trellis 在 packages/cli/src/configurators/index.ts（617 行）里维护了一个 17 平台的注册表：

Claude Code、Cursor、OpenCode、Codex、Kiro、Gemini、Qoder、CodeBuddy、Copilot、Droid、Pi、Oh My Pi、Kilo、Antigravity、Devin、Trae、Zcode。

每个平台有独立的 configurator，把统一的 skill/command/agent/hook 模板适配成平台特有的目录结构和格式。举几个例子：

Claude Code: .claude/commands/trellis/*.md + .claude/agents/*.md + hooks
Cursor:      .cursor/commands/trellis-*.md + .cursor/agents/*.md + hooks.json
Codex:       .codex/skills/ + .codex/agents/*.toml + hooks.json
Copilot:     .github/prompts/*.prompt.md + .github/agents/*.agent.md
Kiro:        .kiro/skills/ + .kiro/agents/*.json（JSON 格式 agent 定义）

每个平台按能力分为两类：

• Sub-agent dispatch 类（Claude Code / Cursor / OpenCode / Codex-sub-agent / Kiro / Gemini / Qoder 等）：可以 spawn sub-agent，用 jsonl 注入上下文
• Inline 类（Codex-inline / Kilo / Antigravity / Devin）：主 agent 直接编辑，用 trellis-before-dev skill 加载 spec

Trellis 声称添加新平台只需 3 步。这个跨平台能力不是包装一层皮那么简单。

不同平台的 agent 定义格式、hook 机制、上下文注入方式差异很大，每个 configurator 都是在做真正的适配工作。

4. 能力矩阵：一张表看清差异

把上面的对比浓缩成一张表：

这张表里没有谁赢——因为它们不在同一个赛道。

两个项目六维度能力对比矩阵图

图 2：六维度能力矩阵——需求对齐、规范管理、任务系统、跨会话记忆、实现检查、平台兼容

5. 什么场景该选哪个

说了这么多对比，到底怎么选？我根据源码体现的设计意图，给几个判断。

选 mattpocock/skills 的情况：

• 你主要用 Claude Code，不需要跨平台
• 你是个人开发者或小团队，不想引入重框架
• 你已经有成熟的 issue tracker（GitHub / Linear）和工作流
• 你认同 TDD、domain modeling、deep modules 这些工程实践
• 你想要的是提升单次编码质量，而不是管理整个开发流程
• 你接受手动记住流程（ask-matt 路由器帮你，但不是强制的）

选 Trellis 的情况：

• 你跨多个平台（比如 Claude Code + Cursor + Codex 混用）
• 你是团队协作，需要共享规范和历史记忆
• 你的项目有一定复杂度（多 package、多 layer），需要分层规范
• 你受够了 CLAUDE.md 越写越长但没人看
• 你需要每次开发都有据可查——任务、spec、会话日志全留痕
• 你能接受框架替你编排流程（4 阶段循环 + 钩子注入）

两者组合用呢？ 理论上可以。Trellis 的 .trellis/ 目录体系和 mattpocock/skills 的 skill 文件不冲突。

你可以用 Trellis 管项目结构和任务流转，同时把 Matt 的 grilling / TDD / code-review 思想融入到你的 spec 和 brainstorm 流程里。但说实话，维护两套体系的认知成本不低，除非你真的两边的核心能力都需要。

如何选择两个项目的决策路径图

图 3：决策路径——先判断问题在纪律层还是管理层，再决定用哪个项目

6. Trellis 独有的 Channel 系统

前面没展开讲的一个东西，这里单独提一下——因为这是 mattpocock/skills 完全没有的能力。

Trellis 有个 Channel runtime（packages/core/src/channel）。trellis channel spawn 可以 spawn 独立的 worker 进程。它不是 prompt 约定层面的子代理，而是真正的进程级管理：

• 完整的进程操作：interrupt / kill / wait / list / send
• Worker guard：idle timeout（默认 5 分钟）、max live workers（默认 6）
• Supervisor 系统：每个 worker 有 supervisor 监控
• Context API：context entries 可以是文件、原始文本

这是 Trellis 把子代理调度做成了运行时能力，而不只是写几行 prompt 说你是个 sub-agent。它的野心已经超出了 AI 编码辅助，在往 AI 开发自动化平台的方向走。

当然，这个功能在 v0.6.6 阶段还比较新，实际效果得看后续迭代。但从架构设计看，Trellis 的 roadmap 明显更激进。

7. 从这两个项目看趋势

读完两个项目的源码，有几个观察值得说。

第一，对齐正在成为 AI 编码的标配。两个项目都不约而同地把逼你想清楚作为第一步。grilling 和 brainstorm 的契约几乎一样——这背后是对同一个问题的共识：AI 写代码快，但写对的前提是想对。

下一步你会看到更多工具把这套拷问机制做进去。

第二，sub-agent 模式在固化。两个项目都用了 sub-agent——mattpocock/skills 的 code-review 用 parallel sub-agents，Trellis 有 implement / check / research 三个 sub-agent。

区别是前者用 prompt 约定，后者做成了进程级调度。这说明行业已经认可了拆分 agent 职责这个方向。

第三个观察是 spec / context 的生命周期管理。CLAUDE.md 这类单文件配置的局限性已经暴露——文件越长越没人读。

Trellis 的分层 spec + jsonl 精确注入是一种解法，mattpocock/skills 的 CONTEXT.md 术语表 + ADR 是另一种解法。核心问题是一样的：怎么让 AI 在正确的时机读到正确的上下文，而不是一股脑全塞进去。

再往下说一层。mattpocock/skills 打的是编码纪律层（怎么写好代码），Trellis 打的是工程管理层（怎么让 AI 持续按规范工作）。这两个层正交，你可以同时需要——这也是为什么我不觉得它们是竞品，更像是互补。

还有一点容易被忽略：跨平台是硬壁垒。17 个平台的 configurator 不是谁都能做的——你得理解每个平台的 agent 格式、hook 机制、目录约定。这堵墙一旦砌起来，后来者很难翻。mattpocock/skills 的单平台策略短期内没事，但长期是个隐患。

8. 怎么选，取决于你的问题在哪一层

如果你读完这篇文章只想记一句话，记这个：

你的 AI 编码问题是写出来的代码质量不行，还是每次都得从头解释项目？前者是纪律层问题，后者是管理层问题。

mattpocock/skills 解决前者——给你一套逼着自己写好代码的工具。Trellis 解决后者——帮你把项目知识沉淀下来，让 AI 每次都能站在已有的基础上。

当然，现实里两个问题往往同时存在。这时候你得判断哪个更痛。

如果你的 AI 写的代码经常需要大改，先解决纪律。如果你的团队里每个人用 AI 的方式都不一样、规范形同虚设，先解决管理。

两个项目都还在早期阶段（mattpocock/skills v1.1.0、Trellis v0.6.6），都在快速迭代。它们代表的两条路线——工具箱 vs 框架、个人 vs 团队、纪律层 vs 管理层——能不能各自站稳，半年后回来看这两个仓库的 commit 活跃度和衍生项目数量就知道。

但作为使用者，搞清楚自己的问题在哪个层，比纠结用哪个工具更要紧。

说明：本文基于 mattpocock/skills（v1.1.0）和 Trellis（v0.6.6）的本地源码分析整理而成，所有文件路径、目录结构、代码片段均来自实际仓库。两个项目仍在活跃迭代，部分功能可能在后续版本中发生变化。文中的架构分析和选型建议仅供参考，实际使用请以你自己的项目需求和团队场景为准。如果有实际使用经验，欢迎在评论区分享交流。

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！