AI Writing 这个说法早已不是新鲜事但开发者社区里真正稀缺的不是“能用 AI 写字”而是“写出来的内容还能被人读下去”。过去一段时间里技术博客、开源项目 README、团队文档中出现了大量同质化、无信息增量、甚至带着编造命令和版本号的 AI 生成内容。这类内容在英文社区里被称作 AI slop放到中文技术语境里可以理解为AI 味很重、没有营养、无法验证的文本。Slop 不只是语气问题。一篇技术文章如果只把概念换成更圆润的说法把步骤写得像说明书却没有可复现的命令、没有版本信息、没有排错路径那它本质上没有传递任何工程价值。更隐蔽的问题是AI 在生成代码和配置时会出现幻觉编造不存在的 API 参数、混用不同版本的行为、给出跑不通的安装命令。把这些内容直接发布等于把没有编译过的代码推送到了生产环境。这篇文章要做的是把 AI 写作从“一次性生成整篇长文”改成一条可以审查、可以验证、可以复用的工程流水线。内容会覆盖 slop 的成因、提示词约束、事实核查方法、常用工具链、发布前检查清单和常见问题排查。示例偏技术写作场景但核心思路同样适用于 README、接口文档、会议纪要和内部技术方案。1. 先搞清楚 AI Slop 是什么以及它为什么会在技术写作里泛滥1.1 从阅读体验判断哪些内容一读就有 AI 味在没有明确证据之前很难单凭“感觉”判定一段文字是不是 AI 写的。但在技术写作里有些特征非常稳定开头习惯用历史背景或时代背景起势最后落到“具有重要作用”这种空泛评价每个功能都写“该功能可以提高效率、增强用户体验”但不说具体怎么做步骤之间缺乏因果关系只写操作不写目的没有版本号、没有环境描述、没有输出示例命令直接甩出来错误处理写成“需要注意异常情况做好日志记录”这类空句结尾把整篇文章复述一遍没有任何新信息。关键判断是AI 味不是来自某个特定的词而是来自“信息密度低”。低信息密度的文字无论词汇多华丽阅读体验都接近 slop。对比下面两种写法低质量版本Redis 连接池非常重要合理配置可以显著提升系统性能建议开发者重点关注相关参数。可编辑版本项目使用 Lettuce 客户端时需要关注 maxTotal 与 maxIdle 的取值。maxTotal 决定高并发下能建立多少连接配置过小会出现连接等待具体表现可以通过 redis-cli info clients 里的 connected_clients 字段观测。第二段虽然还需要进一步核对默认值但它的信息密度远高于第一段有组件名、有参数名、有观测方式读者拿到后可以立即开始验证。1.2 技术写作里 Slop 的三个主要来源第一个来源是直接让 AI 一次性生成整篇长文。把“帮我写一篇 Redis 连接池配置教程”这样的请求扔给模型生成结果通常结构完整、段落通顺但没有任何真实工程痕迹没有本地报错、没有版本冲突、没有日志片段。这种文章和模板填充没有本质区别。第二个来源是用 AI 扩写或洗稿已有内容。把一段几十字的