在飞书里查 GitHub 项目，带着依据作判断

“这个入口现在支持什么？”“活动规则会不会和现有逻辑冲突？”一个业务判断，往往要先找到熟悉实现的人，再补上背景。真正需要的是能核对的依据，以及它对当前决定意味着什么。

Mochi 从你们明确选定的 GitHub 项目中查找信息，在飞书对话里回答并给出来源。GitHub 是共同上下文，不要求每个提出问题的人都会写代码。

第一次，就查一个真实功能

选一个你最近确实需要向同事确认、准备向客户介绍的功能。第一次只查这一件事，看回答能不能帮助你继续决定。

开始前，按上手指南连接自己的模型账号、飞书和一个获准访问的 GitHub 项目，让麻薯开始值班，并保持 Mac 在线。如果需要组织管理员审批，先把管理员说明交给负责的人；设备与账号要求见下载页。

在飞书群里输入 @ 并选择你们的麻薯，再发送下面的问题。把方括号换成实际项目和功能，普通文字“@麻薯”不能代替真正的提及：

@麻薯 ［项目］的［功能］现在能向客户承诺可用吗？请分清代码是否合并、是否已经发布、是否有实际验收依据，附上能核查的来源。查不到的部分请明确说不知道。这次先查证，不创建或修改 Issue。

怎样算有用：打开回答中的一个来源，检查它是否真的支持对应结论。回答应让你知道可以继续做哪个决定，或还缺谁确认哪项事实。“有实现，但尚无发布依据”也可以是有用的答案。

如果没有回复，先确认真正 @ 到了已开始值班的伙伴、Mac 在线且它已加入这个群；如果找不到资料，检查选中的项目是否包含这项功能。不要把连接失败当成“项目里没有”。

做完后，保留原话题。等这件事有新进展时，在同一话题要求重新查询，比较新依据，而不是只重复上一次的结论。

把业务目的说清楚

不用先把问题翻译成技术术语。说明准备作出的决定、需要核对的范围和期望产出就可以。项目里没有的事实，应留作问题，而不是由智能体补全一个看似完整的故事。

要一份可核对的回答

有用的回答应当把三件事分开：

1. 已有事实：相关文件、Issue 或其他可访问来源在哪里，具体支持了哪个判断。
2. 推断与限制：哪些结论依赖条件，哪些资料尚未取得，是否可能存在不同实现。
3. 待决定的事：为了达到业务目的，还需要谁确认哪一项选择。

抽查一个来源，看看它是否真的支持回答。需要最新状态时，明确要求重新查询；记忆里的背景不能代替当前仓库状态。

写在代码里，不等于已经上线

仓库能够说明一个实现或改动存在，却不一定证明生产环境已发布、用户已经看到，或某个外部配置正在生效。问“上线了吗”时，应要求说明证据来自代码、PR、发行记录还是实际环境。

没有生产证据，就保留“发布状态尚未确认”。这种边界比一个毫不犹豫的“已上线”更能帮助团队作出正确决定。Mochi 的访问仍受你选择的项目、工具能力和授权限制。

从答案接到行动

确定改动范围后，再让麻薯整理待办草稿，并由团队确认负责人和验收方式。参见让聊定的事有人接续。如果暂时只需要判断，就把依据留在原对话里，不必为了使用工具而制造任务。

用一个真实问题检验价值

挑一个最近确实需要找同事确认的问题。检查回答是否让你能继续决定：来源能打开吗，结论对应来源吗，不确定处清楚吗，下一步是谁确认什么？如果仍然要从头解释，先找缺失的上下文，不要只增加更多提示词。

Mochi 不能保证每个答案正确，也不能从无法访问的资源中得到事实。PDF、Office 和音视频不应被默认当作已解析正文。涉及私密资料时，先阅读隐私说明，只连接完成任务需要的资源。

设备与账号条件见下载页。