Hermes Agent 技能实战：从零搭建文档质量审核工作流

最近折腾 Hermes Agent 的技能系统，走了不少弯路。把整个过程整理成这篇实操笔记，从搜索安装、自建技能到公众号发布，一条龙。

一、先装一个现成的：avoid-ai-writing

这个技能的作用是检测并重写 AI 写作痕迹。它的核心逻辑是识别 51 种 AI 写作模式，包括套话开场、意义夸大、模糊归因、词汇降级等等。

安装方法很简单——从 GitHub 拉 SKILL.md：

# 目标路径（Windows 用户注意用 MSYS2 路径）
SKILL_DIR="/c/Users/woodt/.hermes/skills/user_skills/avoid-ai-writing"
mkdir -p "$SKILL_DIR"

# 通过 jsDelivr CDN 下载（国内能访问）
curl -sL "https://cdn.jsdelivr.net/gh/conorbronsdon/avoid-ai-writing@main/SKILL.md" \
  -o "$SKILL_DIR/SKILL.md"

踩坑记录：

jsDelivr 的 URL 路径要和 GitHub 仓库结构一致。avoid-ai-writing 的 SKILL.md 在仓库根目录，不是 plugins/avoid-ai-writing/ 下
下载后只有 14 字节说明路径错了——那是个 404 页面。用 head -5 SKILL.md 验证是否拿到了 YAML frontmatter
Windows 的 ~ 在 git-bash 里解析到 /home/woodthree，不是 C:\Users\woodt，路径写错就装到奇怪的地方了

装完后刷新 WebUI 就能用了。触发词包括 “remove AI-isms”、“clean up AI writing” 等。

二、自建一个 doc-writing-qa 技能

社区里没有现成的文档质量审核技能，于是我自己写了一个。核心思路是把 QA 拆成 5 个维度：

1. 结构检查 — 标题层级是否连续、有没有孤儿段落、章节是否重复

2. 术语审计 — 同一概念在不同地方是否用了不同叫法（比如 “API endpoint” 和 “接口” 混用）

3. 事实一致性 — 数据前后矛盾、引用缺失、版本号冲突

4. 逻辑连贯性 — 引言是否呼应正文、结论是否由正文推导而出

5. 写作质量 — 结合 avoid-ai-writing 的模式检测 + 冗余重复检测

文件结构：

~/.hermes/skills/user_skills/doc-writing-qa/
└── SKILL.md    # 6.5KB，包含完整的工作流程和输出模板

关键设计决策：

用 [OK] / [WARN] / [ERROR] 三级标记，避免过度纠正
支持 Markdown、DOCX、纯文本三种输入格式
与 avoid-ai-writing 联动：先跑结构/术语 QA，再跑 AI 痕迹清理
引用部分之后的孤立段落几乎总是复制粘贴错误，标记为 ERROR

踩坑记录：

技能文件写到 user_skills/ 目录下，WebUI 不会热加载。需要刷新页面或重启 Gateway 才能识别
SKILL.md 的 frontmatter 里 name 字段必须和目录名完全一致，否则技能系统找不到
61KB 的 avoid-ai-writing 和 6.5KB 的 doc-writing-qa 加载速度差异明显，技能文件不宜过大

三、实际效果演示

假设有一篇公众号文章草稿 article.md，运行 doc-writing-qa 后输出类似这样的报告：

# Document QA Report

## Structure
- [OK] Heading hierarchy: H1 → H2 → H3 (valid)
- [WARN] Section "其他" at line 234 has no sub-sections
- [ERROR] Orphaned paragraph at line 312 (after references)

## Terminology
- [OK] "Hermes Agent" used consistently (42 occurrences)
- [WARN] Mixed usage: "API endpoint" (3x) vs "接口" (2x)
- [ERROR] Inconsistent casing: "windows" (line 89) vs "Windows"

## Writing Quality
- [WARN] 3 instances of AI-tell patterns detected
- [INFO] Average sentence length: 28 chars (normal)

然后交给 avoid-ai-writing 做一次清理，基本就能达到发布标准。

四、发布到微信公众号

整个流程的最终产出是发到公众号的文章。我用的是 wechat-official-account 技能，它封装了 wechat-public-cli 工具。

发布工作流：

写好 markdown 文章，frontmatter 里设置 banner_path
封面图用 Agnes AI 生成为主图，上传到微信公众平台获取 thumb_media_id
正文插图同样用 Agnes 生成，通过 upload-body-image.js 上传到微信 CDN
替换 markdown 中的本地图片路径为微信 CDN URL
运行 wechat-public-cli wechat:draft 创建草稿
订阅号需手动在后台发布（草稿箱 → 发布）

踩坑记录：

封面图上传经常报 40113 unsupported file type，即使 PNG 完全有效。解决方法是用 upload-thumb.js 脚本手动上传拿到 media_id，然后 frontmatter 里用 thumb_media_id 替代 banner_path
正文图片和封面图走的是完全不同的 API 端点，不能混用
绝对路径在 banner_path 里会双重拼接 CWD 导致 ENOENT，必须用相对路径
wechat:draft 命令执行前必须先 cd 到 workspace 目录，否则相对路径全部失效

五、总结

技能	用途	来源	大小
avoid-ai-writing	AI 写作模式检测与重写	GitHub 社区	61KB
doc-writing-qa	文档质量审核（自建）	自行编写	6.5KB
wechat-official-account	公众号草稿发布	内置	-

核心经验：

社区技能优先搜索 GitHub + jsDelivr CDN 安装，国内网络比直接 clone 快
没有合适的就自己写 SKILL.md，结构清晰比功能全面更重要
技能装完要刷新 WebUI 才能识别，别以为没装上就放弃
公众号发布的坑主要在图片上传，记住 banner_path 上传大概率要 fallback 到 thumb_media_id

整个工作流跑通后，从写作到发布基本可以半自动化。下次打算把这套流程做成 cron 定时任务，定期审核和发布。