没有不值得去解决的问题,也没有不值得去学习的技术!

  • WordPress 站点健康从 6 个推荐项降到 3 个:清理旧主题插件、关闭调试日志与评论功能

    WordPress 站点健康从 6 个推荐项降到 3 个:清理旧主题插件、关闭调试日志与评论功能

    今天继续整理 WordPress 生产站的站点健康状态。最初后台显示 6 个“推荐的改进”,包括未启用的插件、未启用的主题、陈旧的 SQL 服务器、公开可访问的调试日志、评论分页,以及固定链接中没有文章名。排查过程中删除了 5 个不再使用的旧主题和 12 个已经没有实际用途的插件,升级 Akismet,关闭 WordPress 调试日志,并结合当前页面缓存与 CDN 架构,最终决定关闭文章评论及 Pingback/Trackback,同时保留历史评论数据。处理完成后,站点健康推荐项由 6 个减少到 3 个;剩余项目则分别因为 Cloudflare 插件暂时保留、阿里云 RDS MySQL 5.7 暂时无法升级,以及现有固定链接结构不适合为消除提示而贸然修改,因此选择保持现状。

  • 103/103 与 7/7 Exact Match:A Tour of Go ChatGPT 新译文的最终线上验收

    103/103 与 7/7 Exact Match:A Tour of Go ChatGPT 新译文的最终线上验收

    在完成 A Tour of Go 简体中文 103 个正式课程页面的 ChatGPT 全量重译、语义审核和 canonical promotion 之后,本轮继续完成最终生产上线验收。当前生产环境已经切换到正式 release 20260818-zh-CN-45f4cad,103 个正式课程路由全部返回 HTTP 200,7 个 article endpoint 的 production origin 与 EdgeOne 公网响应达到 7/7 exact match,同时新的 ChatGPT 译文标记存在、旧版译文标记已经消失。真实 Run 与 Format 请求也均返回 HTTP 200,并得到预期执行和格式化结果;/socket 等不应公开的路径继续保持 404。结合 EdgeOne 的 HIT 与 Age 结果,本次发布在没有执行全站缓存刷新的情况下仍然确认公网已完整返回新 release,因此后续更适合采用“先验收、发现 stale URL 后再 targeted purge”的缓存处理方式。至此,103 页 ChatGPT 重译从翻译、审核、正式提升到生产上线和公网验收的完整…

  • 103 页翻完还不能发布:A Tour of Go ChatGPT 译文的语义审核与 Canonical Promotion

    103 页翻完还不能发布:A Tour of Go ChatGPT 译文的语义审核与 Canonical Promotion

    在完成 A Tour of Go 简体中文 103 个正式课程页面的 ChatGPT 全量重译后,我没有立即覆盖现有正式译文,而是继续进行了完整语义质量审核,并使用 A/B/C/D 四级标准区分“可以直接发布”“可选优化”“建议修订”和“必须修复”。审核过程中曾有 2 页处于 B 级,本身已经达到发布质量,但由于最终只剩少量页面且修改成本很低,仍继续 revision,最终达到 A=103、B/C/D=0。随后项目进一步完善 canonical promotion 的 evidence chain、retry provenance 与 EOF normalization,确认每个正式 candidate 都能追溯到对应的 ChatGPT 原始译文和最终有效 attempt。正式 apply 后 103 页中 102 页发生变化,80 页完成确定性 EOF normalization,再次 dry-run 得到 0 changed、103 unchanged,完整测试最终通过。结合 103 页全量重译、完整语义审核和统一工程验证,我对当前 zh-CN 的内部综合质量评价由原来的约 94 …

  • 没有 OpenAI API,我如何用 ChatGPT + GitHub 完成 A Tour of Go 103 页全量重译

    没有 OpenAI API,我如何用 ChatGPT + GitHub 完成 A Tour of Go 103 页全量重译

    在 A Tour of Go 简体中文项目中,上一篇实验已经确认 ChatGPT 值得作为新的 Translation Engine 继续扩大验证。本轮进一步将实验扩展到全部 103 个正式课程页面,并通过固定 retranslation batch、GitHub 数据交接、ChatGPT 整页翻译、raw response 保存、restore、统一 validator 与有限 retry,完成 103/103 全量重译。整个过程没有改变原有完整 present.Section 翻译单元和结构校验体系,而是利用 ChatGPT + GitHub 减少大量人工复制粘贴,并通过 11 个 Batch、独立 Git 提交和历史 evidence 保留,使新的 ChatGPT 译文能够进入可追踪、可校验的工程流程,为后续完整语义审核和 canonical promotion 做好准备。

  • WordPress 历史文章迁移终于收尾:全量审计 1438 篇中文文章,并停用 SyntaxHighlighter Evolved

    在持续处理 WordPress 历史文章摘要、旧代码格式、SyntaxHighlighter 短代码及中英文覆盖翻译之后,这一轮历史迁移终于正式收尾。最终 67 个固定批次、1281 篇历史文章全部完成,remaining=0、integrity=ok。为准备退役 SyntaxHighlighter Evolved,又重新同步并审计了 1438 篇中文已发布文章,最终只有 14 篇进入人工检查,真正需要迁移到 Code Pro 的文章不到 5 篇。审计工具、配置、测试和历史迁移状态也已完成 Git 收口,503 项测试通过。发布本文前,SyntaxHighlighter Evolved 已正式停用,插件文件暂时保留约 5 天,等待旧页面缓存自然退出后再彻底删除。

  • 阿里云 ECS 系统盘占用超过 80%:清理 PHP、Nginx、Redis 升级残留后从 81% 降至 42%

    阿里云 ECS 系统盘占用超过 80%:清理 PHP、Nginx、Redis 升级残留后从 81% 降至 42%

    阿里云 ECS 20GB 系统盘使用率升至 81% 并持续触发告警后,对服务器磁盘占用进行逐项排查。确认 PHP 8.5、Nginx 1.30.4、Redis 8.10.0 当前生产运行路径后,清理升级遗留的构建目录、源码、回滚备份和旧 OneinStack 归档,同时处理 824MB PHP-FPM 异常日志、约 2GB systemd journal,以及已经完成使命的 WordPress 历史文章处理目录。最终系统盘使用率从 81% 降至 42%,可用空间增加至约 11GB,并完成 Nginx、PHP-FPM、Redis 运行状态验证。

  • A Tour of Go 翻译质量再评估:minimal-protect 未达预期后,我开始比较 ChatGPT、Codex 与 GLM-5.2

    A Tour of Go 翻译质量再评估:minimal-protect 未达预期后,我开始比较 ChatGPT、Codex 与 GLM-5.2

    在完成 A Tour of Go 简体中文 103 个课程页面后,我继续验证如何把现有约 94 分的工程性翻译质量进一步提升到 96~97 分。最初重点研究 minimal-protect,希望通过减少 protected token、保留更多原始上下文改善 GLM-5.2 译文,但后续对 157 个 protected token 的信息损失审计、Static Context 实验以及重复请求测试均未显示稳定质量优势,因此优化重点从 Protection Policy 转向 Translation Engine。本轮选取 methods/24、concurrency/7、concurrency/11 三个代表页,由 ChatGPT、Codex Sol 和 GLM-5.2 独立生成最终译文,再交给 ChatGPT、DeepSeek、GLM-5.2 和豆包进行 12 次匿名质量评审。ChatGPT 获得 8/12 第一名,即使排除自身作为评审模型后仍获得 5/9 第一名。现阶段不会立即覆盖已有 103 页,而是准备进一步验证自动化 ChatGPT retranslation stagin…

  • A Tour of Go 翻译实验:更多原始上下文为什么没有更好?从 157 个保护标记到 30 次重复盲评

    A Tour of Go 翻译实验:更多原始上下文为什么没有更好?从 157 个保护标记到 30 次重复盲评

    在 A Tour of Go 简体中文翻译流程中,我一直担心大量 protected token 会遮挡模型上下文,从而影响 GLM-5.2 的翻译质量。为验证这一点,我先将保护策略缩减到 minimal-v1,又进一步设计了只额外暴露静态代码的 Static Context 单变量实验。结果却逐渐指向另一个问题:7 个代表页中的 157 个保护标记并没有隐藏任何可翻译英文自然语言,而完全相同的 API Request 在 5 个页面上全部生成了不同的 Response。随后通过 5 页、2 种模式、3 次独立运行共 30 个计划样本,并对所有通过结构校验的译文进行匿名多候选排名,最终发现模型自身的运行间波动明显大于目前能够观察到的 Static Context 质量收益。基于这一结果,正式翻译流程继续保留成熟的 Default protected-token 方案,而 minimal-v1 与 Static Context 保留为开发实验能力。

  • A Tour of Go 中文翻译完成后,我为什么重新评估 minimal-protect 翻译模式

    A Tour of Go 中文翻译完成后,我为什么重新评估 minimal-protect 翻译模式

    A Tour of Go 简体中文第一阶段 103 个课程页面已经全部进入 ready 状态。在现有版本已经具备较高翻译质量和完整发布能力后,我重新评估此前暂时搁置的 minimal-protect 翻译模式。当前 zh-CN 译文工程性估计约为 94 分,而成熟的 minimal-protect 目标希望达到 96~97 分。通过 methods/24 的真实实验可以看到,raw-input 会错误修改 .play 指令,而 minimal-protect 只保护完整 .play 后成功消除了这一问题,同时让 validator 继续发现 link inline-code 和 font span 等下一层结构差异。同页对比中,默认 protected-token 使用 15 个保护 token,而 minimal-protect 仅使用 1 个,更多原始上下文可以直接交给 GLM-5.2。后续将继续使用原有 7 个代表页验证翻译质量、结构稳定性、重试成本和跨语言保护规则的复用程度,再决定是否正式切换默认模式。

  • A Tour of Go 搜索引擎收录实测:从 Google 自然索引到百度主动提交与 Bing IndexNow

    A Tour of Go 搜索引擎收录实测:从 Google 自然索引到百度主动提交与 Bing IndexNow

    A Tour of Go 简体中文站点完成 Sitemap 提交后,进一步实测 Google、Bing、360、百度与搜狗的实际索引状态。Google 已开始自然抓取并建立索引,Bing 已发现页面但尚未抓取,因此通过 IndexNow 一次主动提交全部 104 个 URL;百度普通收录 API 则受每日 10 条额度限制,最终只提交首页和核心课程入口。结合 360 暂无索引数据以及搜狗主站“收录量高、索引量低”的实际表现,最终决定停止持续人工主动提交,让后续页面依靠 Sitemap、内部链接和搜索引擎自然抓取完成收录。

👨‍💻 个人品牌

王世强|PHP / Go 技术顾问

15+ 年 Web 后端开发经验,专注于系统维护、架构优化、性能调优及 Linux 运维。

持续运营技术博客 10+ 年,累计发布 1000+ 篇原创技术文章。

为创业团队、中小企业及独立开发者提供长期技术支持与远程合作服务。

👉 关于我 & 合作

.env (14) 404 (13) add (16) AI 翻译 (24) Apache (13) Array (19) A Tour of Go (39) Cache (13) CentOS (23) chrome (19) Cloudflare (28) Codex (14) composer (42) composer.json (22) composer install (13) composer update (14) console (16) Container (25) curl (15) delete (31) Docker (32) Dockerfile (15) EdgeOne (30) environment variable (19) error (24) Failed (13) file (15) filter (20) Git (27) GitHub (21) Gitlab (15) GLM-5.2 (26) Go (49) Google AdSense (22) Go 语言 (23) GraphQL (24) GraphQL API (14) Gutenberg (33) http (21) https (22) Interface (19) Jquery (13) json (24) Laravel (37) Laravel 6 (55) Laravel 9 (25) Lighthouse (17) Lighthouse 5 (14) Linux (21) Migrate (13) Module (17) MySQL (78) MySQL 5.7 (21) Nginx (63) normalize.css (28) OKX (15) OneinStack (21) PHP (67) php-fpm (18) php.ini (24) PHP 7.1.12 (22) PHP 7.4 (26) phpmyadmin (15) PhpStorm (24) Polylang (57) postman (18) Query (17) queue (16) Rancher (24) Redis (49) response (13) RESTful (27) RESTful API (23) Shell (13) Shopify (19) SlyTranslate (20) SQL (24) String (14) TortoiseGit (14) Twenty Twenty-Five (20) Ubuntu (40) update (20) VPN (17) W3 Total Cache (35) Windows 10 (46) WireGuard (27) WordPress (124) WordPress 多语言 (13) WPCode (23) Wstunnel (14) Yii (40) Yii 2 (70) Yii 2.0 (51) 命令行 (13) 多语言翻译 (23) 技术博客 (15) 故障排查 (14) 数据库迁移 (16) 浏览器 (14) 阿里云 (19)

2026 年 8 月
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Most Viewed Posts

  1. 从 LetsVPN 停用至自建 WireGuard VPN 全流程复盘(附避坑指南) (7,571)
  2. 使用中国大陆手机号登录 Telegram,弹出 SMS Fee 且支付选项不支持,购买 Premium 后短信验证码未收到的完整解决流程 (5,391)
  3. ZgoCloud + Wstunnel + WireGuard 提速 4 倍,Clash Verge Rev 自动分流与 443 端口防封实战 (4,888)
  4. WireGuard 国内直连+国外走隧道 配置踩坑与完美解决(实测可用) (3,914)
  5. WireGuard VPN 配置优化:国内网站直连,国外流量走VPN(实测有效) (2,102)
  6. 基于 yiisoft/yii2-app-advanced,在 GitHub 上新建仓库 yii2-app-advanced,新建接口应用(实现 RESTful 风格的 Web Service 服务的 API),新建api目录、配置和环境、测试、Vagrant等的支持 (1,340)
  7. 一直收到 Huobi.info 的账户管理费收取通知,决定提取出剩余的资产 (1,327)
  8. 基于 yiisoft/yii2-app-advanced,在 GitHub 上新建仓库 yii2-app-advanced,新建接口应用(实现 RESTful 风格的 Web Service 服务的 API),在 api 的 tests 目录中准备用户相关操作的一些自动化测试的样例(API 测试),确保应用程序在改变或增加新的功能时不会影响现有的功能 (1,309)
  9. 基于 yiisoft/yii2-app-advanced,在 GitHub 上新建仓库 yii2-app-advanced,新建接口应用(实现 RESTful 风格的 Web Service 服务的 API),实现模型分层:数据层、逻辑层,明确公共目录、应用、模块的继承、引用关系 (1,284)
  10. 基于 yiisoft/yii2-app-advanced,在 GitHub 上新建仓库 yii2-app-advanced,新建接口应用(实现 RESTful 风格的 Web Service 服务的 API),实现 RESTful Web 服务,支持国际化(动态地设置目标语言,默认为简体中文) (1,276)