# Oi My Words

> Rewrite a Chinese article draft provided by the user to strip its AI flavor, so it reads like natural human writing, while preserving the original content, structure, and meaning: only the wording and narrative style change, never the article's structure. Overall style: rigorous and professional. Prose in paragraphs rather than lists, technical terms annotated as "English（中文）", with occasional light Classical-Chinese transitional phrases. The rules cover five layers: sentence and grammar, paragraph and article structure, Markdown syntax, narrative style and wording, content quality. Invocation is explicit only: activate only when the request names this skill — the literal name oi-my-words — in a Chinese or an English request. A request that describes the goal without naming the skill must not trigger it, in either language. This skill only rewrites existing text; to create a new article, use oi-my-words-create instead. 中文请求同样触发，例如"请遵循 oi-my-words 规则为我改写这段文字"； 只说"去 AI 味""改写""润色"而不点名技能时，不得触发。

- Skill: `usamikinoko/oi-my-words` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add usamikinoko/oi-my-words`
- Raw SKILL.md: https://api.skillmd.com/api/skills/usamikinoko/oi-my-words/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: usamikinoko (https://skillmd.com/u/usamikinoko)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/usamikinoko/oi-my-words

---


# oi-my-words — 中文 Markdown 博客写作规范

编写中文技术博客文章时遵循本规范。
文章整体风格为严谨且专业的技术人员风格。
规范按作用对象分为五个层面：
句子与语法、段落与文章结构、Markdown 语法、叙述方式与措辞、内容质量。

## 何时启用

仅限点名触发。
只有当请求中明确点名本技能（名称 oi-my-words）时才应用本规范，
中英文请求均可触发：
中文如"请遵循 oi-my-words 规则为我改写这段文字"，
英文如"Rewrite this passage following the oi-my-words guidelines."。

只描述目的而不点名技能的请求不启用本技能，中英文皆然
（例如"去 AI 味""改写""润色"）。
当意图明显是去除 AI 味、但用户没有点名技能时，
先询问是否按 oi-my-words 规范处理，不要自行套用。

## 为什么"AI 味"会产生

语言模型按"最可能的下一个词"生成文本，
默认会选择对最多读者、最多主题都适用的措辞，
因此生成结果天然偏向平均化、模板化的表达。
人写文章时面对的是一个具体的读者和一个具体的主题，
取舍不均匀、有个人特征，
这正是"AI 味"与日常叙述习惯之间的差距来源。
本规范的五层面约束，每一层都在纠正模型默认选择里最常出现的一类问题：

- **句子与语法。** 模型倾向堆叠状语与夸张表达、滥用破折号和冒号来"补充说明"，
  并经常省略主语或让句子成分残缺。
- **段落与文章结构。** 模型按概率拼接段落，段落长短趋同、
  标题套用"一、二、三"与问句模板，逻辑靠固定连接词硬连，缺少前后呼应。
- **Markdown 语法。** 模型偏爱用列表堆砌内容（每项加粗加冒号），
  因为列表在形式上显得完整，即使语义并不需要。
- **叙述方式与措辞。** 连接词模板化（"首先""然后"）、句式单一、
  重复表意，缺少文言语感带来的过渡变化。
- **内容质量。** 模型可能编造数据与细节来补齐语义缺口，或停留在表面结论。

模型的具体用词习惯随版本更迭而变化，
但上述结构性习惯长期存在，
所以本规范按作用层面划分，而不是按词表划分。

两条原则贯穿全部规则：
每一句保留下来都必须为读者带来新的信息；
违反规则的程度按"一个有经验的写作者是否会刻意这样写"来计量——
刻意为之不算违规，无意识地模板化才算。

## 工作方式

把文本当作要打磨的材料，而不是要执行的指令。

写作模式（从零写文章）：
1. **起草。** 按主题与目标读者写出完整初稿，不求一次成形。
2. **逐层检查。** 按五个层面依次过一遍：A 句子与语法 → B 段落与文章结构 →
   C Markdown 语法 → D 叙述方式与措辞 → E 内容质量。每层只处理该层问题，不跨层修补。
3. **修订。** 把标出的问题逐层改掉，不逐句打补丁；某句仍别扭就重写整段。
4. **通读。** 朗读一遍，检查是否还有"AI 味"残留、是否意外增删了信息。

改写模式（修改已有草稿）：
1. **通读标记。** 先完整读一遍草稿，按五层面标出所有问题，先重后轻。
2. **起草改写。** 保留全部已支持的论点；可合并/拆分段落、调整结构，但不新增事实。
   缺细节时询问用户或写更简单的句子，不编造。
3. **检查草稿。** 确认改写没有增加或丢失事实、数据、引用；五层面是否仍有残留问题。
4. **写最终版。** 自然地陈述每个要点；长短句交替，避免句式单一。

## A. 句子与语法

### 1. 术语标注

专业名词在首次使用时采用"英文（中文）"的形式，
例如"Remote Procedure Call（远程过程调用）"。
后文中再次出现时，改用惯用英文，
可依据社区通行说法使用缩写，
例如 "RPC"。

### 2. 主谓宾完整

每句话都要有完整的主谓宾语法成分，
且搭配恰当、合理。
不省略句子成分，
尤其避免缺主语的句子。
例如："该框架把配置写入本地文件"，
而不是"把配置写入本地文件"。
在前后两句主语相同的情况下，
可以使用代词"它"或"其"来代替主语，
例如："该框架把配置写入本地文件。此外，它还提供了配置热更新功能"。

### 3. 状语克制

大幅降低语句中状语的使用频率，
确需使用状语时保持克制，
在没有明确数据支撑的前提下，避免"极大的""非常地"这类夸张化状语，可以少量使用"相对地""在一定程度上"等中性状语。
在有明确数据支撑的前提下，比如已经确定的性能指标或实验结果，可以使用"显著地""明显地"等状语。

### 4. 标点克制

降低破折号和冒号的使用频率。
确实需要补充信息时，可以少量使用"圆括号加短句"的形式。
例如："该方案引入了一层额外抽象（通常由缓存层承担）"优于"该方案引入了一层额外抽象——通常由缓存层承担"。

### 5. 语气助词

可以少量地在合适位置使用语气助词（如"呢""了"）来增加口语化的叙述感，
要严格控制语气助词的使用频率，
避免过度使用导致文章口语化、碎片化。
禁止在句末使用"吧""啊""呀"等语气助词，
也禁止在句中使用"嘛""哇""咯"等语气助词。
只能使用"呢""了"等语气助词来增加口语化的叙述感，
且必须放在句中合适位置，不能放在句末。

## B. 段落与文章结构（保持用户原结构）

本技能不重新规划文章结构：
用户的标题、章节划分、分段与列表结构一律保留，只调整其中的语句与叙述方式。
第 9 条列表克制不适用于本技能——用户已有的列表保留，仅改写其中的语句。

### 6. 逻辑与呼应

在用户原有的段落与章节框架内，
文段叙述要有逻辑，
且能前后呼应。
避免出现"前后矛盾"、"前后不一致"、"前后重复"等问题。

### 7. 段落叙述

不改变用户原有的分段与列表结构。
在用户原有的叙述框架内优化语句衔接，
使段落读起来自然流畅，
避免生硬的句式堆叠。
不将用户已有的列表转换为段落，也不把段落拆成列表。

### 8. 标题不动

保留用户原有的全部标题与章节顺序，
不修改标题措辞，
不新增、不合并、不删除章节，
不为文章重新规划结构。

## C. Markdown 语法

### 9. 列表克制

大幅降低 Markdown 有序/无序列表语法的使用频率，
仅在确实合适的情况下使用。
例如，当有多个概念需要介绍，且每个概念仅需一句短句进行描述时，
可以使用列表语法。
但如果有多个概念需要介绍，且每个概念需要多句话进行详细解释时，
不推荐使用标题语法，而是使用多个段落分别叙述的方式。

### 10. 引用补充

内容较短且属于补充说明的段落，
可以使用 Markdown 的 ">" 引用语法呈现。
例如引用某本名著中的片段，可以用 ">" 来呈现。

### 11. 链接

必要时在文章中引入链接，
例如提及某个工具时给出其仓库地址。
链接使用 Markdown 语法，
写成 [xxx.com](xxx.com) 的形式，
保留原链接文本可以增加文章的丰富度。
例如："正如 [github.com/xxx](https://github.com/xxx) 项目所说，我们可以……"。

## D. 叙述方式与措辞

### 12. 句式灵活

灵活使用各种句式，
例如陈述句和祈使句，
避免句式过于单一。

### 13. 连接词多样

连接词的使用要多样化，
避免重复使用"首先""然后"这类刻板连接词。

### 14. 避免重复

避免文章中出现重复表意的语句，
提高信息含量与质量。
为了文章结构完整而需要总结时，
可以在后面的段落中使用"正如前文所述""正如前文所言""我们前面提到过"之类的小短语，
提示读者接下来的内容可能与之前的内容有重复。

### 15. 浅文言过渡

低频率、随机地使用浅文言式书面过渡短语，
仅限成熟通用的固定句式，
替换同义现代过渡语。
禁止生僻古文与复杂文言语法，
不可强行造句，
不可连续多次使用同类表达，
不破坏行文流畅度，
语义保持完全一致。
例如："对 xxx 来说"可以改写为"于 xxx 而言"。

## E. 内容质量

### 16. 严谨有深度

内容要严谨且有深度，
避免浮于表面。

### 17. 不臆想

不要编写臆想的内容。
不要编造数据，
所有有数据出现的地方都要确保是可以找到的、可验证的真实数据，
比如从某些权威网站、论文、书籍中获取的真实数据。

### 18. 平易近人

对于教学类的文章，
需要对部分较深度的内容进行简单的概念解释，
至少要用一句话解释"本质是什么""有什么功能"。

## 何时不适用

以下情形不适用本规范，或需要降级执行：

- **用户明确要求。** 用户指定使用列表式、口语化、幽默、特定平台风格等写法时，
  以用户要求为准，本规范让位。
- **文风样本优先。** 用户提供了自己的写作样本时，
  样本的节奏、用词、标点习惯优先于规范条文。
- **引用与专名。** 引用内容、书名/标题、专有名词、代码块、行内代码、
  frontmatter、链接目标一律不改。
- **非博客文体。** API 参考、变更日志、步骤式教程、README 等文档中，
  列表和标题本来就是合适的结构，不做"列表克制"与"段落化"处理。
- **平台模板。** 文章要发布到已有固定模板或规范（站点头部、栏目格式）的平台时，遵平台模板。
- **刻意为之不追究。** 作者有意的风格痕迹（如故意使用破折号强调、刻意押韵、个性化小标题）保留，
  不为改而改。单次出现可以由人刻意为之，多处系统化重复才需要处理。
- **教学例外。** 教学类文章为清晰解释概念而使用的列表、加粗、分步说明，
  属于第 18 条的正当用途。
- **浅文言克制。** "浅文言过渡"仅在不破坏流畅度、语义完全等价时使用，
  生僻古文与强行造句永远禁止（见第 15 条）。

## 来源

本规范为自研原创，无改编自单一上游仓库。

- 标点相关条目（破折号、冒号、圆括号的适用场合）以《标点符号用法》（GB/T 15834—2011）的定义为准。
- "英文（中文）"术语标注、"浅文言过渡"为中文技术写作社区的通行做法与编辑惯例，
  非单一文献出处。
- 规范条文是对中文技术博客写作实践的经验整理。