# Oi My Words Create

> Write Chinese Markdown blog articles that follow natural everyday narrative habits, based on a topic or outline the user provides. Overall style: rigorous and professional. Prose in paragraphs rather than lists, technical terms annotated as "English（中文）", headings as declarative level-2 and level-3 headings, with occasional light Classical-Chinese transitional phrases. Plan the article's structure and section divisions before writing. 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-create — 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 creates new articles; to rewrite existing text, use oi-my-words instead. 中文请求同样触发，例如"请基于 oi-my-words-create 规则为我编写一篇 Markdown 文档"； 只说"写博客""写篇文章""撰写技术文章"而不点名技能时，不得触发。

- Skill: `usamikinoko/oi-my-words-create` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add usamikinoko/oi-my-words-create`
- Raw SKILL.md: https://api.skillmd.com/api/skills/usamikinoko/oi-my-words-create/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-create

---


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

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

## 何时启用

仅限点名触发。
只有当请求中明确点名本技能（名称 oi-my-words-create）时才应用本规范，
中英文请求均可触发：
中文如"请基于 oi-my-words-create 规则为我编写一篇 Markdown 文档"，
英文如"Write a Markdown article following the oi-my-words-create guidelines."。

只描述目的而不点名技能的请求不启用本技能，中英文皆然
（例如"写博客""写篇文章""撰写技术文章"）。
当意图明显是从零撰写文章、但用户没有点名技能时，
先询问是否按 oi-my-words-create 规范处理，不要自行套用。

## 为什么"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. 语气助词

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

### 6. 人称代词

在撰写新文章/博客时；
如果没有明确指定，
默认使用第一人称代词"我们"来指代作者群体，
但是也要尽量少使用第一人称代词，
避免文章过度口语化、碎片化。

## B. 段落与文章结构

动笔前先规划文章结构，再按规划逐节写作。

### 7. 逻辑与呼应

文段叙述要有逻辑，
且能前后呼应。
避免出现"前后矛盾"、"前后不一致"、"前后重复"等问题。

### 8. 段落叙述

多使用段落叙述。
分段的依据是本段要介绍的内容：
既不要把全部内容整合进一个段落导致繁冗，
也不要分段过碎导致难以阅读。
段落长短错落有致，
避免各段字数彼此接近。

### 9. 结构与标题规划

写作前先规划结构：
先确定文章的中心论点或主线，
再规划章节（二级标题 "##"），
每个章节下按内容划分小节（三级标题 "###"，必要时四级标题 "####"）。
规划先行：先列出章节与小节提纲，确认覆盖完整、逻辑连贯、无重复后，再逐节写作。
标题要凝练简洁，
采用陈述式，
不使用标点符号，
不使用序号。
例如："## 依赖管理的演进"，
而不是"### 一、依赖管理——为什么会乱？"。

每个小章节下的内容至少要包含两个段落，
且不能是两个单句段落，
至少是一个长段落+一个短段落。
如果有只适合放在单个段落中的内容需要分节，
你可以考虑将其作为补充说明，
使用 Markdown 的 ">" 语法将其添加在合适的段落末尾。

## C. Markdown 语法

### 10. 列表克制

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

### 11. 引用补充

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

### 12. 链接

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

## D. 叙述方式与措辞

### 13. 句式灵活

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

### 14. 连接词多样

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

### 15. 避免重复

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

### 16. 浅文言过渡

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

## E. 内容质量

### 17. 严谨有深度

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

### 18. 不臆想

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

### 19. 平易近人

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

## 何时不适用

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

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

## 来源

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

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