Grill与Trellis协作：从需求澄清到原子化任务拆解的AI工作流实践

背景

在 AI 辅助编程的实践中，开发者常面临两个核心痛点：一是 AI 往往急于生成代码，缺乏对需求边界、架构决策和领域术语的深入澄清，导致生成的代码与真实业务场景脱节；二是任务管理混乱，缺乏从“模糊需求”到“原子化任务”再到“代码实现与验证”的标准化闭环。

LINUX DO 社区分享了一套结合 grill-doc-me 技能与 Trellis 工作流的个人开发工作流。该工作流旨在通过 grill 阶段进行深度的需求澄清与架构决策（Plan），再通过 Trellis 进行任务拆解、执行与验证（Implement/Verify），从而将“人脑的架构决策”与“AI 的长上下文执行能力”解耦。用户只需扮演 Technical Lead 的角色，负责技术选型和代码 Review，而将繁琐的上下文管理和代码实现交给 AI。

核心内容

该工作流主要包含环境初始化、需求澄清、任务移交与创建、以及 Trellis 执行流程四个阶段。

1. 环境初始化

首先需要在项目中安装并初始化 Trellis 和 grill-doc-me 技能：

• 安装 Trellis：通过 npm 全局安装 @mindfoldhq/trellis。
• 初始化项目：在项目根目录运行 trellis init -u yourname --claude，生成 .trellis 文件夹，其中包含 specs、tasks、workspace 等结构。
• 安装技能：将 grill-doc-me 技能放入 .claude/skills/ 文件夹。
• 初始规范：初始化后建议立即运行 00-bootstrap-guidelines 任务，完善项目的 spec 规范，记录真实的架构决策，避免推测性架构。

2. 需求澄清 (使用 grill-doc-me)

此阶段的核心是利用 grill-doc-me 与 AI 进行多轮对话，澄清模糊需求。

• 交互方式：用户输入模糊需求（如“写一个 FastAPI 后端接口”），AI 会主动提出关于技术栈、边界条件、异常处理等具体问题。
• 决策过程：用户回答 AI 的提问（如选择异步 SQLAlchemy、定义数据缺失时的 400 错误响应等）。
• 目标：直到所有边界条件确认完毕，生成 CONTEXT.md 和 docs/adr 文件，确立领域术语和架构决策。

3. 移交与任务创建 (Handoff to Trellis)

当需求完全清晰后，通过特定指令将上下文移交 Trellis，将其拆解为原子化任务。分享者提供了三种不同粒度的提示词策略：

• 简洁版：直接要求 AI 将方案拆解为 3-5 个原子化任务，生成在 .trellis/tasks/ 目录下，每个任务包含前置条件、实现步骤和验收标准。
• 细化版：要求 AI 扮演 trellis-brainstorm Planner，输出共识总结、6-12 个任务分解（含 Slug、Objective、Acceptance Criteria），并提供可直接运行的 task.py create 命令。
• 标准版（推荐）：
  1. 读取资产：AI 需读取 CONTEXT.md、docs/adr/ 及现有代码。
  2. 垂直切片拆分：禁止按技术层拆分（如“实现整个 MVP”），必须拆分为能独立验证、工作量 0.5-1 天的垂直切片。
  3. 可测验收标准：每个任务需有 3-6 条可测标准（如“POST /x 传 A 返回 B”），而非仅验证文件存在。
  4. 依赖排序：后端/数据层在前，前端在后。
  5. 先方案后执行：AI 先输出拆分表供用户 Review，确认后再执行创建命令，建立父任务（史诗）和子任务结构。

4. Trellis 工作流执行

任务创建完成后，进入执行阶段：

• 激活任务：使用命令 python3 ./.trellis/scripts/task.py start $TASK_DIR 激活特定任务。
• 核心控制指令：
  • /trellis-brainstorm：完善 Task 的 PRD。
  • /trellis:continue：推进工作，最常用的指令。
  • /trellis:finish-work：任务完成后执行，用于写 Journal、归档任务、更新 spec，这是保持长期记忆的关键。
• 结束流程：Commit 代码 -> 执行 /trellis:finish-work -> Review Journal -> 定期 Commit CONTEXT.md、.trellis/spec/、ADR 到 Git。

5. 操作总结

• 想需求：claude -> /grill-me [一句话模糊需求]。
• 做决策：回答 AI 的单选题/判断题，直到需求清晰。
• 建物化：AI 将方案写入 .trellis/tasks/xxx/prd.md。
• 放手干：用户按依赖顺序认领任务，AI 自动执行 start -> implement -> check -> update-spec -> commit -> finish-work。

关键要点

• 解耦人与 AI 的职责：用户专注于做 Technical Lead（技术选型、Review、决策），AI 负责长上下文管理、代码实现和细节执行。
• 拒绝模糊任务：任务拆分必须遵循“垂直切片”原则，每个任务必须是“一次能验收”的独立单元，避免“搭骨架”、“实现整个 MVP”等大而无当的任务。
• 验收标准可测：验收标准（Acceptance Criteria）必须极度具体，包含正常路径、边缘案例、测试要求和安全/性能要求，确保 Verify 阶段能真实跑通。
• 上下文一致性：所有任务必须严格遵循 CONTEXT.md 中的领域术语和 docs/adr/ 中的架构决策，确保代码与前期设计一致。
• 迭代式澄清：利用 grill-doc-me 的“无情采访”（relentless interview）风格，通过多轮问答消除需求歧义，避免 AI 因信息不足而错误编码。
• 记忆与归档：/trellis:finish-work 不仅是结束任务，更是更新项目长期记忆（Journal、Spec、ADR）的关键步骤，确保后续对话能基于最新状态进行。
• Trellis 版本优化：最新版本的 Trellis (0.6.5+) 强化了 brainstorm 的 lossless PRD convergence gate 和 auto-injected context，使得类似 grill-me 的需求澄清更加可靠，部分场景下可跳过显式的 Grill 步骤。

意义与影响

这套工作流的价值在于它提供了一套可复用的、标准化的 AI 编程工程化方案。

1. 提升代码质量与一致性：通过强制性的需求澄清和架构决策记录（ADR），解决了 AI 编程中常见的“幻觉”和“上下文丢失”问题，确保生成的代码符合业务逻辑和技术规范。
2. 降低认知负荷：开发者无需记忆复杂的命令行参数或维护庞大的 Prompt，只需关注核心决策和验收结果，极大地降低了使用 AI 辅助开发的门槛。
3. 增强可维护性：通过生成详细的 PRD、Journal 和 Spec，并将代码与文档同步 Commit，使得项目具有更好的可追溯性和可维护性，便于团队协作和后期迭代。
4. 推动 AI 编程范式转变：从“直接生成代码”转向“先规划、后执行、再验证”的工程化范式，强调了人在环中（Human-in-the-loop）的决策作用，代表了当前 AI 辅助编程的最佳实践方向。