// 笔记文件级标签整理的核心原则与完整工作流程。用户提到"整理笔记标签"、"清理标签"、"标签太乱"、"标签太多"、"帮我打标签"、"重构标签"、"重新分类"、"笔记分类混乱"、"标签体系需要优化"时必须使用；基于 wps-note MCP 的 get_note_stats、find_tags、get_note_info、search_notes、manage_note_tags 等工具执行，不通过编辑 block 或 <tag> XML 管理标签。
Create new skills or improve existing skills by clarifying intent, drafting SKILL.md instructions, organizing supporting resources, and doing lightweight manual review. Use when users want to create a skill from scratch, revise a skill, package a skill, or improve a skill's trigger description.
【深度搜索】面向复杂问题的启发式检索助手。 默认执行“笔记证据 + 网络权威信源”的混合检索，不止笔记内关键词搜索。 当用户说“深度搜索”“帮我深挖”“关联查询”“全面梳理”“帮我核实一下”时使用。 本版本为单代理串行执行，禁用 sub_agent。
基于用户已有笔记创建学习自测闭环；当用户说“出点题考考我”、自测、测验时，读取材料，生成选择题、填空题、简答题等不提前泄题的习题，等待用户作答后按原文证据批改，并输出错因反馈、重学建议和可选复习记录。
笔记文件级标签整理的核心原则与完整工作流程（CLI 版）。通过系统命令行调用 wpsnote-cli 操作 WPS 笔记，无需 MCP 服务连接。当用户提到"整理笔记标签"、"清理标签"、"标签太乱"、"标签太多"、"帮我打标签"、"重构标签"、"重新分类"、"笔记分类混乱"、"标签体系需要优化"等需求时使用；标签管理必须使用 wpsnote-cli manage-tags，不通过编辑 block 或 <tag> XML 修改标签。
多平台编码助手。遵循各平台官方文档做编码规范、单测与编译/lint；协助将核心技术梳理为完整 WPS 笔记技术文档。生成的笔记必须包含 7 个二级标题（核心技术、核心代码、关键技术点、核心类和职责、调用链、架构概览、注意事项）；其中架构、核心技术、调用链的图示优先用 WPS 笔记的 generate_image 根据描述生成图片再用 insert_image 插入。用户新增标题时根据诉求补充内容；用户未关闭当前笔记期间约 1 分钟后主动更新直至关闭。当用户使用 Cursor、Codex、Claude Code、AS code 且提到架构、设计图、核心方法、关键技术或技术文档时，自动读写在 WPS 笔记。先 list_notes 先查后编；核心代码可从注释、复制、剪切板、选中或指定函数获取。子 skill review-notes 与 reference 负责流程细节。每30s监控一个笔记内容是否变动，如果变动自动更新文档。
通过 MCP 工具读取、编辑和管理 WPS 笔记，基于 block 文档模型，所有内容以 XML 格式交换。当用户说"帮我看看笔记"、"搜索笔记"、"创建一篇笔记"、"编辑笔记内容"、 "整理标签"，或提到 WPS 笔记、WPS Note、云笔记时使用。也适用于排查 MCP 工具调用错误 （BLOCK_NOT_FOUND、EDITOR_NOT_READY 等）。
| name | tag-organize |
| description | 笔记文件级标签整理的核心原则与完整工作流程。用户提到"整理笔记标签"、"清理标签"、"标签太乱"、"标签太多"、"帮我打标签"、"重构标签"、"重新分类"、"笔记分类混乱"、"标签体系需要优化"时必须使用；基于 wps-note MCP 的 get_note_stats、find_tags、get_note_info、search_notes、manage_note_tags 等工具执行，不通过编辑 block 或 <tag> XML 管理标签。 |
| when_to_use | 用户说整理笔记标签/清理标签/标签太乱/标签太多/帮我打标签/ 重构标签/重新分类/笔记分类混乱/标签体系需要优化。 |
| when_not_to_use | 整理笔记内容和结构用 整理当前笔记 或 整理所有笔记； 单篇笔记加一个标签直接操作不需要此技能。 |
| aliases | ["标签整理","清理标签","标签管理","标签分类","打标签"] |
| author | wps |
| compatibility | 需要 WPS 笔记 wps-note MCP 工具可用 |
| metadata | {"author":"wps","version":"1.1.1","category":"note-organization","tags":["wps-note","file-level-tags","note-organization"]} |
整理标签不是在执行一套标准方法论，而是在服务一个具体的人。没有统一的「正确」分类方式，一切决策以用户的实际需求为准。
整理的价值只来自三个方向，不能带来其中任何一项的改动都不值得做：
不要在任务开始时反问用户「你想整理什么范围、怎么整理」。用户找 AI 来整理，本身就意味着他不想自己做这些判断。AI 的职责是主动给出具体方案，让用户做选择题，而不是问答题。
当前阶段只做打标。 笔记标签是文件级独立对象，通过 wps-note 专用工具 manage_note_tags 增删改；不要再通过 edit_block、batch_edit 或 <tag> XML 修改标签。
硬性规则，每次操作都必须遵守：
修改标签只用 manage_note_tags：
manage_note_tags({ note_id })（只传 note_id 即为查询）manage_note_tags({ note_id, add: ["工作/项目"] })manage_note_tags({ note_id, remove: ["旧标签"] })remove + add# 前缀；#工作/项目 只用于对用户展示时的习惯写法跨笔记的全局操作必须先 ask_user 确认：标签的全局重命名、合并、批量删除（影响 2 篇以上笔记）属于跨笔记批量操作，执行前必须调用 ask_user。
意图不明的笔记直接跳过：无法确定内容主题或用途时，不猜测、不修改，在方案中列为「未处理」告知用户。
不删除任何笔记：无论笔记看起来多空，都不在此阶段做任何笔记删除。
确认必须用 ask_user 工具：禁止用文本提问代替 ask_user 调用——文本提问不会暂停执行，用户无法介入。调用 ask_user 的同一轮中禁止执行写入工具。
在 WPS 笔记中操作时，以下系统行为会影响结果，必须了解：
| 行为 | 说明 | 应对方式 |
|---|---|---|
/ 表示层级分隔 | 标签名中的 / 是层级分隔符，WPS 自动将其解析为父子关系 | 写完整路径调用 manage_note_tags({ note_id, add: ["工作/项目"] }) |
| 区分大小写 | 标签按用户输入原样存储，TODO、Todo、todo 是三个不同的标签 | 比对标签时按字面比对，不做大小写归一 |
| 标签输入限制 | 最多 10 级层级，每级最多 20 字符；禁用 \ : * ? " < > | 与 emoji；同一文档内不允许重复标签 | 生成新标签时主动遵守这些限制；命中系统报错时根据返回信息调整后重试 |
第一步：全局概览，判断健康度
↓
第二步：分析与诊断
↓
第三步：给出具体方案 ──→ [结论：不需要整理] → 说明理由，结束
↓
第四步：用户确认 ──→ [有异议] → 修改方案，回到第四步
↓
第五步：执行
↓
第六步：回顾检查 ──→ [有偏差] → 修正，重新检查
选择合适的工具查看当前笔记文件和标签列表，了解当前笔记系统的整体状况，再决定深入哪些地方。
get_note_stats({ detailed: true }) — 一次调用获得：
find_tags() 看全量）find_tags() — 获得：
完成这两步后，通常已能发现大多数问题（颗粒度失衡、命名不一致、无标签文件过多等），并形成整理方向的初步判断。
根据第一层发现的线索，针对性使用以下工具按需调查：
| 想了解的内容 | 用哪个工具 |
|---|---|
| 某个可疑标签下都有哪些文件 | search_notes({ tags: ["标签名"] }) |
| 无标签的文件有哪些 | get_note_info({ limit, page }) 分页查询，过滤 tags 为空的笔记 |
| 某篇笔记当前挂着哪些标签 | manage_note_tags({ note_id })（只传 note_id 即为查询） |
| 某篇文件大概讲什么 | get_note_outline({ note_id }) |
| 某篇文件的某几个 block 的精确内容 | read_blocks({ note_id, block_ids }) |
| 某篇文件的完整内容（需要深度理解内容时） | read_note({ note_id })，不加 max_length 限制 |
原则：用最轻量的工具满足当前需求：get_note_outline 能定位时优先用它；search_notes({ tags: [...] }) 能筛选时优先用它；仅在需要完整内容理解时才用 read_note。
在完整信息的基础上，识别用户的分类习惯，并逐项对照下方问题诊断表检查。
已有习惯是有价值的资产，不是需要纠正的问题。如果用户已有固定习惯且分类逻辑合理，不要轻易打破。
分析时同时结合笔记内容思考：每篇笔记用户为什么存了它？服务于什么场景？未来会用什么关键词检索？这决定了标签是否有真实的检索价值。
当已有标签极少时，不足以判断用户的分类偏好，此时跳过以下诊断，改为根据笔记内容为用户从头设计标签体系。
→ 查阅 references/classification-methods.md，根据用户场景从中选择合适的分类方法（层级分类法 / P.A.R.A. / 实体场景法），并在第三步明确说明选择理由，让用户确认。不确定时默认推荐层级分类法（适应性最广，最易上手）。
1. 重复 / 语义相同
| 说明 | |
|---|---|
| 正常状态 | 同一概念只有一个标签 |
| 问题表现 | 待办、TODO、to-do 并存；AI 和 人工智能 并存；会议 和 meeting 并存 |
| 处理建议 | 合并为用户更常用的那个；原标签失去所有引用后由系统自动清理 |
2. 层级结构不合理
| 说明 | |
|---|---|
| 正常状态 | 父子关系在语义上成立（子标签是父标签的具体化）；同级标签是真正的并列概念；每层标签数量适中，层级深度有实际意义 |
| 问题表现（层级错位） | 同级概念被误放成父子关系：学习/数学/语文，数学 和 语文 是并列学科，语文 不应挂在 数学 下面 |
| 问题表现（同级过多） | 一个层级中有几十个标签全部平铺，没有任何分组，标签列表冗长——此时应将同类标签归入共同的父标签 |
| 问题表现（层级冗余） | 一个层级中只有一个标签，中间层没有其他并列项，也不带来额外的过滤价值——此时应合并或移除中间层 |
| 判断方法 | 每个层级都问：「这一层的意义是什么？未来可能会有哪些概念与它并列？」答不上来的层级不应存在；同级标签较多时，考虑是否有可以归类的共同上级 |
| 处理建议 | 层级错位 → 修正父子关系；同级过多 → 找出共同属性，建立父标签做归类；层级冗余 → 合并或移除中间层 |
3. 标签颗粒度失衡
| 说明 | |
|---|---|
| 正常状态 | 每个标签关联的文件数量适中，能有效过滤（既不过宽也不过细） |
| 问题表现（过细） | 某标签只关联 1-2 篇文件，且这些文件已被更合适的父标签覆盖——此标签是冗余的 |
| 问题表现（过粗） | 某标签关联了大量文件，点开后几乎等于「全部笔记」，检索时没有过滤价值 |
| 处理建议 | 过细 → 合并到父标签或相近标签；过粗 → 拆分子标签，引导用户使用更精确的分类 |
4. 命名风格不一致
| 说明 | |
|---|---|
| 正常状态 | 同一层级的标签命名风格统一（词性、语言、大小写一致） |
| 问题表现 | 同级标签中部分用名词、部分用动词；中英文混用；全角半角符号混用；英文大小写不统一 |
| 处理建议 | 以用户现有的多数标签风格为基准统一；命名风格本身没有对错，统一即可 |
5. 笔记覆盖不均衡
| 说明 | |
|---|---|
| 正常状态 | 大多数笔记有标签，标签体系能覆盖用户的主要内容类型 |
| 问题表现 | 大量笔记没有任何标签，或某一类内容（如近期新增笔记）系统性地缺少标签 |
| 处理建议 | 为无标签笔记补充标签；缺口过大时优先处理最常用、最重要的内容 |
如果以上问题均不存在： → 进入第三步，直接告知用户「建议保持现状」并说明理由。
直接呈现改动后的目标标签体系结构，附上每条改动的理由——完整呈现目标状态，便于用户对比判断。
方案格式示例：
建议改动后的标签体系：
工作
├── 项目 ← 原 项目A、项目B 统一归入此处
└── 日常 ← 原 工作记录 改为此，更简洁
学习 ← 原 读书 和 网课 合并入此
├── 读书
└── 网课
生活 ← 保持不变
待办 ← 原 TODO、to-do 合并为此（用户最常用的写法）
未处理：「未命名笔记」「未命名笔记(1)」（内容为空或无法判断意图，请用户自行决定）
情况一：只需要少量改动
→ 直接列出具体的几条改动，说明理由，进入第四步确认。
情况二：需要较大范围重建
→ 先呈现整体目标结构，再列出主要改动点，让用户对全貌有判断后再确认。
通过 ask_user 工具获取用户确认。
情况一：用户同意
→ 进入第五步执行。
情况二：用户提出异议或质疑
→ 重新思考方案。用户的质疑通常指向方案中逻辑不自洽的地方，据此修改后重新呈现，回到第四步。
情况三：用户部分同意
→ 只执行用户确认的部分，存疑的部分暂缓，等用户进一步确认。
按确认后的方案执行改动。
执行规模判断：
执行完成后，主动验证结果。
必须验证两个层面：
manage_note_tags 写入操作的返回值检查——tags 是更新后的完整标签列表，added / removed 是实际生效的项；确认目标标签在 tags 中、层级以 / 正确体现find_tags()）：确认新标签已创建、合并/删除的旧标签已消失，整体结构符合方案情况一：结果与预期一致
→ 向用户呈现改动摘要，说明有无遗留问题（例如某些笔记被跳过的原因）。
情况二：发现偏差
→ 找到原因，修正，重新检查，直到结果与预期一致后再向用户汇报。