前言¶

团队里常见的问题是：同一批报表每个月手工汇总一次，同一批通知每天要按规则分发一次。这类任务重复度高、规则稳定，但很少有人愿意专门为它写一套系统。一般的做法是要么继续人工处理，要么临时拼一段脚本——脚本跑过一两次就没人维护了。

办公自动化 这个 Skill 走的是第三条路：先让 Agent 识别哪些任务值得自动化，再按「触发器—动作—兜底」的结构把方案设计出来，最后输出可以直接跑的脚本、集成配置或低代码搭建步骤。下面介绍这个 Skill 的实际情况、能力和启用方式。

这是什么¶

一句话定位：面向企业办公场景的自动化方案生成 Skill，输入是一段任务描述，输出是可运行的自动化方案。

它解决的不是「怎么调用某个 API」，而是「这个活儿该不该自动化、自动化成什么形态、出了异常怎么办」。和通用代码生成 Skill 的区别是，它把兜底和触发条件当成方案的一等组成部分，而不是写完脚本之后的补丁。

核心功能¶

官方简介写的是：识别高重复办公任务，设计触发器-动作-兜底，生成可运行的自动化方案（脚本/集成/低代码）。拆开看是三步。

1. 识别候选任务。从一段工作描述里判断哪些环节属于高重复、规则明确的类型，把值得自动化的部分挑出来。
2. 设计触发器-动作-兜底。确定什么时候启动（定时、事件、手工触发）、启动后做什么、失败之后回到什么状态。
3. 生成可运行方案。按任务性质给出三种落地形态之一：独立脚本、已有系统的集成配置，或低代码平台的搭建步骤。

需要 API Key 的环节在资料里没有出现，标签 requires_api_key=false 说明本身不依赖外部付费模型接口，可以直接在本地 Agent 环境里跑。

安装与启用¶

已抓取的资料里没有提供具体的安装命令或配置字段，只有名称、坐标、版本、分类、来源归属和标签这几项元数据。这个 Skill 遵循通用 SKILL.md 格式，实际启用方式以 SkillHub 页面为准。

下面是启用前需要确认的几项信息，命令本身需要在页面上核对后再执行：

# 待确认项：资料中未给出安装命令
# 1. 安装来源：SkillHub 页面 https://www.skillhub.cn/skills/kunlungrowth/kunlun-office-auto
# 2. 加载位置：Agent 的 skill 目录（具体路径取决于所用 Agent）
# 3. 额外配置：资料中未列出任何配置项

另外两点值得注意。一是该 Skill 无需 API Key，装完即可用，不用先申请密钥。二是 SkillHub 页面当前显示安装次数为 0、下载 1223 次、评分 100000。安装数为 0 意味着还没有可参考的实际部署反馈，评分数字则是平台侧的展示值，不宜当作使用体验的佐证。

典型用法¶

资料里没有给出官方的完整可复现示例，下面的用法是按 Skill 自带的三步流程组织的，属于流程层面的描述，不是经过实跑验证的输出样例。

第一步，把任务说清楚。给 Agent 一段具体的工作描述，包含触发频率、涉及的文件或系统、期望结果：

每周一上午 9 点，把上周五新增的客户工单按优先级分类，
写入销售群公告，并把高优先级工单同步到负责人邮箱。

第二步，让 Agent 先判定自动化收益，再给出方案结构。这个 Skill 会按触发器—动作—兜底的顺序组织答案，而不是直接开始写代码。

第三步，看产出物属于哪种形态。规则简单、数据量小的通常落到脚本；需要对接现成系统的落到集成配置；在低代码平台上搭建的落到搭建步骤。拿到方案后建议先在测试数据上跑一遍，确认兜底路径能覆盖失败场景。

适用场景与注意¶

适合的场景：规则明确、重复频率高、输入输出边界清楚的办公任务，例如定期汇总、按规则分发、跨表格搬运数据、批量通知。

不太适合的场景：规则本身还在频繁变化的工作。这类任务自动化之后，维护脚本的开销会超过人工处理的开销，而且每次规则调整都要改方案，不如等规则稳定后再做。

使用时的三个注意点：

1. 触发器要能被验证。如果「什么时候启动」这一步只能靠口头约定，自动化方案实际上是不可运行的。
2. 兜底要落到具体动作。仅仅写「失败则通知某人」不够，需要明确通知渠道、通知对象和重试次数。
3. 权限和数据范围要先确认。自动化脚本会以当前环境的身份访问文件和系统，涉及跨部门数据时需要提前确认授权范围。

结尾¶

办公自动化 的价值在于把「该不该自动化、自动化成什么样」的判断过程固化进了 Skill，输出的方案带触发器和兜底，而不是一段跑完就不管的脚本。需要了解最新安装方式和示例，以官方页面为准：https://www.skillhub.cn/skills/kunlungrowth/kunlun-office-auto