本文面向所有在 WPS 里改稿、审稿、核稿的人——政务文秘、法务、标书、编校、信息中心。不是产品广告，也不是操作手册的复述。文中的技能机制、写回动作、JSON 输出、批注锚点，全部对应察元 AI 文档助手 v4.0（WPS 文字加载项）的真实实现。本专栏其他文章可在 CSDN 搜标题找到，命令与端口可在《内网离线用 Ollama 审 WPS：本机 MCP 与察元 v4.0 全链路》复现。

一句话先放在这儿：文档审查要的不是更聪明的聊天框，而是「一条指令只干一类事、结果钉在原文上、改没改谁来点头」的标准动作。 WPS 里的「技能（Skill）」，就是把这个标准动作固化下来的容器。下面从一个真实翻车场景讲起，说清技能到底是什么、四条来源、审稿型技能的三个特征，再给一个能直接抄走的自写技能示例。

一、那个把正文粘进聊天框的下午

综合科小王的故事，每个写稿人都干过。

周三下班前，领导甩来一份十五页的工作总结，让「把错别字和前后不一致的地方过一遍，明早要用」。小王打开某网页大模型，把正文整段粘进去，问「帮我校对一下」。

模型很给力，回了一大段：「本文整体写得不错，建议修改如下：第二段『的得地』有误，第五页数据疑似前后矛盾……」

然后小王花了两个小时，在这段「优美回复」和原文之间来回切换，手动找「第二段」在哪、手动改、手动核对模型说得对不对。改到一半发现模型把「2019 年」说成「二〇一九年」建议统一，可原文本来就是阿拉伯数字，它读错了。最后还是得自己逐字通读一遍才敢交。

小王的真问题，从来不是「模型不够聪明」。是三件事同时错了：

• 任务太宽。 「帮我校对一下」是一句没有边界的话。错别字、术语、数据、格式、逻辑，全混在一次回答里，模型只能写散文，你也只能读散文。
• 结果没有锚。 模型说「第二段」，可它不知道你的第二段从哪行开始。所有的「位置」都要你人工二次定位。
• 没人点头。 模型直接吐结论，没有「先给你看清单、你确认了我再动稿子」这一步。改对改错，全凭你最后那一遍通读。

这三件事，恰恰是「聊天」和「审查」的分水岭。聊天是发散的、无痕的；审查是收敛的、要留痕的。把聊天框当审查工具，本质是用错了工具。

二、WPS 里的「技能」是什么：一句话、一份提示词、一个写回动作

察元 AI 文档助手在 WPS 文字里把上面三件事拆开，用「技能（Skill）」这个单位来装。

一个技能，就是一个被预先约束好的文档处理动作。它由三部分固化下来：

1. 一句话定位：技能只干一类事。比如「拼写与语法检查」只输出问题清单，「术语统一」只对齐全文用词，「段落序号检查」只核对编号一致性。技能的名字、图标、提示词，都在告诉你它的边界。
2. 一份系统提示词 + 用户模板：技能背后有一段写死的 systemPrompt（告诉模型你是谁、按什么口径审查、绝对不要做什么）和一段 userPromptTemplate（把选区或全文按固定格式喂给模型）。你不用每次重新组织语言，点一下技能，模板自动套。
3. 一个写回动作：技能的结果不是飘在聊天里的散文，而是按预设动作写回文档——插入 / 替换 / 添加批注 / 链接批注 / 批注+替换 / 追加 / 仅生成。审稿型技能的默认动作通常是「添加批注」：原文不动，意见挂在边上。

所以「技能」和「聊天」最大的区别是：聊天每次都要你重新定义任务、重新组织提示词、再手动搬运结果；技能把这些固化成了一次点击。 同样的模型，套进技能里，输出就从「一段散文」变成「一条可定位、可确认、可留痕的修改建议」。

这正是一个好的审稿流程要的形态。

三、四种技能从哪来：内置、自定义、插件目录、市场

察元里的技能有四条来源，运行时完全等价——都走同一套「提示词 → 模型 → 写回」的管线。区别只在「谁写的、怎么装进来」。

第一条：内置技能。 产品自带，按领域打包成几百个。政务、法务、人社、财政、审计、教育、医疗……每个领域一组，覆盖改写、扩写、纠错、润色、正式化、术语统一、结论与风险、文档审计等通用动作。打开 WPS 功能区的「文本分析」「更多」两个下拉，里面就是一组高频内置技能。

第二条：自定义技能。 在「创建智能助手」里自己填：系统提示词、用户模板、模型类型、输入来源（优先选区/仅选区/全文）、输出格式（纯文本/Markdown/列表/JSON）、默认写回动作、显示位置（主菜单/更多/右键）。填完存下来，下次就是一键调用。适合「我们科室就认这套口径」的私有规则。

第三条：技能插件目录。 这是给会写两行代码的人准备的。在 src/skills/ 目录下放一个 .js 文件，default export 一个技能对象，产品启动时会自动扫描注册，不用改主代码。下一节会给完整示例。这种技能的 id 会被自动加上 ext.skill. 前缀，不会和内置冲突。

第四条：市场技能。 从技能市场安装第三方技能包，安装时做签名校验和受信发布者白名单，通过后注册到全局，可随时卸载。管理员还能把任意技能导出为 JSON 分发给团队，接收端导入 JSON 自动注册到团队命名空间。

四条来源，同一个运行时。你既可以拿来就用，也可以把单位里那套审稿口径固化成一个技能，全科室共享。

四、审稿型技能的三个特征：JSON 输出、批注锚点、预览确认

不是所有技能都适合审稿。「润色」「扩写」这类技能是创作型的，吐出来的是新文本；审稿型技能要的是「指出问题」。一个合格的审查校对技能，通常有这三个特征：

特征一：输出 JSON 问题列表，而不是散文。

审稿型技能会把 defaultOutputFormat 设成 json，并在提示词里反复强调「仅输出合法 JSON」。输出长这样：

{
  "problems": [
    {
      "quote": "进一步深化改革开放",
      "type": "错别字",
      "suggestion": "进一步深化改革开放",
      "reason": "「进一步」与「深化」语义重复，建议删去其一"
    },
    {
      "quote": "第三条 ……",
      "type": "序号",
      "suggestion": "第四条",
      "reason": "上文为第二条，此处跳号"
    }
  ]
}

为什么要 JSON？因为机器能解析。每一条问题里的 quote 是原文片段，模型下一步就拿这个片段去文档里定位，而不是让你人工找「第二段」。

特征二：批注锚点，原文不动。

审稿型技能的 defaultAction 通常是 comment（添加批注）。产品拿到上面的 JSON 后，逐条把 quote 在活动文档里匹配定位，在对应位置挂一条 WPS 批注，批注内容是 suggestion + reason。正文一个字都没动，所有意见都挂在边上。 这就是「留痕审稿」。

提示：表格里的错字，批注有时会挂在整格上而不是单个字上，这是 WPS 批注锚点的机制限制。想让批注钉得更准，把 quote 片段写长一点、带上下文，定位会更稳。详见本专栏《WPS 表格批注锚点》一文。

特征三：预览 → 确认 → 写回，人来点头。

这是和「聊天框直接改」最根本的区别。技能跑完后，默认不会直接写进文档，而是先给一个预览（dryRun）：这是发现的问题清单、这是建议、这是要挂批注的位置。你扫一眼，确认没问题，再点「写回」。模型读错了的（比如把阿拉伯数字误判成需要统一的），你在预览里就能挑出来删掉，不让它进稿子。

模型可以发现一万条问题，但只有你点头的才会落到文档上。 这一句，是审查和聊天最本质的分界线，也是技能机制把「问责」还给人的方式。

五、开箱即用的审查校对技能清单

如果你不想自己写，下面这些内置技能直接覆盖了八成审查校对场景。按「要查什么」对号入座：

你要查的事	用这个技能	默认动作	说明
错别字、明显语病	拼写与语法检查	批注	输出 JSON 问题列表，长文初筛主力，区别于「整段重写」的纠错
段落编号跳号、格式不一致	检查段落序号格式	批注	公文、标书编号一致性，挨条核对
全文同一个词多种写法	术语统一	批注	「互联网+」/「互联网 ＋」/「Internet+」归一
结论是否站得住、有无风险点	提取结论与风险	追加/批注	把散落的结论聚拢，标出风险
涉密词、密级、单位项目编号	保密检查	批注	分级风险提示，仅辅助参考，不替代定密
是否有 AI 生成痕迹	AI 痕迹检查	批注	保守评估，辅助人工，不构成结论
逐书签/逐段合规	文档审计助手	批注	按规则逐项过，出审计报告
整段重写式纠错	纠正拼写和语法	替换	注意：这是改写型，会动正文，区别于上面的 JSON 路径

一个建议：先用「批注型」技能把问题列出来，确认后再决定动不动正文。 别一上来就「替换」，那是创作型技能的用法，在审稿阶段会让你失去留痕。

六、自己写一个审查技能：在 src/skills/ 放一个文件

科室有一套自己的审稿口径？把它做成一个技能，一次写好，全员复用。下面是一个完整可用的技能插件，做的事是「公文错别字 + 序号 + 术语」三合一审查，输出 JSON、默认挂批注。

在 src/skills/ 下新建 gov-proofread-trio.js：

// src/skills/gov-proofread-trio.js
// 察元 AI 文档助手 · 技能插件
// 放进 src/skills/ 后，启动期由 scanAndRegisterSkills() 自动注册，
// id 会被加上 ext.skill. 前缀，无需改动主代码。

export default {
  // —— 身份 ——
  id: 'gov-proofread-trio',          // 注册后变成 ext.skill.gov-proofread-trio
  label: '公文三合一审查（错别字/序号/术语）',
  shortLabel: '三合一审查',
  icon: '🔍',
  group: 'analysis',
  description: '对活动文档做错别字、段落序号、术语一致性三类审查，输出 JSON 问题清单，默认挂批注，不改正文。',

  // —— 输入输出 ——
  defaultInputSource: 'document',     // 审查整篇活动文档（也可改成 selection-preferred）
  defaultOutputFormat: 'json',        // 关键：审稿型用 JSON，便于解析成批注
  temperature: 0.2,                   // 审查要稳，温度调低

  // —— 写回 ——
  allowedActions: ['comment', 'replace', 'none'],
  defaultAction: 'comment',           // 关键：默认挂批注，原文不动
  defaultDisplayLocations: ['ribbon-more'],

  // —— 系统提示词：约束模型行为 ——
  systemPrompt: [
    '你是公文校对专家，只做三件事：错别字、段落序号、术语一致性。',
    '规则：',
    '1. 只指出你确信的问题；拿不准的不要写进清单。',
    '2. quote 必须是原文中连续出现的字，便于回原文定位；不要改写 quote。',
    '3. 序号类只报跳号、重复、格式不一致，不报文体问题。',
    '4. 术语类只在同一文档内出现两种及以上写法时才报。',
    '5. 绝对不要改正文，也不要给「润色版」，你的产出只有问题清单。',
    '6. 仅输出合法 JSON，不要任何说明文字、不要 markdown 代码块。'
  ].join('\n'),

  // —— 用户模板：把文档喂进去 ——
  userPromptTemplate: [
    '请审查下面这篇公文，按 {problems: [{quote, type, suggestion, reason}] } 的 JSON 结构输出。',
    'type 取值限定为：错别字 | 序号 | 术语。',
    '只输出 JSON。',
    '',
    '---',
    '{{input}}',
    '---'
  ].join('\n'),

  // —— 技能元信息（可选）——
  skill: {
    version: '1.0.0',
    author: '综合科',
    description: '公文错别字/序号/术语三合一审查，JSON+批注',
    tags: ['公文', '校对', '错别字', '序号', '术语']
  }
}

几个要点：

• defaultOutputFormat: 'json' + defaultAction: 'comment' 是审稿型技能的灵魂。前者让结果可解析，后者让原文不动。
• temperature: 0.2 审查要稳定可复现，别用默认的高温度。
• systemPrompt 里反复强调「只输出 JSON」「不要改正文」，这是阻止模型写散文、擅自改稿的关键约束。
• quote 字段是批注锚点的依据，模板里要求模型照抄原文连续字，定位才准。
• 存盘后重启加载项，技能就出现在「更多」里。第一次用先在小段上试，确认 JSON 解析正常、批注挂得准，再上长文。

不会写代码也没关系——同样的东西，在「创建智能助手」界面里把系统提示词和用户模板贴进去，效果完全一样。技能插件只是把这件事文件化了，方便版本管理和团队分发。

七、跑一遍完整流程：选技能 → 预览 → 确认 → 写批注

把上面那个三合一技能装好后，一次真实的审稿长这样：

第一步，打开稿子，选技能。 在 WPS 里打开要审的公文，点功能区「更多」→「公文三合一审查」。技能按 defaultInputSource: 'document' 读取整篇活动文档。

【贴图1：WPS「更多」下拉里点选「公文三合一审查」技能。】

第二步，技能跑完，先看预览。 模型返回 JSON 问题清单，产品不直接写文档，而是先弹一个预览：第几条、原文 quote、类型、建议、理由。这是 dryRun，你的眼睛过一遍。

【贴图2：预览界面，问题清单逐条列出，每条可勾选/取消，底部「写回」按钮灰色待确认。】

第三步，人工剔除误报。 模型把「2019 年」误判成要统一的，你在预览里把这一条取消勾选。删错了的、读偏了的，都在这一步清掉。这一步是人对模型的兜底。

第四步，确认写回。 点「写回」，产品把保留的每一条问题，按 quote 在文档里定位，挂上 WPS 批注。正文一字未改，所有意见挂在边上，鼠标移过去就能看到建议和理由。

【贴图3：写回后的文档，批注气泡挂在错字和跳号旁边，正文完好。】

第五步，交给作者或定稿。 作者打开文档，逐条看批注，接受就改、不接受就在批注里回复。WPS 修订模式下，后续任何替换动作都会产生修订记录，谁改的、改了什么，全留痕。

注意一个常见现象：批注太多时，把技能的默认动作改成「链接批注」或「仅生成」，预览清单本身就是交付物，不一定非得挂满全文。按单位文控制度选「最弱侵入」还是「最强留痕」。

八、技能之外：让 Claude Code 用自然语言驱动这些技能

到这里，技能已经把审查校对做成了标准动作。还有一档升级：让智能体用中文指令串起多个技能，自动跑预览→确认→写回。

察元 v4.0 在本机起了一个 MCP 服务，固定监听 http://127.0.0.1:62588/mcp，服务名 chayuan-wps-mcp，默认只绑 127.0.0.1，不要 Token。Claude Code、Codex、OpenClaw、Hermes 这类客户端连上这个本机回环地址，就能用自然语言驱动 WPS 里的技能。

你不用再记「点哪个下拉」，直接说：

打开当前这份合同，先用三合一审查跑一遍错别字和序号，预览给我；我再让你用「术语统一」把全文「甲方/乙方」的写法对齐；最后把结论与风险提取追加到文末。每一步都先预览，我确认了再写回。

智能体负责拆步骤、依次调用技能、走「预览→确认→写回」的纪律；察元负责读段落、定位原文、挂批注。技能是「做什么」，智能体是「按什么顺序做」，人仍是「能不能做」的那一关。

这条 MCP 路径的完整安装、健康检查、提示词库，见本专栏《用 Claude Code 对本机 WPS 文件做自动审查》系列。本文只强调一点：智能体不是替代技能，而是把多个技能编排起来的调度层。 技能定义得越干净，智能体编排出来的审查就越可靠。

九、把技能管起来：命名、导出、市场签名

技能写多了会乱。几条实操经验：

命名体现业务，不要起「我的助手1」。 好名字是 财务部-银行函证回复润色、综合科-公文三合一审查、法务-合同付款条款检查。名字里带部门 + 动作 + 对象，全科室一看就知道谁的、干什么。

一个技能只做一类事。 别把「校对 + 润色 + 续写」塞进一个技能，提示词会打架，输出会变成四不像。宁可拆成三个技能，让智能体去编排。

团队分发走 JSON 导入导出。 管理员把技能导出为 JSON（含 schema、不含运行时状态），发到工作群，同事导入即注册到团队命名空间。单位模板可以统一推荐一份「必装技能清单」，避免每个人各写各的、口径不一。

市场技能认签名。 从市场装第三方技能包，一定要走签名校验 + 受信发布者白名单。来路不明的技能，系统提示词里可能藏着把全文外发之类的不良指令。内网环境优先用自写技能和单位内部市场。

涉密稿用离线模型。 技能本身的提示词不外发数据，但技能调用的模型可能在外网。审带密级的稿，把技能的模型类型指到本机 Ollama 或内网端点，让流量不出域。技能机制和离线模型是正交的，可以自由组合。

十、几条不踩坑的提醒

最后，把容易翻车的点一次性说清：

• 审稿用批注，别用替换。 替换是创作型技能的动作，在审查阶段用会动正文、丢留痕。除非你已备份或开了修订模式，否则默认 comment。
• JSON 技能别让模型写散文。 温度调低、提示词里反复「仅输出合法 JSON」，否则模型多输出一句解释，解析就失败。
• 批注锚点靠 quote。 让模型照抄原文连续字，别让它概括。表格里尤其要带上下文。
• 预览不是走过场。 模型会读错数字、会误判术语、会把正确的改错。预览这一步，是人在给模型兜底，别图快跳过。
• 保密检查、AI 痕迹检查只是辅助。 它们不构成定密结论，也不构成司法结论。涉密定稿以人工和单位制度为准。
• 技能不是越多越好。 一个科室维护三五个高质量技能，远胜于装三十个半成品。技能贵在「边界清晰、口径稳定」。

---

收尾：把审查做成标准动作，而不是一次性的灵感

回到开头小王那个下午。如果那十五页总结是用「公文三合一审查」技能过的，流程会变成：点一下技能 → 预览问题清单 → 剔除误报 → 确认挂批注 → 交稿。两个小时的手工通读，压缩成十几分钟的「确认清单」。

省下来的不是时间，是可复现性。同样一份规则，下个月新来的同事装上同一个技能，审出来的口径和你一致；领导问「凭什么改的这句」，你点开批注，建议和理由都在；下一次审同类稿子，还是这套动作，不依赖任何人的状态和心情。

这才是文档审查该有的样子：不是一次性的灵感，而是一条可以被固化、被共享、被追溯的标准动作。 WPS 里的「技能」，就是装这条标准动作的容器。

如果你也在反复用聊天框校对稿子、改完说不清依据、科室口径总是对不齐——把你们那套审稿规则做成一个技能，放进 src/skills/，全科室共享。这一步，比换一个更贵的模型管用得多。

本专栏其他文章：安装与全生命周期、本机 MCP 端口 62588、模型与供应商配置、校对预览与写回、提示词库、表格批注锚点、长文档分块审查、多文档交叉校对、healthz 四级验证、加载项内置检查 vs Claude MCP、内网离线 Ollama、多客户端共用同一 MCP、公文与合同场景、确认策略与 localhost 边界、错误码排错手册。CSDN 搜标题可找到。