

> 全文约 4000 字，含完整实操步骤。文中数据来自本人真实工作场景。
>
> **标签**：WorkBuddy、AI办公、效率工具、Skill开发
> **分类**：人工智能 / 开发工具　**来源**：原创

---

## 一、先说痛点：12 份 Word，两天时间，全靠手改

我在一家三级医院的质控办工作，负责审核各职能科室每月提交的**质控月报**。

这件事的麻烦在于：**它不是难，是碎。**

每份月报要过的检查项有四大类：

1. **公文格式**——页边距、行间距、字体字号、标题分级、页码
2. **表格与图片**——表格要居中、表内字体要统一、首行要加粗并重复标题行
3. **文字表述**——科室名称是否规范、错别字、标点
4. **数据一致性**——正文里报的合计数，和表格里加出来的对不对得上

这些检查项，**单看每一条都不需要动脑**，但乘以 12 份文档、乘以每份几十个段落，就是整整两天。

更关键的是：**它极度消耗注意力，却几乎不产出价值。** 我把两天时间花在"这个数字是不是仿宋三号"上，就没有时间去想"这个科室连续三个月这个指标异常，是不是说明流程本身有问题"。

所以我决定把它交给 WorkBuddy——但**不是让它"帮我看看"，而是把它做成一个可复用的 Skill。**

---

## 二、为什么是 Skill，而不是每次对话

一开始我也是直接对话："帮我检查这份月报的格式"。

用了几次就发现问题：**每次都要重新交代一遍规则。**

页边距是多少？行间距几磅？一级标题用什么字体？哪些问题可以直接改、哪些只能标注？……这些东西重复输入，本身就是新的机械劳动。

Skill 的本质，是**把一套标准动作固化成可调用的流程**。我用 WorkBuddy 的 skill 能力把整个审核流程封装起来，之后一句话就能触发：

```
审月报
```

它就会自动跑完整个流程。这才是真正的降本——**不只是省掉手工操作，还省掉了"重新描述需求"这件事。**

---

## 三、核心设计：把"审核标准"变成"授权边界"

这是我做这个 Skill 时踩的第一个、也是最重要的坑。

我最初的想法很朴素：把院里的公文格式标准整理成文档，让 AI 照着改。结果第一版跑完，出现了两个问题：

- 有些**不该改的地方被改了**（比如涉及数据口径的表述）
- 有些**该改的地方没改**（字体继承了默认样式，看着对，其实没设）

第一个问题让我意识到：**审核工作真正的核心，不是"知道标准"，而是"知道改到什么程度"。**

所以我给 Skill 定的第一条规则，是一张**三级处理表**：

| 问题类型 | 处理方式 | 是否留修订痕迹 |
|---|---|---|
| 格式类（页边距/行距/字体字号/标题分级/页码） | 直接修改 | 是 |
| 表格与图片格式 | 直接修改 | 是 |
| 科室名称与规范名单不一致 | 直接修正 + 标注 | 是 |
| 明显错别字、标点错误 | 直接修正 | 是 |
| **逻辑矛盾 / 表述存疑** | **只标注，不改** | — |
| **数据前后不一致** | **只标注，绝不改** | — |
| 临床诊疗内容 | 不做专业判断 | — |

这张表的逻辑很清楚：**格式是客观的，数据是敏感的。**

字体错了，改成正确的，没有第二种解释；但"这个数字和表格对不上"——是正文写错了，还是表格错了，还是口径不同？**这个判断必须由人来做，AI 碰了就是越界。**

这条边界一旦定清楚，后面所有的事情都顺了。这也是我建议所有做办公类 Skill 的人第一件要想清楚的事：**不是"它能做什么"，而是"它不能做什么"。**

---

## 四、完整实操：四步流程

### 第一步：定标准——把散落的规范变成一份可执行的清单

院里的格式标准分散在几份文件里。我把它整理成一份结构化的参考文档，涵盖：

- **页边距**：页边距四边各有规定
- **正文**：字体、字号、首行缩进
- **标题分级**一共五个层级，每级的字体字号各不相同
- **行间距**：固定值（不能用倍数行距，否则排版会漂）
- **表格**：居中方式、表内字号、标题行处理

**关键点：标准必须精确到数值。而且必须是数值。** "字体大一点""行距宽松些"这种描述，AI 无法执行；只有写成"某某字体、某号、行距固定值多少磅"，它才能落地。

### 第二步：写流程——五步 SOP，不许跳步

我把整个审核拆成五个有序步骤，并写成硬规矩：

1. **通读确认**——确认文档可编辑、结构完整。遇到扫描件或纯图片，直接拒绝并提示"请提供可编辑版本"，**停止后续步骤**（避免它对着图片硬编）
2. **文本格式修正**——页边距、行距、字体字号、标题分级
3. **表格与图片格式**——居中、字号、重复标题行
4. **内容审改**——科室名核查、错别字、标点（逻辑与数据只标注）
5. **输出审核报告**——分「已完成修改」和「需人工确认」两部分

**第 1 步的"停止"指令特别重要。** 如果不明确禁止，AI 遇到读不了的文档会倾向于"猜着答"，反而制造麻烦。

### 第三步：留痕——所有修改必须可追溯

这是政务办公场景的硬要求：**改动必须能被逐项接受或拒绝。**

我的 Skill 里，所有修改都通过 Word 修订痕迹实现。打开文档，在「审阅」里能看到每一处改动：谁改的、改了什么、原值是什么。像这样：

| 问题类型 | 是否留痕迹 | 留下的痕迹类型 |
|---|---|---|
| 格式类（页边距/行距/字体字号） | 是 | 格式修订标记 |
| 明显错别字、标点错误 | 是 | 删除 + 插入标记 |
| 科室名称规范性修正 | 是 | 删除 + 插入标记 |
| 逻辑矛盾 / 数据前后不一致 | **不改，只标注** | 批注（Word Comment） |

**为什么要区分"修订痕迹"和"批注"？**

因为这两类问题的性质完全不同。格式和错别字是**已经确定的错误**，直接改掉、留痕即可；而数据和逻辑问题是**待确认的疑点**——我只知道"这里对不上"，不知道"正确的应该是什么"。

所以处理方式必须是**用批注钉在原位**，而不是改。这样审核人打开文档就能在原文旁边看到问题，不用拿着报告去逐句搜。

> **这一点解决了一个真实的麻烦。**
> 我原本是把问题写在审核报告里的，但同事反馈："**你说这个问题在第三段，我打开文档找不到在哪。**"
> 报告和数据是割裂的——报告说"第 5 段有问题"，人得自己去数到第 5 段。
> 改成批注之后，问题直接长在原文旁边。这是从"给一份清单"到"把问题钉进文档"的转变。

**【图 1】批注钉在原文旁边：正文被高亮选中，右侧批注卡直接指出前后表述矛盾**

> ![1-批注钉在原文旁.png](https://developer.qcloudimg.com/http-save/yehe-12771655/5844e5925c5d8ab90bfe68420d5b08d3.png)![1-批注钉在原文旁.png]
*示意：同一段里前面写"稍有升高"、后面写"均有所减退"，批注卡就钉在这一段的右侧。审稿人不用数段落，一眼就能看到问题在哪。*

**【图 2】批注卡放大：数据类问题只标注，不给结论**

> ![2-批注卡待核明细.png](https://developer.qcloudimg.com/http-save/yehe-12771655/4dddd91dcdaf6796f9540eb8483ce7ba.png)
*示意：抽取数 134、合理 109、不合理 20，109+20=129，与 134 差 5。批注只把差额指出来，至于哪边错、口径是什么，留给人判断。*

另外，"数据硬伤"这一类，脚本会单独抓出来列成一张清单，**只标注、绝不改动原文**：

**【图 3】脚本抓到的数据硬伤清单（只标注没改）**

> ![3-数据硬伤清单.png](https://developer.qcloudimg.com/http-save/yehe-12771655/d833e8ef259ab6be74b1f7f2daa9711e.png)
*示意：逐条给出段落位置和差额，交付时放在报告的「需人工确认」一节，不混进「已完成修改」。*

### 第四步：报告——分开说"我改了什么"和"你要看什么"

最后输出的审核报告分两节：

- **已完成修改**：逐条列出改了什么、在哪、为什么改
- **需人工确认**：逻辑、数据类问题，附位置和建议

这个分法的好处：**交付的是"决策材料"，不是"工作日志"。**

如果我给你 200 条改动流水，你得逐条读；但如果我告诉你"格式我都改完了，只有 3 处数据我拿不准，在第 X、Y、Z 段"，你只需要看 3 个地方。

**【图 4】审核跑完后的结果卡片：改了多少、落没落到位，一句话说清**

>![4-审核完成结果.png](https://developer.qcloudimg.com/http-save/yehe-12771655/a9b1261e4e52fc10601093475064258f.png) 
*示意：报告顶部直接给出"格式落地自查通过（正文 1023/1023、表格 9753/9753 文字块全部显式落字体），共 1265 处修改，全部带修订痕迹，原文件没动"。改了多少、有没有漏，不用自己数。*

---

## 五、实际效果：两天变成两小时

**最大的变化其实不是速度，是精力分配。**

以前：12 份文档，每份约 40 分钟纯手工核对格式，累计约 8 小时，加上汇总问题、写反馈，总共**两天**。

现在：批量跑一遍，**格式类问题自动处理**，我只需要：

1. 看「已完成修改」清单，快速扫一遍有没有奇怪的改动
2. 重点看「需人工确认」里的数据和逻辑问题
3. 在 Word 里逐项接受或拒修订

整体时间压缩到**两小时左右**，而且省下来的不是体力，是**注意力**——我终于可以把脑力花在"这个科室为什么连续三个月这个指标异常"这类真正需要判断的问题上。

**另外一个意外收获：一致性。**

手工改 12 份文档，改到最后几份时，判断标准难免会漂移——这份改得严一点，那份松一点。而 Skill 每次执行的标准是完全一致的，**不存在"今天心情好就多改两处"这种情况。**

**【图 5】批量跑完之后的产物：一批 `-修改版.docx`，原文件一个没动**

> ![5-批量处理文件列表.png](https://developer.qcloudimg.com/http-save/yehe-12771655/8bf6979890c1ad6d363d21cdc0333183.png)
*示意：改好的文档统一带 `-修改版` 后缀，跟原始文件并列放着，一眼能看出哪些是审过的、哪些还没审，也不会覆盖掉同事交上来的原稿。*

---

## 六、几个真实的踩坑记录

这部分可能比流程本身更有用。

### 坑 1：格式改了，但 Word 里看着没变（最隐蔽）

有一批文档，脚本跑完报告说"格式已按标准修正"，但打开 Word 一看——**字体还是宋体**。

查下来发现原因：各科室交上来的 Word，文字块**大多数根本没有显式设置字体**，它们是从文档默认样式继承来的。而脚本最初的判断逻辑是"如果这个文字块设了字体，就检查它对不对"——**没设置的情况下，判断直接被跳过，"没设置"被当成了"没问题"。**

**这个坑的教训很关键：判断格式，必须按"最终生效的值"来比，而不是看"有没有设置过"。**

因为文档来源不同，字体特征完全不同：

| 文档来源 | 字体特征 | 老逻辑命中率 |
|---|---|---|
| 系统导出的报表 | 每个文字块都把字体写死 | 100% |
| **人工在 Word 里敲的稿子** | **几乎全靠默认样式继承** | **几乎全漏** |

**所以"上次更新没问题"绝对不能推出"这次也没问题"**——只说明上次那份文档恰好没踩到坑。这也是我后来加了一条**强制自检**的原因：每份文档处理完，都回头数一遍"还有多少文字块没有显式字体"，**这个数字必须是 0**。不为零，就说明有问题，不允许交付。

### 坑 2：修好了 A，结果引入了新问题 B

有一次发现某份文档的章节序号缺失，我"顺手"把后面几个序号整体往前挪了一位。

结果：**原本缺一个号，改完后出现了两个重复的号。**

正确的做法是：**先把所有序号全部列出来**（包括重复的），再判断到底是"缺号"还是"重号"——缺号只补缺的那个位置，重号只改重复的那个，**其余一律不动。**

不要用会"连锁改动多个位置"的改法，那是在制造新错误。

### 坑 3：报告说"没问题"，但其实改了一大半没生效

有一回，脚本在处理时跳过了大量正文段落，**却依然在报告末尾写着"格式已按标准修正，未发现需人工确认的问题"。**

我差点直接把这句转述给同事。

从那以后我定了一条规矩：**不许看结论，要看"检查过程本身"。** 交付前必须确认自检是否通过、必须打开文档亲自看几段字体到底对不对。

**"报告说没问题"和"真的没问题"，是两件事。**

---

## 七、给想做同类 Skill 的人几条建议

如果你也想把某个重复性工作做成 Skill，我的经验是这几条：

**1. 先写"不能做什么"，再写"能做什么"**

授权边界比能力清单重要。尤其是涉及数据、对外内容、合规判断的场景，边界不清，AI 越能干越危险。

**2. 标准要精确到数值**

"字体大一点"是无效指令，"仿宋 3 号"才是。所有模糊形容词都要换成可验证的参数。

**3. 一定要有自检环节**

凡是"跳过类"的判断（这条路不走、这个情况不处理），都要配一条独立的覆盖率检查兜底。**因为跳过是最不容易被发现的错误。**

**4. 用真实样本反复迭代，而不是一次写完**

我的版本改了十几轮，每一轮都是拿真实文档跑、发现新问题、再修。**一次性写完的 Skill，遇到第二份文档大概率就崩了。**

**5. 别指望它替你做判断**

它擅长的是"标准明确、重复执行"的部分。真正的判断——数据对不对、流程有没有问题、这件事该怎么处理——**还是要人来做。**

工具的价值是把你从"机械劳动"里解放出来，去做"只有人能做的事"。**如果反过来让它替你做判断，那才是真的危险。**

---

## 八、小结

回到最开始的问题：**这件事值不值得做成 Skill？**

我的判断标准是三条：

1. **这件事每个月都会重复吗？**——是
2. **它有一套明确的标准吗？**——是
3. **它消耗大量时间但不需要创造性判断吗？**——是

三条都满足，那就值得。

我做这个 Skill 前前后后花了一些时间，但它每个月都在帮我省下接近两天的工作量。**而且它越用越顺**——每遇到一个新的坑，就把它变成一条新规则，下次自动避开。

这大概就是"把 AI 用到极致"最朴素的一种理解：**不是找最炫的用法，而是把你最烦的那件重复劳动，彻底交出去。**

---

*本文使用 WorkBuddy 完成写作与文档处理。


标签：WorkBuddy、AI办公、效率工具、Skill开发 分类：人工智能 / 开发工具　**来源：原创

#WorkBuddy 实测：用 Skill 审 12 份质控月报，从两天手工压到两小时

WorkBuddy、AI办公、效率工具、Skill开发

人工智能

开发工具

将医院质控月报审核从12份/两天压缩至两小时，通过WorkBuddy自定义Skill固化审核流程，内置三级处理边界、五步SOP、Word修订留痕及显式格式自检，格式问题自动修正，数据逻辑只标注不改写，实测1265处修改全部可追溯，有效规避格式继承、连锁修改等四大真实踩坑。

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

#WorkBuddy 实测：用 Skill 审 12 份质控月报，从两天手工压到两小时-腾讯云开发者社区-腾讯云

#WorkBuddy 实测：用 Skill 审 12 份质控月报，从两天手工压到两小时

#WorkBuddy 实测：用 Skill 审 12 份质控月报，从两天手工压到两小时

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐