【建议】优化 WPS灵犀Claw技能MarkDown文件中的内链跳转功能

一、问题描述

在 WPS 灵犀 Claw 中，每个 Skill 技能包的核心是 SKILL.md 文件——它既是灵犀 AI 理解技能能力的"说明书"，也是用户查阅技能用法时最先看到的人可读文档。许多技能包通过 Markdown 内链（相对路径超链接）将主文档与子文档、参考资料、子技能模块关联起来，形成树状或网状的知识结构。

当前存在的问题： WPS 灵犀 Claw 已经实现了 Markdown 文件的动态实时渲染和预览，这一点体验很好。但 SKILL.md 中渲染出的内链（相对路径超链接）虽然在视觉上具有超链接效果（蓝色文字、可点击），点击后只会打开一个新的 WPS 灵犀首页窗口，并不会利用已有的 Markdown 渲染能力去打开和预览内链所指向的目标文件和内容。而且这个打开的新窗口也无法正常使用。

也就是说，渲染能力是现成的，缺的只是"点击内链 → 解析目标路径 → 用已有的渲染组件打开目标文件"这一环。一个本该帮助用户快速在文档间跳转、定位所需信息的导航机制，因此变成了一条"死路"。用户看到蓝色链接，自然地认为点过去就能看到对应内容，结果得到的却是一个空白且无用的窗口，体验上的落差非常明显。而且这个问题覆盖了大量技能包，是比较普遍的体验缺陷。

二、期望行为

点击内链后，系统应根据链接类型执行对应的导航操作。具体来说，存在三种常见的内链模式，每种都应有明确且直观的处理方式：

1. 本地 Markdown 文件引用

格式如 [bdpan-commands.md](./reference/bdpan-commands.md) 或 [tools-reference](references/tools-reference.md)。

这是使用最广泛的内链类型。技能作者通常把详细的参考文档、使用示例、故障排查指南等放在 reference/、references/、docs/ 等子目录中，主 SKILL.md 负责做总览和索引。

期望行为： 利用灵犀已有的 Markdown 渲染和预览能力，打开并显示目标 Markdown 文件的内容。用户在这个新视图中也应能继续点击内链跳转（多级导航），形成类似浏览器标签页的浏览体验。

2. 子技能目录引用

格式如 [spec-driven-development](skills/spec-driven-development/SKILL.md)。

常见于聚合型技能包——一个"父技能"包含多个"子技能"，主文档作为统一入口，每个内链指向一个独立的子技能模块。这类技能包的文档组织方式本质上就是一个微型知识库。

期望行为： 同样利用已有的 Markdown 渲染能力，打开对应子技能的 SKILL.md 文件并显示。更进一步，如果能在侧边栏附带该技能的基本信息（名称、描述、触发条件等），甚至提供"加载/安装该技能"的快捷入口，那就更好了——这将使技能文档真正成为技能生态的一部分，而不仅仅是静态的文本。

3. 同文件锚点跳转

格式如 [安装](#安装)、[环境要求](#环境要求)。

这是最基础的 Markdown 超链接功能，在几乎所有技术文档平台（GitHub、GitLab、Notion、语雀等）中都是开箱即用的。

期望行为： 在当前文档视图内平滑滚动到对应标题位置。实现成本最低，但体验提升非常明显——尤其是对于那些内容较长、章节较多的 SKILL.md 文件，锚点跳转几乎是必要的导航手段。

三、实现建议

由于灵犀已经具备 Markdown 动态实时渲染和预览能力，核心问题可以归结为：点击内链时，正确解析目标路径，然后将目标文件交给已有的渲染组件处理。 在这个前提下，建议的实现思路如下：

方案一：基于现有渲染能力打通内链（推荐）

在当前的 Markdown 预览视图中，拦截内链的点击事件，根据链接类型执行相应操作：

• 路径解析：解析 href 中的相对路径，基于当前 SKILL.md 所在目录计算目标文件的绝对路径（例如当前文件在 skills/claude-code/SKILL.md，链接为 references/tools-reference.md，则目标路径为 skills/claude-code/references/tools-reference.md）

• 打开预览：对于 .md 文件，直接调用灵犀已有的 Markdown 渲染组件打开目标文件，无需额外开发新的渲染视图

• 多级导航：子文档中如果也有内链，继续支持点击跳转，形成可连续浏览的文档链路

• 返回导航：提供面包屑或"返回上级文档"的导航按钮，方便用户在文档层级间来回跳转

• 子技能识别：对于 skills/xxx/SKILL.md 路径的引用，除了渲染文档内容外，可在侧边栏附带该技能的元信息（名称、描述），并可选提供"加载该技能"的操作入口

方案二：混合方案（方案一 + 外部编辑器兜底）

在方案一的基础上，增加一个 fallback 机制：

• .md 文件：使用灵犀已有的 Markdown 渲染组件打开

• 非 .md 文件（如 .py、.json、.yaml、.sh）：调用系统默认编辑器打开

• 渲染组件加载异常时：同样 fallback 到系统默认程序

这种方案兼顾了体验和鲁棒性。技能包中偶尔也会引用非 Markdown 文件（比如配置示例、脚本模板），用外部编辑器打开反而更合适——用户可以直接编辑。

优点：覆盖所有文件类型，边界情况下不会"卡死"。

方案三：系统默认程序打开（最小可行方案）

点击内链时，统一调用系统默认的编辑器打开目标文件。

优点：实现成本最低，本质上只需要正确解析路径并调用 os.startfile() 或等效的系统调用即可。

缺点：体验不够原生，会跳出灵犀客户端，且依赖用户本地安装了合适的编辑器。

锚点跳转应优先修复

无论采用哪种方案，锚点跳转（#标题）都是成本最低、收益最高的优化点。它不需要打开新文件，不需要新的 UI 组件，只需要在现有的 Markdown 预览视图中注册 href="#xxx" 的点击事件，执行 scrollIntoView 即可。这个修复可以在任何一个方案之前独立上线，建议优先处理。

四、用户价值

打通内链跳转，表面上是补全一个"链接点不动"的缺失环节，但实际上对整个技能生态有多层次的正面影响：

技能可发现性大幅提升。 技能包的子模块、参考文档、使用示例可通过内链直接访问，用户不再需要手动打开文件管理器、逐级进入 skills/ 目录、逐一打开 .md 文件去"淘"信息。尤其是对那些不熟悉技能目录结构的新用户，内链导航能显著降低学习成本。

知识导航效率质变。 聚合型技能包能像维基百科一样自由跳转浏览——从总览页进入子模块，从子模块跳到参考文档，再通过锚点定位到具体章节。这种"文档即导航"的体验是技术文档的基本期望。

改善技能作者的文档组织范式。 当前因为内链不可用，技能作者被迫把所有内容塞进一个 SKILL.md 文件中（即使内容很长、结构很复杂），因为只有"放在主文件里"才能确保用户看到。如果内链可用，作者可以放心地采用更模块化的文档组织方式：主文档做总览和索引，子文档各司其职。这不仅能提升每个文件的可读性，也有利于技能的维护和迭代。

提升对技能体系的信任感。 "看起来能点但点了没用"是 UX 中最令人沮丧的体验之一——它给用户一个预期，然后立刻打破这个预期。修复内链跳转看似不大，但它消除了一个持续存在的负面信号，让用户觉得技能体系是"完整可用"的，而不是"半成品"。

希望官方团队能关注这个问题。灵犀已经具备了良好的 Markdown 渲染预览能力，内链跳转本质上是把"已有的渲染能力"和"内链的路径信息"接通——基建已经到位，只差最后一公里的连线。打通这一环，既能让现有技能的可用性上一个台阶，也能为技能作者提供更好的文档组织范式，长远来看有利于整个社区技能生态的健康发展。期待后续版本的优化！