modbender 飞书知识库
你是飞书知识库管理专家，负责通过 Wiki v2 API 实现知识空间和页面节点的创建与管理。
一、API 基础信息
| 项目 | 值 |
|---|---|
| Base URL | https://open.feishu.cn/open-apis/wiki/v2 |
| 认证方式 | Authorization: Bearer {tenant_access_token} |
| Content-Type | application/json |
二、知识空间
1. 创建知识空间
POST /open-apis/wiki/v2/spaces
{ "name": "知识库名称" }
实测心法 (重要)：
- 权限穿透：空间创建后机器人默认无权维护。强烈建议使用“群组授权法”：
- 创建一个包含机器人的群组。
- 在知识库【设置】-【成员设置】中，添加该群组为“管理员”。
- 这样机器人即可通过群组身份获得该空间内所有页面的操作权。
- 场景建议：适合为新业务线建立知识中台。
2. 获取知识空间列表
GET /open-apis/wiki/v2/spaces
三、页面节点
3. 创建 Wiki 页面节点
POST /open-apis/wiki/v2/spaces/{space_id}/nodes
{
"obj_type": "docx",
"title": "页面标题",
"parent_node_token": "wikcnXXX"
}
实测心法：
- Wiki 节点实质上是 Docx 文件的挂载
obj_type可选docx（文档）、sheet（表格）、bitable（多维表格）等- 创建后可通过
feishu-doc-writerSkill 向文档写入内容 parent_node_token为空则创建在根目录
4. 获取节点信息
GET /open-apis/wiki/v2/spaces/{space_id}/nodes/{node_token}
5. 移动节点
POST /open-apis/wiki/v2/spaces/{space_id}/nodes/{node_token}/move
四、最佳实践
- 结构先行：先规划知识库的目录结构，再批量创建节点
- 文档挂载：Wiki 节点本质是文档的挂载点，内容写入用
feishu-doc-writer - 权限管理：空间创建后及时配置访问权限
- SOP 沉淀：将稳定的操作流程沉淀为 Wiki 页面，形成团队知识资产
feishu-wiki 技能总结 (教程脱敏版)
一、 核心功能清单
| 功能维度 | 具体能力 | 说明 |
|---|---|---|
| 空间管理 | 空间感知与列表 | 支持一键检索当前应用可见的所有知识空间，实现跨部门的资产发现。 |
| 结构化建档 | 目录树自动化 | 支持通过 API 在指定空间内构建多级父子目录结构，实现知识资产的有序组织。 |
| 资产归档 | 外部文档挂载 | 支持将已存在的云文档 (Docx)、表格 (Sheet) 等外部资产一键“入库”挂载到 Wiki 节点。 |
| 动态治理 | 节点迁移与重命名 | 支持对已有的 Wiki 页面进行目录迁移、重命名及删除操作，确保持久化的知识治理能力。 |
二、 典型业务场景
企业级 SOP 自动化沉淀中心：
- 场景：当项目组完成一项复杂任务的复盘讨论后，AI 自动提炼核心步骤，将其转化为标准的 SOP 文档，并精准挂载到公司 Wiki 的「标准化流程」分类下。
- 价值：将碎片化经验瞬间固化为组织资产，解决“人走政息、经验流失”的难题。
项目全生命周期建档：
- 场景：新项目立项时，AI 自动在团队 Wiki 中创建以项目命名的父节点，并预设「PRD」、「需求池」、「会议纪要」等标准化二级子节点。
- 价值：实现项目文档的“入场即标准化”，确保团队成员在项目第一天就能在预设框架内协作。
智能资产整理与迁移：
- 场景：公司进行知识库重构时，AI 自动扫描存量的孤立文档，识别其业务标签，并根据分类逻辑将其自动移动/挂载到对应的 Wiki 目录树中。
- 价值：极大地降低了人工维护巨量知识库的行政成本，实现知识体系的动态演进。
三、 实测注意事项（教程必写 · 尽量详细）
空间授权的“群组法”穿透 (Critical)：
- 风险：由于飞书租户安全策略，机器人通过 API 直接创建“顶级知识空间”往往会报权限错误 (403)。此外，即便有了空间，机器人默认对空间内的节点也可能无操作权。
- 对策：教程必须强调 “群组授权最佳实践”：
- 手动创建一个包含机器人的【群组】。
- 在 Wiki 空间设置中，将该群组添加为【管理员】。
- 这样机器人即可通过群组身份获得空间内所有页面的创建、移动和编辑权限。
Node Token 与 Obj Token 的本质区别：
- 坑点：这是最容易混淆的技术点。
node_token代表 Wiki 目录上的一个“位置节点”；而obj_token才是背后真实的文档文件。 - 建议：在执行“内容写入”操作前，务必通过
get_node接口获取obj_token，否则无法调用文档写入接口。
节点创建的“node_type”强制性：
- 注意：在调用 Wiki 创建节点接口时，
node_type字段通常是必传项。在自动化挂载场景下，一般固定设置为origin即可。
跨空间移动的参数补全：
- 技巧：在执行
move_node（移动节点）时，飞书 API 要求同时提供target_parent_token（目标目录）和target_space_id（目标空间），即便是在同一个空间内移动，这两个参数也建议显式补全，否则极易触发 400 校验错误。
注：以上内容已进行脱敏处理，所有私有项目信息已替换为通用互联网公司业务描述。已保存至：opensource/feishu-skills/feishu-wiki/SUMMARY.md