看到“A 1986 Aircraft Manual Fixed My Anti-Slop Skill”这个标题的时候我第一反应是这下好了AI写作问题的解药竟然藏在一份几十年前的飞机维修手册里。翻译过来就是一份1986年的飞机维修手册把我的“反AI味”能力修好了。这件事对经常写技术文章、接口文档、README、周报的开发者很有参考价值。今天不聊模型部署不聊显存占用只聊一套能直接落地的写作控制方法把飞机维修手册的文体规则注入到AI提示词里让AI生成的内容从“云里雾里”变成“照着做就行”。文章后面会给可复制的提示词模板、改造前后的对照案例还有一套检测AI味残留的脚本。先说结论这个思路完全不需要额外硬件不挑显卡不挑模型任何能跑提示词的本地或在线LLM都能用。你只需要改一套提示词模板再加一个关键词黑名单。下面进入正题。1. 核心能力速览这一套“Anti-Slop Skill”本质上是提示词工程和写作规范的组合不是某个具体软件。先把能力项整理成一张表能力项说明解决的问题消除AI生成内容的模板化、空泛化、不可执行问题也就是常说的 AI Slop核心思路用飞机维修手册的工程文体作为风格基准强制每句话都可执行、可验证技术门槛无不需要写代码不需要GPU不需要额外依赖主要适用对象技术博客、API文档、故障排查手册、知识库、代码注释、周报、项目复盘运行方式在任意LLM的提示词窗口运行或通过API批量改写是否支持批量支持同一套模板可覆盖全部技术文档是否支持接口与模型本身无关接口不变只改提示词内容典型工具提示词模板、关键词黑名单、Python检测脚本不适用场景营销文案、品牌宣传、情绪化表达、需要故事感的叙事内容这个技能和传统意义上的“本地部署项目”不一样它不改变你的运行环境只改变你要求AI“怎么说话”。所以后面的内容没有安装步骤重点是方法论、模板、案例和验证手段。2. 什么是 AI Slop为什么技术人先得识别它AI Slop 是最近两年非常流行的说法专门形容AI生成的、看起来很通顺但实际没什么信息量的内容。它不一定是错的但它是“低密度、高风险、高替换成本”的文字。我归纳过AI Slop的几种典型特征高频使用抽象词汇比如 delve、tapestry、testament、优化、赋能、抓手、闭环、颗粒度。每段先给一个“总结段意”的句子然后再用两三句话把同样的意思换个说法重复一遍。排比结构很多但排比的内容没有增量信息。到处都是“值得注意的是”“需要注意的是”“总而言之”“综上所述”这类过渡词。结论听起来很正确但落到执行层面读者不知道下一步该点哪个按钮、调哪个参数。在技术写作里AI Slop的杀伤力很大。程序员看文档是为了解决一个具体问题如果文档花了两段铺垫“为什么要解决这个问题”却没写“出现什么报错、检查哪个日志、改哪个配置”那这篇文档就是负资产。更现实的问题是很多内容平台已经开始对明显的AI生成内容降权搜索引擎也在过滤“无信息量页面”。如果你运营技术博客或团队知识库文章全是AI Slop腔调流量和搜索收录都会受影响。所以反AI味不是审美洁癖是实际收益问题。3. 为什么偏偏是“1986 年的飞机维修手册”飞机维修手册不是文学读物它是给机务人员在航班间隙、噪声环境、夜班状态下使用的操作依据。这种文档的写作约束非常极端写错了会导致事故写模糊了会导致误操作。所以它必须做到“一个没参与过设计的人也能照着执行”。从这类工程手册里可以提炼出几个文体特征明确对象和前提条件先说明这是哪个机型、什么状态下适用。步骤是命令式动作直接写“拆卸盖板螺丝”“拔出保险销”而不是“需要对盖板螺丝进行拆卸处理”。每个动作都有验收标准拆完要检查什么锁紧要达到多少扭矩间隙不能超过多少。状态是具体的写“液压油位低于最低刻度线”不写“液压油量不足”。警告、注意、提示分级清楚哪些操作会伤到人哪些会损坏设备哪些只是提醒。为什么强调“1986年”这个年份因为那个年代没有算法辅助生成手册是工程师一句一句写出来的。它必须能经得起实际维修场景的检验用词必须准确到不会产生歧义。放在今天看它反而成了对抗AI废话的绝佳标本。这套风格用一个通用例子来演示故障现象主起落架收放速度变慢收起时间超过 8 秒。状态检查查看主液压系统压力表确认压力是否在 2800 至 3000 psi 区间。处理步骤若压力低于 2800 psi检查液压泵出口滤芯是否堵塞。若滤芯污染按维护手册第 5 节更换并记录更换时间。压力正常后地面作动收放三次观察锁定时间是否低于 5 秒。验收标准连续三次收起时间不超过 5 秒且目视确认机械锁到位。这个例子是通用写法不代表任何真实机型。你会发现哪怕完全不懂飞机读这段文字也能知道“该看什么、该做什么、做完怎么算成功”。这就是技术写作最缺的东西。4. 把手册文体转成 Anti-Slop 写作框架从飞机维修手册里提炼出的风格可以固化成四条写作规则。这四条规则就是 Anti-Slop Skill 的核心。4.1 规则一删掉形容词写状态量“性能明显下降”“稳定性较差”“响应变慢”这类话在技术文档里没有意义因为每个读者对“明显”的理解不同。正确的做法是写可测量的状态量。改前系统性能明显下降。改后接口平均响应时间从 120ms 上升到 850ms错误率从 0.1% 上升到 5.2%。我平时要求AI写内容时会强制它把每个抽象词替换成“指标 数值 对比对象”。如果AI说没有数据那就让它写“需要补充监控数据”而不是强行编造。4.2 规则二用条件分支替代泛泛建议手册里永远不会写“请妥善处理”而是写“如果出现X则做Y如果出现Z则做W”。这种条件分支结构让读者能在错误发生时快速定位。改前建议关注系统资源使用情况。改后若 CPU 占用连续 5 分钟超过 90%检查是否有死循环任务若内存占用超过 80% 且持续增长优先抓取堆栈信息后再重启服务。条件分支的好处是它把“知识”变成了“决策表”读者不需要自己推断。4.3 规则三命令式步骤替代说明式段落很多AI写的教程喜欢用“我们需要对配置文件进行修改以实现端口变更”这种句子应该直接改成“修改 config.yaml 中的 port 字段改为 7861”。具体操作步骤的粒度要控制到“每一行只包含一个动作”。动作之间不要插解释解释可以放到步骤后面的“说明”里或者干脆删掉。4.4 规则四每个章节给验收标准手册的每个维修流程结尾都有验收标准。放到技术文章里就是读者做完你的步骤后怎么判断自己有没有成功。验收标准写浏览器访问 http://127.0.0.1:7861页面正常返回控制台无红色报错日志。不写服务应该能正常启动。有了验收标准文档就具备可测试性这也是技术文章和散文最本质的区别。5. 提示词模板给 AI 注入手册风格规则本身不能自动改变AI的输出你需要把它写进提示词模板。下面这套模板是我目前在用的 Anti-Slop 通用模板可以直接复制到任意LLM对话里。从现在开始你是一名工程文档评审与改写专家。请把输入内容改写成“飞机维修手册”风格。 严格遵守以下规则 1. 词汇层 - 删除并替换这些词delve、tapestry、testament、优化、赋能、抓手、闭环、颗粒度、值得注意的是、需要注意的是、总而言之、综上所述。 - 所有抽象描述必须替换为可观察的状态量例如“性能下降”改为“响应时间从120ms上升到850ms”。 2. 句子层 - 禁止使用“为了……需要……”这种万能句式。 - 每句话只能表达三种内容状态描述、动作指令、判断条件。 3. 段落层 - 每个小节先写前提条件再写操作步骤最后写验收标准。 - 如果某段无法给出验收标准直接删除该段。 4. 结构层 - 标题只能使用以下词汇故障现象、状态检查、处理步骤、验收标准、注意事项。 - 不允许自行创造其他标题。 5. 输出格式 - 只输出改写后的正文。 - 不要解释修改原因。 - 不要输出“好的”“以下是改写结果”之类的开头。使用方式很简单把原来的AI生成内容粘贴到这个模板后面让模型重新输出。如果是批量处理可以写一个简单的循环脚本把模板和正文拼接后逐个请求模型API。我建议把模板里的“禁用词列表”单独拆出来维护因为不同团队的黑名单不一样。比如国内团队可能更在意“赋能”“抓手”海外团队更在意“delve”“tapestry”。词表越贴合自己的领域效果越好。6. 效果对比改造前 vs 改造后看模板不如看实例。下面我把一个很常见的开发主题“本地服务端口被占用”分别用AI味写法和手册风格写法跑一遍再说明关键差异。6.1 改造前典型 AI Slop 写法在本地开发中端口冲突是经常遇到的问题它可能导致服务无法正常启动从而影响整体开发效率增加不必要的排查成本。为了解决这一痛点我们可以通过灵活配置端口参数来优化。首先我们需要检查当前端口的使用情况确保资源分配的合理性。然后根据检查结果决定是否需要更换端口。最后重新启动服务验证问题是否解决。这段文字每一句话都对但读完之后你依然不知道要敲哪条命令。6.2 改造后手册风格写法故障现象启动服务时提示 Port 7860 is already in use。状态检查在终端执行 netstat -ano | findstr 7860记录占用 7860 端口的进程 PID。处理步骤若占用进程属于当前用户可停止的进程执行 taskkill /PID /F 强制结束。若占用进程属于系统进程或不允许结束的进程打开 config.yaml修改 port 字段为 7861。保存文件并重启服务。访问 http://127.0.0.1:7861 验证返回状态。验收标准连续访问 10 次HTTP 状态码全部为 200无 Connection refused。差异点非常清楚改造前写“检查当前端口使用情况”改造后直接给出netstat命令。改造前写“根据检查结果决定是否更换端口”改造后给条件分支可停进程走终止流程不可停进程走改端口流程。改造前写“验证问题是否解决”改造后写“连续访问10次状态码全部200”。再举一个项目周报场景改造前本周我们重点推进了系统优化工作提升了平台的稳定性和用户体验。改造后本周完成登录模块超时重试逻辑。线上登录超时率从 2.1% 降至 0.6%。验收方法通过压测脚本连续运行 30 分钟无超时告警。周报改成这样之后领导不看过程也能知道结果团队复盘时还能直接拿验收方法当回归测试用例。7. 验证方法检测 “AI 味” 是否还残留AI改写完之后还要过一道检查。我一般用两层验证关键词脚本和人工执行测试。7.1 关键词检测脚本下面这个Python脚本可以统计一篇文档里AI高频词出现次数适合在文章发布前跑一遍。import re from pathlib import Path AI_WORDS [ delve, tapestry, testament, landscape, realm, 优化, 赋能, 抓手, 闭环, 颗粒度, 值得注意的是, 需要注意的是, 总而言之, 综上所述, 首先, 然后, 最后, ] def detect_slop(text_path: str) - dict: text Path(text_path).read_text(encodingutf-8, errorsignore) hits {} for word in AI_WORDS: count len(re.findall(word, text, flagsre.IGNORECASE)) if count: hits[word] count return hits if __name__ __main__: import sys result detect_slop(sys.argv[1]) if result: print(检测到AI高频词) for word, count in result.items(): print(f {word}: {count} 次) else: print(未检测到明显AI高频词。)使用方法python detect_slop.py article.md这个脚本只是第一道筛子能拦住明显的词汇级问题拦不住句式级和结构级问题所以还要做人工验证。7.2 人工执行测试找一位不熟悉这个主题的人让他完全照着你的文档操作一遍看他卡在哪一步。如果他在某一步停下来问你“这个文件在哪”“这条命令去哪执行”说明文档的“状态检查”和“处理步骤”还是不够具体。这个方法借鉴的是飞机维修手册的验收逻辑文档是否合格不看写得好不好看执行者能否一次性完成操作。8. 常见问题与排查方法用这套方法时会遇到一些比较典型的问题我把排查思路整理成表问题现象可能原因排查方式解决方案AI 改完还是很空提示词只限制了词汇没限制句式和结构检查输出中是否还有“为了……需要……”句式在模板里增加“每句话只能表达状态、动作、判断条件”改完太干像流水账步骤粒度太粗缺少解释让不了解背景的人试读在步骤后补充“说明”小节解释技术原理风格太冷没有上下文手册风格完全取代了背景介绍对比内容类型保留第一段背景介绍正文进入故障现象AI 不遵守禁用词列表上下文太长规则被后来的内容淹没查看输出里哪些词还在新开对话把模板放最前面正文放后面没有数据可写内容本身没有可量化指标检查日志、监控、压测报告先补监控数据再写文档不要编造数字批量改写时结果不稳定每个请求的上下文长度不同固定模板顺序和字数上限拆成小批量单次最多处理一个章节第5条特别提醒一下如果你自己的业务没有监控数据AI瞎编一个“响应时间从120ms升到850ms”出来比写“性能下降”危害更大。修改后的文档里出现的每个数字都必须能从日志或监控里查到查不到就写“需补充监控数据”。9. 最佳实践与适用边界Anti-Slop Skill 不是万能文体它适合的目的是“让读者完成任务”不适合“让读者产生情绪”。所以在实际使用中要分清边界。适合使用手册风格的场景故障排查文档、错误码说明。API 接入文档、参数对照表。项目周报、验收报告、复盘文档。团队内部知识库、新人上手文档。代码注释里的“为什么这么做”。不建议使用手册风格的场景产品营销页需要情绪和故事。技术分享的开场白可以先用故事讲清楚问题再进入操作步骤。课程脚本和教学叙事需要节奏和悬念手册式写法会让读者流失。工程化方面我建议把整套规则沉淀成三份资产提示词模板统一放在团队的资料库里。禁用词表定期根据AI输出的新套路更新。检测脚本直接在CI流程里跑文章合并前拦截AI味。另外要注意合规边界。反AI味的过程本质上是让AI辅助你更清楚地整理自己的知识和操作流程。涉及代码、配置、数据指标时不要编造参数和结果。涉及其他人编写的文档、代码或维修资料要保留引用和版权信息。商用场景下AI生成的文字也要经过人工复核确认没有虚假技术信息和隐私泄露。10. 总结与下一步这个标题最值得尝试的点是把“飞机维修手册”这种极致工程文体当成提示词约束让AI从“写得像篇作文”切换到“写得像份施工图”。不需要换模型不需要加硬件只改提示词规则效果立竿见影。建议你先做一个小实验拿自己最近写的一篇技术博客或一份接口文档用第5节的模板跑一遍再用第7节的脚本检查一遍看看删掉多少废话、改出多少明确步骤。通常第一次就能发现大量“为了……需要……”句式。最容易踩的坑是只加关键词黑名单不约束段落结构。只换词不换骨架AI照样能写出格式工整但没有操作价值的文字。正确的做法是把词汇、句式、段落结构、验收标准四层一起约束。后续可以继续扩展的方向把模板接入团队知识库的API形成“提交文档自动扫描AI味”的流水线或者把这个思路做成IDE插件在写Markdown文档时实时提示“这句话没有可执行动作”。方法本身不难难的是每次写作都坚持用验收标准收尾。养成这个习惯之后你再看AI写的东西会明显觉得它“听话了不少”。 
长河君 · 2026/8/30 11:44:35 · 阅读 1.2k 用飞机维修手册风格写技术文档：一套反AI味提示词模板
看到“A 1986 Aircraft Manual Fixed My Anti-Slop Skill”这个标题的时候我第一反应是这下好了AI写作问题的解药竟然藏在一份几十年前的飞机维修手册里。翻译过来就是一份1986年的飞机维修手册把我的“反AI味”能力修好了。这件事对经常写技术文章、接口文档、README、周报的开发者很有参考价值。今天不聊模型部署不聊显存占用只聊一套能直接落地的写作控制方法把飞机维修手册的文体规则注入到AI提示词里让AI生成的内容从“云里雾里”变成“照着做就行”。文章后面会给可复制的提示词模板、改造前后的对照案例还有一套检测AI味残留的脚本。先说结论这个思路完全不需要额外硬件不挑显卡不挑模型任何能跑提示词的本地或在线LLM都能用。你只需要改一套提示词模板再加一个关键词黑名单。下面进入正题。1. 核心能力速览这一套“Anti-Slop Skill”本质上是提示词工程和写作规范的组合不是某个具体软件。先把能力项整理成一张表能力项说明解决的问题消除AI生成内容的模板化、空泛化、不可执行问题也就是常说的 AI Slop核心思路用飞机维修手册的工程文体作为风格基准强制每句话都可执行、可验证技术门槛无不需要写代码不需要GPU不需要额外依赖主要适用对象技术博客、API文档、故障排查手册、知识库、代码注释、周报、项目复盘运行方式在任意LLM的提示词窗口运行或通过API批量改写是否支持批量支持同一套模板可覆盖全部技术文档是否支持接口与模型本身无关接口不变只改提示词内容典型工具提示词模板、关键词黑名单、Python检测脚本不适用场景营销文案、品牌宣传、情绪化表达、需要故事感的叙事内容这个技能和传统意义上的“本地部署项目”不一样它不改变你的运行环境只改变你要求AI“怎么说话”。所以后面的内容没有安装步骤重点是方法论、模板、案例和验证手段。2. 什么是 AI Slop为什么技术人先得识别它AI Slop 是最近两年非常流行的说法专门形容AI生成的、看起来很通顺但实际没什么信息量的内容。它不一定是错的但它是“低密度、高风险、高替换成本”的文字。我归纳过AI Slop的几种典型特征高频使用抽象词汇比如 delve、tapestry、testament、优化、赋能、抓手、闭环、颗粒度。每段先给一个“总结段意”的句子然后再用两三句话把同样的意思换个说法重复一遍。排比结构很多但排比的内容没有增量信息。到处都是“值得注意的是”“需要注意的是”“总而言之”“综上所述”这类过渡词。结论听起来很正确但落到执行层面读者不知道下一步该点哪个按钮、调哪个参数。在技术写作里AI Slop的杀伤力很大。程序员看文档是为了解决一个具体问题如果文档花了两段铺垫“为什么要解决这个问题”却没写“出现什么报错、检查哪个日志、改哪个配置”那这篇文档就是负资产。更现实的问题是很多内容平台已经开始对明显的AI生成内容降权搜索引擎也在过滤“无信息量页面”。如果你运营技术博客或团队知识库文章全是AI Slop腔调流量和搜索收录都会受影响。所以反AI味不是审美洁癖是实际收益问题。3. 为什么偏偏是“1986 年的飞机维修手册”飞机维修手册不是文学读物它是给机务人员在航班间隙、噪声环境、夜班状态下使用的操作依据。这种文档的写作约束非常极端写错了会导致事故写模糊了会导致误操作。所以它必须做到“一个没参与过设计的人也能照着执行”。从这类工程手册里可以提炼出几个文体特征明确对象和前提条件先说明这是哪个机型、什么状态下适用。步骤是命令式动作直接写“拆卸盖板螺丝”“拔出保险销”而不是“需要对盖板螺丝进行拆卸处理”。每个动作都有验收标准拆完要检查什么锁紧要达到多少扭矩间隙不能超过多少。状态是具体的写“液压油位低于最低刻度线”不写“液压油量不足”。警告、注意、提示分级清楚哪些操作会伤到人哪些会损坏设备哪些只是提醒。为什么强调“1986年”这个年份因为那个年代没有算法辅助生成手册是工程师一句一句写出来的。它必须能经得起实际维修场景的检验用词必须准确到不会产生歧义。放在今天看它反而成了对抗AI废话的绝佳标本。这套风格用一个通用例子来演示故障现象主起落架收放速度变慢收起时间超过 8 秒。状态检查查看主液压系统压力表确认压力是否在 2800 至 3000 psi 区间。处理步骤若压力低于 2800 psi检查液压泵出口滤芯是否堵塞。若滤芯污染按维护手册第 5 节更换并记录更换时间。压力正常后地面作动收放三次观察锁定时间是否低于 5 秒。验收标准连续三次收起时间不超过 5 秒且目视确认机械锁到位。这个例子是通用写法不代表任何真实机型。你会发现哪怕完全不懂飞机读这段文字也能知道“该看什么、该做什么、做完怎么算成功”。这就是技术写作最缺的东西。4. 把手册文体转成 Anti-Slop 写作框架从飞机维修手册里提炼出的风格可以固化成四条写作规则。这四条规则就是 Anti-Slop Skill 的核心。4.1 规则一删掉形容词写状态量“性能明显下降”“稳定性较差”“响应变慢”这类话在技术文档里没有意义因为每个读者对“明显”的理解不同。正确的做法是写可测量的状态量。改前系统性能明显下降。改后接口平均响应时间从 120ms 上升到 850ms错误率从 0.1% 上升到 5.2%。我平时要求AI写内容时会强制它把每个抽象词替换成“指标 数值 对比对象”。如果AI说没有数据那就让它写“需要补充监控数据”而不是强行编造。4.2 规则二用条件分支替代泛泛建议手册里永远不会写“请妥善处理”而是写“如果出现X则做Y如果出现Z则做W”。这种条件分支结构让读者能在错误发生时快速定位。改前建议关注系统资源使用情况。改后若 CPU 占用连续 5 分钟超过 90%检查是否有死循环任务若内存占用超过 80% 且持续增长优先抓取堆栈信息后再重启服务。条件分支的好处是它把“知识”变成了“决策表”读者不需要自己推断。4.3 规则三命令式步骤替代说明式段落很多AI写的教程喜欢用“我们需要对配置文件进行修改以实现端口变更”这种句子应该直接改成“修改 config.yaml 中的 port 字段改为 7861”。具体操作步骤的粒度要控制到“每一行只包含一个动作”。动作之间不要插解释解释可以放到步骤后面的“说明”里或者干脆删掉。4.4 规则四每个章节给验收标准手册的每个维修流程结尾都有验收标准。放到技术文章里就是读者做完你的步骤后怎么判断自己有没有成功。验收标准写浏览器访问 http://127.0.0.1:7861页面正常返回控制台无红色报错日志。不写服务应该能正常启动。有了验收标准文档就具备可测试性这也是技术文章和散文最本质的区别。5. 提示词模板给 AI 注入手册风格规则本身不能自动改变AI的输出你需要把它写进提示词模板。下面这套模板是我目前在用的 Anti-Slop 通用模板可以直接复制到任意LLM对话里。从现在开始你是一名工程文档评审与改写专家。请把输入内容改写成“飞机维修手册”风格。 严格遵守以下规则 1. 词汇层 - 删除并替换这些词delve、tapestry、testament、优化、赋能、抓手、闭环、颗粒度、值得注意的是、需要注意的是、总而言之、综上所述。 - 所有抽象描述必须替换为可观察的状态量例如“性能下降”改为“响应时间从120ms上升到850ms”。 2. 句子层 - 禁止使用“为了……需要……”这种万能句式。 - 每句话只能表达三种内容状态描述、动作指令、判断条件。 3. 段落层 - 每个小节先写前提条件再写操作步骤最后写验收标准。 - 如果某段无法给出验收标准直接删除该段。 4. 结构层 - 标题只能使用以下词汇故障现象、状态检查、处理步骤、验收标准、注意事项。 - 不允许自行创造其他标题。 5. 输出格式 - 只输出改写后的正文。 - 不要解释修改原因。 - 不要输出“好的”“以下是改写结果”之类的开头。使用方式很简单把原来的AI生成内容粘贴到这个模板后面让模型重新输出。如果是批量处理可以写一个简单的循环脚本把模板和正文拼接后逐个请求模型API。我建议把模板里的“禁用词列表”单独拆出来维护因为不同团队的黑名单不一样。比如国内团队可能更在意“赋能”“抓手”海外团队更在意“delve”“tapestry”。词表越贴合自己的领域效果越好。6. 效果对比改造前 vs 改造后看模板不如看实例。下面我把一个很常见的开发主题“本地服务端口被占用”分别用AI味写法和手册风格写法跑一遍再说明关键差异。6.1 改造前典型 AI Slop 写法在本地开发中端口冲突是经常遇到的问题它可能导致服务无法正常启动从而影响整体开发效率增加不必要的排查成本。为了解决这一痛点我们可以通过灵活配置端口参数来优化。首先我们需要检查当前端口的使用情况确保资源分配的合理性。然后根据检查结果决定是否需要更换端口。最后重新启动服务验证问题是否解决。这段文字每一句话都对但读完之后你依然不知道要敲哪条命令。6.2 改造后手册风格写法故障现象启动服务时提示 Port 7860 is already in use。状态检查在终端执行 netstat -ano | findstr 7860记录占用 7860 端口的进程 PID。处理步骤若占用进程属于当前用户可停止的进程执行 taskkill /PID /F 强制结束。若占用进程属于系统进程或不允许结束的进程打开 config.yaml修改 port 字段为 7861。保存文件并重启服务。访问 http://127.0.0.1:7861 验证返回状态。验收标准连续访问 10 次HTTP 状态码全部为 200无 Connection refused。差异点非常清楚改造前写“检查当前端口使用情况”改造后直接给出netstat命令。改造前写“根据检查结果决定是否更换端口”改造后给条件分支可停进程走终止流程不可停进程走改端口流程。改造前写“验证问题是否解决”改造后写“连续访问10次状态码全部200”。再举一个项目周报场景改造前本周我们重点推进了系统优化工作提升了平台的稳定性和用户体验。改造后本周完成登录模块超时重试逻辑。线上登录超时率从 2.1% 降至 0.6%。验收方法通过压测脚本连续运行 30 分钟无超时告警。周报改成这样之后领导不看过程也能知道结果团队复盘时还能直接拿验收方法当回归测试用例。7. 验证方法检测 “AI 味” 是否还残留AI改写完之后还要过一道检查。我一般用两层验证关键词脚本和人工执行测试。7.1 关键词检测脚本下面这个Python脚本可以统计一篇文档里AI高频词出现次数适合在文章发布前跑一遍。import re from pathlib import Path AI_WORDS [ delve, tapestry, testament, landscape, realm, 优化, 赋能, 抓手, 闭环, 颗粒度, 值得注意的是, 需要注意的是, 总而言之, 综上所述, 首先, 然后, 最后, ] def detect_slop(text_path: str) - dict: text Path(text_path).read_text(encodingutf-8, errorsignore) hits {} for word in AI_WORDS: count len(re.findall(word, text, flagsre.IGNORECASE)) if count: hits[word] count return hits if __name__ __main__: import sys result detect_slop(sys.argv[1]) if result: print(检测到AI高频词) for word, count in result.items(): print(f {word}: {count} 次) else: print(未检测到明显AI高频词。)使用方法python detect_slop.py article.md这个脚本只是第一道筛子能拦住明显的词汇级问题拦不住句式级和结构级问题所以还要做人工验证。7.2 人工执行测试找一位不熟悉这个主题的人让他完全照着你的文档操作一遍看他卡在哪一步。如果他在某一步停下来问你“这个文件在哪”“这条命令去哪执行”说明文档的“状态检查”和“处理步骤”还是不够具体。这个方法借鉴的是飞机维修手册的验收逻辑文档是否合格不看写得好不好看执行者能否一次性完成操作。8. 常见问题与排查方法用这套方法时会遇到一些比较典型的问题我把排查思路整理成表问题现象可能原因排查方式解决方案AI 改完还是很空提示词只限制了词汇没限制句式和结构检查输出中是否还有“为了……需要……”句式在模板里增加“每句话只能表达状态、动作、判断条件”改完太干像流水账步骤粒度太粗缺少解释让不了解背景的人试读在步骤后补充“说明”小节解释技术原理风格太冷没有上下文手册风格完全取代了背景介绍对比内容类型保留第一段背景介绍正文进入故障现象AI 不遵守禁用词列表上下文太长规则被后来的内容淹没查看输出里哪些词还在新开对话把模板放最前面正文放后面没有数据可写内容本身没有可量化指标检查日志、监控、压测报告先补监控数据再写文档不要编造数字批量改写时结果不稳定每个请求的上下文长度不同固定模板顺序和字数上限拆成小批量单次最多处理一个章节第5条特别提醒一下如果你自己的业务没有监控数据AI瞎编一个“响应时间从120ms升到850ms”出来比写“性能下降”危害更大。修改后的文档里出现的每个数字都必须能从日志或监控里查到查不到就写“需补充监控数据”。9. 最佳实践与适用边界Anti-Slop Skill 不是万能文体它适合的目的是“让读者完成任务”不适合“让读者产生情绪”。所以在实际使用中要分清边界。适合使用手册风格的场景故障排查文档、错误码说明。API 接入文档、参数对照表。项目周报、验收报告、复盘文档。团队内部知识库、新人上手文档。代码注释里的“为什么这么做”。不建议使用手册风格的场景产品营销页需要情绪和故事。技术分享的开场白可以先用故事讲清楚问题再进入操作步骤。课程脚本和教学叙事需要节奏和悬念手册式写法会让读者流失。工程化方面我建议把整套规则沉淀成三份资产提示词模板统一放在团队的资料库里。禁用词表定期根据AI输出的新套路更新。检测脚本直接在CI流程里跑文章合并前拦截AI味。另外要注意合规边界。反AI味的过程本质上是让AI辅助你更清楚地整理自己的知识和操作流程。涉及代码、配置、数据指标时不要编造参数和结果。涉及其他人编写的文档、代码或维修资料要保留引用和版权信息。商用场景下AI生成的文字也要经过人工复核确认没有虚假技术信息和隐私泄露。10. 总结与下一步这个标题最值得尝试的点是把“飞机维修手册”这种极致工程文体当成提示词约束让AI从“写得像篇作文”切换到“写得像份施工图”。不需要换模型不需要加硬件只改提示词规则效果立竿见影。建议你先做一个小实验拿自己最近写的一篇技术博客或一份接口文档用第5节的模板跑一遍再用第7节的脚本检查一遍看看删掉多少废话、改出多少明确步骤。通常第一次就能发现大量“为了……需要……”句式。最容易踩的坑是只加关键词黑名单不约束段落结构。只换词不换骨架AI照样能写出格式工整但没有操作价值的文字。正确的做法是把词汇、句式、段落结构、验收标准四层一起约束。后续可以继续扩展的方向把模板接入团队知识库的API形成“提交文档自动扫描AI味”的流水线或者把这个思路做成IDE插件在写Markdown文档时实时提示“这句话没有可执行动作”。方法本身不难难的是每次写作都坚持用验收标准收尾。养成这个习惯之后你再看AI写的东西会明显觉得它“听话了不少”。