上周运营组扔过来270篇历史旧稿要求3天内改完过平台原创校验我头直接大了一圈。之前手动改个十几篇我还能摸鱼做完这次量翻了十几倍硬扛肯定不现实。前后花了一天半搭完这套自动化的自媒体批量改写流水线踩了一堆之前没注意到的暗坑整理出来给大家参考。最开始的第一版方案我图省事直接整文喂给大模型加改写指令以为十几行代码就能搞定。结果跑完全部270篇拿样稿去平台测直接给我返回个“内容原创度得分32AI生成占比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_allFalse) # 省略句向量相似度计算逻辑核心是保证切分后语义连贯 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(contentchunk_content) resp llm_client.chat.completions.create( modelgpt-3.5-turbo, messages[{role:user, content: prompt}], temperature0.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库上运营后续再有类似的批量需求自己上传文件点个运行就行不用再跑到我工位旁边站着等我出结果。