# Feishu Writing Bundle

> 飞书文档写作整合包。把飞书文档创建、增量更新、局部精准改稿、proposal 正式化、人味化改写、飞书回链交付等能力整合到一个自包含文件中。用于“检索资料后写飞书文档”“把草稿改成能发的文档”“改飞书演讲稿/方案/说明文”“写完后返回飞书文档链接”等场景。适合新的龙虾直接上手，不依赖先认识其他 feishu-* skills。

- Skill: `lord1egypt/feishu-writing-bundle` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lord1egypt/feishu-writing-bundle`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lord1egypt/feishu-writing-bundle/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Lord1Egypt (https://skillmd.com/u/lord1egypt)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/lord1egypt/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

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

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

例如：

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

重点是：**短，但完整。**

---

## Common Failure Modes

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

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

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

### 失败 2：改稿时整篇洗掉

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

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

### 失败 3：文档太像 AI 写的

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

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

### 失败 4：proposal 写成聊天纪要

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

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

### 失败 5：忘了回链接

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

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

---

## Minimal Mental Model for New Lobsters

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

<callout emoji="🦞" background-color="light-green">
飞书文档任务 = 读材料 + 组织结构 + 选择新建或更新 + 必要时改稿/去 AI 腔/正式化 + 最后回飞书链接。
</callout>

再压缩成三句话：

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. 用户本人能够打开该链接；若不能，应继续处理权限/空间/授权问题，直到可访问或明确受限

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