* fix: preserve non-data payload keys in SuccessEnvelopeData
When an API response uses a non-"data" key (e.g., /bot/v3/info returns
payload under "bot"), the previous implementation discarded the payload
and returned an empty object. Fall back to the envelope minus transport
fields (code, msg, data) so the business payload is preserved.
Fixes #2428
(cherry picked from commit a82585718c)
* fix(output): pass non-object bodies through and pin api envelope at command level
Follow-up to the cherry-picked fix for #2428: return nil bodies as {} and
non-object bodies untouched instead of collapsing them, align the new test
with its neighbours, and add cmd/api regression tests through the httpmock
path so the user-visible envelope is pinned where the bug was reported.
* test(output): pin null data with sibling payload, drop SDK-pinned array test
TestApiCmd_NonObjectBody_FailsLoudly asserted the SDK's pre-decode rejection
of non-object bodies, not the output-layer branch this PR added; reverting
that branch left it green. The unit test already covers the branch, so the
command-level copy is removed. Add a unit case for {"data": null, "bot": {..}},
which the previous code collapsed to {} and now returns as {"bot": {..}}.
* fix(output): normalize legacy bot payloads
---------
Co-authored-by: Wu Shuwen <108231307+dajiaohuang@users.noreply.github.com>
Co-authored-by: sang-neo03 <266690410+sang-neo03@users.noreply.github.com>
15 KiB
导入分流规则: 如果用户要把本地 Excel / CSV /
.base快照导入成 Base / 多维表格 / bitable,必须优先使用lark-cli drive +import --type bitable。不要先切到lark-base;lark-base只负责导入完成后的表内操作。
快速决策
- 用户要把已有 Wiki 节点移出知识库,放到 Drive 文件夹或“我的空间”根目录:切到
lark-wiki,使用lark-cli wiki +move-to-drive;不要把 Wiki token 直接交给drive +move。执行前确认源节点与目标位置。 - 用户要把本地
.xlsx/.csv/.base导入成 Base / 多维表格 / bitable,第一步必须使用lark-cli drive +import --type bitable。 - 用户要把本地
.md/.docx/.doc/.txt/.html导入成在线文档,使用lark-cli drive +import --type docx。 - 用户要把本地
.xlsx/.xls/.csv导入成电子表格,使用lark-cli drive +import --type sheet。 - 批量执行
drive +import且目标是同一个位置(同一--folder-token、默认根目录,或同一--target-token)时,必须串行执行;不要并发导入到同一位置,服务端可能返回并发冲突错误。 - 用户要在云空间里新建文件夹,优先使用
lark-cli drive +create-folder。 lark-base只负责导入完成后的 Base 内部操作(表、字段、记录、视图),不要在“本地文件 -> Base”这一步提前切到lark-base。
修改标题
- 使用
drive files patch命令,通过new_title字段可以修改标题,支持 docx、sheet、bitable、file、wiki、folder 类型
核心概念
文档类型与 Token
飞书开放平台中,不同类型的文档有不同的 URL 格式和 Token 处理方式。在进行文档操作(如添加评论、下载文件等)时,必须先获取正确的 file_token。
文档 URL 格式与 Token 处理
| URL 格式 | 示例 | Token 类型 | 处理方式 |
|---|---|---|---|
/docx/ |
https://example.larksuite.com/docx/doxcnxxxxxxxxx |
file_token |
URL 路径中的 token 直接作为 file_token 使用 |
/doc/ |
https://example.larksuite.com/doc/doccnxxxxxxxxx |
file_token |
URL 路径中的 token 直接作为 file_token 使用 |
/wiki/ |
https://example.larksuite.com/wiki/wikcnxxxxxxxxx |
wiki_token |
⚠️ 不能直接使用,需要先查询获取真实的 obj_token |
/sheets/ |
https://example.larksuite.com/sheets/shtcnxxxxxxxxx |
file_token |
URL 路径中的 token 直接作为 file_token 使用 |
/drive/folder/ |
https://example.larksuite.com/drive/folder/fldcnxxxx |
folder_token |
URL 路径中的 token 作为文件夹 token 使用 |
Wiki 链接特殊处理(关键!)
知识库链接(/wiki/TOKEN)背后可能是云文档、电子表格、多维表格等不同类型的文档。不能直接假设 URL 中的 token 就是 file_token,必须先查询实际类型和真实 token。
处理流程
推荐方式:使用 drive +inspect 自动解包
lark-cli drive +inspect --url 'https://xxx.feishu.cn/wiki/wikcnXXX'
返回结果包含 type(底层文档类型)、token(真实 file_token)、title、url 等字段,直接用于后续操作。
手动方式:使用 wiki.spaces.get_node 查询节点信息
-
使用
wiki.spaces.get_node查询节点信息lark-cli wiki spaces get_node --params '{"token":"wiki_token"}' -
从返回结果中提取关键信息
node.obj_type:文档类型(docx/doc/sheet/bitable/slides/file/mindnote)node.obj_token:真实的文档 token(用于后续操作)node.title:文档标题
-
根据
obj_type使用对应的 APIobj_type 说明 使用的 API docx新版云文档 drive file.comments.*、docx.*doc旧版云文档 drive file.comments.*sheet电子表格 sheets.*bitable多维表格 / Base drive file.comments.*、bitable.*slides幻灯片 drive.*file文件 drive.*mindnote思维导图 drive.*
查询示例
# 查询 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 需求
| 操作 | 需要的 Token | 说明 |
|---|---|---|
| 读取文档内容 | file_token / 通过 docs +fetch 自动处理 |
docs +fetch 支持直接传入 URL |
| 添加局部评论(划词评论) | file_token |
传 --block-id 时,drive +add-comment 会创建局部评论;docx 支持 block_id,sheet 使用 <sheetId>!<cell>,slides 使用 <slide-block-type>!<xml-id>;Base / bitable 只有记录局部评论,定位为 file_token(base token) + --block-id <table-id>!<record-id>!<view-id> |
| 添加全文评论 | file_token |
不传 --block-id 时,drive +add-comment 默认创建全文评论;支持 docx、旧版 doc URL、白名单扩展名的 Drive file,以及最终解析为 doc/docx/file 的 wiki URL |
| 下载文件 | file_token |
从文件 URL 中直接提取 |
| 上传文件 | folder_token / wiki_node_token |
目标位置的 token |
| 列出文档评论 | file_token |
同添加评论 |
评论能力边界(关键!)
drive +add-comment支持两种模式。- 全文评论:未传
--block-id时默认启用,也可显式传--full-comment;支持docx、旧版docURL、白名单扩展名的 Drive file,以及最终解析为doc/docx/file的 wiki URL。sheet、slides、Base / bitable 不支持全文评论。 - 局部评论:传
--block-id时启用;docx支持 block id,sheet支持<sheetId>!<cell>,slides支持<slide-block-type>!<xml-id>,Base / bitable 支持<table-id>!<record-id>!<view-id>;wiki URL 解析到这些类型时也支持对应局部评论。Drive file 本次只支持全文评论,不支持局部评论。 - Drive file 评论仅支持白名单扩展名:
.md、.txt、.json、.csv、.go、.js、.py、.pptx、.png、.jpg、.jpeg、.zip、.mp3、.mp4。.pdf、.docx、.xlsx等未在白名单内的普通文件暂不支持,CLI 会直接报错提示当前还不支持这种类型的评论。 - Review / 审阅 / 校对 / 逐条指出问题场景优先使用局部评论,不要把多个可定位问题汇总成一条全文评论;具体参数和定位方式见生成后的
skills/lark-drive/references/lark-drive-add-comment.md。 drive +add-comment的--content需要传reply_elementsJSON 数组字符串,例如--content '[{"type":"text","text":"正文"}]'。slides评论要求显式传--block-id <slide-block-type>!<xml-id>;CLI 会将其拆分后写入anchor.block_id和anchor.slide_block_type。其中<xml-id>是 PPT XML 协议中的元素id;不支持--full-comment。- Base 记录局部评论使用
--type bitable/--type base或/base/、/bitable/、wiki Base 链接;bitable和 Base 是同一概念,bitable是内部代号、Base 是产品名,裸 token 推荐传bitable,base仅作为兼容别名兜底。Base 不支持全局评论,所有评论都挂在记录上;定位信息必须是 file token(base token)+--block-id <table-id>!<record-id>!<view-id>,其中 table/record/view ID 通常分别以tbl/rec/vew开头。view_id 只决定被提及时点击通知打开哪个视图,不影响评论挂载点,但必须传;ID 可通过lark-base获取。 - 如果 wiki 解析后不是
doc/docx/file/sheet/slides/bitable/base,不要用+add-comment。 - 如果需要更底层地直接调用评论 V2 协议,再走原生 API:先执行
lark-cli schema drive.file.comments.create_v2,再执行lark-cli drive file.comments create_v2 ...。全文评论省略anchor;docx/sheet/slides 局部评论传anchor.block_id,Base 记录局部评论传anchor.block_id(table_id)、anchor.base_record_id、anchor.base_view_id。
评论查询与统计口径(关键!)
强制规则:drive file.comments list 默认必须传 is_solved:false,即仅查询未解决评论。即使用户说“所有评论”“全部评论”“把评论都列出来”,只要没有明确提到要包含已解决评论,仍然按默认口径查询未解决评论。
仅当用户明确要求包含已解决评论时,才可省略 is_solved 参数。
正确示例:
# 默认查询:仅未解决评论(推荐)
lark-cli drive file.comments list --params '{"file_token": "xxx", "file_type": "docx", "is_solved": false}'
# 查询所有评论(用户未明确要求包含已解决评论)
lark-cli drive file.comments list --params '{"file_token": "xxx", "file_type": "docx", "is_solved": false}'
# 包含已解决评论(需用户明确要求)
lark-cli drive file.comments list --params '{"file_token": "xxx", "file_type": "docx"}'
错误示例:
# 不推荐:用户未明确要求但查询所有评论
lark-cli drive file.comments list --params '{"file_token": "xxx", "file_type": "docx"}'
- 查询文档评论时,使用
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 条评论"等场景。
Reaction / 表情场景
- 遇到评论 / 回复上的 reaction(表情、各表情数量、谁点了什么、添加/删除表情)相关问题时,先阅读 lark-drive-reactions.md 了解如何使用。
典型错误与解决方案
| 错误信息 | 原因 | 解决方案 |
|---|---|---|
not exist |
使用了错误的 token | 检查 token 类型,wiki 链接必须先查询获取 obj_token |
permission denied |
没有相关操作权限 | 引导用户检查当前身份对文档/文件是否有相应操作权限;如果需要,可以授予相应权限 |
invalid file_type |
file_type 参数错误 | 根据 obj_type 传入正确的 file_type(docx/doc/sheet/slides/bitable) |
232140101 / 232140100 / 233523001(常见于 drive +import 的 job_error_msg) |
同一位置下存在并发导入 / 创建操作 | 批量导入到同一文件夹、根目录或同一 --target-token 时改为串行执行;每个失败项每次重试前等待几秒,总共最多重试 3 次,仍失败就停止并报告冲突 |
授权当前应用访问文档
当需要将文档权限授予当前应用(bot)自身时,先通过 bot info 接口获取应用的 open_id,再调用权限接口授权:
# 1. 获取当前应用的 open_id
lark-cli api GET /open-apis/bot/v3/info --as bot --jq '.data.open_id'
# 输出即当前应用的 open_id
# 2. 授权当前应用访问文档
lark-cli drive permission.members create \
--params '{"token":"<doc_token>","type":"<resource_type>"}' \
--data '{"member_type":"openid","member_id":"<bot_open_id>","perm":"view","type":"user"}'
注意:此方式仅适用于需要授权给当前应用的场景。授权给其他用户时,直接使用对方的 open_id 即可,无需调用 bot info 接口。
<resource_type> 可选值:doc、docx、sheet、bitable、file、folder、wiki。