🔴 Hot News: baronbool/article/details/

背景：我为什么要搭这个

身为运营，经常要去对接 KOL 的征文，现在基本上都是人工审核，有时候，稿件多的时候，第一轮的机械核对是最费时间的，同样的要求要在每篇稿里反复找，发现问题后还要整理成达人能看懂的修改意见。

所以我希望做一个自动批量审核的工具，当然，它不仅仅是判断“是否通过”，而是在首轮审核时，就把它变成可追溯的清单。这样我能导入多篇链接或直接粘贴正文，工具就能先做确定性规则检查，再让大模型补充我预设的规则覆盖不到的语义问题，最后输出报告、逐篇批注和修改意见。

当然，审核标准还需要支持多元化的标准，不止看错别字、语义、敏感词、隐私信息、前后逻辑一致、内容结构完整等通用的规则，还需要支持针对这次稿件的特殊的稿件要求，比如：主题方向、字数要求、代码要求等等。

最终效果

在这里插入图片描述
图1 审核页面

因为目前 KOL 收集上来的文档都是飞书文档的链接，所以我做成了一个输入支持多行的飞书链接，当然也是支持是手工粘贴的稿件；征文的要求目前支持上传 Word、Markdown、PDF、TXT，解析后仍可在页面里编辑。后端的执行逻辑是每篇稿件并行执行 “拉取正文 → 规则与模型审核 → 写入报告”，这样就能大大节省审核的时间。

在这里插入图片描述 图2 Qwen3.8-max RPM&TPM

之前人工审核可能 5min/篇，现在是 2min/单篇，但是注意这是单路并发，目前 qwen3.8-max 是 RPM 3万次/分钟，TPM 是 500万 Token/分钟，也就是说同时执行最高 3 万篇，当然这只是理论上限制，还需要考虑机器本人是否支持 3 万并发，以及 Token 的消耗量等。

在这里插入图片描述
图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，避免在一批稿件里同时对文档接口和模型网关发起过多请求，这个参数可以调整的。

EXECUTOR = ThreadPoolExecutor(max_workers=4)

def start_batch(links, docs, campaign_text):
    batch_id = uuid.uuid4().hex[:12]
    items = [{"kind": "link", "link": link} for link in links]
    items += [{"kind": "doc", "doc": doc} for doc in docs]
    status = [{"state": "queued", "title": item.get("link") or item["doc"].get("title", "未命名")}
              for item in items]
    JOBS[batch_id] = {
        "items": items, "campaign": campaign_text, "rules": load_rules(),
        "done": False, "report": None, "results": [None] * len(items),
        "status": status,
    }
    for index in range(len(items)):
        EXECUTOR.submit(process_item, batch_id, index)
    return batch_id

def process_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.1

PROMPT

我们公司的运营，经常要审核大量达人稿件，目前都是人工审核，目前我想实现一个工具，能够批量审核所有稿件，并提供检测报告以及修改建议。

Prompt 补充

帮我增加多篇文章并行处理的逻辑？

比如批量上传 10 篇文章，每篇文章等待 1 分钟的话就会累计 10 分钟，如果是并行的话，可能就需要1 分钟就搞定了。

飞书创建一个 app 应用
添加回调地址 127.0.0.1:8765和添加权限 docx:document:readonly 和 offline_access