技术折腾

本文介绍了作者从 2020 年开始接触 Linux 的探索历程与体会。最初因疫情在家自学编程，通过黑马程序员课程接触到 Ubuntu 的 Unity 界面，被其新奇与自由吸引。随后在 Windows 上用 WSL 运行 Ubuntu，从命令行入手，逐渐尝试 Xfce、Mate、KDE 等桌面环境，并在平板电脑上用 Termux 搭建移动开发平台。2024 年更换 RTX 4060 游戏本后安装 Ubuntu，却遇到显卡驱动、Snap 包管理器导致的系统崩溃等问题。转用 Arch 后深入理解了 Snap 的容器化机制及其商业色彩，批评其封闭、粗糙且用户体验差。同时发现 Ubuntu 的 GNOME 界面有中英文混杂、翻译不准确等缺陷，社区插件质量参差不齐。作者怀念早期 Unity 的简洁前卫，但最终因 Ubuntu 的“替用户做主”态度以及系统缺陷，转而使用 macOS，认为其流畅性和精致度远超 Ubuntu。全文以个人经历为线索，表达了对 Linux 发行版选择、包管理生态及用户体验的思考。

本文介绍了作者针对静态博客实现邮箱订阅推送的解决方案。文章首先指出现有方案（如基于 GitHub Issues 的推送）存在重复推送、依赖读者 GitHub 账号等问题，随后提出利用 GitHub Actions 的 Cache 系统记录已推送文章链接，从而避免重复。作者详细说明了整体流程：通过定时触发 Actions，运行 Python 脚本抓取博客 RSS 地址中的最新文章，解析标题、摘要和链接，并与缓存文件比对，若为新文章则生成 HTML 邮件，并通过 SMTP 协议密送订阅者。所有敏感配置（如 SMTP 凭据、邮箱列表）均存入 GitHub Secrets 以保护隐私。文章还给出了完整的 YAML 工作流配置和 Python 脚本示例，支持自定义邮件模板标签。最后，作者推荐使用 Resend 等免费 SMTP 服务，并列出需要创建的 Secrets 参数，方便读者 Fork 仓库后直接使用。该方案实现了真正的不重复邮箱推送，适用于任何拥有 RSS 输出的静态博客。

本文介绍了作者作为 DeepSeek 忠实用户的长期使用体验与最新发现。作者最初被 DeepSeek 吸引，因其开源特性带来代码透明与掌控权，API 按量付费模式对个人开发者极为经济，相比 Claude Code 等按月订阅方案更为灵活。近期因 Trae 引入高价排队机制而放弃使用，转而重新关注 iFlow CLI 但渴望更优的开源替代品。在社交媒体上发现由非专业出身的开发者 Hunter Bown 创建的 DeepSeek TUI，这是一款开源社区出品的命令行 Agent 工具。安装通过 npm 一行命令完成，初始化界面支持语言选择与 API Key 输入，默认使用 DeepSeek V4 Pro 并自动根据任务切换至 V4 Flash 以节省成本。其左侧面板实时展示 AI 当前操作、错误信息及 Token 预估费用，透明化设计让用户清楚每一步进展。作者利用该工具解决了之前由同一模型在 iFlow CLI 中编写的有问题的 PJAX 友链代码，实现了“自己修复自己 Bug”的效果。最后作者计划用 DeepSeek TUI 基于 SMTP 和 RSS 为静态网站搭建文章更新邮件提醒功能，旨在提供更纯粹、不依赖第三方平台的订阅体验，并充分利用闲置的邮箱地址。全文展现了开源工具链的自由度与社区创新的价值。

本文介绍了作者在维护个人博客网站时发现字体拥挤、段落缺乏缩进导致可读性差的问题，并借助 DeepSeek 寻求解决方案的过程。通过分析，作者确定需要针对文章正文容器（article p 和 div#article-container p）添加 text-indent: 2rem 实现首行缩进，同时为全站 body 设置 letter-spacing: 0.1rem 以增加字符间距。随后，作者在 _config.butterfly.yml 主题配置文件中正确引用了自定义的 paragraph.css 文件，并利用 GitHub Actions 自动部署更新。文章还强调了在开发者工具中验证样式是否生效、以及清除浏览器缓存或强制刷新页面等常见排查步骤，帮助读者避免因配置遗漏或缓存导致修改无效的陷阱。最终，通过精准的 CSS 选择器和统一的间距设置，网站排版获得了“书卷气”般的舒适阅读体验。

本文介绍了作者在修改 Butterfly 主题网站封面布局时，因无法通过覆写规则实现需求，转而 Fork 主题仓库直接修改源代码，却因长期未操作导致环境变化而失败。情绪冲动下，作者先删除仓库，又误删了整个网站文件夹，导致包含 60 多篇空白草稿的 _drafts 文件夹彻底丢失——这些草稿本是未来一年的选题灵感来源。作者反思了将草稿库加入 .gitignore 仅影响版本控制、无法保护本地文件的教训，并对比了此前因缺乏备份丢失 100 多篇文章文档站的更惨痛经历。文章还提到树莓派因承担评论服务和图床导致流量异常（下传 120 多 GB、上传 80 多 GB）的过往问题。最终作者依靠自己记录博客的习惯重新恢复部分脚本逻辑，但承认未来更新速度会变慢、选题难度加大。本文警示读者备份要彻底，避免选择性忽略文件。

本文介绍了作者将网站说说功能从本地文件管理迁移到远程拉取架构，解决 Git 提交历史臃肿的技术债务。随后，作者重构了标签系统，编写了两个 Python 脚本：auto-essay-tags.py 批量调用大语言模型 API 为已有说说自动生成社交媒体风格标签，essay.py 则用于新增说说时自动获取时间、生成唯一 key 并调用 API 打标签，两者共用同一标签库 essay-tags.md。文章还探讨了在轻量级标签生成场景下，长上下文并非最优解——传递最小必要信息更高效，并质疑当前 AI 厂商依赖长上下文消耗 Token 的商业模式可能扭曲了技术发展方向。

本文介绍了作者在重构网站编译模式并提交 GitHub Actions 工作流时遇到的困境。作者试图提交到官方模板仓库，却发现必须勾选一份全英文的 Pull Request 表单，其中一条要求提供图标。由于作者仅准备了代码，便尝试将 Hugo 的六角形图标修改为 Hexo 的尖角风格，但 SVG 修改失败。在求助 AI 豆包时，豆包反复复述问题却无法生成正确图片，甚至只给出空洞承诺。作者回忆豆包仅在生成角色三视图和技校填表时有用，对这次低效服务感到失望。文章探讨了 AI 工具在具体任务中的局限性及用户体验问题。

本文介绍了作者如何优化网站部署与数据管理流程，实现 Butterfly 主题的说说页面与主网站完全分离。作者首先改造了 GitHub Actions 中原本为 Next.js 设计的模板，将其适配为 Hexo 构建流程，配置了缓存、并发控制与自动部署，使每次推送代码后自动完成依赖安装、静态文件生成并部署到 GitHub Pages。随后，作者用 Python 编写脚本，将本地 YAML 格式的说说数据转换为独立 JSON 文件，并修改说说页面的 Frontmatter 配置，使其远程加载该 JSON 数据，从而实现内容与主站分离管理。最后，作者解决了因仓库名称冲突导致的路径跳转问题，通过改用不重名的仓库成功部署。整个过程显著提升了版本管理效率，降低了维护成本。

本文介绍了作者从 Windows 7 和 Windows 10 的忠实用户，到尝试 Windows 11、Linux 发行版，最终换用 MacBook Air 的曲折经历与反思。文章描述了 Win11 初期仅作为 Win10 皮肤，在低端硬件上频繁崩溃，而后在高配游戏本上表现稳定的体验对比；以及切换到 Linux 后因图形界面难用、驱动兼容问题又重回 Windows，却面临 Win10 即将停止安全更新的困境。作者指出微软砍掉测试团队、由 Surface 部门接管 Windows 业务，将用户当作免费测试员的错误做法。文章探讨了用户真正需要的是稳定一致的体验与长期安全维护，而非频繁的 UI 花样改动。最终作者得出结论：操作系统应作为可靠的生产力工具，而非需要用户不断适应和妥协的半成品。

本文介绍了作者为解决博客文章标签利用率低的问题而编写的 Python 自动化脚本。该脚本利用 DeepSeek API 为每篇文章生成 5 个适合 SEO 的标签，并优先复用已有的标签库以避免重复。脚本自动读取 Markdown 文件，调用 API 后解析返回的标签，插入到文件的 frontmatter 中，同时更新一个标签总和文件，确保每次运行只载入当前文章和标签列表，从而降低上下文熵增。作者还建议配合 Git 管理文章目录以防数据丢失。该脚本有效简化了标签分配流程，提升了博客 SEO 优化效率。