大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



一句话理解：$start 不是让 AI 立刻写代码，而是让 AI 先进入当前项目的 Trellis 上下文。

在 Claude Code 教程里，经常看到的是：

 /trellis:start 

在 Codex 里，对应的常见触发方式是：

 $start 

所以可以先记住这组映射：

• Claude Code：/trellis:start
• Codex：$start

它们做的核心事情类似：

• 读取当前项目状态
• 读取当前任务状态
• 读取 Trellis 工作流信息
• 让 AI 知道这是一个带任务、带规范、带记录的项目会话

最常见的 4 种场景：

1. 刚进入一个项目，准备正式开始协作。
2. 新开了一轮会话，需要让 AI 重新认识当前项目。
3. 会话聊散了，想重新对齐到项目工作流。
4. 你准备从“普通聊天”切换到“正式开发 / 正式记录”的状态。

简单记忆：

只要你准备认真在这个项目里开工，就先 $start。

同一个项目、同一段连续会话里，通常只需要执行一次 $start。

以下情况一般不用重复：

• 你刚 $start 完，接着继续问项目问题。
• 你刚 $start 完，马上进入同一个任务继续做。
• 你只是在同一轮对话里继续改文件、解释代码、补测试。

以下情况适合重新 $start：

• 重新打开 Codex / 新开一轮会话。
• 切换到了另一个项目。
• 中间聊偏很久，想重新对齐。

一句话：

不是每说一句开发话都要 $start，而是在“重新进入项目工作状态”时再 $start。

可以。

$start 不是“禁止聊天开关”，而是“进入项目上下文”的动作。执行完以后，你仍然可以：

• 问项目结构
• 问任务怎么理解
• 问 Trellis 的工作原理
• 提出开发需求
• 让 AI 先分析再动手

区别在于：

• 不 $start 时，更像普通聊天
• $start 之后，更像“AI 已经进入这个项目开始协作”

所以最合理的理解是：

$start 后仍然能聊天，但最好聊当前项目相关的事情。

最推荐的方式是分两句写：

 $start 继续当前任务 

或者：

 $start 帮我做一个 xxx 功能 

也就是说，$start 后面不需要复杂提示工程，通常只要跟一句自然语言，说明“这次要干什么”。

自然语言里最有用的 4 类信息：

1. 目标：这次想做什么。
2. 范围：改哪个模块、哪个页面、哪个文件附近。
3. 限制：先做最小版本、不要大改结构、保持现有风格。
4. 状态：继续当前任务，还是新开任务。

走法 1：继续已有任务

 $start 继续当前任务 

适合：项目里已经有当前任务，或者你知道自己要接着上次往下做。

走法 2：直接进入明确开发目标

 $start 帮我给设置页加一个深色模式开关。 尽量沿用现有样式，不要大改结构。 

适合：你已经知道要做什么，而且范围比较明确。

走法 3：先脑暴再进入任务流

 $start $brainstorm 我想做一个待办事项功能，但需求还没想清楚。 

适合：你只有想法，没有清晰范围。

因为 Trellis 真正重要的不是“华丽提示词”，而是：

• 当前项目上下文
• 当前任务
• 当前规范
• 这次目标

如果你在 $start 后立刻扔很长很乱的一大段话，常见问题是：

• 目标不清晰
• 范围不稳定
• AI 容易顺手扩展
• 不利于挂任务和后续记录

更稳妥的方式是：

先 $start，再用正常人话说清楚你要做什么。

模板 1：继续当前任务

 \(start 继续当前任务，先告诉我现在做到哪了，再继续。 

模板 2：继续指定任务

 \)start 继续 Bootstrap Guidelines 这个任务。 

模板 3：明确开发需求

 \(start 帮我做一个 xxx 功能。 先做最小可用版本，不要顺手扩展。 

模板 4：小改动

 \)start 帮我改一下 xxx。 只改必要文件，先别动其他地方。 

模板 5：先分析再改

 \(start 我想改 xxx，先帮我看当前代码和规范，再告诉我准备怎么改。 

模板 6：需求还不清楚

 \)start $brainstorm 我想做 xxx，但需求还不够清楚，先帮我梳理范围。 

错误 1：把 \(start 当成 shell 命令

错误理解：

 \)start 

问题：这不是 PowerShell 或 bash 原生命令，而是 Codex 对话里的技能触发方式。

正确理解：

• 在终端里跑 git、python、trellis、npm
• 在 AI 对话里用 \(start、\)brainstorm、\(finish-work

错误 2：同一轮会话里反复 \)start

错误做法：每说一句开发相关的话都先来一次 \(start。

问题：会打断节奏，而且没有额外收益。

正确做法：

• 连续同一会话里，一般只需要一次
• 只有“新会话 / 新项目 / 聊散后重对齐”才重来

错误 3：\)start 后不说明目标

错误做法：

 \(start 

然后什么也不说，或者马上跳去完全不相关的话题。

问题：AI 虽然进入了项目上下文，但不知道你这次到底要干什么。

正确做法：

 \)start 继续当前任务 

或

 \(start 帮我做一个 xxx 功能 

错误 4：正式开发却不挂任务

错误做法：直接让 AI 改很多文件，但没有明确任务。

问题：会失去 Trellis 最重要的价值：

• 需求沉淀不到 prd.md
• 下次不好恢复
• 完成边界不清楚
• record-session 和归档会变虚

正确做法：

• 问答可以直接聊
• 小修小补可以灵活一点
• 正式开发尽量进入任务流

错误 5：把 \)start 当成“不能聊天”的模式切换

错误理解：\(start 以后只能下命令，不能正常说话。

问题：这会让使用变得僵硬。

正确理解：

\)start 以后仍然可以正常聊天，只是 AI 会带着项目上下文来理解你的话。

可以把 $start 记成：

“先让 AI 进入项目状态，再告诉它这次要干什么。”

如果只记一个最简模板，就记这个：

 $start 继续当前任务 

或者：

 $start 帮我做一个 xxx 功能 

• $start 在 Codex 里很重要，但它不是 shell 命令，而是 AI 工作流命令。
• $start 的作用是让 AI 先进入当前项目的 Trellis 上下文。
• 同一轮连续会话里通常不用重复 $start。
• $start 后仍然可以正常聊天，但最好围绕当前项目。
• $start 后最有用的不是复杂提示词，而是一句清晰的自然语言目标。
• 如果需求模糊，$start 后很适合接 $brainstorm。

这里最容易误会的一点是：

$brainstorm、$finish-work、$record-session、$update-spec 不是固定连招，而是分别对应任务不同阶段。

如果我要先记最短版顺序，可以先记成：

• $start：先进入当前项目上下文
• $brainstorm：需求还不清楚时，先理清范围
• $finish-work：准备提交前，先做完工检查
• 人工测试：自己再实际确认这轮结果没问题
• git commit：先把这一轮最新改动提交掉
• $record-session：再记录这次 session 做了什么
• $update-spec：最后只在需要沉淀项目规矩时再用

一句话理解：$brainstorm 不是直接开工，而是让 AI 先帮我把需求、范围和方案理清楚。

它最适合什么时候用？

• 我知道自己想做什么方向，但边界还不清楚
• 我还拿不准该做最小版本，还是顺手考虑未来扩展
• 这件事可能有不止一种做法，我想先看选项和取舍

最重要的理解是：

$brainstorm 只在“需求还没清楚”时有价值，不是每次任务开始都必须先跑一次。

$brainstorm 最像什么

如果我要用最白话的话记，它更像：

“先别急着做，先把这次到底要做什么聊清楚。”

它通常会帮我做几件事：

• 先把当前想法挂成任务
• 把已知目标写进 prd.md
• 根据项目现状和已有文件，先做一轮研究
• 如果有多个可行方案，再给我 2 到 3 个更具体的选项
• 最后把 MVP 边界收敛下来

$brainstorm 什么时候最典型

比如下面这种情况就很适合：

 $start $brainstorm 我想把这份笔记继续整理下去，但第 5 章到底该偏安装说明，还是偏实战理解，我还没完全想清楚。 

或者：

 $start $brainstorm 我想给项目加一个新功能，但我还不确定要不要拆任务、要不要先保留扩展性。 

一句话记忆：

需求模糊时，用 $brainstorm；需求清楚时，不用为了形式硬加它。

一句话理解：$finish-work 是在 准备提交之前，让 AI 帮我做一次完工检查。

它不是“整个大任务彻底结束时才用一次”，而是更像：

这一轮改动准备提交了，我先检查有没有漏项。

本地技能里写得很明确，它的时机是：

• 写完代码或内容之后
• 跑过必要检查之后
• git commit 之前

所以更准确的记法是：

所以更准确的记法是：

$finish-work 是提交前检查，不是归档命令。

它也不能替代人工测试。更稳的顺序是：

$finish-work → 人工测试 → git commit

$finish-work 会帮我想到什么

它更像一张“别漏”的检查清单，比如：

• 该跑的 lint / type-check / test 有没有跑
• 这次改动有没有影响相关规范
• 有没有跨层改动却没补 code-spec
• 有没有漏掉手工验证

对文档型任务来说，它不一定每次都要很重地用，但如果这一轮已经形成完整成果、准备 commit，那它仍然有价值。

一句话记忆：

提交前心里没底，就先 $finish-work。

一句话理解：$record-session 不是检查质量，而是 记录这次 session 做了什么。

它会把本次工作总结写进：

 .trellis/workspace/ 

里的 journal 文件，方便以后恢复上下文。

这里最重要的一点，我现在一定要记住：

$record-session 之前，通常应该先把你想记录的最新改动提交掉。

也就是说，顺序更像：

 做任务 -> 需要时 $finish-work -> 人工测试 -> git commit -> $record-session 

因为 record-session 记录的应该是“这次已经落稳的结果”。

如果我上一次 commit 之后又继续改了内容，但还没提交，这时直接 record-session，就很容易出现：

• session 里看起来像已经收尾
• 但真正最新的内容还没进入版本历史

所以以后最稳的判断标准不是“我今天提交过一次”，而是：

我要记录的这一批最新改动，是不是已经提交好了。

一句话记忆：

$record-session 是提交后记日志，不是提交前占坑。

一句话理解：$update-spec 不是普通工作记录，而是把这次任务里沉淀出的经验，升级成 项目以后都能复用的规矩。

它最适合什么时候用？

• 我实现了一个以后还会重复遇到的模式
• 我修掉了一个很容易重复踩的坑
• 我明确了某个设计决定，以后不想每次重新争论
• 我发现某个“先做 X 再做 Y” 的稳定顺序值得写下来

所以它不是“这次做了事就顺手记一句”，而是：

这次学到的东西，值不值得变成项目级知识。

这些规矩会写到哪里

默认是当前项目的：

 .trellis/spec/ 

下面，但具体放哪一层，要看它是什么类型的规则：

• .trellis/spec/backend/
  放“后端怎么实现”的具体规矩
  
  
  
  
  
• .trellis/spec/frontend/
  放“前端怎么实现”的具体规矩
  
  
  
  
  
• .trellis/spec/guides/
  放“做之前要想到什么”的思考清单和提醒
  
  
  
  
  

如果我要用最简单的话区分，就是：

• “这是以后代码该怎么写”
  放 backend/ 或 frontend/
  
  
  
  
  
• “这是以后做事前该先想到什么”
  放 guides/
  
  
  
  
  

一句话记忆：

$update-spec 是把一次性的经验，变成这个项目长期可复用的规矩。

如果需求还不清楚，最常见的顺序是：

 $start $brainstorm 做任务 $finish-work 人工测试 git commit $record-session 

如果这次工作还顺手沉淀出了项目级规则，再额外考虑：

 $update-spec 

如果需求本来就很清楚，那就可以简化成：

 $start 做任务 $finish-work 人工测试 git commit $record-session 

所以最后最值得记住的不是“固定连招”，而是：

这些命令分别属于不同阶段，按场景选用，不是每次都必须全跑一遍。

1. $start 用来恢复项目上下文，$brainstorm 只在需求还没清楚时才有价值。
2. $finish-work 是提交前检查，后面还应该自己做人工测试，再 git commit。
3. $update-spec 只在经验值得升格成项目规矩时再用，不是每次任务都要机械补一遍。

---

一句话理解：/trellis:parallel 是把一个已经比较清楚的大任务，拆成几块边界清楚的小任务，然后让多个 AI 同时推进。

课件里写的是 /trellis:parallel，但在我现在这个 Codex + Trellis 环境里，更接近的入口通常是 $parallel。

名字不一定完全一样，但核心意思是一致的：

• 主代理先负责规划、拆分、配上下文
• 真正写代码或写内容的，是后面被派出去的并行代理

所以它不是“再开几个聊天窗口碰碰运气”，而是按任务边界派工。

• $start：我自己回到当前项目上下文，然后继续在主仓库这一条主线里往下做
• $parallel：我先把任务拆开，再把不同子任务分发给多个代理并行推进
• 所以 $start 更像“进入上下文”，$parallel 更像“组织并行流水线”

最典型的是下面这种情况：

1. 需求已经比较清楚，不需要再花很长时间脑暴
2. 能拆成 2 到 3 块相对独立的工作
3. 每一块都能说清楚“谁改什么、产出是什么、验收是什么”
4. 并行之后，确实比串行更省时间

比如：

• 一个代理改后端接口
• 一个代理改前端页面
• 另一个代理补测试、文档或 Spec

这种拆法通常比“所有东西都让一个 AI 串着做”更合适。

• 需求本身还很模糊
• 大部分改动其实都挤在同一个文件或同一段逻辑里
• 子任务之间强依赖，谁都要等谁
• 只是个很小的修补，拆开反而更慢

一句话说，就是：拆不清，就先别并行。

结合当前仓库里的并行技能和脚本，我可以把它理解成这样：

1. 主代理先在主仓库里读 workflow、任务上下文和 Spec
2. 先把任务整理成可执行的 PRD 和上下文配置
3. 再启动多代理流水线，把每个子任务放到各自独立的 worktree 里
4. 每个 worktree 里的代理再继续走实现、检查、收尾这些步骤

也就是说，主代理更像项目经理；真正干活的代理，是被分发出去的那些工作树代理。

worktree 可以先简单理解成：同一个仓库的独立工作副本。

它的价值是：

• 每个代理都有自己独立的目录和分支
• 不容易互相覆盖彼此正在改的文件
• 主仓库可以继续负责统筹，而不是一边调度一边自己下场乱改

你可以把它想成：同一个项目，被临时分成了几张彼此隔开的工作桌。

1. 这几个子任务的边界，我现在能说清楚吗？
2. 共用的接口、字段、命名规则，是不是已经先定住了？
3. 每个子任务结束时，我能不能单独验收？
4. 我到底是为了提速，还是只是因为“看起来很高级”才想并行？

如果前 3 个问题答不稳，那通常应该先继续收敛需求，而不是急着上并行。

• /trellis:parallel 不是“任务一大就无脑开”
• 它也不是跳过 PRD、Spec、检查流程的捷径
• 并行不是拆得越细越好，拆太碎只会增加合并和沟通成本
• 真正关键的不是“同时有几个 AI”，而是“边界是不是提前拆清了”

如果我要先记最短版，只记这三层就够：

• /trellis:parallel 在我当前这个 Codex 环境里，可以先对应理解成 $parallel
• 它只适合“需求已经清楚，而且真的能拆开”的任务
• 真正让它有效的不是数量，而是任务边界、共享约定和验收标准

1. $parallel 不是多开聊天，而是把一个清楚的大任务拆给多个代理并行做。
2. 拆不清、依赖重、改动太小，就不要为了形式硬上并行。
3. 并行真正难的不是“启动几个 AI”，而是先把边界、接口和验收说清楚。

---

如果我后面复习时总觉得这些词长得像，可以先按“这次做什么 / 按什么规矩做 / 做完怎么留痕”三层来记。

一句话理解：任务就是“我这次到底在推进哪件事”。

• 它通常落在 .trellis/tasks/ 下面的某个任务目录里
• 它主要回答“这次要做什么、做到哪一步了”
• 不要和 Spec 混：任务说的是这一次，Spec 说的是以后都尽量怎么做

一句话理解：当前任务就是“我这轮会话默认接着做的那张任务卡”。

• Trellis 会把它记到 .trellis/.current-task
• $start 之后，AI 会优先读这个任务对应的目录和 prd.md
• 它的价值不是多一个名字，而是让 AI 知道这轮会话该接着哪条主线走

一句话理解：PRD 是这次任务的目标、范围、要求和阶段结论。

• 在这个项目里，最常见的文件就是任务目录里的 prd.md
• 它主要负责把需求边界固定住，避免 AI 每次都重新猜
• 你可以先把它理解成：任务的详细说明书

一句话理解：Spec 是“这个项目平时做事要遵守的规矩”。

• 它通常放在 .trellis/spec/
• 它回答的不是“这次做什么”，而是“做的时候应该怎么做才像这个项目”
• 如果 PRD 像任务说明书，那 Spec 更像长期有效的项目规则

一句话理解：guides 是提醒我“做之前先想到什么”的思考指南。

• 它也是 .trellis/spec/ 里的一层，但和 backend / frontend 不完全一样
• 它更像检查思路、边界和风险的提示，不一定是直接的实现规则
• 可以先粗记成：Spec 更像“怎么写”，Guide 更像“先想什么”

一句话理解：context 不是玄学记忆，而是这轮会话开始时 AI 能读到的项目上下文。

• 比如当前任务、prd.md、Spec、git 状态、活跃任务这些信息
• $start 的作用之一，就是把这些上下文重新接回来
• 所以 Trellis 的重点不是让 AI 硬记，而是让关键状态可重新读取

一句话理解：$brainstorm 是需求还不够清楚时，先把范围和边界聊清楚。

• 它不是正式实现本身，而是实现前的收敛阶段
• 当我还不知道怎么拆、怎么做、要不要保留扩展性时，它最有价值
• 需求已经清楚时，就不用为了形式硬加它

一句话理解：workspace 是用来放 session 记录和个人工作留痕的地方。

• 这里更像“工作日志区”
• 它保存的是这次做了什么、怎么推进的，不是任务目标本身
• 所以不要把它和任务目录混成一件事：任务目录管任务，workspace 管过程记录

一句话理解：$record-session 是把这次 session 的结果记进 workspace。

• 它是提交后记录，不是提交前检查
• 它前面通常应该先确认最新改动已经 commit 进版本历史
• 如果 $finish-work 是提交前检查，那 $record-session 就更像提交后的工作日志

一句话理解：Archive 是已经完成、不再活跃的任务归档区。

• 在工作流里，任务可以从活跃列表移到 archive/{year-month}/ 下面
• 它解决的是“旧任务往哪放”，不是“这次 session 记到哪里”
• 所以不要把 Archive 和 workspace 混淆：一个偏任务归档，一个偏过程记录

一句话理解：worktree 是同一个仓库的独立工作副本。

• 它常出现在并行协作场景里
• 每个代理可以在自己的 worktree 里改自己的分支和文件，减少互相打架
• 你可以先把它想成：同一个项目临时分出来的独立工位

如果我只想先记最容易混的几对，可以先抓住这 4 组：

• 任务 / PRD：任务是这次要做的事，PRD 是这次任务的详细边界
• PRD / Spec：PRD 管这一次，Spec 管以后类似事情怎么做
• workspace / Archive：workspace 记过程，Archive 收旧任务
• $finish-work / $record-session：前者提交前检查，后者提交后记录

1. 任务、PRD、Spec 不是一个东西，而是“这次做什么 / 这次边界是什么 / 长期规矩是什么”三层。
2. workspace 记录 session 过程，Archive 存已经归档的旧任务。
3. context 不是 AI 靠脑子硬记，而是 Trellis 让关键状态可以被重新读回来。

---

这是一个很容易犯的错，而且我刚刚就真实遇到了。

当时的情况是：

• 我先做了一次提交
• 提交之后又继续补了新的笔记内容
• 然后准备直接 $record-session

这时候问题就出现了：

虽然仓库里“有 commit”，但最新改动其实还没再次提交。

也就是说，$record-session 能稳定记录下来的，只是已经提交过的状态。如果我在上一次提交之后又改了文件，但还没重新 commit，那么现在直接记录 session，就会出现一种“看起来要收尾了，但最新内容其实还没真正落进版本历史”的情况。

所以更稳的判断不是：

• 只要我今天 commit 过一次，就能 $record-session

而是：

• 我要记录进 session 的这批最新改动，必须已经完成提交

我现在可以这样记这个顺序：

1. 先改内容
2. 如果后面又继续改了，就再提交一次最新改动
3. 确认 git status 是干净的
4. 再执行 $record-session

最简单的检查方法就是这两个命令：

 git status git log --oneline -1 

如果看到：

 nothing to commit, working tree clean 

并且 git log --oneline -1 显示的是我刚刚那次最新提交，才说明现在适合去做 $record-session。

一句话记忆：

不是“今天提交过一次就行”，而是“我要记录的最新内容已经提交好了，才适合 $record-session”。

这条对我尤其重要，因为我现在这种学习方式很容易出现：

• 先提交一版
• 又继续补几段思考
• 然后以为可以直接收尾

以后遇到这种情况，我就先停一下，问自己一句：

“我准备记录到 session 里的，是不是已经是最新那次 commit 了？”

如果不是，就先补提一次，再记录。

不一定，但可以这样判断：

• 如果你问的是通用概念，比如“PRD 是什么”“Spec 和 Guide 区别是什么”，不一定非要先 $start
• 如果你问的是“这个仓库现在是什么状态”“我当前任务接下来该补哪一段”这种项目内问题，最好先 $start

最简单的判断标准就是：这件事需不需要读当前仓库和当前任务的真实状态。

如果需要，就先 $start；如果只是泛知识问题，可以先直接问。

因为 $brainstorm 的价值不在“形式完整”，而在“帮你收敛不清楚的东西”。

如果这次任务已经满足下面几点：

• 目标清楚
• 改动范围大致清楚
• 你已经知道大概要改哪里

那就可以直接 $start 之后进入任务，不用为了流程好看再额外脑暴一轮。

一句话记忆：$brainstorm 是用来消除模糊，不是用来走仪式。

最稳的顺序通常是：

1. 先看 PRD
   先搞清楚这次任务要做什么
   
   
   
   
   
2. 再看 Spec
   再确认这个项目希望你怎么做
   
   
   
   
   

因为如果一上来只看 Spec，你可能只知道“规矩是什么”，但还不知道“这次到底要交什么”。

反过来，如果只看 PRD 不看 Spec，你又容易做出“这次能跑，但不像这个项目的人会写的东西”。

如果我要把整份笔记压成一页速查版，我会先记住下面这些。

• Trellis 的本质，是把 AI 从“随便聊聊”变成“按项目流程协作”。
• 它最重要的不是让 AI 变神，而是让任务、规范和记录尽量落进项目文件。
• 所以恢复上下文时，我靠的是重新读项目状态，不是靠 AI 硬记。

• 安装 Trellis：npm install -g @mindfoldhq/trellis@latest
  这是把工具装到电脑里，一台电脑通常一次。
  
  
  
  
  
• 项目接入 Trellis：git init / trellis init ...
  这是让某个具体项目接上版本管理和 Trellis 工作流。
  
  
  
  
  
• 进入当前会话：$start
  这是让 AI 回到当前项目上下文开始协作。
  
  
  
  
  

如果需求还不清楚：

 $start $brainstorm 做任务 $finish-work 人工测试 git commit $record-session 

如果需求本来就清楚：

 $start 做任务 $finish-work 人工测试 git commit $record-session 

如果这个任务还能清楚拆成几块，再额外考虑：

 $parallel 

如果这次工作还顺手沉淀出了项目级规则，再额外考虑：

 $update-spec 

• $start：恢复项目和任务上下文
• $brainstorm：需求模糊时先理清范围
• $parallel：把可拆分的大任务分发给多个 AI 并行推进
• $finish-work：提交前检查有没有漏项
• 人工测试：自己确认这轮结果真的可用
• $record-session：提交后记录这次 session 做了什么
• $update-spec：把可复用经验升级成项目规矩

• $finish-work 不是任务归档，而是提交前检查。
• $finish-work 后面，通常还要自己做一次人工测试，再决定是否提交。
• $record-session 之前，通常应该先提交你想记录的最新改动。
• $update-spec 不是普通日志，而是写进 .trellis/spec/ 的项目级知识。

• 它不只适合写代码，也适合像 trellis-study-notes 这样会跨越多轮对话的整理型任务。
• 真正有价值的不是某次回答，而是任务、边界、产物都落到了项目文件里。
• 我不是每次都从头开始解释任务，而是在 Trellis 里持续接着做。

---

如果我现在只想复习最重要的内容，可以按这 3 种节奏来：

1. 先看“一页总结”，把整体骨架过一遍。
2. 再看“常用命令——每个都有演示”里的 $start、$brainstorm、$finish-work、$record-session。
3. 最后扫一眼“名词小字典”，把 PRD / Spec / workspace / Archive 这几组边界重新对齐。

1. 看第 1、2 章，重新确认 Trellis 到底解决了什么问题。
2. 看第 6 章和第 7 章，把“工作流怎么走”和“Spec 为什么重要”重新接起来。
3. 看第 9 章和 FAQ，把最容易混的命令时机再过一遍。

1. 先回看“一页总结”里的命令顺序。
2. 再看 \(start 和 \)finish-work 两段，确保自己不会把开始和收尾时机搞反。
3. 如果这次任务跨度大，再补看 /trellis:parallel 和“名词小字典”里的 worktree、PRD、Spec。

如果我只能记一句话，就记这个：先分清这次做什么，再分清按什么规矩做，最后分清怎么把结果留在项目里。