把飞书讨论接成 GitHub Issue，让决定有人接、能继续追

群里聊了很久，大家似乎已经达成共识。过了几天，却还要重新问：到底决定了什么，谁接了，做到哪了？需要的不是更多聊天摘要，而是一件有范围、有负责人、能继续追踪的事。

Mochi 在团队已有的飞书群里参与讨论，查阅你们选定的 GitHub 项目，经确认后记录事项。下面是一种使用方法，例子为情景说明，不是客户记录或节省时间的实测。

先把决定和设想分开

假设运营提出：“活动页的报名按钮不够清楚，想让第一次来的用户更容易找到。”讨论中可能出现改文案、换颜色、调整位置几种设想。此时还不应该把每个设想都变成任务。

先让麻薯核对已有实现和关联 Issue：“查一下报名入口现在怎么工作，有没有正在处理的事项。列出依据，先不要新建 Issue。”

你应当拿到的是当前实现的依据、已有事项的链接，以及仍需决定的问题。查不到或权限不足时，应明确说明缺口；不能把推测当作项目事实。

确认一件可交接的事

做出决定后，再给出具体范围。比如：“这次只把按钮文案改成‘报名参加’，不动报名流程。请先整理 Issue 草稿，负责人待我们确认。”

检查草稿是否具备：

• 要解决的问题：谁在什么情境下遇到困难。
• 这次的范围：已经决定做什么，哪些设想暂不执行。
• 验收方式：怎样看到改动正确，例如手机和桌面都能读清按钮，原报名流程仍可用。
• 负责人和来路：使用真实的 GitHub 账号，并保留讨论或相关事项的链接；没有确定的人就写明待分配。

团队确认后，再明确要求创建或更新对应 Issue。检查实际返回的 Issue 链接和字段，不只看一条“完成了”的回复。已有同一事项时，继续更新它，避免出现两份不同状态的记录。

后来的问题，回到同一个事项

下一次可以直接引用这个 Issue：“看看这件事现在的状态，有哪些更新，哪些还没确认。”把事实变化和下一步分开，比重新总结整段群聊更容易判断。

如果需要按时跟进，明确说出事项、时间和要回报的内容，并检查安排确实建立。执行依赖运行 Mochi 的 Mac、值班状态、网络和账号授权；它不是无需设备在线的云端承诺。

拿到什么，怎样判断有用

第一次只选一件真实、范围小的工作。目标是得到一个能打开的 Issue：决定、负责人、验收方式和来源都可核对。过后再问一次进展，看能否沿同一事项接着走，而不必重讲背景。

如果团队不使用 GitHub 管理项目，或者讨论还没有做出决定，这套方法就未必适合。Mochi 目前聚焦以 GitHub 为项目上下文的团队，也不会替团队作出业务决定或自动完成 Issue 中的工程工作。

开始前的条件

需要运行 Mochi 的 Mac、模型账号，以及所选飞书和 GitHub 资源的授权。设备要求见下载页，组织权限见管理员说明。

只想先弄清项目现状，可以从带着依据回答一个项目问题开始。