接上篇，这篇继续分享 Grok Build 的几个任务管理技巧。

如果平时只是让 Grok Build 改一个小功能，可能感觉不到这些功能的价值。

但任务一复杂，尤其是需要连续执行多个步骤、同时处理多个需求时，队列、计划、分支任务、后台任务这些能力就非常有用了。

使用队列

Grok Build 正在执行任务时，我们依然可以继续输入新的提示词。

新发送的提示词默认不会立即打断当前任务，而是先进入等待队列：

也就是说，你不用等当前任务全部完成之后，再输入下一个需求。

比如 Grok Build 正在修改代码时，你突然想到还有一个地方需要调整，就可以先把需求发出去，让它排队等待执行。

队列右边还提供了立即发送和取消操作。

如果这个需求比较紧急，可以立即发送；如果发现刚才的需求写错了，也可以直接取消。

这个设计还是挺实用的，尤其是连续开发的时候，可以减少不少等待时间。

查看进度

遇到复杂任务时，Grok Build 一般不会一上来就埋头改代码，而是会把整个任务拆解成多个步骤执行。

通过右上角的任务入口，就可以查看当前任务进度：

左边会展示当前任务拆解出来的所有步骤，以及每一步的执行状态，这样 Grok Build 现在做到哪一步、还有哪些事情没做，基本一眼就能看到。

相比一直盯着终端输出，我觉得这种方式直观很多。

特别是执行时间比较长的任务，不至于让人产生一种假死的感觉。

使用计划模式

如果任务比较复杂，我一般不建议直接让 AI 上来就改代码。

可以先进入计划模式，让 Grok Build 只分析问题、设计方案和拆解任务，暂时不要修改代码。

Grok Build 提供了两个相关命令：

通过 /plan [description] 输入具体的任务，使用 /view-plan 查看当前任务计划。

我觉得这个功能特别适合重构、复杂 Bug、跨多个模块修改这类任务。

先看看它准备怎么改，确认整体方向没问题之后再让它动手，可以减少 AI 一通乱改的概率。

分支任务

如果突然有一个任务和当前会话不是完全一回事，或者想针对同一个问题尝试另外一种方案，可以使用 /fork 命令：

有意思的是，/fork 会基于当前会话创建一个新的分支。

最大的好处就是，原来的上下文可以直接继承过去，但是后续操作不会污染当前会话。

比如当前会话已经讨论了很久，你现在想：

  • 尝试另外一种实现方案；
  • 验证一个新的思路；
  • 临时排查另外一个问题；
  • 对比两套不同的解决方案。

这种情况下，就可以直接 /fork 一个分支出去折腾，折腾失败了也没关系，主会话还是原来的主会话。

不打断任务进行提问

Grok Build 也学习 Claude Code，提供了一个很好用的 /btw 命令。

它可以让你在不打断当前任务执行的情况下，对当前会话临时提问：

比如 Grok Build 正在修改一个比较复杂的功能，这时候你可以顺手问它：

/btw 现在执行到哪一步了？

或者：

/btw 为什么这里要使用这种实现？

它回答你的问题之后，原来的任务还能继续执行。

这个功能我觉得很好用，以前 AI 干活的时候，要么等它做完，要么中途插一句，搞不好就把当前任务节奏打乱了。

现在通过 /btw，就可以真正做到边让它干活，边问它问题。

循环任务

Grok Build 支持使用 /loop 定时循环地执行任务：

也就是让某个任务按照固定时间间隔重复执行，比如一些需要周期性执行的场景，就可以考虑使用 /loop。

相比自己隔一会儿手动执行一次，这种方式显然方便不少。

查看任务列表

使用 /tasks 命令查看正在运行的任务列表：

这里不仅仅包含普通任务，还包括后台任务、子代理和定时任务等。

当同时运行多个任务时，通过 /tasks 可以很方便地知道现在到底有哪些任务还在跑。

另外，还可以使用 /queue 命令查看正在排队等待运行的任务：

简单来说，/tasks 看正在干什么，/queue 看接下来准备干什么。

把这几个功能结合起来之后，Grok Build 就不只是一个简单的的 AI 编程工具了，是不是有点 Claude Code 的感觉？

最后再总结一下：

  • 对于复杂任务，可以先用 /plan 做计划；
  • 执行过程中通过任务进度查看状态；
  • 有新需求直接扔进队列；
  • 想尝试新方案就 /fork；
  • 想临时问一句就 /btw；
  • 周期性工作还可以交给 /loop。

所以，任务一多以后，学会这些命令还是很有必要的，能够明显减少来回等待和上下文混乱的问题。

好啦，这篇先分享到这里，我们下篇继续，有帮助点个关注再走哦。