feat：移除了弹窗，服务器添加sls

2026-09-08 22:39:45 +08:00
commit 6a295f9a7a
4082 changed files with 1322534 additions and 0 deletions
--- a/.agents/skills/lark-drive/references/lark-drive-comment-location.md
+++ b/.agents/skills/lark-drive/references/lark-drive-comment-location.md
@ -0,0 +1,205 @@
+# 文档评论定位字段
+
+当用户需要根据评论定位文档正文位置、对文档做 review、区分多处相同引用文本，或把评论落点映射到 `docs +fetch --detail with-ids` 的内容时，优先使用 `drive +list-comments --need-relation` 查询 docx 评论位置。
+
+## 适用范围
+
+- 当前只有 `file_type=docx` 支持通过 `need_relation=true` 查询评论的位置，并返回可用于定位正文 block 的 `relation`、`parent_type`、`parent_token` 等字段。
+- `drive +list-comments` 会在目标不是 docx 时静默忽略 `--need-relation`，避免把无效参数传给 OpenAPI。遇到 sheet、bitable、slides、普通文件等类型的评论时，不要承诺可以用 `need_relation` 精确定位正文位置，应退回普通评论字段、对应资源能力下钻或人工确认。
+
+## 调用方式
+
+分页列出评论时，优先传 URL；Wiki URL / Wiki token 会自动解析到底层真实 token/type：
+
+```bash
+lark-cli drive +list-comments --url '<docx_or_wiki_url>' --need-relation
+```
+
+如果只有 Wiki token，显式传 `--type wiki`：
+
+```bash
+lark-cli drive +list-comments --token '<wiki_token>' --type wiki --need-relation
+```
+
+只有在需要未被 shortcut 暴露的底层参数时，才直接调用 raw OpenAPI。此时把 `need_relation` 放在 query params：
+
+```bash
+lark-cli drive file.comments list \
+  --params '{"file_token":"<doc_token>","file_type":"docx","is_solved":false,"need_relation":true}'
+```
+
+已知评论 ID 批量查询时，把 `need_relation` 放在请求体里：
+
+```bash
+lark-cli drive file.comments batch_query \
+  --params '{"file_token":"<doc_token>","file_type":"docx"}' \
+  --data '{"comment_ids":["<comment_id>"],"need_relation":true}'
+```
+
+同时获取文档内容，并要求返回 block id：
+
+```bash
+lark-cli docs +fetch --doc '<doc_token_or_url>' --detail with-ids
+```
+
+## 字段含义
+
+- `relation`：评论在文档内容中的结构化位置。`relation.relation` 是一个 JSON 字符串，需要再解析一次；其中 `positionInfo.blockID` 是最关键字段，用于匹配 `docs +fetch --detail with-ids` 返回的文档 block。
+- `relation.content_deleted`：评论引用的内容是否已被删除。为 `true` 时，不要假设还能在当前正文中找到原位置。
+- `parent_type`：评论所在的父级嵌入资源类型。常见值包括 `SHEET_BLOCK`、`BITABLE_BLOCK`、`WHITEBOARD_BLOCK`，表示评论落在文档内嵌电子表格、多维表格或画板内部。
+- `parent_token`：父级嵌入资源 token。对 sheet / bitable / whiteboard 内部评论，服务端可能无法给出内部单元格、记录或画板节点的文档 block 级 `relation`，但可以通过 `parent_type` + `parent_token` 定位到文档里的父级嵌入 block。
+
+## 准确度分级
+
+输出定位结论时，必须区分以下三类，不要把弱推断说成精确定位：
+
+| 等级 | 判定条件 | 输出口径 |
+|---|---|---|
+| `relation 精确` | `relation.relation` 中有 `positionInfo.blockID`，且能在 `docs +fetch --detail with-ids` 中匹配到同一 block | 可说“准确定位到 block” |
+| `父级资源精确，内部需下钻` | 只有父级嵌入资源的 `blockID` / `parent_type` / `parent_token`，或内部资源的 `positionInfo` 为空 | 可说“准确定位到嵌入资源；内部单元格/记录/节点需用对应 skill 下钻确认” |
+| `弱匹配/推断` | 只能依赖 `quote`、序号、当前展示顺序或文本搜索 | 必须标明“推断”，说明歧义来源和需要的补充信息 |
+
+## 返回示例
+
+普通 docx block 上的评论会返回 `relation`。注意 `relation.relation` 本身是字符串，需要再 JSON parse 一次：
+
+```json
+{
+  "comment_id": "7646774324967295982",
+  "quote": "code2",
+  "relation": {
+    "content_deleted": false,
+    "relation": "{\"22-doc_token_xxx\":{\"objType\":22,\"index\":2,\"objVersion\":10,\"positionInfo\":{\"blockID\":\"block_id_xxx\"}}}"
+  },
+  "parent_type": null,
+  "parent_token": null
+}
+```
+
+把 `relation.relation` 再解析后，取 `positionInfo.blockID`：
+
+```json
+{
+  "22-doc_token_xxx": {
+    "objType": 22,
+    "index": 2,
+    "objVersion": 10,
+    "positionInfo": {
+      "blockID": "block_id_xxx"
+    }
+  }
+}
+```
+
+然后在 `docs +fetch --detail with-ids` 的结果里查找同一个 block id，例如：
+
+```json
+{
+  "block_id": "block_id_xxx",
+  "block_type": "code",
+  "text": "code1\ncode2"
+}
+```
+
+嵌入 sheet / bitable / whiteboard 内部评论可能没有可用 `relation`，但会返回父级标记：
+
+```json
+{
+  "comment_id": "7646775036988148672",
+  "quote": "记录 2",
+  "relation": null,
+  "parent_type": "BITABLE_BLOCK",
+  "parent_token": "bitable_app_token_xxx_table_id_xxx"
+}
+```
+
+这种情况下，用 `parent_type` 判断目标是嵌入资源，再用 `parent_token` 匹配 `docs +fetch --detail with-ids` 中的 bitable / sheet block。定位粒度是文档里的父级嵌入 block，不是内部记录、字段或单元格。
+
+画板内部评论的返回形态类似：
+
+```json
+{
+  "comment_id": "7646775036988148673",
+  "quote": "画板节点文本",
+  "relation": null,
+  "parent_type": "WHITEBOARD_BLOCK",
+  "parent_token": "whiteboard_token_xxx"
+}
+```
+
+此时 `parent_token` 对应 `docs +fetch --detail with-ids` 结果中 `<whiteboard>` 的 `token` 属性，例如：
+
+```xml
+<whiteboard id="whiteboard_block_id_xxx" token="whiteboard_token_xxx"></whiteboard>
+```
+
+匹配到这个 `<whiteboard>` 后，`id` 就是文档正文里的父级画板 block id。定位粒度是文档里的画板 block；如果需要继续定位到画板内部具体节点，需要再用画板能力读取画板内部结构。
+
+## 定位流程
+
+1. 确认目标是 `file_type=docx`；只有 docx 文档支持通过 `need_relation` 查询评论位置。
+2. 用 `drive +list-comments --need-relation` 获取评论；已知评论 ID 且需要批量查询时，可用 `drive file.comments batch_query` 并带 `need_relation=true`。raw `drive file.comments list` 仅作为低层参数兜底。
+3. 用 `docs +fetch --detail with-ids` 获取文档内容。
+4. 对每条评论先看 `relation`：
+   - 如果存在 `relation.relation`，解析这个 JSON 字符串。
+   - 从解析结果里取 `positionInfo.blockID`。
+   - 在 `docs +fetch` 结果中查找相同 block id，这就是评论对应的文档 block。
+5. 如果没有可用 `relation`，但有 `parent_type` 和 `parent_token`：
+   - `SHEET_BLOCK`：定位到文档中的 sheet 嵌入 block；`parent_token` 通常包含 sheet token 和 sheet id，必要时取 `_` 前的 token 与文档 block 的嵌入资源 token 对比。
+   - `BITABLE_BLOCK`：定位到文档中的 bitable 嵌入 block；`parent_token` 通常包含 bitable app token 和 table id，必要时取 `_` 前的 token 与文档 block 的嵌入资源 token 对比。
+   - `WHITEBOARD_BLOCK`：定位到文档中的 whiteboard 嵌入 block；`parent_token` 对应 `docs +fetch --detail with-ids` 中 `<whiteboard>` 的 `token` 属性。
+   - 这种场景能定位到父级嵌入 block，但通常不能仅凭评论接口定位到嵌入资源内部的具体单元格、字段、记录或画板节点。
+6. 只有在 `relation`、`parent_type`、`parent_token` 都缺失时，才退回使用 `quote` 文本做弱匹配；`quote` 是评论接口返回的引用文本字段。弱匹配不能区分多处相同文本。
+
+## 嵌入资源内部定位
+
+### Sheet 内部评论
+
+- `parent_token` 常见格式是 `<spreadsheet_token>_<sheet_id>`；也可能在 `relation.relation` 中看到 `subToken` 为 `3-<spreadsheet_token>`。
+- 评论接口通常只把 `positionInfo.blockID` 指到文档里的 `<sheet>` block，内部 sheet 的 `positionInfo` 可能为空。
+- 如果 `quote` 是 `C3`、`A1` 这类单元格坐标，可拆出 `spreadsheet_token` / `sheet_id` 后用 `lark-sheets` 读取该单元格确认：
+
+```bash
+lark-cli sheets +read \
+  --spreadsheet-token '<spreadsheet_token>' \
+  --sheet-id '<sheet_id>' \
+  --range '<cell>'
+```
+
+- 准确度口径：父级 sheet block 可由 relation/parent token 精确定位；单元格坐标若只来自 `quote`，应说明“单元格来自 quote，已通过 sheets 读取验证”，不要说它来自 `positionInfo`。
+
+### Bitable / Base 内部评论
+
+- `parent_token` 常见格式是 `<base_token>_<table_id>`，其中 `table_id` 通常以 `tbl` 开头。解析时优先按最后一个 `_tbl` 边界拆分，避免 base token 内出现 `_` 时误拆。
+- 评论接口可能只返回 `parent_type=BITABLE_BLOCK` 和 `parent_token`，没有 `relation`；即使有 relation，也通常只足够定位到文档里的 `<bitable>` block。
+- 下钻读取时切到 `lark-base`，最少确认表、字段、记录：
+
+```bash
+lark-cli base +table-list --base-token '<base_token>'
+lark-cli base +field-list --base-token '<base_token>' --table-id '<table_id>'
+lark-cli base +record-list --base-token '<base_token>' --table-id '<table_id>' --limit 200 --format json
+```
+
+- 如果 `quote` 是某个稳定业务值，优先用字段/记录数据做精确匹配；如果 `quote` 只是“第 N 条”“第 N 行”这类 UI 序号，只能基于当前记录顺序推断对应记录，必须输出为“推断”，并说明评论接口没有返回 `record_id` / `field_id`。
+- 如果 `record-list` 返回 `has_more=true`，不要基于第一页下全局结论；继续分页或说明只能覆盖已读取范围。
+- 需要写入时，如果评论没有字段信息，不要自行猜字段；除非用户给出默认规则，否则请求用户确认字段，或明确说明将使用哪个字段作为默认。
+
+### Whiteboard 内部评论
+
+- `parent_token` 对应文档 XML 中 `<whiteboard token="...">`；先用它匹配文档里的 whiteboard block。
+- 若要定位画板内部节点，切到 `lark-whiteboard` 读取 raw 节点结构：
+
+```bash
+lark-cli whiteboard +export \
+  --whiteboard-token '<whiteboard_token>' \
+  --output-type raw
+```
+
+- 如果 raw 节点中存在唯一匹配 `quote` 的文本节点，可定位到该节点；如果有多个相同文本节点，仍然是弱匹配，需要结合位置、样式、用户描述或人工确认。
+- 修改画板节点前，先说明匹配到的节点 id 和文本；复杂画板不要只凭 `quote` 批量替换全部同名节点。
+
+## 使用原则
+
+- Review 文档时，不要只依赖 `quote` 文本定位评论；多处相同文本会产生歧义。
+- 能拿到 `relation.positionInfo.blockID` 时，以 block id 为准，再用 block 内容理解上下文。
+- 对嵌入 sheet / bitable / whiteboard 内的评论，以父级嵌入 block 作为文档正文定位点；如需继续定位到表格单元格、多维表格记录或画板内部节点，需要再调用对应 sheet / bitable / whiteboard 能力读取内部数据。