mirror of
https://github.com/larksuite/cli.git
synced 2026-07-08 10:08:02 +08:00
e40ef66912
- Add explicit NOT boundaries to the description and a dedicated "不在本 skill 范围" section: file upload -> lark-drive, content editing -> lark-doc / lark-sheets / lark-base. - Move the Shortcuts table up, right after 快速决策, so command entry points are discoverable first; keep the member-add flow and target-semantics sections after it. - Add an inline reminder under the delete-space guidance that a wiki URL / name is not a space_id and must be resolved via `wiki spaces get_node` first. - Remove the duplicated permission (scope) table and the redundant schema note so auth/permission guidance stays centralized in lark-shared. - Bump the skill version to 1.0.1. - Keep skill-template/domains/wiki.md in sync with the SKILL.md introduction narrative. Change-Id: If2b4341f350191ee0a65bf3a2cab9afa2b76d931
5.4 KiB
5.4 KiB
成员管理硬限制：
- 如果目标是“部门”，先判断身份，再决定是否继续。
--as bot对应tenant_access_token。官方限制：这种身份下不能使用部门 ID (opendepartmentid) 添加知识空间成员。- 遇到“部门 + --as bot”时，禁止先调用
lark-cli wiki +member-add试错；直接说明该路径不可行。- 如果用户明确要求“以 bot 身份运行”，且目标是部门，必须停下说明 bot 路径无法完成，不要静默切到
--as user。
快速决策
- 用户要整理 / 盘点 / 归类 / 重构知识库、个人文档库、文档库目录或 Wiki 节点结构，或要生成整理方案、目标目录树、移动计划时，不要只使用 Wiki 节点 API。必须先阅读
../lark-drive/references/lark-drive-workflow-knowledge-organize.md，该 workflow 负责 Drive / Wiki / 个人文档库的统一入口解析、资源盘点、分类计划、写前确认和结果验证。 - 用户给的是知识库 URL（
.../wiki/<token>），且后续要查成员/加成员/删成员：先调用lark-cli wiki spaces get_node --params '{"token":"<wiki_token>"}'获取space_id，后续成员接口统一使用space_id。 - 用户要删除知识空间（
wiki +delete-space）但只给了名称或 URL：不能把名称 / URL 原样传给--space-id，必须先解析出真实space_id。解析方式：- URL（
.../wiki/<token>）：lark-cli wiki spaces get_node --params '{"token":"<wiki_token>"}' --format json，读data.node.space_id。 - 只知名称：
lark-cli wiki spaces list --format json，边翻页边收集 items 并按name精确匹配；一旦任一页累计到至少 1 条精确匹配就停止翻页。只有当翻完所有页（has_more=false）仍无精确匹配时，才对已收集的全量 items 做宽松匹配（nametrim 空格、大小写不敏感、子串包含）。 - 关键安全约束：无论精确还是模糊，无论命中 1 条还是多条，发起删除前都必须把候选（
name+space_id+description+space_type）列给用户，由用户明确选定一个space_id再执行。不要因为"只命中一条"就自动执行删除。 - 命中 0 条：停下来问用户是名称拼错了还是调用方无权限；不要自行改名字重试。
- 用户明确选定后再执行
lark-cli wiki +delete-space --space-id <ID> --yes（高风险写操作，必须显式--yes）。 - 反例：不要把 wiki URL / 名称直接当
--space-id（如--space-id "https://.../wiki/<wiki_token>"）；务必先用wiki spaces get_node解析出data.node.space_id再传。
- URL（
- 用户要在知识库中创建新节点，优先使用
lark-cli wiki +node-create。 - 用户说“给知识库添加成员/管理员”：先把目标解析成“用户 / 群 / 部门 / 应用”四类之一，再决定
--member-type，不要先调wiki +member-add再根据报错反推类型。 - 用户说“部门 + bot”：这是已知不支持路径。不要继续尝试
wiki +member-add --as bot；直接提示必须改成--as user，或明确告知当前要求无法完成。 - 用户说“用户 / 群 / 应用 + 添加成员”：先解析对应 ID，再执行
wiki +member-add。 - 用户说“查看 / 列出空间成员”：用
wiki +member-list；该 shortcut 默认只取一页，多成员场景显式加--page-all。 - 用户说“移除 / 删除空间成员”：用
wiki +member-remove，必须传齐原始授予时的--member-type和--member-role（不知道就先wiki +member-list查一下）。
成员添加流程
- 调用
lark-cli wiki +member-add前，先把自然语言里的“人 / 群 / 部门 / 应用”解析成正确的--member-id，不要猜格式。 - 用户场景默认优先
--member-type=openid：用lark-cli contact +search-user --query "<姓名/邮箱/手机号>" --format json获取open_id。 - 群组场景使用
--member-type=openchat：用lark-cli im +chat-search --query "<群名关键词>" --format json获取chat_id。 - 应用场景使用
--member-type=appid：--member-id传应用 ID，格式通常为cli_xxx。 userid/unionid只在下游明确要求时才使用；先拿到open_id，再调用lark-cli api GET /open-apis/contact/v3/users/<open_id> --params '{"user_id_type":"open_id"}' --format json读取user_id/union_id。- 部门场景使用
--member-type=opendepartmentid：当前 CLI 没有 shortcut，需调用lark-cli api POST /open-apis/contact/v3/departments/search --as user --params '{"department_id_type":"open_department_id"}' --data '{"query":"<部门名>"}'获取open_department_id。 - 只有在目标类型和身份都已确认可行后，才调用
lark-cli wiki +member-add。对于部门场景，这意味着必须是--as user。
目标语义约束
我的文档库/My Document Library/我的知识库/个人知识库/my_library都应视为 Wiki personal library，不是 Drive 根目录- 处理这类目标时，先解析
my_library对应的真实space_id，再执行wiki +move、wiki +node-create或其他 Wiki 写操作 - 不要因为缺少显式
space_id就退化成drive +move - 如果用户明确说的是 Drive 文件夹、云空间根目录、
我的空间，才进入 Drive 域处理