Grill x Trellis：让 AI 真正干活的团队开发工作流#

3.1 一句话定位#

grill-me（GitHub: mattpocock/skills）是 Matt Pocock 那套 “Skills for Real Engineers” 里的一个轻量 Skill。整套 Skills 的口号是 “not vibe coding”（拒绝凭感觉编码），而 grill-me 是其中最纯粹、最核心、也最受欢迎的一个。

Grill 的字面意思就是”烤架”——引申为”严加盘问”。

它做的事可以用一句话概括：在 AI 动手写任何代码之前，先让它反过来盘问你，一个问题一个问题地问，沿着决策树的每一个分支往下钻，直到每一个含糊的地方都被钉死。

grill-me 这个 Skill 本身极其精简——它底层调用的 /grilling，核心 Prompt 只有这么几行：

1
Interview me relentlessly about every aspect of this plan
2
until we reach a shared understanding. Walk down each branch
3
of the design tree, resolving dependencies between decisions
4
one-by-one. For each question, provide your recommended answer.
5

6
Ask the questions one at a time, waiting for feedback on each
7
question before continuing.
8

9
If a question can be answered by exploring the codebase,
10
explore the codebase instead.

翻译过来就是四条铁律：

1. 逐个问，别一次抛一堆——一次一个问题，等你回答了再问下一个。Matt 原话：“Asking multiple questions at once is bewildering”（一次问一堆会让人懵）；
2. 每个问题都给推荐答案——不是干巴巴地问，而是带着 AI 自己的判断问，你来拍板；
3. 沿着决策树往下钻——不是随机提问，而是按决策之间的依赖关系一个个解决，前面的不钉死，后面的没法谈；
4. 能看代码就别问人——能从代码库里查到的，AI 自己去查，别拿这种问题烦你。

3.2 为什么这招这么管用#

你可能会问：我自己写 PRD 不也是在澄清需求吗？为什么要让 AI 来盘问我？

因为人有一个致命弱点：我们以为知道自己想要什么，其实并不知道。

当你自己写需求文档时，你会本能地跳过那些”感觉很明显”的细节。但 AI 不知道你的”感觉”，它只能根据你写下来的字面意思干活。那些被你跳过的含糊地带，就是 AI 翻车的雷区。

让 AI 反过来盘问你，本质上是强迫你把脑子里的隐性知识显性化。每被问住一次，就排掉一颗雷。

举个真实场景。需求是”做一个积分系统”，你觉得自己说得很清楚了。但 /grill-me 会这么问你（每个问题都带着它的推荐答案）：

1
AI: 我们要做的"积分"，是指可消费的虚拟货币，
2
    还是不可消费的等级积分？
3
    我倾向前者——因为你说的是"积分系统"，通常隐含可兑换。
4
    请确认。
5

6
你:  对，是可消费的。
7

8
AI: 那积分会被消耗在哪些场景？充值？兑换商品？打赏？
9
    我推荐先只支持"兑换商品"，其他后续迭代。
10
    这样切片最小，能最快验证。
11

12
你:  兑换商品 + 打赏，这两个都要。
13

14
AI: "打赏"是指用户之间转移积分对吧？
15
    那并发场景下，如果 A 和 B 同时给 C 打赏，
16
    C 的余额该怎么算？是按事务先后扣减，
17
    还是允许短暂超扣再用对账兜底？
18
    我推荐事务先后扣减——简单，且不会超扣。
19
    但这会要求打赏走强一致性路径。
20
    请确认。
21

22
你:  ……（被问住了，这确实没想过）

注意第三问——这就是 grill-me 的价值所在。你原本以为”做一个积分系统”很清楚，但并发打赏的扣减语义这种关键细节，你不被问就根本想不起来。而一旦没想清楚，AI 自己脑补一个实现，上线后就是 bug。

3.3 它和 Trellis 的 brainstorm 有什么不一样#

熟悉 Trellis 的同学可能会问：Trellis 不是也有 /trellis-brainstorm 做需求澄清吗？为什么要再引入 grill-me？

两者定位确实重叠，但纪律强度不一样：

说白了，/trellis-brainstorm 是温和的需求收敛，目标是”把 MVP 圈出来”；grill-me 是严苛的逐点拷问，目标是”把每个含糊处逼到非黑即白”。

我的建议是两者都能用，按需求复杂度选：

• 简单需求、边界清晰 → 直接用 Trellis 的 brainstorm，快；
• 复杂需求、或者你隐约觉得”哪里没想透” → 上 grill-me，盘问到清爽为止。

4.1 一张图看清分工#

一句话：grill-me 管的是”动工前”，Trellis 管的是”动工后”。中间的交接点，就是盘问结束后凝练出的那份对齐共识（你可以把它直接写成 PRD 喂给 Trellis）。

4.2 流程的接力点#

grill-me 的妙处在于：它本身很轻，只产出”对齐共识”，不绑定任何后续流程。 这反而让它能完美地嵌进 Trellis 的任务生命周期，当那个”动手前”的对齐环节：

关键洞察：grill-me 把”需求到底对不对”这件事在动手前解决掉，Trellis 接手时拿到的就是一个”已经对齐过、没有含糊地带”的需求。Trellis 的 Spec 约束”代码长什么样”，grill-me 保证”需求本身没问题”——两者叠加，AI 才既不会跑偏，又不会乱写。

4.3 为什么这个组合比单用任何一个都强#

单用任何一个都有明显的洞。组合起来，从”想清楚”到”做稳定”全链路没有断点。

5.1 第 0 步：一次性环境准备#

1
npx skills@latest add mattpocock/skills

1
trellis init -u yourname

5.2 第 1 步：盘问对齐（grill-me 主场）#

现在来了一个需求：“做一个用户积分系统”。别急着让 AI 写代码，先盘问。

1
/grill-me

接下来你会经历一场”灵魂拷问”。AI 会一个一个地问你，沿着决策树往下钻。大致会是这样的节奏（每个问题都带着它的推荐答案，你只需确认或修正）：

这一步结束，你得到的是一份”被盘问得清清楚楚、所有含糊地带都钉死”的需求共识。

这一步是 Trellis 从来没帮你做过的，而它恰恰是团队里 A 同学和 B 同学产出质量差距的根源——A 同学脑子清楚、自己能把需求想透，B 同学需要被逼着才能想透。grill-me 把 A 同学的”想清楚”能力，变成了一套所有人都能照着走的纪律。

5.3 第 2 步：把对齐共识写成 PRD（交接给 Trellis）#

grill-me 本身不产出文件，它只产出”对话里的共识”。盘问完之后，你需要把这份共识固化成 Trellis 能消费的 prd.md。

两种做法：

• 手写：照着盘问记录，把决策整理成 PRD（适合关键需求，你想自己把关）；
• 让 AI 综合：直接在同一会话里说”把刚才盘问的所有结论整理成一份 PRD”，AI 会综合整个对话生成。

PRD 长这样：

1
# 营销活动报表（限时满减 / 限时折扣）
2

3
> 本 PRD 记录需求与验收标准。技术设计见 `design.md`，执行计划见 `implement.md`（复杂任务，二者在 `task.py start` 前补齐）。所有决策来自一轮 grill-me 对齐会议，已逐项确认。
4

5
---
6

7
## 一、背景
8

9
现有营销域只有「活动管理」（增删改查）和活动详情页的 3 个汇总数（订单数 / 成交额 / 优惠额，来自 T+1 汇总表 `kj_promotion_statistics`）。**缺少跨活动横向对比和单活动纵向复盘能力**，运营无法回答"这批活动哪个效果好""某个活动里哪些商品卖得最好"。
10

11
本任务为「限时折扣」(type=1) 和「满减活动」(type=2) 两种活动补齐**活动报表**，分两层：跨活动汇总对比 + 单活动下钻复盘。
12

13
---
14

15
## 二、对齐决策（grill-me 共识，9 项）
16

17
---
18

19
## 三、功能需求
20

21
---
22

23
## 四、接口清单（6 个）
24

25
---
26

27
## 五、关键约束（口径与一致性）
28

29
---
30

31
## 六、改动范围（预计 ~12 文件，全部新增、零侵入现有逻辑）
32

33
---
34

35
## 七、验收标准
36

37
**功能**
38

39
**口径**
40

41
**工程**
42

43
**性能**
44

45

46
---
47

48
## 八、明确不做（v2 backlog）
49

50
---
51

52
## 九、依赖与风险
53

54
---
55

56
## 十、后续步骤（交接给 Trellis 执行流程）

注意：PRD 里的每一条决策，都是刚才被 grill-me 钉死过的，不是凭感觉写的。 这就是盘问的价值——你的 PRD 从”我以为我想清楚了”变成”我真的被逼着想清楚了”。

5.4 第 3 步：进入 Trellis 任务流（Trellis 主场）#

PRD 写好后，接力棒正式交给 Trellis。这一步开始就是我上一篇讲过的流程：

1
trellis start  # 或 /trellis:continue

Trellis 会自动：

1. 创建 task.json，记录任务元数据（状态、负责人、分支）；
2. 创建 Git Worktree，把这个任务隔离到独立分支，多人/多 Agent 并行不踩脚；
3. 注入 implement.jsonl 定义的所有 Spec 文件——Controller 规范、错误处理规范、日志规范、返回格式规范……全部喂给 AI；
4. 创建 Journal，开始记录本次会话。

到这一步，AI 同时被两样东西托着：

• grill-me 盘问出来的对齐共识（写进了 PRD，AI 知道”要做什么”）；
• Trellis 的 Spec（AI 知道”代码长什么样”）。

意图 + 规范，一起喂给 AI。 这就是为什么组合比单用强——单用 Trellis，AI 知道”怎么写”但不知道”写什么是对的”；单用 grill-me，AI 知道”写什么”但没有规范兜底。两个一起，意图和规范都齐了。

5.5 第 4 步：实现 + 质量检查 + 归档（Trellis 主场）#

实现、检查、归档这几步全是 Trellis 的强项，我上一篇详细讲过，这里简单带过：

1
# 编码时，Trellis 已注入 Spec，AI 自动按规范写
2
# （不用再重复说"用 MyBatis-Plus""日志用 Slf4j""返回 Result<T>"——都在 Spec 里了）
3

4
/check-backend    # Spec 合规检查：目录结构、异常处理、日志、返回格式逐项过
5
/finish-work      # 触发 AI Code Review + Spec 合规
6
/record-session   # 归档，生成 Journal

如果上线后发现 bug，用 Trellis 的 /break-loop 做根因分析——它会分析”为什么之前的修复失败了”，然后把经验沉淀回 Spec。下次换个人、换个会话，不会再踩同一个坑。

6.1 第一阶段：建立共享基座（1-2 周）#

团队推广的第一步，不是让所有人学会所有 Skill，而是建立共享的知识基座。对这套组合来说，共享基座只有一个——Trellis 的 Spec：

1
仓库根目录
2
└── .trellis/
3
    └── spec/               ← 技术规范（团队共建，随仓库版本化）
4
        ├── shared/
5
        │   └── index.md    ← 跨技术栈通用规范
6
        └── backend/
7
            ├── index.md
8
            ├── database-guidelines.md
9
            ├── error-handling.md
10
            └── ...

这里要特别说明：Matt 那套 Skills 里还有个 grill-with-docs 会额外沉淀 CONTEXT.md（业务术语）和 ADR（架构决策）。但我们这次只用 grill-me，它不产出任何文件，所以团队共享基座就只有 Trellis 的 Spec 这一份。这样反而更简单——团队只需要维护一个 .trellis/spec/，心智负担低，推广阻力小。

Trellis 官方文档把这一步叫”团队共享标准”：Spec 随仓库一同版本化，个人总结的规则与流程可以直接成为整个团队的基础设施。

这一步要做的：

• 拉一次全团队的工作坊，把团队现有的编码规范迁移进 .trellis/spec/；
• 约定 Spec 的分层结构（shared / backend / frontend）；
• 让每个人 trellis init 接入，跑通第一个需求。

这一步的价值是”拉高全员基线”——以后不管谁用 AI，喂进去的规范基座都是一样的。这是推广能成立的地基。

6.2 第二阶段：统一工作流（2-4 周）#

基座建好后，约定一套所有人都遵守的工作流。核心就两条纪律：

1
团队统一工作流（建议贴在团队 wiki）
2

3
任何非 trivial 的需求，都必须走这条主线：
4

5
  1. /grill-me           ← 动手前盘问对齐（不许跳过）
6
  2. 把共识写成 prd.md    ← 固化盘问结果
7
  3. trellis start        ← 进 Worktree，注入 Spec
8
  4. implement            ← AI 按对齐需求 + Spec 写代码
9
  5. /check-backend       ← Spec 合规检查
10
  6. /finish-work         ← 归档
11

12
trivial 的小修小改（改个文案、调个配置）可以跳过 grill-me。
13
判断标准：这个改动有含糊地带吗？有就别跳盘问。

推广时最常见的两个反对意见，我都帮你准备好反驳：

• “盘问太慢了，直接写不是更快？” → 反驳：你省下的是盘问的 30 分钟，赔上的是返工的 3 小时。盘问是把返工成本前置。而且 grill-me 每个问题都带推荐答案，你大多数时候只需点头，没你想的那么慢。

• “我们团队用 Cursor / Codex，不是 Claude Code，能用吗？” → 这正是这套组合能推广的命门，见下一节。

6.3 第三阶段：不挑平台，这才是能推广的关键#

这一点必须单独拎出来讲，因为它是能不能推广成功的命门。

团队里一定有人用 Claude Code，有人用 Cursor，有人用 Codex，有人用 Gemini。如果工作流绑死一个平台，推广必败。

而 grill-me 和 Trellis 恰好都不挑平台：

这意味着：团队里 A 用 Claude Code、B 用 Cursor，他们读的是同一份 Spec、同一份 PRD，盘问走的是同一套 grill-me 纪律。 换工具不影响产出，这才是能推广的基础。

Trellis 官方文档的原话：

同一套 Trellis 结构覆盖 16 个 AI coding 平台。.trellis/ 下的核心概念跨平台一致，差异仅在于 command、skill、sub-agent、hook 的交付方式。

1
┌──────────────────────────────────────────────────────────┐
2
│                  团队的共享层（和平台无关）              │
3
│                                                          │
4
│              .trellis/spec/  （技术规范）                │
5
│                    │                                     │
6
│                    │  + grill-me 纪律（运行时，不挑平台  │
7
│                    │                                     │
8
│         任何人、任何平台都能用                           │
9
│                    │                                     │
10
│     ┌──────────┬───┴────────────┬───────────┐            │
11
│     ▼          ▼                ▼           ▼            │
12
│  Claude     Cursor           Codex       Gemini          │
13
│  Code                                        等 16 个    │
14
└──────────────────────────────────────────────────────────┘

注意一个细节：grill-me 是运行时纪律，它不往仓库里写东西，所以它本身不需要”团队共享”——每个人在自己机器上装一份就行。真正需要团队共享的只有 .trellis/spec/，而它是纯 Markdown，跟着 git 走。这让推广变得异常干净。

6.4 团队落地检查清单#

最后给一份可直接用的团队落地清单：

• .trellis/spec/ 覆盖了团队的主要技术栈，且随仓库版本化
• 团队 wiki 写明了统一工作流（6 步主线）
• 每个成员都在自己机器上装好了 grill-me 和 Trellis
• 至少跑通一个完整需求（从 grill-me 到 finish-work）
• PR 模板里加一句：“本需求是否经过 grill-me 盘问对齐？”
• 新人 onboarding 文档里有这套流程的说明
• 定期 review Spec 是否需要更新（项目演进后 Spec 要同步）

7.1 优势#

7.2 局限#

7.3 什么时候不该用#

别为了用而用。以下场景，这套组合反而拖累：

• 一次性脚本、原型 —— 盘问和 Spec 都是负担，直接 vibe coding；
• 单人小项目 —— Trellis 的 Worktree/Task 状态机是过度设计，光用 grill-me 盘问就够了；
• 需求极度明确的小改动 —— 改个文案、调个阈值，别走六步流程；
• 团队对 AI 还很陌生 —— 先让每个人用好单会话 Claude Code，再谈团队工作流。