Ignis · Feishu Capability
用户把飞书链接丢给 Mai,Mai 就能读;让它写文档、记表格、搬素材、发通知,它都能干。这页讲清楚:它以什么身份干活、界面上用户会经历什么、哪些规矩是刻死的。
At a glance
一句话:Mai 以用户本人的身份操作他的飞书。用户能看的它才能读,它建的文档所有者就是用户自己。全部能力都在对话里发生——用户说话,Mai 干活,结果给链接。
Identity model
很多产品接飞书用的是"机器人进群"。我们没走这条路。用户授权一次后,Mai 拿到的是用户自己的飞书身份,由此带来三条产品性质:
值得记住的一点:飞书的登录凭证只存在网关的保险箱里,Mai 的模型、对话记录、日志全都碰不到它。哪怕对话记录被导出,里面也没有任何凭证。
Onboarding
用户第一次让 Mai 碰飞书时,才会遇到授权。流程刻意做得很轻:
之后永远不再打扰:凭证自动续期,后台每天还有一次保活检查,把快到期的凭证提前换新。授权一次就一直有效,除非用户自己在飞书侧撤销(撤销后下次使用会重新走一遍授权卡)。
等待期间 Mai 不轮询、不反复推卡片,就安静等用户回话。
Actions
对模型来说这是一个 feishu 工具;对用户来说,是八件他能用自然语言唤起的事:
| 动作 | 用户怎么说 | Mai 干什么 |
|---|---|---|
| read | "看看这个文档"+ 链接 | 读文档、知识库页、多维表格、电子表格,直接读,不反问 |
| create | "把方案写成飞书文档" | 整篇建新文档,回链接,所有者是用户 |
| edit | "把这篇改成…" | 整篇替换,带警告门和恢复版本(见下节) |
| extract_media | "把表里的视频拎进素材库" | 文档/表格里的图·视频·附件下载成素材库 file_id |
| append_records | "往表里加一行" | 多维表格追加记录,附件列可以直接写素材 |
| update_records | "把那行的状态改了" | 按行更新记录,行号不明就先读表拿 |
| send_card | "弄完飞书叫我" | 往用户飞书推通知卡片,内容 Mai 写,可带按钮链接 |
| request_auth | (Mai 发现没权限时自动使用) | 申请飞书授权:系统把授权卡直发用户飞书,链接不经过 Mai |
还有一个包装原则,决定了用户看到的形态:短话直接说,长产出进文档,任务完成推卡片。超过一屏的内容不会刷在对话里,Mai 会主动提议"要不要建成飞书文档给你链接"。
Assets
验收标准我们用的是最严的一条:素材从素材库放进飞书、再从飞书取回来,两份文件逐字节相等。图片、视频、大文件三条链都按这个标准真机验过。
Interaction rules
下面这些不是"模型自觉",是写进工具说明书、每次调用都会被约束的硬规则。PM 可以拿它们当承诺对外讲:
"改"的本质是整篇替换。改任何不是 Mai 自己建的文档前,它必须原话告知用户风险并等确认;动手前自动创建一个带 Ignis 标记的恢复版本,改坏了在文档"版本"里一键还原。
链接指向的文件里有多张表时,Mai 列出候选让用户点名,不猜、不默认。
文件超 20MB 传不进表格?直说传不了,不偷偷压缩、不换文件。用户要删行?直说没有删除能力,不拿别的动作凑数。读到的内容被截断?明说"这是节选"。
每次调用都带一个用户能看懂的短标题("读取飞书文档"/"提取表格附件"),用户在界面上始终知道 Mai 正在干什么。
卡片只在三种时机出现:长任务完成、需要用户拍板、授权引导。不拿卡片刷进度、刷存在感。
Limits
| 项目 | 上限 | 超了怎样 |
|---|---|---|
| 读文档 | 256KB | 截断并明说"这是节选" |
| 读表格 | 500 行 | 同上 |
| 表格附件(写入) | 20MB / 件 | 如实报"太大传不了" |
| 文档嵌文件 | 200MB / 件 | 文档照建,警告点名哪件没进 |
| 素材提取(单次) | 总量 500MB | 超出部分列入"跳过"清单如实汇报 |
三件明确不做的事,建议对外话术也保持一致:
Status