上周运营组扔过来270篇历史旧稿，要求3天内改完过平台原创校验，我头直接大了一圈。
之前手动改个十几篇我还能摸鱼做完，这次量翻了十几倍，硬扛肯定不现实。前后花了一天半搭完这套自动化的自媒体批量改写流水线，踩了一堆之前没注意到的暗坑，整理出来给大家参考。
最开始的第一版方案我图省事，直接整文喂给大模型加改写指令，以为十几行代码就能搞定。结果跑完全部270篇，拿样稿去平台测，直接给我返回个“内容原创度得分32，AI生成占比78，不予通过原创标签申请”的报错。
我当时第一反应是prompt写得不够细，熬了俩小时往提示词里堆要求，什么“全文语序全部重排”“所有专有名词以外的词汇尽量替换成同义表述”“绝对不能出现和原文连续10字重复的内容”，自我感觉写得相当周全。
结果跑出来的样稿更离谱，原文里清清楚楚的“2023年短视频行业GMV破3万亿”，被大模型改成“2023年短视领域的总流水额度超过三万个亿左右”，核心数据直接出错，拿给运营看直接给我打回来返工，说这稿子发出去要被用户骂死。
分层策略在自媒体内容批量改写中的核心作用
踩完这俩坑我才反应过来，直接把几千字的长文整坨扔给大模型，本质就是开盲盒。大模型连上下文都捋不明白，怎么可能不出错？核心思路得改，从整文改写改成先切片再分类型处理。
第一步先做语义切片，不能按句号硬切，要按段落的语义单元拆分，每段切出来的内容控制在300字以内，确保每个片段只承载单一信息，不会同时混数据、案例、观点三种内容。
import jieba from sklearn.feature_extraction.text import CountVectorizer def semantic_slice(content: str, max_len: int = 300) -> list: # 先按原生段落拆分 raw_paragraphs = [p.strip() for p in content.split("\n") if p.strip()] slices = [] current_slice = "" for para in raw_paragraphs: # 短段落直接加入当前切片 if len(current_slice) + len(para) < max_len: current_slice += para + "\n" continue # 超长度的段落按句向量相似度切分 sentences = jieba.cut(para, cut_all=False) # 省略句向量相似度计算逻辑，核心是保证切分后语义连贯 if current_slice: slices.append(current_slice.strip()) current_slice = para if current_slice: slices.append(current_slice.strip()) return slices这个逻辑跑出来的切片，每一块的信息边界都很清晰，不会出现前半段讲A后半段跳B的情况，大模型处理的时候上下文压力直接减了80%，几乎不会出现之前那种改着改着丢信息的问题。
第二步是做改写策略的路由，这也是很少有人提的细节——不同类型的内容，根本不能用同一套改写规则。我把切片自动分类成数据类、观点类、故事类三个大类，分别对应不同的prompt指令，完全不用靠大模型自己发挥。
PROMPT_ROUTER = { "data": "你是内容改写员，仅对给定片段做改写，严格保留所有数值、专有名词，仅调整语序、替换不同的数值表述方式，输出不能超过原文1.2倍长度：{content}", "opinion": "你是内容改写员，仅对给定片段做改写，保留核心论点，调整论证顺序，替换相似的佐证案例表述，不能改变核心观点：{content}", "story": "你是内容改写员，仅对给定片段做改写，转换叙事视角，补充2-3句无关紧要的细节描写，让内容更口语化：{content}" } def rewrite_chunk(chunk_content: str, chunk_type: str, llm_client) -> str: prompt = PROMPT_ROUTER[chunk_type].format(content=chunk_content) resp = llm_client.chat.completions.create( model="gpt-3.5-turbo", messages=[{"role":"user", "content": prompt}], temperature=0.7 ) return resp.choices[0].message.content.strip()改完之后把切片按原来的顺序拼回去，就能得到完整的初版改写稿。用这套逻辑跑，再也没出现过把3万亿改成三万个亿的离谱错误，样稿拿给运营看，核心信息100%保留，完全看不出机器硬改的痕迹。
接下来就得做本地初筛，我专门写了三层校验逻辑，没必要啥稿子都往外送浪费时间。第一层用difflib对比改写稿和原文的字符重合度，重合度高于40%直接打回重写；第二层跑本地7B参数的小检测模型，AI生成占比超过30%直接丢回队列重新改写；第三层用正则扫一遍所有数字、专有名词的位置，确认没有被改写乱改。
改写完之后我习惯性地丢到团象AI检测里跑一遍，确认检测率降到阈值以下再往下走。
初筛完的稿子，我还加了个1/20的随机抽检机制，抽中的稿子走人工过审，重点核对核心数据和逻辑有没有问题。之前图省事完全跳过人工校验，结果跑出来17篇大模型瞎编的不存在的用户案例，发出去铁定出事故，现在靠抽检把这部分风险直接掐灭。
当时跑任务的时候还踩了个并发的坑，我一开始图快，直接开了50个线程并发调大模型接口，结果跑了不到20分钟就收到API方的限流通知，直接给我封了2小时权限，差点耽误交付。
后来我直接换成Celery做异步任务队列，把并发数压到8以内，每批次最多跑20篇稿子，同时把所有中间改写结果全部存在Redis里，就算接口断了或者网络炸了，下次启动直接从断点续跑，完全不用从头返工。调整完之后跑完全部270篇稿子，总耗时才38分钟，比之前的50线程还快，也没再触发限流。
最后交稿的时候统计了下，这批稿子直接提交平台的过审率达到了96%，剩下的不到10篇稿子，手动改个两三处表述就顺利过审，完全没出现之前大面积被打回的情况。
之前见过很多人做自媒体批量改写，上来就找个在线工具批量导进去点运行，看起来十分钟出几百篇，最后过审的时候90%都被打回，返工的时间比你半自动化写还久，本质就是没摸透改写的底层逻辑，全靠工具瞎撞。
我已经把这套脚本打包成了带Web界面的内部小工具，放到组里的私有Git库上，运营后续再有类似的批量需求，自己上传文件点个运行就行，不用再跑到我工位旁边站着等我出结果。
