用 Claude 分析 6 个月团队回顾，发现遗漏的问题

通过 Jira 和 GitHub 集成的 MCP

产品经理有一件事，没有人会写在职位描述里。每隔几周，在一次回顾会后，你在脑子里标记三四个项目是值得关注的事情。然后一个冲刺周期过去了。再过一个。三个月后，在一次领导力评审中，有人问"X 在改进还是在恶化？"，而你的回答完全是凭直觉，因为没时间在开会前读 12 份回顾会记录。

回顾会的记录就在那里。数据很好。读它们的工作量不好。

我在做 Kollabe，所以要带着一定的保留意见听这个。这些模式是可以推广的；如果你的回顾工具公开了 API 或者 MCP 服务器，下面的工作流可以用在你手里的任何东西上。我会让提示词保持厂商中立，这样你可以轻松替换。

过去两个月，我一直在通过 Claude 推进我大部分跟回顾相关的工作，连接了三个 MCP 服务器：Kollabe（用于回顾和行动项界面）、Atlassian（用于 Jira）和 GitHub。Kollabe MCP 公开了约 50 个工具，1:1 映射到公开的 REST API，所以我在 UI 里能做的任何事，Claude 都能代我做。这包括读我有权限访问的所有空间里的每一份回顾和行动项。

周一早上的工作流就是一个提示词。它依次做四件事，然后停下来等我。

1. 读过去 26 周内我拥有的各个空间里的所有回顾。

2. 拉取每一个开放中的行动项，包括那些悄悄超龄、比创建它们的人还老的项。

3. 读上一个冲刺周期的所有每日站会，以获取额外的信号。

4. 写一份结构化的简报：什么在改进，什么在恶化，哪些行动项已过时，以及一句话的"本周我会问团队什么问题"。

然后它就闭嘴，让我来思考。

行动项的一半：悄悄失效的部分

这是一个令人尴尬的事实，没有人会公开说起，关于回顾：大多数行动项没有关闭，因为它们从工作记忆中消失了。回顾会召开，有人写下"调查不稳定的 CI"，分配给某人，两个冲刺周期过去，那个拥有它的人换了团队，这个项在工具里技术上永远是开放的。在大多数团队上读一份"开放行动项"的清爽仪表板，你会发现中位数年龄约为 47 天。

修复不是一个更好的跟踪器。修复是某个人每周读一遍每个开放行动项，并问三个问题：它还相关吗，它是不是其实已经悄悄完成了，现在谁真的拥有它。

我让 Claude 来做这个。提示词很短：

For each space I own, use `action_item_list` (status = PENDING).
For every item older than 21 days:
1. Use `search` (Kollabe MCP) to look for activity on the item's keywords across
   retros, standups, and Jira via the Atlassian MCP — last 30 days.
2. If the item appears resolved or superseded, propose marking it COMPLETED with
   a one-line note explaining what closed it.
3. If the assignee changed spaces or hasn't been active in standups for >14 days,
   flag it for reassignment.
4. Otherwise, propose a one-sentence nudge comment from me, via
   `action_item_create_comment`.
Show me a table. Wait for me to approve each row before any writes.

它生成一份表格。大多数周，我批准其中的约 80%，拒绝其余的。被拒绝的最有趣。它们是 AI 认为已解决但我知道没有的项，这通常意味着我们有一个文档化的决定应该成为文档化的决定。

两个月后，我们各个空间的中位数行动项年龄从 47 天变成了 14 天。没人非得去催促任何人。没人非得搭建仪表板。

六个月的增量：新出现的部分

这是我接入时低估的部分。Kollabe MCP 有一个搜索工具，在你的各个空间里对每一份回顾、每日站会、行动项和回合进行语义搜索，由 pgvector 嵌入驱动。比滚动更快本质上不是重点。重点是你本来不会问的问题，因为工作量不值得。

我每个周一问什么，在同一个提示词里：

Using the Kollabe MCP `search` and `retro_list` + `retro_get`, scan the last
26 weeks of retros in my spaces. Produce:

1. The five themes that appeared in the first 3 months but have NOT appeared
   in the last 6 weeks. (Things that quietly got fixed.)
2. The five themes that have appeared in 3+ retros over the last 6 weeks
   and weren't a problem 6 months ago. (Things that quietly got worse.)
3. Any theme that appeared, was resolved, and has come back.
4. Two questions worth asking the team this week given (1) - (3).

第一次我跑它时，AI 浮出三件真正让我惊讶的事。一件是我忘记团队悄悄做过的修复。部署流一直是第一季度的一个持久抱怨，然后它就简单地停止成为抱怨了，这意味着某人一月的工作有了回报，而我没有为此感谢他们。一件是代码审查等待时间的缓慢漂移，太安静了，以至于在任何单个回顾会里不像个问题，但当你看到三个回顾会一排排提及它而没有升级，就明显是个问题了。第三件是一个经常重复出现的关于会议超载的挫折，曾经被解决过一次，现在正在悄悄蔓延回来。

这很不舒服。这也是一年以来我对我的团队得到的最有用的单一数据点。我那天下午给修复部署的开发者发了一份公开表扬。

为什么是 MCP 而不是"我就写个脚本"

我在这个领域工作，我确实写过脚本版本。它工作。但它也很僵化：每次我想问一个略有不同的问题，我就得编辑代码。MCP 版本让我周一早上用英文写下问题，然后它用我的 Python 脚本会用到的同一个 API 界面去跑。

让这个真实而不是一个客厅把戏的是公开 API 和 MCP 服务器是同一个界面。每个 MCP 工具都注册到一个 /api/v1/* 处理器，拥有相同的 Zod schemas 和相同的访问检查。所以当我在聊天里原型设计某个东西，结果证明是有用的每周运行，我可以把相同的调用提升到一个定时 Worker，周五下午 4 点运行，然后给自己发一份简报。提示词和脚本共享一个接口。

这对技术性的产品经理特别重要。你会想要把那些工作的东西升级为不需要你就能跑的东西。有了一个镜像真实 REST API 的 MCP，你可以做到——不需要在两个界面间翻译，也不需要等厂商发布 Zapier 支持。

它的工作深度取决于你的回顾内容。如果你的团队写"deploy bad"作为回顾项，搜索和总结界面不会从中挖出智慧。它首先说服我的是我们需要更好的回顾写法。我们给两个列添加了一个模板化的"发生了什么、谁受影响了、什么改变了"的主体。一个月后信号跳跃了。

语义聚类很聪明，但不是通灵。AI 有时会把两个表面相似但实际上是关于不同事情的项分组。比如，一个 CI 抱怨和一个发布流程抱怨。我读的是聚类标题，不仅仅是结论。

行动项分类提示词做写。总是。我从来没让它不经过逐行批准步骤就写过。某一天，当我相信它可以不经我就更新时，就是它会因为某人在一个切线上说了"固定"这个词而把一个未解决的合规项标记为已修复的那一天。提示词保持"提议然后等待"的形态。

你可以偷的经验法则

如果你是一个感觉数据存在但工作量不存在的产品经理，这里有个你在构建任何东西之前应该问的问题：

如果我刚花两小时读了过去六个月的回顾会，我会问我的团队什么问题？

把那个问题写下来。那是你的每周提示词。如果你的回顾工具有一个 MCP 服务器或有语义搜索的公开 API，你可以让 AI 做阅读，然后把问题的答案和引用带回来。如果没有，那是一个采购问题。下一代敏捷工具会假设一个 AI 在读历史记录，而不仅仅是一个人。

我在周一上午 9 点运行我的版本。不管你的版本是什么，省下的时间并不真的是赢。赢是被问到的问题，那些本来不会被问的问题。

如果你想对照 Kollabe 的 MCP 试试这个，连接大约需要一分钟，并包含在 Premium 及所有试用版上。MCP 页面有 OAuth 流和一键设置。如果你想要脚本版本，我提到的每个工具也都是一个文档化的 REST 端点，相同的验证，相同的形态。

For further actions, you may consider blocking this person and/or reporting abuse