👋 我是三笠丶，一名专注数据库与数据库架构的 DBA。更多原创文章和技术资料同步更新：ora100.com

别再只研究“去 AI 味”了，文章里没有你，改多少遍都白搭

我们花了不少时间研究怎么去 AI 味，后来才发现，问题压根不在语气词，也不在多写两句吐槽。文章里如果没有“你”，改得再口语，也只是更像人说话的通用稿。

最近在 X 上看到杨一转译的一篇长文，原标题是《用 AI 写作的正确方式》。我本来以为又是一套提示词教程，点进去以后才发现，它讨论的是一个更麻烦的问题：你亲手敲出来的文字，未必真的属于你。

这话刚看有点扎心，仔细想想又确实如此。

“要了解客户需求”“坚持长期主义”“AI 不会取代人，只会取代不会用 AI 的人”……这些话谁都能写，意思也没错，可把作者名字遮住，你根本猜不出是谁说的。

原文把它叫作 Commodity Content，我更愿意把它翻成“通用内容”。这类内容主要回答“是什么”和“怎么做”，对新人有用，却很容易被复制。以前是人从十篇文章里东拼西凑，现在模型几秒钟就能搂一篇，而且通常比普通人搂得更完整。

所以，AI 冲击的不是所有写作，最先被打成白菜价的，是这种谁写都差不多的内容。

文章没有“你”，再口语也没用

这段时间我们一直在折腾文章里的 AI 味。删掉“首先、其次、最后”，减少工整小标题，塞一点“说实话”“挺烦的”，确实会自然不少。

但这种方法有个上限。

模型现在也会吐槽，也会写短句，甚至知道什么时候加一句“完犊子了”。如果文章里的观点、经历和判断仍然可以套到任何人头上，那些口语只是贴纸，撕掉以后，里面还是一篇标准答案。

能把文章变成你的，是原文说的五类东西：你经历过什么、你赞成什么、你反对什么、你从哪件事里突然想明白了什么，以及最后吃过什么亏。

拿数据库文章来说，ORA-01555 的定义是通用内容，官方文档写得比谁都准。真正值得你写的，是那次故障为什么偏偏发生在凌晨，报表任务和清理策略怎么撞到一起，你一开始怀疑错了什么，最后又是靠哪条日志翻过来的。

别人可以复述知识点，却很难复制这一整串细节。

AI 最适合干的，恰恰是那些“不属于你”的活

我很认同原文的一点：不要因为文章是自己逐字敲的，就天然觉得它更高贵。

查官方文档、整理版本差异、把散乱材料排成顺序、检查数字和链接，这些工作当然要做，但没必要每次都靠人肉硬扛。AI 在这方面又快又稳，放着不用才有点可惜。

问题是，人得先把不能外包的东西拿出来。

比如这篇文章到底赞成什么？作者为什么会这么想？有没有一个具体细节能证明这不是临时编的？哪些话即使会得罪人也不准备改？如果这些输入全是空的，只扔一句“按我的风格写”，模型只能从互联网上最常见的写法里拼一个“平均的你”。

平均下来，当然谁都不像。

真要把这件事做起来，也不用先建多复杂的知识库。我觉得最实用的办法，是每次写完文章，多留几份模型自己拿不到的东西。

一份是事情经过。你为什么注意到这个问题，最开始判断错了什么，后来是哪条日志、哪段对话或哪个数字让你改了主意。另一份是取舍，哪些方案看起来漂亮但你不会在生产上用，原因是什么。再留一份原话，尤其是脱口而出的吐槽、犹豫和判断，不要急着让模型全改成书面语。

以数据库故障为例，错误码和官方解释当然要查，但真正有价值的素材通常藏在时间线里。凌晨谁先发现，监控为什么没提前叫，业务说的“卡”究竟是连接慢还是 SQL 不返回，第一次处理为什么没效果。把这些记下来，下一次 AI 才有机会写出属于这次事故的文章，而不是又一篇《数据库故障排查的五个步骤》。

还有个很笨但好用的检查：把产品名、公司名和作者名临时遮住再读。如果换成任何数据库、任何 AI 产品都成立，那一段大概率只是行业常识。常识不是不能写，但后面最好跟一个自己的选择，或者解释一下为什么偏偏在这里强调它。

这里也别走到另一个极端。人格化内容不是多爆隐私，更不是每篇都编一段凌晨救火。没有经历就别装有，引用别人的故事就写清楚是谁的。真正的作者感，有时只是一句有边界的判断，例如“这个参数我不会在业务高峰期直接改”。它没什么戏剧性，却能让读者知道写文章的人真的做过取舍。

原文还有一句我很喜欢：你没法自动化一件自己都说不清楚的事。

这句话放到 Skill 上同样成立。Skill 不是把“自然一点、有深度、有个人风格”写进去就完事了。真正有用的，是不断存下作者认可和嫌弃的原句，记录他爱用什么词、句子在哪儿停顿、什么时候喜欢解释、什么时候直接下判断。

这篇文章对我们的 Skill 有什么用

有用，而且不是加几个禁用词那么简单。

我准备把它提炼成四道检查。写之前，先分清素材里哪些是通用事实，哪些是作者自己的判断和经历；没有人格素材时不假装有，应该回头补采访或原始记录。写完以后把作者名盖住再看，如果换个账号照样成立，说明稿子还太“公版”。

文风也不能只存几个口头禅。原文把声音拆成用词、节奏，以及解释、描写、行动和叙述四种句子功能，这比“像一个资深 DBA”具体得多。

最后，AI 负责重复和整理，人负责提供新经历、新判断和最后拍板。这个边界一旦搞反，Skill 越复杂，生成出来的文章反而越像精装修样板间：哪儿都挺好，就是看不出谁住在里面。

写到这里，我倒不太关心一篇文章能不能骗过所谓 AI 检测器了。

我更关心的是，把名字遮住以后，老读者还能不能认出这是我写的。

如果认不出来，那就继续改。检测分数再漂亮也没什么用。

参考资料

1. 杨一：《用 AI 写作的正确方式》
2. Nicolas Cole：The Right Way To Write With AI

DBA 资源导航

• ora100.com · 数据库学习平台
• Oracle DBA 应该掌握的 100 条命令（建议收藏）
• MySQL DBA 应该掌握的 100 条命令（建议收藏）
• PostgreSQL DBA 应该掌握的 100 条命令
• SQL Server DBA 实用的 100 条命令（建议收藏）
• 达梦 DBA 应该掌握的 100 条命令（建议收藏）
• OceanBase DBA 应该掌握的 100 条命令（建议收藏）
• MongoDB DBA 应该掌握的 100 条命令（建议收藏）

更多 Oracle、MySQL、PostgreSQL、MongoDB 实战内容，可以访问 DBA 学习平台：ora100.com

感谢阅读。
我会持续分享 Oracle、GoldenGate、RAC、Data Guard、MySQL、PostgreSQL、OceanBase、电科金仓等数据库技术文章。
个人网站：ora100.com