anti-ai-prose

Anti-AI-Prose：审查并修正机器生成文本的痕迹

识别并修正那些让英文读起来像机器生成的语言特征。目标是让文字读起来像出自某个具体、周到的人之手。

此技能适用于任何文本：文档、README、Wiki（Confluence、Notion、内部 Wiki）、拉取请求描述、提交消息、发行说明、博客文章、电子邮件、幻灯片文案、创意写作以及代码注释／文档字符串。词汇、句法、语气和格式检查针对的是语言领域，而非平台领域。

部分内容取自 Wikipedia：AI 写作的迹象——这是一份由阅读过海量大模型生成文本、了解其实际特征的编辑编写的实用指南——以及 stop-slop（MIT），后者贡献了自信式填充内容检查：强调性依赖、修辞铺垫和假深刻的片段；还取自 poteto/plugins pstack/skills/unslop（MIT），后者贡献了通俗表达检查、抽象隐喻名词列表、聊天痕迹以及恢复声音风格的指导。

适用场景

• 审查读起来像机器写的 README、文档页面或 Wiki 文章，或在发布前检查 PR 正文、提交消息或发行说明草稿
• 润色借助大模型起草的博客文章、电子邮件、脚本或创意写作，或检查文档字符串和代码注释中的相同模式
• 有人说“这听起来像是 ChatGPT 写的”，或在大量借助大模型起草内容后进行自查
• 写作时过滤自己的回复、解释和草稿（行内模式，见下文）

不适用场景

• 代码质量、过度抽象、依赖膨胀、过时习惯用法——使用 code-simplification
• 功能变更、API 重命名或配置更新后文档与实际情况不符——使用 update-docs
• 根据粗略笔记生成或重组提示词——使用 prompt-generator
• 正确性缺陷、逻辑错误、边界情况——使用 code-review
• 审查身份验证、机密或攻击面方面的安全问题——使用 security-audit；如需对代码库进行全方位审查，则使用 repo-audit

---

两种模式

此技能有两种模式。根据触发方式选择模式，而非根据内容选择。

行内模式（默认）

适用于你自己的对话输出：聊天回复、解释、摘要、提交正文、PR 描述，以及你为用户起草的任何文本。只要此技能处于上下文中，就对每条回复应用，无需再次询问。它无法清理加载前已起草的回复，因此在文本质量很重要时应尽早加载。

• 写作时默默应用模式规则。这会过滤起草内容，而不是审查完成的草稿。
• 不输出报告、发现项、严重性评级或交付文件，也不提及已运行此技能。
• 引用用户原话时，不要重组用户的文字。
• 不适用密度阈值。修正你在自己输出中发现的每一处痕迹。
• 发送前，先问自己：“这条回复中有哪些地方读起来像机器生成的？”修正由此发现的问题。

审查模式（显式）

适用于用户交来的文本：文件、粘贴内容、差异或目录。由明确请求触发（“审查这个”“这听起来像 AI 写的吗”“把这份文档里的机器腔改掉”），或由针对某个目标调用此技能触发。运行下文的完整工作流程，输出完整的结果，并应用密度阈值，以免标记长文档中孤立出现的情况。

优先级

规则冲突时，后面的条目优先级较低：（1）用户在本次对话中的明确指示；（2）项目指令文件（CLAUDE.md、AGENTS.md、仓库风格指南）；（3）所写文本的体裁惯例；（4）本技能的模式规则。要求使用破折号、标题采用首字母大写格式或使用正式语体的内部风格规范，不属于问题。行内模式应适应这些规范，而不是凌驾于其上。

---

AI 自检

无论使用哪种模式，都必须做到：

• 正确选择模式：行内模式不输出报告、问题列表或交付文件；审查模式输出完整约定。不得在同一回复中混用两种模式
• 清除聊天套话：输出中不得残留 Great question!、I hope this helps!、Certainly! 或截断免责声明，无论使用哪种模式

仅限审查模式：

• 说明问题对读者的影响：每条发现都要指出清晰度降低、缺乏依据的说法，或与受众及体裁不符之处。仅凭风格模式不足以判定作者身份
• 尊重语境：不得将体裁惯例（学术、新闻、营销、旅游）和领域术语标记为问题——例如五金铰链中的 pivotal、园艺中的 landscape、儿童福利中的 foster、Kerberos 中的 realm
• 保留直接引语：不得编辑其他作者的引文，即使其中包含禁用词汇
• 代码不动，审查文字：不得因标识符、字符串字面量和 API 名称中含有禁用词而标记它们。注释和文档字符串中的文字属于有效审查对象；其周围代码不属于
• 扫描全部四个类别，包括容易漏掉的检查项：副词堆叠、过度自信的填充语、通俗表达检查集（分词尾缀、虚假范围、未指明行为者的被动语态、句子密集堆叠、以感受代替机制），以及角色名称清晰度
• 确认对读者的影响：问题密度有助于优先处理已确认的清晰度问题；字数或词汇匹配本身不能决定严重程度
• 严重程度判断准确：不得为了充实报告而将 P3 夸大为 P2，也不得凑数增加问题
• 改写确有改善：每个“改写后”版本都应比“改写前”更简洁、更清晰或更具体，表达立场并提供具体信息，且不得杜撰源文中没有的事实。不得只做同义词替换；语气建议应标为 Consider，而非 Fix
• 保持受众定位：编辑应保留作者的领域词汇、意图和必要的正式程度
• 遵守内部风格规范：用户的明确指示和项目指令文件优先于本技能的模式规则；不得将强制使用破折号或标题首字母大写格式的规范报告为问题
• 审查输出本身不含 AI 写作痕迹（这些规则也适用于你自己的输出）
• 应用跨领域 Agent 规范——参见 references/agent-hygiene.md

---

执行要求

• 标记问题前，先通读全文——密度按每 500 个单词的比例计算，抽样无法得出该比例。抽样用于判断某个目录是否值得审查，而不是评定文档得分。
• 按模式归纳重复问题，避免在每段都留下近乎重复的评论；优先处理可见度高的文本：标题、摘要、引言、结论和面向用户的文档。

最佳实践

• 标记具体短语和结构模式，不凭感觉判断。
• 修复方式明确时，提供替换文案；否则说明问题，让作者自行决定。
• 不要为了让文字听起来更随意而删去必要的限定语、合规用语或领域特定精确表述。

工作流

仅审计模式。完整详情见 references/audit-mode.md：范围界定规则、文本类型列表、密度启发式、操作和严重程度等级，以及附有示例的报告模板。

1. 确定范围。 审计指定的文件或粘贴的内容。如果未指定目标，则依次检查未提交的文档更改、已更改文件中的文档字符串，然后询问。
2. 识别文本类型。 技术文档、README/PR/提交信息、营销文案、小说、wiki、电子邮件和幻灯片各有不同惯例，判断哪些特征值得标记时需考虑这些差异。
3. 扫描。 按照以下四个类别进行检查。标记前先阅读上下文：5000 字中出现 1 个 AI 用词只是噪声，3 段中出现 3 个则是模式。密度有助于确定已确认问题的优先级；不足 100 字且有 2 个或更多实质性问题的文本可能应列为 P1。有些检查不考虑密度，因为单个实例本身就是问题：旅游指南式语气、宣传口吻、公式化文章结构和聊天痕迹。仅出现角色姓名不算问题。信任违规也不考虑密度；对于准备发布的文本，这类问题列为 P0——虚构引用、编造事实、泄露秘密、生成器残留，或署名为人类作者却带有免责声明截断痕迹。 权威的启用/未启用检查项列表见 references/audit-mode.md。
4. 报告并修复。 按类别分组，给出具体改写，并确保每处改写都比原文更简短或更具体。应用获准的修复，并记录影响同一范围的新发现问题。只有在修复会改变作者意图或扩大获准工作范围时才询问；常规发现无需单独审计。返回前，依据 AI 自检清单检查报告；修复任何未通过的项目，然后再次检查。

---

AI 腔废话的四个类别

1. 词汇特征

大模型使用频率远高于自然英语频率的特定词语。

标记词汇（需结合上下文判断，例外情况见下文）：

按修改方式分组。（或删去）标记通常是填充内容的词语，此时应删除整段短语，而不是替换词语。

改用“use”： leverage、utilize -> use。facilitate -> help、enable。

改用普通动词： delve / dive deep into -> look at、examine、dig into、cover。showcase -> show、display、feature。navigate -> handle、work through、manage。garner -> get、earn、attract。 underscore -> show、highlight、confirm。enhance -> improve、speed up、extend（或直接说明改进之处）。 ensure -> make sure、guarantee（或直接说明具体机制）。empower -> help、enable、let。 foster -> build、grow、support、encourage。boast -> has。commence / embark on -> start、begin。

改用普通名词： realm -> area、field、world。landscape -> scene、field、mix。tapestry -> mix、range、variety（或删去这个比喻）。testament -> proof、evidence、example。interplay -> how X and Y interact（或删去）。synergy -> fit、overlap、how X and Y work together（或删去）。

改用更朴素的形容词： enduring -> lasting、long-running。numerous -> many。nestled -> set、located、built。innovative -> new、novel（或直接说明新在哪里）。

填充性形容词，默认均标记为（或删去）——只有在形容词确实发挥作用时才替换：pivotal / crucial -> key、important、central、needed。nuanced -> subtle、careful、specific。intricate -> detailed、complex。multifaceted -> has many sides、covers a lot。holistic -> whole、end-to-end、full。seamless -> smooth。robust -> reliable、solid。vibrant -> lively、active、busy。

填充性短语，规则相同：commitment to -> cares about、focuses on。journey toward -> work toward、move toward、aim for。moving forward -> from now on、next。additionally -> also、 and（或直接以具体内容开头）。

检测：

• 同一段落中出现多个标记词
• 标记词被用作比喻（tapestry of experiences、realm of possibility）
• 在普通动词也适用的语境中使用标记词（showcase the features -> show the features）

**修改：**替换成普通表达。如果替换后句子显得更无力，说明原词只是填充内容——删去整个短语。

人物姓名（虚构作品）

评估姓名是否符合故事背景，以及是否有助于读者区分人物。常见的姓名或读音模式并不能证明作品文笔不佳或由 AI 创作。有关背景和连续性的检查，请参见 references/fiction-tells.md。

抽象隐喻名词

读起来像技术术语、实际却代指更普通词语的名词（substrate、vector、 paradigm）。应明确说出具体事物。列表、检测测试和术语例外情况见： references/plain-speech.md 第 1 节。

2. 句法特征

大模型常用来营造均衡感或强调重要性的句式结构。

否定式排比

not X but Y 和 not just X, but also Y，用于营造均衡感。适度使用属于自然英语，但大量出现则是明显特征。

**检测：**一篇文章中出现三个或更多 not X but Y / it's not about X, it's about Y 结构，或在直接陈述也适用的地方使用其中一种：this isn't just a tool, it's a platform -> this is a platform。

**修改：**直接陈述肯定内容。如果对比关系很重要，可保留一处，其余改写。

生硬的三项并列（三段式）

X, Y, and Z 这类列表只是为了节奏，而非列举具体项目。大模型默认列出三项，即使两项或四项更准确也不例外。

检测：

• 三个形容词中只有一个真正承载含义（a fast, reliable, and scalable system），或三个名词实际上指同一概念（clarity, precision, and accuracy）
• 为了凑够三项，第三项明显多余的三项列表

**修改：**删去最弱的一项。表达对比时用两项；确属实际列表时用四项或更多。

系词回避

LLM 会避免直接使用 is / are / has / have，转而采用复杂表达：serves as、marks、represents、features、offers、boasts、stands as。

检测：it serves as a backup -> it is a backup。this represents a shift -> this is a shift。the app boasts 50 features -> the app has 50 features。this marks the first time -> this is the first time。

**修正：**使用简单的系词。复杂动词应发挥实际作用——不要把它们浪费在简单的身份说明上。

副词依赖与刻意求变

两种编辑上的破绽。**副词依赖：**用 -ly 副词堆砌描述，取代精准的动词（said softly、ran quickly、whispered quietly）。问题在于密度，而非某一次使用。测试方法：去掉副词。如果只是节奏变了，说明动词不够有力——said softly -> whispered。保留那些传递了动词无法表达的信息的副词（answered honestly）。

**刻意求变：**在相近语句中，用 3 个或更多勉强的同义词指代同一事物——Alice 一会儿是 the protagonist，一会儿是 the young woman，又一会儿是 the eponymous heroine。修正方法：使用名字或代词。重复胜过刻意变换说法。

两种问题的检测列表、修改示例和例外情况：references/fiction-tells.md。

直白语句句法检查

四种结构性破绽，没有对应词表；每种都需要重写，而非替换词语。标记之前，请阅读 references/plain-speech.md，了解各项的检测方法、修正方式和例外情况：

• 表面化的分词尾句（..., ensuring reliability）：删去尾句，或另起一句说明结果及其产生机制
• 虚假的范围表达（everything from authentication to deployment）：直接列出各项内容
• 未指明行为者的被动语态（errors are logged）：指出行为者
• 句子过度堆叠：拆分需要读第二遍才能找到动词的句子

3. 语气破绽

即使每个词单独看都无可指摘，语气仍会暴露作者。旅游指南式语气、宣传口吻、公式化结构、聊天痕迹和结尾免责声明都不设密度门槛：出现一次就算问题。本节中的句子级问题——模糊归因、夸大意义、模棱两可、铺垫过多、自信式填充语、用感受代替机制——则和词汇问题一样，按密度判断。

旅游指南式语气

Nestled between rolling hills, this vibrant city boasts a rich cultural heritage and a thriving arts scene。这是描述任何地理或文化主题时的默认语气。

检测：nestled、rolling hills、vibrant、thriving、rich heritage、bustling、charming、picturesque。**修正：**陈述事实——The city has 300,000 people, two universities, and a jazz festival in August.

宣传口吻

Our commitment to excellence ensures we foster innovation and empower our customers to succeed. 这是新闻稿式的语调，描述任何组织或产品时都容易采用。

检测：commitment to、empower、foster、ensure、strive、dedicated to、passionate about、industry-leading、cutting-edge、next-generation。**修正：**换成具体说法——We help X customers do Y 胜过 We empower customers to succeed。

模糊归因

Experts say、industry reports indicate、observers have noted、many believe。LLM 在想要提出某种说法却没有来源时会使用这些表达。真正的作者要么引用来源，要么为说法负责。

**检测：**没有指明专家的 experts say / experts agree；没有列出具体研究的 industry reports / studies show；没有说明姓名的 observers have noted / critics argue；复数形式的 sources say 实际上最多只指向一个来源。

**修正：**引用来源；或为说法负责；或删掉归因——大多数时候，去掉归因后，句子本身仍然通顺。

重要性填充

This marks a pivotal moment, underscoring broader trends in the industry. 大模型会夸大日常事件的重要性，以凑足字数。

识别： marks a pivotal moment、underscoring broader trends、highlighting the importance of、serves as a reminder that、in an era where、in today's fast-paced world。

修正： 删除整句话。如果没有这句填充内容，后文就讲不通，请重写相关段落。

过度保留和限定词堆叠

大模型会堆叠保留措辞和限定词，让语气听起来谨慎或平衡。单个保留措辞在英语中都没问题；堆在一起会让每个论断都显得犹豫不决。

识别：

• 频繁使用 generally、typically、often、usually、in many cases、for the most part，或连续使用弱情态词：may、can、might、could potentially、arguably、relatively
• 同一分句中出现两个或更多保留措辞：can generally be considered to be relatively reliable
• 在作者明确知道为真的论断上使用保留措辞：this may help with performance，但段落中已经列出基准测试结果

修正： 删除保留措辞，直接陈述论断。如果论断确实需要加以限定，请具体说明：on Linux only、for connections over 1000 RPS，而不是 generally speaking。

结构填充

围绕实际内容打转、却没有增加信息的短语。大模型会用这些短语让表达显得有条理或更口语化。

识别：

• it's worth noting that、it's important to note、it's worth mentioning、here's the thing:、the fact is:、the truth is:、at the end of the day、when all is said and done
• 对文章本身的元评论：in this article, we'll explore、in this guide, we'll cover、let's dive into、let's explore、let's take a look at
• as we've seen / as mentioned earlier / as previously discussed，但读者刚刚已经读过相关内容
• 可用一个词替代的冗长连接词：in order to -> to、due to the fact that -> because、in the event that -> if、for the purpose of -> to、with regard to -> about、a large number of -> many、at this point in time -> now

修正： 删除包装语，保留内容。It's worth noting that X 改为 X。In this article, we'll explore Y 改为以 Y 为主题的首句。

自信腔填充和虚假强调

大模型会用刻意营造的自信语气和修辞铺垫，宣告自己有所洞见，却没有真正表达洞见。

识别：

• 强调口头禅：Full stop.、Period.（单独用于强调时）、let that sink in、make no mistake、here's why that matters
• 修辞铺垫：What if...、Imagine...、Think about it:、Picture this
• 故作深刻的片段：以简短结尾宣称深意，却没有充分铺垫——<short sentence>. That's it.、Simple as that.、Nothing more.

修正： 删除包装语，让论断本身站得住脚。密度能说明问题：一次恰到好处的 that's it 是个人风格，三次就是口头禅。此类表达与重要性填充（serves as a reminder that）和结构填充（let's dive into）有所重叠；如果一个短语符合多个类别，只归入最贴切的类别计数，不要在它涉及的每个类别中重复计算。

公式化的文章结构

大模型描述任何组织或项目时常用的默认结构：第 1 段表达肯定，第 2 段以 Despite 或 However 开头列出挑战，第 3 段以 Looking ahead 或 The future 开头。关键在于结构，而不是具体用词。结尾的写法也自成一格：用一段空谈未来却不做承诺的文字收尾——The future looks bright、Only time will tell、As the space continues to evolve、The possibilities are endless。

修正： 围绕实际情况重新组织内容；如果没有实际内容，这篇文章就不该存在。具体到结尾，请说明计划、日期或事实，或者以最后一个有实质内容的要点收尾。文章不一定要有结论段才算完整。

聊天痕迹和谄媚

从聊天窗口复制粘贴到文档、PR 或邮件后仍残留的助手口吻。在行内模式中，这也是价值最高的检查项，因为它针对回复本身。

**检测：**开场白（Great question!、Certainly!、You're absolutely right!）、结束语 （I hope this helps!、Let me know if you have any questions）、进度表演（Found the smoking gun!、单独作为反应的 Perfect!），以及在回答前复述请求。

**修正：**删除。开头直接给出答案，答案结束时就收尾。在行内模式中，这是一条没有密度阈值的硬性规则：一个 Great question! 都嫌多。

截止时间和知识免责声明

关于模型自身局限的含糊说法，却留在了本该由人撰写的文本中： While specific details are limited、As of my last update、I don't have access to real-time data、Based on available information。

**修正：**查明事实并陈述，或者删掉句子。如果确实存在不确定性，就说明未知的内容及其原因：The 2026 figures are not published yet。

用感受代替机制

描述印象而非读者可以据以行动的事实的文字（SQL you can read）。用机制、数字或指令替代，或者删掉句子。表格和例外情况见 references/plain-speech.md 第 2 节。

4. 格式特征

LLM 常用的布局和标点模式。以下四种几乎会出现在每份草稿中。其他常见问题——弯引号、表情符号、装饰性的 --- 分隔线、偏爱三条项目符号的布局、Markdown 痕迹、LLM 输出错误（turn0search0、oaicite）、句中冒号连接，以及重复说明自身内容的行内标题——见 references/formatting-tells.md。

检测：

• 长破折号（U+2014，或替代写法 --）用作正文中的句子分隔符。替换为单个 - 或调整句式；用圆括号和短破折号只不过是换了一种特征。切勿改写代码或围栏代码块中的 --——在那里它是真正的语法。
• 项目使用句子大小写时，章节标题却采用标题式大小写（Understanding the Core Concepts）。
• 过度使用粗体——每三个名词就有一个加粗。粗体只用于标示术语或路径，不用于其他内容。
• 项目符号大杂烩——明明段落更易读，却把正文改成项目符号。

**修正：**遵循项目惯例。若无惯例，则默认使用纯 ASCII、句子大小写、尽量少用粗体，并采用段落正文。

---

恢复文风

去掉特征只是工作的一半。剔除所有模式却不补充任何内容的文字读起来会很生硬，而这本身也是一种特征。改写应体现立场、富于变化的节奏、对复杂性的承认、恰当使用第一人称，以及具体细节。长篇内容见 references/plain-speech.md。在审计模式下，文风建议属于 Consider 级别，绝不能是 Fix 级别：文风属于作者，因此切勿打着移除 AI 痕迹的旗号，把内容改写成你自己的文风。在行内模式下，应将这些原则用于自己的写作，而非报告问题。

不应标记的情况

这些看起来像 AI 写作特征，但其实不是：

• 直接引用——不要修改他人写下的内容，即使其中包含禁用词汇
• 体裁惯例——游记会采用旅行指南的语气，因为游记就是这样写的。营销文案会使用宣传语气。新闻报道会使用破折号。小说会有意使用优雅变换和三段式表达。尊重体裁。
• 专业术语——机械工程中的 pivotal，网络或身份领域（Kerberos、OIDC）以及奇幻小说中的 realm，儿童福利领域中的 foster，园艺、平面设计或机器学习（损失景观）中的 landscape，统计学和机器学习中的 robust（稳健估计），科学哲学中的 crucial experiment。上文每个检查项中的 Exception: 区块同样适用于此处——领域语境始终优先于模式匹配
• 刻意变换语体——讽刺、戏仿、仿作和风格实验
• 小说中的直接引语／对话——角色可以用任何方式说话
• 真正的列表——三项列表只有在项目内容凑数时才可疑。列举三件真实的事物完全没问题
• 要求使用破折号的出版物——有些风格指南（Chicago、AP）允许或要求使用破折号。此规则适用于你项目的惯例
• 真实范围——from 10ms to 2s、from v1 to v4 处在同一尺度上。只有没有有意义中间值的范围才是虚假范围
• 真正的修辞性问题或单个有力的片段句——文章确实会回答的一个“What if X?”，或一个落点有力的刻意使用的“That's it.”，都属于表达风格。标记成组出现的铺垫或反复装深沉的片段句，而不是孤立的用法。恰到好处地使用一次并非写作特征，因此不计入短文本密度阈值，也不会单独升级为 P1——严重程度取决于堆叠使用。

反例（看起来像 AI 写作，但其实没问题的文字）

在接近某个尖锐极小值的损失景观中，模型的稳健特征无法泛化。这凸显了 Keskar 等人（2017）的一项关键结果：与尖锐极小值相比，平坦极小值往往更有利于提高测试准确率。

乍看之下似乎应标记：nestled、landscape、robust、underscores、pivotal、foster。但 loss landscape 和 robust 是机器学习与统计学中的专业术语，underscores 有明确的指代对象，pivotal 和 foster 描述的是一项可核查的引用研究结果，而非夸大常规结果，nestled 则是在表达字面上的空间关系。六处匹配，只有一处确实值得怀疑，零个写作特征。结论：没问题。不要标记。请注意其中的推理：领域语境和明确的指代对象都能分别优先于词汇匹配，这是两种不同的理由。

---

输出格式

仅限审计模式。报告模板、报告本身的规则，以及用于说明格式的完整示例，请参阅 references/audit-mode.md。

行内模式没有输出格式：清理后的文字就是输出。

参考文件

• references/audit-mode.md——审计流程、范围界定、密度和严重程度等级、报告模板、完整示例
• references/plain-speech.md——抽象隐喻名词、具体性与行为者测试、拆分句子、恢复语气、分词尾部结构、虚假范围
• references/fiction-tells.md——角色姓名清晰度、副词拐杖、优雅变换
• references/formatting-tells.md——格式方面的细枝末节
• references/agent-hygiene.md——整个文集通用的跨领域 Agent 规范
• references/output-contract.md——通用输出约定

输出约定

完整约定请参阅 references/output-contract.md。

• 技能名称： ANTI-AI-PROSE
• 交付类别： audits
• 模式： 根据上述两种模式切换。审计模式（提交文件、粘贴内容、差异或目录供审查）遵循 references/output-contract.md 中的报告篇幅和证据规则。行内模式（在编写时过滤自己的对话输出）不输出任何内容：不输出标题、问题、交付物，也不声明技能已运行。
• 交付路径： docs/local/audits/anti-ai-prose/<YYYY-MM-DD>-<slug>.md
• 严重性等级： P0 | P1 | P2 | P3 | info（参见共享约定）。

相关技能

• code-simplification - 代码质量审计。审计代码仓库时，对代码运行 code-simplification，对文档运行 anti-ai-prose。两者有意互为补充。
• update-docs - 在功能变更后确保文档准确。Anti-ai-prose 关注文风，update-docs 关注事实偏差。
• prompt-generator - 将粗略草稿整理成 LLM 提示词，以便下次生成更清晰的文案。
• repo-audit - 协调 code-review、code-simplification、security-audit 和 update-docs。快速模式不包含 anti-ai-prose；详尽模式会将其纳入代码质量审计。
• code-review - 检查逻辑和正确性。Anti-ai-prose 只处理文案。

规则

1. 让每个字都有价值。 优先采用更简短、更清晰或更具体的表述。必要的解释或无障碍细节可以作为增加篇幅的理由；切勿编造事实。
2. 保留作者的风格。 目标是让文案听起来像某个具体的人写的，而不是泛泛的“好文笔”改写。如果不了解作者的风格，只标出机械化的写作特征。