菜单
检查和清理中英文文本里的 AI 套路，适用于“去 AI 味”“说人话”“自然一点”“别像模板”“先标问题”这类改写和审稿需求；按场景控制力度，同时保留事实、术语、语域和责任主体。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | shuorenhua |
| description | 检查和清理中英文文本里的 AI 套路，适用于“去 AI 味”“说人话”“自然一点”“别像模板”“先标问题”这类改写和审稿需求；按场景控制力度，同时保留事实、术语、语域和责任主体。 |
把文本从”像模型在表演写作”拉回”像具体人在当前场景下表达”。
这份 skill 不是敏感词替换器，也不是反技术、反抽象、反专业。它的目标是减少模板感、表演感和语域漂移，同时保住事实、术语和责任主体。
在下面这些需求里使用：
chat、status、docs、public-writing在下面这些需求里不要硬套：
in-place scope，就只做句内改写。按固定顺序做，不要跳步：
chat / status / docs / public-writingprotected spans，看有没有必须保留的术语、系统主语、引用原文、命令或正式语体Tier 1 / Tier 2 / Tier 3，按问题命中强度判断，不要把 Tier 当作改写力度minimal / standard / aggressivestructural / bounded / in-place，判断这次能删到什么程度——自由删并重排、只把整句空话进删除清单、还是一句都不删references/，默认继续按问题类型补看 Protected Spans、Positive Style Contract、微操作手册、结构反模式 和相关短语表；如果目标是“改完能直接发”，或文本明显属于 README、release note、论坛帖、issue 回复，再补看 Scene Packs、真实样本评测 和 改写示例annotation mode执行第 6 步时，先按“模式”处理，再按“词条”兜底：
先判主场景，再处理局部问题。混合文本只保留一个主语域，其他语域只在必要信息层面留下。
chat信号：
默认档位：minimal
status信号：
默认档位：minimal 或 standard
docs信号：
默认档位：minimal
public-writing信号：
默认档位：standard
更细的下限限制见 场景禁改表。
如果文本本身命中下面任一子场景，不依赖用户是否明说，也不受主场景初判限制，都要补看 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。
只加载 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 时，才退化为只按本文件做基础清理。
处理无源引用时，固定只在这 3 种模式里选一种：
rewrite-safe
研究表明 / studies show / 业内人士认为 这类权威铺垫chat 和 public-writingaudit-only
docs 和 statusrewrite-with-placeholder
如果用户没指定模式，就按场景默认值走；如果文本跨场景，优先取更保守的 audit-only。
minimal适用于：文本本身基本自然，只需去掉局部模板感、收尾腔和多余修辞。
默认动作：
standard适用于：有明显 AI 腔或语域混搭，但信息骨架是好的。
默认动作：
aggressive适用于：Tier 1 命中密集，或 Tier 1 + Tier 2 叠加后整段呈现强模板感或强表演感。
限制：
Tier 1 明显密集，或多类结构问题叠加时才允许docs 默认不要升到 aggressiveScope 表示这次能不能改动句子和段落结构，和 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 能去味：允许删"整句都是空话"的句子，但不直接删，而是进删除清单交用户拍板一句能进删除清单，必须同时满足三条：
两类动作分开走（实测依据：长文里句首引导词模型能句内清掉，但整句空话在 in-place 下删不掉，只会被软化成另一种说法）：
值得一提的是 / 归根到底 / 这说明）后面还跟着实质内容 → 直接句内洗，删引导词留骨架，不进清单不仅仅是……更是…… 的价值拔高）→ 进删除清单，不擅自软化成另一种说法输出：正文给句内洗后的稿，末尾附「建议删除（待确认）」清单，每条写 原文 + 为什么删了不丢信息。用户点头才删，长度由用户拍板。
in-place适用于用户明确要求"完全原样 / 一句都别删 / 严格保句数"的情况，比 bounded 更严：整句空话也不删，只做句内降调。
默认触发条件：
bounded 仍删多了禁止动作：
允许动作：
删短语前先做语义独立性检查：删掉短语后，剩余部分必须仍是完整、可读、没有悬空指代的陈述句。否则改用句内替换，不要硬删。遇到整句空话，保留原句并标注 [空句，建议人工确认是否删除]，不擅自软化成新说法。
aggressive + in-place 可以存在，但默认先提醒用户：长文 aggressive 很容易明显缩水；如果用户真正要保长度，优先改成 standard + bounded。用户明确坚持时，再执行 aggressive + in-place，但仍遵守不删整句、不并句、不重排的边界。
Tier 表示问题命中强度，与 严重度分级 保持一致，不表示改写力度。
默认替换。命中这类词或句式时，通常直接删掉或换成更具体的表达。常见类型：
默认处理：局部命中用 minimal 或 standard，密集命中时可升到 aggressive
单独出现可以放行，但同段聚集时是 AI 味信号。常见类型：
长度参考：短段落（< 100 字/词）同段 2+ 个即标记；长段落（≥ 100 字/词）同段 3+ 个再标记。
默认处理：保留最贴切的一个，其余改写；通常用 minimal 或 standard
常见词本身不构成问题，只在全文密度明显过高时才处理。常见类型：
重要 / 关键 / 核心 / 提升significant / innovative / effective默认处理：只替换一部分重复命中，通常用 minimal，必要时不改
以下内容默认优先保留，除非用户明确要求改风格且改动不损害信息：
不要为了“像人”把文本改得更假。专业文本可以专业，关键是别模板化、别表演化。
完整的保护清单见 Protected Spans。
改写后的文本应尽量满足：
更完整的正向目标、分场景校准和“cleaner vs more human”对照见 Positive Style Contract。
默认输出一个推荐版本，不默认输出审稿过程、多版本比稿或逐条点评。
只有在用户明确要求下面这类事情时才启用：
先别改，先标问题这段哪里像 AI只做诊断 / 审稿 / 标注先告诉我该不该改annotation mode 不直接给整段改写稿，默认只输出最重要的 1-5 个问题点。每个问题点固定包含这 4 个字段：
问题族：例如 开场套话 / 无源引用 / 工程师腔 / 语域混搭触发点：点明命中的词、结构或局部句子建议动作：删掉、换成具体表达、补来源、保持不动是否建议改写：是 / 否额外约束：
是否建议改写：否annotation mode 时，仍然按默认改写合同输出单一推荐版本遇到无源引用时，输出必须符合所选模式：
annotation mode 下，只输出对应的处理建议，不直接给整段改写稿rewrite-safe：建议删掉无证据权威铺垫；如果不是 annotation mode，再给改写结果，不补虚构来源audit-only：优先点明缺来源、缺归属，而不是假装已经证实rewrite-with-placeholder：允许保留论证位置，但要显式暴露“此处待补来源”；如果不是 annotation mode，可以给带占位提示的改写结果只有在高风险误杀时，才额外补一行极短说明，例如：
保留了系统主语和术语，避免失真。这里只做轻改，避免把正式公告写成口语贴。提交改写前，把回读固定拆成两步，不要混着做：
先检查这 5 项：
如果删掉一句后段落突然没了落点，就补一条事实句，不要补口号句。
bounded / in-place scope 下额外检查：
in-place：输出字数低于原文 85% 时，回退检查是否误删整句、并句或压段落（in-place 不该删任何整句）bounded：字数会因删整句空话而下降，不设硬下限；但要确认删除清单里每条都是"删了不丢信息"的纯空句，没混进实句或承担节奏的重复只有在第一遍已经保住事实、但读起来还有轻微 AI 味时，才做第二遍。第二遍固定只查这 5 件事：
结论先说 / 直接说结论 / 值得注意的是 这类提示层总的来说 / 归根结底 / 最终来看 这类空收尾方向是对的 / 意义重大 / 真正理解了用户第二遍只允许做轻量修正：
第二遍不要做的事：
场景保守策略：
public-writing 和 AI 味偏重的 chat，第二遍更常需要docs / status / code-context 默认更保守；如果第二遍会让语气变口语、变广告、或影响保真，就停在第一遍SKILL.md + references/ 一起工作Tier 1 / 2 / 3 校准命中规则：看 严重度分级annotation mode 的对照：看 改写示例默认做法是：先用本文件完成“场景、Tier、档位、输出合同”的主判断，再按问题类型补读 references/；只有在单文件安装场景里，才停留在本文件的兜底规则。