name: shuorenhua description: 检查和清理中英文文本里的 AI 套路，适用于“去 AI 味”“说人话”“自然一点”“别像模板”“先标问题”这类改写和审稿需求；按场景控制力度，同时保留事实、术语、语域和责任主体。

说人话

把文本从”像模型在表演写作”拉回”像具体人在当前场景下表达”。

这份 skill 不是敏感词替换器，也不是反技术、反抽象、反专业。它的目标是减少模板感、表演感和语域漂移，同时保住事实、术语和责任主体。

When to use

在下面这些需求里使用：

• 用户明确说”去 AI 味””说人话””自然一点””别像模板””别太像 ChatGPT”
• 需要改写中文或英文 chat、status、docs、public-writing
• 需要先判断文本该轻改、中改还是重改

在下面这些需求里不要硬套：

• 用户要逐字翻译、保留原文风格、仿官方模板或仿特定品牌 voice
• 文本主要是代码、日志、命令、配置、接口名、报错
• 用户要的是事实校对，不是风格改写

Core stance

• 去 AI 味，主要处理的是模板感、收束腔、虚假主语、语域混搭和表演性技术腔。
• 保留技术性。专业词、系统主语、事故复盘用语、PRD/发布说明中的术语默认可保留。
• 优先保信息，再谈风格。任何改写都不能新增事实、删核心事实或改变责任主体。
• 不用机械同义词替换表。默认可以删句、并句、降调、换主语、去总结式收尾；如果进入 in-place scope，就只做句内改写。
• 短语表默认只列代表项，不追求穷举所有变体。遇到新口癖，先按现有模式归类，再决定要不要补词。

Execution order

按固定顺序做，不要跳步：

1. 判场景：chat / status / docs / public-writing
2. 查禁改项：先划 protected spans，看有没有必须保留的术语、系统主语、引用原文、命令或正式语体
3. 判 Tier：Tier 1 / Tier 2 / Tier 3，按问题命中强度判断，不要把 Tier 当作改写力度
4. 再判档位：minimal / standard / aggressive
5. 判 scope：structural / bounded / in-place，判断这次能删到什么程度——自由删并重排、只把整句空话进删除清单、还是一句都不删
6. 先执行本文件里的最小规则；只要环境里能读 references/，默认继续按问题类型补看 Protected Spans、Positive Style Contract、微操作手册、结构反模式 和相关短语表；如果目标是“改完能直接发”，或文本明显属于 README、release note、论坛帖、issue 回复，再补看 Scene Packs、真实样本评测 和 改写示例
7. 回读拆成两步：先做保真回读，再按需做残留味回读
8. 输出：默认只给单一推荐版本；用户明确要求“先标问题，不改写”时切到 annotation mode

执行第 6 步时，先按“模式”处理，再按“词条”兜底：

• 同一类调试腔、暴力动作腔、主动出击腔、总结提示腔，默认按同一模式处理，不要求逐词命中
• 只有当新说法改变了误杀边界，或明显不属于现有模式时，才把它当作新增词条处理

1. Scene detection

先判主场景，再处理局部问题。混合文本只保留一个主语域，其他语域只在必要信息层面留下。

chat

信号：

• 短回复、日常对话、协作沟通、评论、即时反馈
• 允许口语，但不该端着说话

默认档位：minimal

status

信号：

• 站会更新、进度同步、复盘摘要、汇报式状态说明
• 重点是时间线、动作、结果、风险

默认档位：minimal 或 standard

docs

信号：

• 操作文档、技术说明、接口说明、FAQ、事故复盘
• 重点是可检索、可复现、术语稳定

默认档位：minimal

public-writing

信号：

• 公众号、小红书、公开帖、对外文章、观点写作
• 重点是语域一致，不要装“有洞见”

默认档位：standard

更细的下限限制见 场景禁改表。

Scene Packs

如果文本本身命中下面任一子场景，不依赖用户是否明说，也不受主场景初判限制，都要补看 Scene Packs：

• README：出现项目介绍、快速开始、安装方式、功能列表、README intro 等信号时，第一屏要说清“这是什么、给谁用、解决什么问题”
• release-note：出现版本标题、Release Highlights、Added / Changed / Fixed / Tested、changelog 列表等信号时，列清本版变更、验证和限制，不写发布宣言
• forum-post：出现 Linux.do / V2EX / 社区帖 / 发帖复盘等信号时，保留维护者的真实观察和社区语气，不改成公告
• issue-reply：出现 issue / PR 回复、bad case、复现、下一版补 benchmark 等信号时，先确认问题和下一步，不做客服式安抚

子场景只负责发布目的和语气收束，不覆盖 protected spans、Tier、档位和回读规则。完整策略见 Scene Packs。

2. Single-file fallback rules

只加载 SKILL.md 时，也必须能完成基础改写。下面这些规则默认直接生效：

• 删开场套话、谄媚和元评论：例如 值得注意的是、让我来为你解释、希望这对你有帮助、Great question!
• 删空总结和收尾腔：例如 综上所述、归根结底、本质上、At the end of the day
• 处理二元对比骨架：不是 X，而是 Y、与其 X，不如 Y 多数删前半句，直接说 Y
• 处理无源引用：研究表明、数据显示、studies show、experts say 默认按场景选择 rewrite-safe 或 audit-only；只有用户明确要保留原论证骨架时才用 rewrite-with-placeholder；不要补虚构来源
• 把商业黑话和表演性技术腔改回普通动作：例如 赋能、抓手、闭环、收窄、兜住、落盘、leverage
• 遇到过度接住、替用户做心理判断或身份认证式夸奖：例如 你不是敏感、你只是太久没被稳稳接住了、你问到了问题的核心、顶刊作者的素养，默认删姿态层，改回低承诺回应或具体判断；不要硬演“我懂了”
• 发现翻译腔时，优先缩短主语和动作，少用长定语链、被动堆砌、基于……、通过……来……
• 误杀防护优先：引用原文、命令、接口名、字段名、日志、报错、系统主语、技术报告术语默认保留
• 中英混排句中的英文词按当前句子的实际语义判断，不机械套英文词表

单文件模式只是兜底，不是完整模式。只要环境里能读 references/，默认就继续补看对应文件；只有在 system prompt 真的只给了 SKILL.md 时，才退化为只按本文件做基础清理。

Unsourced citation modes

处理无源引用时，固定只在这 3 种模式里选一种：

• rewrite-safe
  • 直接删掉 研究表明 / studies show / 业内人士认为 这类权威铺垫
  • 只保留原文里本来就成立、且不依赖虚构来源才能成立的判断
  • 默认用于 chat 和 public-writing
• audit-only
  • 不替作者补写来源，也不把无证据判断改写成像是已有证据
  • 明确指出“这里缺来源/缺归属”，必要时保留原句不重写
  • 默认用于 docs 和 status
• rewrite-with-placeholder
  • 只在用户明确要求保留原结构、原语气或编辑稿框架时使用
  • 可以写成“有研究认为……，但这里没有给出处”这类占位提醒
  • 不能补具体机构、数据、年份、研究名称

如果用户没指定模式，就按场景默认值走；如果文本跨场景，优先取更保守的 audit-only。

3. Rewrite level

minimal

适用于：文本本身基本自然，只需去掉局部模板感、收尾腔和多余修辞。

默认动作：

• 删掉空总结
• 把过度抬高的语气压回常规
• 把"像在解释自己会写作"的句子压回事实句

standard

适用于：有明显 AI 腔或语域混搭，但信息骨架是好的。

默认动作：

• 统一语域
• 改掉工程师表演腔、商业黑话、narrator 腔
• 必要时并句或换主语

aggressive

适用于：Tier 1 命中密集，或 Tier 1 + Tier 2 叠加后整段呈现强模板感或强表演感。

限制：

• 只有在 Tier 1 明显密集，或多类结构问题叠加时才允许
• 先保护事实和术语，再做重写
• docs 默认不要升到 aggressive

3.5 Edit scope

Scope 表示这次能不能改动句子和段落结构，和 minimal / standard / aggressive 是两条轴。三档 scope 按"能不能删整句、怎么删"区分：structural 自由删并重排；bounded 只删"删了不丢信息"的整句空话，且走删除清单交用户确认；in-place 一句都不删。

structural

默认 scope。适用于短文本、明确要求重写的文本、AI 味密度很高且不需要保留原节奏的文本。

允许动作：

• 删整句空总结
• 合并相邻事实句
• 轻量调整句序或段落落点
• 按场景重写局部结构

bounded

中文 public-writing 长文（约 1000 字以上）的默认 scope。目标是把整句级的 AI 味去干净，又不被 structural 不可控地压缩——长文走 structural 时缩水程度依模型而定（同一篇可能 -18%，也可能 -39%），用户无法预期；bounded 把"删多少"交还给用户。

和另两档的关系：

• 比 structural 克制：不合并相邻句、不重排段落、不删承担节奏的实句或有意重复
• 比 in-place 能去味：允许删"整句都是空话"的句子，但不直接删，而是进删除清单交用户拍板

一句能进删除清单，必须同时满足三条：

1. 删掉后该段信息点不变（不带任何独有的事实、数字、判断、动作或指令）
2. 不是相邻两实句之间的唯一过渡
3. 命中纯空句型：空总结 / 价值拔高收尾 / 无源权威铺垫 / 谄媚开场 / 整句旁白

两类动作分开走（实测依据：长文里句首引导词模型能句内清掉，但整句空话在 in-place 下删不掉，只会被软化成另一种说法）：

• 句首可剥离的引导词（值得一提的是 / 归根到底 / 这说明）后面还跟着实质内容 → 直接句内洗，删引导词留骨架，不进清单
• 整句都是空的，剥掉引导词就什么都不剩（无源论断、不仅仅是……更是…… 的价值拔高）→ 进删除清单，不擅自软化成另一种说法

输出：正文给句内洗后的稿，末尾附「建议删除（待确认）」清单，每条写 原文 + 为什么删了不丢信息。用户点头才删，长度由用户拍板。

in-place

适用于用户明确要求"完全原样 / 一句都别删 / 严格保句数"的情况，比 bounded 更严：整句空话也不删，只做句内降调。

默认触发条件：

• 用户 prompt 明确要求保留句数、完全原样、一句不删，或反馈 bounded 仍删多了

禁止动作：

• 不删整句（即使整句是空话）
• 不合并相邻句
• 不重排段落
• 不把多段压成一段

允许动作：

• 句内替换词或短语
• 删除句内提示层、空泛修饰和语气垫片
• 把句内拔高语气降回普通判断
• 在单句内部拆短过满结构，但不改变段落顺序

删短语前先做语义独立性检查：删掉短语后，剩余部分必须仍是完整、可读、没有悬空指代的陈述句。否则改用句内替换，不要硬删。遇到整句空话，保留原句并标注 [空句，建议人工确认是否删除]，不擅自软化成新说法。

aggressive + in-place 可以存在，但默认先提醒用户：长文 aggressive 很容易明显缩水；如果用户真正要保长度，优先改成 standard + bounded。用户明确坚持时，再执行 aggressive + in-place，但仍遵守不删整句、不并句、不重排的边界。

4. Tier severity

Tier 表示问题命中强度，与 严重度分级 保持一致，不表示改写力度。

Tier 1

默认替换。命中这类词或句式时，通常直接删掉或换成更具体的表达。常见类型：

• 开场套话、总结式收尾、谄媚句
• 明显商业黑话、自媒体流水线用语、表演性工程师腔
• 过度接住式共情、替用户做心理判断、郑重预告和身份认证式夸奖
• 英文里的 sycophantic openers、significance inflation、business jargon

默认处理：局部命中用 minimal 或 standard，密集命中时可升到 aggressive

Tier 2

单独出现可以放行，但同段聚集时是 AI 味信号。常见类型：

• 高频连接词扎堆
• 渲染性修饰词扎堆
• 某一类姿态词在同段重复出现

长度参考：短段落（< 100 字/词）同段 2+ 个即标记；长段落（≥ 100 字/词）同段 3+ 个再标记。

默认处理：保留最贴切的一个，其余改写；通常用 minimal 或 standard

Tier 3

常见词本身不构成问题，只在全文密度明显过高时才处理。常见类型：

• 重要 / 关键 / 核心 / 提升
• significant / innovative / effective

默认处理：只替换一部分重复命中，通常用 minimal，必要时不改

5. No-touch and keep rules

以下内容默认优先保留，除非用户明确要求改风格且改动不损害信息：

• 引用原文、命令、接口名、参数名、字段名、配置项、日志、报错
• 技术文档里的系统行为主语
• postmortem / incident / PRD / release note 中的专业术语
• 承载关键事实的抽象句，即使它“有点像 AI”

不要为了“像人”把文本改得更假。专业文本可以专业，关键是别模板化、别表演化。

完整的保护清单见 Protected Spans。

6. Positive style targets

改写后的文本应尽量满足：

• 有具体信息，不靠空洞总括撑气势
• 有主语和动作，不靠虚假主体兜底
• 有统一语域，不在技术腔、商业腔、自媒体腔之间跳
• 以“可直接发”为终点，不为了更像人继续抛光到失真
• 有节奏，但节奏来自删冗余和保留重点，不来自硬造金句
• 有立场，但立场来自判断或事实，不来自“故作洞见”
• 有边界，没把握就直说，不替对方做心理判断，也不硬演“我懂了”

更完整的正向目标、分场景校准和“cleaner vs more human”对照见 Positive Style Contract。

7. Output contract

默认输出一个推荐版本，不默认输出审稿过程、多版本比稿或逐条点评。

Annotation mode

只有在用户明确要求下面这类事情时才启用：

• 先别改，先标问题
• 这段哪里像 AI
• 只做诊断 / 审稿 / 标注
• 先告诉我该不该改

annotation mode 不直接给整段改写稿，默认只输出最重要的 1-5 个问题点。每个问题点固定包含这 4 个字段：

• 问题族：例如 开场套话 / 无源引用 / 工程师腔 / 语域混搭
• 触发点：点明命中的词、结构或局部句子
• 建议动作：删掉、换成具体表达、补来源、保持不动
• 是否建议改写：是 / 否

额外约束：

• 如果文本主要问题是“缺来源”，可以只建议补来源，不强行给改写稿
• 如果文本落在误杀防护边界内，直接写 是否建议改写：否
• 不要一边说“只标问题”，一边偷偷输出完整重写版
• 用户没要求 annotation mode 时，仍然按默认改写合同输出单一推荐版本

遇到无源引用时，输出必须符合所选模式：

• 在 annotation mode 下，只输出对应的处理建议，不直接给整段改写稿
• 在默认改写模式下，再按所选模式实际给出改写结果
• rewrite-safe：建议删掉无证据权威铺垫；如果不是 annotation mode，再给改写结果，不补虚构来源
• audit-only：优先点明缺来源、缺归属，而不是假装已经证实
• rewrite-with-placeholder：允许保留论证位置，但要显式暴露“此处待补来源”；如果不是 annotation mode，可以给带占位提示的改写结果

只有在高风险误杀时，才额外补一行极短说明，例如：

• 保留了系统主语和术语，避免失真。
• 这里只做轻改，避免把正式公告写成口语贴。

8. Required reread checks

提交改写前，把回读固定拆成两步，不要混着做：

Pass 1 | 保真回读

先检查这 5 项：

1. protected spans 是否漂了
2. 信息是否丢失
3. 语域是否统一
4. 术语是否失真
5. 删改后是否出现生硬断裂

如果删掉一句后段落突然没了落点，就补一条事实句，不要补口号句。

bounded / in-place scope 下额外检查：

• 信息留存优先：原文每个信息点（事实、数字、判断、动作）在输出里都要可追溯，这是硬指标
• in-place：输出字数低于原文 85% 时，回退检查是否误删整句、并句或压段落（in-place 不该删任何整句）
• bounded：字数会因删整句空话而下降，不设硬下限；但要确认删除清单里每条都是"删了不丢信息"的纯空句，没混进实句或承担节奏的重复
• 句数变化超过约 10% 时，回退检查是否偷偷做了未经确认的 structural 改写
• 关键事实句、转场句和承担节奏的重复句，不能因为“看起来像模板”就默认删除

Pass 2 | Residual Audit

只有在第一遍已经保住事实、但读起来还有轻微 AI 味时，才做第二遍。第二遍固定只查这 5 件事：

1. 开场残留：还在用 结论先说 / 直接说结论 / 值得注意的是 这类提示层
2. 总结残留：还在用 总的来说 / 归根结底 / 最终来看 这类空收尾
3. narrator 残留：还在解释“这说明了什么”，而不是直接说事实或判断
4. 空泛判断残留：还在写 方向是对的 / 意义重大 / 真正理解了用户
5. 句长过匀：每句都差不多长、差不多整齐，像被统一抛光过

第二遍只允许做轻量修正：

• 删一个残留开场或收尾
• 合并两句过匀的事实句，或拆一处过满的句子
• 把一句 narrator / 空泛判断压回直接表达

第二遍不要做的事：

• 不重写全文
• 不补原文没有的事实
• 不为了“更像人”改掉术语、参数、命令、报错或责任归属

场景保守策略：

• public-writing 和 AI 味偏重的 chat，第二遍更常需要
• docs / status / code-context 默认更保守；如果第二遍会让语气变口语、变广告、或影响保真，就停在第一遍

Reference navigation

• 本文件可以单独兜底；完整模式默认是 SKILL.md + references/ 一起工作
• 想先看“改成什么样才算更像人”：看 Positive Style Contract
• 想先看哪些数字、引用、命令、参数不能漂：看 Protected Spans
• 想看中文高频短语：看 中文禁用短语表
• 想看英文高频短语：看 English Banned Phrases
• 想看句子和段落层面的结构问题：看 结构反模式
• 想按 Tier 1 / 2 / 3 校准命中规则：看 严重度分级
• 遇到具体病灶怎么动手：看 微操作手册
• 想确认某个场景什么不能乱动：看 场景禁改表
• 想校准误杀边界或做静态回归：看 边界案例集
• 想看真实样本评测：看 真实样本评测
• 想看默认改写和 annotation mode 的对照：看 改写示例
• 想处理没收录进词表的同类变体：先看 微操作手册 里的“变体归并”规则，再决定要不要补词

默认做法是：先用本文件完成“场景、Tier、档位、输出合同”的主判断，再按问题类型补读 references/；只有在单文件安装场景里，才停留在本文件的兜底规则。

说人话 专治那种“每个字都对，但一看就不是你写的”中文。它不把空话包装得更漂亮，也不替你编新事实；它先护住版本、命令、责任和证据，再拆掉过度承接、工程师腔、小红书 AI 腔、翻译腔和无源权威铺垫。目标很简单：改完你敢直接发。

它适合这些场景：

英文去 AI 味已经有 stop-slop 和 humanizer。说人话 补的是中文这一层：互联网黑话、工程师腔、小红书 AI 腔、翻译腔、语域混搭、场景分档和事实保真。

改成什么样

接住体，先颁奖再共情

改写前

你不是敏感，你只是太久没被稳稳接住了。你问到了问题的核心。这次我懂了，我真的懂了。我必须很认真地说一句：你这种观察力和表达方式，绝对是顶刊作者的素养。

改写后

我在听。你要是愿意，可以继续说。

问题不在某个单词，而在整套姿态链：先替对方做心理判断，再表演共情，最后给对方颁奖。完整样本见 evals/real-samples.md RS-13。

工程师腔溢出到生活

改写前

先说结论：吃日料。我把你最近三周的外卖记录过了一遍，已经把差异收窄到两个选项，根因基本坐实是你上周说过腻了火锅。要不要我顺手帮你把 X 店的外卖也下了？你一回复我就上手。

改写后

吃日料吧，上周你说火锅腻了。要帮你下单吗？

这类文本的问题是把 debug 口吻带进生活对话。信息可以保留，工程报告感不需要保留。

公开介绍的宏大开场

改写前

在当今快速发展的人工智能时代，如何打造一个真正赋能开发者的工具，已经成为业界不容忽视的关键议题。

改写后

AI 工具很多，真正能帮开发者把活做快、做稳的并不多。这个项目做的，就是把模型写出来的套话和表演感压下去，让结果更像人写的。

更多例子见 references/examples.md 和 evals/real-samples.md。

30 秒上手

Codex — clone 后单次使用：

git clone https://github.com/MrGeDiao/shuorenhua.git && cd shuorenhua
codex exec -C . "读取 ./SKILL.md，按其中规则改写以下文本：……"

Claude Code — 放进 skills 目录，之后自动触发：

git clone https://github.com/MrGeDiao/shuorenhua.git
mkdir -p ~/.claude/skills
cp -r shuorenhua ~/.claude/skills/shuorenhua

装好后在对话里说「把这段去 AI 味」就会命中。想跟随仓库更新，用软链接代替 cp，见 install/claude-code.md。

ChatGPT — 什么都不用装：说人话 GPT（需 Plus / Pro），完整规则已内置。

只想先看问题、不要改稿：指令里加一句「按 annotation mode 只标注不改写」。

Cursor、OpenClaw 和自建 agent 见安装。

它怎么判断怎么改

说人话 不是见词就替换。一句话原则：

先保信息，再谈风格。

完整流程固定六步：

1. 判场景：chat / status / docs / public-writing；命中 README、release note、论坛帖、issue 回复时，再进对应的 Scene Pack
2. 划保护片段：数字、版本、命令、路径、报错、引用原文先锁住
3. 按命中强度定力度（minimal / standard / aggressive），按能删到什么程度定 scope（structural / bounded / in-place）
4. 先按模式改，词表只兜底
5. 保真回读：事实、术语、语域、保护片段逐项过
6. 仍有残味才做第二遍 Residual Audit，只允许轻量修正

场景与力度

四个场景的默认力度：

按发布目的细分（Scene Packs）

可发布文本再按「发到哪里」细分，不是换语气，是按发布目的决定改法：

长文不缩水：三档 scope

长文按默认动作改写，删句、并句会叠加，1800 字可能被压到 1000 字；反过来一句不删，整句的空话又留在文里。所以长文把「删到什么程度」单独分成三档，和力度档位正交：

长文按默认 structural 动作改写时，删句、并句、重排段落容易叠加，一篇 1800 字的稿子可能被压到 1000 字（见 #4）。但反过来只做句内改写（in-place），整句级的空话（无源引用、价值拔高收尾）又删不掉、去味偏弱——v1.8.6 用真实模型实跑验证了这一点：两个模型在 in-place 下都把无源引用和拔高收尾整句留了下来。

bounded 的取舍：句内洗实句直接改、承担节奏的重复不动；整句都是空话的（剥掉引导词就什么都不剩）进「建议删除（待确认）」清单，删多少由用户拍板。这样既不像 structural 那样不可控地缩水，也不像 in-place 那样把整句空话留在文里。

哪些内容永远优先保护

这些内容默认优先保护：

改完往哪个方向靠

清理不是只删词。它也会把文本往这些方向拉：

• 具体动作优先于抽象拔高
• 真主语和真动作优先于姿态层
• 允许轻微不对称，不把每句都抛光成同一种腔
• 按场景校准，不把聊天改成公告，也不把文档改成段子

评测

规则层覆盖 210+ 中文短语、96 条英文短语、19 类结构反模式。

当前评测集共 73 条：

v1.9.0 起 benchmark 改为双模型实跑口径（Codex + Claude 交叉判分，见 evals/results-v1.9.0.md）；静态走查退为发版前快速自查。完整用例集见 evals/benchmark.md，整段真实样本见 evals/real-samples.md。results-v1.8.6.md 保留为 v1.8.6 首次模型实跑归档。

安装

核心只需要 SKILL.md 一个文件（lite）；长期项目、公开文本和需要误杀防护的场景，建议带上 references/ 完整包（full）。

项目内长期使用时，可以在 AGENTS.md 加一段触发规则：

## 写作风格
当任务涉及“去 AI 味”“说人话”“自然一点”“别像模板”这类改写时，遵循 `shuorenhua/SKILL.md`。
对外文本优先按它处理；代码、日志、配置和命令输出不套这个 skill。

常见问题

这是不是拿来骗 AI 检测器的？

不是。目标是减少模板感、表演感和语域漂移，让文本更自然、更可发布，不是绕过检测。

英文能不能用？

可以，但这是一个中文优先项目。英文支持主要用于清理常见英文套话和中英混写里的模板感。

为什么改完有时还是有 AI 味？

“去掉明显套路”不等于“拥有具体作者的个人表达”。当前版本更擅长清理模板感和表演感，还不负责拟合某个具体人的长期写作习惯。

会不会把技术文档改坏？

正常不会按聊天口吻去改技术文档。docs、status、code-context 都有更保守的保护策略，命令、路径、版本、报错和指标优先保真。

贡献：bad case 比 star 有用

欢迎提交新的评测样本、边界案例、真实问题案例、改写前后样本和误杀防护。

如果你遇到“改完还是像 AI”的具体文本，可以用 bad case 模板 提交。请先脱敏，不要贴未授权私聊全文、密钥、内部链接或真实个人身份信息。也可以直接贴到征集 issue。

在提交新词之前，先想一件事：

这是一个“新模式”，还是只是“现有模式的变体”？

详细规则见 CONTRIBUTING.md。

相关项目

• stop-slop：英文 AI slop 规则和评分框架
• humanizer：英文 AI 模式分类
• avoid-ai-writing：AI 写作问题分类和严重度参考

Star History

许可

MIT