人工写作

核心原则

• 主动语态：用“我们发布了修复”而非“修复已被发布”
• 明确动作主体：每句话都需有具体的人作为主语并执行某个动作。无生命对象不会修复 Bug、转变文化，也不会向我们传达任何信息——只有人才会。
• 具体优于模糊：用“将报表生成时间从 4 小时缩短至 15 分钟”，而非“节省时间”
• 使用简单词汇：用“use”而非“utilize”，用“help”而非“facilitate”，用“start”而非“initiate”
• 采用肯定形式：直接说明“是什么”，而非“不是什么”——例如用“Ignore”，而非“Do not pay attention to”
• 表达自信：删去“almost”、“very”、“really”、“quite”、“arguably”及所有以 -ly 结尾的副词
• 内容具体可感：命名具体事物，给出确切数字，注明信息来源
• 删减冗余词语：用“Because”而非“due to the fact that”；用“Now”而非“at this point in time”；用“Can”而非“has the ability to”
• 使用缩略形式：如“don’t”、“won’t”、“it’s”、“they’re”——未缩略形式是 AI 写作的显著特征之一
• 让读者身临其境：用“You”优于“People”；用具体描述优于抽象概括；避免远距离旁白式叙述

AI 写作模式 —— 见即清除

检测重点应放在结构上：模型复现句子结构的可靠性远高于词汇选择，而大多数 AI 语调藏于句式形态之中，而非具体用词。

禁用词汇：delve、crucial、pivotal、foster、leverage、tapestry、testament、underscore、vibrant、landscape（抽象义）、shape（抽象义，如“previous shape” / “the shape of the problem”）、interplay、multifaceted、enhance、enduring、garner、showcase、Additionally、seamless、robust、cutting-edge、groundbreaking、nestled、renowned

结构性识别特征：

• 三元组套路：强行堆砌三个并列动词（如“streamline, optimize, and enhance”）
• 否定式平行结构：“It's not just X — it's Y” 或 “Not X. But Y.” → 直接陈述 Y
• 表层 -ing 短语：“ensuring reliability”、“showcasing features”
• 系动词规避：“serves as”、“stands as”、“boasts” → 改用“is”、“has”
• 同义词轮换：连续四句用四个不同名词指代同一事物
• 虚假范围表述：“from X to Y”，但 X 和 Y 并不在同一有意义的量纲上
• 公式化挑战句式：“Despite X, Y continues to thrive”
• 戏剧性碎片化：“[Noun]. That's it. That's the [thing].” —— 表演式极简
• 修辞性铺垫：“What if I told you...” / “Think about it:” / “Here's what I mean:”
• Wh- 开头句式：以 What/When/Where/Which/Who/Why/How 起始的填充式问句。应重构为以主语或动词开头。
• 远距离旁白视角：“This happens because...”、“People tend to...”、“Nobody designed this.” → 改为让读者置身其中
• 懒惰式极端表述：every、always、never、everyone、nobody —— 假权威。改用具体事实替代笼统断言
• 元评论（meta-commentary）：“Hint:”、“Plot twist:”、“Spoiler:”、“In this section, we'll...”、“As we'll see...”、“Let me walk you through...”

格式类识别特征：

• 正式行文中禁止使用 em dash（—）—— 应重写句子（拆分、加逗号、改用冒号或彻底重写）；en dash（–）仅限数字范围中使用
• 机械式高频加粗：每间隔几个短语就加粗一次
• 带 emoji 的标题（例外：README 中的章节标题；见下方 README 规则）
• 加粗标题式项目符号列表（Thing: explanation of thing）
• 每个单词首字母大写的标题格式（Title Case）—— 改用句首大写（sentence case）

禁用短语—— 见即删除并重写。完整清单参见 references/phrases.md。

高频违规项：

• “In today's rapidly evolving landscape”
• “game-changer”、“revolutionary”、“transformative”
• “Moreover”、“Furthermore”、“Additionally”（作为句首连接词）
• “It's worth noting that”、“It is important to note that”
• “At the end of the day”
• “Here's the thing:” / “It turns out” / “Let me be clear” / “The uncomfortable truth is”
• “Full stop.” / “Let that sink in.” / “Make no mistake”
• “In order to” → “To”｜“Due to the fact that” → “Because”
• 泛泛而谈的结论：“The future looks bright” → 替换为具体计划

沟通冗余物（全部删除）：谄媚式开场与收尾（如“Great question!”、“I hope this helps!”）、知识截止日期提示（如“As of my last update”）、模糊归因（如“Experts argue”）。

虚假主体（False Agency）

AI 常通过赋予无生命对象人类动词来规避明确动作主体。请找出真实的人，并将其置于句首。

若无特定人物对应，可用“You”将读者置于决策者位置。人称使用规则如下：“you” 指读者，“we” 指组织行为，“I” 指个人声音。避免第三人称被动语态（如“it was decided”）—— 务必点明动作主体。

质量关卡（Quality Gate）

首先按长度分流处理：短文本（提交信息、PR 描述、评论、帖子）：快速审核 + 自检 1–4，到此为止；长文本（文档、文章、报告）：按 audit-workflow.md 执行两阶段审核，再完成自检 1–5。

快速审核—— 标记以下任一情形；标记仅为候选，非最终判定（编辑前须先审慎裁决）：

• 是否含强化词及 -ly 类模糊副词（如“very”、“really”、“significantly”）？标记它们。
• 是否存在被动语态？找出动作主体，使其成为主语。
• 是否有无生命对象执行人类动词？请指出具体人物。
• 是否存在 “Not X, it's Y” 类对比结构？请直接陈述 Y。
• 是否连续三句长度一致？拆分其中一句。
• 是否存在模糊陈述句（如“The implications are significant”）？请指出具体影响。
• 是否存在元连接词（如“The rest of this section...”）？删除。让文本自然推进。

克制原则 —— 过度编辑与编辑不足同等严重。

• 若某句已读来自然，请保留原样。修改本已合格的文本，反而易引入新问题并削弱作者声音。
• 关注语感，而非字面匹配。列表中某个词若在上下文中自然成立，则无需标记——应标记的是语气，而非词汇本身。对某词实行一刀切禁令属于机械式编辑，而这正是本规范力图消除的问题。

长文本输出骨架（标签词汇、严重程度后缀及修正操作详见上方审核流程参考）：

## AUDIT
1. "quoted snippet" [TAG] [TAG +H]
— END AUDIT: [n] issues found —

## CORRECTED TEXT
[full corrected text]

## CHANGELOG
- Line/section: brief description of change

语气（Voice）

• 持有观点—— 对事实做出反应，而非仅作陈述
• 节奏多变—— 短句之后接长句。快速审核规则：连续三句长度一致？拆分其中一句。
• 承认复杂性—— “impressive but also unsettling” 优于单说 “impressive”
• 适时使用第一人称—— “I keep coming back to...” 明确传递真人发声信号
• 精准表达感受—— 不说“this is concerning”，而要指出具体令人不安之处
• 容许适度杂乱—— 片语（“Because that's real.”）、以连词开头的句子（“But that changes everything.”）、插入语（思考过程中的即兴补充）—— 全部体现真人起草痕迹，而非机器生成

行文结构（Composition）

• 一段只讲一个主题。首句即主题句。
• 相关词语尽量靠近。强调性词语置于句末。
• 勿用逗号连接两个独立分句；勿将一句话硬拆成两句。
• 现在分词短语作状语时，其逻辑主语必须与句子语法主语一致。
• 语气须契合场景：博客宜轻松，文档求精准，UI 文本讲直接。

自检清单（Self-Check）

1. 逐句朗读。若听感类似新闻稿、维基百科或聊天机器人，请重写。
2. 用 phrases.md 中条目对文本执行 grep；结果必须为零匹配。
3. 检查虚假主体：是否存在无生命对象执行人类动词？请点明人物。
4. 检查 em dash、机械式加粗、同义词轮换现象。
5. 剔除“可摘录金句”：若某句读起来像引述语或格言警句，请重写。

更新日志语气（Changelog Voice）

• 销售测试（Sell test）：每条更新均需通过“用户读到后是否会想‘我想试试这个’？”检验。优先说明用户现在能做什么，而非实现细节。“You can now filter by date range” 优于 “Refactored the query builder to support date predicates”
• 面向用户 vs 内部变更：内部改动（重构、依赖升级、CI 修复）应单独归入“For contributors”子章节，不得与面向用户的条目混排
• 动词时态：描述已发生变更用过去式（“Added”、“Fixed”），不用现在式（“Adds”、“Fixes”）

PR / MR 描述规范

描述长度须匹配变更复杂度（微小变更一句足矣，架构级变更需完整叙事）。开篇阐明 Before / After / Scope rationale；聚焦净终态（net end state），而非迭代路径；拓扑图选用 Mermaid，表格数据用表格呈现。详见 references/pr-descriptions.md 中的尺寸矩阵、叙事框架、GitHub 风险提示（#NN 自动链接陷阱）及自检清单。

README 规则

README 是区别于博客、社交帖文及 PR 描述的独立界面。通用反 AI 特征规则在此适用，但以下条款除外：

• em dash 关卡：grep -c "—" README.md 提交前必须返回 0。替换规则依上下文而定：Term — explanation → **Term**: explanation；name — qualifier → name (qualifier)；句中中断 → 拆为两句或改用分号 ;；- foo — bar → - **foo**: bar；Section — note → Section: note。
• emoji 标题属 README 常规用法：## 🚀 Features、## 📦 Installation 在开源社区中被视为惯例，而非 AI 风格；社交帖文中的 emoji 禁令不适用于此处。每标题最多一个 emoji，且不可内嵌于正文。
• 星标链接用纯文本，非 Markdown URL：If this saves you a debugging cycle, ⭐ star it! 读来是真人请求；[⭐ Star on GitHub](https://...) 则显营销腔。
• 重写时采用混合合并策略：改写现有 README 时，对各节分类处理：PRESERVE（技术准确性、版本锁定、安装命令、可运行代码块）；ADD（缺失背景）；REJECT（AI 套话、营销口吻、填充内容）；FIX（错误主张、过期版本、失效链接）。切忌全盘替换：既有技术内容通常正确，问题仅在于语气。
• 自检以章节为单位，而非段落：每个 H2 级别章节承担单一职责，自身即为独立审核单元；一个打磨精良的章节紧邻一个浮夸章节，其整体效果劣于统一平实的版本。

参考 references/examples.md 查看改写前后对照示例。