我现在处理长期开发任务时，会把终端分成三层：Herdr 负责把工作空间和会话留住，Codex 负责读代码、改文件和跑检查，helix-kanban 负责记录还有什么没做、哪些正在做、哪些已经完成。

这几个工具单独用都能工作，组合起来之后，解决的是另一件事：任务不会因为一次对话结束就消失，Codex 也不用每次都从一段很长的上下文里猜下一步该做什么。

三个工具各管一件事

这套组合的边界比较简单：

工具负责什么状态放在哪里
Herdr管理终端工作空间、分屏和持久会话Herdr 的会话状态；Codex 自己的历史由 Codex 保存
Codex分析代码、修改文件、执行命令和验证结果Codex 会话与当前代码工作区
helix-kanban保存项目、任务、优先级、标签和状态列Markdown 文件，位于 ~/.kanban/ 或项目目录的 .kanban/

这里有一个容易混淆的地方：Herdr 保存的是终端工作空间和持久会话，让窗口、分屏和正在运行的程序可以继续；Codex 保存自己的会话历史，负责恢复之前的对话上下文。看板则是第三份更适合长期查看的记录，它不依赖某个 Codex 对话是否还开着。

先装好 helix-kanban

helix-kanban 已经发布到 GitHub Releases 和 crates.io。已经安装 Rust 的话，直接用 Cargo：

cargo install helix-kanban --locked

安装后可以确认 hxk 在 PATH 中：

hxk --version

第一次运行 hxk 会进入终端看板。全局项目放在 ~/.kanban/projects/，适合跨仓库的个人待办；在某个代码仓库里创建本地项目后，数据会放到该仓库的 .kanban/ 目录，适合和项目一起管理。

任务本身是 Markdown 文件，状态列就是目录。默认列通常是 todo、doing 和 done，也可以在看板里按自己的工作流增加或调整状态。文章中的状态名只是示例，实际操作时以 hxk 当前项目列出的名字为准。

把 hxk mcp 接给 Codex

helix-kanban 把 MCP server 集成到了 hxk 主程序里，不需要另外维护一个 MCP 二进制。Codex CLI 可以直接注册这个 stdio server：

codex mcp add helix-kanban -- hxk mcp

如果 hxk 不在 PATH，把命令换成绝对路径：

codex mcp add helix-kanban -- /Users/your-name/.cargo/bin/hxk mcp

用下面的命令确认配置已经被 Codex 读到：

codex mcp list

之后重新打开 Codex 会话。它就能通过 MCP 调用 helix-kanban 的工具，包括：

  • helix-kanban_list_projects：列出全局和本地项目
  • helix-kanban_list_tasks：按项目和状态查看任务
  • helix-kanban_show_task：读取任务的完整描述
  • helix-kanban_create_task：创建任务
  • helix-kanban_update_task：修改标题、优先级、标签或 Markdown 内容
  • helix-kanban_move_task：把任务移到目标状态列
  • helix-kanban_batch_create_tasks：一次创建多个任务

这些调用的参数是结构化的。比如查看任务时要明确提供项目名和任务 ID，移动任务时要提供目标状态，不需要让 Codex 通过读取目录名来猜测一套隐藏规则。

我实际怎么安排一次任务

假设要给一个 API 增加新的筛选条件，我会在看板里先建一条任务，标题写成能独立理解的句子，描述里放验收条件和相关目录。可以直接在 hxk 里创建，也可以让已经连好 MCP 的 Codex 创建：

在项目 api-platform 中创建一个任务：为租户列表增加状态筛选。
优先级 high，标签 feature,api。
描述写清楚：更新 GraphQL 输入类型、服务端查询条件、分页行为，并运行现有测试。

任务进入 todo 后，我再让 Codex 读取列表并开始执行：

读取 helix-kanban 项目 api-platform 的 todo 任务，先处理优先级最高的一项。
开始前把它移动到 doing，完成代码和测试后把执行结果写回任务，并在确认验证通过后移动到 done。

Codex 会先调用 helix-kanban_list_tasks，必要时调用 helix-kanban_show_task 读取完整描述，然后按任务要求修改代码。开始工作时移动到 doing，中途遇到阻塞，可以把阻塞原因补进任务内容；代码、测试和人工确认都完成后，再移动到 done。

这一步的价值在于，任务状态不再只存在 Codex 的回答里。即使我关闭当前对话，稍后从另一个窗口回来，打开 hxk 仍然能看到这条任务停在什么位置。

Herdr 把工作空间留在原地

看板和 Codex 配好后，Herdr 负责让这套布局一直可用。我通常会给一个项目单独开一个命名会话：

herdr --session api-platform

在同一个 Herdr 工作空间里，可以保留几个固定 pane：

  • 一个 pane 跑 Codex
  • 一个 pane 打开 hxk 看板
  • 一个 pane 跑测试、日志或开发服务器

下面这张截图就是这种安排：左侧是 Herdr 的空间和 Codex，右侧是 helix-kanban 的项目看板。Codex 正在执行检查时，右边仍然能看到 todo、doing 和 done 的总量，以及当前任务列表。

Herdr、Codex 和 helix-kanban 并排工作

Herdr 让终端布局、Codex 进程和看板窗口保持在同一个工作现场，不需要再复制一份任务记录。需要离开时可以退出客户端，回来后重新连接命名会话；任务记录仍然由 helix-kanban 的文件保存。

看板让长任务有一个外部记忆

Codex 很适合连续执行一串动作，但长任务通常会跨越多个会话：今天先改模型，明天补测试，后天处理部署环境。把所有信息都留在聊天记录里，会遇到几个问题：

  • 下一次会话需要重新解释当前进度
  • 多个项目的待办混在不同对话里，不方便比较
  • 被测试失败或外部依赖卡住时，很难留下一个明确的现场记录
  • 任务完成后，无法快速看到一段时间内到底做了多少事情

看板把这些内容放到项目和状态列中。任务描述可以继续用 Markdown 写详细背景，标题和标签用于快速筛选，优先级帮助 Codex 决定先后顺序。状态列只表达当前阶段，不把错误日志、讨论过程和长期笔记都塞进一个状态字段。

因为 helix-kanban 使用文件存储，任务也可以被人工编辑、版本控制或直接交给其他工具读取。全局项目适合记录个人长期事项，本地项目适合把仓库专属任务和代码放在一起。选哪一种，取决于任务是否应该跟着代码仓库移动。

一套足够稳定的约定

这套工作流不需要复杂的自动化规则，但需要几个固定动作：

  1. 开始一项明确工作前，先在 todo 建任务，写清验收条件。
  2. Codex 开始处理时，把任务移动到 doing。
  3. 每次发现新的后续工作，直接创建新任务，不把它埋在当前对话的结尾。
  4. 测试失败、等待接口或需要人工决定时，把原因写回任务内容，保持在 doing 或单独的阻塞列。
  5. 只有代码、检查和必要的人工确认都完成后，才移动到 done。

这些动作看起来很小，却能把“我记得还有一件事”变成别人也能读懂的状态。Codex 负责把事情做完，helix-kanban 负责让事情可见，Herdr 负责让工作现场随时回来。

适合什么场景

这套组合尤其适合下面几类工作：

  • 一个项目会连续维护几天或几周，单次对话装不下全部背景
  • 同时维护多个仓库，需要一个地方看总的待办
  • 经常暂停 Codex 去查资料、跑测试或等待外部反馈
  • 希望 AI 可以直接更新任务，而不是每次手动复制标题和状态
  • 喜欢终端和键盘操作，不想为了任务列表再开一个网页服务

它也不要求把所有事情都交给 Codex。临时想法可以自己在 hxk 里记下，任务拆分和状态移动可以让 Codex 代劳，最终是否完成仍然由人根据代码和验证结果确认。

项目地址：