飞书OpenAPI不提供meeting_summary接口，AI会议纪要为客户端黑盒能力，PHP需自行构建ASR+LLM流水线处理录音并提取摘要与待办。
飞书 API 文档里没有 meeting_summary 这个接口
飞书官方 OpenAPI 目前不提供直接“会议纪要生成”或“AI 会议摘要”的端点。所谓“飞书 AI 会议纪要”，是飞书客户端（桌面/移动端）在录制会议时，由飞书服务端调用其内部大模型能力实时处理音视频流后生成的——这个过程完全黑盒，不对外开放调用权限。
所以 PHP 后端无法像调用 messages/send 那样，发个请求就拿到摘要和待办。你看到的“会议纪要”页面，本质是飞书前端读取了会议回放元数据 + 服务端预生成的结构化结果（比如 summary 字段、action_items 列表），这些字段只对会议创建者/参与者在飞书 App 内可见，不会通过 OpenAPI 返回给第三方应用。
常见错误现象：
– 调用 /v1/meetings/{meeting_id} 或 /v1/meetings/{meeting_id}/recordings，返回 JSON 里压根没有 summary 或 todo_list 字段；
– 在开放平台申请了“会议管理”权限，仍收不到 AI 生成内容；
– 误以为开启“飞书 AI”企业版就能开放 API，实际只是增强客户端能力，不等于开放模型调用。
PHP 能做的真实路径：用飞书录音文件 + 第三方 ASR + LLM 自搭流水线
如果你真需要在 PHP 项目里生成会议摘要和待办，唯一可行方案是绕过飞书 AI，自己接管语音转文字 + 文本提炼流程。前提是：你有权限下载飞书会议的原始录音（MP4 / M4A），且该会议开启了云录制并配置了可公开访问的录制地址（或你有 recordings:read 权限 + 正确的 tenant_access_token）。
立即学习“PHP免费学习笔记（深入）”；
- 先用 PHP 调用
/v1/meetings/{meeting_id}/recordings拿到play_url或download_url - 用
file_get_contents()或cURL下载音频（注意鉴权 header，如Authorization: Bearer ttt.xxxx） - 转成 WAV/MP3 标准格式（飞书 M4A 有时带 DRM，需先确认能否直解；若不行，得走 FFmpeg 命令行：
ffmpeg -i input.m4a -acodec libmp3lame output.mp3） - 把音频喂给 ASR 服务（如阿里云
SpeechRecognizer、腾讯云asr_recognize、或开源 Whisper 的 API 封装）得到文本 - 再把文本丢给 LLM（如通义千问
/v1/chat/completions、或本地 Ollama 的qwen:7b）做摘要+待办抽取，提示词要明确要求输出 JSON 结构（含summary和action_items字段）
性能影响：整个链路耗时取决于音频长度、ASR 延迟、LLM 响应速度。一个 60 分钟会议，ASR 可能花 2–5 分钟，LLM 提炼再加 10–30 秒。别指望实时。
file_get_contents() 下载飞书录音常因鉴权失败返回 401 或空内容
飞书录制文件 URL 是临时签权链接，有效期通常只有 5–10 分钟，且绑定 tenant_access_token 的签发者身份。PHP 直接 file_get_contents($url) 失败，大概率不是网络问题，而是没带正确 header 或链接已过期。
实操建议：
– 不要用裸 URL，必须带上 Authorization header：Authorization: Bearer ttt.xxx（注意是 tenant_access_token，不是 user_access_token）；
– 下载前先检查 download_url 是否含 Expires= 参数，用 strtotime() 校验是否过期；
– 若返回 401，立刻刷新 tenant_access_token（调用 /open-apis/auth/v3/tenant_access_token/internal/）；
– 若返回空但状态码 200，可能是飞书返回了重定向（302），而 file_get_contents() 默认不跟随，改用 cURL 并设置 CURLOPT_FOLLOWLOCATION => true；
– 录音文件可能很大（GB 级），PHP 默认 memory_limit 和 max_execution_time 会炸，务必提前设置：ini_set('memory_limit', '2G');、set_time_limit(0);
LLM 提炼会议文本时，action_items 容易漏掉隐含待办或责任人
纯靠大模型从会议转录文本中抽待办，效果很依赖提示词质量与上下文长度。飞书客户端里的待办能标出“@张三 本周五前输出方案”，是因为它结合了发言者 ID、时间戳、消息气泡上下文；而你传给 LLM 的只是平铺直叙的文本，缺少这些信号。
提升准确率的关键点：
– 在送入 LLM 前，用正则粗筛出含“请”“需要”“务必”“截止”“下周”等关键词的句子，单独加权重；
– 强制要求输出 JSON，且每个 action_items 必须含 text、owner（从发言者昵称匹配）、due_date（用 date_parse() 提取）三个字段；
– 别用太长的上下文（如整场 90 分钟转录塞进去），LLM 容易丢失细节，按发言轮次分块处理更稳；
– 对比发现：Qwen2.5-7B 在中文会议文本上比 Llama3-8B 抽取 owner 更准，但对模糊表述（如“后面跟进一下”）依然无力——这时候就得人工补规则，比如默认 assignee 是下一句发言者。
真正卡住的地方不在 PHP 语法，而在音频质量、ASR 错字率、以及 LLM 对口语省略和指代的理解。飞书客户端里那个“一键生成”，背后是整套工程优化过的 pipeline，不是换几个 API 密钥就能平移的。
