# 办公 Skill 编排对决：Google、飞书、Notion 的三条路线 ## 概述 本期是 Skills 生态系列第 4 轮，主题为内容创作与办公类横向评测。翻译、表格、演示、写作四条赛道的单品头牌此前都拆过（baoyu-translate、xlsx、pptx、writing-great-skills），本期把镜头拉高一层：办公场景的竞争焦点已经从「单个文档技能」上移到**编排层**——谁能把「查资料 → 写文档 → 发邮件 → 排会议」这类多步流程预编译进 Skill。三个玩家恰好代表三条路线：Google `googleworkspace/cli` 的**编译型**（recipe 剧本 + persona 角色由 Rust 构建时生成，两天内从 92 个技能扩到 107 个）、Notion 的**解释型**（SKILL.md 写流程、MCP 工具当手，meeting-intelligence 六步流水线）、飞书的**事务型**（CLI 封装 + 退出码门禁，双渠道合计约 2200 万安装）。本期对 `gws-gmail-send` 做逐段深拆——它暴露了一个此前周报没讲到的设计：**自愈式依赖声明**。数据抓取于 2026-08-30，口径混杂处均已标注。 ## 生态坐标：编排层成了大厂的新战场 先看三个玩家在本周 skills.sh 榜单上的位置（2026-08-30 抓取）： | 玩家 | 渠道 | 体量 | 代表编排位 | |---|---|---|---| | 飞书 | open.feishu.cn（域名直发） | 24 个技能合计约 1420 万安装，lark-doc 596.3K 居总榜第 13 | lark-base 趋势榜第 36（7.8K） | | 飞书 | larksuite/cli（GitHub） | 约 790 万安装，lark-doc 420.0K 总榜第 70 | lark-base 趋势榜第 78（4.9K） | | Google | googleworkspace/cli | 仓库页显示 107 个技能、合计 119.7K 安装 | gws-gmail-send 位列 24 小时趋势榜第 67 | | Notion | makenotion/notion-cookbook | 安装量未进总榜前段 | meeting-intelligence 走 GitHub 分发 | 两个值得记住的动态：一是 **Google 在两天内把技能数从 92 扩到 107**（8-28 周报口径 92，今日仓库页口径 107），新增部分明显向管理面倾斜——gws-vault、gws-licensing、gws-reseller、gws-alertcenter、gws-cloudidentity、gws-groupssettings、4 个 gws-modelarmor 变体悉数在列，企业 IT 的「管人管权管安全」场景正在被批量技能化；二是今日两次快照显示 skills.sh 不同页面的安装基数不一致（首页全时计数 1,273,375 vs 趋势页 917,217），各页缓存口径混杂，本文安装量一律标注口径，名次仅作热度参考。 按今日仓库页清点，googleworkspace/cli 的 107 个技能构成为：gws-* 服务与助手约 42 个、gws-workflow-* 跨服务工作流 5 个（standup-report、email-to-task、weekly-digest、meeting-prep、file-announce）、recipe-* 剧本 50 个、persona-* 角色 10 个，外加 admin/modelarmor 等管理面长尾。与 8-28 周报相比，**recipe 从 41 涨到约 50**——Google 用两天时间补的正是「多步办公流程」这块板。 ## 评测对比表 | 套件 / 技能 | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15% | 社区活跃 15% | 加权 | |---|---|---|---|---|---|---| | 飞书 lark 家族（lark-doc/lark-base 样本） | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | **4.6** | | gws 编排层（recipe/persona/workflow 全层） | ★★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★★ | **4.4** | | gws-gmail-send（单技能） | ★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★★ | **4.3** | | notion-meeting-intelligence | ★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★ | **4.0** | 评分说明：上手难度星级越高越容易上手。gws 全层扣分在需要先装 `gws` 二进制并完成 OAuth；Notion 扣分在必须挂载 MCP 服务器，且其 SKILL.md 强绑定 Notion schema，离开 Notion 几乎不可用（本系列 6-27 文结论，本期维持）；飞书体量与迭代速度为其加了社区满分。 ## 主拆解：gws-gmail-send，一封邮件里的四个设计决策 以下逐段分析基于 skills.sh 抓取的 SKILL.md 原文（2026-08-30）。它是 gws 家族的「第一封邮件」入口，1.6K 安装（仓库页口径），但麻雀虽小，四个设计决策个个有讲头。 ### 第 1 段：标题就是命令——「gmail +send」 SKILL.md 正文第一行不是介绍，而是 `# gmail +send`。技能文件名 `gws-gmail-send` 与 CLI 命令 `gws gmail +send` 严格一一对应：**文件名即命令行**。这套「加号动词」命名法把服务（gmail）和动作（+send）拆成两个轴——gws-gmail 是服务参考文件，gws-gmail-send 是挂在服务下的动词助手。对模型的好处是零翻译成本：读到技能名就知道敲什么命令，不需要任何「技能→工具」的映射表。对比飞书的 lark-doc（按文档类型命名）和 Notion 的 meeting-intelligence（按场景命名），Google 是唯一把**命令语法**编进技能名的。 ### 第 2 段：自愈式 PREREQUISITE——依赖缺失时给出修复命令 原文第一段引用块值得整段抄录： > **PREREQUISITE:** Read `../gws-shared/SKILL.md` for auth, global flags, and security rules. If missing, run `gws generate-skills` to create it. 大多数 Skill 的共享底座引用只做一半：告诉你「先读某某文件」，至于文件不在怎么办，没下文。gws-gmail-send 把**恢复动作**写进了依赖声明——gws-shared 丢失时，跑一条 `gws generate-skills` 就能现场重建。这是「技能即构建产物」路线的自然延伸：既然所有技能都能从 Rust 源码再生成，那依赖损坏就不是错误而是一次重编译。8-28 周报拆 gws-shared 时讲过它的认证与四条安全规则，但这个自愈条款是编排层独有的设计——它把技能间的依赖从「软引用」升级成了「可自修复的硬引用」。反观飞书的 lark-shared 底座是强引用无自愈（靠退出码 10 门禁兜底），Notion 则靠 MCP 服务器常驻来回避文件依赖问题。三种依赖哲学，高下且不论，工程完成度上 Google 这手最漂亮。 ### 第 3 段：Usage——把参数契约写成最小命令 ``` gws gmail +send --to --subject --body ``` 三个必选参数全部显式化，CC/BCC、send-as 别名地址为可选。设计上真正加分的是摘要里的这句：支持 HTML 正文但 **HTML 片段不需要包裹标签**——模型最常见的翻车点就是自作主张包一层 `` 导致邮件客户端渲染异常，技能直接把这个坑提前填了。send-as 别名则瞄准企业多身份场景（一个人挂着 n 个发件地址），这是通用邮件技能不会碰、企业用户天天撞的边界。 ### 第 4 段：Flags——安全边界全部预编译进参数 三个安全设计挤在 flag 层：一是 `--dry-run`，发送前可预览完整请求，给了一个不碰真实发信的演练通道；二是附件上限 25MB（多附件用重复 `--attach`），与 Gmail 真实限制对齐，避免模型生成必然失败的调用；三是「自动 RFC 5322 格式化与 MIME 编码」——这句话的潜台词是模型**不需要也不应该手工构造邮件协议层**，格式合法性由 CLI 保证。发邮件是办公自动化里风险最高的动作（外发不可撤回），这个技能把防线修在了参数契约层而不是提示词层，比写十句「请谨慎发送」都管用。 ## 三条编排路线：编译、解释、事务 把三个玩家的编排方式画在一张图上： ```mermaid flowchart LR U((办公用户多步任务)) subgraph G[Google 编译型] A1[Rust 源码] --> A2[gws generate-skills] A2 --> A3[50 recipe + 10 persona + 5 workflow] A3 --> A4[PREREQUISITE 自愈] end subgraph N[Notion 解释型] B1[SKILL.md 六步流程] --> B2[MCP 三钥匙 search/fetch/create-pages] B2 --> B3[预读 + 议程双文档回写] end subgraph F[飞书 事务型] C1[lark-shared 底座] --> C2[退出码 10 高危门禁] C2 --> C3[lark-doc / lark-base 文档事务] end U --> G U --> N U --> F ``` **Google 的编译型**：流程在构建时就固化成剧本。50 个 recipe 覆盖了办公自动化的高频闭环——recipe-draft-email-from-doc（文档起草件转邮件）、recipe-generate-report-from-sheet（表格生成报告）、recipe-save-email-to-doc（邮件归档成文档）、recipe-create-events-from-sheet（表格批量建日程），邮件、文档、表格、日历四件套在剧本层互相咬合。10 个 persona 则把角色心智模型直接做成入口：persona-exec-assistant、persona-project-manager、persona-content-creator、persona-hr-coordinator 等。优点是确定性强、上下文省（平时只加载 1KB 级 Helper），缺点是剧本外的流程没有自由度。 **Notion 的解释型**：SKILL.md 只写「检索 → 抓取提炼 → 补充背景 → 生成对内预读与对外议程双文档 → 回写互链」六步程序，具体执行交给 MCP 三把钥匙在运行时组合。它没有任何预编译剧本，弹性最大，也是三者中唯一做到「一份输入、两份面向不同读者的输出」的——对内预读和对外议程分开生成，这个信息分级意识至今仍是办公类 Skill 的独一份。代价是每一步都消耗模型推理，且强绑定 Notion 数据模型。 **飞书的事务型**：本系列 8-29 文已逐段拆过 lark-doc 与 lark-shared，这里只给编排视角的定位——它把每个办公动作封装成带退出码的 CLI 事务，高危操作有退出码 10 门禁，文档是唯一中心（lark-doc 双渠道合计百万级安装），编排发生在文档的创建-流转-协作链上而非跨服务剧本上。双渠道分发（域名直发 + GitHub CLI）是它独有的规模武器：同一套技能，国内走 open.feishu.cn（24 技能 1420 万安装），国际版走 larksuite/cli（约 790 万），分渠道独立计数、合力虹吸。 三条路线的共同启示：**办公自动化的竞争力不在「会调几个 API」，而在把企业流程的确定性、权限边界和失败恢复预编译进 Skill 结构本身。** ## 内容创作被大厂「收编」了吗 回到本轮主题的另一半：内容创作。本周最大的信号不是某个写作 Skill 登榜，而是**内容创作正在被大厂收编为角色与剧本**：Google 把它拆成了 persona-content-creator（内容创作者角色包）+ recipe-create-presentation（一键演示文稿）+ recipe-draft-email-from-doc（文档转邮件草稿）；飞书有 lark-doc 直接生成文档；Notion 有 research-documentation 把调研变成结构化内容。 对照 8-29 文的独立内容头牌（baoyu-translate 加权 4.50、writing-great-skills），结论是两条线正在分化而非替代：独立内容 Skill 的护城河在**文风与术语控制**（宝玉的三模式翻译、去 AI 味纪律），大厂编排层的优势在**通道与权限**（能真的把内容发出去、归档、共享）。内容生产者和办公自动化用户应该各取所需：写作质量交给独立 Skill，交付链路交给厂商套件——把两者串起来（比如用 gws-gmail-send 发送 baoyu-translate 的产出）正是下一批复合工作流的形态。 ## 安装命令 ```bash # Google gws 全家桶（107 技能，需另装 gws 二进制并完成 OAuth） npx skills add googleworkspace/cli # 飞书 lark 家族（国际版 GitHub 渠道；国内可用 open.feishu.cn 站点直发） npx skills add larksuite/cli # Notion meeting-intelligence（先挂载 Notion MCP：notion-search / notion-fetch / notion-create-pages） git clone https://github.com/makenotion/notion-cookbook cp -r notion-cookbook/skills/claude/meeting-intelligence ~/.claude/skills/ ``` 单装 gws 的邮件动词技能：`npx skills add googleworkspace/cli` 后按需读取 gws-gmail-send，缺失 gws-shared 时执行 `gws generate-skills` 自愈。 ## 推荐排行榜 - **按工程完成度**：gws 编排层 ＞ 飞书 lark ＞ Notion meeting-intelligence（自愈式依赖声明是当前生态最先进的一段 SKILL.md） - **按安装体量**：飞书（双渠道约 2200 万）＞＞ Google（119.7K，增速最陡）＞ Notion（走 GitHub 分发，未进总榜前段） - **按编排弹性**：Notion ＞ Google ＞ 飞书（解释型流程可自由组合，编译型只覆盖预置剧本） - **按新手友好**：飞书 ＞ Google ＞ Notion（lark 开箱即用；gws 要装二进制加 OAuth；Notion 要配 MCP） - **一句话**：要规模和文档深度选飞书，要流程确定性选 Google，要「一次输入两份产出」的信息分级编排学 Notion——而无论选谁，先看懂 gws-gmail-send 那 62 个词的 PREREQUISITE，它代表了 Skill 依赖管理的下一步。 ## 参考来源 1. [skills.sh 首页总榜](https://skills.sh) — All Time 榜单：lark-doc 596.3K 第 13、larksuite/cli 7.9M、open.feishu.cn 14.2M 等口径（2026-08-30 抓取） 2. [googleworkspace/cli 仓库页](https://skills.sh/googleworkspace/cli) — 107 技能全目录、119.7K 累计安装、recipe/persona/workflow 构成清点 3. [gws-gmail-send 技能页](https://skills.sh/googleworkspace/cli/gws-gmail-send) — SKILL.md 原文：PREREQUISITE 自愈条款、+send 语法、--dry-run、RFC 5322/MIME、25MB 附件 4. [skills.sh Trending 24h](https://skills.sh/trending) — gws-gmail-send 第 67、lark-base 双渠道第 36/78 名 5. [googleworkspace/cli GitHub 仓库](https://github.com/googleworkspace/cli) — gws CLI 与技能源码分发主仓 6. [makenotion/notion-cookbook](https://github.com/makenotion/notion-cookbook) — meeting-intelligence 六步流水线 SKILL.md 所在仓库（六步细节引自本系列 6-27 文对其原文的拆解） > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。