![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
最近一段时间，我一直按照 目前主要参考的 WordPress 历史文章处理 SOP 继续处理剩余的历史文章。
这套 SOP 已经经历过多轮真实批次验证。现在的日常流程大致包括固定批次、Gutenberg 规范化、生产只读验证、中文摘要生成、英文覆盖翻译、失败恢复以及最终的 completed 状态确认。
更早一阶段的流程，则记录在 每天批量处理 20 篇 WordPress 历史文章：代码块迁移、摘要补全与英文覆盖翻译完整 SOP 中。
随着后续历史文章继续推进，我现在实际操作时主要参考的是 7 月 30 日更新后的 SOP，而不是重新从最早的流程开始。
前几天其实已经遇到过一次自动处理无法正常完成、最后改成人工处理的情况。当时我选择让 ChatGPT 接手所需内容，再人工完成 WordPress 中的文章处理。那次过程已经记录在 前几天人工处理的一篇历史文章 中。
今天继续处理新的 20 篇固定批次时，又遇到了一个更适合正式补进 SOP 的异常场景：
自动流程甚至还没有进入英文覆盖翻译阶段，就在生成中文摘要时持续收到 GLM HTTP 400。
经过多次真实重试、execution evidence 检查和离线分析以后，最终确认这并不是普通的网络波动，而是 GLM 明确触发了内容安全过滤。
这一次，我没有为了让模型审核通过而修改原来的历史文章，而是进一步完善了现有的人工兜底流程：
自动模型确定性拒绝
→ 停止无意义重试
→ ChatGPT 人工生成中文摘要
→ ChatGPT 人工完成英文标题、摘要和正文
→ 人工写回 WordPress
→ mark-manual-completed 生产只读验收
→ 保留原始失败 evidence
→ coordination state 安全收敛到 completed
最终，这一批仍然实现了 20 / 20 全部完成。
一、20 篇只剩最后一篇，但摘要生成持续 HTTP 400
这次处理的是批次：
mixed-syntaxhighlighter-20260814-03
整批共 20 篇，其中 19 篇已经正常完成，只剩：
zh=7756
en=10072
对应中文文章标题为：
通过 ARB 跨链，将 USDT 从欧易转出至 MEXC 的流程
这是一篇历史操作记录，正文包含 MEXC、欧易、USDT、Arbitrum One、充值地址、提币网络、手续费和到账记录等内容。
这次失败发生得比英文翻译还早。
execution evidence 显示：
status: excerpt_generation_failed
error: HTTP request failed with status 400
如果只看到 HTTP 400，其实还很难判断究竟属于：
请求参数异常
输入内容问题
模型服务异常
网络波动
内容审核
因此继续查看保存下来的结构化 GLM 响应。
真正关键的信息终于出现：
error.code = 1301
同时还有：
contentFilter:
role = assistant
level = 1
模型返回的信息也明确指向了内容安全过滤。
1301 内容过滤结果。到这里，问题已经不应该继续简单按照“网络错误”处理。
二、一次 TimeoutError 并不能解释反复出现的 HTTP 400
这次排查中间确实还出现过一次：
TimeoutError
因此最开始也存在一个疑问：
会不会只是 GLM 服务当时不稳定？
但是把整个失败顺序放在一起以后，就比较清楚了：
HTTP 400
→ HTTP 400
→ HTTP 400
→ recover
→ TimeoutError
→ recover
→ HTTP 400
中间那次 TimeoutError 可以单独视为一次暂时性的网络请求异常。
但是前后稳定重复出现的 HTTP 400，显然不能都用网络波动解释。
后续代码也进一步增强了诊断信息，让 HTTP 状态、结构化错误响应以及 GLM 请求尺寸能够进入 execution evidence。
这样以后再遇到类似错误，不需要只盯着一长串 Python traceback。
三、离线检查以后，基本排除了输入长度问题
为了进一步确认原因，我把生产中文源只读拉到本地，并确认 SHA-256 与程序保存的生产源摘要完全一致。
然后使用生产代码中的：
extract_excerpt_source()
重新生成真正送给 GLM 的摘要输入。
结果为：
原始正文：
8228 chars
10234 bytes
清洗后正文：
892 chars
2024 bytes
完整 GLM payload：
3427 bytes
也就是说，这篇文章送给 GLM 的实际内容并不长。
当前摘要提取逻辑本身允许远大于这个规模的输入，因此没有证据表明 HTTP 400 是因为正文过长或者请求体过大造成的。
真正比较特殊的是，经过 Gutenberg 注释、HTML 标签等内容清洗以后，剩余正文仍然连续包含：
USDT
Arbitrum One
MEXC
欧易
充值
提现
链上网络
完整地址
转账金额
手续费
到账记录
这些内容组合起来，很可能触发了模型侧的内容审核。
不过现有 evidence 只能证明：
GLM 1301 内容过滤是这次 HTTP 400 的直接原因。
至于究竟是哪一句话、哪一个地址或者哪一类词触发，现有证据还不足以精确判断。
四、我不准备为了让模型通过审核去修改历史文章
确认模型内容过滤以后，其实还有一种处理办法。
可以不断修改中文源：
删除可能敏感的词
→ 删除地址
→ 简化金额描述
→ 修改转账步骤
→ 再请求 GLM
→ 直到模型接受
但我最终没有选择这个方向。
这次历史文章处理的本来目标是：
规范历史格式
补齐中文摘要
重新完成英文翻译
而不是：
为了适应某一家模型当下的审核规则
反过来修改原文章内容
尤其这篇文章记录的是一次真实的历史操作过程。
如果为了模型审核，把网络、金额、地址或者操作过程删掉，最终反而破坏了这篇历史记录本身。
所以当确定 HTTP 400 属于模型内容过滤以后，我认为继续盲目调用 GLM 已经没有太大意义。
更合理的方案是：
保留自动失败事实
→ 停止自动重试
→ 转入人工兜底
五、前几天已经验证过 ChatGPT 人工处理路线
这并不是我第一次考虑人工接管。
前几天处理另一篇异常历史文章时，自动流程同样无法顺利完成，最后已经尝试通过 ChatGPT 完成人工处理。
相关过程记录在：
那次实践至少验证了一件事情：
自动流程遇到少数无法继续推进的文章时，没有必要让整个批次都停在那里。
可以把这篇文章单独转入人工处理。
不过今天 7756 又暴露出了一个新的边界。
前面的人工完成机制主要考虑的是：
translation_failed
blocked
而 7756 停在：
excerpt_failed
也就是说：
这次连中文摘要都还没有生成成功。
因此，原来的人工完成入口还不能直接安全覆盖这种情况。
六、原来的 mark-manual-completed 还不支持 excerpt_failed
仓库本来已经存在一个专门用于外部人工完成后的命令：
python3 bin/history-migration.py mark-manual-completed \
--post-id 文章ID
正式确认则是：
python3 bin/history-migration.py mark-manual-completed \
--post-id 文章ID \
--confirmed
这个设计本身非常适合 ChatGPT 人工兜底。
问题在于，原来的允许状态主要是：
translation_failed
blocked
而当前文章是：
excerpt_failed
这两种情况不能简单等价。
如果是 translation_failed，通常意味着：
中文摘要已经生成
→ 中文摘要已经写入
→ 英文覆盖翻译阶段失败
但是 excerpt_failed 意味着：
中文摘要都还没有成功生成
如果只是把：
excerpt_failed
加入允许状态，而不增加额外检查，就可能出现：
中文摘要仍然为空
→ 英文旧文章本来就有内容
→ mark-manual-completed 误认为人工工作已经完成
→ workflow_status = completed
这显然是不安全的。
七、为 excerpt_failed 增加更严格的人工完成检查
因此这次对 mark-manual-completed 做了一个很小但非常重要的扩展。
excerpt_failed 现在可以进入人工完成检查，但是必须同时满足：
中文文章 ID 正确
中文文章 status = publish
中文 post_excerpt 非空
英文文章 ID 正确
英文文章 status = publish
英文 title 非空
英文 content 非空
Polylang 中英文关系双向正确
其中真正新增的关键检查就是：
Chinese excerpt is not empty
而且这个条件只针对：
excerpt_failed
原来的：
translation_failed
blocked
行为没有因此被无条件放宽。
八、第一次 Preview 正确阻止了人工完成
代码修改并通过测试以后，我没有马上开始改 WordPress。
先直接拿当前真实文章 7756 做了一次 Preview：
cd ~/code/wordpress-ai-excerpt-backfill
python3 bin/history-migration.py mark-manual-completed \
--post-id 7756
当时中文摘要仍然为空。
程序输出：
模式: preview
文章: zh=7756 en=10072
当前状态: excerpt_failed
只读检查: post ID、publish、Polylang、英文标题和正文（excerpt_failed 另检中文摘要）
允许人工完成: 否
写入操作: 否
阻断原因: Chinese excerpt is empty
这个结果正是我希望看到的。
它证明程序没有因为英文历史文章原本就有标题和正文，就错误地把这篇文章认定为“已经人工处理完成”。
必须先真正补齐中文摘要。
九、由 ChatGPT 人工生成中文摘要
随后，我直接从 WordPress 编辑器中复制出文章标题和完整 Gutenberg 正文，交给 ChatGPT。
ChatGPT 根据完整原文重新生成中文摘要：
本文记录一次通过 Arbitrum One 网络将 USDT 从欧易转入 MEXC 的实际过程，包括在 MEXC 生成充值地址、在欧易选择 USDT 和对应提币网络、核对地址与网络、完成邮箱和手机验证、查看提币状态，并通过小额测试及后续转账确认到账情况。过程中还记录了平台风险提示、手续费和账户余额变化，重点提醒跨平台转账时必须保证充币与提币使用同一网络，并仔细核对地址，避免因网络或地址选择错误造成资产损失。
然后人工填写到 WordPress 中文文章的摘要字段。
这里没有为了避开审核修改中文正文。
真正新增的只是原来缺失的 post_excerpt。
十、ChatGPT 同时重新完成英文文章
既然这篇文章已经进入人工兜底，我最终也没有再让自动翻译管线继续承担后面的英文覆盖翻译。
而是直接让 ChatGPT 完成：
英文标题
英文摘要
完整英文正文
图片 alt
Figure caption
最终英文标题为：
Transferring USDT from OKX to MEXC via Arbitrum: The Process
正文继续保留原有 Gutenberg 结构：
段落顺序不变
图片区块不变
图片 ID 不变
媒体 URL 不变
完整地址不变
只重新翻译自然语言内容。
这样一来，生产环境中的真正内容已经达到了人工完成要求。
但是此时我仍然没有手工修改 state JSON。
十一、重新 Preview 后，程序才允许人工完成
人工保存中文摘要和英文内容以后，再执行相同的 Preview：
cd ~/code/wordpress-ai-excerpt-backfill
python3 bin/history-migration.py mark-manual-completed \
--post-id 7756
这一次结果变为：
模式: preview
文章: zh=7756 en=10072
当前状态: excerpt_failed
只读检查: post ID、publish、Polylang、英文标题和正文（excerpt_failed 另检中文摘要）
允许人工完成: 是
写入操作: 否
这意味着程序已经通过生产只读查询确认：
中文摘要已经存在
中文文章正常 publish
英文标题存在
英文正文存在
英文文章正常 publish
Polylang 中英文对应关系正常
只有生产环境中的真实内容满足要求以后，才允许进入下一步。
这一点比直接修改本地：
workflow_status = completed
可靠得多。
十二、最后执行 –confirmed
Preview 确认：
允许人工完成: 是
以后，才正式执行：
cd ~/code/wordpress-ai-excerpt-backfill
python3 bin/history-migration.py mark-manual-completed \
--post-id 7756 \
--confirmed
真实输出为：
模式: confirmed
文章: zh=7756 en=10072
当前状态: excerpt_failed
只读检查: post ID、publish、Polylang、英文标题和正文（excerpt_failed 另检中文摘要）
允许人工完成: 是
写入操作: 是
需要特别说明的是，这里的：
写入操作: 是
并不是再次修改 WordPress。
WordPress 中的内容已经由我人工保存完成。
这一条命令写入的是本地 coordination state。
最终增加：
"manual_completion": {
"status": "confirmed",
"method": "manual_external"
}
并把：
workflow_status
更新为：
completed
十三、completed 并没有把原来的自动失败伪装成成功
这次我特别在意一个问题：
既然后来已经人工完成，原来的 GLM 失败 evidence 应该怎么办？
我的选择是：
不改。
最终文章状态已经是：
workflow_status: completed
但是 execution evidence 仍然明确记录：
status: excerpt_generation_failed
最后一次自动失败也继续保留：
HTTP request failed with status 400
reason: http_client_error
与此同时，新增：
manual_completion:
method: manual_external
status: confirmed
completed，但原来的 excerpt_generation_failed、HTTP 400 和人工完成记录同时保留。我觉得这种状态比直接把 execution evidence 改成：
success
更加符合事实。
真实发生的是：
自动摘要失败
+
人工外部完成
=
最终业务目标完成
这三件事情完全可以同时成立。
completed 表示的是：
当前历史文章迁移任务已经完成。
并不意味着：
以前的自动执行从来没有失败过。
十四、整批最终恢复为 20 / 20 completed
最后重新检查整个批次：
cd ~/code/wordpress-ai-excerpt-backfill
echo "========== FINAL RESULT =========="
python3 bin/history-migration.py summary \
| grep -E \
'mixed-syntaxhighlighter-20260814-03|最新未完成批次|建议创建下一批|建议:'
最终输出：
mixed-syntaxhighlighter-20260814-03:
total=20
completed=20
remaining=0
最新未完成批次: 无
建议创建下一批: True
建议: all batches complete
completed=20、remaining=0，可以继续创建下一批。这意味着：
一篇文章被模型拒绝，并没有让整个历史文章迁移批次长期卡死。
十五、现在 SOP 中多了一条正式的人工兜底路径
正常情况下，日常主流程仍然没有变化：
创建固定批次
→ 人工检查 / Gutenberg 规范化
→ mark-converted
→ 生产只读验证
→ run-ready --execute
→ completed
正式执行阶段发生普通单篇失败以后，仍然优先：
recover --post-id
→ 程序判断恢复策略
→ recover --execute
例如程序可以根据 production source、pre-write baseline 和 execution evidence 自动判断：
resume
restart_from_current
blocked
none
前几天的人工处理已经证明：
极少数异常文章可以由 ChatGPT 单独接管。
而今天 7756 进一步把这条路线正式补进了状态机。
现在遇到类似的确定性模型拒绝，可以按照：
GLM 摘要持续失败
→ recover / execution evidence 确认真实原因
→ 确认属于模型内容过滤等确定性失败
→ 停止盲目重试
→ ChatGPT 生成中文摘要
→ ChatGPT 生成英文标题、摘要和完整正文
→ 人工保存 WordPress
→ mark-manual-completed Preview
→ 生产只读检查
→ 确认允许人工完成
→ mark-manual-completed --confirmed
→ workflow_status = completed
整个过程中：
不删除 state
不清空 evidence
不手工伪造 completed
不修改原失败记录
这条路径也已经补进目前主要使用的 WordPress 历史文章处理 SOP。
以后再遇到类似问题，就不需要重新回忆：
人工翻译完成以后应该执行什么命令？
是不是需要改 JSON？
怎样才能让这篇文章进入 completed？
直接走：
mark-manual-completed
即可。
十六、为什么我觉得这次补的不是一条命令，而是一种状态设计
历史文章自动化处理到后面，绝大多数普通文章其实已经越来越稳定。
真正消耗时间的通常都是少数异常。
例如目前实际遇到过：
SSH timeout
REST 认证异常
GLM TimeoutError
Protected Token 校验失败
WordPress HTTP 500
Ctrl+C 中断
execution evidence 与 workflow 不一致
模型内容过滤
如果每出现一种异常，都通过：
删除 state
清空 evidence
修改 JSON
强制 completed
来解决，那么随着项目越来越长，本地状态最终反而越来越不可信。
我现在更希望保持一个比较明确的原则：
自动失败就保存自动失败。
人工完成就记录人工完成。
最终 workflow state 只表达当前任务是否已经完成。
这样以后重新查看某篇历史文章时，仍然能够回答：
它当时为什么失败？
自动流程执行到了哪里？
真实错误是什么？
后来有没有修改生产内容？
最终是谁完成的？
是否经过生产检查？
为什么最终允许进入 completed？
这比只看到：
completed
一个结果更有价值。
十七、后续还要继续观察不同大模型的内容审核尺度
这次 GLM 1301 也让我开始重新考虑历史文章自动化过程中模型的选择。
对于普通技术内容，目前 GLM 在大量历史文章上的自动摘要和翻译整体已经能够正常工作。
但是这篇文章比较特殊。
它连续涉及：
数字资产
充值
提现
链上地址
网络选择
金额
手续费
账户余额
到账记录
即使原文章本身只是记录一次正常操作过程，也仍然可能被模型侧的内容审核拦截。
后续我准备继续实际测试国内不同大模型在这类文章上的审核尺度。
重点观察几个因素：
中文理解与生成质量
API 稳定性
调用成本
长文本能力
结构化输出能力
内容误拦截情况
看看是否存在审核尺度相对更适合技术博客历史内容处理的国内模型。
从我目前实际使用不同模型的体验来看，一些海外大模型在处理这类正常技术记录时，出现类似误拦截的情况相对少一些。
不过，这个观察还不能简单归纳为：
国内模型都会严格审核
海外模型完全不审核
不同厂商、不同模型甚至不同时间的安全策略都可能变化。
因此后续还是需要通过真实 API 调用继续验证。
我也不准备为了适配某一家模型的内容审核规则，去长期修改自己的历史文章。
更希望后续工作流能够继续朝这个方向发展：
模型 A 正常完成
→ completed
模型 A 暂时性失败
→ 有限重试
模型 A 确定性拒绝
→ 停止无意义重试
→ 尝试模型 B
模型 B 仍无法处理
→ ChatGPT / 人工兜底
→ 生产验收
→ manual completion
→ completed
如果以后这类案例继续出现，下一阶段甚至可以考虑把现在的：
人工 ChatGPT fallback
进一步发展成：
多模型自动 fallback
这样能够把人工介入继续压缩到极少数真正需要人工判断的文章。
总结
今天最开始只是一次很普通的批处理异常。
20 篇文章中：
19 篇正常完成
1 篇中文摘要生成失败
最开始看到的只是：
HTTP 400
继续检查以后，最终确认：
HTTP 400
→ GLM error.code = 1301
→ contentFilter
→ 内容安全过滤
随后又通过真实中文源和生产摘要提取逻辑确认：
cleaned_content = 892 chars
payload = 3427 bytes
没有证据表明问题来自输入长度。
当确定继续反复请求 GLM 已经没有意义以后，我没有选择修改历史正文去迎合模型，而是转入：
ChatGPT 生成中文摘要
→ ChatGPT 完成英文标题、摘要和正文
→ 人工保存 WordPress
同时又给原有：
mark-manual-completed
增加了 excerpt_failed 的安全支持。
如果文章停在：
excerpt_failed
程序现在必须额外确认：
Chinese excerpt is not empty
并同时检查：
post ID
publish
英文标题
英文正文
Polylang
真正通过生产只读检查以后，才允许：
python3 bin/history-migration.py mark-manual-completed \
--post-id 文章ID \
--confirmed
最终文章同时保留：
execution_evidence = excerpt_generation_failed
last_failure = HTTP 400
manual_completion = manual_external
workflow_status = completed
整个批次最终恢复为：
total=20
completed=20
remaining=0
最新未完成批次: 无
建议创建下一批: True
建议: all batches complete
所以这次真正解决的已经不仅仅是：
“一篇文章 HTTP 400 怎么办？”
而是进一步回答了另一个更重要的问题：
当自动模型明确拒绝处理某篇文章时，整个自动化工作流怎样在不篡改历史 evidence、不修改原文迎合模型、也不手工伪造状态的情况下，继续安全地完成这篇文章。
目前的答案就是：
自动模型可以失败，但整个历史文章迁移工作流必须保留一条可验证、可审计、能够安全收敛到 completed 的人工兜底路径。
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan
发表回复