最近我一直在思考一个问题：AI 编码工具越来越多，但为什么每次切换工具或开启新会话，都感觉像是从零开始？我用 [[Claude Code]] 写了一段时间，又想试试 [[Gemini]] CLI，但每次都要重新解释项目背景、编码规范、当前任务进度。这种重复性的”上下文喂养”工作，慢慢变成了一种隐性负担。
直到我发现了 Trellis，才意识到这个问题其实已经有人在认真解决了。
什么是 Trellis
Trellis 是由 Mindfold AI 开发的一个开源框架，定位非常明确：让 AI 编码代理真正具备生产就绪能力（production-ready）。它的核心理念是把开发规范、任务上下文和项目记忆统一存储在代码库中，让任何支持的 AI 平台都能自动获取这些信息，而不是每次手动复制粘贴。
从本质上说，Trellis 是一个”AI 代理的工作协议层”。它不替代任何具体的 AI 工具，而是在这些工具之上建立一套共享的约定和存储机制。开发者写一次规范，团队中所有人的 AI 代理都能受益；记录一次任务背景，下次换平台或换人接手时，AI 依然能理解当前进度。
目前 Trellis 声称支持 14 个 AI 编码平台，涵盖 [[Claude Code]]、Gemini CLI、OpenAI Codex、Cursor、Windsurf、Cline 等主流工具，基本覆盖了现在开发者常用的选择。
为什么 AI 辅助开发需要一个框架
在没有 Trellis 这类工具之前，AI 辅助开发存在几个非常实际的痛点，相信很多人都踩过。
第一个是上下文丢失问题。每次新开会话，AI 都不记得上次的内容。你需要重新解释项目结构、告诉它你们团队不用 var、提醒它接口命名要用驼峰式。这些碎片化的重复沟通，看似小事，累积起来却非常耗时。
第二个是跨平台一致性问题。假设你用 Claude Code 开发，同事用 Cursor，另一个同事用 Copilot，那三个人的 AI 助手都在按各自的”理解”写代码，最终合并时风格差异、规范冲突在所难免。
第三个是任务追踪缺失。AI 写代码很快，但它不知道”整个功能的实现计划是什么”、”这个 PR 的审查意见有哪些”、”上次做到哪一步了”。没有结构化的任务信息，AI 的输出往往是局部正确但全局脱节的。
Trellis 针对这三个问题都给出了对应的解决方案。
Trellis 的核心机制
Trellis 在项目根目录下创建一个 .trellis/ 文件夹，里面分三个子目录各司其职，设计非常清晰。
.trellis/spec/ 存放编码约定和项目规范。你可以在这里定义代码风格、架构决策、命名规范、禁止使用的模式等内容。Trellis 会在每次 AI 会话启动时自动注入这些规范，让 AI 始终按照你们团队的标准工作，而不是按照它自己的默认偏好。
.trellis/tasks/ 是任务中心。你可以把产品需求文档（PRD）、功能实现计划、代码审查意见存储在这里。当 AI 开始处理一个任务时，它能先读取完整的任务背景，而不是盲目地从当前文件猜测意图。这让 AI 的工作更有方向感，输出的代码也更符合整体设计。
.trellis/workspace/ 保存项目记忆。它会记录历史会话中的重要决策、已解决的问题和关键背景信息。这样下一次会话，不管是你自己接着做，还是换个 AI 平台，都能基于真实历史而不是空白状态开始工作。
这三个目录的内容都是普通文本文件，可以纳入版本控制，团队成员都能贡献和修改。一个人优化了规范，所有人的 AI 助手都同步受益，这是 Trellis 设计中我最欣赏的一点。
安装与上手
Trellis 的安装非常简单，通过 npm 全局安装即可：
npm install -g @mindfoldhq/trellis@latest
然后在你的项目目录下初始化：
trellis init -u your-name
-u 参数指定你的用户名，用于在项目记忆中标记是谁添加了哪些信息。初始化完成后，.trellis/ 目录会被创建，里面有基础的模板文件供你填写。
之后的工作流很自然：在 spec/ 下写你们的编码规范（可以从现有的 .cursorrules 或 CLAUDE.md 迁移过来），在 tasks/ 下创建功能任务卡，然后打开你喜欢的 AI 编码工具开始工作。Trellis 负责在会话开始时把相关信息注入给 AI，你只需要专注于具体问题本身。
对于已经有 CLAUDE.md 或者 .cursorrules 的项目来说，迁移成本很低。可以把现有的规范内容直接复制到 .trellis/spec/ 下，Trellis 会统一管理这些信息并适配到不同平台。
在团队协作中的价值
我觉得 Trellis 真正发光的场景是多人协作。个人开发者用它能省去不少重复沟通，但团队使用时带来的价值会被放大几倍。
想象一个典型场景：产品经理把需求写成一个 tasks/feature-xxx.md 文件提交到仓库，后端工程师的 Claude Code 读取后按照 spec/backend-conventions.md 中的规范实现接口，前端工程师的 Cursor 读取同样的任务背景后按照 spec/frontend-conventions.md 写组件，代码审查的意见也记录回 task 文件。整个过程中 AI 始终在同一个”知识库”下工作，而不是各自为战。
这种模式下，团队对 AI 工具的依赖不再是个人行为，而是变成了一种可以持续演进的集体能力。规范越来越完善，记忆越来越丰富，新成员入职后 AI 助手也能快速提供高质量的辅助，因为它已经”学到”了这个团队的工作方式。
最后
Trellis 解决的问题听起来不算惊天动地，但它戳中了 AI 辅助开发工作流中一个真实而长期被忽视的薄弱环节：AI 工具本身越来越强，但工具之间、会话之间的连接性一直很弱。把规范和记忆从每个工具的私有配置中解放出来，存到代码库里统一管理，这个思路既简单又务实。
对我来说，Trellis 最大的启示不只是这个工具本身，而是它背后反映的一种工程思维：AI 代理不应该是用完即弃的临时助手，而应该是可以积累知识、与团队共同成长的协作者。把这种积累机制做好，才是 AI 辅助开发真正成熟的标志。
如果你也在使用多个 AI 编码工具，或者在团队中推广 AI 辅助开发，Trellis 值得认真了解一下。项目地址在 GitHub：mindfold-ai/trellis。