Skill: tianyilt/feishu-writing-bundle (version 1.0.1)

--- name: feishu-writing-bundle description: 飞书文档写作整合包。把飞书文档创建、增量更新、局部精准改稿、proposal 正式化、人味化改写、飞书回链交付等能力整合到一个自包含文件中。用于“检索资料后写飞书文档”“把草稿改成能发的文档”“改飞书演讲稿/方案/说明文”“写完后返回飞书文档链接”等场景。适合新的龙虾直接上手，不依赖先认识其他 feishu-* skills。 --- # 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. 用户本人能够打开该链接；若不能，应继续处理权限/空间/授权问题，直到可访问或明确受限 如果以上条件缺了一条，就说明这项任务还没真正收尾。


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)