Feishu Writing Bundle

Feishu Writing Bundle

Overview

这个整合包的目标很简单：让一个新的龙虾，只看这一份文件，就知道怎么完成飞书文档相关任务。

它覆盖的是一整条写作链路，而不是某一个零散动作：

1. 先读材料 / 检索资料
2. 判断是新建文档还是修改已有文档
3. 判断是普通说明文、演讲稿改稿，还是正式 proposal / 申请材料
4. 决定是直接创建飞书文档，还是对已有文档做局部更新
5. 做必要的人味化、正式化处理
6. 最后把飞书文档链接回给用户

这个 Skill 设计目标是单独拎出来也能用。它不依赖同目录之外的其他 Skill 文件；即使使用者完全没读过别的飞书 Skill，也应当能只靠这个 bundle 完成主要任务。下面会把真实工作流里的职责直接讲清楚。

如果需要补充材料，优先读：

• references/quick-reference.md：速查手册（工具调用速查、语法速查、7种更新模式）
• references/best-practices.md：完整最佳实践（工作流、Lark Markdown 语法、代码示例、反模式）
• references/open-box-rules.md：开箱即用与权限/空间补救规则
• references/workflows.md：常见工作流
• references/style-guide.md：风格与交付规则
• references/skill-map.md：相关能力地图（所有能力已内联，不依赖外部 skill 文件）

Core Principle

飞书文档任务的完成标准，不是“我在聊天里写了一段像文档的话”，而是：

• 文档真的创建出来了，或者真的改进去了
• 结果在飞书里可继续协作
• 最终把链接回出来了

也就是说，飞书文档是交付物，聊天消息只是交付说明。

如果用户要求“写个飞书文档”，最后只回一大段纯文本，没有建文档、没有链接，这不算真正完成。

文档自包含原则（新增默认规则）

飞书文档默认不是聊天消息的延长线，而是一个会被单独打开、转发、收藏、长期留存的交付物。

因此默认要求：即使读者完全没看过聊天上下文，也应该能读懂这份文档。

写作或改稿时，要主动判断并补足这些上下文是否应该出现在文档开头或前部：

• 这份文档到底在讲什么
• 原始对象是什么（视频、会议、方案、链接、数据表、任务、聊天整理等）
• 来源链接 / 原文链接 / 视频链接 / 编号
• 时间信息（发布时间、会议时间、整理时间、数据抓取时间）
• 阅读对象 / 适用范围
• 必要时补一句“本文档基于什么材料整理而成”

尤其在这些场景里，默认要补：

• 从视频、会议、聊天记录、群消息或网页链接整理成飞书文档
• 标题本身不足以交代对象来源
• 文中大量使用“这期视频 / 这次会议 / 上面这个方案 / 原文”之类依赖上下文的指代
• 文档未来大概率会脱离当前聊天被转发或单独阅读

一句话理解：

飞书文档默认要写成脱离聊天上下文也能成立的文本。

What This Bundle Integrates

这份整合包实际上把 7 类能力揉到了一起，下面不按“技能名”，而按“你在工作里会遇到的动作”来讲。

1. 读材料 / 读现有飞书文档

很多任务不是从零开始写，而是：

• 先看已有飞书文档
• 先读资料
• 先梳理上下文
• 再重写 / 总结 / 改稿

所以第一类能力是：读取已有内容，作为写作输入端。

适用场景：

• “先看看这篇飞书文档，然后帮我改”
• “把这些资料整理成一份说明文档”
• “根据组织里现有材料，写个 onboarding 文档”

基本原则：

• 不要没读原文就直接开写
• 不要把想象当成原始材料
• 如果材料分散，先提炼骨架，再进入写作

一句话理解：

真正的写作，往往先从读开始。

2. 从 0 创建飞书文档

当任务目标是“把东西写成一篇飞书文档”时，核心动作不是聊天输出，而是：创建飞书文档。

创建时要遵循这些规则：

• 标题通过文档 title 传，不要在正文开头重复一个同名一级标题
• 正文结构要清楚，层级尽量稳定
• 合理使用飞书的结构元素：
  • callout：强调重点
  • 表格：做对比和汇总
  • mermaid：画流程图 / 架构图
  • 分栏：做并列展示
• 不要为了“炫”乱用格式

适合场景：

• 入门文档
• 说明文档
• 周报 / 纪要整理版
• 调研总结
• 新同学 onboarding 文档

一句话理解：

这是“把内容真正落成飞书文档”的能力。

3. 更新已有飞书文档，而不是整篇洗掉

真实协作里，比“从零写一篇”更常见的是：

• 给已有文档补一节
• 替换某个章节
• 在某个标题后插入说明
• 删除过时内容
• 微调已有段落

这时候最重要的原则是：默认不要整篇覆盖。

应优先做：

• append：在后面补
• insert_before / insert_after：在特定位置前后插入
• replace_range / replace_all：精确替换某一块
• delete_range：删除某段过时内容

不要动不动就 overwrite 整篇，除非用户明确说“整篇重写”或者原文确实已经没法救。

一句话理解：

在飞书协作环境里，增量更新通常比整篇重写更专业。

4. 局部精准改稿

这是和“普通更新”不太一样的一类能力。

有些任务里，用户其实不是要你“加内容”，而是要你：

• 改表达
• 调语气
• 收结构
• 精修某几段
• 帮演讲稿/说明文更顺、更稳

这时候应该采用的不是“整篇重写思维”，而是：

• 先判断哪些段需要改
• 只改必要部分
• 保留原文结构、原文意图、上下文关系
• 不要把作者本来想说的话洗成另外一种东西

这个动作最适合：

• 演讲稿
• 方案文的某几段
• 内部说明文
• 已有草稿的保守精修

一句话理解：

这是“稳、细、克制”的改稿能力。

5. 去 AI 腔 / 提高人味

很多时候一篇文档的问题，不是信息错了，而是：

• 太像模型写的
• 套话太多
• 总结句太整齐
• 语气太平，像模板拼出来的
• 看起来“很像在完成任务”，不像真的在表达

这时候要做的，不是重写所有内容，而是：

• 消掉空泛拔高
• 去掉僵硬排比
• 减少“泛泛正确”的总结句
• 保留信息密度
• 让句子更像真实作者会写出来的样子

注意：

• 人味化 ≠ 把文档写油
• 人味化 ≠ 多加情绪
• 人味化的目标是可信、自然、不过度像机器

一句话理解：

这是“把一篇正确但假假的文档，收成像人写的”的能力。

6. Proposal / 申请材料正式化

有一类文档，不能只追求“顺”和“自然”，还必须追求：

• 正式
• 可评审
• 可提交
• 结构经得起看

比如：

• proposal
• 项目申请书
• 正式汇报文档
• 给老师 / 评审 / 管理者看的材料

这种场景下，工作重点不是普通润色，而是：

• 重建论证结构
• 收紧语气
• 避免聊天体
• 减少碎列表和拼贴感
• 让整篇像正式材料，而不是聊天整理稿

可以把它理解成：

• 普通写作解决“看得懂”
• proposal 正式化解决“能拿去发”

一句话理解：

这是“把草稿抬升到正式材料标准”的能力。

7. 飞书交付回链

这个动作极其重要，也最容易被忘。

飞书文档任务做完以后，默认应该：

• 把文档链接发回来
• 最多再补一句说明这份文档是什么、做了什么处理

而不是：

• 只说“我写完了”
• 只在群里粘一大段内容
• 让用户自己再问一次“链接呢”

所以，飞书文档任务的最后一步必须显式检查：

Final checklist

• 文档是不是已经创建 / 更新成功？
• 有没有拿到文档 URL？
• 有没有把 URL 回给用户？

一句话理解：

不回链，等于没完整交付。

Workflow Decision Tree

下面直接给出几种最常见场景的处理方法。新的龙虾可以照着走。

场景 A：检索资料后写一篇新飞书文档

用户常见说法：

• “检索下资料，写个入门文档”
• “帮我整理成一篇飞书文档”
• “搜一下组织里相关文档，再写个说明”

处理流程：

1. 先检索资料
2. 读最核心的几份材料
3. 提炼出结构骨架
4. 先写成结构化正文
5. 需要时做人味化 / 正式化处理
6. 创建飞书文档
7. 回传飞书链接

输出标准：

• 不是只给群里一版摘要
• 必须真的创建飞书文档
• 最终应返回链接

场景 B：已有飞书文档，需要局部改稿

用户常见说法：

• “帮我改这篇飞书文档”
• “改下这篇演讲稿”
• “把这段写顺一点”
• “这一节帮我重写下”

处理流程：

1. 先读原文
2. 判断修改目标：是提表达、改结构、收语气，还是补信息
3. 尽量局部改，不要整篇洗掉
4. 把修改精确落到文档里
5. 回链，并可简要说明改了哪些部分

输出标准：

• 默认保守修改
• 保留原结构
• 除非明确要求，否则不要 overwrite 全文

场景 C：把草稿改成能发的 proposal

用户常见说法：

• “改成能发的 proposal”
• “不要 AI 腔，要正式一点”
• “这个申请文档帮我重构下”

处理流程：

1. 读取原稿
2. 判断原稿的问题：是逻辑散、语气松、结构不对，还是像聊天记录
3. 重建为正式材料结构
4. 去掉 AI 腔和碎列表感
5. 创建新文档或更新既有文档
6. 回传链接

输出标准：

• 更像正式提交材料
• 不像聊天纪要或口头整理稿

Writing Rules

1. 文档是交付物，不是聊天记录

文档至少应该有：

• 明确标题
• 清楚层级
• 稳定段落节奏
• 足够信息密度
• 方便继续协作的结构

2. 先保证结构，再谈修辞

坏文档通常不是败在词藻不够，而是败在：

• 没结构
• 没主线
• 全是并列碎点
• 读者看不出重点

所以默认优先：

• 结构
• 层次
• 信息组织
• 交付完整度

3. 默认克制用格式

飞书支持很多花样，但不要滥用。

推荐：

• callout：提重点
• 表格：做对比
• mermaid：画流程
• 分栏：做并列展示

不推荐：

• 到处上色
• 每段都加粗
• 乱堆装饰性块

4. 默认不要用“聊天体”写正式文档

正式材料里少用：

• “其实”
• “大概就是”
• “然后这里我们就”
• “总的来说还是比较”

这些口气在口头交流里自然，在文档里容易显得松。

5. 写完一定检查“能不能发出去”

最后自问：

• 这是一篇草稿，还是一篇能交付的文档？
• 如果用户现在转发给别人，会不会显得不成熟？
• 链接是不是已经给出？

Recommended Output Template

当任务完成后，默认可以用这种很短的交付格式：

• 一句话说明文档是什么
• 直接给出飞书文档链接
• 如有必要，再补一句做了哪些关键处理

例如：

我已经整理成飞书文档了，重点补了结构、命令速查和权限排障这几块。
链接：

重点是：短，但完整。

Common Failure Modes

失败 1：只在聊天里给摘要，没创建文档

问题：用户要的是飞书文档，不是聊天长回复。

修正：创建文档，再回链。

失败 2：改稿时整篇洗掉

问题：真实协作里，大家通常要的是保守精修，不是换一个作者。

修正：默认局部改，除非明确要求整篇重写。

失败 3：文档太像 AI 写的

问题：结构可能没错，但读感不可信。

修正：去套话、去机械排比、去空泛总结，保留信息密度。

失败 4：proposal 写成聊天纪要

问题：正式材料不能像内部群聊整理。

修正：重建结构，收紧语气，减少碎点拼贴。

失败 5：忘了回链接

问题：用户还得追问一次“文档呢”。

修正：把回链当成默认最后一步。

Minimal Mental Model for New Lobsters

如果新的龙虾只想记住一段话，就记这段：

再压缩成三句话：

1. 先读，再写。
2. 默认局部改，不乱洗稿。
3. 写完必须回链。

只要把这三条守住，飞书文档协作能力就不会太差。

Reference Docs

这个 Skill 开源时，建议把下面两篇文档作为参考资料挂进去，帮助其他 OpenClaw 使用者快速理解真实产物与实际操作链路：

• OpenClaw 飞书写作最佳实践（用户可访问版）：
  • https://fudan-nlp.feishu.cn/wiki/WZVMwUEnXiHUqLkfzDycSp9en2c?from=from_copylink
• 现有飞书写作参考文档：
  • https://fudan-nlp.feishu.cn/docx/HdWfdNomtoGd7yxL3gVcFgrhnnb

如果 Skill 目录允许放 references 文件，优先把这两条放进独立 reference，而不是只埋在正文里。

Final Standard

完成这类任务时，默认结果应满足：

1. 飞书文档已创建或已更新
2. 文档内容结构化、可交付
3. 处理方式符合场景：
   • 普通说明文 → 结构清晰
   • 演讲稿/改稿 → 局部精准
   • proposal → 正式可发
4. 最终已返回飞书文档链接
5. 用户本人能够打开该链接；若不能，应继续处理权限/空间/授权问题，直到可访问或明确受限

如果以上条件缺了一条，就说明这项任务还没真正收尾。