tag-organize

name	tag-organize
description	笔记标签整理的核心原则与完整工作流程。当用户提到"整理笔记标签"、"清理标签"、"标签太乱"、"标签太多"、"帮我打标签"、"重构标签"、"重新分类"、"笔记分类混乱"、"标签体系需要优化"等需求时使用。
compatibility	需要 WPS 笔记 MCP 服务连接
metadata	{"author":"wps","version":"1.0.1","category":"note-organization"}

笔记标签整理核心原则与流程

核心原则

整理标签不是在执行一套标准方法论，而是在服务一个具体的人。没有统一的「正确」分类方式，一切决策以用户的实际需求为准。

整理的价值只来自三个方向，不能带来其中任何一项的改动都不值得做：

• 提升使用效率：减少维护负担，降低分类焦虑
• 提升检索效率：让用户更快找到目标内容
• 带来新的知识连接视角：发现原来看不到的关联

不要在任务开始时反问用户「你想整理什么范围、怎么整理」。用户找 AI 来整理，本身就意味着他不想自己做这些判断。AI 的职责是主动给出具体方案，让用户做选择题，而不是问答题。

---

操作安全约束

当前阶段只做打标。 标签没有专属位置，可能出现在任意 block 中——修改标签必须通过修改 block 内容来实现。

三条硬性规则，每次操作都必须遵守：

1. 操作前必须读完整 block：用 read_blocks 获取目标 block 的完整内容，在新内容中只改标签部分（<tag> 元素或 #标签 文本），其余内容原样保留后再用 edit_block(op="replace") 写回。未读完整就直接写回会导致 block 内正文文字丢失，不可恢复。

2. 意图不明的笔记直接跳过：无法确定内容主题或用途时，不猜测、不修改，在方案中列为「未处理」告知用户。判断标准：内容极少看不出主题、无法确定用户是否仍关注、打什么标签都不确定。

3. 不删除任何笔记：无论笔记看起来多空，都不在此阶段做任何笔记删除。

---

WPS 笔记系统行为说明

在 WPS 笔记中操作时，以下系统行为会影响结果，必须了解：

行为	说明	应对方式
/ 表示层级分隔	标签名中的 / 是层级分隔符，写入 #父级/子级 时 WPS 自动将其解析为父子关系	写完整路径，如 <tag>#工作/项目</tag>，不要把父级名和子级名分段拼接后再合并
标签名小写存储	WPS 笔记中所有英文字母均以小写存储，这是系统级规则，与写入方式无关（GTD笔记 → gtd笔记）	已知限制，无法通过 MCP 修复，请勿尝试将小写转大写
标签自动清理	标签失去所有笔记引用后，WPS 笔记会异步自动删除，不会立即消失	验证时不以标签立即消失为判断标准

---

任务流程

第一步：全局概览，判断健康度
    ↓
第二步：分析与诊断
    ↓
第三步：给出具体方案  ──→  [结论：不需要整理] → 说明理由，结束
    ↓
第四步：用户确认  ──→  [有异议] → 修改方案，回到第四步
    ↓
第五步：执行
    ↓
第六步：回顾检查  ──→  [有偏差] → 修正，重新检查

---

第一步：全局概览，判断健康度

选择合适的工具查看当前笔记文件和标签列表，了解当前笔记系统的整体状况，再决定深入哪些地方。

第一层：必做（全局概览）

1. get_note_stats(detailed=true) — 一次调用获得：

   • 文件总数、标签总数、无标签文件数
   • 每个标签下的文件数量分布
   • 近期更新的文件列表

2. find_tags() — 获得：

   • 完整的标签层级结构（父子关系、命名）
   • 识别命名风格、层级逻辑、可疑标签名

完成这两步后，通常已能发现大多数问题（颗粒度失衡、命名不一致、无标签文件过多等），并形成整理方向的初步判断。

第二层：按需调查（针对发现的问题）

根据第一层发现的线索，有针对性地使用以下工具，不要全量展开：

想了解的内容	用哪个工具
某个可疑标签下都有哪些文件	search_notes({ tags: ["标签名"] })
无标签的文件有哪些	list_notes 结合 get_note_stats 里的无标签数量对照
某篇文件大概讲什么、标签在哪	get_note_outline(note_id)
某篇文件的某几个 block 的精确内容	read_blocks(note_id, [block_ids])
某篇文件的完整内容（需要深度理解或精确改标签时）	read_note(note_id)，不加 max_length
在某篇长文件里快速找到标签所在 block	search_note_content(note_id, "#标签名")

原则：用最轻量的工具满足当前需求，只在必要时才读全文。 如果通过 get_note_outline 已经能判断该打什么标签，就不需要 read_note；如果通过 search_notes({ tags: [...] }) 已经能判断标签是否合理，就不需要逐篇读内容。

---

第二步：分析与诊断

在完整信息的基础上，识别用户的分类习惯，并逐项对照下方问题诊断表检查。

已有习惯是有价值的资产，不是需要纠正的问题。如果用户已有固定习惯且分类逻辑合理，不要轻易打破。

分析时同时结合笔记内容思考：每篇笔记用户为什么存了它？服务于什么场景？未来会用什么关键词检索？这决定了标签是否有真实的检索价值。

前置判断：标签数量过少，无法诊断

当已有标签极少（例如有意义的标签少于 3 个）时，不足以判断用户的分类偏好，此时跳过以下诊断，改为根据笔记内容为用户从头设计标签体系。

→ 查阅 references/classification-methods.md，根据用户场景选择合适的分类方法，并在第三步明确说明选择理由，让用户确认。不确定时默认推荐层级分类法（适应性最广，最易上手）。

---

问题诊断表

1. 重复 / 语义相同

	说明
正常状态	同一概念只有一个标签，命名风格统一（中英文、缩写、全称选其一）
问题表现	待办 / TODO / to-do 并存；AI 和 人工智能 并存；会议 和 meeting 并存
处理建议	合并为用户更常用的那个；原标签失去所有引用后会由系统自动清理

2. 层级结构不合理

	说明
正常状态	父子关系在语义上成立（子标签是父标签的具体化）；同级标签是真正的并列概念；每层标签数量适中，层级深度有实际意义
问题表现（层级错位）	同级概念被误放成父子关系：学习/数学/语文，数学 和 语文 是并列学科，语文 不应挂在 数学 下面
问题表现（同级过多）	一个层级中有几十个标签全部平铺，没有任何分组，标签列表冗长——此时应将同类标签归入共同的父标签
问题表现（层级冗余）	一个层级中只有一个标签，中间层没有其他并列项，也不带来额外的过滤价值——此时应合并或移除中间层
判断方法	每个层级都问：「这一层的意义是什么？未来可能会有哪些概念与它并列？」答不上来的层级不应存在；同级标签较多时，考虑是否有可以归类的共同上级
处理建议	层级错位 → 修正父子关系；同级过多 → 找出共同属性，建立父标签做归类；层级冗余 → 合并或移除中间层

3. 标签颗粒度失衡

	说明
正常状态	每个标签关联的文件数量适中，能有效过滤（既不过宽也不过细）
问题表现（过细）	某标签只关联 1-2 篇文件，且这些文件已被更合适的父标签覆盖——此标签是冗余的
问题表现（过粗）	某标签关联了大量文件，点开后几乎等于「全部笔记」，检索时没有过滤价值
处理建议	过细 → 合并到父标签或相近标签；过粗 → 拆分子标签，引导用户使用更精确的分类

4. 命名风格不一致

	说明
正常状态	同一层级的标签命名风格统一（词性、语言一致）
问题表现	同级标签中部分用名词、部分用动词；中英文混用；全角半角符号混用
处理建议	以用户现有的多数标签风格为基准统一；命名风格本身没有对错，统一即可
排除项	英文字母大小写差异不属于命名风格问题。WPS 笔记中所有英文字母均以小写存储，这是系统级规则，无法通过 MCP 修复，无需处理。例如用户写入 PKM工具，系统存储后显示为 pkm工具，这是正常状态，不是问题。

5. 笔记覆盖不均衡

	说明
正常状态	大多数笔记有标签，标签体系能覆盖用户的主要内容类型
问题表现	大量笔记没有任何标签，或某一类内容（如近期新增笔记）系统性地缺少标签
处理建议	为无标签笔记补充标签；缺口过大时优先处理最常用、最重要的内容

---

如果以上问题均不存在： → 进入第三步，直接告知用户「建议保持现状」并说明理由。

---

第三步：给出具体方案

直接呈现改动后的目标标签体系结构，附上每条改动的理由。不要只列问题，要给出完整的目标状态。

方案格式示例：

建议改动后的标签体系：

工作
├── 项目            ← 原 #项目A、#项目B 统一归入此处
└── 日常            ← 原 #工作记录 改为此，更简洁

学习               ← 原 #读书 和 #网课 合并入此
├── 读书
└── 网课

生活               ← 保持不变

待办               ← 原 #TODO、#to-do 合并为此（用户最常用的写法）

未处理：「未命名笔记」「未命名笔记(1)」（内容为空或无法判断意图，请用户自行决定）

情况一：只需要少量改动

→ 直接列出具体的几条改动，说明理由，进入第四步确认。

情况二：需要较大范围重建

→ 先呈现整体目标结构，再列出主要改动点，让用户对全貌有判断后再确认。

---

第四步：用户确认

等待用户基于方案给出判断。

情况一：用户同意

→ 进入第五步执行。

情况二：用户提出异议或质疑

→ 重新思考方案，不要辩解。用户的质疑通常指向方案中逻辑不自洽的地方。修改后重新呈现，回到第四步。

情况三：用户部分同意

→ 只执行用户确认的部分，存疑的部分暂缓，等用户进一步确认。

---

第五步：执行

按确认后的方案执行改动。

执行规模判断：

• 改动少（个位数）→ 一次完成
• 改动多 → 分批执行，每批按逻辑单元划分（如：先处理全局合并操作，再处理单篇笔记调整）

---

第六步：回顾检查

执行完成后，主动验证结果，不能依赖用户来发现问题。

必须验证两个层面：

1. 笔记块内容（read_blocks）：标签是否正确写入，是否已成为 <tag> 元素，block 内其他内容是否完整；层级标签格式为 #父级/子级
2. 系统标签列表（find_tags()）：新标签是否已创建，旧标签数量是否符合预期

情况一：结果与预期一致

→ 向用户呈现改动摘要，说明有无已知遗留问题（如系统限制导致的标签小写存储）。

情况二：发现偏差

→ 找到原因，修正，重新检查，直到结果与预期一致再向用户汇报。不要在偏差未修正前向用户声称完成。

---

常见错误速查

错误	后果	正确做法
层级标签写法错误	父子关系解析、筛选出现异常	多级路径用 / 分隔：<tag>#工作/项目</tag>
一开始就逐篇读所有文件	效率极低，文件多时完全不可行	先用 get_note_stats + find_tags() 建立全局视图，再按需深入
需要读全文时截断内容	漏掉标签，误判内容性质	read_note 不加 max_length 限制
只看笔记块预览，不读系统标签列表	遗漏未发现的残留标签	两个视角都验证
任务开始时先问用户想整理什么	把负担推回给用户	先读后分析，主动给出具体方案
结论是不需要整理时强行提改动	引入不必要风险	明确说「建议保持现状」并说明理由
用户有异议时辩解而不是修改方案	方案逻辑缺陷被掩盖	重新思考，修改后再呈现
执行后不主动回顾检查	偏差未被发现	执行后必须验证块内容和标签列表
未读完整 block 就直接写回	block 内的非标签文字丢失，不可恢复	先用 read_blocks 读取完整内容，只改标签部分，其余原样保留后再写回
对意图不明的笔记强行打标	标签不准确，干扰检索	跳过，列为「未处理」告知用户
删除看起来为空的笔记	可能丢失用户数据	不在此阶段做任何笔记删除
为了「整洁」而整洁	用户体验未改善，还引入风险	每次改动都对应具体的效率提升或检索价值