Skip to content

[Feature Request] 允许 lark-cli update 自定义更新模式:仅更新 CLI 本体,或同时更新 CLI 与 skills #1145

@leeeezx

Description

@leeeezx

背景

目前 lark-cli update 会将 CLI 本体更新与 Lark/Feishu skills 同步行为耦合在一起。

这对希望官方 CLI 和官方 skills 始终保持一致的用户是方便的;但对另一类用户来说会带来风险:他们可能已经使用自己的 skill 管理工具或本地管理流程,例如 Skillshare,来统一管理 AI agent skills。

在这种情况下,如果 lark-cli update 默认联动更新、重写或同步 skills,就可能打乱用户已有的 skill 管理状态,造成双重管理风险。

需求

希望 lark-cli update 支持用户显式选择更新范围。

建议通过后缀参数或 flag 实现,例如:

# 只更新 lark-cli 本体 / npm 包
lark-cli update --cli-only

# 同时更新 lark-cli 本体与官方 Lark/Feishu skills
lark-cli update --with-skills

也可以采用子模式形式:

lark-cli update cli
lark-cli update all

或:

lark-cli update --mode cli
lark-cli update --mode all

期望行为

模式 期望行为
仅更新 CLI 只更新 @larksuite/cli,不安装、不更新、不重写、不同步任何 skills
CLI + skills 更新 @larksuite/cli,并同步更新官方 Lark/Feishu skills
检查模式 lark-cli update --check --json 能分别暴露 CLI 与 skills 的更新状态,方便 agent 或脚本判断

为什么需要这个能力

用户可能存在两种合理的管理模型:

管理模型 说明
Lark CLI 统一管理 lark-cli 同时负责 CLI 本体和官方 skills
外部工具管理 skills lark-cli 只负责 CLI 本体,skills 由 Skillshare 或其他工具/流程管理

当前的耦合更新行为会让第二种模型变得脆弱。用户本来可能已经通过外部工具维护了 skill 来源、目录结构、同步状态和元数据,但一次 lark-cli update 就可能改变这些状态。

这对 AI agent 场景尤其敏感,因为 skills 可能同时被 Claude Code、Codex、Cursor 或其他本地 agent 共享。skills 的变化不只是文件更新,还可能影响 agent 路由、上下文注入、元数据追踪和同步状态。

兼容性建议

为了避免破坏已有用户习惯,可以保持当前默认行为不变。

核心诉求是增加一个明确、文档化的“只更新 CLI 本体”的安全路径,让已有 skill 管理体系的用户可以避免被 lark-cli update 意外改动 skills。

相关 issue

这个需求与以下 issue 相关,但关注点不同:

本 issue 只聚焦于:lark-cli update 是否可以让用户选择更新范围。

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain/coreCLI framework and core librariesenhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions