背景我为什么要搭这个身为运营经常要去对接 KOL 的征文现在基本上都是人工审核有时候稿件多的时候第一轮的机械核对是最费时间的同样的要求要在每篇稿里反复找发现问题后还要整理成达人能看懂的修改意见。所以我希望做一个自动批量审核的工具当然它不仅仅是判断“是否通过”而是在首轮审核时就把它变成可追溯的清单。这样我能导入多篇链接或直接粘贴正文工具就能先做确定性规则检查再让大模型补充我预设的规则覆盖不到的语义问题最后输出报告、逐篇批注和修改意见。当然审核标准还需要支持多元化的标准不止看错别字、语义、敏感词、隐私信息、前后逻辑一致、内容结构完整等通用的规则还需要支持针对这次稿件的特殊的稿件要求比如主题方向、字数要求、代码要求等等。最终效果图1 审核页面因为目前 KOL 收集上来的文档都是飞书文档的链接所以我做成了一个输入支持多行的飞书链接当然也是支持是手工粘贴的稿件征文的要求目前支持上传 Word、Markdown、PDF、TXT解析后仍可在页面里编辑。后端的执行逻辑是每篇稿件并行执行“拉取正文 → 规则与模型审核 → 写入报告”这样就能大大节省审核的时间。图2 Qwen3.8-max RPMTPM之前人工审核可能 5min/篇现在是 2min/单篇但是注意这是单路并发目前 qwen3.8-max 是 RPM 3万次/分钟TPM 是 500万 Token/分钟也就是说同时执行最高 3 万篇当然这只是理论上限制还需要考虑机器本人是否支持 3 万并发以及 Token 的消耗量等。稿件链接 / 粘贴正文读取正文征文要求解析为审核项规则检查Qwen3.8-Max 语义补检报告看板逐篇批注与修改意见函运营人工复核图3 审核完成图4 审核报告图5 修改意见审核结束后报告页会汇总通过、需修改、不合格、拉取失败的数量以及广告法/违禁词、品牌信息、错别字、投放要求、AI 痕迹五个维度的问题分布。单篇页面保留原文和问题卡片修改意见函可直接复制给达人。搭建过程图6 Qwen3.8-max 官方跑分最近刚刚发布了 Qwen3.8-Max看它的宣传跑分非常高迫不及待要体验一把于是我在官网购买了 TokenPlan 的 Standard 套餐目前优惠价格是 139元/月价格不便宜与 GPT Plus 价格基本一致但是其在跑分表现上已经超过 GPT并且 GPT 付费实在太麻烦动不动就封号所以我还是国内大模型。图7 Token Plan Standard技术选型图8 CC Switch 配置由于我习惯了Cluade Desktop所以我准备了CC Switch官方也提供了接入方式非常方便的就接入了。请求地址https://token-plan.cn-beijing.maas.aliyuncs.com/apps/anthropic模型映射都填写qwen3.8-max即可注意在点击获取模型列表时一直提示未找到可用的模型列表端点请检查 Base URL 或确认供应商是否开放该接口需要我们手动填写模型映射。图9 接入成功核心 Prompt这个项目没有引入复杂的多 Agent 编排。一篇稿件只走一条清晰的链路先读取正文先跑规则再调用 Qwen3.8-Max 进行语义补检最后合并结果并按原文位置。并没有给他太多太长的提示词我只是简单的描述了需求它就能很好分析出 原型、PRD、最后编码直接生成项目。我们公司的运营经常要审核大量达人稿件目前都是人工审核目前我想实现一个工具能够批量审核所有稿件并提供检测报告以及修改建议。图10 prompt随后出现了交互式问答自动让我补全信息。图11 交互式问询先生成了原型让我预览并给我提供相关方案整体上还是比较满意的以书本的风格并且生成了 Logo、以及名称。图12 生成原型继续生成了产品 PRD让我预览整体的产品设计符合预期并且没有打的出入所以我仅仅提供一点修改意见并让他继续执行了。图13 生成 PRD根据 PRD 帮我实现了项目代码只需要配置一些参数就能运行了。图14 生成代码多路并行目前还是单进程单篇处理模式目前处理大概 2min/篇如果是 10 篇文章可能需要 2min 的十倍也就是 20 分钟这显然不符合我的需求我的需求是无论是多少文章都要在快速完成。于是我继续补充到帮我增加多篇文章并行处理的逻辑 比如批量上传 10 篇文章每篇文章等待 1 分钟的话就会累计 10 分钟如果是并行的话可能就需要1 分钟就搞定了。并行处理是这次 Demo 的实用改动。批次创建后立即返回batch_id服务端将每篇稿件提交给固定大小的线程池前端每 0.8 秒查询一次进度。目前的代码我把并发数设为 4避免在一批稿件里同时对文档接口和模型网关发起过多请求这个参数可以调整的。EXECUTORThreadPoolExecutor(max_workers4)defstart_batch(links,docs,campaign_text):batch_iduuid.uuid4().hex[:12]items[{kind:link,link:link}forlinkinlinks]items[{kind:doc,doc:doc}fordocindocs]status[{state:queued,title:item.get(link)oritem[doc].get(title,未命名)}foriteminitems]JOBS[batch_id]{items:items,campaign:campaign_text,rules:load_rules(),done:False,report:None,results:[None]*len(items),status:status,}forindexinrange(len(items)):EXECUTOR.submit(process_item,batch_id,index)returnbatch_iddefprocess_item(batch_id,index):# 拉取正文 → 规则检查 Qwen3.8-Max 语义补检 → 写回单篇状态...前端不再只显示“检测中”而是按稿件显示排队中、拉取正文、规则 LLM 审核、完成或拉取失败。对于网络请求较慢的任务这比单纯的转圈更有用运营至少知道任务卡在了文档读取还是模型审核。踩坑记录坑 1飞书文档不是一个拿到链接就能抓取的网页。一开始用普通请求访问文档链接得到的是登录跳转不是正文。实际接入需要从新版/docx/{document_id}链接中解析文档 ID再调用文档原始内容接口。项目中优先使用运营本人授权后的user_access_token没有用户令牌时才用应用身份作为兜底。这样运营本来就有权限阅读的文档才能以其本人身份进入审核流程。坑 2开放平台显示“已开通”不代表 OAuth 授权页真的申请了权限。这次最容易误判的地方是scope。最初的授权链接只有app_id、redirect_uri和state没有显式传入scope授权页只会请求用户身份标识即使后台已开通文档权限用户令牌里也没有读取文档所需的授权范围。图15 OAuth scope修复是把docx:document:readonly写进 OAuth 授权链接同时在应用后台开通对应权限、发布新版本并让用户重新扫码授权。代码里还加入offline_access用于 access token 到期后的静默续期。缺少它时授权页面会直接给出权限不足提示。图16 在feishu开发者后台的权限缺少 offline_access另一个现实限制是文档本身的访问权限。应用身份无法读取未授权给应用的文档跨组织共享文档通常更适合走用户授权。即便失败也保留“粘贴正文”补审入口避免一个链接拉取失败拖住整批审核。效果对比这次我测试的第一篇三千多字的飞书稿件结果页显示 42 分、需修改 5 个问题它不是多篇历史稿件的性能统计因此我不把它包装成“节省多少分钟”的结论。对比更有意义的是审核信息如何交接。环节过去审核开发的工具稿件进入打开链接后人工审核优先读飞书正文失败时可粘贴正文补审确定性问题逐篇找敏感次、错别字以及征文要求rules.json统一检查并记录原文位置语义问题审核人靠经验判断Qwen3.8-Max 补检要求返回原文短引审核结果评论散在不同文档或聊天里报告看板、单篇批注、修改意见函批量状态只能安排多人处理通过协同软件同步显示排队、拉取、审核、完成或失败我的直接感受是工具没有替我做业务决策但它把机械核对和问题归档先做了。审核人打开报告就能看到缺什么、命中了哪句、建议怎么改剩下的精力可以花在事实、调性和投放策略上。总结Qwen3.8-Max 在这个场景下的表现Qwen3.8-Max 在我开发这个工具里承担的是语义补检、结构化输出以及理解征文需求、依据需求分析文章的问题它对“字典里没有、但上下文有问题”的表达可以补出人工应关注的地方并在代码中通过限制 JSON 字段、原文短引和问题类型输出能被后端接住并展示到报告页面。这次真实运行也提醒了我模型能力只是整个流程的一部分。文档权限、授权范围、令牌续期、网络等待和失败降级都会决定运营是否愿意把它当成日常工具。把这些边界做清楚后Qwen3.8-Max 的输出才真正能进入审核工作流。一句话评价Qwen3.8-Max 让这个工具多了一层能读懂上下文的首检能力真正把 Demo 跑通的是规则、权限、并发和人工终审一起组成的流程。复现指南环境配置Python 3.14.1PROMPT我们公司的运营经常要审核大量达人稿件目前都是人工审核目前我想实现一个工具能够批量审核所有稿件并提供检测报告以及修改建议。Prompt 补充帮我增加多篇文章并行处理的逻辑 比如批量上传 10 篇文章每篇文章等待 1 分钟的话就会累计 10 分钟如果是并行的话可能就需要1 分钟就搞定了。飞书创建一个 app 应用添加回调地址127.0.0.1:8765和添加权限docx:document:readonly和offline_access 我用 Qwen3.8-Max 搭了一个达人稿件审核工具，真实飞书稿件终于能跑完首轮质检
背景我为什么要搭这个身为运营经常要去对接 KOL 的征文现在基本上都是人工审核有时候稿件多的时候第一轮的机械核对是最费时间的同样的要求要在每篇稿里反复找发现问题后还要整理成达人能看懂的修改意见。所以我希望做一个自动批量审核的工具当然它不仅仅是判断“是否通过”而是在首轮审核时就把它变成可追溯的清单。这样我能导入多篇链接或直接粘贴正文工具就能先做确定性规则检查再让大模型补充我预设的规则覆盖不到的语义问题最后输出报告、逐篇批注和修改意见。当然审核标准还需要支持多元化的标准不止看错别字、语义、敏感词、隐私信息、前后逻辑一致、内容结构完整等通用的规则还需要支持针对这次稿件的特殊的稿件要求比如主题方向、字数要求、代码要求等等。最终效果图1 审核页面因为目前 KOL 收集上来的文档都是飞书文档的链接所以我做成了一个输入支持多行的飞书链接当然也是支持是手工粘贴的稿件征文的要求目前支持上传 Word、Markdown、PDF、TXT解析后仍可在页面里编辑。后端的执行逻辑是每篇稿件并行执行“拉取正文 → 规则与模型审核 → 写入报告”这样就能大大节省审核的时间。图2 Qwen3.8-max RPMTPM之前人工审核可能 5min/篇现在是 2min/单篇但是注意这是单路并发目前 qwen3.8-max 是 RPM 3万次/分钟TPM 是 500万 Token/分钟也就是说同时执行最高 3 万篇当然这只是理论上限制还需要考虑机器本人是否支持 3 万并发以及 Token 的消耗量等。稿件链接 / 粘贴正文读取正文征文要求解析为审核项规则检查Qwen3.8-Max 语义补检报告看板逐篇批注与修改意见函运营人工复核图3 审核完成图4 审核报告图5 修改意见审核结束后报告页会汇总通过、需修改、不合格、拉取失败的数量以及广告法/违禁词、品牌信息、错别字、投放要求、AI 痕迹五个维度的问题分布。单篇页面保留原文和问题卡片修改意见函可直接复制给达人。搭建过程图6 Qwen3.8-max 官方跑分最近刚刚发布了 Qwen3.8-Max看它的宣传跑分非常高迫不及待要体验一把于是我在官网购买了 TokenPlan 的 Standard 套餐目前优惠价格是 139元/月价格不便宜与 GPT Plus 价格基本一致但是其在跑分表现上已经超过 GPT并且 GPT 付费实在太麻烦动不动就封号所以我还是国内大模型。图7 Token Plan Standard技术选型图8 CC Switch 配置由于我习惯了Cluade Desktop所以我准备了CC Switch官方也提供了接入方式非常方便的就接入了。请求地址https://token-plan.cn-beijing.maas.aliyuncs.com/apps/anthropic模型映射都填写qwen3.8-max即可注意在点击获取模型列表时一直提示未找到可用的模型列表端点请检查 Base URL 或确认供应商是否开放该接口需要我们手动填写模型映射。图9 接入成功核心 Prompt这个项目没有引入复杂的多 Agent 编排。一篇稿件只走一条清晰的链路先读取正文先跑规则再调用 Qwen3.8-Max 进行语义补检最后合并结果并按原文位置。并没有给他太多太长的提示词我只是简单的描述了需求它就能很好分析出 原型、PRD、最后编码直接生成项目。我们公司的运营经常要审核大量达人稿件目前都是人工审核目前我想实现一个工具能够批量审核所有稿件并提供检测报告以及修改建议。图10 prompt随后出现了交互式问答自动让我补全信息。图11 交互式问询先生成了原型让我预览并给我提供相关方案整体上还是比较满意的以书本的风格并且生成了 Logo、以及名称。图12 生成原型继续生成了产品 PRD让我预览整体的产品设计符合预期并且没有打的出入所以我仅仅提供一点修改意见并让他继续执行了。图13 生成 PRD根据 PRD 帮我实现了项目代码只需要配置一些参数就能运行了。图14 生成代码多路并行目前还是单进程单篇处理模式目前处理大概 2min/篇如果是 10 篇文章可能需要 2min 的十倍也就是 20 分钟这显然不符合我的需求我的需求是无论是多少文章都要在快速完成。于是我继续补充到帮我增加多篇文章并行处理的逻辑 比如批量上传 10 篇文章每篇文章等待 1 分钟的话就会累计 10 分钟如果是并行的话可能就需要1 分钟就搞定了。并行处理是这次 Demo 的实用改动。批次创建后立即返回batch_id服务端将每篇稿件提交给固定大小的线程池前端每 0.8 秒查询一次进度。目前的代码我把并发数设为 4避免在一批稿件里同时对文档接口和模型网关发起过多请求这个参数可以调整的。EXECUTORThreadPoolExecutor(max_workers4)defstart_batch(links,docs,campaign_text):batch_iduuid.uuid4().hex[:12]items[{kind:link,link:link}forlinkinlinks]items[{kind:doc,doc:doc}fordocindocs]status[{state:queued,title:item.get(link)oritem[doc].get(title,未命名)}foriteminitems]JOBS[batch_id]{items:items,campaign:campaign_text,rules:load_rules(),done:False,report:None,results:[None]*len(items),status:status,}forindexinrange(len(items)):EXECUTOR.submit(process_item,batch_id,index)returnbatch_iddefprocess_item(batch_id,index):# 拉取正文 → 规则检查 Qwen3.8-Max 语义补检 → 写回单篇状态...前端不再只显示“检测中”而是按稿件显示排队中、拉取正文、规则 LLM 审核、完成或拉取失败。对于网络请求较慢的任务这比单纯的转圈更有用运营至少知道任务卡在了文档读取还是模型审核。踩坑记录坑 1飞书文档不是一个拿到链接就能抓取的网页。一开始用普通请求访问文档链接得到的是登录跳转不是正文。实际接入需要从新版/docx/{document_id}链接中解析文档 ID再调用文档原始内容接口。项目中优先使用运营本人授权后的user_access_token没有用户令牌时才用应用身份作为兜底。这样运营本来就有权限阅读的文档才能以其本人身份进入审核流程。坑 2开放平台显示“已开通”不代表 OAuth 授权页真的申请了权限。这次最容易误判的地方是scope。最初的授权链接只有app_id、redirect_uri和state没有显式传入scope授权页只会请求用户身份标识即使后台已开通文档权限用户令牌里也没有读取文档所需的授权范围。图15 OAuth scope修复是把docx:document:readonly写进 OAuth 授权链接同时在应用后台开通对应权限、发布新版本并让用户重新扫码授权。代码里还加入offline_access用于 access token 到期后的静默续期。缺少它时授权页面会直接给出权限不足提示。图16 在feishu开发者后台的权限缺少 offline_access另一个现实限制是文档本身的访问权限。应用身份无法读取未授权给应用的文档跨组织共享文档通常更适合走用户授权。即便失败也保留“粘贴正文”补审入口避免一个链接拉取失败拖住整批审核。效果对比这次我测试的第一篇三千多字的飞书稿件结果页显示 42 分、需修改 5 个问题它不是多篇历史稿件的性能统计因此我不把它包装成“节省多少分钟”的结论。对比更有意义的是审核信息如何交接。环节过去审核开发的工具稿件进入打开链接后人工审核优先读飞书正文失败时可粘贴正文补审确定性问题逐篇找敏感次、错别字以及征文要求rules.json统一检查并记录原文位置语义问题审核人靠经验判断Qwen3.8-Max 补检要求返回原文短引审核结果评论散在不同文档或聊天里报告看板、单篇批注、修改意见函批量状态只能安排多人处理通过协同软件同步显示排队、拉取、审核、完成或失败我的直接感受是工具没有替我做业务决策但它把机械核对和问题归档先做了。审核人打开报告就能看到缺什么、命中了哪句、建议怎么改剩下的精力可以花在事实、调性和投放策略上。总结Qwen3.8-Max 在这个场景下的表现Qwen3.8-Max 在我开发这个工具里承担的是语义补检、结构化输出以及理解征文需求、依据需求分析文章的问题它对“字典里没有、但上下文有问题”的表达可以补出人工应关注的地方并在代码中通过限制 JSON 字段、原文短引和问题类型输出能被后端接住并展示到报告页面。这次真实运行也提醒了我模型能力只是整个流程的一部分。文档权限、授权范围、令牌续期、网络等待和失败降级都会决定运营是否愿意把它当成日常工具。把这些边界做清楚后Qwen3.8-Max 的输出才真正能进入审核工作流。一句话评价Qwen3.8-Max 让这个工具多了一层能读懂上下文的首检能力真正把 Demo 跑通的是规则、权限、并发和人工终审一起组成的流程。复现指南环境配置Python 3.14.1PROMPT我们公司的运营经常要审核大量达人稿件目前都是人工审核目前我想实现一个工具能够批量审核所有稿件并提供检测报告以及修改建议。Prompt 补充帮我增加多篇文章并行处理的逻辑 比如批量上传 10 篇文章每篇文章等待 1 分钟的话就会累计 10 分钟如果是并行的话可能就需要1 分钟就搞定了。飞书创建一个 app 应用添加回调地址127.0.0.1:8765和添加权限docx:document:readonly和offline_access