企业官网建设流程全解析

看到“A 1986 Aircraft Manual Fixed My Anti-Slop Skill”这个标题的时候，我第一反应是：这下好了，AI写作问题的解药，竟然藏在一份几十年前的飞机维修手册里。翻译过来就是：一份1986年的飞机维修手册，把我的“反AI味”能力修好了。

这件事对经常写技术文章、接口文档、README、周报的开发者很有参考价值。今天不聊模型部署，不聊显存占用，只聊一套能直接落地的写作控制方法：把飞机维修手册的文体规则，注入到AI提示词里，让AI生成的内容从“云里雾里”变成“照着做就行”。文章后面会给可复制的提示词模板、改造前后的对照案例，还有一套检测AI味残留的脚本。

先说结论：这个思路完全不需要额外硬件，不挑显卡，不挑模型，任何能跑提示词的本地或在线LLM都能用。你只需要改一套提示词模板，再加一个关键词黑名单。下面进入正题。

1. 核心能力速览

这一套“Anti-Slop Skill”本质上是提示词工程和写作规范的组合，不是某个具体软件。先把能力项整理成一张表：

这个技能和传统意义上的“本地部署项目”不一样，它不改变你的运行环境，只改变你要求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 区间。

处理步骤：

1. 若压力低于 2800 psi，检查液压泵出口滤芯是否堵塞。
2. 若滤芯污染，按维护手册第 5 节更换，并记录更换时间。
3. 压力正常后，地面作动收放三次，观察锁定时间是否低于 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。

处理步骤：

1. 若占用进程属于当前用户可停止的进程，执行 taskkill /PID /F 强制结束。
2. 若占用进程属于系统进程或不允许结束的进程，打开 config.yaml，修改 port 字段为 7861。
3. 保存文件并重启服务。
4. 访问 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(encoding="utf-8", errors="ignore") hits = {} for word in AI_WORDS: count = len(re.findall(word, text, flags=re.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. 常见问题与排查方法

用这套方法时，会遇到一些比较典型的问题，我把排查思路整理成表：

第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写的东西，会明显觉得它“听话了不少”。