September的个人空间

国家公园不只是远方的风景

Wed, 03 Jun 2026 00:00:00 +0000

国家公园不只是远方的风景

目标受众：喜欢旅行、自然风光、户外生活，但对国家公园保护价值了解不深的普通公众，尤其是年轻人和亲子家庭。

如果你在城市里待久了，可能会对几件事格外敏感：

地铁里的拥挤，手机里的红点，楼下永远停不下来的喇叭声，还有早上醒来时那一点点“我想逃去山里”的冲动。

于是我们向往国家公园。

向往雪山、森林、湖泊、峡谷；向往一条没有红绿灯的小路；向往风吹过树梢时，不需要开降噪耳机的安静。

但国家公园的价值，远远不只是“适合拍照”“适合打卡”“适合发朋友圈”。

它更像是地球给自己留的一间恢复室，也是人类留给未来的一封绿色情书。

这里不是风景背景板，而是生命真正的家

我们去国家公园时，看到的是山、树、河流和偶尔出现的动物。

但对野生动物来说，那里不是景点，而是家。

一片森林，可能是鸟类筑巢的地方；一条河流，可能是鱼群洄游的路线；一块看似普通的草地，可能正藏着无数昆虫、种子和微生物的生命网络。

国家公园最重要的意义之一，就是把这些地方从“可以被随意消耗的资源”变成“必须被认真守护的家园”。

人类很擅长修路、建楼、开发景区，也很擅长在地图上画出新的边界。

但自然需要的，有时候恰恰是少一点打扰，多一点完整。

它保护的其实也包括我们

很多人以为保护国家公园，是在保护远方的动物和植物。

其实，它也在保护我们自己。

森林可以涵养水源、净化空气；湿地可以调节洪水、储存碳；草原和山地生态系统可以维持气候稳定，减少水土流失。

换句话说，国家公园不是城市生活的反面。

它是城市生活能够继续下去的底层系统之一。

你今天喝到的一杯水，呼吸到的一口空气，夏天少一点极端高温的可能性，都和远方那些安静运转的自然系统有关。

它们不发通知，不上热搜，不会在深夜给你弹窗提醒：

“您好，今日已为您净化空气、储存水源、稳定生态，谢谢使用。”

但它们一直在工作。

国家公园也是一间没有围墙的课堂

真正走进自然，人会变得谦虚。

站在峡谷边，你会知道时间不是只有日历上的一天一天；

看见一棵古树，你会意识到自己的忙碌可能只是它生命里很短的一阵风；

遇见野生动物，你也会明白：喜欢，不等于靠近；好奇，不等于打扰。

国家公园教给我们的，不只是地理、生物和环保知识。

它还教我们如何与世界保持距离感，如何尊重边界，如何承认人类并不是自然的主人。

这门课没有考试，但每个人都在交答卷。

喜欢它，就别只带走照片

去国家公园旅行，最好的纪念品不是石头、花朵、树枝，也不是偷偷投喂动物后拍下的“亲密合影”。

最好的纪念品，是你离开之后，它仍然像你来之前一样完整。

我们可以做的事情并不复杂：

不乱扔垃圾，把自己带来的东西带走。
不投喂野生动物，别让它们学会依赖人类。
不采摘植物，不带走石头、种子或自然遗物。
不越过步道和警示线，把“不能去”当成一种保护。
不制造过度噪音，把安静还给森林、湖泊和其他游客。
支持自然教育、生态保护和负责任的旅行方式。

环保不一定要从很宏大的口号开始。

有时候，它就是一次不乱扔垃圾，一次不投喂动物，一次把脚步停在警戒线外。

把国家公园留给明天

我们以为走进国家公园，是为了逃离城市。

后来才发现，那些森林、湖泊、山脉和动物，并不是远方的装饰。

它们在安静地保护空气、水源、气候和生命的多样性。

它们也在提醒我们：有些美好，不该只属于今天。

国家公园的价值，不只在于我们能不能去看它。

更在于很多年以后，仍然有人可以看见清澈的河流、完整的森林、自由生活的野生动物，和一个没有被我们透支完的地球。

所以，下次走进国家公园时，请轻一点。

轻一点说话，轻一点行走，轻一点索取。

因为我们不是自然的主人。

我们只是刚好路过，也刚好有责任守护它的人。

互动区

如果只能推荐一个国家公园给朋友，你会选哪里？

你最想守护的自然风景，又是什么？

欢迎在评论区写下你的答案。

配图来源与署名

Yosemite Half Dome：Jon Sullivan，Public Domain，via Wikimedia Commons。
Grand Canyon National Park：National Park Service Digital Image Archives，Public Domain，via Wikimedia Commons。
Zhangjiajie National Forest Park：Kuruman，CC BY 2.0，via Wikimedia Commons。

Git 与 GitHub 核心概念入门笔记

Sun, 24 May 2026 00:00:00 +0000

这篇是把一份 Git 与 GitHub 的长笔记重新整理成博客版。原笔记覆盖了从安装配置、初始化仓库，到分支协作、Pull Request、Cherry-pick、Stash、Rebase 等常用操作。

如果只想记住一句话：Git 负责记录代码历史，GitHub 负责把仓库放到网上协作。前者是版本控制工具，后者是代码托管和协作平台。

Git 和 GitHub 是什么

Git 是一个版本控制工具。它解决的问题是：文件改来改去以后，怎么知道每次改了什么、谁改的、什么时候改的，以及怎么回到之前的状态。

GitHub 是基于 Git 的代码托管平台。它把本地 Git 仓库放到云端，让别人可以浏览、下载、协作、提 Issue、提交 Pull Request。

可以简单理解为：

Git：本地版本管理系统
GitHub：远程仓库和协作平台
Repository：一个项目仓库
Commit：一次历史快照
Branch：一条开发线
Pull Request：请求别人合并你的改动

Git 不依赖 GitHub 也能用，但多人协作和开源项目通常会搭配 GitHub 一起使用。

准备工作

最基础的环境一般包括：

Git
VS Code
一个 GitHub 账号
可选：Codex、Claude Code 这类 AI coding agent

安装 Git 后，可以用下面命令确认：

1

git --version

新电脑第一次使用 Git，建议先配置用户名和邮箱：

1
2


git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

这两个信息会写进每次提交记录里，用来标识这次 Commit 是谁提交的。

初始化仓库

把一个普通文件夹变成 Git 仓库，可以执行：

1

git init

执行后，文件夹里会出现一个隐藏目录：

1

.git/

这个目录保存了 Git 的全部版本信息。一般不要手动改它。删除 .git/，就相当于取消这个文件夹的 Git 管理。

在 VS Code 里，也可以通过 Source Control 面板点击 Initialize Repository 完成初始化。

.gitignore 忽略文件

并不是项目里的所有文件都应该提交。

常见需要忽略的内容包括：

.env：可能保存密钥、Token、数据库密码
node_modules/：依赖包体积大，可以通过 npm install 重新安装
构建产物：例如 dist/、build/
日志和缓存文件

可以在仓库根目录创建 .gitignore：

1
2
3
4


.env
node_modules/
dist/
*.log

原则是：源码、配置模板、文档应该提交；机器生成的临时文件、依赖目录、隐私密钥不要提交。

Commit 是一次快照

Commit 可以理解为给项目拍了一张快照。

一次完整的提交流程通常是：

1
2
3


git status
git add .
git commit -m "说明这次改了什么"

其中：

git status：看当前有哪些文件被修改
git add：把改动放进暂存区
git commit：把暂存区内容保存成一次历史记录

提交信息不要写成“修改”“更新”这种空话。更好的写法是描述这次改动的意图，比如：

1
2
3


git commit -m "Add prompt guide category filter"
git commit -m "Fix homepage sidebar link"
git commit -m "Translate RenPy interpolation guide"

以后回看历史时，Commit Message 是最快的索引。

工作区、暂存区、本地仓库、远程仓库

理解 Git 最重要的是理解几个区域。

区域	含义
Working Directory	当前文件夹里正在编辑的文件
Staging Area	准备提交的改动，也就是 `git add` 后的区域
Local Repository	本地保存的 Commit 历史
Remote Repository	GitHub 上的远程仓库

常见命令对应关系：

1
2
3
4


git add # 工作区 -> 暂存区
git commit # 暂存区 -> 本地仓库
git push # 本地仓库 -> 远程仓库
git pull # 远程仓库 -> 本地仓库并合并

很多 Git 问题，本质上是在问：这个改动现在在哪个区域？

撤销操作：Discard、Reset、Revert

Git 里有好几种“后悔药”，但它们适用场景不同。

操作	作用	适合场景
Discard	丢掉工作区未提交的改动	文件改坏了，还没 commit
Reset	把分支指针退回某个历史状态	本地历史需要重写，通常适合未推送的提交
Revert	生成一个反向提交来撤销旧提交	已经推送或多人协作时更安全

新手最容易混淆 reset 和 revert。

简单规则：

自己本地还没推送的提交，可以考虑 reset
已经推送到远程、别人可能基于它继续开发的提交，优先用 revert

revert 不会删除历史，而是新增一条“抵消旧改动”的提交，所以更适合团队协作。

Branch 分支

分支是另一条开发线。

常见用法是：主分支保持稳定，新功能放到单独分支开发。

1

git switch -c feature/login

开发完成后，再合并回主分支：

1
2


git switch main
git merge feature/login

分支的价值在于隔离风险。你可以在 feature 分支上尝试新功能，不影响 main 的稳定状态。

如果使用 VS Code 或 GitHub Desktop，也可以通过界面创建、切换和删除分支。

HEAD 是什么

HEAD 表示当前仓库指向哪一次提交。

通常情况下：

在 main 分支上，HEAD 指向 main 的最新提交
在 feature 分支上，HEAD 指向 feature 的最新提交
如果 checkout 到某个历史提交，可能进入 detached HEAD 状态

Detached HEAD 可以用来看历史代码，但不适合直接长期开发。需要继续改的话，最好从这个状态创建一个新分支。

Worktree 工作树

Worktree 可以让一个仓库同时拥有多个工作目录。

它适合这种场景：

常用命令：

1

git worktree add ../project-feature feature-name

AI coding agent 很适合搭配 worktree：每个任务一个独立工作树，互相不干扰，完成后再合并。

Merge Conflict 合并冲突

当两个分支修改了同一个文件的同一部分，Git 不知道该保留谁，就会产生冲突。

解决冲突不是“哪个按钮更高级”，而是人工判断最终文件应该长什么样。

一般流程：

打开冲突文件
找到冲突标记
保留正确内容
删除冲突标记
git add
git commit

冲突标记大概长这样：

1
2
3
4
5


<<<<<<< HEAD
当前分支内容
=======
另一个分支内容
>>>>>>> feature

在 VS Code 中可以选择保留当前、保留传入、两者都保留，但最终还是要确认合并后的代码是否合理。

Clone、Push、Pull

远程仓库最常用的三个动作是：

1
2
3


git clone <url>
git push
git pull

含义分别是：

clone：把 GitHub 上的仓库复制到本地
push：把本地提交推送到 GitHub
pull：把 GitHub 上的新提交拉到本地

如果你先在 GitHub 创建仓库，再复制到本地，一般用 clone。

如果你先在本地写了项目，再想传到 GitHub，就先 git init、commit，再添加远程仓库并 push。

GitHub 页面常用功能

GitHub 不只是放代码的网盘，它还有很多协作功能。

常用区域包括：

Code：查看代码、下载 zip、复制 clone 地址
Commit：查看提交历史
README：项目介绍，一般是仓库首页最重要的说明
Releases：发布版本和下载构建产物
Issues：提 bug、需求、讨论
Pull Requests：代码合并请求
Actions：自动化构建、测试和部署
Fork：把别人的项目复制一份到自己账号下
Star：收藏项目，也能反映项目热度

快捷键也很实用：

/：搜索仓库内容
t：快速找文件
.：在浏览器打开网页版 VS Code
?：查看 GitHub 快捷键

Fork 和 Pull Request

开源协作通常不是直接改别人的仓库，而是：

Fork：把仓库复制到自己账号
Clone：把自己的 fork 克隆到本地
Branch：创建新分支修改
Commit：提交改动
Push：推送到自己的远程仓库
Pull Request：请求原项目合并

Pull Request 不是单纯的“上传代码”，它也是讨论区。维护者可以 review 代码、提出修改意见，直到确认没问题再合并。

如果你是项目协作者，仓库管理员也可以直接把你加成 collaborator。这样你可以直接 push 到仓库，但更推荐仍然通过分支和 PR 保持审查流程。

Cherry-pick 精选提交

cherry-pick 用来把某几个 Commit 单独拿到当前分支。

例如 feature 分支有三次提交：

1
2
3


A 修按钮
B 改文案
C 加功能

你只想把 A 合到 main，不想要 B 和 C，就可以 cherry-pick A 的 Commit ID。

1

git cherry-pick <commit-id>

它适合“只挑某个改动”的场景，不适合替代正常合并流程。

Stash 临时存储

如果你正在改代码，突然需要切到另一个分支处理急事，但当前改动还不适合提交，可以用：

1

git stash

它会把当前未提交改动临时收起来，让工作区恢复干净。

回来以后再恢复：

1

git stash pop

Stash 适合临时切换任务，不应该长期当作保存代码的地方。真正有价值的进度还是应该 commit。

Rebase 变基

rebase 可以把一个分支的提交“挪到”另一个分支最新提交之后，让历史更线性。

例如：

1
2


git switch feature
git rebase main

效果是：feature 分支像是基于最新 main 重新开发出来的一样。

注意：rebase 会改写提交历史。
如果这个分支已经推送并且别人也在用，随便 rebase 再强推会影响别人。所以它更适合个人分支、尚未公开协作的分支。

简单规则：

自己一个人用的功能分支，可以 rebase
多人共用的公共分支，谨慎 rebase
主分支不要乱 rebase

AI 时代更要懂 Git

现在很多代码可以交给 AI agent 写，但 Git 反而更重要。

因为 AI 改代码很快，也可能一次改很多文件。如果没有 Git，你很难回答这些问题：

AI 到底改了哪些文件？
哪次改动引入了问题？
能不能只保留其中一部分？
能不能回到 AI 修改前的状态？
多个 AI 任务能不能并行？

所以 AI coding 的基础动作应该是：

1

一个任务 -> 一个分支或 worktree -> 小步 commit -> 审查 diff -> 再合并

不要让 AI 在一个长期混乱的工作区里连续改很多轮。每完成一个明确的小功能，就 commit 一次。这样即使后面改坏了，也能清楚地回退。

总结

Git 的核心不是背命令，而是理解版本流动：

1

工作区 -> 暂存区 -> 本地仓库 -> 远程仓库

GitHub 的核心也不是“上传代码”，而是围绕仓库建立协作流程：

1

Fork -> Branch -> Commit -> Push -> Pull Request -> Review -> Merge

掌握这些概念后，命令只是操作方式。无论是在 VS Code 里点按钮，还是让 AI agent 执行命令，本质都是在移动文件状态、提交历史和分支指针。

对新手来说，最值得先熟练的不是所有高级命令，而是这几件事：

会看 git status
会做小步 commit
会写清楚提交信息
会用分支隔离任务
会区分 discard、reset、revert
会把本地改动 push 到 GitHub
会通过 Pull Request 协作

这些掌握了，Git 和 GitHub 就不再是黑盒，而是你和 AI、队友、未来的自己协作时最可靠的底座。

把 Ren'Py 游戏翻译流程写成一个可复用 Skill

Sat, 23 May 2026 00:00:00 +0000

最近把一套 Ren’Py 游戏翻译流程整理成了一个 Codex Skill。它的作用不是“教 AI 怎么随便翻译几句文本”，而是把 Ren’Py 汉化里那些很容易被忽略的规则，变成一份可以反复执行的检查清单。

Ren’Py 游戏翻译看起来很简单：找到文本，翻成中文，保存。但真正做起来会发现，问题经常不在“这句话怎么翻”，而在“这句话到底会不会被 Ren’Py 正确匹配、正确加载、正确显示”。

所以这个 Skill 的核心思路是：不要把翻译当成纯文本替换，而要把它当成一个小型补丁工程。

为什么要写成 Skill

单次翻译靠经验可以做完，但下一次换一个游戏，很多坑还会再踩一遍。

比如：

old 字符串被改了一个空格，导致翻译完全匹配不上
菜单选项带了文字标签或状态后缀，生成的翻译没有覆盖真实显示内容
变量插值里的人名、阵营名仍然显示英文
字体不支持中文，结果游戏里全是方块
直接改原脚本，更新游戏后补丁很难迁移
批量脚本写文件时编码错了，中文变成乱码或问号

这些不是“翻译水平”问题，而是流程问题。Skill 适合处理的正是这种流程：每次遇到 Ren’Py 项目，都按同一套顺序检查、修改和验证。

工作区应该放在哪里

Ren’Py 翻译最重要的目录是：

1

game/tl/<language>/

Skill 里的第一条规则就是：优先在翻译目录里工作，能不改原始脚本就不改原始脚本。

原因很现实。原脚本是游戏本体的一部分，直接改它虽然快，但后续更新、分发、回滚都会变麻烦。更稳的方式是把翻译、字体、界面覆盖、语言按钮、默认语言设置等内容尽量放进 game/tl/<language>/。

这样做的好处是：

删除语言文件夹就能恢复原版
游戏更新时更容易迁移
补丁边界清楚
不容易误伤原游戏逻辑

如果原游戏没有 .rpy，只有 .rpyc 或资源包，那就先处理解包、反编译或生成翻译文件的问题，而不是直接乱改。

old/new 不能乱动

Ren’Py 里常见的翻译形式有两种。

一种是对话块：

1
2


translate chinese start_abc123:
 "这里写翻译后的台词"

另一种是字符串表：

1
2
3


translate chinese strings:
 old "Start"
 new "开始"

这里最容易犯的错是改 old。
old 不是给你润色的原文，它是 Ren’Py 用来匹配原始文本的钥匙。空格、标点、文本标签、大小写、换行都可能影响匹配。

所以规则很简单：

1
2


old 保持原样
new 写翻译

如果一个 old 看起来有点怪，比如带着 {size=}、颜色标签、状态后缀，也不要顺手清理。真实运行时显示出来的字符串很可能就是这么匹配的。

菜单和 UI 要单独查

Ren’Py 自动生成翻译文件很有用，但它不一定能覆盖所有运行时可见文本。

除了对话，还要主动搜索这些位置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Character("...")
text "..."
textbutton "..."
tooltip "..."
renpy.input("...")
renpy.notify(...)
default xxx = "..."
define xxx = "..."
$ xxx = "..."
menu:

尤其是菜单选项。它们经常带条件、标签、样式或自定义 screen 处理。你在翻译文件里看到的 old "Yes"，不一定覆盖了运行时真正显示的 {color=#fff}Yes{/color}。

如果某个选项死活不翻译，别先怀疑 Ren’Py。先把运行时原文和 old 逐字节对一下，包括空格和标签。

变量插值是隐藏大坑

这次整理 Skill 时，最值得单独记下的是变量插值。

Ren’Py 里常见写法是：

1

"Welcome to [tribe_name], [player_name]."

如果 tribe_name 的值是 "Wartribe"，即使你在字符串表里写了：

1
2


old "Wartribe"
new "战族"

最终显示时也不一定会自动变成中文。因为普通的 [tribe_name] 插值只是把变量当前值拿出来显示，不会必然再走一遍翻译表。

这种情况下要用翻译感知插值：

1

"欢迎来到 [tribe_name!t]，[player_name!t]。"

如果变量翻译后还需要继续插值，可以看情况用：

1

[variable!ti]

这个坑很隐蔽，因为外面的句子已经翻译了，只有嵌进去的人名、地名、阵营名还保留英文。看起来像漏翻，其实是插值方式不对。

高级补丁放 zzz.rpy

有些问题不是一句 old/new 能解决的，比如：

添加语言切换按钮
设置默认语言
替换字体
调整中文 UI 样式
覆盖 screen
修正少量源代码层面的文本

这类内容可以放到翻译目录里的补丁文件，例如：

1

game/tl/chinese/zzz.rpy

常见做法是加：

1

init offset = 1

让补丁比原定义更晚加载。这样可以覆盖 screen、style、define 等内容，又不会直接动原文件。

默认语言也要分清：

1

define config.default_language = "chinese"

这更适合“首次启动默认中文”。
如果用 config.language 强行指定语言，就可能变成每次启动都锁死语言，不一定符合玩家预期。

字体不是最后再想的事

中文翻译里，字体问题经常到最后才暴露：文本已经翻好了，进游戏一看全是方块。

Skill 里把字体和样式也放进检查范围。一般有几种处理方式：

在 translate <language> style 里覆盖样式
在 translate <language> python 里设置 GUI 变量
在 game/tl/<language>/ 下镜像放置字体资源
用 zzz.rpy 做语言限定的字体覆盖

关键是尽量让字体修复只影响目标语言，不要全局改坏原版 UI。

不要信任批量替换

批量脚本很诱人，尤其是翻译量大的时候。但 Ren’Py 文件里有很多结构性内容：

缩进
引号
转义符
文本标签
插值变量
%、\、/ 这类特殊符号

如果脚本没有严格按 UTF-8 读写，中文很容易变成乱码、问号或损坏标签。

所以 Skill 里明确写了：在 Windows 上做批量编辑时，要使用明确的 UTF-8 读写方式。改完后要扫一遍：

1
2
3
4
5


乱码
???? 
� 
损坏的 {tag}
损坏的 [variable]

翻译文件不是普通 Markdown，不能只看文本大概对不对。

验证要看三个文件

改完之后，不要只打开一两句台词看看。至少要检查：

1
2
3


errors.txt
traceback.txt
text_overflow.txt

它们分别对应不同问题：

errors.txt：生成或启动阶段的问题
traceback.txt：运行时崩溃
text_overflow.txt：文本溢出、排版放不下

还要实际测试：

主菜单
设置界面
语言切换
存档读档
代表性对话
选项菜单
字体显示
被覆盖的 label 或 screen

Ren’Py 翻译不是“文件能保存就完成”，而是“游戏运行时每条路径都能正确显示”。

这个 Skill 最有用的地方

我觉得它最有用的不是告诉 AI “请翻译成中文”，而是强迫 AI 先尊重 Ren’Py 的工程规则。

它会提醒我：

不要乱改 old
不要直接动原脚本
不要忽略菜单和 UI
不要忘记变量插值的 !t
不要把字体和排版当成收尾小事
不要跳过运行验证

这比单纯提高翻译文风重要得多。

总结

Ren’Py 游戏汉化本质上不是文本替换，而是一套围绕运行时匹配、语言加载、界面覆盖和补丁分发的工程流程。

把这套流程写成 Skill 之后，AI 就不只是“会翻译”，而是会按固定步骤处理项目结构、翻译文件、UI 字符串、变量插值、字体、补丁和验证。

下一次再做 Ren’Py 游戏翻译时，就不用从零回忆哪些坑要避开。直接让 Skill 接管检查清单，人只需要把关翻译质量和最终体验。

NotebookLM 做 PPT 的正确打开方式：先搭结构，再分章生成

Fri, 15 May 2026 00:00:00 +0000

最近看了一个 NotebookLM + Antigravity 的进阶教程，里面有一个点很适合单独拎出来写：不要把 NotebookLM 当成“一键生成 PPT”的按钮，而是把它当成一个能理解资料、拆解结构、辅助生产的外脑。

如果只是把一堆资料扔进去，然后直接让它生成 PPT，结果通常不会太理想。它会很快给你一份看起来完整的幻灯片，但页数有限、内容压缩严重，很多细节被省略。对于读书报告、课程展示、专题分享这种材料量比较大的任务来说，这种“一键生成”更像是摘要，不像是一份真正能拿去讲的 PPT。

更好的做法，是把 PPT 制作拆成几个阶段。

先让 NotebookLM 搭大纲

第一步不要急着生成幻灯片，而是先让 NotebookLM 读完资料，输出一个完整大纲。

这个大纲至少要包括：

整份 PPT 要分成几个章节
每个章节负责讲什么
每个章节大概需要几页
每页承担什么信息
整体的风格、语气和版式方向

这一步的意义是先拿到全局地图。AI 最容易犯的错误，不是不会写，而是在没有全局规划时把复杂内容压扁。先要结构，再要页面，后面的结果会稳定很多。

再按章节分批生成

NotebookLM 直接生成 PPT 时会遇到页数和信息密度的限制。如果材料很多，可以把生成任务拆开。

比如一份 60 页左右的专题 PPT，可以拆成：

第 1 章：背景与问题
第 2 章：核心概念
第 3 章：案例或文本分析
第 4 章：方法总结
第 5 章：结论与延伸

每次只让它生成其中一章。这样做有两个好处：一是绕开单次生成页数太少的问题，二是每一章能写得更细，不会被强行压缩成几页概述。

用固定提示词保持风格一致

分章生成的问题也很明显：如果每次提示词不一样，最后合起来就会像几份不同 PPT 拼在一起。

所以每次生成时，都应该复用同一套风格要求，例如：

标题层级保持一致
封面页、章节页和内容页的版式统一
配色和字体气质统一
每页信息密度接近
图文比例一致
不要突然切换成完全不同的设计风格

这部分可以理解成给 AI 一份“设计规范”。它不一定能百分百遵守，但有规范总比每次自由发挥要可靠。

最后人工合并和校对

AI 生成的内容不能直接当成最终稿。最后还要人工做一次整合。

我会重点检查这些地方：

章节之间有没有重复
页面顺序是否顺畅
每章开头和结尾是否能接上
标题风格是否统一
重点结论有没有被埋掉
有没有看起来很漂亮但实际上没信息量的页面

这一步很重要。AI 擅长把资料快速摊开，但最后的表达节奏还是要人来把关。PPT 不是资料堆叠，而是一次有顺序的讲述。

Antigravity 的作用

视频里另一个思路是把 NotebookLM 和 Antigravity 连起来，让一个工具负责理解资料，另一个工具负责操作、检索和自动化。

这种组合的价值在于：NotebookLM 更像资料库和阅读助手，Antigravity 更像可以执行任务的工作台。前者负责理解，后者负责行动。比如让它自动搜索资料、构建笔记本、整理来源，再反过来指导 PPT 或项目开发。

这其实是一个很有代表性的 AI 工作流变化：不是让一个工具包办全部，而是让多个 AI 工具各自做擅长的事。

我自己的理解

这套方法真正有用的地方，不在于“AI 可以帮我做 PPT”，而在于它把制作 PPT 的流程重新拆开了。

传统做法是：

1

找资料 -> 整理资料 -> 写大纲 -> 做页面 -> 改格式

一键生成的做法是：

1

塞资料 -> 生成 PPT

但更稳的 AI 工作流应该是：

1

塞资料 -> 生成结构 -> 分章生成 -> 统一风格 -> 人工整合

这比一键生成多了几步，但每一步都更可控。尤其是材料量大、主题复杂、最后还要公开展示的时候，可控性比速度更重要。

总结

NotebookLM 不应该只被当成 PPT 生成器。它更适合当成资料理解器、结构规划器和内容初稿生成器。

如果只是想快速做一份十几页的展示，一键生成当然够用。但如果想做一份真正能讲清楚问题的长 PPT，就应该先让它帮你搭结构，再分章生产，最后人工合并和润色。

AI 做 PPT 的关键不是“少点几下鼠标”，而是把原本混乱的资料整理过程变成一个更清晰的工作流。它节省的不是最后排版那一点时间，而是从资料到表达之间最消耗脑力的那段路。

把旧手机变成私人学习资料网盘

Sat, 02 May 2026 00:00:00 +0000

之前博客已经跑在一台安卓手机上了。既然这台手机本来就 24 小时在线，那干脆再给它加一个更实用的功能：私人学习资料网盘。

现在入口是：

September Archive

主要用来放课程 PPT、教材 PDF、作业资料、考试复习文档，还有一些平时从桌面和聊天记录里扒出来的学习文件。它不是公开资源站，更像是给自己准备的长期资料仓库。

架构

整体结构很简单：

1
2
3
4
5


安卓手机 Termux
 └─ Alist
 └─ /sdcard/StudyArchive
 └─ Cloudflare Tunnel
 └─ drive.september.win

手机本地跑 Alist，资料实际存在 /sdcard/StudyArchive。外部访问不直接暴露手机端口，而是通过 Cloudflare Tunnel 转发到公网域名。

这样做的好处是：

不需要公网 IP
不需要在路由器上开端口
手机只主动连 Cloudflare
网盘地址稳定
和博客一样都挂在自己的域名下面

安全

这个网盘没有裸奔。

外层用了 Cloudflare Access，访问 drive.september.win 时会先要求邮箱验证码。通过之后才会进入 Alist 自己的登录页。

也就是说现在是两层：

1
2
3


Cloudflare Access
 -> Alist 登录
 -> StudyArchive

Alist 的游客访问也关掉了，游客按钮也从页面里隐藏了。文件接口未登录时会返回 401。

这点很重要，因为学习资料虽然不是什么商业机密，但里面可能混着作业、论文、准考证、课程名单之类的东西，不能随便暴露在公网。

资料整理

这次顺手把电脑里的学习资料整理了一遍。

大致扫了这些地方：

1
2
3


D:\
E:\
Desktop

最后手动整理成几个分类：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Presentation
人智
党史课资料
分析化学
基础无机化学实验
新生研讨课
有机化学（生科，生技）
生物
线代
职规赛
英美文学鉴赏
逻辑学
高等数学

最后传到手机上一共大约 1.1GB，230 个文件。

网页外观

Alist 默认界面有点朴素，所以换了一套社区美化主题，又稍微改了一下：

背景图使用博客同款背景
favicon 和头像使用博客头像
左上角改成 September Archive
加了一个上传入口
友链页面也挂上了网盘入口

现在它看起来更像博客的一部分，而不是一个突兀的单独服务。

上传方式

目前上传有两种方式。

一种是直接登录网页，在网盘里上传文件。

另一种是本地先整理好文件夹，然后打包传到手机，再解压到：

1

/sdcard/StudyArchive

这次大批量传输的时候，普通 scp 走 Cloudflare SSH 隧道太慢，所以最后用了临时下载隧道：电脑开一个本地 HTTP 服务，再用 Cloudflare quick tunnel 暴露给手机下载。下载完成后校验 SHA256，再在手机端解压。

虽然过程有点绕，但对大文件比一堆小文件逐个 scp 稳得多。

为什么不用现成网盘

不是不能用 OneDrive、百度网盘、阿里云盘这些服务，只是它们不太像“自己的资料库”。

我想要的是：

域名是自己的
文件放在哪里自己知道
目录结构自己控制
上传下载没有额外客户端绑架
可以和博客、服务器、自动化脚本继续联动

这也是自建服务最有意思的地方：它不一定更省事，但更可控。

后续计划

后面还可以继续加几件事：

WebDAV，同步 Obsidian 或 Zotero
自动备份到另一台电脑或对象存储
给 PDF 和文档做全文搜索
做一个学习资料索引页
按课程自动生成目录
给重要资料加冷备份

目前第一版已经够用了。旧手机继续发光发热，博客和网盘都跑在上面，也算是一个小型个人资料中心了。

清理c盘用软件

Sun, 19 Apr 2026 00:00:00 +0000

逮到一个很好用的C盘清理软件

https://privazer.com/zc/download.php

专为阿尔卡娜写的一篇博客

Sun, 12 Apr 2026 00:00:00 +0000

那无所畏惧，仿佛要将我整个吃掉的眼神。

即便如此，仍让人想守护的女孩。

时而撒娇，时而主动进攻的存在。

前言

在前前后后花费了近十个小时的时间，终于在更新前四个小时玩完了妮姬的这次活动。

先评价一下本次活动吧，可以说是顶中顶，不亚于阿尔卡娜第一次活动带给我的惊喜，上一次阿尔卡娜的初登场活动承接了2.5周年失败的剧情，给玩家发了一波小甜饼，狠狠地挽救了一波妮姬的活动剧情的质量。而这一次又延续了上一个活动（E.H.的背景故事）的优质剧情，同时也承担了缺失的情人节活动的重任，着实令人惊喜。

值得一提的是当初的提前解包泄露中出现了这样一张图片

一度被人猜测是否是第二位拥有指挥官子嗣的妮姬，以至于~~某位红发女保安~~拉毗的本就脆弱的女主地位被动摇，不过显然这是官方的恶趣味，那个蓝发小孩只是路边的一个小孩。

阿尔卡娜个人简介

OK先来介绍一下这位蓝毛吧，她隶属于“极乐净土”企业，所在部队为“热销如潮”。表面上，阿尔卡娜的职责是管理方舟图书馆，实际负责管理禁书库部分机密信息。由于工作的问题，阿尔卡娜会定期清除一些记忆。

作为副业，阿尔卡娜经营着一家小型塔罗牌占卜店。性格外向开朗，社交能力极强。她喜欢用一些跳脱的塔罗牌解读来捉弄人（尤其喜欢捉弄指挥官），但令人意外的是，她的实际占卜结果往往具有惊人的准确率，这点在这次的剧情中也有所体现。

虽然在剧情的“强度”达到了前所未有的高度~~足以比肩另一位蓝毛三号位充能辅助妮姬~~，但是她的实际强度却十分甚至九分高，其名为命运伴侣的异格在火系霰弹队中扮演了一块重要的拼图。

部分台词欣赏

我：差点忘了……

阿尔卡娜：学长怎么可以忘记！

阿尔卡娜：不然您以为我是谁？？

我：女朋友啊。

阿尔卡娜：……啊？

一击击沉阿尔卡娜后，我重新看起资料。

这样的女孩逗逗也不错

阿尔卡娜：您是不是想说，「阿尔卡娜在那青春的中心每天都只顾着玩」，或者「说是这样说，其实你根本不喜欢待在教室里吧」！

我：……

我：阿尔卡娜在那青春的中心每天都只顾着玩。

阿尔卡娜：啊啊啊啊！

我轻轻松松地将冲过来的阿尔卡娜封印在怀里。

整个前哨基地谁人不识君

阿尔卡娜抬起头来。她露出灿烂的笑容，托着下巴看我。

阿尔卡娜：是不是有人在觊觎学长？

艾米：……

艾米：……对，而且还不少。

我：你，你怎么知道……？

随时随地发糖

阿尔卡娜：怎么了？

我：你看起来很开心。

阿尔卡娜：当然开心。

阿尔卡娜：因为是跟喜欢的人一起做喜欢的事。

小吃醋也很可爱

我：我倒是很难想象你生气的样子。

阿尔卡娜：我也是会生气的好吗？嗯……

阿尔卡娜：要是学长在我面前跟别的女生……

阿尔卡娜：跟别的女生……这样那样的话！我当然会生气啊！

阿尔卡娜：……光想象就真的让我好火大喔！

我：……

阿尔卡娜：不过，您要做也不是不行。前提是不要被我发现。

阿尔卡娜：被我抓到，你们两个就死定了。

我：如果对方是更凶的女生怎么办？

我：你又不太会打架。

阿尔卡娜：……

我：你好漂亮。

阿尔卡娜：……

阿尔卡娜：……那个只是我随口说说而已。

阿尔卡娜：不准笑！

我：……

阿尔卡娜：现在装哭又是什么啦？

阿尔卡娜：……真是的。走了啦。

阿尔卡娜：唉，果然喜欢更多的那一方就是比较吃亏呢。

阿尔卡娜：被牵着走也只能认了～

明明就在乱翻牌子嘛

我：……就这样？

阿尔卡娜：不不不。

阿尔卡娜：总之先随手丢出来了，接下来就要看牌面硬凑出一套说法。

阿尔卡娜：来，您试试看。

我：到这一步又换我来了？？

阿尔卡娜：嘿嘿，因为我现在也没什么头绪。

我：这……

在女仆人数超过二位数和不知道多少次金币之战后

阿尔卡娜：学长喜欢女仆也算是公开的秘密了。

我：……

阿尔卡娜：不对，是比较喜欢兔女郎吗？

我：……外面到底都在传什么谣言？

阿尔卡娜：正所谓无风不起浪，

阿尔卡娜：好好反省一下您平时的行为吧。

阿尔卡娜：不过，我两种都可以穿给您看就是了。

紧紧地抓住

阿尔卡娜：锵～

……她把只剩下「学长」两个字的便利贴拿给我看。

阿尔卡娜：这样就好了吧？

我：……

阿尔卡娜：……啊啊！我清单里唯一剩下的就是学长耶！

阿尔卡娜：要是不小心弄丢就糟了，所以一定要牢牢抓住～

阿尔卡娜用力地和我十指交扣。

绚烂的烟火

嘴唇分开后，阿尔卡娜钻进了我的怀里。我抱紧阿尔卡娜，抬头望着烟火。

阿尔卡娜：我……从来没想过这辈子能看到这样的景象。

阿尔卡娜：真的真的……好开心。

我：嗯，我也是。

阿尔卡娜：……嘿嘿。

众目睽睽的告白

阿尔卡娜：有话想对学长说！

爱因：喔？什么啊～公开告白？

阿尔卡娜：是的！我觉得现在不说就来不及了！

我：……

阿尔卡娜：那我说了。

阿尔卡娜：……学长～！

阿尔卡娜：总是让我能够依靠、

阿尔卡娜：总是把我放在心上、

阿尔卡娜：还有总是爱着我的学长～

……阿尔卡娜称呼我「学长」，这平常是我们之间默认的情景演出。但是，现在……

阿尔卡娜：……这样的学长。

阿尔卡娜：让我所做的一切变得有意义。

阿尔卡娜：为我们顶着性命去战斗，

阿尔卡娜：以及……

阿尔卡娜：把我世界的一半找回来的学长……！

阿尔卡娜：我真的真的……

阿尔卡娜：……真的真的很喜欢您！！！

太受欢迎的男友

打扮华丽的女子：我想让这位哥哥给我买单。

阿尔卡娜：什么？

我：什么？

打扮华丽的女子：不是可以自己选吗？

阿尔卡娜：是……是没错……

我和阿尔卡娜交换了眼神。

阿尔卡娜：……学长。

我：是。

阿尔卡娜：我们明天不要开摊了。

我：……什么？

阿尔卡娜：……

我：好。

阿尔卡娜：真乖～

太受欢迎的男友的女友的觉悟

阿尔卡娜：唉……学长有什么好道歉的。

阿尔卡娜：交了一个太受欢迎的男朋友，本来就要有心理准备。

阿尔卡娜：……不过这两天确实有点奇怪。

阿尔卡娜：简直像整人节目……

兔女郎装是惊喜

阿尔卡娜：……对。

阿尔卡娜：这几天一直有其他女生靠近学长身边，让我有点在意……

阿尔卡娜：所以想说要给您这、这种惊喜，

阿尔卡娜：让您不会产生别的心思……

阿尔卡娜拿起兔女郎装。

……虽然那的确是衣服，但尺寸小得有点夸张。

阿尔卡娜：是一时冲动买的，所以尺寸……太小……

我们结婚吧

我：你很漂亮。

阿尔卡娜：再来、再来。

我：非常适合你。

阿尔卡娜：嘿嘿。

阿尔卡娜：再来、再来、再来。

我：我们结婚吧。

阿尔卡娜：好。

阿尔卡娜：新娘阿尔卡娜，愿与学长结为伴侣。

阿尔卡娜：无论顺境逆境，都将永远爱您、尊重您。

阿尔卡娜：对您忠诚，尽到妻子应尽的责任。

阿尔卡娜：与您共组幸福的家庭。

阿尔卡娜：……这样就回到平常的心情了吧？

呃，嗯。

阿尔卡娜：反正老师已经完全被我迷住了。

我：呃，嗯。

阿尔卡娜侧过身，靠在我身上。

阿尔卡娜：……要小心别被发现呢。

阿尔卡娜：还是……

阿尔卡娜在我耳边小声说道。

阿尔卡娜：要不要，故意让其他人发现？

日常工作

阿尔卡娜：老师，啊～

躺在我腿上的阿尔卡娜，剥了橘子喂我吃。

阿尔卡娜：还剩很多事情吗？

阿尔卡娜：今天会议把大部分的事情都定下来了。

我：不过最后决定的要决定好，该整理的也要整理好。

我：也还要获得批准。

阿尔卡娜：啊啊，所以才说我帮不上忙喔？

在别的学校度过庆典中

阿尔卡娜：那我是不是看起来像在Cosplay？

阿尔卡娜摆了个奇怪的姿势。

阿尔卡娜：其实我早就毕业很久了，根本不是学生。

阿尔卡娜：然后老师就是那个让女朋友穿制服Cosplay的坏男友。

阿尔卡娜：我其实没有很喜欢，但穿起来又好像有点漂亮。

阿尔卡娜：然后看到男友很开心，自己也有点高兴。

阿尔卡娜：可是为了自尊心，又不能太高兴，是有点别扭的那种女友。

《坏结局》

阿尔卡娜：不要啦～就是老师啦～

阿尔卡娜：妮姬跟指挥官的话，反而不能这样一起……吗……

阿尔卡娜：陪我啦……抱我～

想去女仆咖啡厅

阿尔卡娜：我超想去女仆咖啡厅的。

我：是吗？

阿尔卡娜：嗯嗯。其实本来没什么兴趣。

阿尔卡娜：不过知道老师喜欢女仆之后就稍微查了一下。

阿尔卡娜：感觉还挺有趣的，衣服也很可爱。

我：呃，嗯……

阿尔卡娜：要我对老师「柔软滑顺，咪」吗？

今后也请多关照

阿尔卡娜：我们回到指挥官和妮姬的身份之后，也要继续谈恋爱。

阿尔卡娜：因为我觉得这样太可惜了。

我：……

阿尔卡娜：我有很多原本想做的事情、未来想做的事情。

阿尔卡娜：原本想跟您一起加入摄影社。

阿尔卡娜：那之后我们就一起去参加摄影同好会。

阿尔卡娜：原本想每天帮您准备便当。

阿尔卡娜：那以后您午餐就一定只能吃阿尔卡娜牌便当。

我：……阿尔卡娜。

阿尔卡娜：嗯。

我：……

我：今后也请多关照。

阿尔卡娜：……

阿尔卡娜：……嗯，我也喜欢您。

部分游戏内cg欣赏

2×2活动体验

🎮 本视频为互动剧情，点击前往 B 站体验完整分支界面 🚀

Markdown 基本语法指北

Mon, 06 Apr 2026 00:00:00 +0000

几乎所有现代的博客平台和静态网站生成器都完美支持 Markdown。它能让我们在纯文本环境下专注于内容创作，而无需被复杂的排版工具打断思路。

以下是日常写作中最常用的 Markdown 基本语法。

1. 标题 (Headings)

要在文档中创建标题，请在单词或短语前面添加井号 (#)。# 的数量代表了标题的级别。为了兼容性，请务必在 # 和标题文字之间保留一个空格。

1
2
3
4
5
6


# 一级标题
## 二级标题
### 三级标题
#### 四级标题
##### 五级标题
###### 六级标题

2. 段落与换行 (Paragraphs & Line Breaks)

段落： 创建段落非常简单，只需要使用一或多个空白行将连续的文本分隔开即可。不要用空格（spaces）或制表符（tabs）缩进段落。

换行： 如果你想在段落内强行换行（创建 <br>），请在这一行的末尾添加两个或多个空格，然后按回车键。

3. 强调语法 (Emphasis)

通过添加星号或下划线，可以轻松实现加粗和斜体效果。

加粗：在单词或短语的前后各添加两个星号或下划线。
- **加粗文本**
- __加粗文本__
斜体：在单词或短语的前后各添加一个星号或下划线。
- *斜体文本*
- _斜体文本_
加粗斜体：前后各添加三个星号或下划线。
- ***加粗且斜体的文本***

4. 引用 (Blockquotes)

要在段落前添加块引用，请在段落的第一行或者每一行前面添加一个 > 符号。引用不仅支持多段落，还可以嵌套其他 Markdown 元素。

1
2
3
4


> 这是一段引用文本。
> 
> > 这是一个嵌套的引用。
> > 里面还可以使用 **加粗** 等其他语法。

5. 列表 (Lists)

你可以将项目组织成有序列表或无序列表。

有序列表： 在每个列表项前添加数字并紧跟一个英文句点。数字不必按数学顺序排列，但列表应当以数字 1 起始。

1
2
3


1. 第一项
2. 第二项
3. 第三项

无序列表： 在每个列表项前添加破折号 (-)、星号 (*) 或加号 (+)。建议统一使用 -。

1
2
3


- 苹果
- 橘子
- 香蕉

6. 代码 (Code)

行内代码： 如果要把句子中的某个单词或短语标记为代码，请将其包裹在反引号 ( \ `) 中。

示例：使用 print("Hello World") 来输出文本。

代码块： 要创建多行代码块，请将代码包裹在三个反引号 (```) 中。在第一排的反引号后面加上编程语言的名称，就可以实现代码高亮。

1
2


def greet(name):
 print(f"Hello, {name}!")

7. 分隔线 (Horizontal Rules)

要创建一条水平分隔线，请在单独一行上使用三个或多个星号 (***)、破折号 (---) 或下划线 (___)，并且不能包含其他内容。

1

---

8. 链接 (Links)

链接文本放在中括号内，链接地址放在后面的括号内。

语法： [超链接显示名](超链接地址 "可选的提示标题")
示例： 欢迎访问我的 GitHub

如果想直接显示网址并使其可点击，可以用尖括号将网址括起来：<https://example.com>。

示例： https://blog.september.win/

9. 图片 (Images)

插入图片的语法和链接非常相似，只是前面多了一个感叹号 (!)。

语法： ![图片替代文字](图片链接地址 "可选的图片标题")
示例：

1

![美丽的风景图](https://markdown.com.cn/assets/img/philly-magic-garden.9c0b4415.jpg "Magic Gardens")

10. 转义字符 (Escaping Characters)

如果你需要显示原本用于格式化 Markdown 文档的字符（比如你不希望 # 变成标题），可以在该字符前面添加反斜杠 (\) 来转义。

1

\* 这不是一个无序列表项，而是一个普通的星号。

掌握了以上基本语法，你就已经具备了使用 Markdown 撰写结构清晰、排版优雅的博客文章的能力。

Markdown 拓展语法指北

Mon, 06 Apr 2026 00:00:00 +0000

掌握了基本语法后，Markdown 的扩展语法将为你打开新世界的大门。Markdown 官方标准（Basic Syntax）仅包含基础元素，但在实际应用中，许多解析器（如 GitHub Flavored Markdown, Hugo 等）支持更强大的扩展语法。掌握这些进阶技能，能让你轻松处理表格、代码高亮和任务清单。

1. 表格 (Tables)

要在 Markdown 中创建表格，请使用管道符 | 分隔各列，并使用三个或多个连字符 --- 创建表头和内容的分隔线。

对齐方式

通过在分隔线行添加冒号 :，可以控制列的对齐方式：

:---：左对齐（默认）
---:：右对齐
:---:：居中对齐

1
2
3
4


| 语法 | 说明 | 示例 |
| :--- | :---: | ---: |
| 表格 | 居中 | $10 |
| 扩展 | 左对齐 | $20 |

2. 围栏代码块 (Fenced Code Blocks)

扩展语法允许你使用三个反引号（```）或三个波浪号（~~~）来包裹多行代码。最强大的功能是支持语法高亮，只需在开头反引号后指定语言名称（如 python, html, css 等）。

1
2
3
4


{
 "project": "September's Blog",
 "status": "Learning Markdown"
}

3. 脚注 (Footnotes)

脚注用于对正文中的内容添加补充说明，而不会打断读者的阅读流。

用法：在词汇后面使用 [^1]，然后在文档底部定义说明。
示例：这是一个使用了脚注的句子。¹

4. 标题 ID (Heading IDs)

部分解析器支持给标题指定唯一的 ID，方便在文章内部进行跳转（锚点链接）。

1

### 我的目标 {#goals}

5. 定义列表 (Definition Lists)

定义列表允许你列出术语及其对应的定义。

1
2
3
4
5
6


第一项
: 这是第一项的定义。

第二项
: 这是第二项的定义。
: 这是第二项的另一个定义。

6. 删除线 (Strikethrough)

在文字前后各添加两个波浪号 ~~ 来表示已被删除或错误的信息。

示例：~~这件衣服原价 99 元~~，现在只需 19 元。

7. 任务列表 (Task Lists)

任务列表非常适合管理待办事项或项目进度。使用带有空格或 x 的中括号 [ ]。

1
2
3


- [x] 完成基础语法学习
- [x] 掌握扩展语法
- [ ] 发布第一篇技术博客

8. 使用 Emoji 表情

在 Markdown 中添加表情有两种常见方式：

直接从表情库复制并粘贴 Emoji 符号（如 🚀）。
使用“短代码”（需解析器支持），例如输入 :smile: 会被渲染成 😄。

9. 自动网址链接 (Automatic URL Linking)

许多现代解析器会自动将纯文本形式的 URL（如 https://google.com）直接转换为可点击的超链接，而无需额外添加中括号。

通过灵活运用这些扩展语法，你的 Markdown 文档将不仅仅是文字，更是一个具备专业排版水准的数字化作品。

这些扩展语法能显著提升你博客内容的专业度和丰富度。建议在使用前，先确认你所使用的博客主题或编辑器是否已完整开启这些功能支持。

这是在文档末尾自动生成的补充说明。 ↩︎

在安卓手机上搭建个人博客的赛博折腾记录

Sun, 05 Apr 2026 00:00:00 +0000

把一台安卓手机变成全天候运行的服务器，这里记录一下整个博客的底层架构、一键启动脚本以及日常编辑的工作流，作为个人记录用 Desuwa。

1. 核心底层架构（搭建过程）

整个站点的运行不需要去购买云服务器，所有的计算和渲染都在手机里完成。

运行环境：安卓端安装 Termux，提供完整的 Linux 终端环境。
核心引擎：使用 Hugo 生成静态页面，并配置了功能齐全的 Stack 主题。
外网穿透：通过 Cloudflared 建立加密隧道。把本机的 8080 端口映射到公网域名，同时打通了 SSH 通道。
云端编辑器：在 Termux 内运行 code-server，提供网页版的 VS Code 界面。

2. 自动化启动方案

手机重启后，手动敲命令拉起服务效率太低。为了实现“一键复活”，配置了结合 tmux 的自动化脚本。

手机开机打开 Termux 后，直接执行以下代码：

1
2
3
4
5
6


termux-wake-lock
sshd
tmux new-session -d -s blog "cloudflared tunnel run"
tmux new-window -t blog:1 "code-server --auth none --bind-addr 127.0.0.1:8443"
tmux new-window -t blog:2 "cd ~/myblog && hugo server -D -p 8080"
tmux attach -t blog

这段脚本执行了以下操作：

获取唤醒锁，防止安卓杀后台。
启动 SSH 服务，允许电脑远程接入。
创建名为 blog 的虚拟窗口，在后台并行三个任务：内网穿透、VS Code 服务、Hugo 本地实时预览。
随时可以通过快捷键 Ctrl+B 配合数字键 0, 1, 2 切换查看不同服务的实时日志。

3. 跨端编辑流

服务端跑通后，日常编辑不需要在手机屏幕上操作。

在电脑端打开终端，执行端口转发：

1

ssh -L 8443:127.0.0.1:8443 phone

接着，在电脑浏览器里打开 http://localhost:8443/，即可接入完整的 VS Code 界面。工作流如下：

敲击 Ctrl + ~ 呼出终端，使用 hugo new post/文章名.md 创建新文章。
直接在网页编辑器里撰写 Markdown 内容。
按下 Ctrl + S 保存，Hugo 会在毫秒级完成重新编译。
刷新博客对应的公网页面，即可看到最新排版效果。