Trellis 是一个为 AI 编码助手设计的框架与工具集，核心是通过自动化规范注入、模块化任务管理、跨会话记忆和团队共享机制，将 AI 的编码行为从“随机发挥”引导至“遵循团队标准和流程”，特别适合希望统一和提升 AI 编码质量的开发团队使用。

这份架构文档揭示了 Trellis 的 设计本质：它不是简单的提示词管理器，而是一套将 AI 编码过程工程化为可管理、可共享、可跨平台的工作流与知识系统。其核心创新在于通过 Git 仓库中的结构化文件（规范、任务、日志） 作为持久化知识层，配合 轻量级的钩子与子代理机制 实现自动化注入，从而在多个 AI 工具和团队成员之间建立一致的“编码契约”。

在当前的 AI 编程工作流中，开发者往往面临一个显著的技术瓶颈：上下文窗口的碎片化与提示词的臃肿。

如果你正在使用 Cursor、Claude Code 等工具处理大型项目，你可能已经发现，简单的 .cursorrules 或 CLAUDE.md 文件在面对复杂逻辑时显得捉襟见肘。随着项目规模扩大，这类单一文件不仅会迅速消耗 Token，还会因为信息密度过载导致模型产生幻觉。

Trellis (https://github.com/mindfold-ai/Trellis)，正是为了解决这一工程化难题而设计的 AI 智能体框架（Agent Harness）

核心痛点：告别“单文件配置”的弊端

传统的做法是将架构规范、代码风格、业务上下文全部堆砌在单个 Markdown 文件中。这种“暴力喂养”方式在工程实践中存在以下缺陷：

上下文污染：不相关的规范干扰了模型对当前任务的理解。

缺乏状态管理：AI 无法有效记录跨会话的决策过程。

维护成本高：团队协作时，配置文件的冲突和版本管理异常困难。

从 Harness Engineering 到 Trellis：AI 编程助手的工程化落地实践

https://blog.csdn.net/qq_49116824/article/details/161491076

从现在开始积累属于自己业务线的数据资产。 无论是代码规范、架构决策、任务拆解记录，还是 AI 与人协作过程中沉淀下来的 spec 文档，这些资产都是迁移到任何新范式时最快的起跑线。

解决 AI “随机发挥” vs 需要“遵循规范”的矛盾

问题：传统方式中，AI 每次写代码风格不一，或不按项目既定规范（如目录结构、API 设计模式）执行。简单的 .cursorrules 需要手动加载且易被截断。

Trellis 方案：通过自动注入机制（Hook 或 Prelude），在 AI 写代码前自动读取 .trellis/spec/ 中的规范文件，并按任务精准加载，实现“写一次规范，AI 永久遵守”。

解决 AI “无记忆” vs 项目需要“跨会话上下文”的矛盾

问题：每次新开对话，AI 都忘记之前做了什么、项目当前状态如何，需要开发者重复解释背景。

Trellis 方案：引入 Workspace Journal（工作区日志），将会话记录持久化到仓库。AI 能跨会话记住上次的进度、决策和项目上下文，实现“断点续传”式的开发。

解决“个人技巧” vs “团队拉齐”的矛盾

问题：高手的 .cursorrules 或提示词难以在团队中标准化共享和迭代，导致成员 AI 使用水平参差不齐。

Trellis 方案：将规范（Spec）、工作流（Workflow）、任务（Task）全部 Git 版本化管理。新成员克隆仓库即获得团队最佳实践，实现“一人写规范，全队 AI 提效”。

解决“手动指挥” vs “自动化工作流”的矛盾

问题：开发者需要频繁手动切换上下文、指挥 AI “先调研、再写代码、再检查”，流程繁琐且易出错。

Trellis 方案：固化 Plan → Execute → Finish 三阶段工作流，并通过 Auto-trigger Skill（自动触发技能） 和 子代理角色（research/implement/check），让 AI 自己按流程推进任务，并保留审查边界（如检查代理产出干净 diff 后再提交）