TjSky | 秋风于渭水修改

2026-03-16 15:25:47

免责声明： 本文仅作为网络安全技术探讨与供应链安全案例分析。文中所引用的测试数据及文件路径均来自公开网络渠道及官方公开发布的软件安装包，不涉及任何非法逆向工程、破解或入侵行为。文章旨在提醒广大开发者重视密钥管理规范，并建议相关用户注意潜在的网络通信风险。若涉及厂商已发布官方修复公告，请以官方信息为准。

近日，某安全社区内有研究人员指出，在 某数字 公司近期发布的 AI Agent 产品 “安全龙虾”（基于 OpenClaw）的公开安装包中，疑似意外包含了其官方泛域名证书的私钥文件。

这一发现引发了技术圈对于客户端打包规范以及 WebPKI 证书吊销机制的广泛讨论。本文将从技术角度对该事件进行客观验证与风险分析。

1. 事件概览与技术验证

根据网络社区公开的信息，在官方提供的软件目录树中，存在一个名为 credentials 的明文文件夹，具体路径如下：
/path/to/namiclaw/components/Openclaw/openclaw.7z/credentials

该目录内包含了 *.myc***.36X.cn 的 Wildcard DV（泛域名）证书及其对应的私钥。

为了验证该私钥与证书的匹配性，我们可以通过标准的 OpenSSL 工具分别提取私钥和证书的 Modulus（模数）进行 MD5 哈希比对：

> openssl rsa -modulus -noout -in myc***.36X.cn.key  | openssl md5
MD5(stdin)= 446097b7674080186a469ecb0945f5af

> openssl x509 -modulus -noout -in myc***.36X.cn.crt | openssl md5
MD5(stdin)= 446097b7674080186a469ecb0945f5af

输出结果显示，两者的 MD5 指纹完全一致，在技术上证实了该 .key 文件确为对应官方泛域名证书的有效私钥。

2. 潜在的安全风险评估

将泛域名私钥直接打包进公开发布的客户端，在安全工程实践中属于较高风险的配置失误。其实际影响主要体现在以下几个维度：

• 中间人攻击 (MITM) 风险： 掌握私钥的第三方可以在网络链路（如公共 Wi-Fi、局域网等）上完美伪造属于 *.my****.36X.cn 旗下的任何服务端节点。由于客户端和系统会信任该合法证书，HTTPS 的加密隧道形同虚设，流量可被实时解密。

• 敏感凭据暴露： 考虑到 OpenClaw 是一款 AI Agent 工具，用户通常会在其中配置各类大语言模型（如 OpenAI, Claude 等）的 API Key。若发生上述中间人劫持，这些高价值的通信凭据存在被明文截获的理论风险。

• 供应链劫持可能： 若该客户端的某些更新或指令下发机制依赖于该子域名的 HTTPS 验证，恶意攻击者可能利用伪造的服务器向客户端下发未经授权的指令或恶意代码。

3. CA 响应延迟与合规性探讨

除了开发环节的打包疏漏，本次事件在证书管理（PKI）层面的响应时间也值得关注。

根据公开的证书透明度（CT）日志（如 crt.sh ID: 24937759962），该证书由 WoTrus（沃通）于 2026年3月12日签发。截至本文撰写之时（距离私钥被公开讨论已接近1天），该证书状态依然为 Valid（有效）。

参照 CA/Browser Forum Baseline Requirements 的行业通行规定（4.9.1.1 章节），当 CA 机构意识到证书私钥可能已遭泄露（Compromised）时，应当在 24 小时内执行吊销（Revoke）操作。此次事件中响应的延迟，暴露出相关主体在漏洞响应（IR）流程上可能存在一定的滞后，这也给 WoTrus 带来了潜在的合规审查压力。

更新 2026-03-16 08:07:16 UTC 时刻，证书 OCSP 显示 Revoked （吊销）
不过鉴于大部分浏览器对无法访问 OCSP 验证服务器时会采取“软失败”配置，仅靠 OCSP 证书吊销验证并不能有效防御中间人攻击（能做中间人攻击的人，顺手拦截掉 OCSP 流量也很容易）

4. 修复建议与总结

对于安全开发生命周期（SDL）而言，高等级的泛域名私钥应当严格存放在硬件安全模块（HSM）或专用的密钥管理系统（KMS）中，开发人员本应无法接触到私钥本体。即使出于这样那样的原因，允许开发人员直接接触私钥，也应配合 CI/CD 流水线的 Secret 扫描机制，防止重要凭据硬编码或被意外打包进公开发布版本。

5. 对于使用某数字安全龙虾的终端用户

出于谨慎起见，建议在官方发布包含新证书的修复版本并吊销旧证书之前，暂时避免在存在不可信网络环境的设备上使用该特定版本的客户端。同时，若曾在其中输入过高价值的 API 密钥，建议前往对应的服务商后台进行重置（Regenerate）操作，以确保资产安全。

其实谁都有写出 Bug 的时候，但这波操作实在有点过于草台班子了，不要为了快的抢先发布，而跳过开发流程的安全检查。这次幸亏只是一个*.myc***.36X.cn，要是不小心泄露了更核心的*.36X.cn的私钥，整个公司所有软件的安全信任体系可就全炸了。

6. 360公司私钥泄露事件的说明

业务因失误将内部域名证书打包到安装包里，证书对应域名是 *.myclaw.360.cn，实际解析地址是 127.0.0.1 本地回环地址，该证书仅在本地使用，不会对外提供任何服务。
发现问题后 360 安全团队立即申请吊销这份证书，目前证书已经失效，无法再用于任何合法的 HTTPS 加密通信，普通用户也不会受到任何影响。
公司已启动内部排查流程，将进一步优化安全管理机制，防范类似疏漏再次发生。

本文 【资讯】离谱！某数字安全大厂 AI 客户端竟“附赠”自己泛域名的私钥？ 最初发表于 秋风于渭水。

2026-03-13 18:03:59

前言

没想到，我最终还是被非中文垃圾评论逼疯了，我的小破站也有被垃圾评论淹没的一天。
最近（这半年）国外的 SPAM Bot 像是冲业绩一样，对着我的评论区狂轰滥炸。
给你们看一眼后台 Akismet 的统计数据：

虽然上个月 Akismet 默默帮我吃掉了 1700 多条纯英文的博彩和 SEO 垃圾评论，并且正确率高达 99.9%，在近 7000 条评论中，漏网的 SPAM 评论数量为 0，假阳性（将正常评论误判为 SPAM）的数量也只有 5 条，可以说 Akismet 工作得非常好。

但问题是，这些被拦截的非中文垃圾评论，会全堆在后台的“垃圾”列表里。之前这个数字涨得还比较慢，我基本每周点一次「清空」，最近这个数字涨得实在太快了，简直是在疯狂折磨我的强迫症！搞得我现在只要进后台就要手动点“清空垃圾”。

上个月一直在折腾前端机反代的事情（详见《忍痛割爱“负优化”腾讯云！年付不到200元，我换到了这台“真香”的香港前端机》）。最近基础的缓存问题、前端轻量化 WAF 都搞得差不多了，我决定从源头上给这帮瞎撞的机器人一点颜色看看。

踩坑第一步：中文互联网上的祖传 WordPress 禁止非中文评论代码

解决思路很清楚：通过后端的 PHP 或前端的 JS，检查提交的评论内容，禁止中文数量太少的评论和直接 POST 到接口的评论。我印象中不止一位博主写过类似的文章，可惜我在 RSS 阅读器里搜了几下，什么都没找到。

遇到问题先“面向 Google 编程”，没必要重复造轮子嘛，搜“WordPress 禁止非中文评论”，不出意外地，满屏的 CV 工程师都在发同一段祖传代码（以及它的徒子徒孙们），各种代码之间的不同之处，无非是写了更多的正则去匹配日语、韩语等语言，改了点报错文本的措辞罢了，它们的核心都是下边这个代码：

// 屏蔽非中文评论 (注意，这个代码超垃圾，千万别用！)
function refused_spam_comments( $comment_data ){
    $pattern = '/[一-龥]/u';
    if(!preg_match($pattern,$comment_data['comment_content'])){
        err( "我擦，你竟然是歪果仁！看不懂你的评论..." );
    }
    return( $comment_data );
}
add_filter('preprocess_comment','refused_spam_comments');

我差点没一口老血喷出来，这都啥祖传垃圾代码啊，槽点密集到无可复加，大家且听我逐一吐槽：

1. 化石级的正则写法： 首先这个正则 /[一-龥]/u，先不说这个正则区间里混进了多少不是中文的奇怪东西。就这写法，纯纯是化石级的写法，我印象里只有 2000 年之前就接触编程的老古董会这样写，因为当年的很多教材就这样写的，他们习惯了。这段核心代码出现的年代绝对不可能早于 2010 年。在 2026 年的当下，匹配中文就算不用 /\p{Unified_Ideograph}/u（匹配中文）或 /\p{Script=Han}/u（匹配中文和中文标点），也要写成 /[\u4e00-\u9fa5]/u 吧（兼容 IE11 等老浏览器）。我寻思，JavaScript 从最初版本 (1997年)就开始支持 \uXXXX了吧？。
2. 令人窒息的报错文案： 这个错误信息写的是个什么鬼玩意 err( "我擦，你竟然是歪果仁！可惜博主的英文太烂，看不懂你的评论，学会汉字再来评论吧..." ); 这个语气，就让我仿佛回到了高中时代的 QQ 空间。
3. 不存在的函数： 最成问题的地方是：这个 err() 函数是哪里冒出来的啊？WordPress 里根本没有这个函数吧！经过我一番 AI 检索，哦，这是当年某个流行主题的自定义函数，主题没有WordPress的原生评论系统，而是用自己写了一个 comments-ajax.php 作为评论系统，使用err() 实现前端报错。因此这个最后的钩子 add_filter('preprocess_comment','refused_spam_comments'); 存在同样的问题，因为代码中没有使用 WordPress 原生的 wp_die() 函数来终止程序，而且咱们也不用那个主题，自然也就没有 err() 函数，部署上去妥妥会炸。
4. 防不住的逻辑： 这个过滤思路也是有问题的，因为它的规则是只要评论内容里包含至少一个汉字，就算通过。现代的垃圾评论群发脚本（Spam Bot）早就进化了，这样过滤是防不住的。

踩坑第二步：被自家前端缓存“物理降维打击”

既然“面向 Google 编程”不成功，那就自己造轮子呗。不过这时候我灵光一闪，其实我的需求并不是完全靠自己解决垃圾评论的过滤问题，而是尽量在评论到达 Akismet 之前，就检测出对方是不是机器人。

所以我决定简单点，一贯不想增加插件负担的我，在后端用 PHP 给评论表单偷偷塞一个隐藏的当前时间戳。访客提交时一减，如果发现他从打开页面到点提交用时小于 6 秒，绝对是机器，当场弄死。

// 基于 PHP 的时间检测代码片段
// 1. 在前端评论表单注入一个“隐形时间戳”
function tjsky_add_comment_time_trap() {
    echo '<input type="hidden" name="comment_render_time" value="' . time() . '">';
}
// 2. 检测对比打开页面后和提交时的时间戳
if (isset($_POST['comment_render_time'])) {
    $render_time = (int)$_POST['comment_render_time'];
    $time_spent = time() - $render_time;
    // 3. 如果从打开页面到点提交不到 6 秒，绝对是机器，弄死。
    if ($time_spent < 6) {
        tjsky_reject_comment();
    }
} else {
    // 4. 如果连隐藏的时间戳都没有，说明是直接往接口 POST 数据的，更要弄死。
    tjsky_reject_comment();
}

兴冲冲部署上去了，过了一天我发现：怎么没效果啊？思考良久后我一拍大腿反应过来了。我他喵的现在是香港前端机 Nginx 反代并缓存加速 + 后端机的技术路线了，不是原来的前端机端口透传方案。

也就是说，访客看到的页面，早就被 Nginx 缓存在香港节点了！PHP 输出的那个隐藏时间戳，会永远停留在缓存生成的那一秒。一个爬虫过来抓取页面并 POST，后端一算：当前时间减去缓存的时间戳，好家伙，早超过 6 秒了，直接判定为“人类”，完美绕过陷阱！

结论：后端 PHP 动态时间戳在静态缓存架构下完全失效。（折腾半天，小丑竟是我自己）

踩坑第三步：现在的垃圾评论脚本竟然有 JS 运行环境了？

既然 PHP 生成时间戳行不通，那就只能让访客的浏览器端动态生成了。往前端塞了一小段 JavaScript 脚本，在页面加载完后，用 JS 把时间戳令牌塞进表单。因为很多针对 WordPress 的低级垃圾评论机器人只抓 HTML 分析，并不执行 JS，这一招应该可以完美解决缓存问题了吧。

新版代码特性：

1. 改用 JavaScript 生成检测时间戳，并提交后端页面打开时刻和提交评论时刻的时间差值，小于 6 秒的直接干掉。
2. 这里采用记录执行函数来记录脚本解析时刻的 loadTime，而不是等待页面加载完成触发 DOMContentLoaded 再记录时间。这是为了以防网络不好时，页面加载完成和提交评论的时间间隔过短（虽然理论上不至于……但以防万一嘛）。
3. 令牌完全由 JS 动态生成，不依赖页面缓存，后端执行的判断轻量简单。

// 基于 JavaScript 的时间检测代码片段
(function() {
    // 记录脚本解析时刻的时间戳
    var loadTime = Math.floor(Date.now() / 1000);
    document.addEventListener('DOMContentLoaded', function() {
        // 往评论表单里写入隐形的时间戳
        var forms = document.querySelectorAll('form[action*="wp-comments-post.php"], #commentform, #comment-form');
        forms.forEach(function(form) {
            if (!form.querySelector('input[name="js_spamtrap_token"]')) {
                var jsToken = document.createElement('input');
                jsToken.type = 'hidden';
                jsToken.name = 'js_spamtrap_token';
                jsToken.value = 'is_human_0'; 
                form.appendChild(jsToken);

                // 在评论提交的瞬间，计算时间差
                form.addEventListener('submit', function() {
                    var submitTime = Math.floor(Date.now() / 1000);
                    var timeDiff = submitTime - loadTime;
                    jsToken.value = 'is_human_' + timeDiff;
                });
            }
        });
    });
})();

结果：部署上去后测试了 1 天，垃圾评论数量大量减少，大概只有原来 20% 的垃圾评论到达了 Akismet，主要是几个做垃圾 SEO 的评论。不过它们居然绕过了 JS 时间差检测，这倒是有点出乎我的意料。从后台记录的时间差看，它们基本是在打开页面 1~2 分钟后提交的评论。现在的垃圾评论有点先进哦，居然有 JS 运行环境，而且会模拟人类的阅读行为？

得，还是要回到检测非中文评论的路子上来。

踩坑第四步：技术博客的“高频误伤区”

首先，我不能设置“只要含有少量中文就放行”的规则，因为我见过会复制我文章标题来伪装的垃圾评论，所以我决定设置为“纯中文字符占比低于 20% 直接拦截”。

写完后，我让 AI 写了个测试脚本，从博客的数据库里拉了 100 条正常评论和 100 条垃圾评论，在真实环境下做测试，结果喜迎再次翻车。

“有效汉字比例小于 20%”的拦截规则，对于生活类博客确实好使，但别忘了这里是一个技术博客（虽然我最近没怎么写教程吧）。
一旦遇到某位老哥跟着我的教程部署/安装代码时报错了，他很有可能会在评论区糊上一大段全英文的报错日志或配置代码，末尾才带了一句：“大佬，报错了，运行后显示这个怎么办”等等很短的一句话。
按照我的规则很容易就直接弹个 403 把友军给厚葬了，这绝对是反人类的。

有人可能会说：那拦截的时候，你直接在报错页面提示他“您的评论中文字符比例过少，请去掉代码重新组织语言”不就行了嘛？

我跟你讲，你可千万别啊！永远不要在报错里给黑客当老师。如果你把具体的规则明明白白写在脸上，灰产作者虽然不会时时刻刻盯着报错看，但回头在脚本里加个正则，随机抓取正文里的中文字符来凑数的案例可是有过的。真正的防御必须是“外松内紧”，统一返回个“缺少有效上下文”的障眼法，让他自己猜去吧。

明确了痛点，我把最终的逻辑梳理成了下面这样：

🎯 最终防御逻辑流程图

1. 前端埋点： JS 记录页面打开时间 ➡️ 访客点击“提交” ➡️ JS 计算时间差并塞入表单隐藏字段。
2. 第一道防线（过滤低级爬虫）： 后端检测时间差。如果没有字段（未执行 JS）或用时 < 6 秒 ➡️ 直接拦截。
3. 技术博客绿色通道（豁免友军）： 评论包含 Markdown/HTML 代码块，且汉字数 ≥ 10 个 ➡️ 直接放行交由 Akismet 审查。
4. 第二道防线（过滤高级非中文 Spam）： 剔除代码块和 URL 链接后，计算剩余内容的汉字占比。如果纯汉字 < 2 个或占比 < 20% ➡️ 直接拦截。

省流太长不看版（终极方案）

如果你的 WordPress 博客充斥着大量非中文垃圾评论，并且有前端缓存、CDN、静态化之类的东西，可以试试下边这套经过无数次踩坑打磨出来的无插件防御 SPAM 代码，直接扔到你的 functions.php 里即可：

/**
 * 评论区终极防 SPAM 护盾 (适配 Nginx 反代缓存 + 技术博客代码块豁免)
 */

// ==========================================
// 1. 前端 JS 注入：动态计算停留时间，完美绕过页面缓存
// ==========================================
add_action('wp_footer', 'tjsky_add_js_time_trap');
function tjsky_add_js_time_trap() {
    if (is_singular() && comments_open()) {
        ?>
        <script type="text/javascript">
        (function() {
            // 核心魔法 1：只要浏览器解析到这段 JS，立刻记录初始时间（秒）。
            // 绝不放在 DOMContentLoaded 里，防止被页面上其他加载卡顿的资源阻塞！
            var loadTime = Math.floor(Date.now() / 1000);

            document.addEventListener('DOMContentLoaded', function() {
                // 暴力兼容各种主题的评论表单
                var forms = document.querySelectorAll('form[action*="wp-comments-post.php"], #commentform, #comment-form');
                forms.forEach(function(form) {
                    if (!form.querySelector('input[name="js_spamtrap_token"]')) {
                        var jsToken = document.createElement('input');
                        jsToken.type = 'hidden';
                        jsToken.name = 'js_spamtrap_token';
                        jsToken.value = 'is_human_0'; // 初始值
                        form.appendChild(jsToken);

                        // 核心魔法 2：在表单提交的瞬间，计算时间差并赋值
                        form.addEventListener('submit', function() {
                            var submitTime = Math.floor(Date.now() / 1000);
                            var timeDiff = submitTime - loadTime;
                            jsToken.value = 'is_human_' + timeDiff;
                        });
                    }
                });
            });
        })();
        </script>
        <?php
    }
}

// ==========================================
// 2. 核心拦截逻辑：在写入数据库前进行终极安检
// ==========================================
add_filter('preprocess_comment', 'tjsky_intercept_spam_comments');
function tjsky_intercept_spam_comments($commentdata) {
    // 站长自己和 Pingback 机器通知，直接放行
    if (is_user_logged_in() || (isset($commentdata['comment_type']) && in_array($commentdata['comment_type'], array('pingback', 'trackback')))) {
        return $commentdata;
    }

    // --- 校验 1：前端 JS 时间陷阱检测 ---
    // 如果连标记都没有（直接 POST 的低级爬虫），直接处决
    if (!isset($_POST['js_spamtrap_token']) || strpos($_POST['js_spamtrap_token'], 'is_human_') !== 0) {
        tjsky_reject_comment(); 
    }

    // 提取时间差
    $time_spent = (int) str_replace('is_human_', '', $_POST['js_spamtrap_token']);

    // 如果打开页面不到 6 秒就点提交，绝对是机器，弄死
    if ($time_spent < 6) {
        tjsky_reject_comment();
    }

    $content = $commentdata['comment_content'];

    // 算一下原始文本的汉字数量
    preg_match_all('/[\x{4e00}-\x{9fa5}]/u', $content, $matches_original);
    $original_chinese_count = count($matches_original[0]);

    // 看看有没有贴代码的痕迹
    $has_code_block = preg_match('/(`|<pre>|<code>)/i', $content);

    // 【技术博客灵魂豁免通道】：带了代码块，且好好打字超过了 10 个汉字，直接放行交由 Akismet 审查！
    if ($has_code_block && $original_chinese_count >= 10) {
        return $commentdata;
    }

    // --- 校验 2：严格的汉字浓度清洗 ---
    // 剥离所有的 URL 链接 (防止垃圾链接凑数)
    $content_clean = preg_replace('/https?:\/\/[^\s]+/i', '', $content);
    // 剥离多行和单行 Markdown 代码块，以及 HTML 代码标签
    $content_clean = preg_replace('/```.*?```/is', '', $content_clean); 
    $content_clean = preg_replace('/`[^`]*`/i', '', $content_clean);       
    $content_clean = preg_replace('/<pre.*?>.*?<\/pre>/is', '', $content_clean); 
    $content_clean = preg_replace('/<code.*?>.*?<\/code>/is', '', $content_clean); 
    // 剥离空白字符
    $content_clean = preg_replace('/\s+/u', '', $content_clean);

    $total_len = mb_strlen($content_clean, 'UTF-8');

    // 剔除后成空壳了？说明全是链接和空格，处决
    if ($total_len === 0) {
        tjsky_reject_comment();
    }

    // 计算剔除代码后的真实汉字占比
    preg_match_all('/[\x{4e00}-\x{9fa5}]/u', $content_clean, $matches_clean);
    $clean_chinese_count = count($matches_clean[0]);
    $ratio = ($clean_chinese_count / $total_len) * 100;

    // 绝杀：日常交流文本中文字符少于 2 个，或者占比低于 20%
    if ($clean_chinese_count < 2 || $ratio < 20) {
         tjsky_reject_comment();
    }

    return $commentdata;
}

// ==========================================
// 3. 障眼法处决函数 (绝不暴露真实死因)
// ==========================================
function tjsky_reject_comment() {
    // 强行返回 403，反向污染爬虫的靶机库
    header('HTTP/1.1 403 Forbidden');
    header('Status: 403 Forbidden');

    $msg = '<div style="max-width: 600px; margin: 50px auto; padding: 20px; border-left: 4px solid #dc3545; background: #f8d7da; color: #721c24; font-family: sans-serif; border-radius: 4px; line-height: 1.6;">';
    $msg .= '<strong>⚠️ 提交失败 / Submission Failed:</strong><br><br>';
    // 这里使用含糊其辞的报错，防止被针对性突破
    $msg .= '系统检测到您的评论存在「格式异常」或「缺少有效上下文」的问题。请修改您的表单并重新组织语言后再试一次。<br>';
    $msg .= '<span style="font-size: 13px; color: #856404;">System flagged this comment as irregular or lacking meaningful context. Please rephrase.</span><br><br>';
    $msg .= '<a href="javascript:history.back()" style="color: #721c24; text-decoration: underline;">返回修改 / Go back and modify</a>';
    $msg .= '</div>';

    wp_die($msg, '拦截提示', array('response' => 403));
}

这年头WordPress被针对的太多了吧，防垃圾评论都能防出谍战片的感觉，不光得跟外面的爬虫斗智斗勇，还得防着自家的缓存背刺。有了这套 WordPress 禁止非中文垃圾评论代码，终于不用天天进后台清空垃圾了。代码已经丢上去跑了几天，那个烦人的未读红点也没再隔三差五地蹦出来。（严格说，这 3 天内防御率为 100%）

本文 拒绝祖传垃圾代码！适配前端静态缓存的 WordPress 防垃圾评论纯代码方案（附源码） 最初发表于 秋风于渭水。

2026-03-09 15:46:10

被腾讯云线路‘负优化’逼出来的迁移

之前腾讯云新加坡轻量，国内访问都是走的「新加坡腾讯云 → 新加坡SingTel（新加坡电信） → AS9929（中国联通工业互联骨干网，即所谓的联通A网） → 广州互联网交换中心 」这种极为优质的线路，任谁不要说一句“腾讯高、联通硬”，要知道联通 A 网的价格那是比电信 CN2 还要贵好几倍的。又没有电信 CN2 那种遇到 DDos 就玩犊子的问题。以我2025年续费的价格每年只要16X的价格来看，十分有性价比。

结果自从腾讯云出了EagleOne和轻量云优化流量包之后，香港和新加坡的线路质量就一落千丈，所有流量要么走TATA绕美，要么走NTT绕日，这俩线路的质量众所周知的爆炸。后果就是，博客的访问速度慢的要死，有些地区的访客甚至告诉我，需要白屏 10 秒以上才能看到内容，完全加载完需要20多秒。

你看看，这新加坡腾讯云的路由能忍？从新加坡直接给我绕美国去了，要知道我这个测试点可是广州联通，不走广州出口走北京出口就挺离谱的，出镜进入TATA线路后，丢包丢的飞起，日常自带 5% 丢包，晚高峰丢包到20%都是常态。晚上随便开个页面都需要好几秒。

虽然从上图的网站测速结果看起来，平均用时也就2秒多还可以，但要知道，图里可不是晚高峰时的测速结果，根据比较公认的说法，2~3秒的加载时长是维持用户体验的底线，图里这个速度已经基本是卡着用户体验的底线了，更不用说到了晚高峰动辄6、7秒甚至10秒的加载时长，顶着这个延迟不关闭标签的访客，那可真是真爱了，所以最好还是能将加载时长控制在1秒左右为好。所以我开始琢磨换一台前端机。

解决方案分析

为了解决博客访问慢的问题，我对比了目前主流的几种网站提速优化方案

• 第一个方案首先被放弃，谁能保证腾讯云未来不会劣化香港轻量的线路质量呢？而且现在是真没啥优惠，现有机器因为机龄计划存在，续费价格十分美好。
• 第三个方案经过我一通折腾，虽然套上后最慢访问用时被大幅改观，但最终还是放弃了，Cloudflare 我折腾了好几天配置后，最终平均用时也就比用原有的新加坡前端好了那么一咩咩，。 EagleOne 倒是比 Cloudflare 的效果还好，但也好的有限，因为站点没备案不能用国内线路，再怎么折腾平均也就2秒出头的速度了，我「将加载时长控制在1秒左右」的目标还是无法实现。
• 于是最终决定选择方案二：换香港机器作为前端机，下一步的目标是：寻找一个满足我的需求的香港机器/线路。

香港前端机的选项（海选大比拼）

为了换个靠谱的前端，我感觉我基本把市面上有点名气的香港机几乎都看了一遍了（笑哭）…… 挑花眼的同时，也算是踩遍了各种奇葩设定的坑。直接上省流版对比表，也给大家一个对比参考（以下都是指的他们最便宜或次便宜的机型）：

最终的选择 YT.NET（云途）

在对比了多款香港前端机之后，我选择了 YT.NET（云途）作为最终选项，虽然他家过于新（意味着有提桶跑路的可能），而且看网上有过一次较大的网络故障的问题，但实在是太便宜了，这个价格和配置只要能用个半年的，跑路了也不亏。一个香港三网优化晚高峰还能跑 150 Mbps的线路 1 年才 160 ，还要啥自行车。

YT.NET 规格：年付 168 元的‘真香’

以下都是带AFF后的正价，搭配九折优惠券：DIGVPS 可以再打个折上折。

• 型号的文字点击可直达购买页。
• AMD 机型的 CPU 性能比 Intel 机型要强一点，所以也贵了一点。
• 我这里列出的是最便宜的几款，如果想看全部的规格可以点这里查看全部：香港优化云主机
• 这个价格，这个网络质量，也就意味着机器经常缺货……不过好消息是，他家补货的速度也比较快。
• 他家还有一个 香港精品云主机 系列，不过我实测下来，精品和优化的线路目前是一样。
• 「2026-03-10更新」 经过持续监控路由，我终于知道精品云和优化云有什么区别了：平常优化云和精品云线路是一样的，具体可看下边的表格，精品云承诺路由一定是下边表格中的路由，而优化云只保证会尽量优化线路，并不承诺具体的路由」
• 他家还卖很多神奇的产品，比如：A端深圳 Z端香港的 深圳前海IX.NAT，送CNIX NAT入口的香港BGP国际网络云主机，懂的人都懂这是干啥用的，需要的自己去看。

YT.NET（云途）网络路由摸底：真的是三网直连吗？

表中的路由情况，仅代表我测试的HK.B和HK.AMD.D这两台机器，实测确实都是三网直连的，晚高峰也没出现明显限速和改路由。

• 从最后的 AS （42960）上看，他家的上游供应商应该是狗云，但他的电信V4回程是走联通的CUG（10099），又和狗云香港主机都不太一样。
• 电信 V6 虽然是走的 163 线路，不过据说属于接近 CN2 的高 Qos 的 163 线路，从我仅有的几次测试中，貌似丢包确实比较低，晚高峰也就 5% 的丢包，比起一般 163 线路动辄 20% 以上的丢包率，确实好了一点。
• 这里提醒一下大家：他家香港优化云主机虽然有标称带宽大于 300 Mbps的规格，但在测试中，哪怕是 500Mbps 的机器实测也是只能跑到 300Mbps 的速度，所以想要确保更大带宽的就放弃吧，不过我就用来反代一下我的博客和几个 API 已经很富裕了。
• 线路解锁质量一般：都是广播 IP ，并不是原生 IP。AI 基本全军覆没 Claude 和 Gemini 都是屏蔽状态，ChatGPT 只能解锁 APP。流媒体倒是还可以，Netflix、DisneyPlus、HBO Max 全都解锁了新加坡区，如果拿来魔法上网的话需要考虑一下。
• 「2026-03-10更新」绝了，我春节期间测了好几次晚高峰都没改路由，我写了文章后，诶，他居然在今天的晚高峰19点到22点把去程路由给切到绕日本了(仅代表我手里的这台HK.AMD.D的机器)。回程倒是没改，还是三网直连。经过询问YT.NET的客服，优化云仅承诺尽可能保证优化，负载实在太高时就可能会切到其他非直连的大陆优化路由，如果想确保三网直连路由需要购买香港精品云主机 系列。
• 关于香港错综复杂的线路情况，可以参考这篇文章《中国国内至国际骨干 ISP 线路整理》的香港部分。

换机体验：这 160 块钱花得值吗？

• 速度体验直接拉满：这速度爽太多了！平均加载时间直接压缩到 0.5 秒左右，就算是最慢的地区也小于 3 秒。晚高峰再也不用看着浏览器转圈圈了，体验极度舒适。
• 性价比“拉满”：三网直连的机器，一年才 160 多块。从年前折腾到现在快一个月了，没遇到啥网络波动，稳如老狗。就算以后真“提桶跑路”，只要能用个半年，这波也绝对不亏。
• 「2026-03-10更新」：如果因为晚高峰等时期，路由由三网直连切到非直连大陆优化路由，最快基本没变化，最慢会延长1秒多，除宁夏电信会到6秒多，其他不会超过4秒，平均会提高到1秒左右。

意外踩坑：为了省点流量，折腾了快1个月的 Nginx 反代

原本我的前端机用的是最无脑的端口转发模式。好处是前端纯纯一“工具人”，Nginx 只管在第四层闭着眼睛转流量，配置极其简单。但缺点也很直接：前端啥也没干，遇到攻击直接穿透到后端（前端被打 = 后端被打）。

更要命的是，YT.NET 的流量是双向计费的！走端口模式等于对等流量，一来一回，流量直接翻倍

为了节约流量包，我一咬牙，决定这次把架构改成 Nginx HTTP/HTTPS 反代。想着让前端机把静态内容缓存住，大部分请求直接在前端消化掉，只有必要时候才去请求后端，美滋滋有没有。

结果……这个折腾哦。

这台机器只有 1G 的小内存和 10GB 的硬盘，根本容不下任何有面板的服务。我想装个雷云 WAF 或者宝塔 BT？做梦！刚装完就磁盘和内存双双爆红，内存被吃得渣都不剩，磁盘只剩1G多一点，只好全自己编译安装了。再加上 WordPress 这个动态博客的复杂性，我硬是跟“前端反代+后端自动化”这套机制死磕了快一个月，才算勉强把它调教服帖。正常工作后，内存占用依然不超过60%，磁盘剩余 3GB。

这中间踩了多少坑、掉了多少头发？全是泪（此处省略一万字内心的疯狂吐槽）篇幅有限，我决定单独开一篇文章，详细说下“ 轻WAF+Nginx 前端反代架构”是如何跑通的，敬请期待（右键，新建markdown文档）。

本文 忍痛割爱“负优化”腾讯云！年付不到200元，我换到了这台“真香”的香港前端机 最初发表于 秋风于渭水。

2026-03-05 23:05:52

前言

年前呢，我给博客折腾了一个小功能，年后写了一篇《拒绝自欺欺人！给博客文章加上 AI 创作等级标识 (附完整 PHP+CSS 代码）》。文章发出去之后，评论区收到了不少朋友的反馈，也和好几个写了相关话题的博主进行了一些交流。然后我就想到，有个现象我好奇很久了：在这个 AI 生产力大爆发的时代，为什么有那么多博主，明明文章很多地方都透漏着文章有经过AI辅助写作，甚至整篇文章都是 AI 生成的，却非要“死不承认”？

过年期间无聊的时间，我一改之前只看AI摘要和标题的阅读方式，把所有RSS聚合订阅里的新文章都看了一遍，颇有些唏嘘。

以前关注的一些还不错的博客，现在点开满篇都是那种经典的“AI 营销号味”——逻辑通顺、排版整齐，永远是“首先、其次、综上所述”，“快来学习2026年最新、本文、详细阐述、通过、解决”，但唯独缺少了博主本人的灵魂、个性和折腾时的“人”味。最滑稽的是，经常出现一些，即便那股“ AI 味”已经溢出屏幕了，依然有嘴硬说这是自己逐字敲出来的人。

就像前文评论区里「石樱灯笼」说的那样：“一代人有一代人的垃圾互联网。”
以前是手动抄袭洗稿，后来是脚本农场批量搬运洗稿，现在轮到了 AI 批量生成了。面对这种 AI 时代的“掩耳盗铃”，我想聊聊我为什么决定要在自己的博客里，挂上这个 AI 标识。

所谓的“AI 羞耻”与“全能创作者”幻觉

从良性思考方向看（咱们不讨论 AI 营销、内容农场的这种最垃圾的情况），很多人死不承认用了 AI，可能是源于一种“AI 羞耻”。他们觉得，用了 AI 辅助，这篇文章就“上不了台面”，显得自己没水平。

这个和很多视频 UP 主或主播，他们极度忌讳被粉丝发现自己有团队一样，哪怕只是简单的有人帮忙，比如被发现稿子是对象帮忙润色的、资料是雇人查的、视频是外包剪辑的，自己那个“全能天才”的人设就崩塌了。

然而现实是：现代创作流程极其复杂，哪有那么多人能单打独斗搞定全流程？合理分配精力、寻求协作，本就是一种能力。写博客也是一样，为了维护一个“我独自熬夜写出万字长文”的虚假精英光环，把 AI 生成的内容全盘复制，这本质上是在满足自己的数字虚荣心。

别把“AI辅助写作”误当成你的“独立创作”

而另一种时候，一些博主则陷入了一种控制错觉：“标题是我输入的，按钮是我点的，所以这就是我的作品。” 这就像你买了一份预制菜，放进微波炉转了三分钟，端出来后非说自己是米其林大厨。混淆了“指令（Command）”与“创作（Creation）”的边界。或者说的更加现实一点就是，领导觉得是我给他们的课题，字是我签的，所以把团队的功劳全揽自己身上。

AI 应该是一个高水平的陪练，或者一套提升效率的，额，用 AI 自己的话说叫 “副驾驶”。可以用它来突破信息茧房，查漏补缺，检查代码语法错误，或者优化修改文字语病。在这个过程中，哪怕我让 AI 写了 90% 的代码，但只要代码核心的业务逻辑、排错时的思路，依然是我的，那我就依然有自己的独创性在里面的。

但如果我只是给 AI 一个标题和大方向，让它输出最优SEO的字符串排列组合，那我就会从一个创作者，降级成了一个廉价的“信息中转站”。关掉页面后，脑子里依然空空如也。

个人博客运营的灵魂：真实“踩坑”的不可替代性

如果一篇个人博客文章没有了作为“人”的思考和背书，读者们还为什么要来看我的博客？如果只是为了获取干巴巴的信息，大家完全可以直接去和 ChatGPT 或 Gemini 对话，为什么要听我在这里废话？人家 AI 还能多轮对话，实时反应呢。

建立个人博客的初衷，是为了记录真实的折腾过程、生活感悟和技术积累。对于技术博客来说，最珍贵的往往不是最后那个成功的 「Success 截图」和像教科书般的操作步骤，而是“遇到问题 -> 解决问题 -> 记录方案”的过程，是明知不可为而为之的极客趣味。

AI 带有“上帝视角”，它能写出完美的结果，却写不出我凌晨两点，对着终端上满屏的报错敲键盘时的焦虑。这些人的“不完美”和“主观性”，才是个人博客在 AI 时代依然能够存在的基础。

坦诚，是最高级的真实

用了就是用了。坦诚地标出 AI 辅助的比例，不仅是对读者的尊重，更是对自我创作边界的一种警醒。敢于在文末挂上“本文代码由 AI 辅助优化”的标签，其实传递的是一种自信：我清楚地知道哪些是我的独立思考，哪些是 AI 工具的产物；是我在驾驭 AI ，而不是被 AI 所支配。

当你大大方方地承认这一点，读者不仅不会觉得你水平不行，反而会觉得你严谨、靠谱且真实嘛。

结语

与其费时费力地先让 AI 生成一堆废话，然后再绞尽脑汁地喂给 AI 各种提示词去“洗稿”、去“AI 味”，想方设法地遮掩自己没动脑子的事实，这种行为真的就像《皇帝的新衣》一样可笑。

与其披着 AI 织造的“皇帝的新衣”在互联网上招摇过市，不如大大方方穿上自己精心挑选和搭配的衣服。虽然你并没有从种棉花、纺纱织布开始制作这件衣服。就像我们在折腾服务器和代码时，不需要从头去造每一个轮子，完全可以借助 AI 写个正则、查个配置、甚至搭个框架写个脚本——但这两者的本质截然不同。这衣服怎么搭、穿去哪、合不合身，体现的都是你作为一个“活人”的真实品味、逻辑与思考。

给博客加上 AI 创作等级标识，不是为了自我标榜，什么数字时代的清流，洁癖啥的，单纯就是为了图个坦荡。

用了就是用了，大方承认自己借助了高效率的工具，把省下来的精力留在真正需要折腾、需要踩坑的地方有何不好。毕竟，从统计数据来看，读者点进我的博客，真正想看的从来不是一份毫无破绽的教程，而是我灰头土脸填完坑后，揉着酸涩的眼睛，骂了一句“终于搞定了”的那个真实瞬间。这也是在这个 AI 时代，我们内容创作者能保留的最后一点“只属于自己的现实”（Personal Reality）吧

PS：前文提到的AI创作标识，因为实在是被只用 CSS 时，说明文字会超出屏幕的问题（不用 JS 实在是无法准确获取浏览器的尺寸和元素的绝对定位）折腾的够呛，现在改成将具体的AI辅助创作声明放在文章末尾，文章开头的 meta 只放 AI 创作等级标识图标了。

本文 大方承认用了AI辅助写作有多难？个人博客的AI羞耻与数字诚信 最初发表于 秋风于渭水。

2026-02-28 17:20:35

年前在日常刷 RSS 订阅的时候，看到了碎言大佬的一篇文章《给你的文章添加 AI 创作等级标识》。点进去一看，文章标题下带了一个精致的小徽章，用来标明这篇文章 AI 参与创作的程度。（现在大佬有改版，已经是小徽章+一句话简述了）看到这个设计，我顿时感觉非常有意思，甚至有种“相见恨晚”的感觉。立马决定：给我的博客也安排上！ 在这个个人技术博客越来越趋同的今天，这种小巧思真的能让人眼前一亮。

其实这活年前就搞定了，估计有些常来的已经注意到，最近几篇文章的标题下多了一个小标签。不过过年事情太多，这篇文章也就拖到年后上班才完成发出来了。

为什么要加 AI 标识？都用 AI 了还敢标出来？

可能有人会问：“别人用AI写文，恨不得藏着掖着，生怕读者看出来是 AI 写的，你倒好还专门搞个标签高调宣布？”

其实我的想法很简单：自己没必要骗自己。

建立个人博客，初衷就是为了记录自己的真实折腾过程、生活感悟和技术积累。在这个 AI 生产力爆发的时代，用 AI 辅助润色代码、画个标题图、提取摘要甚至寻找灵感、完成代码和项目，早就成了常规操作。用了就是用了，既然是自己的地盘，何必搞“掩耳盗铃”那一套？坦诚地标出 AI 辅助的比例，不仅是对读者的尊重，也是对自我创作边界的一种警醒。真诚，永远是个人博客的必杀技嘛。

我的 AI 创作等级标识设计 (带自定义声明)

参考了前人的思路后，我结合自己博客的主题风格，同样设计了 4 个等级，并配上了 Emoji。同时，我还额外增加了一个“AI 工具声明框”，鼠标悬停在徽章上时就会直接显示出简要的AI辅助创作情况说明（比如用了什么模型，具体哪些部分是AI创作的）。

我的 4 个等级定义如下：

• 🧠 AI 0 – 独立个体：本文完全由人类的大脑完成。🔘 灰色底。
• 🪄 AI 1 – 灵感辅助：本文人类在写完后，AI 做了辅助润色修饰；或写作时使用 AI 查询/核实了资料。🔵 蓝色底。
• 🤝 AI 2 – 人机合作：本文人类和 AI 的贡献基本五五开，合作探讨完成。🟣 紫色底。
• 🤖 AI 3 – 硅基生成：本文绝大部分内容都由 AI 生成。🟠 橙色底。

WordPress 代码折腾实录：AI 创作等级标识的 PHP 后端 + CSS 前端实现

既然我是技术博客，那自然要说一下我是怎么实现的啦。我是利用 WordPress 的 Code Snippets 插件（或者你直接加在 functions.php 里也行），分四步来实现它的。

第一步：注册后台 AI 创作等级标识面板并保存数据

目的是在文章编辑页的侧边栏加一个选择AI创作等级的下拉菜单和一个输入AI辅助创作声明的文本输入框。

代码如下，Snippets 插件新建 PHP 代码段 或写在 functions.php 里。

// ==========================================
// 1. 注册后台面板 (Meta Box)
// ==========================================
add_action('add_meta_boxes', 'add_ai_meta_box');
function add_ai_meta_box() {
    add_meta_box(
        'ai_level_meta_box',      // ID
        '✨ AI 创作声明',         // 标题
        'render_ai_meta_box',     // 回调
        'post',                   // 适用文章
        'side',                   // 位置：侧边栏
        'high'                    // 优先级
    );
}

// 渲染面板 HTML
function render_ai_meta_box($post) {
    $level = get_post_meta($post->ID, '_ai_creation_level', true);
    $tools = get_post_meta($post->ID, '_ai_creation_tools', true);
    wp_nonce_field('ai_save_action', 'ai_nonce');
    ?>
    <p style="margin-bottom:10px;">
        <label style="font-weight:bold;">✒️ 创作等级：</label><br>
        <select name="ai_level_select" style="width:100%; margin-top:5px;">
            <option value="0" <?php selected($level, '0'); ?>>🧠 AI 0 - 独立个体</option>
            <option value="1" <?php selected($level, '1'); ?>>🪄 AI 1 - 灵感辅助</option>
            <option value="2" <?php selected($level, '2'); ?>>🤝 AI 2 - 人机合作</option>
            <option value="3" <?php selected($level, '3'); ?>>🤖 AI 3 - 硅基生成</option>
        </select>
    </p>
    <p>
        <label style="font-weight:bold;">🤝 AI辅助创作声明：</label><br>
        <input type="text" name="ai_tools_input" value="<?php echo esc_attr($tools); ?>" 
               placeholder="例如：DeepSeek, Copilot" style="width:100%; margin-top:5px;">
    </p>
    <?php
}

// ==========================================
// 2. 保存数据
// ==========================================
add_action('save_post', 'save_ai_data');
function save_ai_data($post_id) {
    if (!isset($_POST['ai_nonce']) || !wp_verify_nonce($_POST['ai_nonce'], 'ai_save_action')) return;
    if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) return;
    if (!current_user_can('edit_post', $post_id)) return;

    if (isset($_POST['ai_level_select'])) {
        update_post_meta($post_id, '_ai_creation_level', sanitize_text_field($_POST['ai_level_select']));
    }
    if (isset($_POST['ai_tools_input'])) {
        update_post_meta($post_id, '_ai_creation_tools', sanitize_text_field($_POST['ai_tools_input']));
    }
}

第二步：把 AI 创作等级标识 给加到前端页面

在主题的 single.php 文件中（在文章日期、分类等元信息输出的位置代码后面），加上一句 <?php echo get_ai_badge(); ?>

以我自己用的主题为例是这样的

<div class="view-meta">
    <span>浏览: <?php the_views() ?></span>
    <span>作者: <?php the_author() ?></span>
    <span>分类: <?php the_category(',') ?></span>
    <span>发布时间: <?php the_time('Y-m-d H:i') ?></span>
    <span><?php edit_post_link('<i class="far fa-edit"></i> 编辑'); ?></span>
    <?php if (function_exists('get_ai_badge')) echo get_ai_badge(); ?>
</div>

第三步：AI 创作等级标识的前端输出逻辑 (气泡提示)

这里加了一个判断：如果填了具体的 AI辅助创作声明，气泡就优先显示声明；如果没填，就显示默认的等级描述。

代码如下，Snippets 插件新建 PHP 代码段 或写在 functions.php 里。

// ==========================================
// 前端获取徽章 HTML 的函数
// ==========================================
function get_ai_badge() {
    global $post;
    if (!$post) return '';

    $level = get_post_meta($post->ID, '_ai_creation_level', true);
    $tools = get_post_meta($post->ID, '_ai_creation_tools', true);
    if ($level === '') $level = '0'; // 默认纯人工

    $data = [
        '0' => ['icon' => '🧠', 'label' => '独立个体', 'desc' => '本文完全由人类的大脑完成', 'class' => 'ai-0'],
        '1' => ['icon' => '🪄', 'label' => '灵感辅助', 'desc' => '本文人类在写完后，AI 做了辅助润色修饰；本文写作时使用AI查询或核实了资料', 'class' => 'ai-1'],
        '2' => ['icon' => '🤝', 'label' => '人机合作', 'desc' => '本文人类和AI的贡献基本五五开，合作探讨完成', 'class' => 'ai-2'],
        '3' => ['icon' => '🤖', 'label' => '硅基生成', 'desc' => '本文绝大部分内容都由 AI 生成', 'class' => 'ai-3'],
    ];

    $current = $data[$level];
    $tooltip = $current['desc'];
    // 如果写了工具名称，且不是纯人工，气泡就显示工具声明
    if (!empty($tools) && $level != '0') {
        $tooltip = '🤝 AI辅助创作声明：' . $tools;
    }

    return sprintf(
        '<span class="ai-badge %s" data-tooltip="%s">%s %s</span>',
        esc_attr($current['class']),
        esc_attr($tooltip),
        $current['icon'],
        $current['label']
    );
}

第四步：AI 创作等级标识的前端 CSS 美化

为了配合网站的主题，让AI参考现有样式，搓了配套的 CSS，并利用 ::after 伪元素实现了 Tooltip 气泡弹窗效果。

这个看你主题情况了，我是用Snippets 插件的。
有些主题提供了写自定义样式的 GUI 。或者你写到主题默认的 style.css 文件里也行。

CSS 样式如下：

/* ===AI 徽章样式 === */
span.ai-badge {
    cursor: help;
    font-weight: 500;
    padding-left: 8px;
    padding-right: 8px;
    position: relative; /* 确保气泡定位准确 */
}

/* 等级颜色定义 (低饱和度高级感) */
span.ai-badge.ai-0 { background-color: #f5f5f7; color: #555; }
span.ai-badge.ai-1 { background-color: #f0f7ff; color: #4080c0; }
span.ai-badge.ai-2 { background-color: #f5f3ff; color: #7c3aed; }
span.ai-badge.ai-3 { background-color: #fff7ed; color: #c2410c; }

/* ===Tooltip 气泡 ==== */
.ai-badge::after {
    content: attr(data-tooltip);
    position: absolute;
    bottom: 135%;
    left: 50%;
    transform: translateX(-50%) translateY(5px);
    background: rgba(0, 0, 0, 0.85);
    color: #fff;
    padding: 6px 10px;
    border-radius: 6px;
    font-size: 12px;
    white-space: nowrap;
    opacity: 0;
    visibility: hidden;
    transition: all 0.2s;
    pointer-events: none;
    z-index: 999;
}
.ai-badge:hover::after {
    opacity: 1;
    visibility: visible;
    transform: translateX(-50%) translateY(0);
}

意料之外的踩坑：修复 WordPress 上古主题的 HTML 渲染 Bug

这里还遇到了一个小插曲：因为我用的这个主题挺老的了，当时受限于当时 WordPress 的设计，主题在 single.php 里是这样写的：

<div class="view-meta">
    <span>浏览: <?php the_views() ?></span>
    <span>作者: <?php the_author() ?></span>
    <span>分类: <?php the_category(',') ?></span>
    <span>发布时间: <?php the_time('Y-m-d H:i') ?></span>
    <span><?php edit_post_link('<i class="far fa-edit"></i> 编辑'); ?></span>
    <?php if (function_exists('get_ai_badge')) echo get_ai_badge(); ?>
</div>

明眼人应该看出来了，这里的<span>都是是写死在 HTML 里的。当访客访问时，edit_post_link()函数检测到访客没有编辑权限，所以就返回了空，但编辑按钮外面的 <span> 和 </span> 依然还在。

对于原版主题这并不是问题，因为这些<span>在样式里就是个纯文字，访客看不出来什么。

但是问题是，AI 创作等级标识肯定是有个边框才好看，我为了统一样式，给整个.view-meta 都加了个灰色框，于是 CSS 把不存在的编辑按钮渲染成了一个没有内容、只有内边距（padding）的扁扁的色块，超级难看。

其实现在的WordPress 原生函数 edit_post_link() 支持 “前置参数” 和 “后置参数”。只有在访客有权限显示编辑按钮时，这两个参数才会被输出，如果访客没有权限，这两个参数也会被一起隐藏。
所以 single.php 这里应该改成

<div class="view-meta">
    <span>浏览: <?php the_views() ?></span>
    <span>作者: <?php the_author() ?></span>
    <span>分类: <?php the_category(',') ?></span>
    <span>发布时间: <?php the_time('Y-m-d H:i') ?></span>
    <?php edit_post_link('<i class="far fa-edit"></i> 编辑', '<span>', '</span>'); ?>
    <?php if (function_exists('get_ai_badge')) echo get_ai_badge(); ?>
</div>

结语

1. 这样以后大家看我的个人博客文章，只需瞥一眼徽章，就能知道这篇文章里有多少是我的脑力创作，有多少是 AI 工具的功劳了。
2. 春节这半个月假期，我看了很多人的博客，有些技术博客一眼就能看出文章是 AI 写的，那个行文风格一股子 AI 营销号的味道，然后刚才我翻了下我自己文章，发现虽然我一直坚持不让 AI 润色我的文字（只让 AI 找我的错字）但打出的某些话还是充斥着一些 AI 的习惯格式了。潜移默化中还是被 AI 影响了啊。

参考文章

给你的文章添加 AI 创作等级标识 – 碎言
给你的文章添加 AI 创作等级标识 – 袁某人博客

本文 拒绝自欺欺人！给博客文章加上 AI 创作等级标识 (附完整 PHP+CSS 代码） 最初发表于 秋风于渭水。

2026-02-16 15:57:19

本来想按照惯例，整点那种“排比句+由浅入深”的拜年吉祥话，最好再配一张红彤彤的配图作为开头。但手放在键盘上那一刻，我反悔了。那太不“秋风于渭水”了，而且大家肯定已经在微信群里被这种“排比信息轰炸”给搞麻了吧？（其实主要是我懒得去搜词了）。

在这个短视频满天飞、大家注意力只有 3 秒、恨不得把所有内容都浓缩进 15 秒 BGM 里的时代，屏幕前的大家居然还愿意静下心来，看我写的一堆枯燥教程，听我为了几百兆内存碎碎念，为了解决个隐藏登录页絮絮叨叨写小几千字，甚至忍受我这个“随缘更新”（说好听点叫佛系，难听点就是拖延症晚期）的更新频率。

你们是我继续在这个互联网角落里“瞎折腾”的最大动力。

过去这一年，博客的数据起起伏伏。有时候精心打磨的干货反响平平，有时候随便吐槽两句“大厂负优化”反而引起了共鸣。但这都不重要，重要的是，后台每一个陌生或熟悉的 ID，每一条“博主帮大忙了”的留言，都让我觉得每次“浪费”掉的这一天半天的摸鱼时间，很值。

新的一年，我就不祝大家财源广进这种虚的了。
作为技术圈子的人，祝大家：

• 所有的 Server 永不宕机（除非是计划重启）；
• 所有的代码 一次 Compile Pass；
• 生活里的 Bug 都能复现并解决，
• 想要的都能得到，遇到的 404 越来越少；
• 最重要的是，在这个容易焦虑的赛博世界里，保持折腾的热情，同时拥有睡个好觉的能力。

感谢大家听我絮絮叨叨写这么多。
小盆友一蹦一跳的过来通知我去包饺砸了。咱们明年（下次更新时）见。

除夕快乐🎇🧨

本文 祝大家除夕快乐｜辞暮尔尔 烟火年年 最初发表于 秋风于渭水。