去 AI 味，不是多装几个 Skill

我最近一直在调整这个账号的文章。标题太像工具说明，就重写；开头没有自己的经验，就补回来；英文小字没有信息，只是为了显得像设计杂志，就删掉。

改了几轮，我发现文章里的 AI 味，通常不是几个词造成的。

“首先、其次、最后”当然可以少用，过度工整的排比也可以拆掉。但这些都删完以后，文章仍然可能很顺、很完整，也很不像任何一个具体的人。

几个词只是表面。文章里缺的是作者自己的判断。

删掉 AI 常用句式，只完成了清洁

网上有很多去 AI 味提示词：少用总结句，不要频繁转折，把长句拆短，多加一点口语。它们有用，尤其适合处理一眼就能认出来的模型习惯。

但这种方法有一个上限。

如果 AI 不知道作者平时在做什么，它只能选择最安全的例子；不知道作者愿意为什么下判断，它就会给出四平八稳的结论；不知道文章写给谁，它只能把每个概念解释一遍。

最后得到的文章可能没有明显病句，也没有臭名昭著的套话，却像一篇经过清洗的通用稿。

去掉 AI 常用表达，只是把噪点擦掉。作者自己的东西不会自动出现。

对这个账号来说，我希望文章至少保留几件事。

我做 UI，也写前端，所以评价一个工具时，不只看它能不能生成漂亮截图，还会看结果能不能继续修改、能不能进入网页、移动端成本是否合理。没有实际运行过的项目，不能写成亲测；别人的案例，也不能换个主语就变成自己的经验。

这些要求很难塞进一句“请用我的口吻写”里。

我更愿意把它拆成四层：作者边界、文章任务、栏目规则和修改记忆。

作者边界回答“我是谁”。它不需要在正文里反复介绍履历，但要限制第一人称可以讲到哪里。什么是我亲手做过的，什么只是看过公开演示，什么仍然无法确认，必须分开。

文章任务回答“这一篇要完成什么”。清单文章帮助读者缩小范围，实测文章展示输入、过程、结果和失败，观点文章则需要给出判断依据。三种内容不能共用一副骨架。

栏目规则决定证据标准。写 GitHub 项目，要核验真实仓库；写界面改造，要有前后对比；写 Skill 实验，要留下真实输入和输出。没有这些材料，文案写得再像真人，也只是包装。

修改记忆负责把人工判断留下来。某种开头连续被删，某类英文装饰反复被认为没有用，某种免责声明总让文章显得生硬，这些问题不应该在下一篇再次出现。

规则写得再完整，初稿也不会自动变成成稿。

要求一多，模型很容易顾住结构，忘了口吻；补上个人经验，又可能把没有发生过的细节写得太真。让同一个模型笼统地“再检查一下”，它往往只会换几个词，然后告诉你已经优化完成。

更有效的做法，是把审稿拆成彼此独立的任务。

第一轮只看任务。文章有没有回答标题提出的问题，主线是否清楚，材料是否足够，读者看完能不能做出下一步选择。

第二轮只看作者。哪些判断超出了真实经验，哪些第一人称没有依据，哪些段落虽然听起来专业，却不像这个作者会关心的事情。

第三轮再看语言。删掉没有信息的完整句，拆掉刻意对仗，处理重复、含混和过度解释。

顺序很重要。结构还没站稳时就忙着改句子，只会把一篇方向错误的文章润色得更顺。

审稿也不能代替人的最终判断。模型可以指出风险，却不知道哪些粗糙是作者故意保留的，哪些句子虽然不够漂亮，但确实是作者最想说的话。

前一篇写 img2threejs 时，最初的开头是：“AI 很会生成图片，但一旦你想继续修改，它往往就不那么好用了。”

这句话没有明显 AI 套话，意思也正确。但它缺少一个关键问题：为什么是我在意这件事？

修改后，我们把实际工作处境放了回来。

新的开头谈到我平时怎样使用 AI 做设计，也谈到一张图进入网页之后还要继续处理镜头、材质、交互和移动端成本。观点没有变，读者却能看见它来自什么经验。

这种修改比替换“首先、其次”更值得记录。

下一次写工具实测时，系统应该先问：作者为什么会在意这个问题？它和真实工作有什么关系？有没有一个具体的失败或取舍可以说明判断？

但也不能把每次局部修改都写成永久规则。规则只增不减，最后会互相冲突，模型反而抓不住重点。

我会优先留下三类问题：反复出现的问题、影响文章可信度的问题，以及下一篇还能复用的问题。临时偏好不必保存，已经过时的规则直接替换。

如果要从今天开始搭一套个人写作系统，不需要先做一个复杂产品。

一个作者文件，写清身份、经验和事实边界；一个栏目文件，区分教程、实测、清单与观点文；一个禁区文件，记录绝对不写和反复删掉的表达；一个修改记录，保存重要改动以及为什么改。

写新文章时，根据任务读取对应文件。初稿完成后，分别检查任务、作者和语言。发布前由人做最后决定，发布后的修改再回到记录里。

这个循环不会让每篇文章立刻变得完美，但它能保证下一篇不是从同一个错误重新开始。

最终要保留下来的，是一个具体作者选择材料、做出判断和承担边界的方式。