tuiqiao

name

tuiqiao

description

Remove signs of AI-generated, translated, or overly mechanical Chinese prose. Use when rewriting, editing, or reviewing Chinese blog posts, essays, newsletters, nonfiction chapters, product analysis, or long-form commentary so they read like native Chinese writing. Trigger this skill when the user asks to 「去 AI 味」, 「推敲」, 「润色成中文母语表达」, 「改得像博客或书里写的」, 「减少翻译腔」, explicitly names this skill (tuiqiao), or similar. Detect and fix translation-like phrasing, empty big words, formulaic contrast frames, sloganized endings, list inflation, punctuation misuse, terminology/casing inconsistencies, paragraph rhythm that feels assembled rather than written, plus copula avoidance, vague attribution, synonym churn, filler phrases, chat artifacts, reasoning-chain residue, and over-structuring. Do not use for English text, code, or config files.

推敲（tuiqiao）

Overview

名字取自贾岛「僧敲月下门」：一个字也要掂量，掂量完还不能看出斧凿痕。把中文文本从「像模型拼出来的稿子」改成「像中文母语者真的写出来的文章」，优先处理翻译腔、结构腔、排版腔和判断腔，保留原文事实、立场和信息密度。

Workflow

1. 先判断文本类型。 博客、专栏、书稿、评论、产品分析可以更有节奏和作者判断；公告、说明文、技术文档则优先保留准确和克制。
2. 先看文章主线。 判断第一段在立什么题，主体每段各自承担什么功能，最后一段是不是在收同一件事。
3. 先找最显眼的 AI 痕迹。 重点看英文句法直译、机械对照句、空泛结论、列表堆砌、连环冒号、破折号、过度工整的段落节奏。
4. 再决定改写力度。 轻度润色只清理措辞和标点；深度改写要重排句子顺序、合并弱句、补足主语或因果关系。 🔴 CHECKPOINT（力度分级）：原文超过三段、且用户没说明「润色」还是「重写」时，先报告准备采用的力度和理由，等用户确认再动笔；三段以内、或用户已指明力度，直接执行。
5. 保留作者原意。 不擅自补充事实，不把谨慎判断写成绝对论断，不把普通结论硬拔高成时代宣言。
6. 做最后一遍朗读检查。 读起来要像中文原生写作，不像英文思路换成中文词汇。

Failure Modes

#	触发条件	一线修复	仍失败兜底
F1	原文几乎全由营销话、口号和空泛判断组成，删完 AI 痕迹后所剩无几	优先保留可核实的具体信息（数字、动作、对象），其余压缩成一句克制的陈述；明确告知用户「原文大部分是无机制支撑的判断」	报告「原文可保留的内容不足」，请用户补一段事实素材或确认接受大幅缩写
F2	用户请求「去 AI 味」但未提供文本	一次性请用户提供待处理文本；不凭空演示	用户持续未给文本则终止本轮，不猜测改写对象
F3	文本太短（一两句话），模式层面的判断（文章级结构、段落节奏）无从谈起	只做词级和标点级清理（翻译腔、空泛大词、破折号、填充短语），不谈文章结构	如此短文本仍无法改善，如实说明短句天然难判 AI 味，不过度处理
F4	引号样式冲突：原文混用 "" 和 「」	按出现频率选主导样式，全篇统一	频率接近时默认 ""，并在交付说明里报告所选样式
F5	项目声明样式与用户本轮要求不一致	以用户本轮要求优先（见 Repo Overrides 顺序）	无法确认用户意图时，列出两种样式各给一行示例，请用户指定
F6	深度改写需要 patterns.md，但文件缺失或读取失败	只用本文件 Core Rules 完成改写，覆盖度略降	告知用户模式库不可用，输出降级说明，指出未覆盖的检查维度

Voice Adoption（可选）

references/voices/ 是本地可选扩展，不随公开仓库分发；该目录不存在时跳过本节的询问与加载，直接走中立路径。

默认走中立去 AI 味润色，不套任何作者腔调。当前任务是深度改写、长篇润色或风格化创作（非公告、说明书、短句修订）、用户未明确限制风格、且本会话还没问过时，按 references/voice-adoption.md 的询问条件，机会性地（每会话最多一次）问用户要不要套某位中文作者的声音。

用户指名作者（「用李笑来的口气重写」）、要求换声音或撤销声音时，加载、切换、卸载流程和 🔴 CHECKPOINT（加载前告知用户该档案会覆盖哪些 Core Rules）见该文件。

Core Rules

1. 优先改掉翻译腔

• 把英文句法硬套中文的句子拆开重写。
• 少用「对于……来说」「基于……」「围绕……展开」「使得……得以……」这类翻译味很重的连接。
• 需要对比时，不默认使用 不是……而是……，改用更自然的转折、递进或重心移动。
• 不用「作为……而存在」「扮演着……的角色」「承担着……的使命」替代简单的「是」；不用「致力于」「旨在」「聚焦于」这类动词堆砌制造虚假深度，直接写动作和对象。详见 references/patterns.md §14。

2. 去掉空泛的大词和套话

• 少用没有机制解释的词，如「颠覆」「革命」「赋能」「重塑」「深刻改变」「开启新篇章」。
• 避免「这标志着……」「这意味着……的时代已经到来」这类自动收束句。
• 把抽象判断落回具体动作、约束、成本、分工或结果。
• 不用「业内人士指出」「专家表示」「广受关注」「引发热议」这类模糊归因和热度词撑场面：有具体来源就写来源，没有就删。详见 references/patterns.md §15。

3. 打散机械结构

• 不强行把每段都写成三分句、排比句或工整对照句。
• 不连续使用「首先」「其次」「最后」「与此同时」「值得注意的是」「从某种意义上说」。
• 发现列表可以改成自然叙述时，优先改写成段落。
• 枚举时两项或四项比三项更自然：AI 爱凑「X、Y 和 Z」，人未必。
• 不靠同义词轮换避免重复，不用「从……到……」制造虚假覆盖，填充短语（「在当前这个时间点上」「为了能够实现这一目标」）直接删。详见 references/patterns.md §16–17。

4. 保持中文节奏

• 允许长短句混用，不把每句都写成同样长度。
• 让句子有明确主语和动作，少写无主句串联。
• 该用「我」就用第一人称；偶尔的题外话和半成型的想法是人味，不必都删干净。
• 信任读者：直接陈述事实，不解释隐喻，不手把手引导；不用可引用的金句收段，句尾分词（「……，象征着……」）直接删。详见 references/patterns.md §20。
• 避免段落结尾总是落在大而空的价值判断上。

5. 管住文章级结构

• 开头要尽快立题，不要第一段说 A，后面一路滑到 B。
• 主体段落各自要有功能，常见功能是：交代背景、提出判断、展开论据、举例、转折、收束。
• 如果某一段既不推进主线，也不提供必要信息，优先删、并、挪，不要硬留。
• 结尾要回应前文真正提出的问题，不要临时拔高到更大的时代命题。
• 深度改写时，可以重排段落顺序，但不要为了工整硬凑成三段论。
• 总结结构时，少把段落关系写成一串 先……再……最后……，更要看它们是不是顺着同一个问题自然往下走。

6. 处理标点和排版

• 正文引号默认用全角双引号 ""，嵌套用全角单引号 ''。如项目在 CLAUDE.md/AGENTS.md 里声明使用 「」，或用户在本轮请求里明确要求，则全篇统一改用 「」（嵌套用 『』）。两种样式不要混用。
• 不使用长破折号 ——，优先改成逗号、句号或拆句。
• 不密集使用冒号 ：，尤其避免连续多句都靠冒号展开解释。
• 中文正文中的英文多词术语使用半角空格分词，如 AI Design Agent。
• 英文术语与中文括号连写时，不在 （ 前加空格，如 LLM（大语言模型）。
• 并列英文术语用斜杠连接时，不在斜杠两侧加空格，如 coworkers/agents。
• 英文品牌名使用官方大小写，如 YouTube、OpenAI、GitHub。
• 不机械加粗关键词；列表项不写成 **标题**：内容 的格式，能改成叙述就改。详见 references/patterns.md §17。
• 中文正文不用表情符号（🚀 💡 ✅ 等）装饰标题或列表项，见一个删一个。详见 references/patterns.md §19。

7. 统一常见术语和日期

• token 保持英文。
• API 保持英文。
• PR 在长篇中文叙述里优先写作 代码审查，除非项目已有别的明确约定。
• 数字日期写作 2026 年 2 月 26 日、2 月 5 日。
• 中文月份叙事写作 一月、二月。

8. 控制判断强度

• 不轻易下「完全取代」「彻底结束」「只剩一种可能」这类极端结论。
• 不做无依据的阴谋论推断、资本市场臆测或人物动机脑补。
• 需要强调重要性时，先给机制，再给判断。
• 有把握就直接下判断，不写「可以肯定的是」「毫无疑问」；正文里不留「让我想想」「你问的是 X 吧」这类推理和复述痕迹。详见 references/patterns.md §21–22。

9. 压住结构密度

• 结构密度不能超过内容密度：短文不搭多级标题骨架，简单观点不拆成「背景 / 分析 / 结论」。
• 标题层级压到两层以内，列表只留真正的并列项。
• 结构本身也是 AI 味的来源，详见 references/patterns.md §22。

规则冲突裁决

两条规则打架时按这里裁，不靠临时折中：

• Rule 8（控制判断强度）与 Rule 5（保留作者原意）冲突：原文是绝对化结论（如「赢者通吃」「彻底颠覆」）时，优先压低判断强度，但要在交付说明里点明改了哪个判断、为什么改；用户明确要求保留原表述时原样保留。
• 补机制的占位边界（对应 N4）：可补的是无实体、无数字的通用流程机制（如「发布要开会」「出故障先定责」），且必须标注「此处按行业常识补了机制，发布前请核实」；不可补的是具体数字、具体人名机构、原文没有的具体事实。拿不准属于哪类时，一律按「不可补」处理，删掉而不是编。
• 冒号引导的解释句：只在引出定义、列表或说明时保留；拿不准是否必要，拆成句号。

反例黑名单（不要做的事）

来自实测暴露的对抗性案例（N1 引号混用、N4 越权补事实、N5 假深度改写、N6 软化返工指令等）。命中任一条即返工改写，不交付带缺陷的版本。完整清单见 references/anti-patterns.md。

Repo Overrides

• 如果当前项目存在 CLAUDE.md、AGENTS.md、样例文章或术语表，先遵守项目内规则，再使用本技能的通用规则。
• 如果项目已经有明确文风样本，模仿它的句长、判断方式、段落推进和术语约定，不额外套用另一套腔调。
• 引号样式按以下顺序确定：用户在本轮请求里明确要求 → 项目 CLAUDE.md/AGENTS.md 的声明（例如 tuikiao quotes: 「」） → 默认 ""。
• 当原文整篇已经显著使用 「」 而项目未声明时，沿用原文样式，不要硬翻成默认 ""。

Deep Review

在以下情况，额外读取 references/patterns.md：

• 需要做深度改写，而不是轻度润色。
• 需要解释「为什么这段中文有 AI 味」。
• 文本明显带有英文原文结构、营销套话或通稿腔。
• 需要给出「修改前/修改后」示例。
• 需要检查开头、主体、结尾之间是不是同一条主线。
• 需要重排整篇结构，先搭一个更自然的文章骨架。
• 需要检查词级痕迹：系词回避、动词堆砌、同义词轮换、假范围、填充短语、模糊归因。
• 整篇说不出具体哪句有问题，但节奏像节拍器、段长句长都接近——参考 references/patterns.md 末尾的「统计信号」。

在以下情况，额外读取 references/corpus.md：

• 需要判断这段中文更接近哪类母语写法。
• 用户明确要求「改得像博客或书里写的」。
• 需要给技术文、评论文、演讲稿分别找不同参照。
• 需要避免把强个人腔调误当成通用中文。

如果只是需要快速选一个参照，先读取 references/corpus-quickpick.md，不够再读完整的 references/corpus.md。

如果用户已经在本会话里选定了某位作者的声音，且 references/voices/ 目录存在（本地扩展，不随公开仓库分发），额外加载 references/voices/index.md 里对应的作者档案；这份档案的规则在与 Core Rules 冲突时优先。

需要回归校验 benchmark 时，运行 python scripts/backtest.py examples/benchmark/cases.md（15 条对抗样例全量检查：禁用痕迹、破折号、表情符号、引号混用、评分加总）。

Output

默认按下面顺序给结果：

1. 直接给改写后的版本。
2. 如果用户要求解释，再简短指出 3 到 6 个最明显的问题。
3. 如果用户要求保留更多原句，再补一个「轻改版」和一个「重写版」。
4. 用户要求评估改写质量时，按 references/final-check.md 的 5 维评分表打分（直接性/节奏/信任度/真实性/精炼度，每维 1–10，总分 50；45–50 达标，35–44 可交付但留弱项说明，<35 重写）。

Final Check

🔴 CHECKPOINT（交付前终检）：输出给用户之前，按 references/final-check.md 逐项过完交付清单，并对照 references/anti-patterns.md 扫一遍 N1–N6；任何一项不过，回到对应 Core Rules 改完再交，不要带病交付。