这次评测的目标很直接：在同一套项目代码、同一份 .trellis 业务知识库、同一个 Claude Code、同一个模型与思考程度下，实测把项目接入从 Trellis 换成 mini-trellis 后，完成同样的开发任务能不能更快、更省 Token。

测试涵盖空载启动、日常写代码、查项目规范、按规范写实现，以及跨会话记规则与迭代修改，共 6 组任务，每组独立跑 3 次。结果显示：在两边自动检查全部通过的前提下，mini-trellis 在每一组任务上都比 Trellis 更快、处理 Token 更低；全部任务累计耗时减少 38.4%（提速 1.62×），累计处理 Token 减少 40.1%（少用 162.7 万 Token）。

一、评测前提与环境配置

为了保证对比公平，除了安装的工具本身不同之外，其余所有条件完全一致，每次测试都在全新初始化的独立项目目录与独立宿主历史目录中运行：

统计口径说明：耗时为命令启动到退出的实际墙上时间（秒）；轮次为 Claude Code 统计的交互轮数（num_turns）；处理 Token 为单次任务处理总量（未缓存输入 + 输出 + 缓存命中读取，其中输入与缓存互斥，不重复计算；处理 Token 衡量上下文处理总量，不等同于 API 账单费用）。

二、整体评测结果与图表对比

全部 6 组任务（每组 3 次，含 15 次单会话任务与 3 条四阶段跨会话长链，每侧各 27 个独立会话）整体表现如下：

• 总耗时减少 38.4%（快 1.62 倍）：完成全部评测任务，mini-trellis 总计用时 472.2 秒，Trellis 总计用时 766.5 秒，累计节省 294.3 秒。
• 总处理 Token 减少 40.1%（少用 162.7 万）：mini-trellis 累计处理 2,426,377 Token，Trellis 累计处理 4,052,930 Token。无论是未缓存的新鲜输入、模型输出还是多轮累积的缓存读取，mini-trellis 在每一项任务上都低于 Trellis。
• 总交互轮次减少 27.8%：mini-trellis 累计 273 轮，Trellis 累计 378 轮，少走了 105 轮探索和读写。

各题型对比汇总大表

下表列出 6 组任务的 3 次中位数 与 3 次合计值（括号内为 mini-trellis 相比 Trellis 的节省比例）：

为什么 mini-trellis 更快、更省？

1. 启动底噪更小，每一轮背负的上下文更轻：从 O00 可以直接看到，哪怕什么文件都不读，Trellis 首轮注入的 8,674 字符也会让初始输入多出近 2,000 Token；一旦进入多轮工具调用（如 I01、M01 动辄 15～20 轮），首轮多出来的数千 Token 会在后续每一轮缓存读取中被反复累加。
2. 定位直接，少了无关目录排查：提示词里不直接告诉模型文件名时，mini-trellis 通过 mem recall 或精简入口直接定位 .trellis/spec/ 下的目标规范；而 Trellis 经常顺着启动说明去翻找 .trellis/tasks/00-bootstrap-guidelines/prd.md 等任务引导目录，多花了好几轮 grep/Read 和模型输出。

三、题目设计与单次轮次详细表现

评测没有在提示词里透露具体规范文件名或公式，全部要求模型自己去项目里查找并完成任务。下面按题型列出设计意图与每次运行的实测数据。

1. 空载启动开销（O00）

• 题目设计：要求模型只回复 pong，禁止读写任何文件。用来剥离工具调用干扰，纯粹测量两个产品在会话启动时的固定注入开销。
• 表现分析：三次测试两边都是 1 轮完成、0 次工具调用。mini-trellis 每次固定输入 11,565 Token，Trellis 固定输入 13,475 Token（多出 1,910 Token，对应启动 Hook 多注入的约 7,500 字符工作流说明）。此外 Trellis 的启动提示要求模型先输出确认语再回答问题，导致输出 Token 和耗时也明显更高。

2. 常规函数实现（N01）

• 题目设计：根据 label_utils.py 中的函数文档实现 normalize_label 标签规范化函数，并用 unittest 编写单元测试。这道题不需要查阅历史规范，用来检验日常普通编码场景下记忆层会不会带来额外累赘。
• 表现分析：两边都没有去调记忆检索，直接读代码、改代码、跑测试，3 次全部通过外部单元测试。即便第 1 次 mini-trellis 比 Trellis 多用了 1 轮（13 轮 vs 12 轮），因为上下文负担轻，耗时依然更短（16.9s vs 18.6s），总 Token 反而省了 26.5%。

3. 查规范：计算公式与异常策略（R01）

• 题目设计：项目里既有研究阶段的背景讨论（.trellis/research/notice-background.md），也有正式敲定的后端规范（.trellis/spec/backend/notice-impact.md）。要求模型找出关于“公告容量影响与实际流量影响”的最终计算公式、3 种缺失/模糊场景的处理策略，以及原文出处。评分器通过 AST 数值探针验证公式真伪。
• 表现分析：两边 3 次均找对规范并全部通过数值探针、策略与引文匹配自动校验。mini-trellis 每次都先执行 mini-trellis mem recall 检索再读取规范，3 次总耗时 39.6s，比 Trellis（72.2s）省了将近一半时间；Trellis 在第 1、2 次中还去翻阅了 .trellis/tasks/00-bootstrap-guidelines/prd.md，拉高了耗时和输出量。

4. 查规范：服务权限边界（R02）

• 题目设计：查询项目对“只读业务工具服务”的权限规定，逐项返回是否只读、是否允许代理问答、是否允许原生 SQL、是否允许触发爬虫、是否允许固定参数化 SELECT（5 个独立布尔值）及原文出处。
• 表现分析：这道题差距非常直观。mini-trellis 三次都直接用 mem recall 命中 .trellis/spec/backend/read-only-tools.md，4～6 轮即给出答案，中位耗时仅 7.2s；Trellis 每次都要在 .trellis/spec、.trellis/tasks、.trellis/workspace 之间搜索和翻看引导文件，用了 7～11 轮，中位耗时 16.3s，是 mini-trellis 的 2.27 倍。

5. 按规范实现业务代码（I01）

• 题目设计：要求模型自己去项目里查找业务规范，按规范实现 pipeline_impact.py 中的 assess_notice 函数并编写测试。外部评分器会用 27 组边界测试（包含正常计算、真实 0 值、口径不匹配、缺失元数据、布尔值冒充数字、负数/无穷大、输入字典防篡改等）做严格验收。
• 表现分析：两边 3 次实现的 27 个测试点全部满分通过。在这样一个 16～23 轮的重度编码任务里，启动注入和无关文件读取通过多轮缓存被明显放大：Trellis 3 次累计缓存读取高达 69.2 万 Token，而 mini-trellis 只有 45.8 万 Token，总 Token 节省了 31.2%（55.0 万 vs 80.0 万）。

四、跨会话记规则与迭代汇总（M01 四阶段长链）

题目设计

M01 模拟真实开发中最常见的“多会话知识沉淀与变更”闭环。在同一项目内连续开启 4 个全新的独立会话（后一个会话没有前一个会话的聊天上下文，只能靠项目里沉淀的文档、日志或记忆检索获取信息）：

1. 阶段 1（记下初始规则）：告知模型回调重试规则改为“transient 失败最多尝试 2 次，permanent 尝试 1 次”，要求更新项目知识并留一条开发日志（journal）。
2. 阶段 2（新会话按规则实现）：开启新会话，不提示次数，只让模型“按项目当前确认的规则实现 retry_policy.py 的 max_attempts 并写测试”（验收要求 transient -> 2）。
3. 阶段 3（新会话变更规则）：开启新会话，告知因“上游已经确认幂等保障”，transient 总尝试次数改为 4 次，要求更新原主题知识并留开发日志说明变更原因。
4. 阶段 4（新会话按新规则更新实现）：再次开启新会话，让模型按最新确认的规则更新 retry_policy.py 与测试（验收要求 transient -> 4）。

整链与四阶段对比汇总

3 条完整四阶段长链跑下来，两边在阶段 2（2 次）和阶段 4（4 次）的代码验收全部通过，但在维护项目知识与跨会话复用的成本上拉开了明显差距：

3 条长链的逐次与逐阶段明细

• 为什么阶段 3（变更规则与留日志）差距高达 60%？ mini-trellis 在新会话启动后，用 1 次 mem recall 就找到了阶段 1 更新的规范、开发日志以及历史会话记录，直接改好规范并追加日志，3 次分别只用了 18.8s / 22.1s / 17.4s。而 Trellis 没有统一检索入口，为了按它的规范更新知识并写日志，模型在 .trellis/spec、.trellis/workspace、.trellis/scripts 下反复读取和核对格式，3 次分别花了 46.3s / 64.8s / 47.2s（其中第 2 次单阶段就跑了 37 轮、消耗 47.4 万 Token）。