圈圈这是篇内部分享。我自己从 vibe coding → Superpowers → GSD → vibe coding → Trellis 绕了一大圈，终于觉得找到了顺手的路子。下面是我现在的判断和具体做法，希望大家也能用起来。
一、为什么 AI 在前端开发里总差点意思？
这个问题我一直在纠结，现在的 AI ，不论是 Gemini、Claude，为啥 UI 总是千篇一律？为何审美总是不让人满意？AI 最终到底能否生成设计师级别的界面？
AI 最擅长的是“纯逻辑”
大模型在处理有明确输入输出的事情上，确实很强：写个函数、做个算法、处理数据、设计 API、写状态机……只要你把意图说清楚，AI 基本能一次写对，而且这个代码 AI 是有判断是否成功的一套标准的，就像理科，1+1 是确定的。
前端的业务逻辑部分也一样——数据请求、状态管理、工具函数，AI 写得又快又好。
但 AI 真的“看不见”界面
前端有大量工作不是纯逻辑：布局、间距、动画、响应式、视觉层次……
这里有个根本性的问题。
图像生成模型（比如 DALL-E、Midjourney、nano banana）是用真实图片训练的，它们对像素、构图、色彩有“直觉”。但大语言模型是用代码文本训练的，它看到的永远是 padding: 11px 这串字符，从来没真正感受过 11px 和 12px 在屏幕上差了多少。
它知道“平均意义上的好看”——因为读过无数 CSS 教程和 UI 库文档——但它完全不懂像素级的视觉决策。
所以现实就是：
- 让 AI 写按钮的点击逻辑 → 很OK
- 让 AI 调整按钮的视觉细节（内边距、阴影、hover 过渡时长）→ 你得不停地说“再大一点”、“阴影淡一点”，AI 每次都是在盲猜
- 让 AI 做交互验收 → 它跑 lint 能过，但它根本不知道做出来的的 hover 动画是不是让人看着舒服，整个页面的布局是否融洽。
验收能力的天花板
这也是我放弃 Superpowers 的核心原因之一：它的质量体系建立在 TDD 上，但前端有太多东西是单元测试覆盖不到的。
UI、交互，这些必须你亲自打开浏览器，点一遍看看。AI 帮你跑 typecheck 当然好，但别指望它能替你做视觉验收。
我的结论：在前端，AI 是超强的逻辑实现引擎，但不是视觉判断者。我们的工作流得建立在这个认识上，别假装 AI 什么都能干。
二、更深的问题：AI 其实不会“写代码”
这话似乎有点“过分”，AI 不是一直在帮我们写代码吗？但我觉得是事实。
AI 确实能写出“语法对、功能能用”的代码片段。但工程化的能力，它基本没有：
- 没有全局观：它不知道项目里已经有一个类似的工具函数，于是又写了一个
- 没有架构判断：它不知道该把这个组件放
shared/还是features/auth/ - 没有历史记忆：两周前你们刚决定不用
useContext做全局状态，改用 Zustand，AI 不知道，下次又写 Context - 没有演化意识：它写的代码能跑，但在你们项目的约定里就是个“异类”
- 对话一结束就失忆：上一个 session 建立的所有上下文，新 session 一开全忘干净
这就是为什么 vibe coding 对个人开发者能 work（因为架构在自己脑子里），但对团队就不行——团队的知识、约定、决策不能只靠某一个人的脑子。
AI 需要的不是更聪明，而是被框在一个知识框架里，有人告诉它：这个项目的规则是什么，过去发生了什么，现在在哪个阶段，接下来该做什么。
这就是 Trellis 存在的意义。
三、为什么 Superpowers 和 GSD 没能解决问题
Superpowers
它的优点是真的：强制 AI 在写代码前先走设计流程，避免“收到需求就开写”。
但我遇到了两个硬伤：
1. 没有持久记忆。每个 session 是孤立的，设计文档、历史决策、团队约定——都不会自动带入下一次对话（除非你手动提及）。今天定的架构方向，明天的 AI 完全不知道。
2. TDD 和前端不太搭。Superpowers 的核心质量机制是测试驱动开发，但前端的验收难点不在单元测试，而在浏览器里的真实交互。强制 RED-GREEN-REFACTOR，在前端很多场景下就是浪费 token。
GSD
GSD 解决的是“context rot”——对话变长后 AI 丢失方向的问题。思路对，把工作拆小，在干净的上下文里执行。
但它本质上是个上下文管理工具，不是项目管理工具。它没回答：团队共识存在哪？规范怎么沉淀？新人怎么快速上手？多人协作怎么不踩坑？
Superpowers 和 GSD 都把 AI coding 当成“一次对话”，而 Trellis 把它当成“持续进行的工程工作”。
四、Trellis 的设计哲学：给 AI 一个可以随时加载的大脑
Trellis 的核心洞察很清晰：AI coding 本质是工作流和知识管理问题，不是聊天问题。
它由两套系统构成，共享同一批文件：
.trellis/
├── spec/ ← 团队规范库（AI 的长期记忆）
├── tasks/ ← 任务驱动的需求文档（AI 的工作上下文）
├── workspace/ ← 每个开发者的 session 日志（AI 的短期记忆）
└── workflow.md ← 工作流契约（AI 的行为边界）
整个目录通过 git 管理，是团队共享的知识资产。
每次打开新 session，AI 不是从零开始——它从文件里重新加载：你是谁、上次做了什么、项目有哪些规范、现在的任务到哪一步了。这就解决了“AI 每次都是新生儿”的痛点。
Trellis 对 AI 的约束方式也很巧妙：它不是塞一大段 prompt 告诉 AI “你应该怎样”，而是用 JSONL 精确控制每个 agent 在执行具体任务时能看到哪些上下文。
// implement.jsonl — 实现这个任务前 AI 必须先读这些文件
{"file": ".trellis/spec/frontend/component-guidelines.md", "reason": "组件规范"}
{"file": ".trellis/spec/frontend/state-management.md", "reason": "状态管理约定"}
{"file": "src/components/UserCard/", "reason": "现有组件写法参考"}
这意味着 AI 在动手之前，已经知道了这个任务需要的所有规则，而不是靠“你是一个优秀的前端开发者”这种空话。
五、我是怎么用 Trellis 的（具体步骤）
第一步：初始化（只做一次，但最重要）
npm install -g @mindfoldhq/trellis@latest
cd 你的项目
trellis init -u yourname
初始化后，AI 会分析现有代码，帮你把已有的规范提取到 .trellis/spec/ 的模板里。重点要填这几个文件：
.trellis/spec/frontend/
├── component-guidelines.md # 组件写法：函数式还是类组件、Props 规范、禁止事项
├── state-management.md # 状态管理：Zustand/Context 的使用边界
├── type-safety.md # TypeScript 规范：any 怎么处理，类型声明放哪
└── directory-structure.md # 目录结构：按功能分还是按类型分
规范质量直接决定 AI 输出质量。好的规范长这样：具体、有代码示例、有禁止项、有原因。
### 状态管理约定
**原则**：组件内状态用 useState，跨组件共享用 Zustand store，禁用 Context 做业务状态。
**原因**：Context 在大项目里容易导致非预期的重渲染，统一用 Zustand 方便调试。
**示例**
- ✅ `const { user, setUser } = useUserStore()`
- ❌ `const { user } = useContext(UserContext)`
第二步：日常任务流
打开 Claude Code → Hook 自动触发，AI 从文件里加载上下文：
Hi yourname！昨天完成了登录页（commit abc1234），
包括 LoginForm 组件、JWT 拦截器、接口对接。
今天想做什么？
描述任务 → AI 先建文档，再写代码：
“做用户资料页，支持修改头像和昵称”
AI 不会立刻写代码，而是先在 .trellis/tasks/05-20-user-profile/ 里创建：
prd.md：需求说明和验收标准info.md：技术设计（用什么组件模式、改哪些文件）implement.jsonl：本次任务要读的 spec 清单
这时候你可以介入了。看一眼 prd.md，确认 AI 理解对了需求，再让它继续。这是“面向文档开发”的核心——你审查的是意图和规则，而不是盯着 AI 一行一行写代码。
实现阶段 → AI 按 spec 写代码，你不用盯着。
前端特有的验收分工：
AI 验收：
✓ lint 通过
✓ typecheck 通过
✓ 组件结构符合 component-guidelines
✓ 状态管理符合 state-management 约定
你来验收（打开浏览器）：
□ 头像上传预览正常吗
□ 昵称输入框 focus/blur 动画流畅吗
□ 移动端布局对吗
□ 错误状态（网络失败、格式不对）显示合理吗
完成后运行 /trellis:finish-work：
AI 会自动把本次任务里发现的新规律写进 spec。比如这次做了头像上传，发现了一个通用的文件处理模式，就沉淀进去：
### 文件上传模式
选文件后用 FileReader 做本地预览，上传成功后用返回的 URL 替换本地 blob，
避免上传后二次请求。参考 AvatarUpload 组件实现。
下次任何人做文件上传相关功能，AI 都会自动遵守这个模式。
第三步：团队协作
# Alice 做完功能，spec 自动更新了
git add .trellis/spec/
git commit -m "docs: add avatar upload pattern"
git push
# Bob pull 之后，AI 自动继承 Alice 的所有规范
git pull
# /start → AI 读到最新的 spec，Bob 的代码自然和 Alice 的风格一致
每个人有独立的 workspace journal，互不干扰。Spec 变更建议走 PR，像对待代码一样认真。
六、省 token 的小技巧：RTK + CodeGraph
Trellis 本身已经通过 JSONL 精确控制上下文，但 Claude Code session 里还是有很多 token 浪费在命令输出的噪音上。配合两个工具能省不少钱。
RTK（Rust Token Killer）
原理：坐在 AI 和 shell 之间，拦截命令输出，过滤掉所有对 LLM 没用的噪音，把压缩后的结果传给 AI。
不用 RTK：
git status → 40 行输出 → AI 看到 ~2000 tokens
用 RTK：
git status → RTK 过滤 → AI 看到 ~200 tokens（“ok main, 3 modified”）
我实测过：一个 30 分钟的 Claude Code session，token 使用从约 150k 降到约 45k，省了 70%。
安装很简单，零侵入——它通过 Claude Code 的 PreToolUse hook 透明拦截，你照常用 git status，AI 自动收到压缩版：
# 安装
brew install rtk-ai/tap/rtk
# 然后在 Claude Code 里启用 hook，之后什么都不用改
省 token 最明显的场景：测试命令（只显示失败的，通过的折叠）、git diff（去掉空行和无意义变更）、ls（只显示文件名，去掉权限/时间戳）。
CodeGraph
原理：AI 探索陌生代码库时，要反复调用 grep、glob、Read 来理解结构——每次调用都消耗 token，而且 session 结束后这些“知识”全消失，下次又要重新探索。
CodeGraph 用 tree-sitter 预先把代码库解析成符号关系图（函数调用、类继承、模块依赖），存在本地 SQLite 里，通过 MCP 暴露给 AI。
不用 CodeGraph：
AI 要找 UserService 的所有调用方
→ grep、glob、Read 反复调用 52 次
→ 花 3 分钟，消耗一堆 token
用 CodeGraph：
AI 调用 codegraph_explore("UserService")
→ 一次查询，立刻返回完整调用关系
→ 94% 更少的 tool calls，速度快 77%
实测数据（跨 7 个真实开源项目）：平均节省 35% 费用、59% 更少 token、70% 更少 tool calls。
# 安装
npx @colbymchenry/codegraph init -i
# 之后每次代码变更后 sync 一下
codegraph sync
三者结合的效果
Trellis JSONL：只给 AI 本任务需要的 spec（不把整个仓库塞进去）
+
RTK：过滤命令输出噪音（git/test/ls 的冗余内容）
+
CodeGraph：代码结构查询从文件扫描变成图查询（大幅减少 explore tool calls）
↓
一个正常 session 的 token 使用能降低 60-80%
七、我的一点核心感悟：面向文档开发
在一个人 vibe coding 的那段时间，我发现一个有意思的现象：即使没有任何工具辅助，只要我脑子里有清晰的架构，通过对话也能做出质量不错的代码。
但这个“脑子里的架构”没法传给团队，也没法传给下一个 AI session。
所以我越来越觉得，在 AI coding 时代，文档的重要性已经超过了代码本身：
- 代码是文档的执行结果，AI 可以从文档生成代码
- 但文档需要人来定义、审查、维护
- 文档错了，代码就错；文档准确，代码就对
我们的工作模式可以变成：
我们定义文档（需求、规范、架构决策）
↓
AI 根据文档生成代码
↓
我们审查：文档是否准确？代码是否符合文档？
↓
发现新规律 → 更新文档 → 下次 AI 自动遵守
Trellis 把这个循环工程化了。.trellis/spec/ 是活文档，随着每次任务结束自动更新；.trellis/tasks/ 是需求文档，开发前先有文档再有代码；workflow.md 是工作流契约，约束 AI 在什么阶段做什么。
我们不再是写代码的人，而是定义规则、审查规则、保持规则更新的人。
这不是让我们变懒——而是把时间花在机器做不好的地方：架构判断、视觉决策、交互验收、规范制定。这些才是前端工程师真正的价值。
八、给团队的一点建议
现在就可以做的：
- 找一个项目
trellis init，把现有规范整理进.trellis/spec/ - 装 RTK，Claude Code session 立刻省钱
- 仓库大的话考虑加 CodeGraph，减少探索成本
值得养成的习惯：
- 每次
finish-work的时候认真看 AI 提议更新哪些 spec，这是知识沉淀的关键时刻 - Spec 变更走 PR，像对待代码一样对待规范
- 新功能开始前先看
prd.md，而不是直接看代码
需要调整的预期：
- AI 验收 lint/typecheck，人工验收交互体验——这个分工很合理，别指望 AI 替你点浏览器
- Spec 写得越细，AI 越听话；写得越模糊，AI 越凭感觉——投入写规范是 ROI 最高的事情
附：工具清单
| 工具 | 作用 | 安装 |
|---|---|---|
| Trellis | 项目 wiki + AI 工作流约束 | npm install -g @mindfoldhq/trellis |
| RTK | 过滤命令输出噪音，省 60-90% token | brew install rtk-ai/tap/rtk |
| CodeGraph | 预索引代码关系图，减少 explore tool calls | npx @colbymchenry/codegraph init -i |
以上基于 Trellis v0.5、RTK v0.28、CodeGraph 最新版，详细可参考 docs.trytrellis.app