AI辅助写作如何避免AI slop？流程控制与质量校验实战

这次我们不聊某个具体的模型权重，也不看某个一键包，而是讨论一个所有用 AI 写技术文章、写代码注释、写产品文案的人都绕不开的问题：AI-assisted writing 和 AI slop 的分界线到底在哪里。

先说结论：AI 辅助写作不是原罪，AI slop 才是。同样的 LLM，有人拿它当搜索引擎加强版，三分钟拼出一篇没有信息来源、没有观点、没有验证步骤的“伪干货”；有人拿它当初稿生成器，再花一小时补充真实数据、跑通代码、修正逻辑，最终产出一篇可以给团队当文档用的内容。两者的差异不在模型，而在流程控制。

这篇文章会把“AI 辅助写作”拆成可执行的技术环节：提示词设计、上下文注入、输出约束、人工校验、质量评分。同时给出识别 AI slop 的检查清单，以及一套可以落地的写作工作流，附带 Python/API 调用示例和批量生成时的质量控制策略。适合用 AI 写技术文章、写周报、写接口文档、写营销文案的开发者阅读。

1. 核心能力速览

一句话总结：这套方法解决的不是“能不能生成”，而是“生成之后怎么保证它不是 AI slop”。

2. 适用场景与使用边界

2.1 AI 辅助写作的合理场景

• 技术博文初稿：给 LLM 提供代码片段、运行日志、API 文档，让它先整理结构，再由作者补齐验证过程和踩坑记录。
• 接口文档生成：根据 OpenAPI Schema 或代码注释生成字段说明。
• 知识库结构化：把零散笔记改写成问答对或条目式说明。
• 多语言翻译润色：保留术语表的前提下进行翻译。
• 日常邮件和周报：先写要点，让 AI 扩展成通顺表达，人工确认事实。

2.2 什么内容不该扔给 AI

• 需要精确到版本号、日期、价格、统计数据的段落，AI 容易“自信地编造”。
• 涉及个人隐私、未公开业务数据的内容，不要把原始数据直接发给第三方 API。
• 需要承担法律或医疗责任的内容。
• 需要作者独立观点和经验判断的段落，比如“这个框架为什么不适合我们团队”。

2.3 合规与边界提醒

使用任何 AI 写作工具前，先确认：

• 你是否有权使用输入素材？源码、客户截图、内部文档是否涉及保密协议？
• 生成内容是否会被搜索引擎收录？如果会，需要避免无信息量的重复内容。
• 是否涉及肖像、声音、版权素材？是，则必须先取得授权。
• 是否对外发布？发布前要做事实核查和人工复核。

3. 环境准备与前置条件

如果你走 API 方案，环境准备非常简单：

如果你走本地模型方案，比如部署 Qwen、DeepSeek、Llama 这类开源模型，需要额外关注：

• GPU 显存至少 6G 到 12G，具体看量化等级和上下文长度。
• 建议使用 Ollama 或 vLLM 启动，OpenAI 兼容接口方便接入统一工作流。
• 本地模型的输出质量通常弱于顶级 API 模型，做质量校验时阈值要放宽。

不建议一上来就本地部署。先用 API 方案把工作流跑通，再根据内容敏感程度决定是否换成本地模型。

4. 安装部署与启动方式

4.1 安装 Python 依赖

bash复制pip install openai python-frontmatter markdownlint-cli

这里 openai 用于调用兼容接口，python-frontmatter 用于解析 Markdown 头信息，markdownlint-cli 用于格式检查。如果只是做 API 调用演示，只需要 openai 和 requests。

4.2 最小 API 调用脚本

python复制import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ.get("LLM_API_KEY"),
    base_url=os.environ.get("LLM_BASE_URL", "https://api.openai.com/v1"),
)

def generate_draft(topic: str, outline: str, context: str) -> str:
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {
                "role": "system",
                "content": (
                    "你是一名资深技术编辑。你的任务是：\n"
                    "1. 根据用户提供的大纲和上下文素材生成初稿；\n"
                    "2. 只使用用户提供的素材，不编造数据；\n"
                    "3. 在信息不足时明确写『此处需要补充素材』；\n"
                    "4. 输出 Markdown 格式，代码块要标注语言。"
                ),
            },
            {
                "role": "user",
                "content": (
                    f"主题：{topic}\n\n"
                    f"大纲：{outline}\n\n"
                    f"可用素材：{context}\n\n"
                    f"请按照大纲生成初稿。"
                ),
            },
        ],
        temperature=0.3,
    )
    return response.choices[0].message.content

if __name__ == "__main__":
    draft = generate_draft(
        topic="本地部署 TTS 模型",
        outline="1. 功能概述；2. 环境要求；3. 部署步骤；4. 测试",
        context="模型名：ChatTTS；支持 Windows；GPU 显存 4G 可跑",
    )
    print(draft)

这段代码的关键点有三个：

• temperature=0.3 降低随机性，减少“看起来合理但实际错误”的内容。
• system 提示词里明确要求“不编造数据”，虽然不能完全阻止幻觉，但能降低概率。
• 输出格式强制 Markdown，方便后续接入格式检查工具。

4.3 批量生成脚本

批量生成时最容易出 AI slop —— 因为没有人逐个校验。建议不要把 50 篇文章一次性全量生成，而是分段处理。

bash复制python batch_generate.py --topics ./topics.txt --output ./drafts/

批量脚本内部需要做三件事：

1. 每个任务独立上下文，不共享素材。
2. 生成后立即跑格式检查和基础质量评分。
3. 低分内容单独放入 review/ 目录，不进入成品目录。

python复制import json
import time
from pathlib import Path

from openai import OpenAI

client = OpenAI(
    api_key=os.environ.get("LLM_API_KEY"),
    base_url=os.environ.get("LLM_BASE_URL"),
)

def generate_article(topic: str, source: str) -> str:
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {
                "role": "system",
                "content": (
                    "写一篇技术说明文。要求：\n"
                    "1. 只使用提供的素材；\n"
                    "2. 每段必须有实际信息，不得写空话；\n"
                    "3. 包含至少一个可执行命令；\n"
                    "4. 结尾不要写总结性套话。"
                ),
            },
            {
                "role": "user",
                "content": f"主题：{topic}\n素材：{source}",
            },
        ],
        temperature=0.4,
        max_tokens=800,
    )
    return resp.choices[0].message.content

def quality_score(text: str) -> float:
    # 从材料看，如果一段文字缺少技术关键词，则判定为信息密度偏低
    density_keywords = ["安装", "配置", "命令", "接口", "显存", "依赖", "端口", "错误", "日志"]
    hits = sum(1 for word in density_keywords if word in text)
    return hits / len(density_keywords)

def main():
    topics_path = Path("./topics.txt")
    output_dir = Path("./drafts")
    review_dir = Path("./drafts/review")
    output_dir.mkdir(exist_ok=True)
    review_dir.mkdir(exist_ok=True)

    with topics_path.open("r", encoding="utf-8") as f:
        for line in f:
            topic = line.strip()
            if not topic:
                continue
            article = generate_article(topic, topic)
            score = quality_score(article)
            target = output_dir if score >= 0.5 else review_dir
            slug = topic.replace(" ", "_")[:30]
            (target / f"{slug}.md").write_text(article, encoding="utf-8")
            print(f"{topic}: score={score:.2f} -> {target.name}")
            time.sleep(1)  # 限流，避免触发 API 频率限制

if __name__ == "__main__":
    main()

这个演示脚本里的 quality_score 只是一个占位实现。真正可靠的质量评估需要结合人工抽查和更多维度的规则匹配，下文第 5 节会详细展开。

5. 功能测试与效果验证

5.1 单篇生成质量验证

无论模型多强，生成后都要按以下四个维度验收：

一个实际的测试流程：

bash复制# 生成初稿
python generate_draft.py --topic "使用 Docker 部署 Nginx" --output draft.md

# 检查代码块语言标注
python check_code_blocks.py draft.md

# 检查 Markdown 标题层级
npx markdownlint-cli draft.md

5.2 AI slop 识别测试

下面是一段典型的 AI slop 和一段合格 AI 辅助写作的对比。

AI slop 示例：

在当今数字化时代，技术发展日新月异，Docker 作为一种容器化技术，在实际应用中具有广泛的应用场景。通过 Docker 部署 Nginx 可以帮助企业提高效率，降低成本，实现快速迭代和敏捷交付。总之，Docker 与 Nginx 的结合是企业数字转型的重要趋势。

这段文字的问题很明显：

• 没有出现任何一条可执行命令。
• “数字化时代”“日新月异”“敏捷交付”都是空话。
• 没有具体的配置文件路径。
• 没有端口、镜像名、验证方式。

合格的 AI 辅助写作示例：

在 Ubuntu 22.04 上部署 Nginx 容器，建议先创建 nginx.conf 并映射到容器内 /etc/nginx/nginx.conf。启动命令如下：

bash复制docker run -d --name nginx-test -p 8080:80 -v $PWD/nginx.conf:/etc/nginx/nginx.conf:ro nginx:1.25-alpine

启动后检查日志：docker logs nginx-test。如果配置正确，访问 http://127.0.0.1:8080 会看到欢迎页。

两者的差异不需要 AI 来辨别，人工一眼就能分出。这也说明了一个现状：AI slop 的本质不是模型不行，而是使用流程缺失了整个“素材注入 + 人工校验”环节。

5.3 如何用脚本辅助识别 AI slop

可以写一个简单的规则脚本，把明显属于 AI slop 的短语标出来：

python复制import re

SLOP_PATTERNS = [
    r"在[^。]{0,30}时代",
    r"日新月异",
    r"综上所述",
    r"随着技术[的]?发展",
    r"为了更加?[^。]*而[^。]*",
    r"赋能",
    r"闭环",
    r"抓手",
    r"助力",
    r"推进[^。]*建设",
]

def detect_slop(text: str) -> list[str]:
    hits = []
    for pattern in SLOP_PATTERNS:
        matched = re.findall(pattern, text)
        if matched:
            hits.extend(matched)
    return hits

if __name__ == "__main__":
    sample = "随着技术的发展，为了助力企业数字化转型，综上所述需要赋能闭环。"
    print(detect_slop(sample))

运行结果会把“随着技术”“综上所述”“赋能”“闭环”都标记出来。这类规则脚本不完美，但可以作为第一道过滤器，把明显没有信息密度的文本拦截在人工审核之前。

需要注意：这类词不是绝对不能出现，而是要区分用法。“为了提升请求成功率，我们加了重试机制”是正常表述，但“为了更好的用户体验而不断优化”就是空话。规则脚本只负责标记，最终判断权在人工审稿。

6. 接口 API 与批量任务

6.1 为什么批量任务最容易产生 AI slop

单篇写作时，人能实时纠正模型输出。批量任务往往直接循环调用 API，生成后不经审稿就发布，导致低质量内容被放大。

批量任务要跑，但必须设计成分阶段流水线：

mermaid复制graph LR
    A[素材整理] --> B[初稿生成]
    B --> C[规则检查]
    C --> D[人工抽样审稿]
    D --> E[终稿发布]

注意：当前文章不支持 mermaid 图表，我在这里仅用文字描述流水线。实际工程中，建议把这四个阶段分开写脚本，不要一个脚本从头跑到尾。

6.2 API 调用最佳实践

6.3 批量任务中的上下文隔离

很多人给批量任务喂素材时图省事，把 20 篇相关的背景资料全部塞进 prompt，希望模型“理解整个知识库”。这会导致上下文过长、成本翻倍、且模型更容易把 A 素材的细节混进 B 文章里。

正确做法是：

• 每篇文章只注入与该主题强相关的 3 到 5 段素材。
• 把素材的关键信息提取成结构化字段，例如：环境、命令、端口、错误现象。
• prompt 中明确要求“未出现在字段中的信息不得使用”。

json复制{
  "topic": "部署 Nginx 容器",
  "facts": {
    "os": "Ubuntu 22.04",
    "image": "nginx:1.25-alpine",
    "port": "8080:80",
    "config": "./nginx.conf",
    "verification": "curl http://127.0.0.1:8080"
  }
}

这个 JSON 结构会直接拼进 prompt 的“可用素材”段落。它的好处是，模型没有机会从无关段落里“自由发挥”。

6.4 批量任务失败重试策略

批量调 API 时，可能出现网络超时、返回空内容、输出截断三类问题。建议增加重试逻辑：

python复制import time
from openai import OpenAI

client = OpenAI(api_key="your-key")

def call_with_retry(prompt: str, max_retries: int = 3) -> str:
    for attempt in range(max_retries):
        try:
            resp = client.chat.completions.create(
                model="gpt-4o-mini",
                messages=[{"role": "user", "content": prompt}],
                temperature=0.4,
                timeout=120,
            )
            content = resp.choices[0].message.content
            if content and len(content.strip()) > 50:
                return content
            raise ValueError("empty output")
        except Exception as e:
            print(f"attempt {attempt + 1} failed: {e}")
            time.sleep(2 ** attempt)
    raise RuntimeError("all retries failed")

重试策略的要点：

• 指数退避，避免连续快速重试触发限流。
• 要求返回内容长度大于 50 字符，过滤“空回复”类故障。
• 重试次数控制在 3 次以内，超过后进入人工处理队列，而不是无限重试。

7. 资源占用与性能观察

7.1 API 方案的性能观察

API 方案的资源占用几乎可以忽略，主要观察三个指标：

• 单次请求耗时：多数主流 API 在输出 800 字左右时，耗时约 20 到 60 秒。
• 成本：按 token 计费，批量生成时需要先估算总 token 数。
• 限流：高并发调用会收到 429 错误，可通过请求日志观察。

一个实用的排查思路：

bash复制# 记录每次请求的耗时和 token 数，写入日志文件
python api_profiler.py --prompt "写一段关于显存占用的说明" --output profile.log

日志中至少应包含时间戳、模型名、请求耗时、返回 token 数、是否重试。后续可以根据日志调整并发数和超时时间。

7.2 本地模型的资源占用

如果使用本地模型，显存占用和推理速度是重点。以常见的中等参数模型为例：

• 7B 模型量化后，显存占用约 4G 到 6G。
• 13B 模型量化后，需要 8G 到 12G 显存。
• 生成速度受显存带宽影响，通常为每秒 10 到 30 token。

实际占用数字一定要以本机测试为准。文章写作类任务对速度不敏感，但批量任务要特别确认：如果本地模型一分钟才生成几百字，跑 50 篇文章可能需要数小时，这时更要依赖 API 方案或分布式推理。

7.3 如何降低生成成本

8. 常见问题与排查方法

8.1 判断“能不能发布”的三个闸门

在字符级规则之上，真正有效的过滤需要三重闸门。

第一道闸门，自动规则检查：跑代码块语言检查、标题层级检查、AI slop 短语过滤。这部分可以全自动。

第二道闸门，人工抽查：批量任务至少抽取 30% 逐篇阅读，重点看事实型字段和命令是否可以复现。

第三道闸门，用户反馈：发布后关注评论和点击数据。如果点击很高但评论为零，说明标题与内容不符，是另一种形式的 slop。

9. 最佳实践与使用建议

9.1 建立“素材约束”工作流

AI 辅助写作的核心不是让模型自由发挥，而是让模型在素材边界内发挥。具体建议：

1. 写任何技术类内容前，先把已知事实整理成字段清单，比如环境版本、命令、路径、错误日志、输出截图。
2. 提示词明确声明“只能使用字段清单中的数据”。
3. 生成后先跑规则检查，再人工复核，最后发布。

这套流程放到团队协作里，可以抽象成一个配置文件：

yaml复制writing:
  model: gpt-4o-mini
  temperature: 0.4
  max_tokens: 1200
  constraints:
    - only_use_provided_facts: true
    - no_empty_conclusion: true
    - require_code_block_language: true
  human_review_ratio: 0.3

9.2 提示词模板管理

不要每次都在对话窗口手写 prompt。把经过验证的提示词模板存成文件，按任务类型分目录：

text复制prompts/
├── article_draft.md
├── api_doc.md
├── weekly_report.md
├── translation.md
└── marketing_copy.md

每个模板文件开头写清楚适用场景和约束条件。这样团队其他人也能复用同一套质量标准，不会出现同一个人有时写出高质量内容、有时写出 AI slop 的情况。

9.3 与版本管理结合

AI 生成的初稿、人工修改后的终稿、最终发布版本，要分目录保存：

text复制content/
├── drafts/        # AI 初稿
├── review/        # 人工修改稿
├── published/     # 发布终稿
└── rejected/      # 低质量弃稿

保留弃稿目录很重要。当你想知道“AI 辅助写作的边界在哪里”时，弃稿是最好的训练集。

9.4 合规与授权再强调

使用 AI 写作时，最容易忽视的两类风险：

• 如果输入素材包含他人版权内容，生成结果可能保留原表达，发布前要进行相似度检查。
• 如果生成内容涉及具体产品、公司、个人，务必确认事实和授权。尤其不建议给第三方生成人脸、声音相关的内容。

批量发布时，还建议检查搜索引擎对站点内容的收录情况，一旦出现大量相似标题，尽早暂停并调整策略。

10. 总结与下一步

AI 辅助写作和 AI slop 的界线，从来不是“用没用到 AI”，而是“有没有人负责”。工具本身不产生 slop，缺失审校流程的批量自动化才产生 slop。

建议你从三件事开始落地这套方法：

• 第一个任务是写一个属于自己的 AI slop 短语过滤器，跑一遍最近三个月生成过的文本。
• 第二个任务是把你常用的一篇技术文章转换为“素材字段 + 提示词 + 人工校验”的结构化流程。
• 第三个任务是批量生成时强制加入 30% 人工抽检制度，这是最低成本的防 slop 措施。

技术写作这件事，真实信息密度永远比字数和“流畅度”重要。AI 能帮你把结构理顺、把语言表达更干净，但“这句话对不对、这个命令能不能跑、这个版本号是否有依据”依然要落到人工。

接下来可以继续扩展的方向：在团队内部搭建一套 AI 写作评测集，用同一批主题对比不同模型、不同提示词策略的输出质量，把它当成一个持续优化的基准任务。这才是 AI 辅助写作走到工程化之后更值钱的部分。