我们用双模型流水线，把内容团队的废稿率降了一半

选题会开到一半，有人翻出三个月前的一篇稿子——和今天刚提的选题几乎一模一样。

全场沉默了五秒。

然后主编说："这个我们写过了。"提选题的编辑翻了翻历史文档，确认了，确实写过，而且那篇的数据还不错。这五秒钟的沉默，我们团队每周至少经历两次。

如果你带过内容团队，应该对这个场景很熟悉。问题不是编辑不努力，而是历史文章库越来越大，人工去重的边际成本越来越高。我们团队5个人，历史文章库超过800篇，靠人力在选题会前完成全量比对，基本是不可能的事。

这篇文章记录的，是我们用3个月时间搭出来的一套双模型去重流水线，以及这套方案背后所有没写进PPT的踩坑细节。

---

第一章：我们到底在重复选题上浪费了多少时间？

在动手做方案之前，我们先做了一次内部统计，结果比预想的难看。

• 每次选题会前，每位编辑平均花 40-60分钟 手动翻历史文档做比对
• 每月平均出现 4-6篇 因为选题重复或高度相似导致的废稿（写完了才发现）
• 废稿的平均返工成本：从重新选题到重新交稿，平均耗时 1.5个工作日
• 团队5人，月均因重复选题损耗的有效工时约 30-40小时

最让人崩溃的不是废稿本身，而是废稿发现的时机——通常是稿子写完、甚至排版完成之后，审稿环节才发现"这个角度我们三个月前写过"。这时候的沉没成本已经很高了。

"我不是不知道要查历史文章，但每次打开那个800篇的Excel，我就不知道从哪里开始搜。"——团队编辑，匿名

这是一个典型的信息检索效率问题，人力解决的天花板很低，适合用AI来做。

---

第二章：方案设计——为什么要"拆开"两个模型来用？

想清楚这个问题，是整个方案最重要的一步。

最直觉的方案是：把所有新选题都丢给Claude，让它判断是否重复。 听起来简单，但算一下成本就知道不现实——如果每个新选题都要和历史库里800篇文章做语义比对，每次选题会可能要处理10-15个新提案，这个调用量和token消耗会很快失控。

我们的核心设计思路是：让便宜的模型做粗筛，让贵的模型做精加工。

具体来说：

• GPT-4.1-mini：速度快、价格低，用来做向量相似度的初步打分，快速过滤掉明显不重复的选题，只把"高风险"的疑似重复案例标记出来
• Claude Sonnet 4.6：语义理解能力强、输出有解释性，只处理mini模型标记的高风险案例，给出详细的"是否重复"判断和理由

这套逻辑的本质是一个漏斗：

新选题输入（10-15条）
↓
GPT-4.1-mini 粗筛
（相似度打分，过滤掉明显不重复的）
↓
高风险选题（通常2-4条）
↓
Claude 精审
（语义摘要 + 是否重复 + 建议）
↓
输出去重报告（结构化JSON）

如果全程用Claude处理：假设每次选题会15个提案，每个提案对比800篇历史文章摘要，token消耗相当可观，月度API费用估算会是纯mini方案的 8-12倍。

用双模型漏斗之后，Claude只需要处理mini标记的高风险案例（通常不超过4条），成本结构完全不同。

---

第三章：落地实现——代码、Prompt和踩过的坑

3.1 核心代码：用8848AI统一接口切换两个模型

我们用的是 [8848AI](https://api.884819.xyz) 的统一接口，好处是同一套代码可以无缝切换 GPT-4.1-mini 和 Claude，不用管两家平台的鉴权差异。下面的代码直接可以跑：

from openai import OpenAI

通过 8848AI 统一接口调用，base_url 替换即可切换模型
文档地址：api.884819.xyz
client = OpenAI(
base_url="https://api.884819.xyz/v1",
api_key="your_key_here"
)

def mini_similarity_check(new_topic: str, history_summaries: list[str]) -> list[dict]:
"""
用 GPT-4.1-mini 做粗筛：给新选题和历史摘要列表打相似度分
返回相似度 > 阈值的历史条目
"""
prompt = f"""你是一个内容去重助手。
新选题：{new_topic}

以下是历史文章摘要列表，请为每条打一个0-10的相似度分数（10=完全相同，0=完全无关）。
只返回JSON数组，格式：[{{"id": "文章ID", "score": 分数}}]

历史摘要：
{chr(10).join([f"[{i}] {s}" for i, s in enumerate(history_summaries)])}
"""
response = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{"role": "user", "content": prompt}],
temperature=0
)
return response.choices[0].message.content


def claude_deep_review(new_topic: str, flagged_articles: list[dict]) -> dict:
"""
用 Claude 对高风险选题做精审，输出结构化判断
"""
response = client.chat.completions.create(
model="claude-sonnet-4-6",  # 通过8848AI接口调用Claude
messages=[{"role": "user", "content": build_claude_prompt(new_topic, flagged_articles)}],
temperature=0.2
)
return response.choices[0].message.content

3.2 Claude的摘要Prompt——稳定输出结构化JSON的关键

这个Prompt调了将近两周才稳定下来，直接给你：

你是一位资深内容编辑，负责判断新选题是否与历史文章重复。

新选题
{{new_topic}}

疑似重复的历史文章
{{flagged_articles_json}}

你的任务
1. 分析新选题的核心角度、目标读者、主要论点
2. 对比每篇历史文章，判断是否构成"实质性重复"
3. 给出明确结论和理由

输出格式（严格按此JSON输出，不要有任何额外文字）
{
"verdict": "重复" | "相似但可写" | "不重复",
"confidence": 0-100,
"reason": "一句话说明判断依据",
"overlapping_articles": ["文章ID1", "文章ID2"],
"suggestion": "如果是'相似但可写'，给出差异化角度建议；否则留空字符串"
}

判断标准
"重复"：核心角度和主要论点高度一致，读者读了新稿不会获得新信息
"相似但可写"：话题相关，但切入角度、目标读者或时效性有明显差异
"不重复"：话题不同或角度完全不同

关键细节：verdict 字段设计了三个值而不是两个，这是经过实践验证的。最初只有"重复/不重复"，导致很多边界案例被Claude判成"重复"直接丢掉，损失了一批可以写的好选题。加入"相似但可写"这个中间态之后，编辑的接受度大幅提升。

3.3 三个真实踩坑记录

最开始我们把mini的粗筛阈值设在6分（满分10），结果Claude那边要处理的高风险案例太多，成本没降下来。调到7分，又出现漏判——一些真正重复的选题被mini直接放过了。

最终的解法是动态阈值：对于标题长度超过15字的选题，阈值设7；短标题（少于10字）阈值设5。因为短标题的语义信息密度低，mini容易打低分，需要更宽松的阈值来保证召回。

有一次新选题是《Cursor使用技巧》，历史库里有一篇《给程序员的AI编程工具对比》，Claude判了"相似但可写"，建议从"非程序员视角"切入。

这个判断其实没错，但问题在于：短标题给Claude的信息太少了，它只能靠标题猜意图，猜错的概率很高。

解法：在送给Claude之前，强制要求编辑补充一段50字以内的"选题意图说明"，作为prompt的补充上下文。这个改动把Claude的准确率明显提升了。

刚上线的时候，历史摘要库是空的，mini没有任何历史数据可以对比，流水线形同虚设。

我们用了一个"笨办法"：花了两天时间，用Claude批量处理了历史库里的800篇文章，每篇生成一条100字以内的结构化摘要，存进数据库。这是一次性的冷启动成本，之后每发布一篇新文章，自动追加摘要即可。

这两天的批量处理API费用，是整个项目前期最大的一笔支出——但只花一次，后续边际成本接近零。

---

第四章：3个月效果复盘——数据说话

流水线稳定运行3个月后，我们做了一次完整复盘。

前后对比数据

ROI怎么算？

给你一个可以直接套用的估算公式：

月节省成本 = (废稿减少数 × 人均返工时长 × 时薪) - API月费

以我们团队为例：
= (4篇 × 12小时 × 80元/小时) - 200元
= 3840元 - 200元
= 约3640元/月

这里的"时薪"按编辑的综合时间成本估算，不同团队可以代入自己的数字。对于大多数内容团队来说，API成本在整个节省成本里的占比不超过10%，ROI相当清晰。

"以前选题会我最怕被问'这个写过没有'，现在开会前看一眼报告，心里有底了。"——团队编辑，匿名

---

第五章：适用边界——什么团队该复制这套方案？

• 历史文章库 超过200篇 以上，人工检索已经开始吃力
• 团队有固定的选题会节奏（每周至少一次）
• 团队中有人能跑Python脚本，或者愿意花半天学（代码复杂度不高）
• 内容方向相对聚焦，历史摘要库的语义密度足够高

• 文章库体量小于100篇——这个量级人工检索完全够用，引入AI是杀鸡用牛刀
• 内容方向极度泛化（什么都写）——历史摘要的语义空间太分散，mini的相似度打分会很不稳定
• 团队完全没有技术背景，且没有预算请人部署——这套方案需要一定的初始配置成本

1. 接入向量数据库（如Chroma或Pinecone）：目前历史摘要是存在普通数据库里做文本匹配，换成embedding向量检索后，mini粗筛的准确率可以进一步提升

2. 自动化触发钩子：目前还是手动跑脚本，理想状态是编辑在飞书/Notion提交选题时自动触发去重检查，结果直接回传到文档里

3. 摘要质量迭代：随着历史库增长，定期用Claude重新生成摘要，保持摘要的信息密度

---

现在你可以做什么？

如果你看完觉得"这套方案值得试"，最小可行版本只需要三步：

1. 去 [api.884819.xyz](https://api.884819.xyz) 开个账号，新用户注册即送体验token，GPT-4.1-mini 的价格低到可以当"粗筛机器"用，国产模型（Deepseek/千问）完全免费，没有月租

2. 整理你们的历史文章库，哪怕是一个Excel，把标题和摘要整理出来，这是最重要的数据基础

3. 跑一次冷启动：用上面的Claude prompt，批量给历史文章生成摘要，存起来——这一步做完，流水线的核心数据就有了

不需要一步到位，先把历史摘要库建好，其他的可以慢慢迭代。

---

这套流水线跑了3个月之后，我们发现了一个意外收获：Claude在写摘要时，偶尔会给出一些"这个选题可以从哪个角度写会更新颖"的建议——完全是prompt里没有要求的。

这让我们开始想：能不能反过来，让AI主动推荐选题，而不只是被动去重？

下一篇我打算写这个：用Claude做内容团队的"选题顾问"——从去重到主动生成差异化选题方向，踩了哪些新坑。

感兴趣的话，关注一下，更新会比你想象的快。

---

#AI工作流 #内容团队 #GPT #Claude #8848AI #API实战 #降本增效 #Prompt技巧