Skate：让编码智能体访问看板

当你和AI结对编程太长时间后，会有这样一种情况。你全身心投入其中——Claude在疯狂输出代码，你在审查、批准、纠正方向——几个小时后你突然意识到：没有人记录下刚才发生了什么。

没有工单被更新。没有计时器在运行。聊天记录长到看不到头，但一旦你关闭会话，它就会消失。如果你的队友问"今天完成了什么？"——祝你好运，靠记忆重建吧。

这一直困扰着我。我完成了和Claude或Codex的马拉松式编码会话后，总有一种模糊的感觉——发生了很多事情，但没有留下任何记录。看板上那些明显已经完成的任务仍然显示"未开始"。时间追踪？别想了。我实际工作的方式和项目看起来的方式之间的脱节越来越荒谬。

1、改变一切的那次午睡

有一天，我埋头苦干了大概五个小时。构建功能、修复bug，在终端、IDE和任务所在的Mattermost看板之间来回切换。我筋疲力尽。

所以我打了个盹。

当我醒来时，半梦半醒地盯着天花板，突然灵光一现：为什么我要当中间人？为什么必须由我来打开看板、找到任务、更新状态、启动计时器，然后回到终端告诉代理接下来要做什么？为什么代理不能自己……做这些事？

所有条件都已经具备了。Mattermost Boards有完整的REST API。像Claude Code这样的AI代理支持MCP工具。我只需要一个东西把它们连接起来。

那天晚上我开始构建Skate。

2、Skate是什么？

Skate是一个Go语言CLI工具和MCP服务器，它让AI编码代理能够直接访问你的Mattermost Boards。你的代理可以列出任务、按优先级选取任务、更新状态、启动计时器、处理任务、留下评论并标记完成——所有这些都不需要你切换到浏览器。

名字的由来？"skate"的一个含义是在某事上快速轻松地取得进展。而这正是发生的事情。过去需要我花几个小时的任务——翻阅代码、编写修复、更新文档、测试——当Claude有一个看板可以参考时，几分钟就能搞定。你只需要说"下一个任务"，然后看它行动。穿越你的积压任务。名副其实。

实际使用效果如下：

$ skate tasks
ID                           TITLE                        STATUS       PRIORITY   ASSIGNEE
c4cf6f4wzbjgxdm3hpa7iygtjdo  Task translation middleware  Not Started  2. Medium
cuppcm819atnixx71qg9i485jsr  listing tasks                In Progress  1. High 🔥

你告诉Claude："按优先级取下一个任务"——它真的会执行。它运行skate tasks，选择优先级最高的项目，用skate task <ID>读取完整的任务描述，更新状态，启动计时器，完成工作，留下说明更改的评论，停止计时器，然后标记完成。

整个循环。全程无需干预。

3、我真正在解决的问题

如果你用过AI编码代理——Claude Code、Cursor、Codex，不管哪一个——你可能也碰到了同样的墙。这些工具在编写代码方面极其强大。但它们对你的项目管理设置一无所知。它们不知道你应该在做什么。它们不会更新工单。它们不会追踪时间。

至于上下文？我曾经对此很执着。我甚至专门构建了一个叫Pantry的工具，为代理提供跨会话的持久记忆。笔记、决策、模式——存储在本地SQLite中，支持语义搜索。有一段时间效果很好。

但关键在于：Claude现在有1M token的上下文窗口。代理的记忆已经不再是瓶颈了。瓶颈是人类的记忆。当三个不同的代理跨多个会话在你的项目上工作时，你需要知道发生了什么。你需要时间戳、你需要评论、你需要一个反映现实的看板。

这就是Skate的用途。不是代理记忆——而是团队记忆。

4、它的实际工作原理

Skate是一个单一的静态Go二进制文件。没有数据库，没有守护进程，没有Docker容器。它使用个人访问令牌直接与Mattermost Boards API通信。

设置大约需要30秒：

skate init          # 输入你的Mattermost URL和token
skate local-init    # 选择该项目使用的看板
skate setup claude-code  # 注册MCP服务器

就这样。Claude Code现在可以调用九个工具：列看板、列任务、查看任务详情、更新状态、创建任务、添加评论、启动/停止计时器和记录手动时间。

幕后原理极其简单。Skate使用Bearer令牌向你的Mattermost实例发送HTTP请求。看板插件处理权限——如果你在浏览器中能看到看板，Skate就能在终端中看到它。

输出格式也很灵活。默认是供人类阅读的整洁表格，但你也可以使用--json或--yaml进行脚本处理：

skate tasks --json | jq '.[] | select(.Priority | test("High"))'

5、翻译功能

这是一个我没有计划但结果出奇有用的功能。

我的团队中有些成员偶尔会用母语编写任务描述。在Mattermost中不是问题——直接读就好。但当AI代理从API解析任务内容时，它需要英文才能发挥最佳效果。

所以我添加了一个翻译中间件。它是可选的——你在配置中使用OpenAI兼容的API来启用（支持OpenAI、Ollama、OpenRouter等）。当Skate渲染任务时，它会运行一个快速启发式检查：这个文本主要是ASCII吗？如果是，跳过。如果不是，翻译它。代理看到的是干净的英文。原始文本在看板上保持不变。

# ~/.config/skate.yaml
translate:
  enabled: true
  provider: ollama
  model: gpt-oss:latest
  base_url: http://localhost:11434/v1

这是那种听起来微不足道，但当你的团队跨越多个国家时会产生真正影响的功能。

6、用AI构建这个项目我学到了什么

这是一个元层面的故事。我用Skate所启发的工作流本身来构建Skate。基本的CLI可以工作后，我开始用它来管理自己的开发。我在Mattermost看板上创建任务，让Skate指向它，然后告诉Claude："按优先级取下一个任务。"

它真的做到了。Claude会：

运行skate tasks查看可用的任务
选择优先级最高的项目
用skate task <ID>读取完整描述
将状态更新为"进行中"
启动计时器
完成实际工作（编写代码、修复bug、更新文档）
留下总结所完成工作的评论
停止计时器
标记完成
问："下一个任务？"

超过30个任务以这种方式完成。每个任务都有时间戳、评论和时间追踪。当我事后查看看板时，我可以清楚地看到发生了什么、以什么顺序、每件事花了多长时间。

这就是全部意义所在。不仅仅是完成工作——而是知道完成了什么。

7、循环任务：拖拽，放下，再来一次

自然出现的一个模式是循环任务。更新README、运行测试、检查文档——这些不是一次性的。每次我添加功能或修复bug时，README可能需要调整，测试需要更新，文档可能过时了。

与其每次创建新任务，不如将旧任务从"已完成"拖回"未开始"。代理会选取它，看到描述和所有之前的评论，理解上下文，然后再次完成工作。它检查文件的当前状态，找出上次以来发生了什么变化，并相应地更新。

这出乎意料地强大。我有一个"更新README"的任务，在开发过程中可能被完成并重新打开了六次。每次代理都会读取自己之前的评论，看到上次添加了什么，然后补充新的内容。我完全不需要重复说明。只需移动卡片然后说"下一个任务"。

测试也是一样。"添加/更新测试"是一个不断回归的任务。代理检查当前的覆盖率，看到上次运行以来添加了什么新代码，编写缺失的测试，附上输出结果。我不需要解释发生了什么变化——它会通过查看代码自己搞清楚。

8、当代理成为团队成员

事情在这里变得有趣了。你正在和Claude结对编程，偶然发现了什么——一个bug、一个想法、一个需要但不紧急的重构。在旧的工作流中，你需要切换到浏览器、打开看板、创建卡片、写好描述、回到终端。上下文切换，心流被打断。

有了Skate，你只需说："为这个创建一个任务。"代理运行skate create，从刚才的对话中填写标题和描述，卡片就出现在看板上了。不需要浏览器，不需要上下文切换。发现直接从你的脑海转到看板上，只需几秒钟。

但它还不止于此。对于更大的任务，代理不会直接一头扎进去——它会先做计划。它研究代码库，思考方案，编写一个markdown文件形式的计划，并把它附加到任务卡片上。然后它将状态设为"阻塞"并等待。接下来是我没想到的部分：其他团队成员可以在看板上看到那个计划。他们可以阅读、留下评论、对决策提出异议、建议替代方案。代理接收反馈，修改计划，附上新版本，只有在方案被批准后才开始编码。

想想刚才发生了什么。一个AI代理提出了一个技术方案，一个人类队友在看板上异步审查了它，留下了反馈，而代理在写一行代码之前就整合了这些反馈。这不是"开发者在终端里和AI对话"。这是一个团队使用共享看板协作工作——其中一个团队成员恰好是一个AI。

这完全改变了动态关系。代理不再隐藏在某个人的IDE里。它的工作是可见的：计划已附上、状态被追踪、时间被记录、评论记录了每一个决策。团队中的任何人都可以看到代理在做什么、花了多长时间、为什么做出某些选择。当有人六个月后加入项目并问"为什么这样构建？"——答案就在卡片上。

9、技能文件：一个文档统领一切

所有这些——状态更新、计时器追踪、提及、计划、内容块——都由一个名为SKILL.md的单一markdown文件控制。它嵌入在Skate二进制文件中，在你运行skate setup时随MCP服务器一起安装。代理读取一次，并在整个会话中遵循它。

让我感到意外的是：代理比任何人类都更好地遵循这些指令。

我是认真的。想想那些在每个团队中都会被遗漏的、枯燥重复的事情。更新工单状态。启动计时器。带说明停止计时器。提及正确的人。附上测试输出。关闭前写总结评论。开始前检查相关任务。阅读重新打开的工单上的所有之前评论。每个开发者都知道自己应该做这些事。我们大多数人到周二就忘了一半。

代理从不忘记。它读取技能文件，然后严格按照它说的做。每一次都是如此。它在开始工作前更新状态。它启动计时器。它检查附加的文件。它提及最后的评论者。它写总结。它带说明停止计时器。它附上计划。不是因为它有动力或有纪律——而是因为它字面意义上遵循给它的指令，没有自尊、没有捷径、没有"我待会儿再做"。

技能文件要求的一件事是签名。每条评论和计时器笔记都以一行类似-- claude-code (claude-opus-4-6)或-- codex (gpt-5-codex)结尾。听起来是小事，直到你有多个代理在同一个看板上工作。我曾让Claude Code在一个项目上处理任务，同时Codex并行处理另一个看板。当我事后查看看板时，每条评论都有归属——我可以确切地看到哪个代理用哪个模型做了什么、以什么顺序。不用猜测，不用问"这是谁写的？"

这比你想象的更重要。当三个代理和两个人类为同一个项目做贡献时，看板就成了唯一的真相来源。不是某个人的聊天记录，不是被滚过的终端日志——而是看板。每一个决策、每一个计划、每一次状态变更都是可见的、有归属的。

技能文件大约130行markdown。没有代码，没有配置解析，没有API集成——只有清晰的自然语言指令。它把一个通用AI模型变成了一个可预测、可靠的团队成员，处理人类很不擅长处理的运营开销。

想让代理行为不同？编辑技能文件。想让它停止提及他人？在配置中添加mentions: false。想让它总是附上计划？已经包含在里面了。整个工作流是声明式的、版本控制的、透明的。

10、枯燥的技术细节（给关心的人）

语言：Go。单一二进制文件，无CGO，一条命令交叉编译到Linux/macOS/Windows。
MCP传输：stdio。代理按需启动Skate，零空闲成本。
配置：YAML三层合并（全局 → 本地项目级 → 环境变量）。
依赖：Cobra用于CLI，官方OpenAI Go SDK用于翻译，MCP Go SDK用于代理集成。
缓存：用户ID解析为用户名并缓存在~/.cache/skate/users.yaml中。
版本：构建时通过ldflags设置，在CLI、HTTP User-Agent和MCP服务器之间共享。

整个项目大约2,000行Go代码。做好一件事。

11、关于Boards插件的说明

我应该提一下：我运行的Mattermost Boards实例不是原版Focalboard。我一直在维护Boards插件的一个定制分支，添加了一些原版从未发布的特性——最显著的是时间追踪。在卡片上启动/停止计时器和记录工时的能力，使得"代理追踪自己的时间"这个循环成为可能。还有一些其他的小调整，是我在团队工作方式上需要的，不值得向上游提交PR，但对日常工作产生了很大影响。

Skate是基于那个插件的API构建的。如果你运行的是原版Focalboard，一切仍然可以正常工作——任务列表、状态更新、评论、附件——只是没有时间追踪端点。Skate会优雅地处理这种情况：如果计时器API不存在，它会告诉你然后继续。不会崩溃，不会破坏工作流。

12、超越Mattermost：Jira、Linear及其他

我一直在想的是：这种方法没有任何东西是特定于Mattermost Boards的。

我不是唯一注意到AI代理和项目管理之间差距的人。像Vibe Kanban（Rust语言，13k+星标）和Kanban Code（Swift语言）这样的项目正在解决同样的问题。它们令人印象深刻——Vibe Kanban提供并行代理编排和隔离的git worktree、可视化代码审查等功能。Kanban Code自动将Claude会话链接到卡片，并在PR合并时在面板上流转它们。

但关键在于：它们都创建了一个新的看板。一个新的UI、一个新的工作流、一个团队中每个人都必须学习的新工具。如果你的团队已经在使用Jira、Mattermost或Linear——你现在有两个看板了。AI看板和真正的看板。祝你的项目经理会去查看AI看板。

Skate采取了相反的方法。它不取代你的看板——它连接你的看板。你的团队继续使用他们一直使用的同一个Mattermost看板，同样的列，同样的工作流，同样的移动应用。代理只是作为另一个参与者出现。没有迁移，没有培训，不需要"请大家切换到这个新工具"。看板留在原处。代理在团队已经工作的地方与他们会合。

这个模式是通用的。你有一个AI代理。你有一个带API的项目管理系统。你需要它们之间一个薄薄的无状态桥梁——一边说MCP，另一边说REST。这就是Skate。今天它与Mattermost Boards对话。但同样的架构——同样的命令集、同样的MCP工具接口、同样的技能文件模式——可以与任何东西对话。

Jira？当然。Linear？更容易，它们的API很棒。GitHub Projects？Shortcut？Notion数据库？它们都有相同的基本对象：任务、状态、评论、负责人。动词是相同的：列出、创建、更新、评论、追踪时间。

我认为我们正在走向一个每个项目管理工具都有MCP适配器的世界，AI代理只需将"更新工单"视为其工作流的正常部分。现在大多数团队都有这个奇怪的差距：代理完成了工作，但人类必须手动记录它发生了。这个差距不应该存在。

Skate是我关闭这个差距的概念验证。Mattermost Boards是起点，因为那是我使用的工具，但这个理念比任何一个工具都大。如果你在使用Jira，想让你的Cursor代理选取工单、更新状态并记录时间——蓝图就在这里。Fork它，替换API客户端，保留MCP工具。困难的部分不是HTTP调用，而是设计工作流，让代理知道如何成为一个好的团队成员。这就是技能文件处理的，而且那部分是完全可移植的。

13、这适合谁？

如果你使用Mattermost Boards（或独立的Focalboard）并与AI编码代理合作，Skate消除了项目看板和终端之间的差距。你的代理成为一等团队成员，更新自己的工单并追踪自己的时间。

如果你的团队做时间追踪，你会获得自动的计时器启动/停止，无需任何人记得点击按钮。

如果你是一个独立开发者，只想告诉Claude"处理下一个任务"并让它真正知道那意味着什么——Skate就是那座桥梁。

如果你使用的是完全不同的PM工具——阅读代码，借鉴模式。AI辅助开发的未来不仅仅是更智能的代理。而是代理参与人类使用的相同工作流，具有相同的问责制和相同的工作记录。

14、试试看

git clone https://github.com/mobydeck/skate
cd skate
make install
skate init

它是开源的，用Go构建，是单一的二进制文件，运行成本为零。

原文链接: I Gave My AI Agent a Kanban Board and It Outperformed My Team at Project Management

汇智网翻译整理，转载请标明出处