Trellis 小白入门：让 AI 先计划再改项目

先用人话理解 Trellis#

不用 Trellis 时，你和 AI 的对话很容易变成这样：

1
你说一个想法。
2
AI 马上开始改。
3
改到一半发现需求没说清。
4
下一轮又忘了前面为什么这么做。

Trellis 想解决的是这个问题。它让 AI 做项目前先停一下：

1
先确认要做什么。
2
再写成 task。
3
再讨论方案。
4
确认后再实现。
5
做完后检查。
6
最后把有长期价值的经验沉淀下来。

它不是让流程变复杂，而是减少“边想边乱改”的成本。

什么时候不用 Trellis#

下面这些事通常不需要建 Trellis task：

判断标准可以很朴素：

1
会改项目文件、会持续多轮、需要验收、经验以后还会用到 -> 用 Trellis。
2
只是问一句、查一下、解释一下 -> 不用 Trellis。

最常用的几句话#

日常不用背命令，先会用自然语言调度 AI 就够了。

Planning 阶段怎么聊#

Planning 阶段的目标不是写代码，而是把“要做什么”说清楚。可以直接复制这段：

1
请按 Trellis 进入 planning 阶段。现在先不要实现。
2
你先帮我澄清目标、范围、验收标准和风险。
3
一次只问我一个关键问题。
4
需求清楚后，请给我 2-3 个执行方案，并说明每个方案的成本、风险和适用场景。
5
等我确认方案后，再写 prd.md；如果任务复杂，再补 design.md 和 implement.md。

讨论时按这个顺序来：

Trellis 会写哪些文件#

记住分工：

1
task 里放“这次任务”的东西。
2
spec 里放“以后也要遵守”的东西。
3
workspace 里放“这次会话发生了什么”。

官方 Trellis 和项目规则怎么分工#

现在应以官方 Trellis 为主。项目本地规则只是补充这个项目自己的习惯。

如果项目里有 .trellis/spec/guides/，它应该是本地规则入口，而不是第二套 Trellis 流程。

不要让 AI 把这些旧入口当成日常操作：

1
恢复旧规则层
2
运行旧的 overlay 恢复脚本
3
用旧的全局 bootstrap skill 接管官方流程
4
用 obsidian-vault-ai-rules 作为中间入口

Skill 分工可以继续看 Trellis Skill 分工。

新项目和旧项目#

新项目从 0 开始：

1
cd <project-path>
2
trellis init --codex -u <user> --skip-existing -y

旧项目升级前先预览：

1
cd <project-path>
2
trellis --version
3
trellis update --dry-run --migrate

如果 dry-run 显示已经最新：

1
✓ Already up to date!

就不要再折腾旧规则恢复。只需要让 AI 检查官方状态和项目本地规则：

1
请检查这个项目的 Trellis 官方状态和项目本地规则。

常用命令可以继续看 Trellis 命令速查。

一个完整例子#

你想让 AI 修一个比较复杂的 bug，可以这样开始：

1
我要修复 UniversalRadialMenu 冷启动时菜单不显示的问题。
2
请按 Trellis 流程创建 task，先进入 planning 阶段。
3
现在不要实现，先问我一个关键问题，确认目标、范围和验收标准。

AI 应该先做这些：

1. 判断这不是普通聊天，应该建 task。
2. 问一个关键问题，例如“这次只修冷启动显示，还是也要改动画和快捷键？”
3. 把确认后的目标写进 prd.md。
4. 如果复杂，再写 design.md 或 implement.md。
5. 等你确认后再开始改文件。

做完后再说：

1
请按 Trellis check 验收。
2
如果这次修复产生了以后也要遵守的规则，请写进 .trellis/spec。
3
最后按 finish-work 收尾。

最终记忆卡#

1. 小事不用 Trellis，正式改项目才用。
2. Trellis 的第一步是讨论清楚，不是马上写代码。
3. prd.md 管这次任务，.trellis/spec/ 管长期规则。
4. 官方 Trellis 管流程，项目本地规则只补充习惯。
5. 做完一定要检查和沉淀，不要只停在“我改好了”。