年度归档： 2026 年
-
在为 WordPress 中英文归档页增加 Adsterra Native Banner 时，前台始终无法及时显示最新模板内容。经过对 WPCode、PHP Snippet、Shortcode、Language Visibility、Block Template、CDN、W3 Total Cache Page Cache 与 Redis Object Cache 的逐层排查，最终确认 www 与 en 不同 Host 下的 W3TC Object Cache 保留了旧版 wp_template。分别清理两个域名上下文的 Object Cache，并重新生成对应 Page Cache 后，中英文广告均恢复正常。此次问题也暴露出现有多域名缓存同步机制对 wp_template 等结构性内容覆盖不足，下一步将重点完善已有 MU 插件，并继续处理首页最新文章仍停留在 7 月 28 日的问题。
-
记录一次 SlyTranslate + GLM-5.2 整篇翻译中的 Protected Token 校验失败排查过程。问题最初表现为文章尾部连续丢失 Gutenberg STRUCT Token，在增加 Tail STRUCT Repair、强化 Prompt 和 Tail Guard 后仍未解决。进一步分析发现，真正原因是中文文章中存在 Paragraph → Plaintext → Paragraph 的跨块自然语言结构，GLM 为生成更自然的英文主动重组内容，导致 Protected Token 顺序漂移。最终通过清理不必要的 Plaintext、让 Gutenberg 区块边界与自然语言语义边界保持一致，在不放宽严格 Token 验证的情况下成功完成 GLM-5.2 整篇翻译。
-
2026 年 7 月 30 日，我尝试使用新购买的 Type-C 转 VGA 线为 ThinkPad T570 连接副屏，但 Ubuntu 始终无法识别外接显示器。排查过程中先后检查了 Wayland、DRM、USB Type-C、UCSI、BIOS 和 Thunderbolt Controller，并将 BIOS 从 1.23 升级到 1.54。即使在 BIOS 阶段将 Boot Display Device 设置为 USB Type-C，副屏仍没有反应；通过 boltctl 强制让 Thunderbolt 上电后，Controller 也没有被系统枚举。综合现象来看，问题更可能位于 T570 的 USB-C / Thunderbolt 底层链路，而不是普通的 Ubuntu 双屏配置。考虑继续修复的时间成本，最终决定暂时停止排查，后续更倾向于购买一台原生支持 HDMI 的显示器作为副屏。
-
ThinkPad T570 在 Ubuntu 26.04 下连续出现挂起后黑屏问题。日志显示系统实际上已经完成唤醒，但显示链路未能正常恢复，普通系统更新后问题仍可复现。考虑到电脑长期连接电源使用，最终不再继续折腾内核和显卡，而是关闭自动挂起，并通过 systemd 禁止合盖触发挂起，只保留自动息屏。实际合盖测试通过，重新掀开屏幕后可以继续原来的工作。
-
在完成 Gutenberg + SyntaxHighlighter 历史文章迁移后，我继续处理 Mixed Gutenberg / Classic + SyntaxHighlighter 文章，并整理出每天固定处理 20 篇的完整 SOP。流程包括 Classic 内容规范化为 Gutenberg、SyntaxHighlighter 转 Code Block Pro、代码语言核对、生产只读验证、中文摘要生成和英文覆盖翻译。经过连续两批共 40 篇真实文章验证，流程同时覆盖了 SSH 超时有限重试、翻译失败单篇 resume，以及 selected_count=0 但批次仍未完成等异常情况，最终形成一套可以长期重复执行的历史文章迁移方案。
-
收到 Zoog Affiliate Manager 关于中国大陆访问问题的正式回复后，我进一步注册并实测了 Zoog Affiliate Program。本文记录普通 Zoog 账号与联盟账号的区别、注册与审核过程、Crypto 收款方式、General / China / Russia 三类推广链接的实际差异，以及当前佣金、Cookie、最低提现和点击统计等规则，重点总结 Zoog 联盟后台中容易产生误解的几个细节。
-
此前我曾对 Zoog 在中国大陆网络环境下的实际访问情况进行测试，并将发现的问题反馈给官方。2026 年 7 月 28 日，我收到 Zoog Affiliate Manager 的正式回复。官方确认中国大陆访问可用性是其面临的重要挑战之一，并表示会持续监测域名状态、调整推荐入口。随后我注册 Zoog Affiliate Program，发现后台也提供了面向中国用户的专属推广入口。本文记录这次官方回应及后续验证结果。
-
在再次出现 CPU 告警后，我暂时停止继续追查瞬时负载根因，转而重新启用 W3 Total Cache 页面预缓存，并从 900 秒 × 5 页 的保守配置逐步优化。通过准确统计中英文 Yoast Sitemap，确认真正需要预缓存的页面为 6270 个，并自动生成 www + en 联合 W3TC 专用 Sitemap，每小时同步更新。最终将 W3TC Page Cache、EdgeOne 中文站和 Cloudflare 英文站的缓存生命周期统一调整为 96 小时，同时采用 300 秒 × 7 页 的低批量持续预热策略，在降低冷缓存回源和 PHP 动态生成压力的同时，避免预缓存本身制造新的 CPU 峰值。
-
Codex 扩展更新到 26.721.41059 后，出现了 Fast 模式提示：根据上周 8 个 chats 的使用情况，Fast 预计可节省约 57 分钟，但同时会增加套餐使用量。结合 OpenAI 官方 Codex Speed 与 Rate Card 文档，可以确认 Fast 的本质是用更高的 credits 消耗换取更快的执行速度，而不是提高套餐额度利用效率。对日常使用来说，Standard 更适合作为默认选择，Fast 则适合需要连续修改、测试和快速反馈时临时开启。
-
2026 年 7 月 29 日，我将 VS Code 从 1.129.1 升级到 1.130.0 后，之前持续加载、灰屏和白屏的 Codex 面板恢复正常。更关键的是，此时 Codex 扩展仍保持之前回退的一周前版本 26.715.61943，并未更新到最新版本。这进一步说明此前故障更可能与 VS Code 本体、Webview 运行环境或版本兼容性有关，而不是单纯由 Codex 扩展版本导致。