Speech Notes

将录音/语音转写为结构化演讲纪要。适用于：会议讲话、内部分享、演讲录音的转写整理。 触发条件：用户发送音频文件并要求整理/转写/纪要，或要求将已有转写文本整理成结构化纪要。

Security Scan

The skill's stated goal (turn audio into structured speech notes) matches its instructions, but the runtime instructions require local tools, scripts, and external API credentials that the skill did not declare or provide — this mismatch deserves caution.

Purpose & Capability

The name/description (transcribe + organize speech) aligns with the instructions. However the SKILL.md expects use of local binaries (ffmpeg/ffprobe), a local script (scripts/speech-to-text.sh for Feishu STT), and multiple external STT/LLM endpoints (Google Generative Language, Qwen) — none of these are declared in the skill metadata (no required binaries, no env vars, no scripts). That discrepancy is disproportionate and unexplained.

Instruction Scope

The instructions explicitly tell the agent to run ffprobe/ffmpeg (file splitting/compression), call a local script for Feishu STT, craft Python scripts to send base64 audio to generativelanguage.googleapis.com, and use Qwen endpoints and Feishu document APIs. They also instruct saving original transcriptions locally and updating Feishu documents via API. Those actions involve local file I/O and network calls to multiple external services; the skill did not limit or declare these resources or credentials and did not include the referenced scripts, so the runtime scope is broader than the metadata indicates.

Install Mechanism

There is no install spec and no code files — instruction-only. That minimizes supply-chain risk. However the SKILL.md instructs running external tools and scripts that are not provided; the absence of a provisioned install still leaves the agent expected to have certain binaries and scripts available on the host.

Credentials

The documentation prescribes calling Feishu STT (file_key), Google Generative Language, and Qwen services and also using Feishu document APIs, which normally require credentials/tokens. Yet the skill metadata lists no required environment variables or primary credential. Requiring multiple external API keys and a local script without declaring them is disproportionate and ambiguous — the user would need to supply keys/credentials out-of-band for the skill to work.

Persistence & Privilege

always is false and the skill is user-invocable; it does not request permanent presence or elevated platform privileges. The instructions do ask the agent to write local files (save original transcriptions) and to update remote Feishu docs, which are normal for this function but should be acknowledged by the user before installation.

What to consider before installing

This skill's functionality (audio → structured notes) is reasonable, but the runtime instructions assume tools and API access that aren't declared or included. Before installing or enabling it, ask the provider: (1) where do scripts like scripts/speech-to-text.sh come from, (2) what credentials are required and how will you supply them (Feishu file_key, Feishu API token, Google API key, Qwen token), and (3) whether ffmpeg/ffprobe are expected on your host. Only provide API keys with minimal scopes and consider testing with non-sensitive audio first. If you can't obtain answers or the skill asks you to paste credentials into an opaque place, treat it as high risk and do not proceed.

演讲纪要整理 Skill

将录音转写为高质量的结构化演讲纪要。整个流程分两步：转写和整理。

第一步：转写

音频预处理

• 用 ffprobe 获取时长、采样率等信息
• 超过 5 分钟的录音：用 ffmpeg -f segment -segment_time 300 分段（每段 5 分钟）
• 每段压缩：ffmpeg -ar 16000 -ac 1 -b:a 32k（降低体积，提高 API 成功率）

转写方式（优先级）

1. 飞书 STT：如有 file_key，调用 scripts/speech-to-text.sh --feishu-file-key <key>
2. 分段 Gemini：写 Python 脚本，逐段调用 generativelanguage.googleapis.com，用 inline_data 传 base64 音频
3. 分段 Qwen：DashScope qwen-omni-turbo，同上方式

转写 Prompt

请精确转写这段中文语音的全部内容，保留原始表述和口语化表达，不要遗漏任何内容。只输出转写文字。

注意事项

• Gemini 转写可能繁简混杂（同一段落出现繁体和简体），整理时需统一
• 保存原始转写到本地文件备查

第二步：整理

文档结构（必须包含）

# [标题：有观点、有张力，不要纯描述]

> 整理自 [谁] 于 [日期] 在 [场合] 的讲话要点     ← 引用容器，居中对齐

## 一、[主题板块]
### [三级标题]
正文段落 / bullet 列表

---                    ← 分隔线：仅在 H2 之间使用

## 二、[主题板块]
...

核心原则

1. 头部三要素

• 谁说的：讲话人姓名和职位
• 什么场合：会议名称、日期
• 标题：提炼核心观点，不要只写「XX会议纪要」
• 头部归属行放在引用容器（飞书 quote_container）中，居中对齐

2. 第一人称视角

• 保留讲话人的第一人称（「我」「我们」），但精简多余的「我」
• 不要改成第三人称（「讲话者认为」）

3. 保留原味，去除口语

• 保留：讲话人的力度表达（「打脸」「浪费生命」「给它打工」）、场景中的人物称呼（群里叫「铎神」就写「铎神」，不要改成全名）
• 去除：「呃」「就是说」「怎么讲」等填充词、重复的句子、碎碎念式的过渡

4. 不加 AI 痕迹

• 不要在文档底部写「本文由 AI 转写整理」
• 不要加「原始录音约 XX 分钟」
• 交付的是一份正式纪要，不是 AI 产物

---

⭐ 排版格式规范（最重要的部分）

这些规则来自对高质量终稿的 block 级逆向分析。排版直接决定文档的可读性。

标题层级严格分工

层级	飞书 block_type	用途	数量
H2 (##)	heading2	大板块（一、二、三…）	3-5 个
H3 (###)	heading3	小节主题	每个 H2 下 2-4 个
加粗文本段	text (bold)	子话题标签（不是标题！）	按需

关键区分：

• 「第一，「活人感」」「第二，跨会话记忆」→ 加粗文本段，不是 H3/H4
• 「关于人才输出」→ 加粗文本段，不是 H3
• 只有独立的小节主题才用 H3，如「三个让人印象深刻的瞬间」「时间线与调整计划」
• 规则：如果一个子话题只有 2-3 个 bullet，用加粗文本段；如果有完整的段落+bullet 结构，才用 H3

段落文本 vs Bullet 的选择（核心）

这是 AI 整理纪要最容易犯的错。不是所有内容都该变成 bullet。

用段落文本（text block）的场景：

• 开场白 / 场景铺垫：「在座的各位主管，对大模型的理解，在全行业都处于前沿」
• 过渡引导句：「原因主要有：」「这是一个尚未完全确认的类比，但逻辑上是成立的：」
• 核心结论（加粗）：「核心认知转变：过去认为有一个强模型就够了，今天看来，Scaffold 同样重要。」
• 收束/感召句：「各位，我们有幸生于这个年代」「要把我们的生命投入到这一轮浪潮中」
• 已经足够有力的单句话，不需要拆成 bullet

用 Bullet 的场景：

• 并列论据/原因（「模型能力跃升」「框架飞速迭代」）
• 叙事序列（先发生A → 然后B → 最后C）
• 对比/映射（「过去：…」「未来：…」）
• 具体事例的细节展开

判断公式：这句话是「引出观点」还是「支撑观点」？引出 = 段落，支撑 = bullet。

Bullet 的嵌套与精炼

嵌套规则：

• 最多 3 层（一级 bullet → 二级 sub-bullet → 三级 sub-sub-bullet）
• 一级 bullet = 论点/事件主干
• 二级 sub-bullet = 证据/细节/对话
• 三级仅在必要时使用（如飞轮链条：用户→问题→修复→PR→进化→更多用户）

精炼规则：

• Bullet 前半加粗 + 后半普通：「范式变了，当前的组织必然不高效——无论工作流还是人员配置…」
• 加粗部分是核心论点（可以只扫加粗就读懂全文），后半是解释/证据
• 每个 bullet 控制在 1-2 行，超过就该拆成子 bullet
• 对比用「前缀：内容」格式：「过去：给业务部门交付模型」「未来：Model + API + Scaffold 的体系交付」

引用块（Quote Block）的使用

• 整篇文档只用 1-2 个 引用块，用于最有冲击力的原话
• 如：「今天是在跟时间赛跑。慢一天，能输出的机会就少一点。」
• 飞书引用块可加背景色（background_color: 4 = 绿色背景）增强视觉效果
• 不要 把所有直接引语都做成引用块——太多就失去了强调效果

表格的使用

• 结构化数据（时间线、对照表）用飞书表格，不用 bullet 模拟
• 表头用 H4 加粗，数据行用普通文本
• 适合场景：里程碑/时间线、功能对比、角色分工

呼吸感（空行与分隔线）

• H3 后 空一行再开始内容（如果下面紧跟加粗标签）
• 加粗标签后 直接跟 bullet（不空行）
• bullet 组与下一个加粗标签之间 空一行
• H2 之间 用分隔线 --- + 空行（文档仅在 H2 之间有分隔线，其他地方不用）
• 结语段落之间 空一行（每句话独立成段，增强节奏感）

加粗的层次

加粗不是随便用的，它有明确的层次：

1. 整句加粗（最强调）：核心结论、感召句

   • 「核心认知转变：过去认为有一个强模型就够了，今天看来，Scaffold 同样重要。」
   • 「要把我们的生命投入到这一轮浪潮中，做出真正能改变世界的事情！」

2. Bullet 前半加粗（论点突出）：论据 bullet 的核心部分

   • 「快 = 保人——调整得快，才有可能把人才留在小米体系内」
   • 「模型能力跃升——核心是指令遵循」

3. 关键词加粗（重点标记）：人名、数字、专有名词

   • 「Model + API + Scaffold 的体系交付」
   • 「提出了一个新概念：「体感」」

4. 子话题标签（结构引导）：不用标题，用加粗文本段落

   • 「第一，「活人感」」
   • 「关于人才输出」
   • 「调整分两步：」

---

常见错误（避免）

错误	正确做法
标题写「XX会议纪要」	提炼核心观点作为标题
不交代讲话人和场合	头部引用容器写明三要素
把人物称呼改成正式全名	保留场景中的自然称呼
所有内容都用 bullet	开场、结论、感召用段落文本
所有子话题都用 H3	轻量子话题用加粗文本段
bullet 太长（一个 bullet 一整段）	拆成主句 + sub-bullet
到处加引用块	全文仅 1-2 处最有力的原话
没有空行，内容紧贴	段落间、bullet 组间留呼吸感
过渡句太多（「先从…说起」）	直接进入内容
底部加 AI 声明	不加
所有标题都是「关于XX」	标题风格多样化
时间线用 bullet 列表	结构化数据用飞书表格
加粗没有层次，要么全加要么不加	按 4 层规则使用

润色检查清单

整理完成后逐项检查：

• 标题是否有观点和张力？
• 头部引用容器是否交代了谁、什么场合？
• 人名是否正确？（向用户确认不确定的人名）
• 专有名词是否正确？（产品名、公司名、技术术语）
• 是否统一了简繁体？
• 口语填充词是否清除干净？
• 段落 vs bullet 选择是否正确？（开场/结论/感召 = 段落，论据/事例 = bullet）
• 子话题是否正确分级？（独立小节 = H3，轻量标签 = 加粗文本）
• 每个 bullet 是否有「前半加粗」的论点突出？
• 引用块是否控制在 1-2 处？
• H2 之间是否有分隔线？
• 段落间是否有适当呼吸感？
• 是否保留了讲话人的语言风格和力度？
• 是否去掉了 AI 痕迹？
• 飞书文档格式是否正确（引号用「」不用""）？

交互流程

1. 收到音频 → 告知用户「正在转写，约X分钟」
2. 转写完成 → 先给用户看大纲和文本内容，确认后再写入飞书文档
3. 用户反馈 → 修改（注意：修改飞书文档时，纯样式变更用 API 直接改 block，不要 write 全文覆盖）
4. 如果用户要求改标题颜色等样式 → 用飞书 block API 的 update_text_elements + text_color

飞书 text_color 枚举

值	颜色
1	暗红
2	橙色
3	黄色
4	绿色
5	蓝色
6	紫色
7	灰色

飞书 background_color 枚举（文字背景色）

值	颜色
4	绿色背景（常用于引用块强调）