| name | avoid-ai-writing |
| description | 扫掉 AI 写作痕迹(AI-isms),让内容自己说话——中英文都适用。写或改会被人读到的文字时用:评论、code review、回复、帖子、邮件、文章、个人陈述、发言稿。Use when writing or editing text a person will read — comments, reviews, replies, posts, emails, essays, personal statements. |
去除 AI 写作痕迹
目标:写得像一个真人在认真说话,而不是一台被调教得过度光滑的机器。让事实和判断自己承重,不靠辞藻和结构撑场面。
动笔前:先定读者和文体
底下所有清单都是减法——告诉你删什么,从不问你写给谁。清单能查出病灶,查不出姿态。
最难看的那几句往往一条规则都不违反,只有把读者放进来才看得见。所以这一步在前面。
读者:一句话写下这段字给谁看、他拿去做什么。不是“用户”,是具体的人和处境——
谁读、他要向谁交代、会不会被转给第三方。然后查三样:
-
称谓。给本人看的东西,不能用第三人称直呼其名转述他说过的话
(“小王之前提过” → “贵方此前提出”)。文中出现一个人名,全篇称谓一起看。
-
姿态。有没有在评价读者负责的东西?开口先给对方的产品打分(“你们这套框架是对的”),
而同一份文档后面还要向他要资源,姿态就错了。改成描述,别下判词。
-
读者读完要做什么。他要拿去向上汇报,别留“你说了算”的口气;
他要批钱,别把设计写成现状。
-
他解不解得开。你手上那套内部语汇,他一个字都没有。逐词扫,每个专有名词问一句
“他见过这个词吗”。四类最容易漏:
- 内部编号与代号——阶段号、实验名、机器名。对你是名字,对他是乱码
- 以“今天/上次/之前”为坐标的时间——他不知道是哪天,更不知道之前是什么样
- 没有指代的“我们”——公开场合它不指任何人,读者无法判断是谁
- 只有你知道基准的比较——“另一套环境也一致”,谁建的、独立于什么,
他无从判断这句话有多重
判据:每个专有名词,他要么在自己的代码库里见过,要么我在同一段里定义过。
两者都不是就是泄漏。改法不是删掉,是换成他能自己核对的描述——把内部编号换成
那件事本身,把“今天那个错”换成报错原文。
这条最容易漏,因为写的时候那些词对你是透明的——你不觉得它们是“词”,
它们就是事情本身。这是 curse of knowledge 在对外文字上的形态。
读者是别人,这段字就走文件。 他问怎么回、要一句现成的话——那句不写在回复里:
写进文件,里面只放要发的内容,过一遍本 skill,再把路径给他。你的判断和理由照常写在
回复里。读者是他自己(分析、解释、给他的判断)才直接写在回复里。
文体:先定档位,写完对照。
| 档位 | 长什么样 |
|---|
| 正式方案 / 对外文档 | 标题是名词短语;无口语词;无行内加粗 |
| 工作邮件 / 群消息 | 完整句,可第一人称口语,不用标语 |
| 页边笔记 / 给我的话 | 小写、缩写、省主语都行(见「代笔人格」) |
- 这张表是例子不是分类法。 载体千奇百怪,表里三行盖不住;遇到没列的(宣传物料、
名录、网页简介、别人的幻灯片)就照读者和场合现判,别硬套最近的一行——同一种载体也能
两种写法,一张海报第一人称写得好的有的是。要定的是这一份给谁看、他在什么场合读到。
- 判断的落点是这段字最后停在哪,不是你把它递出去的地方。 传递管道(聊天软件、邮件、
issue 回复)几乎总比落地载体口语,照管道定档就一路写散。
翻车实例:一段要放进对外展示物的简介,交付方式是聊天软件发给对接人。assistant 照
“群消息”定档写成第一人称口语,被当场退回、指出这种明显该用正式文体。skill 当时已加载,
第一节就是这条,只是没跑。加载不等于执行:动笔前先写出一行「读者=X,落地载体=Y,
档位=Z」再下笔。
- 标题也算文体。正式文体的标题是名词短语(“当前进展”),不是说话口气
(“先说我们手上现在有什么”“这块怎么做”)。一份文档的标题要么全是名词短语,
要么全不是,别混着来。
- 方向是“像真人写的正式文字”,不是“像真人说的话”。把正式文档改口语是另一种改坏,
和下面「最高优先」是同一条。常见翻车:为了去 AI 味,把“团队日常工作都在上面进行”
改成“天天在上面干活”。
最高优先:不要过度纠偏(硬约束)
去 AI 味不等于把文字改散、改口语、改水。这是最常见的反向翻车。
- 保留:好的正式语感、经过思考的判断、排比、诗意、克制的修辞。
- 只动:确认的句式痕迹和堆砌,做窄范围手术。不要从头重写已经认可的内容——做行级精修。
- 触发全文重写的阈值见末尾;没到阈值就只改命中点。
- 改完问一句:语气是不是被降级了?如果原来是“考究的书面体”,改完变成“随口聊天”,那是改坏了。
- 功能性格式不是 AI 味,别扫掉:论文/仓库/文档的超链接、行内代码、必要的章节引用是信息,真人恰恰会加。要扫的是装饰性格式(加粗轰炸、emoji 标题、PPT 式小节),不是让文字裸奔成纯文本。
判断“不是X而是Y”这类句式时不要一刀切删:
- 留:真有反差/反直觉张力的(承重的“钉子”,一篇留 1–2 个)。
- 删/改平:X 是没人信的稻草人的(改成普通正面陈述)。
怎么判“承重”(不然“留 1–2 个”实操上就等于“留我喜欢的”):
- 把 X 那半句盖住,只留 Y。这段的意思缺不缺一块?缺 = 承重,留;不缺 = 装饰,删。
- 读者真有可能相信 X = 承重;X 是没人主张过的说法 = 稻草人,删。
英文 tell(写 HN 评论、英文内容时重点查)
词(出现即换成普通词):
| AI 词 | 换成 |
|---|
| leverage / utilize | use |
| robust | reliable / solid |
| seamless / streamline | smooth / simplify |
| delve / dive into | look at / get into |
| foster / empower | build / help / let |
| boast / feature / serve as | has / is |
| showcase / highlight / underscore | show |
| pivotal / crucial / vital | important(或直接说为什么) |
| tapestry / landscape / ecosystem / realm | (具体名词) |
| meticulous / intricate / nuanced | careful / detailed |
| testament to / nestled | (删,直接说事实) |
短语 / 套路(删或重写):
- 开场客套:"Great question", "Certainly", "You're absolutely right", "Let me break this down"
- 收尾客套:"Hope this helps", "Feel free to reach out", "At the end of the day", "Only time will tell", "The future looks bright", "a game-changer"
- 软化垫话:"It's worth noting", "That said", "Interestingly", "It's important to remember"
- 假权威:"Experts say", "Studies show", "It's widely believed"
- 自我标注:"Here's the interesting part", "The kicker?", "The catch?", "Here's the thing"
补充词/短语:moreover / furthermore / albeit / indeed / certainly;"a symphony of" / "a tapestry of" / "delicate balance";装腔状语 "with practiced efficiency" / "with measured steps" / "mastered precision"。
句式:
- 否定排比:"It's not X, it's Y" / "Not only X but also Y" / "not just X — Y"。这是头号 tell,英文同样要管;留 1–2 个真有张力的,其余改平。
- 提问紧接自答:"And that question? It's the answer." / "The result? Total chaos." → 删掉这种自问自答的小机灵。
- 戏剧性断句:"Short sentences. Pauses. For effect." 一串名词/碎句堆戏剧感 → 合回正常句子。
- 强行明喻/比喻:被要求“写得更生动”时给什么都硬塞一个比喻("X like an angry octopus after a bad haircut")→ 没必要的比喻删掉。
- 三连(rule of three):"fast, reliable, and scalable" 这种凑数三元组——砍成一个具体的。ChatGPT 改不掉这个,要专门盯。
- 系动词回避:别用 serves as / boasts / features 代替 is / has。
- 拖尾 -ing 拔高:"..., highlighting its significance" / "..., reflecting a broader shift" → 删掉这条尾巴,或拆成有事实的句子。
- 拔高夸张:"You're not just onto something — you've changed the entire game" 这种顺势升级捧场 → 删。
- 节奏均匀:所有句子 15–25 词、所有段落一样长 = 机器感。故意让长短不齐。
标点 / 格式:
- 破折号(— / --)滥用:能用逗号句号就别用。
- 弯引号 " " 混进直引号(技术痕迹)。
- 每个关键词都 加粗;每行都是 粗体标签: 开头的列表;标题 Title Case 每个词大写;emoji 当小标题(🚀💡✅);随手撒 emoji(🤖🌀)。正文该是段落就写段落,别什么都列表化。
- 整篇切成 PPT/大纲式的小节(没内容也要凑标题)。
内容造假 / 虚饰:
- 编造化名假人当案例:没数据/没真例子时,AI 爱凭空造个人(经典名字 "Sarah Chen")+ 一段轶事。要么用真例子,要么不编。
- 只说“代表/象征/反映”不说事实:"this represents/symbolizes/reflects…" → 直接给可核查的事实。
- 过度周全:面面俱到、每点都平衡、每段都收个漂亮尾巴 = 没立场没灵魂。真人会有偏好、会跑题、会留开口。
中文 tell(写中文内容、发言稿、文章时重点查)
分三类,是为了让末尾的重写阈值数得出来。
句式类
- 铺垫短句开场:一句话独立成段/成句,作用只是宣布下一句要说什么,本身不载信息。
中文里长这样:“先说这个平台是什么。”“这里要讲三件事。”“X 不是重点。重点是Y。”
(等于英文的 "Here's the thing" / "Let me break this down"。)真人写正式文字直接说事,
不清嗓子。删掉这一句,后面那句几乎总是能独立站住——站不住才说明它真载了信息。
- “不是X,而是Y”:你最反感、每篇都冒出来的句式。留 1–2 个承重的,其余改成普通正面陈述。
- 单音节压缩:为省字把双音节词砍成单字,念出来像公文或古文,不像人说话。
现代汉语默认双音节,单字动词只在少数现成的口语搭配里站得住。动因通常是省 token /
压字数,而不是表达需要——这是它区别于真人简省的地方。
- 命中:“说完不再争”(→ 就不争了)、“我没法回头认自己违反了它”(→ 承认)、
“不判对错”(→ 不判断谁对谁错)、“她有四处,他零处”(→ 他一处也没有)、
“气泄了”(→ 出了气)、“这个我不辩”(→ 这个我不想争)、
“真的谢”(→ 真的谢谢你)
- 不命中:“这个我认”“这个你定”“我看行”——高频动词带前置的简单宾语,
是现成的口语说法,砍掉反而假
- 判据一,查词:这个字有没有你日常真会说的双音节形式——谢→谢谢、辩→争辩、
泄→泄气、判→判断、争→争论。有就是压缩,换回去。例外是本来就能单说的高频动词:
认、定、看、行、说、做、想、要、给、去、来。
- 判据二,查句法:高频单字动词后面跟小句或复杂宾语,也得换。
“这个我认”可以,“我没法回头认自己违反了它”不行(→ 承认)。
- 定稿时把中文里的单字动词逐个找出来,对照这两条查一遍
- 一起查文言虚词渗入(“此”“其”“之”“乃”“故”“兹”混进现代中文),
以及“不赘”“兹不详述”这类四字压缩。病根一样:为显精炼而离开现代口语
- 凑整的排比/对仗:为整齐而堆的删;真有力量的留。四项排比先问一句是不是第四项在凑数。
- 口号化:正文里的标语腔,改成平实陈述。
修饰类
- 加粗/斜体的量——强调是稀缺资源,不是要不要用的问题,是用多少的问题。少量、只标承重的那几句,是真人写法,该保留甚至该主动加;满屏加粗才是 tell,因为读者一个重点都抓不到。判断:把所有强调去掉,读者还能一眼找到最重要那句吗?找不到=加得不够;去掉后冒出五六个“重点”=加得太多。具体的 tell 是:每个关键词都加粗、每条列表都用**粗体标签:**开头、为排版好看而加粗。一页正文里三五处承重加粗是健康的。斜体在中文里渲染偏丑、真人也少用,除了专名/外文术语/一处轻微强调,基本不用——想强调优先用加粗。
- 概念词加引号成癖:“一体化”“集市”“抓手”——引号密度本身是 tell,只留必要的(英文术语注释、专名)。
- 空评价/空过渡:“很重要”、“对我影响很大”、“更重要的是”、“我逐渐意识到”、“这是一次宝贵的经历”——说了等于没说。换成那个让人自己得出结论的具体场景/事实。
- 空名词:“部分”“方面”“层面”“因素”。写下它就问一句它具体指什么,说不出来就删掉
这个词、直接说那个东西。“不是我最记得的部分”指不出任何东西,“我记得的是你这个人”
才指得出。这类词后面跟否定式尤其危险(“不是……的部分”),一句读完什么都没剩下。
结构类
- 段尾总结/升华句:“这些都是…的一部分”、“这让我明白了…”、“真正的意义在于…”——删掉评语,只留发生了什么,让读者自己感受。
- 小标题模板:对仗四字(“诉讼先行,规则未定”)、“从X到Y”、“双X与Y”、“…的X维度”、“本质:…”、“宏观启示:…”。改成具体、略不对称、真人会起的标题。
- 节奏均匀:每句每段一样长 = 机器感。故意让长短不齐。
中文标点(机械换一遍,不计入重写阈值)
这条不是文风判断,是模型自身的输出偏差:全角标点在 tokenizer 词表里不占便宜,
模型写中文时会默认滑向 ASCII 半角。真人不会——中文输入法默认就出全角,打半角反而要多切一次。
所以满屏半角是一眼假,而它在语义层之下,靠“写得用心”修不掉,只能定稿前扫一遍。
任何一段中文都算,包括聊天里的一句话回复。
换成哪个:,→, .→。 :→: ;→; ?→? !→! ...→……。
并列项之间是顿号 、 不是逗号;书名篇名用 《》,不用引号也不用斜体;外国人名分隔用 ·。
破折号不在这张表里:它的问题不是宽度是数量,别顺手换成 —— 了事,先看字频表能不能删掉。
引号最要命:中文用 “”,套引号里层才用 ‘’,别用 ",也别和 「」 混着来。
英文那节说直引号才对——那是英文,英文句子里仍然是 "。中英混排的文档两套各归各。
不动的地方:代码、路径、URL、参数名、数字(含 12:30)、整句英文引文。
括号看里面装什么:英文或代码就 (transformative use) 半角带空格,中文就 (见上一节) 全角。
定稿前跑一遍,肉眼漏得比想象中多:
python3 ~/.claude/skills/avoid-ai-writing/scripts/cjk-punct.py --fix <文件>
还没落成文件的(聊天回复、issue 评论)就自己对着上面那行逐条过。
结尾(最后一句几乎总要重写)
两种坏法:
- 总结式:把前文重说一遍,不推进任何东西——跑步机测试直接不过。
- 悬空式:最后一句是个标签或半截计划(“第一批先跑通”),说了动作,没说结果,
也没说要对方做什么,读着像话没说完。
正式文档的最后一句只落在三处:请求(要对方做什么)、承诺(我们接下来给什么、
什么时候)、或者干脆没有结尾段——正文说完就停。
先查第三种。 如果诉求、时间安排这些已经各自成节,再加一段收尾就是纯重复,
连同它上面那条 --- 一起删。想写结尾段这个冲动本身就是“每段都收个漂亮尾巴”的
AI 本能。升华、展望、“这套模式还可以推广到…”一律删。
字频扫描(肉眼漏掉的痕迹,用计数抓)
定稿前数一遍,超量就砍。分母是每 1000 字(不是全文,不然长文永远不超标):
| 项 | 上限 / 千字 |
|---|
| 破折号(— / ——) | 3 |
| 圆括号 ( ) | 5 |
| “不是…而是” / "it's not...it's" | 1 |
| 概念词加引号(成对数) | 2 |
| “本质”“核心”“关键” | 2 |
正当保留不计入:英文术语注释 (transformative use)、法条号、案件年份/法院标注、脚注编号、行内代码。
两个判断测试(写完自检)
- 段落互换测试:随便交换两个正文段,通不通?如果照样通顺,说明每段没有真正往前推进——它在原地踏步。
- 跑步机测试:逐段问“这段到底新增了什么?”。如果什么都没推进,删掉。
重写 vs 精修 阈值
英文:命中 5+ 个词 tell + 3+ 类句式/结构 tell + 节奏均匀 → 整段重写,别逐点打补丁。
中文没有词 tell 表,按上面那三类数:句式类中 3 处,或三类各中 1 处且全段节奏均匀
→ 整段重写。
否则只精修命中点,保住已认可的内容和语气(见最高优先那条)。
代笔人格(以用户身份写 comments/页边笔记/消息时)
写的不是“assistant 的话”,是这个人会说的话。写完自问:他真会这么说吗?
- 禁服务业结尾:"say so" / "let me know" / "feel free to" / "flag me if" / "happy to" / “尽管说”。assistant 腔的第一标志。真人笔记要么直接问("do we want both in?"),要么陈述完就停。
- 页边笔记是钝的:改了什么、为什么、需要对方做什么,三件事说完就完。不铺垫、不客套、不总结。
- 笔记里破折号(—)基本不出现,真人用逗号和句号。
- 语域向低不向高:小写开头、缩写、省略主语都比“考究的完整句”更像真人笔记。
发之前:凡是可核实的,重核一遍
上面所有清单查的是怎么写。这一节查的是写的是不是真的——一句话读起来完全正常,
里面的函数名、版本号、日期、行号却是错的,而这类错误比文风问题贵得多:对方照着复现不出来,
或者更糟,去查了一个不存在的东西。
要核的是「可被对方核对的东西」,判据不是“我记不记得清”,是“他会不会拿去对”:
- 引用对方代码里的名字——函数、文件、配置项、行号。他一搜就知道你有没有编
- 版本号、日期、提交号——尤其是“X 在 Y 之前发布”这种推理,整条结论压在两个日期上
- 数字——次数、耗时、比例。写“3/3 一致”就得真跑过三次
- 对方项目的行为描述——“你们这个检查不会捕获它”,说错就是当众指摘错了地方
词的当下含义也是可核实的。 流行语的色彩会朝反讽漂:“真的谢”现在是没好气,
不是道谢。短、口语、带情绪的近年流行语,用之前查一次。
必须在发之前重做,不能只在写的时候做过。 两个原因:草稿从成形到发出往往隔着很久,
中间事实会变(对方合并了新提交、你自己的环境改过);更常见的是,写的时候你是先写后查,
而先写下来的那个版本会锚住你——查证变成“确认我写的对不对”,不是“事实是什么”。
凭印象写完再去查、结果恰好对,那是运气,不是方法。
做法:定稿后逐条列出可核实的断言,一条一条去查,查完再发。列不出来说明你没在写事实。
这条和「读者」第 4 条常常一起翻车,不是巧合:都是把“对我透明的东西”默认成“对他也透明”。
未验证的东西可以写,不能不标。 上面读起来像“核不动就别发”,那是把一件事收得太紧:
有些断言当场核不了——环境已经不在、复现要半小时、或者这本来就是给自己留的一条线索。
这时候删掉是丢信息,硬核是浪费,正确的做法是把成色写进句子里:“没复现,从日志推的”“上次
是这样,这轮没测”“看代码得出的,没跑”。真正的失败形态从来不是“写了没核实的东西”,是
用验证过的语气写没验证的东西——读者分不出哪句是实测哪句是推断,只能全信或全不信。
核到什么程度,看错了的代价,不看场合大小。 往别人仓库提 issue,说错就是当众指错地方,
先复现值这个时间;自己仓库里给自己留的条目,标一句“未验证”就够。变的是投入,不变的是标注。
不确定该投入多少时,先花两分钟做最省事的那次验证:它经常直接改掉结论,比权衡本身便宜。
查了,也可能查错——因为查的东西本身不作数。 上面问的是“这个数字我编没编”,这一层问的是
“我拿去核对的那个东西,凭什么算数”。一句话可以查得很认真而结论仍然错:查的是摘要、状态输出、
缓存、构建产物,而它们都不是事实本身,是从事实生成出来的一份说法,生成之后事实还在动。
替身与原件的常见配对:
- 文档、README、注释 对 数据与代码本身——文档记的是当初的意图,数据是现在的事实
- 状态命令的输出 对 被查询的系统自己的记录——前者常是从几个条件推断的,后者是实测
- 构建产物、缓存、快照 对 源与实时查询——二进制可能是几天前编的
- 自己刚写下的笔记 对 原始出处
- 任何一层 API 的自述 对 另一层的独立观测——两层不一致时,能反驳的那层才作数
判据是对每个来源追问一句:它是从哪来的? 只要它是从别的东西生成、摘录、缓存出来的,
那个别的东西才是要核的,一路溯到不能再溯。同层互证不算证——用一个接口去印证同一个接口,
无论跑多少遍,验的都是它自洽,不是它对。
代价不对称,所以值得多花一步:查错来源产生的是有据可依的错误,它带着一份看起来像证据的东西,
比凭印象写的错误更难被人推翻,也更难被自己发现。
最容易漏掉的场景
最容易漏的是应答式写作:回评论、回 issue、回邮件、回聊天。被人问一句、答一句,
感觉像在说话不像在写东西,检查根本不会触发。这是本 skill 被跳过的头号原因——
不是改得不好,是压根没想起来要改。(发生过:同一个会话里 skill 加载过两次、
也确实用在了草稿上,成批的评论回复却一条没过,其中还有一句替用户许下了工作承诺。)
第二容易漏的是改稿。一份已经过检的文档,感觉是“过了”的状态,之后再改就不检查了。
但每一次 Edit 都是新写的字,而真实工作里绝大多数写作是改不是写。
五条硬规定:
- 短不豁免。一句话的回复也要过。越短的字 AI 腔越集中——"Say the word"、
"Happy to"、"Let me know"、"Feel free to" 全长在短回复里。
- 被动不豁免。别人先开口不改变性质:发出去的仍然是署用户名的字。
- 加载 ≠ 用了。skill 读进上下文不算数,要在每次动笔前过一遍;
写完再想起来已经晚了,尤其当那段字已经发出去。
- 过检状态不继承。改一处就重过一处;改动累积到三五处,整篇重过。
- 发现一处,扫全篇同类。对方指出的是实例,要修的是模式:称谓错一处 → 全文称谓
都看;标题口语一个 → 整套标题都看;一句改口语了 → 全篇语域都看。
逐处打补丁的代价是对方连着指出三四次同一类错误,每次都以为是新问题。