Wiki 链接特殊处理（关键！）

知识库链接（/wiki/TOKEN）背后可能是云文档、电子表格、多维表格等不同类型的文档。不能直接假设 URL 中的 token 就是 file_token ，必须先查询实际类型和真实 token。

处理流程

1. 使用wiki.spaces.get_node 查询节点信息

   lark-cli wiki spaces get_node --params '{"token":"wiki_token"}'

2. 从返回结果中提取关键信息

   • node.obj_type：文档类型（docx/doc/sheet/bitable/slides/file/mindnote）
   • node.obj_token：真实的文档 token （用于后续操作）
   • node.title：文档标题

3. 根据obj_type 使用对应的 API

查询示例

# 查询 wiki 节点
lark-cli wiki spaces get_node --params '{"token":"wiki_token"}'

返回结果示例：

{
  "node": {
    "obj_type": "docx",
    "obj_token": "xxxx",
    "title": "标题",
    "node_type": "origin",
    "space_id": "12345678910"
  }
}

资源关系

Wiki Space (知识空间)
└── Wiki Node (知识库节点)
    ├── obj_type: docx (新版文档)
    │   └── obj_token (真实文档 token)
    ├── obj_type: doc (旧版文档)
    │   └── obj_token (真实文档 token)
    ├── obj_type: sheet (电子表格)
    │   └── obj_token (真实文档 token)
    ├── obj_type: bitable (多维表格)
    │   └── obj_token (真实文档 token)
    └── obj_type: file/slides/mindnote
        └── obj_token (真实文档 token)

Drive Folder (云空间文件夹)
└── File (文件/文档)
    └── file_token (直接使用)

常见操作 Token 需求

评论能力边界（关键！）

• drive +add-comment 支持两种模式。
• 全文评论：未传 --selection-with-ellipsis / --block-id 时默认启用，也可显式传 --full-comment；支持 docx、旧版 doc URL，以及最终解析为 doc/docx 的 wiki URL。
• 局部评论：传 --selection-with-ellipsis 或 --block-id 时启用；仅支持 docx，以及最终解析为 docx 的 wiki URL。
• drive +add-comment 的 --content 需要传 reply_elements JSON 数组字符串，例如 --content '[{"type":"text","text":"正文"}]'。
• 如果 wiki 解析后不是 doc/docx，不要用 +add-comment。
• 如果需要更底层地直接调用评论 V2 协议，再走原生 API：先执行 lark-cli schema drive.file.comments.create_v2，再执行 lark-cli drive file.comments create_v2 ...。全文评论省略 anchor，局部评论传 anchor.block_id。

评论查询与统计口径（关键！）

• 查询文档评论时，使用 drive file.comments list。
• drive file.comments list 返回的 items 应理解为"评论卡片"列表，每个 item 对应用户界面里看到的一张评论卡片，而不是平铺的互动消息列表。
• 服务端语义上，创建第一条评论时会同时创建该卡片里的第一条 reply；因此真正承载正文的是每个 item.reply_list.replies，其中第一条 reply 在用户视角下就是这张卡片里的"评论本身"。
• 当用户要统计"评论数"或"评论卡片数"时，统计 items 的长度即可；如果是全量统计，则对所有评论分页返回的 items 长度累加。
• 当用户要统计"回复数"时，按用户视角应排除每张评论卡片里的首条评论，统计口径是所有 item.reply_list.replies 的长度之和减去 items 的长度。
• 当用户要统计"总互动数"时，统计所有 item.reply_list.replies 的长度之和即可；这个口径包含每张评论卡片里的首条评论。
• 如果某个 item.has_more=true，说明该评论卡片下还有更多回复未包含在当前返回中；此时需要继续调用 drive file.comment.replys list 拉全后，再做全量回复数 / 总互动数统计。

评论业务特性与引导（关键！）

评论排序引导

• 一个文档通常有多个评论，评论按 create_time（创建时间）排序。
• 重要 ：只有当用户明确提到"最新评论"、"最后评论"、"最早评论"时，才需要根据 create_time 进行排序：
  • 必须先获取所有评论（处理分页拉完所有数据） ，不能只获取一页就排序
  • "最新评论" / "最后评论"：按 create_time 降序排列，取第一条
  • "最早评论"：按 create_time 升序排列，取第一条
• 如果用户只说"第一条评论"，直接使用 drive file.comments list 返回的第一条即可，不需要额外排序。

评论回复限制

• 添加评论回复前先检查是否存在以下限制
• 全文评论不支持回复 ：is_whole=true 的评论（全文评论）无法添加回复，遇到此类评论应提示用户"全文评论不支持回复"。
• 已解决评论不支持回复 ：is_solved=true 的评论无法添加回复，遇到此类评论应提示用户"该评论已被解决，无法回复"。
• 注意 ：当用户要回复某条评论但该评论因上述限制不能回复时，只提示不能回复即可，不要自动帮用户找其他可以回复的评论 ，避免不符合用户预期。

批量查询与列表查询的选择

• 使用 drive file.comments batch_query 是已知评论 ID 后 的批量查询，需要传入具体的评论 ID 列表。
• 使用 drive file.comments list 用于分页获取评论列表，适合统计评论总数、遍历所有评论，或获取"最新/最后 N 条评论"等场景。

典型错误与解决方案

Shortcuts（推荐优先使用）

Shortcut 是对常用操作的高级封装（lark-cli drive +<verb> [flags]）。有 Shortcut 的操作优先使用。

API Resources

lark-cli schema drive.<resource>.<method>   # 调用 API 前必须先查看参数结构
lark-cli drive <resource> <method> [flags] # 调用 API

重要 ：使用原生 API 时，必须先运行 schema 查看 --data / --params 参数结构，不要猜测字段格式。

files

• copy — 复制文件

file.comments

• batch_query — 批量获取评论
• create_v2 — 添加全文/局部（划词）评论
• list — 分页获取文档评论
• patch — 解决/恢复 评论

file.comment.replys

• create —
• delete — 删除回复
• list — 获取回复
• update — 更新回复

permission.members

• auth —
• create — 增加协作者权限
• transfer_owner —

metas

• batch_query — 获取文档元数据

user

• remove_subscription — 取消订阅用户、应用维度事件
• subscription — 订阅用户、应用维度事件（本次开放评论添加事件）
• subscription_status — 查询用户、应用对指定事件的订阅状态

权限表

每周安装量

15.4K

代码仓库

larksuite/cli

GitHub Stars

3.3K

首次出现

2 天前

安全审计

Gen Agent Trust HubPassSocketPassSnykFail

已安装在

codex15.4K

opencode15.4K

cursor15.4K

gemini-cli15.4K

github-copilot15.4K

cline15.4K