Feishu Writing Bundle

Overview

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

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

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

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

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

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

---

Core Principle

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

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

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

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

---

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

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

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

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

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

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

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

一句话理解：

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

What This Bundle Integrates

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

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

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

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

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

适用场景：

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

基本原则：

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

一句话理解：

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

---

2. 从 0 创建飞书文档

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

创建时要遵循这些规则：

• - 标题通过文档 title 传，不要在正文开头重复一个同名一级标题
• 正文结构要清楚，层级尽量稳定
• 合理使用飞书的结构元素：

- callout：强调重点 - 表格：做对比和汇总 - mermaid：画流程图 / 架构图 - 分栏：做并列展示

• - 不要为了“炫”乱用格式

适合场景：

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

一句话理解：

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

---

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

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

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

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

应优先做：

• - append：在后面补
• insertbefore / insertafter：在特定位置前后插入
• replacerange / replaceall：精确替换某一块
• delete_range：删除某段过时内容

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

一句话理解：

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

---

4. 局部精准改稿

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

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

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

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

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

这个动作最适合：

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

一句话理解：

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

---

5. 去 AI 腔 / 提高人味

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

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

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

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

注意：

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

一句话理解：

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

---

6. Proposal / 申请材料正式化

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

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

比如：

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

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

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

可以把它理解成：

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

一句话理解：

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

---

7. 飞书交付回链

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

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

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

而不是：

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

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

Final checklist

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

一句话理解：

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

---

Workflow Decision Tree

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

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

用户常见说法：

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

处理流程：

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

输出标准：

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

---

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

用户常见说法：

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

处理流程：

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

输出标准：

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

---

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

用户常见说法：

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

处理流程：

1. 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

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

飞书文档任务 = 读材料 + 组织结构 + 选择新建或更新 + 必要时改稿/去 AI 腔/正式化 + 最后回飞书链接。

再压缩成三句话：

1. 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. 1. 飞书文档已创建或已更新
2. 文档内容结构化、可交付
3. 处理方式符合场景：

- 普通说明文 → 结构清晰 - 演讲稿/改稿 → 局部精准 - proposal → 正式可发

1. 4. 最终已返回飞书文档链接
2. 用户本人能够打开该链接；若不能，应继续处理权限/空间/授权问题，直到可访问或明确受限

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