![[截图 2：浏览器 Network 中直接请求 translate.yandex.net]](https://media.shuijingwanwq.com/2026/07/2-16-1024x568.png)
最近继续处理 WordPress 历史文章的中英文迁移时，遇到了一篇比较特殊的文章。
这篇文章的中文 ID 为 4652，英文文章 ID 为 14655，主要记录微信第三方平台 component_verify_ticket 超时提醒的排查过程。文章年代比较早，正文中除了普通中文说明，还包含 PHP 代码、服务器日志、文件列表、路径、时间戳以及大量历史调试输出。
它所在的历史迁移批次为：
mixed-syntaxhighlighter-20260807-03
这一批一共有 20 篇文章，其他文章陆续完成，唯独 4652 在调用 GLM-5.2 进行整篇翻译时持续返回 HTTP 400。
此前我已经整理过历史文章迁移以及 Plaintext 结构对整篇翻译的影响：
但这一次遇到的不是 Protected Token 校验失败，而是请求在 GLM-5.2 这一层直接被拒绝。
一、GLM-5.2 持续返回 HTTP 400
失败时最关键的错误为：
prompt_client_error: Bad Request (400) - 系统检测到输入或生成内容可能包含不安全或敏感内容，请您避免输入易产生敏感内容的提示语，感谢您的配合。
历史迁移程序记录的失败状态也指向相同问题：
error_summary:
prompt_client_error: Bad Request (400) - 系统检测到输入或生成内容可能包含不安全或敏感内容，请您避免输入易产生敏感内容的提示语，感谢您的配合。
reason:
wordpress_api_error
从错误文案来看，很容易首先怀疑文章中存在某些触发模型安全检测的内容。
但是这篇文章本质上只是一次正常的技术故障排查，内容围绕微信第三方平台、PHP、Yii、Redis、HTTP 请求耗时以及服务器日志展开，并不存在刻意提交敏感内容的情况。
遇到这种情况以后，第一件事并不是立即反复修改 Prompt，而是先确认：
到底是标题、摘要，还是正文触发了 HTTP 400？
二、通过 Trace 确认只有正文失败
当前 GLM-5.2 整篇翻译调优插件会将关键执行过程记录到：
/tmp/swq-glm52-execution-trace.jsonl
检查失败任务的 Trace 后，可以看到标题和摘要其实都已经正常完成。
执行流程大致为：
unit_started: title
unit_finished: title
unit_started: excerpt
unit_finished: excerpt
unit_started: content
content_raw_started
...
content_raw_finished: prompt_client_error
由此可以确定：
- 标题翻译成功；
- 摘要翻译成功；
- HTTP 400 出现在正文翻译阶段。
这样就把排查范围从整篇文章缩小到了真正发送给 GLM-5.2 的正文模型载荷。
当时进一步生成诊断数据后得到：
post_id: 4652
source_chars: 583450
model_payload_chars: 49938
protected_count: 109
plain_region_count: 8
alt_region_count: 18
其中：
source_chars: 583450
代表 WordPress 中的原始正文非常大，达到约 58 万字符。
但代码块、Gutenberg 结构和其他受保护内容经过占位符处理以后，真正交给模型的正文 Payload 已经下降到：
49938
另外，HTTP 请求层记录的完整消息长度为：
54848
这个数比 model_payload_chars 更大，是正常的，因为实际请求中除了正文 Payload，还包含系统提示词、翻译规则等内容。
问题因此进一步集中到了这约 5 万字符的模型可见内容。
三、最初先尝试调整文章文字
因为智谱返回的是：
系统检测到输入或生成内容可能包含不安全或敏感内容
所以最开始还是从文章本身着手，对部分可能产生歧义的文字进行了调整。
包括：
- 缩短并调整文章标题；
- 改写部分描述；
- 调整部分图片 Alt 文本；
- 保留真正有意义的 PHP 代码、服务器日志和技术数据。
修改中文源以后，再通过：
restart-from-current
重新建立当前生产中文源对应的迁移基线。
但问题并没有因此明确消失。
这说明，仅仅寻找“哪个中文词可能比较敏感”，很可能不是最有效的排查方向。
于是我开始直接分析：GLM-5.2 到底看到了什么。
四、8 个 Plaintext Region 开始变得可疑
进一步导出 4652 的模型载荷及保护映射：
/tmp/swq-4652-model-payload.txt
/tmp/swq-4652-protected-map.json
/tmp/swq-4652-plain-regions.json
/tmp/swq-4652-alt-regions.json
其中一个关键数字是：
plain_region_count: 8
也就是说，正文中有 8 个 Code Block Pro Plaintext 区块被转换成 SWQPLAIN 区域，并继续暴露给模型。
其中第一个 Plaintext 确实包含需要处理的中文：
Appid:
昵称:
时间: 2020-11-27 13:35:05
内容: 微信服务器向公众号服务开发者推送component_verify_ticket时，开发者5秒内没有返回
次数: 30分钟 9次
报警排查指引，请见: ...
这类 Plaintext 中存在自然语言，因此让模型看到是有意义的。
问题在于剩下的几个区块。
它们大量属于这种内容：
[root@b21d3b4237a2 runtime]# ls -lt
total 28
drwxrwxr-x 2 nginx nginx 4096 Nov 27 14:35 debug
-rw-r--r-- 1 nginx nginx 305 Nov 27 14:35 msgXml.txt
-rw-r--r-- 1 nginx nginx 1 Nov 27 14:35 decrypt_result.txt
-rw-r--r-- 1 nginx nginx 219 Nov 27 14:35 requestQueryParams.txt
-rw-r--r-- 1 nginx nginx 573 Nov 27 14:35 requestRowBody.txt
-rw-r--r-- 1 nginx nginx 18 Nov 26 17:24 actionReceive.txt
[root@b21d3b4237a2 runtime]#
后面还有大量类似的文件列表。
这些内容有几个共同特征：
- 没有中文；
- 本身就是机器输出；
- 不应该被翻译；
- 最终仍然要求逐字保留。
这时问题就比较明显了。
五、旧 Plaintext 策略存在不必要的模型输入
原来的 Plaintext 处理思路大致是：
只要 Code Block Pro 的语言属于：
plaintextplaintexttxt
就建立一个 SWQPLAIN 区域。
如果内部没有中文，则通过 preserve_source 标记，等模型返回以后再恢复原始内容。
从最终输出正确性的角度看，这个方案没有明显问题。
因为即使模型修改了这些内容，恢复阶段最终仍然会使用原始内容。
但问题出在更前面：
这些最终一定会恢复原文的服务器日志，为什么还要完整发送给模型？
换句话说，旧流程实际上是：
原始机器日志
→ 发送给 GLM-5.2
→ 模型生成结果
→ 不采用模型结果
→ 恢复原始机器日志
模型做了一次最终不会被使用的工作。
普通文章中可能感觉不到问题，但 4652 恰好包含大量这种历史终端输出和文件列表。
结果就是：
- 增加模型输入长度；
- 增加 Token 消耗；
- 增加上下文噪声；
- 还可能让模型的内容安全检测接触到大量实际上不需要理解的机器文本。
因此，这里比继续修改 Prompt 更值得优化。
六、重新划分 Plaintext 与 SWQBLOCK
最终没有取消 Plaintext 机制，而是重新明确它的使用边界。
新的规则变成：
- 非
plaintext/plain/text/txt的 Code Block Pro，继续完整保护为SWQBLOCK； - Plaintext 中包含中文时，继续使用
SWQPLAIN； - Plaintext 中完全没有中文时，直接整体保护为
SWQBLOCK； - 纯机器输出不再进入模型正文 Payload；
- 翻译完成以后，仍然恢复原始 Code Block Pro 内容。
这样做以后，两类内容的边界就清楚了。
真正存在自然语言的内容：
中文说明 + 时间 + 状态信息
继续允许模型翻译。
而这类内容：
ls -lt
文件列表
Shell 输出
路径
服务器日志
时间戳列表
纯英文机器状态
则不再让模型看到内部正文。
它们对于模型来说只剩下类似：
SWQBLOCK00000xEND
这样的占位符。
七、先补测试，再部署到生产环境
这一次并没有直接修改生产代码后立即重试。
本地首先补充了 Plaintext 相关回归测试，重点验证：
- PHP 等普通 Code Block Pro 仍然转换为
SWQBLOCK； - 含中文 Plaintext 仍然转换为
SWQPLAIN； - 不含中文的 Plaintext 转换为
SWQBLOCK； - 纯机器日志、路径和文件列表不再进入模型 Payload；
- 翻译结束以后原始区块能够逐字恢复；
- 原来的 Protected Token 校验继续正常工作。
测试结果全部通过：
swq-plaintext-structure-test.php: pass
swq-token-validation-test.php: pass
swq-adjacent-token-repair-test.php: pass
swq-tail-struct-token-repair-test.php: pass
patch/token-normalization-tests.php: pass
PHP syntax: pass
git diff --check: pass
这里有一点对我来说比较重要：
没有为了绕过 HTTP 400 而降低结构校验强度。
该保护的结构仍然严格保护。
真正修改的是：
哪些内容值得进入模型上下文。
八、修复前后 Payload 出现巨大变化
新版 MU 插件部署到生产服务器以后，再次对同一篇 4652 生成诊断数据。
原始 WordPress 正文没有改变，但模型实际接收到的内容已经明显缩小。
| 项目 | 修复前 | 修复后 | 变化 |
|---|---|---|---|
| WordPress 正文字符数 | 583450 | 583450 | 不变 |
| 模型正文 Payload | 49938 | 8876 | 约减少 82.2% |
| Protected Count | 109 | 116 | +7 |
| Plaintext Region | 8 | 1 | -7 |
| Alt Region | 18 | 18 | 不变 |
| HTTP 请求消息长度 | 54848 | 13786 | 约减少 74.9% |
这几个数字能够非常直观地说明变化。
Plaintext Region：
8 → 1
而 Protected Count：
109 → 116
两边正好相差 7。
也就是说，原来的 7 个无中文 Plaintext 区块现在全部改成了整体 SWQBLOCK 保护。
只留下真正包含中文的那个 Plaintext Region 供模型处理。
模型正文 Payload 则从：
49938
下降到：
8876
减少了大约 82%。
真正发出的 HTTP 请求中，消息总长度也从：
54848
下降到：
13786
减少约 75%。
这里也说明了一个很实际的问题：
不是所有“Plaintext”都应该送给 AI。
编辑器中的语言类型只能说明它以纯文本形式显示，并不能说明这些内容一定属于“应该翻译的自然语言”。
九、修复 400 的过程中还遇到了 Ctrl+C 恢复问题
Plaintext 修复完成以后，准备重新验证 4652。
但之前的一次执行过程中，我曾经按过 Ctrl+C。
本地进程虽然被中断，服务器端已经发出的请求却不一定立即结束。
结果历史迁移状态留下了：
translation_started
以及：
execution_in_progress
随后在恢复这个任务时，又暴露出了 reconcile-attempts 的一个边界问题。
十、recovery_generation 没有隔离历史重试次数
此前的迁移程序已经支持：
recovery_generation
当中文源经过修改并执行 restart-from-current 时，会进入新的 recovery generation。
旧 generation 中的重试次数应该转入：
lifetime_retry_counts
而当前 generation 的：
retry_counts
则重新开始计算。
但问题在于，reconcile-attempts 当时扫描历史 attempt 事件时，没有完整按照 recovery_generation 过滤。
因此旧 generation 中已经结束的 resume attempt，又被计算到了当前 generation。
结果新的 generation 明明还没有真正耗尽重试次数，却出现：
resume retry limit exhausted
这个问题已经和 GLM-5.2 HTTP 400 没关系了，而是恢复状态协调过程暴露出的真实 Bug。
十一、增加 generation 隔离和 counter drift 修正
随后针对这个问题进行了两项最小调整。
首先，让：
- started attempt；
- terminated attempt；
- orphaned attempt；
都只在当前 recovery_generation 内进行恢复对账。
历史 Attempt 编号依然继续递增，便于审计，但旧 generation 不再占用新 generation 的重试额度。
修完以后，又发现还有一个遗留问题。
旧逻辑此前已经把错误的：
retry_counts.resume = 3
真正写进了状态文件。
即使 generation 过滤已经正确，程序仍然需要主动发现：
current_resume_count: 3
corrected_resume_count: 0
这种已经产生的计数漂移。
因此又增加了：
counter_drift
修正。
真实文章的 Preview 最终显示：
counter_drift: true
current_resume_count: 3
corrected_resume_count: 0
reconciliation_action: counter_drift_correction
eligible: true
planned_count: 1
修正后，再使用：
sync-execution
把迁移工作流恢复为：
ready_for_translation_resume
相关历史迁移测试最终达到：
124 tests passed
这也算是在解决 400 的过程中顺手发现并修复了一个真正的恢复流程边界问题。
十二、最后又遇到 WordPress REST Nonce 过期
等状态终于恢复以后，再次执行：
python3 bin/history-migration.py resume \
--post-id 4652 \
--execute
结果这次甚至没有进入 GLM-5.2。
WordPress REST API 预检直接返回：
HTTP request failed with status 403:
rest_cookie_invalid_nonce:
Cookie 检查失败
也就是说：
当前终端环境中的 WordPress REST Nonce 已经过期。
需要特别注意的是：
环境变量还存在，不代表里面的 Cookie 和 Nonce 仍然有效。
于是重新从同一个成功的 WordPress REST 请求中取得 Cookie 和 X-WP-Nonce，然后在当前终端覆盖：
read -r -s -p "请输入新的 WordPress Cookie：" WP_ADMIN_COOKIE
echo
export WP_ADMIN_COOKIE
read -r -s -p "请输入新的 X-WP-Nonce：" WP_REST_NONCE
echo
export WP_REST_NONCE
随后再次同步执行状态：
python3 bin/history-migration.py sync-execution \
--apply \
--json
再进行 Resume Preview：
python3 bin/history-migration.py resume \
--post-id 4652
终于重新得到：
模式: preview
完整性: ok
selected_count: 1
allowed_count: 1
- mixed-syntaxhighlighter-20260807-03 zh=4652 allowed=True blocked=-
说明迁移程序已经允许再次执行。
十三、重新执行以后终于 completed
最后再次运行：
python3 bin/history-migration.py resume \
--post-id 4652 \
--execute
这一次结果为：
模式: execute
完整性: ok
selected_count: 1
- zh=4652 result=completed category=completed returncode=0 error=
完成以后，再运行一次 Resume Preview：
python3 bin/history-migration.py resume \
--post-id 4652
得到：
模式: preview
完整性: ok
selected_count: 0
allowed_count: 0
这里的 0/0 已经不是失败。
而是因为 4652 已经进入：
completed
因此自然不会再成为 Resume 候选。
十四、最终成功 Trace 再次验证请求规模
成功以后立即检查：
/tmp/swq-glm52-execution-trace.jsonl
可以看到这次任务一共完成 3 个 GLM-5.2 请求单元：
titleexcerptcontent
其中正文开始时：
source_chars: 583450
message_text_chars: 13786
正文大约 30 秒后正常返回。
而此前发生 HTTP 400 时，相同文章正文请求中的：
message_text_chars
还是：
54848
也就是说，最终成功版本实际发送给 GLM-5.2 的消息规模已经比原来下降约 75%。
这和前面的：
model_payload_chars: 49938 → 8876
能够相互印证。
十五、能不能确定 HTTP 400 就是那 7 个 Plaintext 导致的？
这里还是需要区分“强证据”和“严格证明”。
目前已经确认：
- 这篇文章此前多次出现相同 HTTP 400；
- 标题与摘要可以成功，失败集中在正文；
- 简单调整标题和部分说明文字，并没有直接解决问题；
- 修复前存在 8 个 Plaintext Region；
- 其中 7 个属于没有中文的大量服务器日志和文件列表；
- 修改保护逻辑以后，这 7 个区块全部变成
SWQBLOCK； - 模型正文 Payload 从
49938降低到8876； - HTTP 请求消息长度从
54848降低到13786； - 最终真实生产翻译成功完成。
这一整套证据已经比较强。
但最终成功执行以前，我还更换了 GLM-5.2 使用的 API Key。
因此这并不是一个完全严格的单变量实验，不能直接得出：
之前所有 HTTP 400 都是那 7 个 Plaintext 区块导致的。
更准确的结论应该是：
大量本来不需要翻译的机器 Plaintext 被发送给 GLM-5.2，是这篇文章中一个明确存在、并且完全没有必要的输入变量。将这些内容改为整体保护以后，模型输入大幅缩小，同时真实生产翻译成功完成。
即使它不是此前 HTTP 400 的唯一原因，这项调整本身仍然值得保留。
因为它同时减少了：
- Token 消耗；
- 无意义的模型上下文；
- 机器日志带来的干扰；
- Plaintext 结构被模型重新组织的机会；
- 超长技术文章中的不确定因素。
十六、这次排查带来的另一个认识
最开始看到：
Bad Request (400)
以及：
系统检测到输入或生成内容可能包含不安全或敏感内容
很容易把注意力全部集中到：
“究竟是哪句话触发了安全检测？”
但这次真正有效的排查路线实际上是：
确认失败单元
→ 确认正文失败
→ 导出模型真实 Payload
→ 分析 SWQPLAIN 与 SWQBLOCK
→ 发现大量无需翻译的机器 Plaintext
→ 调整保护策略
→ Payload 大幅缩减
→ 恢复迁移状态
→ 更新过期 REST Nonce
→ 重新执行
→ completed
相比不断修改 Prompt 或尝试猜测敏感词，这种方式更容易得到可以重复验证的结果。
对于复杂 WordPress 历史文章，我现在越来越倾向于一个原则：
不要先问模型能不能正确处理这些内容，而应该先问这些内容有没有必要交给模型处理。
程序代码、服务器日志、文件列表、路径、机器输出，如果已经确定不需要翻译，那么直接完整保护通常比：
“发给模型，然后要求模型不要修改”
更加可靠。
真正需要翻译的人类语言，则继续让模型处理。
这一次 4652 从持续 HTTP 400，到最终：
result=completed
不仅解决了一篇历史文章，也进一步明确了 Plaintext 与机器数据之间应该如何划分边界。
对于后续还要继续处理的大量 WordPress 历史文章，这项调整应该也能减少类似超长正文带来的额外风险。
需要长期技术维护或远程问题排查？
我是拥有 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
发表回复