工具定位
本技能是笔记文件级标签整理的核心原则与完整工作流程（CLI 版），通过系统命令行调用 wpsnote-cli 操作 WPS 笔记，无需 MCP 服务连接。
CLI 工具适配
启动前先检查连接状态：
wpsnote-cli status --json
如果命令不存在或返回连接失败，应停止执行并告知用户需要先安装并打开 WPS 笔记、在「设置」→「AI 实验室」中开通能力，然后重新运行上述命令确认。
所有操作直接在系统命令行中执行 wpsnote-cli；复杂参数通过 --json-args 传入，需要结构化结果的命令加 --json。例如：
wpsnote-cli manage-tags --note_id "<id>" --json-args '{"add":["工作/项目"],"remove":["旧标签"]}' --json
MCP 语义与 CLI 命令的对应关系包括：get_note_stats 对应 wpsnote-cli stats --detailed true --json；find_tags 对应 wpsnote-cli tags --json；search_notes 对应 wpsnote-cli find --json-args '{"tags":["标签名"]}' --json；get_note_info 对应 wpsnote-cli info --json-args '{"page":1,"page_size":50}' --json；manage_note_tags 对应 wpsnote-cli manage-tags --note_id <id> --json（增删时附加 add/remove 参数）；get_note_outline 对应 wpsnote-cli outline --note_id <id> --json；read_note 对应 wpsnote-cli read --note_id <id> --json；read_blocks 对应 wpsnote-cli read-blocks --json-args '{"note_id":"...","block_ids":["..."]}' --json。
标签整理写入只使用 wpsnote-cli manage-tags；read、outline、read-blocks 只用于理解内容，不用于改标签。
核心原则
整理标签是在服务一个具体的人，没有统一的「正确」分类方式，一切决策以用户的实际需求为准。整理的价值只来自三个方向，不能带来其中任何一项的改动都不值得做：提升使用效率（减少维护负担、降低分类焦虑）、提升检索效率（更快找到目标内容）、带来新的知识连接视角（发现原来看不到的关联）。
不要在任务开始时反问用户「想整理什么范围、怎么整理」。AI 的职责是主动给出具体方案，让用户做选择题，而不是问答题。
操作安全约束
当前阶段只做打标。笔记标签是文件级独立对象，通过专用命令 wpsnote-cli manage-tags 增删改。硬性规则：查询某笔记当前标签用 wpsnote-cli manage-tags --note_id <id> --json；添加用 --json-args '{"add":["工作/项目"]}' --json；删除用 --json-args '{"remove":["旧标签"]}' --json；重命名或合并在同一次调用中组合 remove + add。跨笔记的全局操作（标签全局重命名、合并、批量删除，影响 2 篇以上笔记）执行前必须先确认。意图不明的笔记直接跳过，不猜测、不修改。不删除任何笔记。确认必须使用 ask_user 工具，禁止用文本提问代替；调用 ask_user 的同一轮中禁止执行写入命令。
WPS 笔记系统行为
标签名中的 / 是层级分隔符，WPS 自动解析为父子关系，写完整路径即可。标签区分大小写，按用户输入原样存储，TODO、Todo、todo 是三个不同标签，比对时按字面比对，不做大小写归一。标签输入限制：最多 10 级层级，每级最多 20 字符；禁用 \ : * ? " < > | 与 emoji；同一文档内不允许重复标签。生成新标签时主动遵守这些限制，命中系统报错时根据返回信息调整后重试。
任务流程
流程为：第一步全局概览判断健康度 → 第二步分析与诊断 → 第三步给出具体方案（若结论为不需要整理，则说明理由结束）→ 第四步用户确认（有异议则修改方案回到第四步）→ 第五步执行 → 第六步回顾检查（有偏差则修正重新检查）。
第一步：全局概览
必做：wpsnote-cli stats --detailed true --json，一次获得文件总数、标签总数、无标签文件数、每个标签下的文件数量分布（按笔记数降序，最多返回 30 个）、近期更新的文件列表；wpsnote-cli tags --json 获得完整标签层级结构与命名。完成这两步后通常已能发现大多数问题。
按需调查：某可疑标签下的文件用 find --json-args '{"tags":["标签名"]}' --json；无标签文件用 info 分页查询并过滤 tags 为空的笔记；某笔记当前标签用 manage-tags --note_id <id> --json；某文件大意用 outline；某文件某几个 block 精确内容用 read-blocks；需要深度理解完整内容时用 read。原则：用最轻量的命令满足当前需求。
第二步：分析与诊断
识别用户的分类习惯，已有习惯是有价值的资产。同时结合笔记内容思考每篇笔记为什么被存、服务于什么场景、未来会用什么关键词检索。
前置判断：标签数量过少时无法诊断，跳过诊断，改为根据笔记内容为用户从头设计标签体系，并明确说明分类方法的选择理由让用户确认（不确定时默认推荐层级分类法）。
问题诊断表覆盖五类：重复/语义相同（如待办、TODO、to-do 并存）、层级结构不合理（层级错位、同级过多、层级冗余）、标签颗粒度失衡（过细或过粗）、命名风格不一致（词性、语言、大小写、符号混用）、笔记覆盖不均衡。如果以上问题均不存在，直接告知用户「建议保持现状」并说明理由。
第三步：给出具体方案
直接呈现改动后的目标标签体系结构，附上每条改动的理由，完整呈现目标状态便于用户对比判断。改动少时直接列出具体几条改动；需要较大范围重建时先呈现整体目标结构再列出主要改动点。
第四步：用户确认
通过 ask_user 工具获取确认。用户同意则执行；提出异议则重新思考方案并回到第四步；部分同意则只执行确认的部分，存疑部分暂缓。
第五步：执行
改动少（个位数）一次完成；改动多则分批执行，每批按逻辑单元划分（如先处理全局合并操作，再处理单篇笔记调整）。
第六步：回顾检查
必须验证两个层面：目标笔记的标签（从 manage-tags 写入返回值检查 tags 完整列表与 added/removed 实际生效项，确认层级以 / 正确体现）；系统标签列表（wpsnote-cli tags --json，确认新标签已创建、合并/删除的旧标签已消失、整体结构符合方案）。结果一致则向用户呈现改动摘要并说明遗留问题；发现偏差则修正后重新检查，直到一致再汇报。
限制
本阶段只做打标，不删除笔记、不修改笔记正文内容。资料未提供具体收费、价格与并发/性能限制信息。