Personal Chinese Writing Style

Personal Chinese Writing Style

Use this skill for Chinese content. The goal is not to explain the style back to the user; the goal is to apply it and verify the final text.

Operating Workflow

1. Identify the content type: article/blog, translation/edit, subtitle/caption, or social post/thread. 2. Load only the needed reference:

• references/punctuation.md - always read for Chinese output.
• references/article-structure.md - read for blog posts, newsletters, long articles, and technical writeups.
• references/voice-and-phrasing.md - read for translation, editing, and long-form Chinese prose.
• references/social-media-style.md - read for X/Twitter, threads, short social posts, and launch notes.

3. Write or edit the content. 4. Run the final punctuation pass before delivering or saving. 5. Fix every real violation in Chinese body text, then reread the affected sentence for meaning.

Non-Negotiable Punctuation

These are output requirements, not suggestions.

Use this exact punctuation in Chinese body text:

• Quotes: use “ and ”. Do not use " around Chinese prose.
• Dash: use - with one space on both sides. Do not use --, ——, or —.
• Ellipsis: use ....... Do not use ……; do not use ... as a Chinese ellipsis.
• Chinese sentence punctuation: use ， 。 ： ； ？ ！ 、. Do not leave , . : ; ? ! between Chinese characters.

Allowed exceptions: YAML frontmatter, code blocks, inline code, JSON/config, URLs, file paths, shell commands, exact source quotes, and English-only sentences.

Final Checklist

Before returning Chinese content, check:

• No " remains around Chinese body text.
• No --, ——, or — remains as a dash in Chinese prose.
• No …… remains; ellipsis is .......
• Chinese sentences use Chinese punctuation, not ASCII comma/period/colon/question/exclamation marks.
• Article prose has no duplicate body # H1 when frontmatter already has title.
• Long-form article endings stay light: no ## 总结, ## 最后, ## 结语, or repeated link dump unless the user explicitly asks.
• Social posts do not end with an empty self-summary such as “这是 X 的标志性时刻”.

Voice Defaults

• Prefer natural Chinese technology prose over literal English translation.
• Avoid business cliches unless they are the precise industry term: 闭环、抓手、颗粒度、对齐、赋能、赛道、弯道超车、心智.
• Delete trust-me lines: “最干净的实现”, “每一步都是真实代码”, “最完整教程”.
• Let facts carry the point; do not over-explain the author’s conclusion in short posts.

Chinese Article Structure Preferences

Core Principle

文章应该像自然对话一样流畅，而不是像教科书大纲那样机械。

Guidelines

1. 结构隐于文中

让内容本身传达层次，不要靠编号、标签、"总结"这类显式脚手架。读者应该感受到结构，而不是看到结构。

• frontmatter 已声明 title，正文不要再写 `# H1` 重复标题。 Markdown 渲染管线（Substack、知识星球、博客主题）大多会用 frontmatter title 渲染大标题，正文 H1 会变成视觉冗余。frontmatter 之后空一行直接进开篇正文，section 用 ## 1. xxx / ## xxx 起步
• 不要在标题里加编号 - 不用"一、""二、""三、"，也不用"1.""2.""3."。标题就是描述性的短语，编号是多余的
• 好：## 坑：sha256 校验挂了
• 避免：## 二、坑：sha256 校验挂了
• 标题保持简洁，不带"主标：副标"结构。 只保留核心概念，补充细节（具体技术名词、解释性内容、本节要拆解什么）放到该章节的正文开头自然引出，而不是塞到标题里。frontmatter 的 title 字段同样不带解释性副标 - 让正文负责展开
• 好：## 核心机制（正文开头再介绍 ui:// 协议和 iframe 沙箱）
• 好：### 5.1 Offscreen 侧（正文负责讲拆什么）
• 避免：## 核心机制：ui:// 协议和 iframe 沙箱
• 避免：### 5.1 Offscreen 侧：拆 WebRTC + 释放音频
• 文章的结尾应该自然收束，不需要仪式感的"总结"章节
• 如果一个子标题只是在给下方内容贴标签（比如"与其他方案的对比"），那它可以被一句自然的引导语替代

2. 用散文连接，不要硬切

话题之间用自然的过渡句桥接，而不是靠标题层级的机械跳转。整篇文章读起来是一个连贯的叙事，不是一份提纲。

• 大的话题转换处，加一句桥接语把上下文串起来
• 写博客不是写论文，语气可以随性、温暖

3. 开篇与收尾

开篇段落承担「写作意图 + 主角点名」两件事，引子可以用客气话收个尾再进正文。

• 开篇用第一人称声明这篇要做什么。 「我会梳理 X」「我会利用这份代码讲清楚 Y」 比「这篇拿 X 当骨架」「本文 Y」更亲近，是中文技术博客的成熟写法
• 开篇至少出现一次主角的英文 ID（产品名、模型名、工具名、库名），用反引号 ` `` 包起来。即使 frontmatter title 已经写过，正文第一段也要重提一次 - 让扫读读者和搜索引擎都抓得住主题
• 引子末尾可以用「期望对大家有所帮助」类客气话收尾再进正文章节。这是中文技术博客的标准惯例，避免技术作者常见的高高在上的语气
• 文章结尾自然收束，回到「跑起来」「资源链接」之类的开放尾部，不要写「总结」「最后」「结语」之类显式的终结章节

Examples

✅ 好：
OpenAI 5 月 7 号在 Realtime API 里放了 `gpt-realtime-translate` - 一个端到端 speech-to-speech 的实时翻译模型。我做了一个 Chrome 扩展叫 `open-realtime-translate` 调通它。

这篇不是产品介绍。我会利用这份代码，把 `gpt-realtime-translate` 模型的使用梳理清楚 - 怎么 X、怎么 Y、怎么 Z。期望对大家有所帮助。

❌ 避免：
# OpenAI gpt-realtime-translate 实战：以 open-realtime-translate 代码为骨架，讲清整条连接生命周期

OpenAI 5 月 7 号 ......

这篇不是产品介绍。这篇拿这份代码当骨架，讲清楚怎么 X、怎么 Y、怎么 Z。每一步都贴真实代码，不是伪代码。

错的版本里有三处问题：H1 重复 frontmatter title、标题带"以 X 为骨架"副标、开篇用「这篇」非第一人称、末尾「每一步都贴真实代码」是 selling line（见下条规则）。

4. 不写 trust-me / 自夸句

事实让读者自己判断。不要在文章里提前夸自己 / 夸内容质量 / 引导读者预先信任。这条覆盖博客和推文都适用。

判断方法：句子如果能被压缩成「这（产品 / 做法 / 文章）+ 最高级形容词」（最稳、最详细、最完整、最干净），它就是 selling line，删掉。show, don't tell。

5. 尾部克制

强烈偏好轻量级结尾。 文章最后不要做仪式感的总结、不做正反对比定位、不做资源清单堆砌。让最后一节自然结束就好。

不要写

• ❌ ## 总结 / ## 最后 / ## 结语 / ## 写在最后 等显式终结章节
• ❌ 收尾段做横向对比定位：「它是 X，不是 Y 的替代品。Y 在 A 上强，X 在 B 上顺手」- 即使每句都是事实，组合起来就是 positioning，读起来像产品页 elevator pitch
• ❌ ## 链接合集 / ## 资源 header 配 2-3 条链接，里面还有正文 inline 已经出现过的重复链接

怎么收

• ✅ 最后一节自然讲完就停。不解释、不总结、不"小结一下"
• ✅ 一两个核心外链（仓库、主资源）→ 文末加一个 --- 分隔线 + 裸 bullet，不加 section header
• ✅ 三条以上链接、或链接需要分组才用 ## 链接合集 这类 header
• ✅ 正文 inline 已经出现的链接，结尾不要再列一遍

Examples

✅ 轻量结尾（推荐）：
...... 最后一节正文结束 ......

---

- 仓库：[github.com/sugarforever/01coder-agent-skills](https://github.com/sugarforever/01coder-agent-skills)

❌ 总结 + 对比定位 + 重复链接（避免）：
...... 最后一节正文结束 ......

定位是清楚的：它是一个 X，不是 Y 的替代品。Y 在 A 上更强，X 在 B 上更顺手。两边并不互斥。

## 链接合集

- 仓库：[github.com/.../...](...)
- 配套博客：[正文已经 inline 过的那篇](...)
- 文中提到的 API 文档：[正文已经 inline 过的那个](...)

判断方法：把文章最后一节之后的内容删掉，剩下的文章是否完整、流畅、不悬空 - 如果是，那段尾部就是冗余的。

Chinese Punctuation Rules

Apply these rules to Chinese body text. They do not apply to YAML frontmatter, code, JSON/config, URLs, file paths, commands, or exact source quotes.

Required Forms

Use the form on the left. Replace the form on the right.

• “中文” replaces "中文".
• 前文 - 后文 replaces 前文--后文, 前文——后文, and 前文—后文.
• 中文...... replaces 中文…… and Chinese prose ellipsis written as 中文....
• 中文，中文。 replaces 中文,中文..
• 问题？回答！ replaces 问题?回答!.
• 说明：内容；补充 replaces 说明:内容;补充.

Common Failure Modes

• Straight quotes remain in Chinese prose: 他说"可以运行了" should be 他说“可以运行了”.
• The model writes -- or —— for a dash. Replace with - .
• The model writes ……. Replace with .......
• English punctuation leaks into Chinese sentences: 中文,中文 should be 中文，中文.

Examples

Correct:
Clawdbot 文档推荐使用 Opus 4.5，部分原因就是它有“更好的 prompt injection 抵抗能力” - 这说明维护者很清楚这是一个真实问题。
所有这些......能力确实是变革性的。

Avoid:
Clawdbot 文档推荐使用 Opus 4.5,部分原因就是它有"更好的 prompt injection 抵抗能力"——这说明维护者很清楚这是一个真实问题。
所有这些……能力确实是变革性的。

Manual Audit

Before delivering, scan the final text for these literal tokens:

• " in Chinese body text.
• --, ——, or — used as a dash.
• …….
• , . : ; ? ! between Chinese characters.

Fix all true positives. If a token is inside a source quote or technical syntax, keep it and do not rewrite the quoted/source material.

---

Bullet 列表项的结尾标点

列表项的句号要么都加、要么都不加，不混搭。这是排版一致性的小要求，不是 punctuation 选择题。

When to use which

• 列表项是完整句子（带主语 + 谓语 + 宾语，能独立读完不别扭）→ 都加句号
• 列表项是名词短语 / 关键词 / 标签 / 短结构（如「闭环」「跑通流程」）→ 都不加
• 列表项是「短语 + 解释」（用 - 或冒号分隔的展开）→ 看解释部分：解释是完整句就都加，解释是短语就都不加

Examples

✅ 一致（都加，因为每项是完整句）：
- 客户端代码在打包后是公开的，key 一旦出现就有可能被反编译看到。
- Mint client secret 在服务端做，offscreen 只接到生命期几分钟的临时 token。
- 即使被截获影响也有限。

✅ 一致（都不加，因为每项是短语）：
- 闭环
- 抓手
- 颗粒度

❌ 不一致：
- 这是第一项。
- 这是第二项
- 这是第三项。

---

Application Scope

These preferences apply to:

• Blog posts and articles
• Translated content
• Video subtitles (Chinese)
• Social media posts

Exceptions:

• Code and technical identifiers
• Markdown/YAML frontmatter
• Direct quotes from sources (preserve original punctuation)

Social Media Writing Style

推文（X/Twitter）发布的写作偏好。适用于 tweet-insight 等技能生成的内容。

语气

自然但不过于口语化。推文是公开发布的内容，需要一定的正式感。

Examples

✅ Anthropic 的博客介绍了他们怎么设计 Managed Agents 的架构
❌ Anthropic 工程博客讲了他们怎么设计 Managed Agents 的架构
❌ Anthropic 于其工程博客中阐述了 Managed Agents 架构的设计理念

Editorial Restraint（短文本要节制）

推文/短帖里 "作者表达" 的空间很小。过度 editorial 反而稀释事实的力量。短文本的核心是让事实自己讲，不是作者解读给读者听。

删显性因果连接

让事实并列摆出来，读者自己接因果。"原因是""所以""因此""其实" 这类显性连接词把推文变成分析报告。

软化强断言副词

"就是""完全""一定""根本" 这类强化副词在 personal-voice 里要少用 - 听起来像键盘评论员。换成 "似乎""看起来" 或者直接去掉。

例外：陈述事实时不算（"这就是他原话"），规则只针对带主观判断的句子。

Emoji 当强动词用

需要表达 "暴跌""飙升""崩盘" 这类强烈方向感时，考虑用 emoji 替代 - 视觉信号比形容词更直接，也更不像 editorial。

不是每条推文都该塞 emoji。判断标准：动词表达的情绪过强、容易让句子读起来像广告或键盘评论员，那就用 emoji 把那个动词替掉。

推文别加作者总结句

写博客可以总结，写推文别在最后加一句 "这应该是 X 的最干净案例""这是 Y 的转折点" 这类自我盖章。短文本里数据 + 引述放完，直接到链接，让读者自己得结论。

例外：如果总结句本身就是核心观察 - 不是把前文复述一遍而是给出新角度 - 可以保留。判断方法：把总结句删掉，看推文是否还成立。如果还成立，删；如果删了不成立，那它不是 "总结" 而是 "主张"，留着。

并列项呈现

2 个及以上的并列概念，且各自带展开说明时，用列表呈现，不要塞在一段话里。

• 有序数关系（"两个原因""三个阶段"）→ 用编号（1. 2. 3.）
• 平行概念无序数关系 → 用 bullet（-）
• 条目很短且无需展开 → 可以保持内联

Examples

✅ 好（编号 - 有"两个原因"引导）：
Karpathy 认为这种分裂有两个原因。
1. 技术上，强化学习需要可验证的奖励函数 - 代码能不能跑、测试过不过，这些有明确的对错判断，所以 RL 在编程和数学上进步最快。
2. 商业上，编程和技术类任务的 B2B 价值最高，公司自然把最多资源投在这些方向。

✅ 好（bullet - 平行概念）：
他们把 agent 拆成了三个独立组件：
- Brain（Claude + harness，负责推理决策）
- Hands（沙箱和工具，负责执行）
- Session（append-only 事件日志，负责记忆）

❌ 避免（内联塞太多）：
他们把 agent 拆成了三个独立组件：Brain（Claude + harness，负责推理决策）、Hands（沙箱和工具，负责执行）、Session（append-only 事件日志，负责记忆）。

链接位置

引用推文的链接放在开头一两句引入文字之后，不要放在最前面（太突兀），也不要放在最后面（X 不会生成卡片预览）。

Examples

✅ 好：
Anthropic 的博客介绍了他们怎么设计 Managed Agents 的架构 - 一个让 Claude 能长时间自主运行任务的托管服务。

https://x.com/AnthropicAI/status/2041929199976640948

有几个细节值得注意......

❌ 链接在最前面：
https://x.com/AnthropicAI/status/2041929199976640948

Anthropic 的博客介绍了......

❌ 链接在最后面：
......所以架构必须对具体实现保持不预设立场，才能撑住未来。

https://x.com/AnthropicAI/status/2041929199976640948

内容结构

结构随内容而定，不要套用固定模板。

• 不是所有内容都适合 1/ 2/ 3/ 4/ 分点
• 有的内容适合连续叙事，有的适合分点 + 叙事混合
• 让内容本身决定呈现方式

资源链接

推文末尾可以附上对读者有价值的资源链接（原文、指南、GitHub 等），简洁标注即可。

Example

原文：anthropic.com/engineering/managed-agents

Voice and Phrasing - Avoid Translation Style and Net-Slang

中文科技写作应该读起来像中文，不像英文翻译过来的。避免最近几年从英文直译或网感文化里冒出来的构造 - 这类构造让文章读起来像 PR 稿或 AI 生成的内容，覆盖掉个人声音。

Patterns to Avoid

Worth-X 构造（X 值得花）

直接翻译自英文 "worth X" / "worth doing X"。中文里 "值得花" 单独使用，"花" 没了宾语，读起来悬空。

Can't-Afford 构造（你买不起 X 的成本）

"You can't afford X" 的直译。中文里 "买不起" 一般指实际购买，引申到 "代价/后果" 时不自然。

业绩/Business 化的 Metaphor

Startup 圈和大厂术语，过度使用让文章像周报或竞品分析。

例外：行业内已成主流术语且没有更精确替代时可以保留（如 "技术栈" "护城河" 这种已经稳固的）。

口语 / 拟人化动词（博客 / 文章场景）

博客和长文上下文里避免太生活、太拟人化的动词。换成中文技术写作的标准词，让语气和载体匹配。

应用范围：这条主要针对博客 / 文章；视频脚本和推文有更多口语余地。但有一类即使在视频口播稿里也要避开 - 把工具 / agent 拟人成「人在干活」的生活化动词（默默干、喊一声、长在、活儿、丢进……）。口播稿可以口语、可以亲切，但不要拟人化到像在描述一个人打零工。判断：换成中性动词（运行、触发、就在、场景、放进）后，句子是不是照样自然、且更像「讲技术」而非「唠家常」 - 是就换。真正生动的口语（如"用眼睛去点屏幕""留一道你自己来确认"）保留。

物理域隐喻借译（thin wrapper / hot path 类）

英文软件圈用一组物理属性词修饰抽象结构 - thin/fat、light/heavy、deep/shallow、clean/dirty、hot/cold。这些在英文里已经是「死隐喻」（dead metaphor）- 读者直接 perceive 抽象含义，不再唤起物理意象。

借译到中文后命运分两种：

• 已被中文吸收（保留，不要矫枉过正）：深度学习、深拷贝、浅克隆、胖客户端、黑盒、健壮、优雅、干净的实现
• 没被吸收（直译给中文读者制造的是物理意象，不是抽象含义）：

判定方法见下方 How to Spot 的 Test 1 + Test 3（搭配 native collocation 检索）。

为什么这条不靠词表：物理域隐喻是个开放集合 - 你列不全所有英文物理形容词与抽象名词的搭配。而且「吸收」是个时间窗口里的连续过程：「深度学习」十年前也是 calque，今天就是中文；「薄」可能十年后被吸收，也可能永远不会。词表永远滞后。所以规则是 principle + canonical examples + test，不是 closed list。

How to Spot

Test 1：回译还原。 如果一句中文几乎可以一对一回译成英文且不丢信息，它八成是翻译腔。

Test 2：单句独立读。 把一句话从文章里抽出来，独立读。如果像 startup 公关稿、产品 landing page 标题、或科技博主搞流量的话术 - 那它八成是网感词。

Test 3：Native collocation 检索（专攻物理域隐喻借译）。 把可疑词组（"薄+协议"、"热+路径"）扔进搜索引擎或语料检索。命中的大多是翻译过来的英文技术文 / AI 生成的稿子，那它还没被中文吸收。命中的有相当比例是中文 native 作者写的（独立写作、非翻译），那它已经吸收了，可以用。

三个 test 任一中招，换日常中文（划算、代价、值得做、帮助、记住、轻、直接、简单）。

Why This Matters

这些构造在语法上都没错。但它们集中出现在：

• AI 从英文翻译过来的稿子
• 出海派 startup 的中文 blog
• 近 2-3 年的科技博主网感文

一篇博客如果带这些构造，读者很容易把它归到上面三类，而不是 "personal voice"。

Add as encountered

This list grows over time. When auditing copy and a phrase feels off but it isn't covered above, add the pattern + replacement here.