用 Claude Code 开发 Fried Rice 主题

Tue, 23 Dec 2025 15:00:00 +0800

最近用 Claude Code 给我自己的博客主题 Fried Rice 加了一些 SEO 功能，整体体验还不错。

背景

Fried Rice 是从 hugo-theme-stack fork 出来的主题。之前已经加了一些基础的 JSON-LD structured data，这次想继续完善。

这次做了什么

主要是增强 SEO 的 structured data：

WebSite schema（支持 search action）
Organization schema（包含 founder、contact point、address）
FAQ schema（支持文章内嵌 FAQ）
增强 Article/BlogPosting schema（加了 accessibility metadata）

Claude Code 的表现

整个开发过程大概 2 小时，Claude Code 帮我：

写代码 - Hugo 模板语法比较繁琐，让 AI 写省心很多
Review 代码 - 我提交后让它检查，它发现了好几个问题：
- datePublished 重复定义了 3 次
- founder 对象重复定义
- JSON 输出有双重转义问题
- 变量作用域错误
修复问题 - 发现问题后直接让它修，一次性改完
创建 PR、打 tag、写 CHANGELOG - 这些琐碎的事情也能做

比较惊喜的是它能发现代码里的逻辑问题。比如 Hugo 的 jsonify 输出被 HTML 转义导致 JSON 格式错误，它找到了正确的解决方案（用 safeJS）。

不足

有时候需要多次提醒才会用正确的工具
对于 Hugo 模板语法，有些地方不太熟悉，需要迭代几次

总结

对于这种「加功能 + 修 bug」的任务，Claude Code 挺好用的。特别是 Hugo 模板这种语法繁琐的东西，让 AI 来写效率高很多。

谨慎使用新兴开源软件

Sat, 13 Dec 2025 11:02:40 +0800

最近我在 dify/langchain 上翻车了，得出这个结论。

追溯

大概7个月前，我部署了开源的 dify 到服务器，通过官方的 docker compose 启动了实例。但是最近，由于 Dify 代码节点的沙箱逃逸漏洞（CVE-2025-3466），被 webshell 提权，植入了门罗币挖矿程序。

好在，这次被提权之后，入侵者做的事情不多，并且入侵的是 docker container，损失可控。

CVE-2025-3466 详情

CVE编号: CVE-2025-3466 发布日期: 2025年7月7日 CVSS评分: 9.8 (严重) 影响版本: langgenius/dify 1.1.0 - 1.1.2 修复版本: 1.1.3

漏洞描述: Dify 的代码节点（code node）存在沙箱逃逸漏洞，允许攻击者通过覆盖全局 JavaScript 函数（如 parseInt）来绕过沙箱安全限制，从而以完整 root 权限执行任意代码。

攻击流程:

攻击者在代码节点的输入中构造恶意 payload
恶意代码在沙箱限制实施前覆盖全局 JavaScript 函数
利用被覆盖的函数绕过安全检查
执行任意命令，获取容器完整控制权
植入 webshell 后门和门罗币挖矿程序

影响范围:

未经授权访问 secret keys 和 API keys
访问内部网络服务器
在 dify.ai 系统内横向移动
完全接管服务器控制权

相关链接:

从这个角度看，保护服务器安全，几个关键的因素不可少。

个人服务器安全

从安全角度来说，个人服务器有几个事情是一定要做的。第一个事情就是尽可能不要使用密码。例如 ssh 密码。

ssh 密码

必须禁用密码登录。ssh 密码破解起来相对容易，如果密码简单，或者用户自行修改密码，使用了简单的密码，那么服务器就会被入侵。

如果使用 Debian/Linux，那么关闭密码登录和关闭 root 登录是必须的：

使用的软件越少，攻击者的攻击面就越窄。一旦你的服务器上只暴露了 nginx，和 80 端口，22 端口（ssh）都没开，那么攻击者能攻击的面就只有 nginx 相关的内容。

使用 rootless docker

使用容器技术相当于在云服务商的基础上进一步做虚拟化。

使用 rootless docker 可以进一步限制容器的权限，即使容器被攻破，攻击者也无法直接获得宿主机的 root 权限。这是最后一道防线。

限制容器的网络访问

大多数服务并不需要无限制的外网访问权限。合理配置容器的网络策略，限制不必要的网络访问，可以大大降低攻击面。

例如，很多服务只需要访问数据库或者内部服务，根本不需要访问外网。如果容器没有外网访问权限，即使被攻破，攻击者也无法下载挖矿程序或者 C2 服务器进行通信。

如何谨慎使用开源软件

这次事件让我反思，在使用新兴开源软件时需要注意以下几点：

选择成熟的项目

查看项目的 star 数、commit 频率、issue 处理情况。如果一个项目：

Star 数很少（少于几百）
最近几个月没有更新
大量未解决的 issue

那么使用这个项目的风险就很高。

审查依赖关系

开源软件往往依赖大量的第三方库。像这次事件中的 Dify 就存在严重的代码节点沙箱逃逸漏洞。在部署前，最好能够：

查看项目的依赖树
检查是否有已知漏洞
定期更新依赖

定期更新和安全扫描

定期检查 CVE 数据库
使用工具如 snyk、trivy 进行依赖漏洞扫描
及时更新到修复了漏洞的版本

限制权限

即使你信任某个开源软件，也应该给它最小的权限：

不要给容器 privileged 权限
限制容器的资源使用（CPU、内存）
使用只读文件系统（如果可能）
不要把宿主机的敏感目录挂载到容器中

监控和告警

安全是一个持续的过程，不能仅仅依靠预防。建立完善的监控和告警机制至关重要：

监控系统资源使用情况（CPU、内存、磁盘IO异常可能表明有挖矿程序）
监控网络流量（异常的出站连接）
监控进程列表（异常的进程）
设置日志告警（例如失败的登录尝试）

总结

开源软件为我们提供了巨大的便利，但也带来了安全风险。这次事件虽然损失不大，但给了我一个重要的教训：

不要盲目信任任何软件，尤其是新兴的开源项目。在使用前要多做调查，在使用时要给最小权限，在使用后要持续监控和更新。

服务器安全不是一劳永逸的，而是需要持续关注和维护的。

Open Source on Svtter's Blog