agent-style：把技术写作规则装进 AI Agent
我看 agent-style 时，最先注意到的不是它有 21 条规则。规则谁都能写，难的是怎么让这些规则真的进入 AI 的工作流。
agent-style 做的正是这件事：把写作规则装进不同 AI Agent，再给你一个 style-review Skill 做二次审稿。
它的语境也要先说清楚。
README 里写的适用场景，主要是英文技术写作：API 文档、设计文档、论文、grant proposal、README、runbook、commit message、postmortem。
小说、诗歌、营销文案、强情绪长文，都不是它的重点。
所以这篇不把它当中文公众号工具来推荐。
我更想拆的是它的产品化写法：规则集放在 RULES.md，压缩版放在 docs/rule-pack-compact.md，审稿入口放在 skills/style-review/SKILL.md，命令行用 agent-style review --audit-only FILE 做机械检查。
这些东西合在一起，才是这篇文章要拆的重点。
1. 先把来源说清楚
agent-style 的仓库在这里：
https://github.com/yzhao062/agent-style
它也发布成了 Python 和 npm 包。
如果只想让 AI 帮你装，可以把仓库地址给 AI：
https://github.com/yzhao062/agent-style
然后说：
帮我安装 agent-style，并在当前项目里启用适合这个 AI 工具的写作规则。
这篇主要看这几个文件：
README.md
RULES.md
docs/rule-pack-compact.md
skills/style-review/SKILL.md
先看规则，再看它怎么被装进工具里。
2. 21 条规则分成两类
agent-style 把规则分成两组。
第一组是 12 条经典写作规则。
来源包括 Strunk & White、Orwell、Pinker、Gopen & Swan。
比如：
- 不要假设读者知道你的隐含知识。
- 当行动者重要时，不要用被动语态。
- 有具体词就不要用抽象词。
- 删掉多余词。
- 不要用陈词滥调。
- 证据弱时不要把话说满。
- 长句要拆，句长要有变化。
第二组是 9 条来自 AI 输出观察的规则。
这组更贴近我们平时看到的 AI 味：
- 不要把不是列表的内容硬改成 bullet points。
- 不要把 em dash 当成默认标点。
- 不要连续用同一个句子开头。
- 不要滥用 Additionally、Furthermore、Moreover。
- 不要每段都用一句总结收尾。
- 事实性判断要有证据或引用。
这两组放在一起，能看出它的判断：技术写作的问题不只来自 AI，也来自老毛病。
读者背景没交代，动作主体藏进被动语态，证据不够还把话说满，这些问题以前就有。LLM 只是把它们放大了，又额外带来过度 bullet、转场词堆叠、em dash 泛滥这些新毛病。
所以它没有只做一张“反 AI 词表”。它先把技术写作本来就该守的规则补上，再处理模型输出里特别常见的坏习惯。
3. 它不是只做事后润色
agent-style 有两条使用路径，一条在写之前，一条在写之后。
写之前，它会把规则装进当前 AI 工具的上下文里。这个路径在 README 里叫 soft enforcement。简单说，就是让 AI 起草第一版时先看到规则，少走弯路。
写之后，它提供 style-review。
这是一个 opt-in 的二次审稿 Skill。文档已经写出来以后，你再让它审一遍，看有没有长句、空泛词、过度 bullet、证据不足这些问题。
这套设计比“请你遵守以下 21 条规则”更稳。生成前规则只能降低出错概率，不能保证模型每次都照做；审稿入口则给了第二次拦截的机会。
4. style-review 怎么工作
skills/style-review/SKILL.md 里写了它的流程。
单文件审稿时，它大致走两层。
第一层是确定性审计。它会调用：
agent-style review --audit-only FILE
这部分查机械规则，比如 em dash、转场词、长句、标题大小写、常见空话。
第二层是语义审计。
有些规则没法靠正则判断。
比如：
读者会不会看不懂这个术语？
这个事实判断有没有证据？
这句话是不是把证据说过头了？
这些需要模型结合规则和例子来判断。
两层结果合并后，它会输出 scorecard。如果用户同意，它才会写一个 FILE.reviewed.md。
这个文件名细节很值得抄：它不直接改原文件。审稿应该可回退，原稿要留着，尤其是团队文档和公众号长文。
5. 它为什么适合技术写作
技术写作最容易出两种问题。
一种是读者根本看不懂。作者默认读者知道太多背景，一上来就堆缩写、方法名、内部术语。
另一种是写得很顺，但事实支撑不够。
比如“显著提升”“行业领先”“证明了什么”，看着像结论，细看没有证据。
agent-style 对这两类问题都很敏感。
它把 RULE-01 放在很前面：不要假设读者共享你的隐含知识。
它又把 RULE-H 标成关键规则：事实性判断要有引用或具体证据。
这也是它和普通“去 AI 味”工具的区别：它先问读者能不能懂，事实能不能站住，然后才处理句子好不好看。
6. 对公众号写作有什么借鉴
虽然 agent-style 主要是英文技术写作，但有几条可以直接迁移到公众号。
迁移到公众号写作，我会先拿它检查三件事。
第一，读者状态有没有写清楚。写 Skill 深拆时，读者可能不懂源码，也可能懂一点命令行。文章不能默认他们都知道 CDP、adapter、frontmatter、CLI 是什么。
第二，事实判断有没有支撑。讲一个 Skill 的实现，就要读源码、看脚本、确认仓库结构。没看到的地方就说没看到，不能为了让文章顺，补一个自己没验证过的机制。
第三，结构有没有过度列表化。公众号文章可以用列表，但整篇都像 README.md 的功能清单，读者会很快疲劳。有些段落讲完就该往前走，不需要再补一句空总结。
7. 对写 Skill 有什么启发
agent-style 最值得学的，是它把规则做成了能落地的一套东西。
它不只说“请按 21 条规则写作”，还把这些问题提前想了：
不同 AI 工具怎么接入
哪些规则可以机械检查
哪些规则需要模型判断
审稿后文件怎么保存
如何避免覆盖原稿
怎么用 benchmark 看效果
如果只是个人使用，一个 SKILL.md 可能够了。
如果希望别人也能用，就要继续往下想：
- 安装后放在哪？
- 怎么确认它生效了？
- 它会不会误改原稿？
- 用户怎么查看前后差异？
- 哪些规则能自动检查？
- 哪些规则只能靠人工判断？
一个好 Skill，最后拼的是这些小地方，不是几句漂亮口号。
8. 我的判断
agent-style 不适合直接搬来写中文公众号。它的语境是英文技术文档，里面不少规则也明显偏英文。
但它很适合拿来学习“写作规则怎么工程化”。
它把风格规则拆成可引用、可安装、可检查、可二次审稿的一套东西。对我来说，它有启发的地方，是把“别写 AI 味”往前推了一步。
先别急着判断像不像 AI。先看读者能不能懂，事实有没有支撑，句子有没有把具体东西说出来。
这些做好了，文章通常就不会那么飘。
