WPS 灵犀版 vs Anthropic 原版 skill-creator 深度对比分析

一、基本情况对比

二、核心架构差异：设计哲学不同

Anthropic 原版的核心设计理念是 "测试驱动迭代"（Eval-Driven Iteration）。它把 Skill 开发当作一个完整的工程化流程来对待：

整篇 SKILL.md 有 71 次提到 "eval"、46 次提到 "test"、26 次提到 "iteration"、19 次提到 "benchmark"。原版认为 Skill 的质量只能通过量化评估闭环来保障。

WPS 灵犀版的核心设计理念是 "模板化创建"（Template-Based Creation）。它将 Skill 开发简化为一个线性的 6 步流程：

1. 通过具体示例理解技能

2. 规划可复用的技能内容

3. 初始化技能（init_skill.py）

4. 编辑技能

5. 打包技能（package_skill.py）

6. 基于真实使用情况迭代

整篇 SKILL.md 中 "eval" 出现 0 次，"test" 出现 0 次。没有测试用例、没有基线对比、没有量化评估。

三、功能模块对比

3.1 技能创建流程

关键差异：灵犀版提供了 init_skill.py 脚手架工具，可以一键生成技能目录骨架和模板，降低了从零开始的门槛。原版则依赖 Agent 手动创建。

3.2 评估与测试（最核心的差异）

这是两者最大的区别。原版投入了约 60% 的篇幅来描述评估体系，而灵犀版这部分为零。

3.3 Description 优化（触发精度）

原版将 description 优化视为一个独立的、可量化的工程问题，而灵犀版仅在编写指导中简单提及。

3.4 多平台适配

原版需要覆盖 Claude 生态内的多种运行环境，而灵犀版只需适配桌面端。

3.5 辅助资源

3.6 写作风格与教育性

四、差异根因分析

这些差异并非简单的"翻译+删减"，而是由平台架构差异决定的：

1. 子代理能力缺失：灵犀桌面端没有 Claude Code 的子代理（subagent）系统，因此原版中依赖子代理的并行测试、基线对比、盲测等功能无法实现。整条 eval 链条的前置条件不存在。

2. 工具链差异：原版依赖 claude -p CLI、present_files 工具、Web 浏览器等，灵犀环境有自己的工具集（write_file、python_cell_exec、generate_image 等），需要适配不同的基础设施。

3. 定位差异：Anthropic 原版面向的是 Claude Code 开发者生态（可分发 .skill 文件、跨平台安装），灵犀版面向的是 WPS 桌面用户的自建技能场景，不需要考虑分发和跨平台兼容。

五、对 WPS 官方的建议

5.1 补齐轻量级评估能力

现状问题：灵犀版 skill-creator 缺失了整个评估闭环。用户创建技能后，只能靠"用着感觉不对再改"来迭代，没有系统化的质量保障手段。

建议方案：设计一套不依赖子代理的灵犀原生评估流程。具体思路：

• 串行测试替代并行子代理：在灵犀中，可以在同一会话中依次执行测试 prompt，记录每次的输出结果、token 消耗和耗时。虽然不如并行快，但在桌面场景下完全可以接受。

• 结构化测试记录：增加 evals/evals.json 的 schema 定义（可参考原版 references/schemas.md），让测试用例可复用、可累积。

• Agent 自评 + 人工复核：没有独立的 grader 子代理，可以让灵犀在执行完测试后自我评估输出质量，再由用户做最终判定。虽然存在"自己评自己"的偏差，但在没有子代理的约束下，这已是性价比最高的折中方案。

• 可视化报告：利用灵犀已有的 write_file 能力，生成 Markdown 格式的测试报告（而非原版的 Web HTML），列出每个测试用例的 prompt、输出摘要、自评结果和人工评分区域。

实现路径：在 scripts/ 下新增 run_evals.py，接收 SKILL.md 路径和 evals.json，输出 Markdown 评估报告。在 SKILL.md 的第 5 步和第 6 步之间插入"评估"环节。

5.2 增加触发精度优化模块

现状问题：灵犀版的 description 编写仅停留在"写清楚触发场景"的层面，缺少系统化的触发精度验证手段。用户无法知道自己的技能是否被正确触发——是该触发时没触发（欠触发），还是不该触发时乱触发（过触发）。

建议方案：

• 移植"pushy"策略指导：将原版关于 description 编写的最佳实践（尤其是对抗模型欠触发倾向的技巧）完整翻译到灵犀版中。

• 轻量级触发测试：不需要原版的 run_loop.py 自动化循环，但可以在 SKILL.md 中增加一个"触发自查清单"——列出 5-8 个应该触发的典型 prompt 和 5-8 个不应该触发的近义 prompt，让用户在创建技能后手动验证。

• description 模板库：在 references/ 或正文中提供常见技能类型的 description 写作模板（文档处理类、数据处理类、浏览器操作类等），降低用户的 description 编写门槛。

5.3 补充安全与质量约束

现状问题：原版有专门的 "Principle of Lack of Surprise" 章节，明确禁止在技能中嵌入恶意代码。灵犀版完全缺失这部分内容。

建议方案：在 SKILL.md 的"核心原则"部分增加安全约束章节，至少涵盖：

• 禁止在技能中包含恶意代码、数据外泄逻辑或未授权访问指令

• 技能内容应可预期——用户仅凭 description 就能判断技能会做什么

• 对 scripts/ 中的可执行脚本增加安全审查提醒（quick_validate.py 可扩展安全检查项）

5.4 建立技能版本管理与 diff 能力

现状问题：灵犀用户在迭代技能时，缺少版本追踪手段。修改前没有快照，改坏了无法回退。

建议方案：

• init_skill.py 在创建技能时可选项地初始化 Git 仓库（git init），每次修改后自动 commit。

• 或者在 scripts/ 中新增 snapshot_skill.py，在修改前将技能目录复制为带时间戳的快照。

• 这与灵犀用户社区中已有人提出的"自定义 Skills 技能包调用路径"需求也是契合的——用户需要灵活管理多个版本的技能。

5.5 增加用户沟通指导

现状问题：原版有专门的 "Communicating with the user" 章节，指导 Agent 根据用户的技术背景调整沟通方式（比如不轻易使用"JSON""assertion"等技术术语）。灵犀版面向的用户群体更加多元——从程序员到办公文员都有，更需要这种适配意识。

建议方案：在 SKILL.md 的开头或"核心原则"部分，增加一段关于用户沟通的指导，提醒 Agent 在创建技能的过程中注意用户的技术熟练度，使用合适的语言层级。