2026-09-09 23:25:57
从聊天到动手：AI 把不可思议变成了日常 From Chat to Action: AI Is Making the Extraordinary Ordinary 三年前惊叹它会聊天，如今 AI 已经能看、能听、能行动 Three Years Ago, AI Could Chat. Now It Can See, Hear, and Act 当 AI 有了“眼睛、耳朵和手脚”，程序员的工作变了 AI Has Eyes, Ears, and Hands—And Programming Is Changing 昨天的 AI 奇迹，今天的理所当然 Yesterday’s AI Miracles Are Today’s Expectations 从复制粘贴到交代任务：程序员与 AI 的三年 From Copy and Paste to Delegating Tasks: Three Years with AI 代码交给 AI 以后，程序员还需要什么能力？ When AI Writes the Code, What Skills Do Developers Still Need? 以后的编程语言是英语？事情没那么简单 Is English the Next Programming Language? It’s Not That Simple 从 ChatGPT 到 AI 智能体：变化比想象中更快 From ChatGPT to AI Agents: Faster Than We Imagined 翻看三年多前的视频，才发现当时让我们惊叹的 ChatGPT 对话能力，如今早已成为日常。从文字聊天到能看、能听、能调用工具执行任务，AI 正在改变软件开发的方式。随着 Vibe Coding 和 Harness Engineering 的发展，程序员可以将更多编码工作交给 AI，而清晰表达需求、阅读代码、理解业务和验证结果的能力，也变得更加重要。
2026-09-08 21:42:19
京东邀请码：SBJG45 首单10英镑省3英镑。
Joybuy登陆英国后：便宜、方便、优惠多，我媳妇已经快买上瘾了 京东Joybuy在英国越来越火：从中国零食到宇树机器人都能买 Joybuy英国使用体验：价格便宜、配送快，就是纸箱太多 从Amazon到Joybuy：英国网购正在多一个强劲选择 Joybuy登陆英国后，我家的快递明显变多了 Joybuy英国体验：优惠券、签到积分、低价会员，确实很会“拿捏”用户 京东Joybuy进入英国及部分欧洲市场后迅速受到不少消费者欢迎。中国零食、饮料、日用品甚至电器都能方便购买，再加上签到积分、优惠券、本地仓配送和低价会员服务，整体体验颇具竞争力。相比Amazon和TEMU，Joybuy既有价格优势，又更贴近日常消费需求。不过频繁购物也带来了一个很现实的问题：家里的纸箱越来越多了。
Joybuy上的矿泉水和泡面，屯粮/隔几天就去露营了。[/caption]
京东邀请码：SBJG45 首单10英镑省3英镑。
送货小哥估计当场就后悔接这一单了。
他得从货车里一箱一箱搬到我家门口，搬到最后还开玩笑地说：
“这是世界上最后的水了吧？”
最近英国政府也一直建议民众准备一些应急饮用水和食物，以防极端天气或者其他突发情况。我估计我媳妇看到这种新闻以后，很快又要有所行动了。
Joybuy每日提醒打卡积点/抵现[/caption]
[caption id="attachment_72892" align="alignnone" width="945"]
Joybuy积点历史[/caption]
而且我发现 Joybuy 和 TEMU 有点类似，经常会给你发各种 Voucher，比如满 £40 减 £5、满 £60 减 £20之类的。有时候刚下完一单，又给你送新的券，感觉永远都用不完。
于是你本来觉得：
“这次买完了，最近应该不用买了。”
结果第二天打开 App：
“咦？又有一张券。”
然后又开始凑单。
不过 Joybuy 和 TEMU 对我来说有一个很大的区别。
Joybuy 上买的东西，大多数至少都是正常生活中会消耗掉的东西，比如吃的、喝的、日用品，所以即使买得频繁，也不太容易买一堆完全没用的东西。
TEMU 就不一样了。
前两年我在 TEMU 上买过不少“有的没的”。下单的时候觉得特别便宜，几镑钱一个，看着很划算，但买回来以后才发现，要么根本用不上，要么质量比较一般。
单看每一件都没多少钱，但加起来其实就是乱花钱。
Joybuy 现在卖的东西也越来越杂，不只是食品和日用品，连电器都有。
比如今年夏天天气特别热的时候，Joybuy 上连空调都卖，而且有一段时间直接卖断货了。
我今天刷 App 的时候，甚至发现上面已经可以买宇树机器人了，而且居然还能隔天送到。
[caption id="attachment_72893" align="alignnone" width="945"]
Joybuy上可以买宇树机器人，价格不便宜啊[/caption]
这基本也能说明 Joybuy 在英国已经铺了不少本地仓储，否则这种配送速度很难做到。
2026-09-07 18:46:28
一次未及时升级的 WordPress 及插件漏洞，导致数据库中的 Cloudflare 凭据疑似泄露。攻击者随后添加恶意 Worker，劫持部分博客页面，将流量导向赌博网站，并把自己添加为 Google Search Console 的已验证所有者。本文完整复盘事件经过、攻击链、调查结论和加固措施，也再次提醒我：安全依赖及时更新、最小权限、日志监控和可恢复的备份，而不是某一项单独的防护。
在床上刷手机的时候收到GOOGLE的邮件，说网站有新的Owner验证，明显不对。[/caption]
[bctt tweet="我完全不认识这个账号。"]
看到邮件的一瞬间，我就意识到事情不对。如果陌生人能够把自己添加为网站所有者，这很可能不只是垃圾评论、撞库登录或者普通的漏洞扫描，而是对方已经能够控制网站向访问者返回的内容。
我立刻开始检查 WordPress、Cloudflare、MySQL 数据库、Web 服务器和系统日志。
调查结果显示，网站确实遭到了入侵。攻击者在部分博客请求到达源服务器之前进行了拦截，并将正常页面替换成了印尼语的赌博网站推广内容。
[caption id="attachment_72814" align="alignnone" width="1456"]
Cloudflare的Audit记录[/caption]
这次事件最终被及时发现和处理，但也给我敲响了一记警钟。
WordPress 向来是漏洞攻击的重灾区。更准确地说，风险并不只来自 WordPress 核心，而是来自由 WordPress、插件、主题、数据库、API Token、CDN、文件权限和日常运维共同构成的整条信任链。
打开cloudflare检查API调用的记录[/caption]
结合服务器日志、数据库内容和 Cloudflare 配置，我认为最可能的攻击路径是：
wp-config.php 中的认证 Key 和 Salt 主要用于保护 Cookie、会话和 Nonce。更换它们会让所有用户退出登录，但不会改变用户的密码。
WordPress 数据库中的密码使用带 Salt 的密码哈希保存。即使密码哈希泄露，攻击者通常也无法直接看到明文密码，但仍然可以离线猜测。
Salt 可以防止预计算彩虹表攻击，也能让相同密码产生不同哈希，但它不能保护弱密码不被字典攻击或暴力破解。
因此，只要数据库可能泄露，正确做法仍然是更换密码，尤其是当密码较短、可预测或者在其他服务中重复使用时。
404，说明被请求的文件在当时并不存在。
请求一个类似 WebShell 的文件名，并不能证明扫描者曾经成功上传过这个文件。互联网上的自动化攻击程序经常尝试访问已知 WebShell 文件名，希望找到其他攻击者之前留下的后门。
这次 WordPress 漏洞可能允许攻击者接触数据库信息，但这并不会自动获得 PHP 执行或文件写入能力。
真正部署 WebShell 通常还需要额外的能力，例如：
wp-config.php 中，而不是保存在 WordPress 配置表里。
只有当攻击者获得任意文件读取、PHP 代码执行或其他能够读取 wp-config.php 的能力时，WordPress 使用的 MySQL 用户名和密码才更可能泄露。
MySQL 自己通常也不会把数据库用户密码以可直接恢复的明文形式保存在系统表中，而是保存认证信息。不过，如果这些认证数据泄露，弱密码仍可能遭到离线攻击。
结合目前的调查结果，我没有发现 WordPress 数据库凭据或所有 MySQL 用户密码已经泄露的直接证据。
但作为事件响应的一部分，轮换 WordPress 专用数据库账号的密码仍然是一项低成本的预防措施。修改 MySQL 密码后，还必须同步更新 wp-config.php 中的数据库密码，否则 WordPress 将无法连接数据库。
Cloudflare的KV值用于拦截HTML[/caption]
[caption id="attachment_72815" align="alignnone" width="674"]
Cloudflare可以设置KV/Worker来拦截请求。[/caption]
// Worker penyaji halaman HTML kustom dari KV (milik tools manual-page/).
// Terpisah dari lp-worker: script name, KV namespace, dan deploy-nya sendiri.
//
// Key KV di-prefix hostname (satu namespace dipakai banyak domain):
// {host}:pages.txt -> daftar path yang aktif untuk host tsb
// page:{host}:{path} -> isi HTML halaman
// Path yang terdaftar disajikan apa adanya ke semua pengunjung.
// Path lain → diteruskan transparan ke origin.
const CACHE_TTL_MS = 300_000; // cache pages.txt per host di isolate, 5 menit
const pagesCache = new Map(); // host -> { time, pages }
async function getPages(env, host) {
const now = Date.now();
const cached = pagesCache.get(host);
if (cached && now - cached.time < CACHE_TTL_MS) {
return cached.pages;
}
const text = await env.PAGES.get($ {
host
}: pages.txt);
const pages = new Set(
text ? text.split('\n').map((p) => p.trim()).filter((p) => p !== '') : []
);
pagesCache.set(host, {
time: now,
pages
});
return pages;
}
export default {
async fetch(request, env) {
if (request.method !== 'GET' && request.method !== 'HEAD') {
return passThrough();
}
const url = new URL(request.url);
const host = url.host.toLowerCase().replace(/^www\./, '');
// Normalisasi sama dengan main.py: lowercase, tanpa trailing slash
const key = '/' + url.pathname.toLowerCase().replace(/^\/+|\/+$/g, '');
// Pass-through ke origin — inject X-Forwarded-Proto agar WordPress/nginx
// tahu request aslinya HTTPS (diperlukan kalau SSL mode CF = Flexible)
function passThrough() {
const modified = new Request(request);
modified.headers.set('X-Forwarded-Proto', 'https');
modified.headers.set('X-Forwarded-Host', url.host);
modified.headers.set('X-Forwarded-SSL', 'on');
modified.headers.set('X-Forwarded-Port', '443');
return fetch(modified);
}
// Root → teruskan ke origin (situs asli tetap jalan normal)
if (key === '/') {
return passThrough();
}
// File verifikasi GSC (googlexxx.html) dari KV — cek dua key:
// - key polos: google{token}.html (utils.py via lp-worker-content)
// - key prefixed: page:{host}:{path} (manual-page/main.py)
const verifyMatch = key.match(/^\/(google[a-z0-9]+\.html)$/);
if (verifyMatch) {
const [plain, gsc] = await Promise.all([
env.PAGES.get(verifyMatch[1]),
env.PAGES.get(`page:${host}:${key}`),
]);
const html = plain || gsc;
if (html !== null) {
return new Response(html, {
headers: {
'content-type': 'text/html; charset=utf-8'
},
});
}
return passThrough();
}
// Binding KV hilang (deploy parsial) -> gagal-aman ke origin,
// jangan 500-kan seluruh domain
if (!env.PAGES) {
return passThrough();
}
try {
const pages = await getPages(env, host);
if (!pages.has(key)) {
return passThrough();
}
const html = await env.PAGES.get(`page:${host}:${key}`);
if (html === null) {
return passThrough();
}
return new Response(html, {
headers: {
'content-type': 'text/html; charset=utf-8'
},
});
} catch {
return passThrough(); // KV error -> gagal-aman ke origin
}
},
};
[show_file file="/var/www/wp-post-common/justyy.com/incidents.php"]
[show_posts keyword="安全 事件"]
[show_posts keyword="wordpress"]
英文：A Google Alert Woke Me Up: Postmortem of a WordPress Security Incident
2026-09-07 18:10:56
控制变量法是科学实验和工程实践中最重要的思维方法之一：研究某个因素对结果的影响时，只改变这个因素，同时尽量保持其他条件不变。本文通过糖在不同水温中的溶解实验、植物肥料实验以及软件性能测试等例子，介绍自变量、因变量和控制变量的区别，并进一步解释为什么控制变量对于判断因果关系、性能优化和问题排查如此重要。控制变量法是科学实验中最基本、也最重要的方法之一。 简单来说： 研究某一个因素对结果的影响时，只改变这个因素，而其他可能影响结果的条件尽量保持不变。 它的核心目的，是帮助我们回答一个非常重要的问题： 到底是什么因素导致了结果发生变化？
20°C → 40°C → 60°C
算法 A + 相同机器 + 相同编译器 + 相同数据集 + 相同配置
算法 B + 相同机器 + 相同编译器 + 相同数据集 + 相同配置
唯一改变的是：
算法。
然后再比较运行时间。
这实际上就是软件工程中的 Benchmark、A/B Test 和 Controlled Experiment 背后的基本思想。
A：加肥料，放在阳光下
B：不加肥料，放在阴暗处
一段时间后，A 植物长得明显更高。
但是我们仍然不能得出：
肥料导致植物长得更快。
因为这里同时改变了两个因素：
A：使用肥料
B：不使用肥料
这样实验结果才能更可靠地说明肥料是否对植物生长产生影响。
A 增加的时候，B 也增加。
并不能马上证明：
A 导致了 B。
因为可能存在第三个变量 C：
C → A
C → B
也有可能是：
B → A
甚至可能只是随机巧合。
控制变量实验的目的之一，就是尽量排除这些其他解释。
如果：
API latency = 500 ms
修改数据库索引后：
API latency = 200 ms
如果其他条件保持一致，那么可以比较有信心地认为索引产生了效果。
但是如果你同时：
只改一个 → 观察结果 → 其他条件尽量不变
它不仅是一种实验方法，也是一种非常重要的思维方式。
当我们看到两个现象同时发生时，不要马上得出因果结论。
而应该继续问：
还有没有其他因素发生了变化？
如果只改变这一个变量，结果还会不会发生？
这正是控制变量法真正有价值的地方。
[show_posts keyword="学习笔记"]
英文：The Controlled Variable Method: Why Good Experiments Change One Thing at a Time?
2026-09-04 23:17:18
[caption id="attachment_72821" align="alignnone" width="2048"]
碎片时间刷刷题[/caption]
AI 正在把写代码的成本快速降低。过去需要程序员花几小时甚至几天完成的工作，现在 AI 可以在几分钟内生成代码、补测试、修 CI、提交 PR。工程师的角色也因此从“写代码”逐渐转向“审核代码、设计系统和做关键判断”。代码本身正在贬值，但架构、设计、安全、验证、Code Review 和判断力反而越来越重要。AI 可以成为 24/7 不知疲倦的程序员，但真正决定软件往哪里走的，依然需要人来掌舵。[caption id="attachment_72251" align="alignnone" width="550"]
01[/caption]
Talk is cheap. Show me the code.以前我非常认同这句话。 程序员嘛，最终还是要拿代码说话。设计讲得再漂亮、PPT 画得再好，如果最后写不出来，或者代码跑不起来，那都没有意义。 但是到了 AI 时代，我越来越觉得，这句话可能需要重新理解了。 因为现在，代码本身正在变得越来越便宜。 我甚至已经不太记得，上一次自己从头到尾手动敲一大段代码是什么时候了。 现在每天工作的方式，更像是在指挥不同的 AI 干活：把需求说清楚，告诉它代码库在哪里、目标是什么、有哪些约束，然后 AI 自己去分析代码、设计方案、修改实现、补测试，最后给我一个 PR。 很多时候，AI 生成的代码确实已经相当不错。 当然，我不会完全不看。 通常我会先让另一个 AI 做一轮 Code Review，看看有没有明显的问题，再自己快速检查一下关键逻辑，有必要的话做一些手动测试。 整个流程已经和以前完全不同了。
拆一下。Small PR。这样比较容易 Review，也比较容易发现问题。 这个原则当然依然是对的。 问题是，AI 把写代码的速度提高了一个数量级之后，人类 Review 的速度根本跟不上。 现在一天十几个 PR 并不是什么特别夸张的事情，随便一个功能可能就是几百行代码。 如果还按照以前的方式，一行一行认真 Review：
Line 1...
Line 2...
Line 3...
...Make the CI pass.你给它一个失败的测试，它会非常努力地想办法把测试变绿。 有时候确实是修复了真正的 Bug。 但有时候它的解决方案会让我哭笑不得。 比如 AI 特别喜欢写这种东西：
try {
...
} catch {
...
}PASS任务完成。从局部来看，每一次修改都“有道理”。 但这些代码堆积半年、一年之后，会变成什么样，就很难说了。 这也是为什么： CI Passing ≠ Code Quality。 甚至： CI Passing ≠ Correctness。 测试只能证明你测试过的那些东西没有发现问题，并不能证明系统没有问题。 AI 特别容易优化一个非常明确的 Objective Function。 你告诉它：
把 CI 变绿。那么它就会想尽办法把 CI 变绿。 但“让这个代码库未来五年仍然容易维护”是一个非常模糊，而且反馈周期极长的目标。 AI 目前并不天然擅长这种事情。
代码要 Readable。为什么？ 因为将来需要另外一个工程师来看。 但是如果以后 80% 的代码维护工作都是 AI 完成的呢？ 那么很多代码实际上可能已经不是主要写给人看的，而是写给 AI 看的。 只要：
Human Readability以后可能越来越强调：
Machine Maintainability这两者高度相关，但未必完全相同。
02[/caption]
Trust me.MOV
PUSH
JMPMachine CodeAssemblyCC++ / Java / Python / C#Natural Language给这个 API 加一个 Rate Limiter，要支持 Distributed Deployment，不能依赖 Local Memory，补好 Unit Tests 和 Integration Tests。AI 去负责：
C#
Python
SQL
YAML
Terraform
Dockerfile
...gcc hello.cImplement this function.它可能给你方案 A。 过一分钟再问一次： 它可能给你方案 B。 换一个模型： 方案 C。 因为现在的大语言模型，本质上仍然是概率模型。 它根据已有的 Context，不断预测接下来最可能出现的 Token。 我们当然可以通过很多手段提高确定性：
AI 会不会写代码？这个问题其实已经差不多解决了。 真正困难的问题是：
我们怎么知道 AI 写的代码是对的？这可能才是未来十年软件工程最重要的问题之一。
Talk is cheap.以前最稀缺的是： 把想法变成代码的能力。 现在 AI 正在把这个成本快速压低。 未来真正稀缺的，很可能变成：
Code is becoming cheap too.
Judgment is expensive.
03[/caption]
还好约会的时候刷题媳妇不管的。[/caption]
[caption id="attachment_72826" align="alignnone" width="2048"]
在威尔士湖的中间，我和娃一起刷力扣。[/caption]
[caption id="attachment_72828" align="alignnone" width="1672"]
一般每周日都会走路20分钟从教堂到Costa然后点杯咖啡，刷个题再往回走。[/caption]
[caption id="attachment_72827" align="alignnone" width="2048"]
这次去威尔士露营，条件艰苦也不能打乱我打卡力扣的节奏。[/caption]
[caption id="attachment_72854" align="alignnone" width="1152"]
和媳妇在星巴克喝咖啡/我刷题[/caption]
[show_file file="/var/www/wp-post-common/justyy.com/leetcode.php"]
[show_file file="/var/www/wp-post-common/justyy.com/ai.php"]
[show_posts keyword="程序员"]
英文：Code Is Becoming Cheaper: What Really Matters for Programmers in the AI Era
AI Agent 真正改变的，不只是“写代码的速度”，而是让代码从软件系统的核心产品，逐渐变成 Agent 为完成任务而临时生成、使用、甚至丢弃的工具。未来工程师的核心工作，将越来越从“写代码”转向定义问题、表达意图、设计约束、组织 Agent，以及验证结果。论文的标题叫做 The End of Software Engineering，也就是“软件工程的终结”。 但我觉得，如果严格按照论文真正的论点来概括，一个更准确的标题可能应该是：
The End of Code-Centric Software Engineering也就是说：
不是 Software Engineering 消失，而是“以人类手工写代码为中心的软件工程”正在逐渐结束。
Problem
↓
Human Reasoning
↓
Design
↓
Code
↓
Execution
↓
Result系统复杂度不断增加，但人的认知能力基本是固定的。过去几十年，我们发明了很多东西来对抗复杂度：
Intent
↓
Agent Reasoning
↓
Tools / APIs / Generated Code
↓
ResultCode 不再一定是 Product。代码可能只是 Agent 完成某一步 reasoning 时临时生成的 intermediate artifact。 比如 Agent 为了解决一个问题，临时生成了 300 行 Python。 代码运行完，结果出来以后，这 300 行代码甚至都没有必要保存。 它不一定需要：
AI
↓
Software
↓
ResultCopilot
↓
帮我写代码
↓
我做出软件
↓
用户获得结果Agent
↓
Result分析我过去一年服务器的日志，找出异常流量，并给我生成一份风险报告。未来我可能根本不需要知道它背后：
结果到底对不对？论文把这种变化进一步描述成：
Local Software
↓
SaaS
↓
AaaS — Agent as a ServiceHuman = Code AuthorHuman =
Intent Architect
+ Coordinator
+ Auditor未来工程师最重要的能力，可能甚至不只是“解决问题”，而是再向前移动一步：发现什么问题值得解决，并且准确地定义这个问题。Code Generation 会越来越 commoditized。 但是：
Problem Formulation 不会。
PM
+ Architect
\+ 20 Developers
+ QA
+ DevOps几个高级工程师 / Architect
+
PM Agents
+
Coding Agents
+
Testing Agents
+
Debugging Agents
+
Security AgentsGoal
+
Constraints
+
JudgementExecution一个能够高效 orchestrate 十个、几十个甚至更多 Agent 的人。真正稀缺的能力，从 execution 转向 orchestration。
The End of Software Engineering但是论文自己引用的一些实验结果，其实恰恰说明： 我们离真正意义上的“软件工程终结”还很远。 例如 Agent 在 isolated tasks 上可能达到：
80% 以上但是到了长期持续维护软件的时候，成功率可能掉到：
38% 或更低问题包括：
“帮我解决这个 Issue。”但是，这和：
“这个 Repository 从今天开始交给你维护三年，保证架构不腐烂。”完全不是同一个问题。 后者涉及长期 architecture、technical debt、隐含需求、历史背景、团队知识以及大量不断变化的 context。 论文自己最终也承认：
Fully autonomous software engineering 仍然是一个 multi-year research challenge。
n 个 components，那么潜在 dependency graph 的数量可能达到：
2^(n choose 2)软件系统复杂度不断增加
+
Human Cognitive Capacity 基本固定
+
LLM Capacity 可以随着 Compute 增长
↓
Agentic Paradigm 最终必然拥有更好的 scalability软件工程的实际认知复杂度就是 exponential。更不能进一步推出：
LLM 就可以有效处理这种 exponential complexity。因为 LLM 自己同样受到很多限制：
AI 将消灭 Software Engineer。我更愿意说：
AI 正在把 Software Engineering 的抽象层，再向上推一层。过去几十年的趋势大概是：
Machine Code
↓
Assembly
↓
C
↓
C++ / Java
↓
Frameworks
↓
Cloud / APIs
↓
AI CodingIntent
↓
Agent
↓
Reasoning
↓
Tools / APIs / Generated Code
↓
OutcomeThe End of Software Engineering.而是：
What persists is the agent's capability, not its intermediate artifacts.换成我自己的理解：
AI 时代，代码的价值正在从“最终产品”，逐渐变成“解决问题过程中的中间产物”。真正稀缺的价值正在向上迁移：发现问题、定义问题、提出正确的问题、设计系统边界，以及判断答案到底是否正确。相比于那个略显 clickbait 的标题：
“Software Engineering is ending.”我认为这个观点其实深得多。 [caption id="attachment_72850" align="alignnone" width="1126"]
AI 时代，代码的价值正在从“最终产品”退化为“解决问题过程中的中间产物”。真正稀缺的东西正在向上迁移：发现问题、定义问题、提出正确的问题、设计系统边界，以及判断答案是否正确。[/caption]
2026-09-03 23:31:11
[caption id="attachment_72810" align="alignnone" width="1448"]
Chessly和Eric一起弹钢琴。[/caption]
Chessly是一只性格大胆、特别黏哥哥的黑白猫。她每天睡前喜欢跑到哥哥房间撒娇，早上又会守在门口等哥哥开门，还会开心地“咕咕咕”叫。偶尔趴在钢琴黑白键旁的她，仿佛也想学哥哥弹琴，而哥哥一直温柔地陪着她，这些日常也成了家里最温暖的小片段。
Chessly黑白猫在黑白键上，估计她也想弹，哥哥很温柔。[/caption]
[video_links]
https://mp.weixin.qq.com/s/tyHUOo6RuiG7zkyKWl5GTw
https://www.facebook.com/reel/1092867996500648
https://weibo.com/1858482220/RgpsOBT0T
https://youtu.be/wSUnE6QGpEU
https://www.bilibili.com/video/BV1YLtZ6xE7x/
https://x.com/doctorzlai/status/2095439901214863568
https://www.instagram.com/p/Dc0gziwgtCL/
https://www.threads.com/@doctorlai/post/Dc0gwzQDoLB
https://www.xiaohongshu.com/explore/6a9939bc0000000011034197?xsec_token=YBRdG81RLwb_O13PaLkIAEId8lYPrRzpo1q0S_HaMIs8o=&xsec_source=pc_creatormng
https://weixin.qq.com/sph/AEEFrNhu8
https://www.threads.com/@doctorlai/post/Dc0gwzQDoLB
[/video_links]
[show_posts keyword="Chessly"]
[show_file file="/var/www/wp-post-common/justyy.com/cat.php"]