野生码农
AI 产线写稿又慢又差怎么办?我抓回 53 篇平台评分,逐环节掐表找到了病根
一篇稿子写 20 分钟,AI 还觉得自己立了功
我的写作产线(IPMS,一套「素材卡 → 写母稿 → 质检 → 分发」的 AI 流水线)最近出了两件让我上火的事。
第一篇稿子,母稿写了 17 分钟——而且第一次跑了 23 分钟还被服务重启杀掉,零日志,等于白烧【实测:产线事件日志】。第二篇,AI 军师跑完报喜:token 比改前省了一半。我看了眼耗时:20 分 42 秒【实测:wire.jsonl 全量计时】。
我当场问它:「你是豆包附体了吧?我让你提高效率,你说你省 token,这点额度有什么影响?」
更扎心的是质量。CSDN 后台的「质量分」是平台给每篇文章打的内部评分,直接决定推荐权重。我翻了下近期文章:9 月 14 日之后的 14 篇里,9 篇只有 72 分,5 篇 82 分——而 8 月份我是拿过两次 88 分的【实测:CSDN bizapi 接口全量拉取】。正如我在讨论里说的:「之前有段时间,基本上每篇都能上高质量。」
又慢又差。问题到底出在哪?
第一步:别猜,先掐表
AI 产线的好处是每一步都有日志。我把第二篇稿子的完整运行记录(wire.jsonl)拉出来,按环节逐段计时:
| 环节 | 耗时 | 占比 |
|---|---|---|
| 补卡(选题卡信息补全) | 6'07" | 29.5% |
| 判卷轮 1(LLM 质检) | 4'30" | 21.7% |
| meta(标题 Top5 评分+摘要) | 3'27" | 16.7% |
| 打回修改 | 2'25" | 11.7% |
| 母稿本体(真正写文章) | 2'27" | 11.8% |
| 判卷轮 2 | 43" | 3.5% |
| 终闸 | 38" | 3.1% |
| 机器闸(规则校验) | 25" | 2.0% |
| 合计 | 20'42" | 100% |
【实测:wire.jsonl 耗时分段】
结论一目了然:真正写文章的时间只占 12%,剩下 88% 全花在「准备工作」和「质检返工」上。 补卡 6 分钟、判卷两轮加返工近 8 分钟、起标题写摘要 3 分半——这些全是产线一道道加上去的「品控工序」,每一道单看都有道理,叠起来就是把 3 分钟的活拖成 20 分钟。
顺带一说,token 确实省了一半(273 万 → 133 万 prompt token),但耗时地板卡在输出生成上:4.2 万 completion token 是硬成本,思考档位开的还是 max 档【实测:wire.jsonl token 统计】。省输入 token 对速度几乎没有帮助——这就是「优化错了方向」。
第二步:把平台评分数据全部抓回来
慢的问题定位了,差的问题怎么办?我最初的思路是让 AI 模拟请求 CSDN 的接口。AI 果然把简单问题搞复杂了,绕去研究签名算法。我一句话点醒它:
「你这个模式是不是搞得很复杂?我连 API 的接口都给你了,你获取我的 Cookie 模拟请求不就可以抓取所有的数据了吗?」
最终方案比签名模拟简单得多,可抄走:
- 电脑上常备一个调试版 Chrome(独立配置目录,
--remote-debugging-port=9333启动),在里头登录一次 CSDN,登录态永久保存; - 写个脚本通过 CDP(Chrome DevTools Protocol)挂到这个浏览器上,让它访问后台文章列表接口
bizapi.csdn.net/blog/phoenix/console/v1/article/list,直接截获返回的 JSON; - JSON 落库,53 篇文章的分数、字数、发布时间全部到手。
不破解签名、不模拟登录、不怕风控——浏览器本来就是登录状态,你只是「站在旁边看它和服务器聊天」。这套思路对所有「后台数据想导出来分析」的场景都通用。
第三步:分组对比 + 变更时间线叠加,病根现形
53 篇数据到手后做了两层分析【实测:分析存档 notes/AI工作/csdn质量分全量分析与产线对齐_20261009.md】。
第一层:高分组和低分组差在哪? 把能匹配到本地发布包的 27 篇分成 ≥80 分组(12 篇)和 72 分组(15 篇)逐项对比,结论:题材之外,字数(+47%)和多级标题数(+57%)是 72 → 82 分的两个操作性杠杆,图、代码块、外链的差异都可以忽略。对照 CSDN 官方 V5.0 评分规则的明文加分项,完全对得上。顶档 87/88 分的 4 篇全是「长+硬核」:最长的 12184 字、49 个多级标题。
第二层:分数是什么时候开始掉的? 这是我自己加的分析维度——我当时的原话是「不仅仅是题材」「结合我们这个脚本变更的时间,有没有什么规律?」把分数按产线规则变更的时间线分段:
| 时间段 | 产线状态 | 篇数 | 平均分 | ≥80 分占比 | 最高分 |
|---|---|---|---|---|---|
| 8-02~9-03 | 旧产线,规则少 | 28 | 76.5 | 39% | 88 |
| 9-03~9-17 | 产线 2.0(GEO 闸/图片闸) | 12 | 76.7 | 42% | 88 |
| 9-17~9-26 | 无头新线(一键派单) | 5 | 78.0 | 60% | 82 |
| 9-26~10-09 | 答案前置+摘要窗口+禁预告+标题适配闸 | 7 | 73.4 | 14% | 82 |
【实测:53 篇分段统计】
拐点清清楚楚:9 月 26 日之后上线的那四道写作规则,平均分从 78.0 砸到 73.4,高分率从 60% 砸到 14%。 之前每道规则上线时都觉得是「改进」,数据说你改错了。这印证了一个常识:没有数据反馈回路的「优化」,大概率是负优化。
方案:先对齐杠杆,再给产线动三刀
病根找到了,开两方。
方子一:对齐评分杠杆(commit 0dc611f)。 把字数窗口从 2000-3000 放宽到 2400-3600(CJK 汉字口径);给机器质检闸加一条「多级标题 ≥8 个」的硬校验;思考档位从 max 降回 high。全部带验证:eval 20/20 通过,一篇 82 分旧稿(8 个标题)能放行、一篇 72 分旧稿(6 个标题)会被拦下,pytest 26 条全绿【实测】。
方子二:产线瘦身,砍三刀(commits cf8c78d / f5aa779 / 70acc72)。 原则是我定的:「机器闸门是秒级的,肯定保留;判卷放到给我终审的里面去。」
| 工序 | 原来 | 现在 |
|---|---|---|
| 补卡(6'07") | AI 先花 6 分钟补全选题卡 | 整道砍掉,选题单写清方向直接开写 |
| LLM 判卷两轮+返工(7'38") | 子代理逐条判卷打回 | 移到人工终审页:AI 分析给建议,我逐条采纳或忽略 |
| 标题 Top5 评分(含在 meta 3'27") | 评分器给 5 个标题打分排序 | 砍评分器,直接出 3 个方向共 10 个标题,我看哪个顺眼点哪个 |
| 机器闸(25") | 规则校验 | 保留——秒级成本,防的是「没做」 |
瘦身后的第一次试写:单篇总耗时 11'09",比 20'42" 降了约 46%【实测:commit f5aa779 试写记录】。还没到我内部 10 分钟的止损线,继续调,但方向已经对了。
经验总结:三样可抄走的东西
1. 平台数据抓回法。 想分析自己在任何平台的历史数据,别碰签名模拟——常备一个登录态调试 Chrome,CDP 截包后台接口,JSON 直出。零风控风险,半小时搭完。
2. 变更时间线叠加法。 感觉产出质量下降时,把产出指标按「规则/配置变更时间点」分段求均值,找拐点。体感会骗人,分段均值不会。这一招对代码性能回归、内容质量回归、转化率下滑全都适用。
3. 品控闸分层原则。 给 AI 产线加质检时按成本分层:秒级的机器闸(字数、结构、格式)前置,随便加;分钟级的 LLM 判卷后移到人工终审环节,变「自动打回」为「给建议、人来点」。质检的价值不取决于加了多少道闸,取决于闸拦下的问题和拦住的成本是否成正比——我那条 25 秒的机器闸,比 8 分钟的 LLM 判卷值钱得多。
素材点
- 17 分钟母稿+23 分钟断链被杀(93a7f4c 修复):断链保护类故障素材
- 耗时八段表原始数据:wire.jsonl,2026-10-09 晚
- CSDN 53 篇评分明细与分组对比:notes/AI工作/csdn质量分全量分析与产线对齐_20261009.md
- 采集脚本:tools/csdn_hq_fetch.py(CDP 截包实现)
- 对齐包:commit 0dc611f;瘦身三批:cf8c78d / f5aa779 / 70acc72;试写 11'09":f5aa779
- 方向讨论定稿(写作转向教程价值):ideas/20261010_IP三线矩阵与研习社规划_会谈定稿.md