很多开发者第一次使用 Claude Code 时，会被它的执行速度震撼。只要输入一句“帮我做一个登录功能”“重构这个模块”“加一个订阅系统”，它就能快速扫描项目、生成代码、修改文件甚至运行测试。但真正落地到复杂项目后，问题也很快暴露出来：AI 不是不会写代码，而是太容易在错误假设上写出一堆看似正确的代码。

这正是 grill-me + Trellis 工作流想解决的问题。它不是让 AI 更快开始编码，而是先把“是否该这样做”问清楚，再把已经确认的结论固定到项目任务里。对复杂功能、多文件改造、架构调整和长期维护项目来说，这一步往往比直接开写更重要。

一、AI 编程最大的问题不是慢，而是理解偏差

在传统提示词流程里，开发者通常会给 AI 一段需求，然后期待它直接实现。小任务这样做没问题，比如写一个排序函数、补一个 loading 状态、修一个 CSS 样式。但当任务变成“重构权限模块”“新增计费系统”“改造订单状态机”时，需求中往往存在大量未说出口的假设。

例如，同样是“新增订阅功能”，至少会牵涉这些问题：订阅是按用户还是按团队计费？是否支持试用期？过期返回 401 还是 403？续费失败是否保留宽限期？历史订单是否需要迁移？这些问题没有提前回答，AI 就会自己补全假设。一旦假设错了，代码越写越多，返工成本也越高。

grill-me 的核心价值就在这里。它不会让 AI 立刻进入实现，而是让 AI 先“拷问”需求，把模糊点逐个拆开。AIHero 对该 Skill 的介绍中也提到，它会持续提问直到达成共同理解，并在早期编码阶段帮助发现需求细节。

二、grill-me：把需求澄清变成标准动作

grill-me 本质上是一个很短的 Claude Code Skill。官方 GitHub 文件显示，它的 SKILL.md 只有 10 lines、7 loc、635 Bytes，却定义了一个非常强的工作习惯：围绕计划或设计持续访谈，逐条解决决策树上的依赖问题，并且一次只问一个问题。

安装命令也很简单：

npx skills@latest add mattpocock/skills

一个可复用的简化版 Skill 思路可以这样写：

name: grill-me
description: Stress-test a plan or design before coding.

Ask one question at a time.
Explore the codebase when the answer can be found there.
For each question, give your recommended answer.
Summarize the confirmed decisions before implementation.

实际使用时，开发者可以先给 Claude Code 一个很粗略的需求：

我要给现有 SaaS 项目增加订阅功能。先不要写代码，请用 grill-me 的方式拷问我，直到需求、边界和验收标准都清楚。

理想情况下，AI 不应该马上创建数据库表，而应该开始追问：

订阅主体是 user 还是 workspace？
免费试用是否需要单独状态？
支付失败后是否保留 grace period？
已有权限校验逻辑在哪里？
接口失败时前端显示什么状态？

更关键的是，grill-me 要求 AI 在提问时给出推荐答案。这样开发者不是从空白开始解释，而是在一个具体建议上做判断。例如：“我建议订阅主体绑定 workspace，因为团队协作产品通常按工作区计费，这样是否符合你的产品模型？”这种方式明显降低了沟通负担。

三、Trellis：把讨论结果变成任务真相源

仅有需求拷问还不够。很多 Claude Code 翻车不是发生在第一轮理解阶段，而是发生在长会话执行过程中。前面说好的约束，后面忘了；一开始确认的命名，后面又改了；原本只改一个模块，最后影响了三个无关目录。

Trellis 的作用就是把这些信息从聊天上下文里拿出来，沉淀成项目文件。官方文档显示，执行 trellis init 后，项目会生成 .trellis/ 核心目录，里面包含 workflow.md、config.yaml、spec/、workspace/ 和 tasks/ 等结构。tasks 目录下的单个任务还能继续包含 task.json、prd.md、info.md、implement.jsonl、check.jsonl、research.jsonl 等文件。

典型结构如下：

.trellis/
├── workflow.md
├── config.yaml
├── spec/
│   ├── frontend/
│   ├── backend/
│   └── guides/
├── workspace/
│   └── {developer-name}/
│       └── journal-N.md
└── tasks/
    └── {MM-DD-task-name}/
        ├── task.json
        ├── prd.md
        ├── info.md
        ├── implement.jsonl
        ├── check.jsonl
        └── research.jsonl

这套结构的意义在于：需求不是只存在于一次对话中，而是变成可审查、可更新、可复用的工程资产。后续 Claude Code、Cursor、Codex 或其他工具进入项目时，都能基于同一套任务文档继续工作。Trellis 官方 FAQ 也提到，它不是只服务 Claude Code，而是一个可跨多个 coding agents 和 IDE 使用的项目层。

四、推荐工作流：先对齐，再规划，最后执行

比较稳妥的流程可以分成四步。

第一步，用 grill-me 做需求澄清。不要一开始就让 AI 写代码，而是让它围绕目标、用户、数据模型、边界条件、错误状态、验收标准持续追问。

第二步，让 AI 输出一份决策摘要。例如：

## Confirmed Decisions

- Subscription belongs to workspace, not user.
- Trial period lasts 14 days.
- Expired subscription returns 403.
- Payment failure enters grace period for 3 days.
- Existing auth middleware should be reused.

第三步，把摘要交给 Trellis，让它生成任务结构、PRD 和验收标准：

trellis init -u your-name

然后让 AI 根据刚才的需求共识创建任务：

请基于上面的 confirmed decisions 创建 Trellis task，并生成 prd.md、info.md 和验收标准。

第四步，再让 Claude Code 开始实现。此时 AI 的任务不再是“自由发挥”，而是围绕明确的 prd.md 和 check.jsonl 去完成开发、测试和修复。

在多模型调用场景中，团队也可以把 TreeRouter 作为补充接入层，用来统一接入不同大模型接口，减少在 Claude、GPT、Gemini 等模型之间反复切换配置的成本，但真正决定产出质量的仍然是需求澄清、任务拆解和上下文沉淀。

五、这种工作流适合什么场景？

grill-me + Trellis 并不适合所有任务。写一个小函数、改一段样式、补一个简单表单，直接提示即可。它真正适合的是复杂度较高、错误返工成本较大的任务，比如权限系统、支付模块、数据迁移、架构重构、多端状态同步、跨服务 API 调整等。

它的核心思想可以总结成一句话：不要让 AI 带着错误假设高速奔跑。先让 AI 拷问你，再让任务文档约束 AI，最后才让它写代码。这样做表面上多花了十几分钟，实际上减少的是后面数小时的返工、回滚和人工审查成本。

对于正在深度使用 Claude Code 的开发者来说，真正的效率提升不是“更快生成代码”，而是建立一套可重复的协作流程。grill-me 负责把问题问透，Trellis 负责把共识落盘，Claude Code 负责按边界执行。三者组合起来，才更接近严肃工程项目中可持续使用的 AI 编程工作流。