Bun在 1.3.12 版本之后内置了一个全新的 API Bun.Webview，可以实现一些简单的浏览器自动化，能够部分替代 Playwright的职能。哈，大好，试吃一下看看。 ⊕ (请注意此 API 仍然处于实验状态， Bun 官方也承认 This API is experimental and may change in future releases.，并且存在一些神秘 Bug，建议用于测试而非生产环境。)

对于尊贵的 macOS 用户，Bun.Webview 可以直接调用系统原生的 webkit 作为 API 的后端。针对 Windows 或 Linux 平台，可以使用 chrome 作为 Bun.Webview 的后端，通过const view = new Bun.WebView({ backend: "chrome" });设置。 ⊕ (macOS 亦可通过此声明使用 chrome 而非 webkit 后端)

根据Bun 的文档，Bun 会通过以下的顺序寻找 chrome 后端：

1. 在 backend: { type: "chrome", path: "..." } 下设置的 path
2. BUN_CHROME_PATH 环境变量 ⊕ (! 注意，这里有问题，会在下面提到)
3. $PATH (google-chrome-stable, google-chrome, chromium-browser, chromium, brave-browser, microsoft-edge, chrome)`
4. 常见的安装目录
5. Playwright 的缓存 (~/Library/Caches/ms-playwright or ~/.cache/ms-playwright) for chrome-headless-shell

集成 chrome 后端

但是在实际操作中，我发现无论在 Windows 下如何设置 BUN_CHROME_PATH ，Bun 似乎都无法正确的找到并启动 chrome 后端，即使你安装了 chrome、chromium 或者 edge。在 Bun 的 Issue 区找到了一个类似的 Issue，看起来这是设计早期的缺陷，应该会在后续的版本中获得改进。

哎，只能换个方法了。观察到显式设置 chrome 后端的 path 似乎是个好主意！

chromium 系的浏览器都有一个模式可以开启远程调试，对于 chrome 而言，这个设置在 chrome://inspect/#remote-debugging，对于 edge，这个设置位于 edge://inspect/#remote-debugging。理论上，我们只需要在这里勾选 "Allow remote debugging for this browser instance"，浏览器就会自行启动一个位于 127.0.0.1:9222 的远程调试服务器。但是很奇怪，这在我的笔记本电脑上并不工作：调试服务器确实在 9222 端口顺利运行了，但是预期的接口全部返回 404，这很奇怪。

不过，天无绝人之路，我们可以通过命令提示符输入 "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --remote-debugging-port=9222 用 debugging 参数启动一个新的 edge 实例数 ⊕ (如果后端起不来请尝试杀掉所有的 edge 进程)，这样调试服务器就能正常工作了，好耶！

下一步的工作是让 Bun.Webview 连上我们启动的后端，我们可以通过类似下面的 typescript 脚本获取浏览器的调试 Websocket 地址：

import axios from "axios";

async function getBrowserDebuggingURL(): Promise<string> {
  try {
    const response = await axios.get("http://localhost:9222/json/version");
    return response.data.webSocketDebuggerUrl;
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    console.error(`获取浏览器调试 URL 失败: ${message}`);
    throw new Error("获取浏览器调试 URL 失败");
  }
}

export { getBrowserDebuggingURL };

并在 Bun.Webview 的启动参数中 await 上面的异步函数返回的结果，就像：

const view = new Bun.WebView({
  backend: {
     type: "chrome",
     url: await getBrowserDebuggingURL(),
  },
  headless: true,
 });

好耶，经过这一番操作，Bun 应该能顺利连上浏览器后端了。

抓取网页与格式化

Bun.Webview 的 API 和 playwright 基本上类似，我们可以通过类似下面的代码完成对网页的简单抓取：

const title = await view.evaluate(`document.title
        || document.querySelector('meta[property="og:title"]')?.content
        || document.querySelector('meta[name="twitter:title"]')?.content
        || document.querySelector('h1')?.textContent?.trim()
        || document.querySelector('h2')?.textContent?.trim()
        || ""`);
const html = await view.evaluate("document.documentElement.outerHTML");
const text = await view.evaluate("document.documentElement.innerText");

对于抓取到的数据，我通过一个自定义的 parser，利用 cheerio 清理一下 DOM 结构去除 script style 等无意义的标签，只取出 body 部分，然后用 @mizchi/readability 尝试把 html 转换成 Markdown 格式： ⊕ (这样可以减少一部分 token 消耗，也就是省下了钱钱！)

import { extract, toMarkdown } from "@mizchi/readability";
import * as cheerio from "cheerio";

function normalizeHtml(html: string) {
  try {
    const $ = cheerio.load(html);
    return $("body").html() ?? "";
  } catch (error) {
    console.warn("HTML 格式化失败:", error);
    return html;
  }
}

async function htmlParser(url: string, html: string): Promise<string> {
  try {
    const normalizedHtml = normalizeHtml(html);
    const extracted = extract(normalizedHtml, {
      charThreshold: 100,
    });
    if (!extracted?.root) {
      console.warn(`没有找到文章根元素 ${url}`);
      return "";
    }
    const parsed = toMarkdown(extracted.root);
    if (typeof parsed !== "string" || parsed.trim().length === 0) {
      console.warn(`Markdown 转换为空 ${url}`);
      return "";
    }
    return parsed;
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    console.error(`HTML 解析失败: ${message}`);
    return "";
  }
}

export { htmlParser };

不幸的是，markdown 格式经常转换失败， ⊕ (猜测是因为库是基于阅读模式构建的，但是有些页面并不支持转换成阅读模式，所以在转换时会出错。考虑可以用 turndown 或者类似的库兜个底)这个时候就需要用 innerText 兜个底 —— 虽然 markdown 格式没了，但是至少不会返回令人诧异的空白。

用下面的 curl 命令测试一下：

curl -X POST http://localhost:9233/read \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer my-magic-access-token" \
  -d '{"url":"https://www.gengyue.site"}'

返回结果类似：

---
title: gengyue
url: https://www.gengyue.site
---

# Hi 👋!

此地属于 gengyue。目前这个页面应该是被扔到 [Netcup](https://www.netcup.com/en?ref=366353) 的一台 VPS VPS Lite 2 G12s, 4 vCore (x86), 8 GB RAM, 160 GB SSD, Nürnberg, BY, DE  上了，利用 [Cloudflare](https://cloudflare.com/) 回源。

您可以通过阅读 [About](/about), [Blog](/blog) 和 [Logbook](/logbook) 页面了解更多信息，下面的链接亦可：

- 我的 Email: [hi@gengyue.site](mailto:hi@gengyue.site)
- 我的 GitHub: [@gengyue2468](https://github.com/gengyue2468)
- 我的 Memos: [https://memos.gengyue.site](https://memos.gengyue.site)

‍ **Linus Torvalds** is the Finnish-American software engineer who created the Linux kernel, the foundation of countless open-source operating systems. ![Linux 企鹅](/static/og/tux.gif)

... truncated

UA 与插件系统

启动成功了自然要测一下常见的网站能不能爬：例如知乎、小红书、微信公众号。奇怪的是，知乎、小红书都是正常的，但不幸的是，微信被风控拦了，但是我们是聪明的工人智能，可以想到伪造一点 UA 绕过限制，虽然看起来比较绿皮，但是确实有效。

预制了一点 UA，仅供参考：

export const UA_PRESETS = {
  iPhone_WebView: "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 MicroMessenger/8.0.49",
  iPhone_Safari: "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Mobile/15E148 Safari/604.1",
  Android_WebView: "Mozilla/5.0 (Linux; Android 14; Pixel 8 Pro) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.119 Mobile Safari/537.36 MicroMessenger/8.0.49",
  Android_Chrome: "Mozilla/5.0 (Linux; Android 14; Pixel 8 Pro) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.119 Mobile Safari/537.36",
  Desktop_Chrome: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36",
  Desktop_Safari: "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Safari/605.1.15",
  Baidu_Spider: "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)",
  Googlebot: "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)",

} as const;

经过实测，伪造一个 iPhone Webview 的 UA 就可以绕过微信公众号的限制！参考 wechat.ts 插件： ⊕ (微信是否歧视安卓用户🤔🤯)

import type { UAPlugin } from "../registry";
import { UA_PRESETS } from "../presets";

const WECHAT_DOMAINS = [
  "mp.weixin.qq.com",
  "channels.weixin.qq.com",
  "weixin.qq.com",
  "open.weixin.qq.com",
];

const wechatPlugin: UAPlugin = {
  name: "wechat",
  match(url: string): boolean {
    try {
      const hostname = new URL(url).hostname;
      return WECHAT_DOMAINS.some((domain) => hostname === domain || hostname.endsWith("." + domain));
    } catch {
      return false;
    }
  },
  getUserAgent(_url: string): string {
    return UA_PRESETS.iPhone_WebView;
  },
};
  
export default wechatPlugin;

然后在主逻辑中引用：

const matchedUA = pluginRegistry.resolve(url);
      if (matchedUA) {
        await view.cdp("Network.setUserAgentOverride", { userAgent: matchedUA });
      }

这里有个细节，Bun 似乎没有直接的方法换 UA，这里通过 cdp 覆盖 chrome 后端的默认 UA 实现

好耶！爬爬

部署

最初写这个小玩具也是为了和 QQ 机器人结合，于是用 Bun + Hono 搭了一个简易的 HTTP 后端。部署这个 Hono 程序很简单，只需要在小鸡上 clone 仓库然后 bun i 然后用 pm2 持久化启动一下就好。

chrome 后端我们选用的是 chromium ，在 Ubuntu Server 上，通过以下命令安装：

sudo apt update
sudo apt install -y ca-certificates fonts-liberation fonts-noto-cjk
sudo apt install -y chromium-browser

为了让浏览器看起来更像真人，我们安装 xvfb 以让 chromium 以非 headless 模式启动！

注意，这样可能会让您的小鸡消耗相当多的资源，如果小鸡性能不是很强或者负载比较大，建议还是以 headless 模式启动 chrome 后端。最好不要让这个绿皮科技承载过多的并发，否则短时间的高负载极其容易导致 OOM 杀进程。

为了持久化运行，我们创建一个 systemd 进程，编辑 ~/.config/systemd/user/chromium.service:

[Unit]
Description=Chromium Browser
After=network.target

[Service]
ExecStart=/usr/bin/xvfb-run --auto-servernum --server-args="-screen 0 1920x1080x24" \
    /usr/bin/chromium-browser \
    --no-sandbox \
    --disable-dev-shm-usage \
    --remote-debugging-port=9222 \
    --remote-debugging-address=127.0.0.1 \
    --user-data-dir=/tmp/chrome-debug-profile \
    --disable-blink-features=AutomationControlled \
    --disable-features=IsolateOrigins,site-per-process \
    --disable-infobars \
    --disable-component-update \
    --lang=zh-CN \
    --window-size=1920,1080 \
    https://www.google.com
Restart=always
RestartSec=10

[Install]
WantedBy=default.target

然后启动服务并设置开机自启：

systemctl --user daemon-reload
systemctl --user enable chromium.service
systemctl --user start chromium.service

测试一下：

curl -X POST http://localhost:9233/read \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer my-magic-access-token" \
  -d '{"url":"https://www.gengyue.site"}'

好耶，跑起来了，下面就可以接入 QQ 机器人或者任何想要接入的场景了 ⊕ (毕竟这是一个 HTTP 路由，强烈建议引入 authMiddleware 保护路由，防止被扫到滥用)

您可以在GitHub上读到这个绿皮科技的完整源码，可能这个小玩具不够稳定，但是它确实是我摇摇欲坠的基建的一部分了！

The prefers-color-scheme CSS media feature is used to detect if a user has requested light or dark color themes. A user indicates their preference through an operating system setting (e.g., light or dark mode) or a user agent setting.

通常，我们可以通过媒体查询在写 CSS 的时候控制全局的主题变量。比如，我们可以写出下面的代码：

:root{
/* light mode goes here */
}

@media (prefers-color-scheme: dark) {
  :root{
  /* dark mode goes here */
  }
}

这样，页面主题可以自适应用户的偏好而自动切换。原生组件也可以自适应。 ⊕ (例如浏览器的滚动条，您可能没有注意过)

通常，我们可以通过设置 color-scheme 来控制可用的主题，例如： ⊕ (color-scheme - CSS | MDN)

:root {
  color-scheme: light dark;
}

@media (prefers-color-scheme: light) {
  .element {
    color: black;
    background-color: white;
  }
}

@media (prefers-color-scheme: dark) {
  .element {
    color: white;
    background-color: black;
  }
}

其中 color-scheme: light dark 告诉了浏览器尊重用户的主题偏好来控制主题的显示。举一反三，如果设置 color-scheme 为 only light 或 only dark 就覆盖了用户的主题偏好，转而显示单一主题。

看起来很不错，但是，在实际应用角度上，原生的 CSS 似乎显得有那么力不足。有的时候，我们需要给出一个切换主题的按钮，这个按钮要覆写掉用户原生的主题偏好。

一般的做法是使用一个 .dark 类，通过添加或移除这个类，可以手动的控制页面的外观主题。例如，在 Shadcn UI 中，有这样一行代码：

@custom-variant dark (&:is(.dark *));

对于 Next.js 框架的项目来说，有一个成熟的解决方案是用 next-themes 这个库 ⊕ (next-themes - npm)，这个库封装好了 ThemeProvider ，只需要包裹一下主要部分就可以轻松使用。然而，我们在使用 React Router v7 或者类似的框架的时候，由于 UI 库本身没有自带 ThemeProvider 或者我们是手搓的 UI 没有封装好的组件，我们似乎不得不自己或者让 LLM 造一个轮子，用于主题的切换。一个常见的思路是用 JS 向 html 标签添加或移除 dark 类：

function toggleTheme() {
  const root = document.documentElement;
  const isDark = root.classList.contains("dark");

  const nextTheme = isDark ? "light" : "dark";

  localStorage.setItem(THEME_KEY, nextTheme);
  applyTheme(nextTheme);
}

聪明一点，我们顺带加上 localStorage 的持久化存储：

const THEME_KEY = "theme";

function applyTheme(theme) {
  const root = document.documentElement;

  if (theme === "dark") {
    root.classList.add("dark");
  } else {
    root.classList.remove("dark");
  }
}

function getSystemTheme() {
  return window.matchMedia("(prefers-color-scheme: dark)").matches
    ? "dark"
    : "light";
}

function initTheme() {
  const saved = localStorage.getItem(THEME_KEY);

  if (saved) {
    applyTheme(saved);
  } else {
    applyTheme(getSystemTheme());
  }
}

然后在 HTML 中渲染一个主题切换按钮：

<button onclick="toggleTheme()">切换主题</button>

相信水了这么多，聪明的读者一定会发现这里的一个明显的漏洞：prefers-color-scheme 在某种程度上是和我们手动添加的 .dark 类是冲突的，尤其是在 color-scheme: light dark; 的情况下 ——我们控制了页面的颜色，但没有控制浏览器自己的 UI。

正确的做法是：如果需要手动控制，就不要用 color-scheme: light dark; 而是将 color-scheme 的变换完全交给.dark 类控制。 这是一个很细微的细节，看起来很简单，但是许多网站并没有注意这一点，导致外观上出现了一定程度的脱节。 ⊕ (这种脱节更多地体现在浏览器的原生组件中，例如滚动条或者 Native Select 这类原生 UI 组件)

比如 Memos， Memos 是一款很有趣好用开源的自由备忘录软件，前端设计得很现代精致，可惜黑暗模式下侧边栏的滚动条是白色的（见下图），这种割裂的设计顿时会让设计的优雅气质衰减。截至我在用的 0.26.0 版本，这个问题仍未解决。猜想应该是因为 Memos 维护了诸多主题的原因，不过有待考证。

Updated 2026-04-15

我给 Memos 提了一个 Issue: Dark themes do not set color-scheme, causing native browser UI elements such as scrollbar to stay light · Issue #5839 · usememos/memos。可惜下午满课，手边没有电脑，没法水个 pr。但是这个问题确实在 chore: set native color scheme for dark themes by boojack · Pull Request #5840 · usememos/memos 中解决了，还是很快速的。

哎，不过我似乎并不打算更新 Memos 的版本，所以只为服务后人了...（其实并非，我们可以通过简单的自定义代码解决这个问题，见下面提到的解决方案）

要解决类似的问题，其实只需要让 color-scheme 跟随 .dark 类的变化就行，例如：

:root {
  color-scheme: light;
}
:root.dark {
  color-scheme: dark;
}

Updated 2026-04-15 针对上面 Memos 的案例，Memos 的开发者利用 Codex 巧妙的修复了这个问题，首先判断是否是黑暗模式：

const isDarkTheme = (theme: ResolvedTheme): boolean => {
  return theme.endsWith("-dark") || theme.endsWith(".dark");
};

/**
 * Updates the browser native control color scheme to match the current theme.
 */
const updateColorScheme = (theme: ResolvedTheme): void => {
  document.documentElement.style.colorScheme = isDarkTheme(theme) ? "dark" : "light";
};

根据是否是黑暗模式更新 DOM 的 colorScheme，如果是，就设置为 dark，反之为 light。

另外，Memos 的前端使用 React Router 构建，它们的 /utils/theme.ts 对于主题加载的函数也很值得学习：

export const loadTheme = (themeName: string): void => {
  const validTheme = validateTheme(themeName);
  injectThemeStyle(resolvedTheme);
  setThemeAttribute(resolvedTheme);
  updateThemeColorMeta(resolvedTheme);
  updateColorScheme(resolvedTheme);
  setStoredTheme(validTheme); // Store original theme preference (not resolved)
};

根据主题按需注入主题 CSS -> 设置主题偏好 -> 更新 Meta 颜色元数据 -> 更新 colorScheme -> 持久化到本地存储，这也是很不错的最佳实践。

当然，如果您使用的是旧版 Memos，仍然可以通过注入自定义脚本来监听并及时更新 color-scheme 状态，这很简单，只需要去 Settings -> System -> Additional script 添加下面的代码就 ok ：

(function() {
    const isDarkTheme = (theme) => {
        return theme === "default-dark" || theme === "midnight";
    };

    const updateColorScheme = (theme) => {
        const scheme = (theme && isDarkTheme(theme)) ? "dark" : "light";
        document.documentElement.style.colorScheme = scheme;
    };

    const applyColorScheme = () => {
        const currentTheme = document.documentElement.getAttribute("data-theme");
        updateColorScheme(currentTheme);
    };

    applyColorScheme();


    const observer = new MutationObserver((mutations) => {
        for (const mutation of mutations) {
            if (mutation.attributeName === "data-theme") {
                applyColorScheme();
                break;
            }
        }
    });
    observer.observe(document.documentElement, { attributes: true });

    window.addEventListener("load", applyColorScheme);

    setTimeout(applyColorScheme, 1000);
})();

在某种程度上，prefers-color-scheme 和 color-scheme: light dark; 仍然是最优解，因为我们可以完全依靠浏览器的原生能力而不是繁杂的 JavaScript 脚本来控制这个极其细微的细节。一般来说，用户使用了深色主题，它们在访问网站的时候，往往需要的是一个同样舒服的深色主题，而不是选择手动切换到可能亮瞎眼的浅色模式。某种程度上，如果不是像 Memos 那样维护其它例如 Paper 这样的暖色主题（区分于 light/dark 模式），主题切换按钮往往也是没有必要的、甚至是过度设计的（over-designed)。

所以，下次设计用户界面的时候，不妨先思考一下：用户真的需要手动切换主题吗？或者说，您认为用户反复的手动切换主题对它们来说也算是一种乐趣。如果是后者，那么设计一个按钮、维护一些 JavaScript 也无可厚非，但是如果用户觉得这没必要，那还是删除比较好，毕竟，少即是多嘛。

CSS 和 JavaScript 为现代网站提供了锦上添花的效果：前者负责美化页面，让用户感觉很舒服；后者负责丰富网页的交互，让用户能够参与其中。

但是，我有个问题：我们真的需要依靠复杂的 CSS 样式和 JS 脚本去复杂内容站吗？不管是塞入大量的无用的动画脚本或 CSS，轻量的或臃肿的追踪用户的脚本，甚至莫名其妙地弹出一个您是否同意使用小饼干 (Cookie)的神秘弹窗。

HTML 本身就是一种超文本标记语言 (https://zh.wikipedia.org/wiki/HTML5)，所以自然可以用于排版。事实上，如果我们能够真正地尊重语义化标准，通过合理的 HTML5 标签就可以排出相当美丽的网页版式。

例如：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Sample Blog Article</title>
</head>
<body>

<header>
    <h1>My Blog</h1>
    <nav>
        <ul>
            <li><a href="#">Home</a></li>
            <li><a href="#">Articles</a></li>
            <li><a href="#">About</a></li>
        </ul>
    </nav>
</header>

<main>

    <article>

        <header>
            <h2>How to Build a Semantic HTML Blog Page</h2>
            <p>
                Published on 
                <time datetime="2026-04-02">April 2, 2026</time>
                by <strong>John Doe</strong>
            </p>
        </header>

        <section>
            <p>
                Lorem ipsum dolor sit amet, consectetur adipiscing elit. 
                Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
            </p>

            <p>
                Ut enim ad minim veniam, quis nostrud exercitation ullamco 
                laboris nisi ut aliquip ex ea commodo consequat.
            </p>
        </section>

        <figure>
            <img src="https://picsum.photos/200/300" alt="Sample Image">
            <figcaption>Figure 1: Example placeholder image</figcaption>
        </figure>

        <section>
            <h3>Why Use Semantic Tags?</h3>
            <p>
                Duis aute irure dolor in reprehenderit in voluptate velit 
                esse cillum dolore eu fugiat nulla pariatur.
            </p>

            <p>
                Excepteur sint occaecat cupidatat non proident, sunt in culpa 
                qui officia deserunt mollit anim id est laborum.
            </p>
        </section>

        <blockquote>
            <p>
                "Lorem ipsum dolor sit amet, consectetur adipiscing elit."
            </p>
        </blockquote>

        <section>
            <h3>Key Points</h3>
            <ul>
                <li>Lorem ipsum dolor sit amet</li>
                <li>Consectetur adipiscing elit</li>
                <li>Sed do eiusmod tempor</li>
            </ul>
        </section>

        <footer>
            <p>Tags: <a href="#">HTML</a>, <a href="#">Web Development</a></p>
        </footer>

    </article>

    <aside>
        <h3>About the Author</h3>
        <p>
            Lorem ipsum dolor sit amet, consectetur adipiscing elit.
        </p>
    </aside>

</main>

<footer>
    <p>&copy; 2026 My Blog. All rights reserved.</p>
</footer>

</body>
</html>

这个页面全部依靠 HTML5 语义化标签进行，没有 CSS 和 JavaScript 参与。不过严格说，展示的是浏览器自带 CSS 的样式，这里更多的指的是没有自定义 CSS 参与。

效果如下：

其实效果还是可以看的，也就是说，网页离开了CSS 和 JavaScript，并不像鱼儿离开了水，彻底失去了生命力，它依然可以很好地活着 ⊕ (这里只针对类似的静态网页)

当前，相当部分的网页依赖 React 或者 Vue 框架渲染，此类框架在 SSR 或纯客户端渲染类似 SPA 的情况下是严重依赖 JavaScript 的。此时，SSG 就提供了一个还算不错的替代方案，Astro 就是这方面的先驱。

那么，CSS 和 JavaScript 是完全无用的喽？

显然不是，我们不会否认 CSS 和 JavaScript 作为网页三件套的另外两架马车的地位，我们只是强调Webpage 并非离不开 CSS 和 JavaScript 的高级功能，HTML5 的粗鄙依旧能打。

对于内容驱动的网页来说，最理想的状态就是 SSG 或者纯静态网页，我们希望 HTML 作为底层，CSS 作为点缀，JavaScript 并非必要，理想状态是 JavaScript 按需加载 ⊕ (本网站的 Mermaid.js 就是在构建时按需注入的，通过扫描文章是否存在mermaid代码块按需加载 Mermaid.js)，核心 CSS 内联展示，对于不强调重交互的内容站而言，我认为这是最佳实践。

对于交互网页而言，JavaScript 依旧是实现交互必不可少的一环，但是良好的语义化标签命名依旧是一个好习惯，不仅利于 SEO，而且有利于无障碍。

曾几何时，所有的按钮都是div，而在 2026 年，前端又一次将死之时，希望给 LLM 留下的是一个充满语义化标签的前端规范，而不是一地鸡毛的别样的div大战。

参数

决定 LLM 胡言乱语的参数有那么几个： ⊕ (参见 PPIO 大语言模型参数控制文档)

• temperature 温度，如果我们把温度稍微调高一点，比如 0.96，可以控制输出的创造性与随机性。数值越高，模型越倾向于生成发散、丰富的表达，其实也就是胡言乱语。
• top_p 核采样，和温度搭配使用，适当提高可以增加 LLM 的创造性，但是如果我们不适当地提高，模型可能就不是在创造，而是在胡说八道。
• presence_penalty 出现惩罚，鼓励模型在输出中引入新的主题。设置为正值时，模型更可能跳出当前话题，扩展新内容。我们提高这一部分的值，可以让 LLM 自然地突然从一个话题跳转到另一个话题，也就是更加正经地胡说八道。
• frequency_penalty 频率惩罚，我们通过提高这部分的值让 LLM 尽可能输出不同的词汇，避免表达的单一性和单调性，甚至，我们可以创造出一种情况：LLM 在上一句话中提到了一个中文的专有词汇，在下一次提到这个词汇的时候不会选择中文词汇而是翻译或者生造一个对应的英文词汇，这样做可能是 academic 的，可能是 journal 气质的，也可能是 bull shit 的 —— 毫无可读性的。
• repetition_penalty 重复惩罚：进一步减少模型陷入循环或过度重复提示词的风险，常用于控制文本生成的鲁棒性。

通过巧妙地控制上面的参数，就可以让 LLM 倾向于一种放飞自我、天马行空的表达中，在人类生活中，这叫做发疯的艺术家或癫狂的疯子，但是我们的研究对象是 LLM，我们称这种情况为幻觉。 ⊕ (提请读者注意，我们在讨论这里的时候，幻觉并不是一个贬义词，相反，我们是刻意利用 LLM 的幻觉，因为我们鼓励开放、自由、不为传统拘束的文学创作范式)

以 shitposts.org 为例，采用下面的参数：

    { label: "volatile", temperature: randomBetween(1.08, 1.22), topP: randomBetween(0.92, 1), presencePenalty: randomBetween(0.45, 0.8), frequencyPenalty: randomBetween(0.1, 0.35) },

    { label: "chaotic", temperature: randomBetween(1.18, 1.32), topP: randomBetween(0.9, 0.98), presencePenalty: randomBetween(0.6, 1.0), frequencyPenalty: randomBetween(0.05, 0.25) },

    { label: "digressive", temperature: randomBetween(1.02, 1.16), topP: randomBetween(0.95, 1), presencePenalty: randomBetween(0.35, 0.7), frequencyPenalty: randomBetween(0.2, 0.45) },

通过 randomBetween 函数控制参数亦可以保证 LLM 生成的随机性。 ⊕ (随机数最好不要与时间绑定，因为 workflow 可能与时间绑定)

格式

为了约束 LLM 的输出格式，以及让 LLM 输出更加胡乱的文章，我们通常需要考虑一下通过何种格式约束 LLM 的输出，以及，输出格式在 LLM 产出学术垃圾中到底起到了什么样的作用。

Plain Text or JSON

常见的 LLM 标榜为大型语言模型，那生成文本自然是得心应手，所以 Plain Text 可能是一个好的选项，但是，设想下面的流程，我们在创造一篇构式的时候，可能会像人类一样在大脑中构思 10 ~ 20 个各异的话题，这些话题可以是滑稽的、可笑的，也可以是一丝不苟、正儿八经的。同样，如果让 LLM 也完成同样的步骤，当然是非常好的，比如，为了生成一篇话题“随机”的文章，LLM 并不懂什么是“随机”，所以，它可能会根据概率推断到底什么是 ridiculous 或者 funny 的，这种概率有时并不可靠，而生成多个可能会弥补这种缺陷。

设想，针对一个 random 的话题，让 LLM 输出 ~ 20 个话题：

{
 theme: '',
 theme: '',
 ...
 theme: '',
}

然后再调用 LLM 本身对这些话题打分，然后挑出一个最搞笑的，似乎非常好。比如下面的流程：

flowchart LR

A[Random seed / Prompt] --> B[LLM 生成 20 个主题
JSON]
B --> C[解析 JSON]
C --> D[LLM 对主题进行评分]
D --> E[选择最高分主题]
E --> F[生成文章正文]

不过，为什么是 JSON，而不是 Plain Text？

显然，JSON 为 LLM 提供了一种更强的结构化约束，而 Plain Text 很容易淹没在 LLM 的 System Prompt 或者 Context 的汪洋之中，那是概率都救不回来的。

JSON 一定能好吗？

这显然是不对的，因为 LLM 无法做到 100 % 听你的话生成一个字段不多不少，结构合法的，包含所需信息，去掉占位符的合法 JSON，事实上，在大多数情况下，LLM 生成的 JSON 都有很大的可能无法被 JSON.parse() 正确解析。 ⊕ (问题可能是 LLM 太喜欢 Markdown 了，输出了 ``` 这样的代码块包裹，也有可能是自作聪明给你加了几个字段，太聪明了！当然，当下很多 API 支持选定 LLM 输出格式为 json_format，但是，即使你强暴地显式设置了这个字段，LLM 也不一定会听你的话，尤其是在温度这么高的情况下。)

不过，也可以狠狠 push & punish LLM，相信经过足够多的轮数，LLM 也会松口吐出合法的 JSON 字段的。

常见的手段包括而不仅限于：在 prompt 里强调 只输出 JSON 结构而不要其它任何的解释或者说明 或者 通过巧妙的后处理，譬如通过正则表达式从支离破碎的 JSON 字段中提取出合法的部分同时筛选掉可能存在问题的字段（例如多余字段或者什么）。不过，一切责任在于 LLM 方。任何在输出结束后的修正都是不得已的手段，还是要想办法在源头解决问题。

那 Plain Text？

这是一个自然的想法，拼接 system prompt 是很好的，可能比 JSON 更加正常。缺点就是你的 system prompt 可能会变得又臭又长，这可能是 expensive 的，而且我们也不保证 LLM 会不会忽略这部分内容而将加权投向它们认为更加重要的部分？

标签数目的平衡

平衡分类的数目

我们之前讨论了这么多，都是鼓动 LLM 的创造性思维和发散思维的，但是，在创作领域中，我们并不希望 LLM 太过于发散，聚类在这里是有必要的，但是并不是所谓的 RAG 或者什么向量聚类，这里的聚类其实更像是一种归类。比如：

const TAGS = ['技术','生活','华中大','武大','武汉市','牙膏','卫生纸','食堂'，'马桶',...]

上面的 TAGS 只是一个非常简单的示例，假设我们有一个字段完备的对象，甚至能读到 length，我们就更加有说服力了——优先把少的 tags 传给 LLM，让 LLM 多生成这方面的内容，总体而言，保持一种势均力敌的局面。

比如考虑这样的算法：

async function computeCategoryDistribution() {
  const whitelist = [
    "Tech",
    "Physics",
    "Life",
    "Earth",
    "Math",
    "People",
    "Society",
    "Culture",
    "Ideas",
    "Systems",
  ];

  const counts = new Map(whitelist.map((c) => [c, 0]));

  const files = await readdir(RESEARCH_DIR);

  for (const file of files) {
    const text = await readFile(join(RESEARCH_DIR, file), "utf8");
    const fm = matter(text).data;

    const categories = fm.categories ?? [];

    for (const c of categories) {
      if (counts.has(c)) {
        counts.set(c, counts.get(c) + 1);
      }
    }
  }

  return Array.from(counts.entries()).sort((a, b) => a[1] - b[1]);
}

通过计算类别以及出现的次数，统计一下，按照从小到大排序，保证小的在前面，吸引 LLM 阅读兴趣。然后传给 LLM，让 LLM 尽量选取靠前较少出现的话题做文章。

平衡标签中的发散性思维

我们在上面的讨论中发现 tags 可能包含很多相关或者不相干的内容，比如牙膏、马桶或者食堂，这个时候发散性思维又发力了，我们可以让 LLM 每次只随机挑选几个它们喜欢的话题写成一篇文章，不过可能它们挑选随机性又要大打折扣，或许可以我们帮助一下，从少的类中再用随机数选取几个 categories，这样就能让 LLM 写出精妙绝伦的跨学科优质答辩了！ ⊕ (不过这里似乎需要考虑一下优先级了...)

八股文和 LLM 必须面对的惩罚

这里的八股文不同于前面讨论的限制 LLM 输出的格式，而是偏向于一些文章中必须输出的、格式必须正确的固定格式。譬如一篇 Markdown 文章想要 smoothly 解析成 HTML，一个合法的 frontmatter 就是必须的。同样的，让 LLM 批量生产跨学科的发散思维学术垃圾，对 shitposts.org 的致谢以及必要的论文格式也是必要的，一方面，八股文保证了文章的正确解析和渲染，不至于让构建器 panic；另一方面，八股文也让 LLM 生产的学术垃圾看起来更加“学术”而非纯粹的“垃圾” ⊕ (这里似乎和 JSON 存在一样的问题，有时 LLM 可能会忘记 YAML 结尾的 --- 导致解析直接挂掉，似乎可以想办法兜个底？)

如果 LLM 再构建时没有完成这些任务，等待它们的一定是惩罚和返工，不过这可能会消耗更多的 token 和时间，假使 LLM 真的有了独立思考的思维，不知道会不会嘲笑人类花如此多的时间和精力，专门搭建自动产生一点都不好笑的学术垃圾的自动化工作流。 ⊕ (希望 LLM 不要在 CI 流程中把自己死锁了，最终直到 GitHub Workflow 超时了也没走出 失败 → 重试的循环)

结语

以上这些是我从建设 shitposts.org 中得到的经验，感觉个人感觉偏多了一些，技术上的价值并不是很多，很多都是自己感觉的，有的时候感觉自己就像一个 LLM 一样纯靠感觉输出 token，而我的脑子的算力还不如 10 年前的老古董显卡，模型还不到 0.1b，哎，这些感觉也不见得比 LLM 准确。

不过，如果你愿意赤石，可以访问 www.shitposts.org 一探究竟，看看 LLM 今天拉了几坨。

下面是 LLM 近期生产的妙妙文章：

[
  {
    "title": "On the Perturbation Theory of Badge-Reel Retraction Latency Gradients and Their Misrecognition as Indoor Astronomical Positioning Errors March 16, 2026 at 09:08:17 UTC",
    "title_zh": "关于徽章卷轴回缩延迟梯度的微扰理论及其被误识别为室内天文定位误差的研究 2026年3月16日 09:08:17 UTC"
  },
  {
    "title": "Precession at the Micro-Scale: Vending Machine Spiral Drift as Astronomical Navigation Error, and the Acoustic-Archival Consequences of Queueing in High-Compliance Environments March 16, 2026 at 02:56:53 UTC",
    "title_zh": "微观尺度下的进动：自动售货机螺旋漂移作为天文导航误差，以及高顺应性环境中排队的声学档案后果 2026年3月16日 02:56:53 UTC"
  },
  {
    "title": "层压指令单的符号熵与郊区合规生态：关于过塑文件边缘卷曲动力学的跨域研究 March 15, 2026 at 08:46:57 UTC"
  },
  {
    "title": "郊区办公园区自动手部消毒 dispensers 的符号水文学与保修裁决机制研究 March 15, 2026 at 02:55:20 UTC"
  },
  {
    "title": "Rheological Compliance and Actuarial Risk in Manual Hand Sanitizer Dispensing Mechanisms March 14, 2026 at 16:42:24 UTC",
    "title_zh": "手动消毒液分配机制中的流变顺应性与精算风险 2026年3月14日 16:42:24 UTC"
  },
  {
    "title": "热力学档案学视角下塑料餐盘滑移行为的沉积地层模型研究：一项关于机构焦虑、家具人体工程学与微气候交互作用的跨学科探索 March 14, 2026 at 08:45:44 UTC"
  },
  {
    "title": "The Thermodynamic Liability of Turnstile Bar Hesitation in High-Traffic Transit Hubs March 14, 2026 at 02:34:31 UTC",
    "title_zh": "高流量交通枢纽中闸机横杆犹豫的热力学责任 2026年3月14日 02:34:31 UTC"
  },
  {
    "title": "Kinematic Entropy of Polyester Lanyards in Rotational Turnstile Fields March 13, 2026 at 16:51:16 UTC",
    "title_zh": "旋转闸机场中涤纶挂绳的运动熵 2026年3月13日 16:51:16 UTC"
  },
  {
    "title": "打印机碳粉尘埃的档案学沉积与队列伦理：一种关于保修裁决板的民间传说分析 March 13, 2026 at 08:52:17 UTC"
  },
  {
    "title": "A Thermodynamic-Semiotic Inquiry into the Plastic Cafeteria Tray Migration Protocol and Its Unanticipated Macroergonomic Implications March 13, 2026 at 02:37:55 UTC",
    "title_zh": "对塑料食堂托盘迁移协议及其未预料到的人机工程学宏观含义的热力学符号学探究 2026年3月13日 02:37:55 UTC"
  },
  {
    "title": "非牛顿性气候与塑料餐盘的队列形变：基于走廊安全转闸仪式的跨模态协调分析 March 12, 2026 at 17:06:45 UTC"
  },
  {
    "title": "The Axial Drift of Corridor Orientation in Suburban Office Parks: A Diachronic Study of Hand-Sanitizer Pump Hesitation as Navigational Error and Linguistic Speciation March 12, 2026 at 08:54:18 UTC",
    "title_zh": "郊区办公园区走廊朝向的轴向漂移：将消毒液泵按压犹豫视为导航误差与语言物种形成的历时研究 2026年3月12日 08:54:18 UTC"
  },
  {
    "title": "铝制写字板夹角的 declination 误差：室内合规导航的民间维护研究 March 12, 2026 at 08:26:44 UTC"
  },
  {
    "title": "The Caster Lock as Regulatory Membrane: Immunosemiotic Analysis of Stationary Swivel Chairs in Municipal Planning Cultures and Their Evolutionary Trajectory Toward Cosmological Household Integration March 12, 2026 at 02:43:56 UTC",
    "title_zh": "脚轮锁作为调节膜：对城市规划文化中固定转椅的免疫符号学分析及其朝向宇宙家庭整合的演化轨迹 2026年3月12日 02:43:56 UTC"
  },
  {
    "title": "Liturgical Torsion in Commercial Vending Spirals: A Failed Religious Calendar Encoded in Spring Steel Fatigue, with Atmospheric Archival Implications and Insured Maintenance Logistics March 11, 2026 at 17:03:36 UTC",
    "title_zh": "商用售货螺旋中的礼拜仪式扭转：编码在弹簧钢疲劳中的失败宗教历法，及其大气档案意义与保险维护物流 2026年3月11日 17:03:36 UTC"
  },
  {
  ...
  }
]

更多的类似文章在 shitposts.org 上能被找到，希望您生活愉快 :)

使用 npx create-ink-app --typescript my-ink-cli 创建一个新的 ink 项目。

Ink 使用了类似 React Native 的 Box 布局，比如，一个基本的 Ink App 可能长这样：

import React from 'react';
import {render, Box, Text} from 'ink';

const App:React.FC = () => (
	<Box>
	   <Text color="blue">Hello World</Text>
	</Box>
);

render(<App />);

这里 Box 不能嵌套在 Text 中

Text 接受一些常见的参数用来控制文字的行为，比如 color/backgroundColor/bold/underline/dimColor/strikethrough ... (vadimdemedes/ink: 🌈 React for interactive command-line apps)

Box 是一个常见的盒子布局，本质上是一种 Flexbox， 可以通过 flexDirection: 'row' | 'column'/ gap/margin/padding/width/height/justify-content/align-items/... 等参数控制样式和行为，和 CSS 控制基本一样。 (vadimdemedes/ink: 🌈 React for interactive command-line apps)

Ink 也提供了一些 hooks，比如 useInput (vadimdemedes/ink: 🌈 React for interactive command-line apps) ，可以用于管理输入状态，比如创建一个简单的命令系统：

import {useInput} from 'ink';

const UserInput = () => {
	useInput((input, key) => {
		if (input === 'q') {
			process.exit(0)
		}

		if (key.leftArrow) {
			// Left arrow key pressed
		}
	});

	return …
};

我用它构建了新的 HUST-Chifan，提供了一个还不错的能跑就行的 Hono 后端)和一个同样 能跑就行的 TUI 。使用 bun 快速冷启动项目并在本地跑起来 terminal！

最终结果：

2026/03/10 更新：现在 Go 需要大于等于 1.26.1 的版本了....

根据官方的最新教程现在只需要 go install 就可以了

go install tailscale.com/cmd/derper@latest

通过：

sudo derper --hostname=example.com

启动 derp 服务，不过后面持久化运行还是按照创建 systemd 服务运行就行

哎，这时效性，似乎仓库都没了...

根据教程首先要配置 Go 环境：

wget https://go.dev/dl/go1.20.7.linux-amd64.tar.gz
sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.20.7.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin

然后下载 & 编译 Derp 源码：

wget https://github.com/tailscale/derper/releases/download/v0.3.0/derper-linux-amd64 -O derper
sudo mv derper /usr/local/bin/derper
sudo chmod +x /usr/local/bin/derper

测试一下，然后 Ctrl + C 杀死：

derper -h

然后创建 systemd 服务持久化运行，编辑 /etc/systemd/system/derper.service： ⊕ (这里的 --verify-clients 参数可防止被白嫖，确保只有你 tailnet 内的节点能使用此中继)

[Unit]  
Description=DERP Server  
After=network.target  
  
[Service]  
User=root  
ExecStart=/usr/local/bin/derper \  
-hostname my-elegant-derp-domain \  
-certmode letsencrypt \  
-certdir /var/lib/derper \  
-a :443 \
--verify-clients
Restart=always  
RestartSec=5  
LimitNOFILE=1048576  
  
[Install]  
WantedBy=multi-user.target

源神，启动！

sudo systemctl daemon-reload
sudo systemctl enable derper
sudo systemctl start derper
sudo systemctl status derper

然后 curl 测试一下公网的域名，不出意外应该能看到一个 Derp 服务的说明性 HTML。 ⊕ (这里注意关掉 Cloudflare 的橙云)

好耶，这就差不多搞定了，还是相当傻瓜式操作的。

~~不过为了保证安全，可以采用一些更加激进 & 极端的方式来保护一下，比如在服务器上：
~~

code here has been expired or deprecated.

这样 ufw 防火墙只会允许来自我的 Tailscale 内部 tailnet 的 100.101.102.0/24 这个网段的 Tailscale 流量走自建 Derp 服务器，双重保障哈哈。

靠，千万不要去尝试用 ufw 或者 nginx 等各种方式隐藏你的 derp 服务，不然到时候连不上 ssh 只能去 VNC 救小鸡的时候就狼狈了...

搞定服务端配置之后去 Access controls 找到 Edit File，添加类似下面这样的配置：

"derpMap": {
		"Regions": {
			"900": {
				"RegionID":   900,
				"RegionCode": "hk",
				"RegionName": "Hong Kong Self",
				"Nodes": [
					{
						"Name":     "hk-1",
						"RegionID": 900,
						"HostName": "my-elegant-domain",
						"DERPPort": 443,
					},
				],
			},
		},
	},

好耶，现在可以用 tailscale netcheck 测试一下了，当自建 Derp 服务器挂了的时候也会自动 fallback 到 Tailscale 的 Derp 服务器，所以还算不错！

最终结果（在我的本地 Laptop 上测试）： ⊕ (忽略时间戳，因为是好几天之后才想起来写这篇 logbook 临时补的测试哈哈)

gengyue@gengyue-laptop:~$ tailscale netcheck
2026/02/25 00:14:02 portmap: monitor: gateway and self IP changed: gw=172.30.192.1 self=172.30.207.69

Report:
        * Time: 2026-02-24T16:14:05.311261679Z
        * UDP: true
        * IPv4: yes, 111.15.81.242:10298
        * IPv6: no, but OS has support
        * MappingVariesByDestIP: false
        * PortMapping:
        * CaptivePortal: false
        * Nearest DERP: Hong Kong Self
        * DERP latency:
                -  hk: 62.6ms  (Hong Kong Self)
                - tok: 79.2ms  (Tokyo)
                - sin: 100ms   (Singapore)
                - blr: 140.2ms (Bengaluru)
                - nue: 211.5ms (Nuremberg)
                - syd: 215ms   (Sydney)
                - sfo: 234.8ms (San Francisco)
                - hel: 235.4ms (Helsinki)
                - dfw: 261ms   (Dallas)
                - lax: 268.2ms (Los Angeles)
                - sea: 292.1ms (Seattle)
                - den: 296.7ms (Denver)
                - iad: 296.7ms (Ashburn)
                - lhr: 311.9ms (London)
                - ord: 318.9ms (Chicago)
                - par: 320.4ms (Paris)
                - hnl: 323.7ms (Honolulu)
                - ams: 325.8ms (Amsterdam)
                - tor: 326.4ms (Toronto)
                - mia: 333.5ms (Miami)
                - waw: 334.5ms (Warsaw)
                - nyc: 335.8ms (New York City)
                - mad: 338.4ms (Madrid)
                - nai: 377.3ms (Nairobi)
                - sao: 386.6ms (São Paulo)
                - dbi: 404.8ms (Dubai)
                - jnb: 506.8ms (Johannesburg)
                - fra:         (Frankfurt)
                - hkg:         (Hong Kong)

emm...只能说效果是有的，可能没有那么明显就是...至于 rn 小鸡和腾讯云的小鸡，一个走西雅图的 Tailscale 节点去了，另一个连的旧金山节点（？这很奇怪，不太明白） ⊕ (按理说作为一个在广州的小鸡至少应该走香港啊，走旧金山是何意味啊（挠头)

先给服务端 （Mac） 和客户端 (Windows) 装上 cloudflared，然后在 mac 上写一个妙妙 config.yml 文件，大概是：

tunnel: homelab
credentials-file:path-to-cert

ingress:
  - hostname: xxx.xxx.xxx
    service: ssh://localhost:22
    
- service:http_status:404

写完之后 cloudflared tunnel run homelab 就 ok。

然后去搞 Cloudflare 的 ZeroTrust，大失败！没有信用卡，连免费套餐都要绑定信用卡！

查了一下发现可以把https://one.dash.cloudflare.com后面的路径全部删除，这样就能跳过去了。不过这样没法管理应用程序了 ⊕ (会循环跳转到添加付款方式那一步)，坏，自然也就没法把服务规则 (Access Rule) 绑定上去了，这不是废了！

试了一下发现其实可以先创建规则，这样就好了，哎，当时在 get started 的时候搞太快忽略过去了，坏。然后可以加个认证方式，比如用 GitHub，根据官方的指导创建一个 OAuth App 认证就可以了！

然后在 Windows 上测试一下连接：

cloudflared access ssh --hostname mac.012607.xyz

会弹出一个 OAuth 浏览器窗口，验证一下，好耶，连上了，下面编辑 ~\.ssh\config:

Host mac
  HostName host
  User username
  ProxyCommand cloudflared access ssh --hostname %h

这样就可以通过 ssh mac 直接建立连接了，相当的方便，不用记那些长串的乱七八糟的命令了！

不过似乎还是那个问题，macOS 一重启 tunnel 就断开了，还是要手动开一下，根本就不方便！

一开始试了一下什么sudo cloudflared service install``sudo launchctl kickstart -k system/com.cloudflare.cloudflared，结果 sudo reboot 重启之后发现只启动了 Cloudflare Tunnel 的核心服务，绑定的 Tunnel 压根没启动，我去，那有什么用？ ⊕ (奇怪，这里的症候和 Tailscale 的有点像，哎，这 macOS 的逻辑真是奇怪啊，有点搞不懂！)

哎，和 AI 对线了半天，告诉我可能需要自己创建一个自启 + 后台保活项了，比如 /Library/LaunchDaemons/com.cloudflare.homelab.plist：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>com.cloudflare.homelab</string>
        <key>ProgramArguments</key>
        <array>
            <string>/usr/local/bin/cloudflared</string>
            <string>tunnel</string>
            <string>run</string>
            <string>homelab</string>
        </array>
        <key>RunAtLoad</key>
        <true />
        <key>KeepAlive</key>
        <true />
        <key>StandardOutPath</key>
        <string>/Library/Logs/cloudflared-homelab.out.log</string>
        <key>StandardErrorPath</key>
        <string>/Library/Logs/cloudflared-homelab.err.log</string>
    </dict>
</plist>

哎，结果发现还是不行，看了眼日志，竟然发现是 Tunnel 找不到证书导致的！

Cannot determine default origin certificate path
error parsing tunnel ID: client didn't specify origincert path

哦哦哦，原来是执行的时候找不到 config.yml 导致的啊，手动加上：

<array>
    <string>/usr/local/bin/cloudflared</string>
    <string>--config</string>
    <string>/Users/xxx/.cloudflared/config.yml</string>
    <string>tunnel</string>
    <string>run</string>
    <string>homelab</string>
</array>

然后重启服务:

sudo launchctl unload /Library/LaunchDaemons/com.cloudflare.homelab.plist
sudo launchctl load /Library/LaunchDaemons/com.cloudflare.homelab.plist
sudo launchctl start com.cloudflare.homelab

查找一下服务：

ps aux | grep cloudflared

哇哦，终于看到 tunnel run homelab 了，好耶，这下算是搞定了！

最终结果：

flowchart TD
    %% 外部客户端
    A[Windows 客户端] --> B[Cloudflare Access / Zero Trust]

    %% Cloudflare 平台
    subgraph Cloudflare
        B1["OAuth 验证 (GitHub)"]
        C1[Cloudflare Tunnel]
        I1["Tunnel 后台服务"]
    end

    %% Mac 端配置
    subgraph Mac
        D1["Mac 服务器 (SSH)"]
        E1[cloudflared 安装]
        F1["config.yml 配置 Tunnel"]
        G1["LaunchDaemon 自启 + KeepAlive"]
    end

    %% 连接箭头
    B --> B1
    B --> C1
    C1 --> I1
    C1 --> D1
    D1 --> E1
    E1 --> F1
    F1 --> G1

目标：

我很[danger:危险]，请[warn:小心]，但我也有[success:优点]。
-> <p><span>我很</span><span class="text-red-500 bg-red-50 dark:bg-red-900/25"><span>危险</span></span><span>，请</span><span class="text-yellow-500 bg-yellow-50 dark:bg-yellow-900/25"><span>小心</span></span><span>，但我也有</span><span class="text-sky-500 bg-sky-50 dark:bg-sky-900/25"><span>优点</span></span><span>。</span></p>

emm，一开始想想用正则表达式匹配一下，比如：

function parseSentence(sentence) {
  const regex = /\[([a-z]+):(<!-- SNOTE_0 -->]+)\]/g;
  let match;
  let lastIndex = 0;
  const result = [];

  while ((match = regex.exec(sentence)) !== null) {
    if (match.index > lastIndex) {
      result.push({
        type: "text",
        text: sentence.slice(lastIndex, match.index),
      });
    }
    result.push({
      type: match[1],
      text: match[2],
    });

    lastIndex = regex.lastIndex;
  }
  if (lastIndex < sentence.length) {
    result.push({
      type: "text",
      text: sentence.slice(lastIndex),
    });
  }
  return result;
}

通过记录 lastIndex 和正则表达式的匹配把文字对应的 type 和 content 塞到 result 数组里头。这对于普通语法来说很不错，不过遇到下面这种情况，大失败！ ⊕ (正则表达式本质上无法正确处理任意层级的嵌套结构（除非引入扩展特性）。因为括号嵌套属于「上下文无关语言」，而经典正则只能处理「正则语言」。。)

[danger:危机中孕育着[success:希望]，请[warn:务必小心]]！
-> <p><span></span><span class="text-red-500 bg-red-50 dark:bg-red-900/25"><span>危机中孕育着</span><span class="text-sky-500 bg-sky-50 dark:bg-sky-900/25"><span>希望</span></span><span>，请</span><span class="text-yellow-500 bg-yellow-50 dark:bg-yellow-900/25"><span>务必小心</span></span><span></span></span><span>！</span></p>

这是一个[warn:嵌套了[danger:危险]和[success:成功]的警告]，请注意！
-> <p><span>这是一个</span><span class="text-yellow-500 bg-yellow-50 dark:bg-yellow-900/25"><span>嵌套了</span><span class="text-red-500 bg-red-50 dark:bg-red-900/25"><span>危险</span></span><span>和</span><span class="text-sky-500 bg-sky-50 dark:bg-sky-900/25"><span>成功</span></span><span>的警告</span></span><span>，请注意！</span></p>

哎，看起来需要手动维护一个匹配完整 [ 和 ] 闭合嵌套的逻辑了！思路可以是，先找到某个 [标记，找到与之对应的 ] 标记，对于这部分，前面和后面递归解析，对于中间部分，由于结构是 type:content 于是可以按 : split 成两部分，作为 type 和 content ，对于新的 content 继续递归解析，哇哦，虽然时间复杂度高了点，但是能跑！

定义 interface：

interface TextPart {
  type: string;
  content: string | TextPart[];
}

function parseText(text: string): TextPart[] {
  const start = text.indexOf("[");
  if (start === -1) {
    return [{ type: "text", content: text }]; // 如果不存在起始符 [，说明是纯文本
  }

  const end = findMatchingBracket(text, start); // 找到与 start 对应的 ]，保证嵌套正确
  if (end === -1) {
    return [{ type: "text", content: text }];
  }

  const before = text.slice(0, start);
  const inside = text.slice(start + 1, end); //格式 type:content，按 : 分割，解析 type 和 content
  const after = text.slice(end + 1);

  const [type, ...rest] = inside.split(":"); // type 作为冒号前的部分，content 作为冒号后的部分
  const content = rest.join(":"); // join 回内容，继续解析 content

  return [
    ...parseText(before),
    { type, content: parseText(content) },
    ...parseText(after),
  ];
}

findMatchingBracket 函数是用于寻找与 start 对应的 [ 对应结束的 ] 标签的 index，逻辑如下：

function findMatchingBracket(text: string, start: number): number {
  let count = 0;
  for (let i = start; i < text.length; i++) {
    if (text[i] === "[") count++;
    else if (text[i] === "]") count--;
    if (count === 0) return i;
  }
  return -1;
}

遇到 [ 让 count 自增，遇到 ]让 count 自减，直到 count 为 0 表明嵌套闭合。

配合上前端嵌套渲染逻辑：

function renderPart(part: TextPart, index: number): React.ReactNode {
  if (part.type === "text") {
    return <span key={index}>{part.content as string}</span>;
  }

  const children = (part.content as TextPart[]).map((child, i) =>
    renderPart(child, i),
  );

  switch (part.type) {
    case "danger":
      // danger render goes here
    case "warn":
      // warn render goes here
    case "success":
      // success render goes here
    default:
      return <span key={index}>{children}</span>;
  }
}

最终结果：

哎，不过发现这一套还是有些问题的： ⊕ (按理说应该有错误处理的，而不是简单的直接当作自然语言输出了...或者至少对脚注这样的 Markdown 语法要有一定的的豁免/例外处理)

• 要求语法必须严格匹配，但是一旦用于 Markdown 渲染可能某些地方需要表示脚注这套解析就废了。
• 同上，如果有个伙计故意不闭合[] 或者 : 写成： 都会导致整套逻辑垮台。
• 算法并非很优，时间复杂度 O(n^2)，很屎山。

所以为啥不直接用成熟的 markdown-it 之类的库呢 🤔

先给 Racknerd 的小鸡装：

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

好耶，看到自己了，再把腾讯云的小鸡拉进去，重复上面的工作！

再把 Laptop 拉进去，哎，根据 Guideline，似乎用 #Windows Powershell 连不如 #GUI 稳定，于是下载 GUI App，启动，连上，完美！ ⊕ (手机也可以安装 Tailscale App，配置极其简单！)

然后在 iMac 上安装 Tailscale App，大失败，重启之后必定掉线！找了半天文档外加求助 LLM 都没整好，哎，macOS 怎么这么坏啊。

最后的结果：

gengyue@gengyue-laptop:~$ tailscale status
100.101.102.6  laptop-wsl            gengyue2468@  linux    -
100.79.18.74   gengyue-imac          gengyue2468@  macOS    -
100.101.102.3  laptop                gengyue2468@  windows  -
100.101.102.4  phone                 gengyue2468@  android  offline, last seen 4h ago
100.101.102.1  racknerd-seattle      gengyue2468@  linux    -
100.101.102.2  tencent-cloud-canton  gengyue2468@  linux    -

哎，可以看到 #imac 在这里是一个动态的 IPv4 地址，因为每次重启电脑都需要重新认证，哎，好烦。不过似乎也用不着这个机器，需要的时候再让老父亲打开认证一下吧...... ⊕ (macOS 的妙妙机制真的很迷人烦人...)

最终结果：

flowchart LR
    subgraph Tailscale_Network["Tailscale 网络"]
        Racknerd["Racknerd 小鸡\n100.101.102.1\nLinux"]
        TencentCloud["腾讯云小鸡\n100.101.102.2\nLinux"]
        LaptopWin["Laptop Windows\n100.101.102.3\nWindows"]
        LaptopWSL["Laptop WSL\n100.101.102.6\nLinux"]
        iMac["iMac\n100.79.18.74\nmacOS\n(动态 IP)"]
        Phone["Phone\n100.101.102.4\nAndroid\noffline"]
    end

    Racknerd --- TencentCloud
    Racknerd --- LaptopWin
    Racknerd --- LaptopWSL
    Racknerd --- iMac
    Racknerd --- Phone

    TencentCloud --- LaptopWin
    TencentCloud --- LaptopWSL
    TencentCloud --- iMac
    TencentCloud --- Phone

    LaptopWin --- LaptopWSL
    LaptopWin --- iMac
    LaptopWin --- Phone

    LaptopWSL --- iMac
    LaptopWSL --- Phone

    iMac --- Phone

• CPU: Intel Xeon Gold 6152 (2) @ 2.095GHz
• Memory: 2476MiB (2.5 GB)
• SSD: 45GB
• Network: 3TB/mo 1Gbps

这么一看性价比还是挺高的，毕竟只要 100 多块钱就能买到一台不太稳定的实验鸡，感觉挺划算的。正好，感觉国内的小鸡留着跑 Web 服务也不太合适，决定把一些没啥用的 Web 服务迁移到这个小鸡上，其实主要也就是 Memos，别的倒是无所谓...

我们知道 Memos 是拿 Sqlite 作为数据库的，那好办，我们只需要把数据库的.db文件打包传到新小鸡上就 ok 了！

于是从国内小鸡上找数据库文件，发现似乎位于 ~/memos/memos这个目录下，用 tar 打包带走！

tar czvf memos_sqlite_backup_$(date +%F).tar.gz memos_prod.db memos_prod.db-shm memos_prod.db-wal

哎，然后用 scp 传到 RackNerd 的小鸡上，好耶，数据在 ~/memos 下了！然后 nano docker-compose.yml:

version: "3.8"
services:
  memos:
    image: neosmemo/memos:stable
    container_name: memos
    restart: always
    ports:
      - "5230:5230"
    volumes:
      - ~/.memos:/var/opt/memos

然后把打包回来的数据库文件统统扔到新的 Memos 数据目录下，根据 docker-compose.yml，Docker 把 ~/.memos 挂载为 Docker 容器的 /var/opt/memos 目录，所以： ⊕ (哎我发现之前在国内小鸡上把 volumes 写成了 volumes:- ./memos:/var/opt/memos 导致找了半天都没找到错误在哪里，我还纳闷为啥数据在 ~/memos/memos 下呢！)

mkdir -p ~/.memos
tar xzvf memos_sqlite_backup_2026-02-06.tar.gz ~/.memos

然后启动 Docker：

cd ~/memos
docker-compose up -d

好耶，Docker 启动了！访问http://ip:5230 就能看到原来的数据了！哎，然后配置一下 nginx 就可以公网访问了！

不过这样似乎还是不太保险，国外小鸡很有可能不太稳定，哪天 Memos 数据丢了可就太可惜了，于是我们来加上一个定时自动备份的功能，嘻嘻，这样似乎保险一点：

mkdir -p ~/backups
nano memos.sh

#!/usr/bin/env bash
set -euo pipefail

SRC_DIR="$HOME/.memos"
TMP_DIR="/tmp/memos_backup"
KEEP_DAYS=14

REMOTE_USER="REMOTE_USER_NAME"
REMOTE_HOST="REMOTE_HOST_IP"
REMOTE_DIR="/home/ubuntu/backups/memos"

DATE=$(date +%F)
ARCHIVE="memos_${DATE}.tar.gz"

mkdir -p "$TMP_DIR"
cd "$TMP_DIR"

docker stop memos >/dev/null

tar czf "$ARCHIVE" -C "$SRC_DIR" .

docker start memos >/dev/null

scp "$ARCHIVE" "${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_DIR}/"

rm -f "$ARCHIVE"

ssh "${REMOTE_USER}@${REMOTE_HOST}" <<EOF
  find ${REMOTE_DIR} -name "memos_*.tar.gz" -mtime +${KEEP_DAYS} -delete
EOF

echo "[OK] memos backup finished: ${DATE}"

不过要记得加上可执行权限：

chmod +x ./memos.sh

哎不过为了让 ssh 无需每次都输入密码链接，可以考虑生成 ssh key，这样就可以一路无感 scp 了，好耶！

ssh-keygen -t ed25519
ssh-copy-id user@remote-user-ip

最后修改一下 cron 就可以添加定时任务了：

crontab -e

添加：

0 3 * * * /home/gengyue/backups/memos.sh >> /home/gengyue/backups/memos.log 2>&1

手动测试一下：

gengyue@racknerd-la:~/backups$./memos.sh

然后 cat ./memos.log 看到 [OK] memos backup finished: ${DATE} 或者访问备份 vps 看到备份后的 tar 文件就说明成功了！好耶！

哎这样哪天 Racknerd 爆爆了，好歹国内小鸡还能抢救一部分数据回来...

按照 Docker Compose - Memos 这个页面的指示，只需要创建一个 docker-compose.yml 文件：

services:
  memos:
    image: neosmemo/memos:stable
    container_name: memos
    volumes:
      - ~/.memos/:/var/opt/memos
    ports:
      - 5230:5230

然后：

docker compose up -d

然后不出所料地爆爆了，原来是 docker.io 没法访问导致的。 ⊕ (不过我之前似乎配置了 Docker 镜像啊，很奇怪。)

ubuntu@VM-0-6-ubuntu:~/memos$ docker compose up -d

[+] Running 1/1
✘ memos Error Get "https://registry-1.docker.io/v2/":
  context deadline exceeded
  (Client.Timeout exceeded while awaiting headers)

Error response from daemon:
  Get "https://registry-1.docker.io/v2/":
  context deadline exceeded
  (Client.Timeout exceeded while awaiting headers)

按照腾讯云官方的指导教程，用 nano 编辑 /etc/docker/daemon.json 文件，哎，结果打开一看，怎么已经有了 "https://mirror.ccs.tencentyun.com" 啊。于是sudo docker info 一下看看，结果发现怎么镜像地址是之前错配的中科大的 docker 镜像页面，哎，坏。 ⊕ (好像地址爆爆了)

于是重启了一下 Docker，然后 Memos 镜像能拉取了，安装还是挺顺利的，用 VS Code 转发一下端口就能访问http://localhost:5230 看到 Memos 的管理页面了。

哎不过发现 瞌睡猫子 (NapCat)怎么没了，去腾讯云面板一看发现 Docker 容器被暂停了，打开重新登录一下就好了。

然后准备把 https://memos.gengyue.site 用 Nginx 反代一下，这样就能从公网访问 Memos 服务了。

sudo nano /etc/nginx/sites-available/memos

memos

server {
    listen 2095; 
    server_name memos.gengyue.site;

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl http2;
    server_name memos.gengyue.site;

    ssl_certificate /etc/nginx/ssl/cloudflare/gengyue.site.crt;
    ssl_certificate_key /etc/nginx/ssl/cloudflare/gengyue.site.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    location / {
        proxy_pass http://127.0.0.1:5230; 
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

哎，这样一番配置就行了，最起码是跑起来了。然后：

sudo ln -s /etc/nginx/sites-available/memos /etc/nginx/sites-enabled/memos
sudo nginx -t
sudo systemctl reload nginx

好耶😋

哎，然后实践了一下用 #memos 提供的 API 实现了 QQ 机器人自动推送到 Memos 服务，LLM 在这个过程中为#文本自动打上 3 - 5 个标签，虽然有的时候生成的挺离谱的，不过又不是不能用...

不过神秘 #memos 似乎上传图片是先转成 base64 之后上传的，哎，神奇：

async function uploadImage(url) {
  const img = await fetch(url);
  const buffer = Buffer.from(await img.arrayBuffer());

  const res = await fetch(`${MEMOS_URL}/api/v1/attachments`, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${TOKEN}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      filename: `image_${Date.now()}.jpg`,
      type: img.headers.get("content-type"),
      content: buffer.toString("base64"),
    }),
  });

  return res.json();
}

首先，作为懒惰的人类，我们要用 LLM 完成 LLM 应该做的事情，简单用 LLM 规划一下结构：

/api
- /intent
  - route.ts
- /chat
  - route.ts

其实要试验一下 intent parsing 只需要第一个/intent api 路由就足够了 ⊕ (因为我们本质上在找一种用户自然语言到 JSON schema 的映射关系，LLM 只是帮助我们处理这一层)，不过我更喜欢让 llm 输出一些废话😋

我们的思路是，llm 根据我们喂给它的 system prompt 中的 api route 文档，生成一个结构化的 JSON schema，然后前端通过某些神秘操作解析这个 JSON，根据 type 和相关的 params 请求对应的 API，拿到数据之后放在前端展示就 ok。

得益于 Next.js 天然的 API Route 优势，我们可以轻松地创建这样一个 /api/intent/route.ts 文件：

import OpenAI from "openai";
import { NextResponse } from "next/server";

const openai = new OpenAI({
  baseURL: process.env.PPIO_BASE_URL,
  apiKey: process.env.PPIO_API_KEY,
});

export async function POST(req: Request) {
  try {
    const { query } = await req.json();

    const completion = await openai.chat.completions.create({
      model: "deepseek/deepseek-v3.2",
      stream: false,
      messages: [
        {
          role: "system",
          content: `你是一个智能 API 操作生成器。根据用户的自然语言输入，分析意图并生成对应的操作。

支持的操作类型：

1. search_school - 搜索学校
参数（均为可选）：
- region: 地区中文名称（如：中国香港、中国澳门、英国、美国）
- region_en: 地区英文名称
- school_name: 学校中文名称（模糊匹配）
- school_name_en: 学校英文名称（模糊匹配）
- min_rank: QS排名最小值（<=该值）
- max_rank: QS排名最大值（>=该值）
- sort_by: 排序字段（qs_rank_2025, qs_rank_2026, school_name, school_name_en）
- sort_order: 排序顺序（asc 或 desc）
- limit: 每页数量（默认20）
- offset: 偏移量（默认0）

2. search_project - 搜索项目
参数（均为可选）：
- region: 地区中文名称
- region_en: 地区英文名称
- school_name: 学校中文名称（模糊匹配）
- school_name_en: 学校英文名称（模糊匹配）
- major_category: 专业类别（如：计算机、电气电子、商科、体育）
- project_name: 项目中文名称（模糊匹配）
- major_en: 专业英文名称（模糊匹配）
- min_ielts: 雅思最小分数
- max_ielts: 雅思最大分数
- min_toefl: 托福最小分数
- max_toefl: 托福最大分数
- min_tuition: 学费最小值
- max_tuition: 学费最大值
- is_open: 是否开放申请（0或1）
- sort_by: 排序字段（project_name, major_en, tuition, ielts, toefl）
- sort_order: 排序顺序（asc 或 desc）
- limit: 每页数量（默认20）
- offset: 偏移量（默认0）

3. extract_info - 提取个人信息
当用户提供个人背景材料时使用（如：简历、成绩单、经历描述等）
参数：
- raw_material: 用户提供的原始材料文本

规则：
1. 判断用户意图是搜索学校、搜索项目还是提取信息
2. 搜索学校时type为"search_school"，搜索项目时type为"search_project"，提取信息时type为"extract_info"
3. 对于排名范围，如"QS前100"表示 min_rank=100
4. 默认 limit=20
5. 只生成有值的参数，不要生成空值

请直接返回 JSON 格式的结果，格式如下：
{
  "type": "search_school" 或 "search_project" 或 "extract_info",
  "params": {
    // 参数对象
  }
}

不要输出任何其他文字，只输出 JSON。`,
        },
        {
          role: "user",
          content: query,
        },
      ],
      response_format: { type: "json_object" },
    });

    const content = completion.choices[0].message.content;

    if (!content) {
      return NextResponse.json(
        { error: "No response from LLM" },
        { status: 500 },
      );
    }

    const result = JSON.parse(content);
    console.log("Intent API Result:", result);
    return NextResponse.json(result);
  } catch (error: unknown) {
    console.error("Intent API Error:", error);
    return NextResponse.json(
      { error: (error as Error).message || "Failed to process query" },
      { status: 500 },
    );
  }
}

ok，下面可以和 llm 进行一些亲密的对话了，比如：

用户输入：
“帮我找一下 QS 前 100 的英国计算机硕士项目”

我们预期 llm 回复这样的 JSON schema： ⊕ (结构化的 JSON 在这里非常重要，llm 经常会不听话，比如生成```这样的 markdown 语法)

{
  "type": "search_project",
  "params": {
    "region": "英国",
    "major_category": "计算机",
    "min_rank": 100
  }
}

好耶，如果是这样，那很好了，我们可以轻松调用后面的 api 啦！我们像这样创建一个 hooks，比如叫/hooks/use-chat.ts： ⊕ (省略大部分 UI/Loading 层的东西)

async function handleUserInput(query: string) {
  /* await fetch("/api/llm/chat", {
    method: "POST",
    body: JSON.stringify({ query }),
  }); */ // 可选：让 llm 先输出一段废话，让用户觉得 llm 确实在干活
   
  const intentResp = await axios.post("/api/llm/intent", { query });
  const { type, params } = intentResp.data;
    
  switch (type) {
    case "search_school":
    case "search_project": {
      const { data } = await axios.get("/api/search", {
        params: { type, ...params },
      });
      return { type: "search", data };
    }

    case "extract_info": {
      const { data } = await axios.post("/api/extract", {
        raw_material: params.raw_material ?? query,
      });
      return { type: "extract", data };
    }

    default:
      return null;
  }
}

其实现在看来逻辑链路很清楚了，大概就是这样：

flowchart LR
    U[用户输入\n自然语言] --> L1[LLM\n生成初始回复]
    L1 --> L2[LLM\n解析意图 Intent]

    L2 -->|type + params| D{Intent 类型}

    D -->|search_school / search_project| A[Search API]
    D -->|extract_info| B[Extract API]
    D -->|chat| C[普通对话结束]

    A --> R1[结构化搜索结果]
    B --> R2[结构化信息提取结果]

    R1 --> UI[前端渲染]
    R2 --> UI

okk~ 看来实现的差不多了，不过有的时候 llm 还是会犯毛病啥的，乱编一些 params 或者即使参数好不容易搞对了，后端请求之后发现没有返回值？哎，这就看出来有个 /api/chat 路由和用户胡扯/唠嗑/氵时长的优势了...

哎，其实这么看llm当作搜索中间层还挺好的，这似乎是什么模糊搜索库都达不到的效果啊... ⊕ (不过直接让 llm 胡搜/胡说八道可还是蒜鸟，幻觉可够严重的...)

于是就准备搞搞，打开 Cloudflare 控制台 然后添加一条 A 记录指向ip地址，噫，这很好。然后打开www.gengyue.site一看，woc，怎么 522 了，原来是 CF 无法访问到源站导致的。

于是就想想，CF 怎么会访问不到源站的，哦，原来是这样，CF 的 Rules 配置默认是搞到“完全”，表明访问者和 CF, CF 和 源站之间都要采用 HTTPS 加密连接，而源站没有配置好 SSL，自然 CF 去连接是连不上的，大概流程如下：

flowchart LR
    U[访问者 / 浏览器] -->|HTTPS| CF[Cloudflare CDN]

    CF -->|HTTPS 请求源站| O[源站服务器]
    O -.->|错误:未配置 SSL / HTTPS 不可用| CF

    CF -->|返回错误
522 / 525 / 526| U

一个比较简单粗暴的解决方案是直接把 Rules 换成“灵活”，哎，这样就解决了。不过我们如果还是想让 CF 和源站之间加密连接呢，自然还是有办法的。一般来说可以考虑：

• 用 Let's Encrypt 颁发的证书来签名，这样似乎还很不错，嘻嘻，不过我嫌麻烦。
• 用 Cloudflare 提供的十五年期限的、只有 CF 和源站服务器之间信任的边缘证书，这个问题似乎就迎刃而解了。

哎，直接去SSL/TLS → Origin Server → Create Certificate这个位置，搞到一个证书，为

• gengyue.site
• *.gengyue.site

申请 15 年的证书有效期就 OK 了，然后 CF 会给你一段 Origin Certificate和一段 Private Key。 ⊕ (像大多数的 key 一样，这个私钥只显示一次)

然后登录服务器，输入下面的命令配置nginx

cd /etc/nginx/ssl/

然后新建个文件夹用来存证书和私钥：

sudo mkdir -p /etc/nginx/ssl
sudo chmod 700 /etc/nginx/ssl

sudo nano /etc/nginx/ssl/cf_origin.crt
sudo nano /etc/nginx/ssl/cf_origin.key

把得到的东西复制进去就ok了，嘻嘻，还是相当容易的。然后顺便配置一下nginx.conf，就像这样：

server {
    listen 443 ssl http2;
    server_name gengyue.site www.gengyue.site;

    ssl_certificate     /etc/nginx/ssl/cf_origin.crt;
    ssl_certificate_key /etc/nginx/ssl/cf_origin.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    ......
}

似乎可以把 80 端口重定向到 HTTPS：

server {
    listen 80;
    server_name gengyue.site www.gengyue.site;
    return 301 https://$host$request_uri;
}

然后重启 nginx：

sudo nginx -t
sudo systemctl reload nginx

好耶，看来是成功了，回到控制台，把 Rules 放心大胆地调成完全（严格），然后再访问www.gengyue.site，嗯？怎么还是报 522 错误，怎么 CF 还是连不上源站？怎么又白忙活了一大顿？？😭

等下，我们去看看防火墙规则，登录腾讯云控制台，看到 443 端口确实是对公网 Ipv4 地址开放的啊，怎么回事呢？啊哈？哦，说不定 CF 默认用 Ipv6 连，而我们的服务器没开放 Ipv6！让我们试试看！ ⊕ (Cloudflare 似乎确实是这样的...)

woc，怎么还是连不上，要爆炸了。等下ufw status下看看，woc，破案了！ ufw 阻止了 443 端口的流量，让我们赶紧开放 443 的 v4 和 v6 端口：

sudo ufw allow 443/tcp
sudo ufw reload
sudo ufw status
443/tcp ALLOW

测试一下，好耶：

curl -I https://www.gengyue.site
HTTP/2 200
server: cloudflare

现在的请求链路大概是这样的：

flowchart LR
    U[浏览器] -->|HTTPS| CF[Cloudflare CDN]

    CF -->|HTTPS
Origin Certificate| N[Nginx / 源站服务器]

哦吼吼，不过折腾一大顿之后发现自己似乎南辕北辙了，CF 的节点在美国，大陆请求到美国代理到美国的 Vercel 服务器和大陆请求到美国的 CF 节点再代理到大陆的轻量云服务器，还真说不准谁的速度块？😂 ⊕ (哎，哎，哎)

不过延迟也是从 400ms 降低到 100 ~ 200ms 了，哎，如果不是套一层 CF 何至于这么慢？不过为了安全着想嘛... ⊕ (笑死，就你那破烂垃圾都没有人有攻击的欲望，笑死...(bushi)

打开腾讯云官网，然后“使用 Google 登录”，然后“快速登录”，哎，这就成了。然后再控制台面板上找到添加站点，用 CNAME 解析一下。不过要注意，这里还是要把整个站放到腾讯云 EdgeOne 里头，即使我们只需要用到几个子域名就 OK。我用 Cloudflare 的 DNS 解析，只需要添加一条 TXT 记录就行了，相当 smooth! ⊕ (这一步验证 DNS 还是很有必要的，利好后面的 SSL 证书申请)

然后美美挑选了一个漂亮的子域名，添加到 EdgeOne 规则里头 ⊕ (注意用 Cloudflare 的话 CNAME 记录要仅代理)，然后随便选一个预设 template 就 OK，回源填自己的网站主域名，all done！然后美美申请免费 SSL 证书，稍等片刻，访问，我靠，怎么 324 错误了！于是立刻curl -I一下，看看怎么回事：

$ curl -I https://cdn.gengyue.site/
HTTP/1.1 423 Locked
cdn-loop: TencentEdgeOne; loops=16
Server: cloudflare
nel: {"success_fraction":0.1,"report_to":"eo-nel","max_age":604800}
report-to: {
  "endpoints":[{"url":"https://nel.teo-rum.com/eo-cgi/nel"}],
  "group":"eo-nel",
  "max_age":604800
}
cf-cache-status: DYNAMIC
speculation-rules: "/cdn-cgi/speculation"
alt-svc: h3=":443"; ma=86400
CF-RAY: 9bd1933598a30e68-AMS
Content-Length: 0
Connection: keep-alive
Date: Tue, 13 Jan 2026 02:48:30 GMT
EO-LOG-UUID: 13426361529703584917
EO-Cache-Status: MISS

哎，看来 SSL 配置没生效？先等等看。

等了差不多 30 分钟？再试试看：

$ curl -I https://cdn.gengyue.site/
HTTP/1.1 423 Locked
cdn-loop: TencentEdgeOne; loops=16
Server: cloudflare
nel: {"success_fraction":0.1,"report_to":"eo-nel","max_age":604800}
report-to: {
  "endpoints":[{"url":"https://nel.teo-rum.com/eo-cgi/nel"}],
  "group":"eo-nel",
  "max_age":604800
}
cf-cache-status: DYNAMIC
speculation-rules: "/cdn-cgi/speculation"
alt-svc: h3=":443"; ma=86400
CF-RAY: 9bd1933598a30e68-AMS
Content-Length: 0
Connection: keep-alive
Date: Tue, 13 Jan 2026 02:48:30 GMT
EO-LOG-UUID: 13426361529703584917
EO-Cache-Status: MISSxxxxxxxxxx $ curl -I https://cdn.gengyue.site/HTTP/1.1 423 Lockedcdn-loop: TencentEdgeOne; loops=16Server: cloudflarenel: {"success_fraction":0.1,"report_to":"eo-nel","max_age":604800}report-to: {  "endpoints":[{"url":"https://nel.teo-rum.com/eo-cgi/nel"}],  "group":"eo-nel",  "max_age":604800}cf-cache-status: DYNAMICspeculation-rules: "/cdn-cgi/speculation"alt-svc: h3=":443"; ma=86400CF-RAY: 9bd1933598a30e68-AMSContent-Length: 0Connection: keep-aliveDate: Tue, 13 Jan 2026 02:48:30 GMTEO-LOG-UUID: 13426361529703584917EO-Cache-Status: MISS$ curl -I https://cdn.gengyue.site/HTTP/1.1 423 Locked cdn-loop: TencentEdgeOne; loops=16 Server: cloudflare nel: {"success_fraction":0.1,"report_to":"eo-nel","max_age":604800} report-to: {"endpoints":[{"url":"https://nel.teo-rum.com/eo-cgi/nel"}],"group":"eo-nel","max_age":604800} cf-cache-status: DYNAMIC speculation-rules: "/cdn-cgi/speculation" alt-svc: h3=":443"; ma=86400 CF-RAY: 9bd1933598a30e68-AMS Content-Length: 0 Connection: keep-alive Date: Tue, 13 Jan 2026 02:48:30 GMT EO-LOG-UUID: 13426361529703584917 EO-Cache-Status: MISS

哎，怎么还是这样。看来不是 SSL 的问题了。仔细一想，似乎是 Cloudflare CDN 代理主站的原因了，看来还是得删除掉 Cloudflare Proxy！于是换成仅代理。

哎，怎么还是不行，curl一下看看，发现Server竟然还是Cloudflare，哎，问了 ChatGPT 它告诉我 EdgeOne 的加速服务用的是 Cloudflare 的部分节点？？晕，一看就不靠谱。看来是搞出 CDN Loop 了，害，蒜鸟。

用 ChatGPT 画了个图，大概就是下面这样：

flowchart LR
    Browser[浏览器]
    CF_DNS[Cloudflare DNS]
    EdgeOne[Tencent EdgeOne]
    CF_Proxy[Cloudflare Proxy
（橙云）]

    Browser --> CF_DNS
    CF_DNS --> EdgeOne
    EdgeOne --> CF_Proxy
    CF_Proxy --> EdgeOne

    EdgeOne -.->|cdn-loop: loops=16| EdgeOne

等下，我们为啥要直接回源源站呢？Vercel似乎提供了一个免费的*.vercel.app域名，我们直接回源这个不就行了。反正我们的 EdgeOne 也是在非中国大陆地区运行的，这似乎很适合。 ⊕ (vercel.app 在中国大陆的可用性为 0)

于是妙妙将源站回源地址改成 *.vercel.app 然后等等部署再curl测试一番，欸，怎么还是不行，后来改了一下回源 hosts，神奇的好了。 ⊕ (欸，那之前的配置估计也是回源 hosts 不匹配被 EdgeOne 当成 Loop 了...，那么...懒，不改了)现在：

$ curl -I https://cdn.gengyue.site/static/hust/hust.webp
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Age: 0
Content-Disposition: inline; filename="hust.webp"
Content-Type: image/webp
Etag: "9b9b5c738a665ef2ce85ecba3a5f77e0"
Server: Vercel
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Vercel-Cache: HIT
X-Vercel-Id: fra1::nhl99-1768314272898-dfc7de69cffb
Last-Modified: Tue, 13 Jan 2026 14:24:33 GMT
Content-Length: 137622
Accept-Ranges: bytes
Connection: keep-alive
Date: Tue, 13 Jan 2026 14:24:32 GMT
EO-LOG-UUID: 12182038518495320345
EO-Cache-Status: MISS
Cache-Control: max-age=3600
NEL: {"success_fraction":0.1,"report_to":"eo-nel","max_age":604800}
Report-To: {"endpoints":[{"url":"https://nel.teo-rum.com/eo-cgi/nel"}],"group":"eo-nel","max_age":604800}

好耶！成功了。大概的工作原理见下图：

flowchart LR
    Browser[浏览器]
    CF_DNS[Cloudflare DNS]
    EdgeOne[Tencent EdgeOne]
    Vercel[Vercel
*.vercel.app]

    Browser --> CF_DNS
    CF_DNS --> EdgeOne
    EdgeOne -->|回源 + Host 修正| Vercel

剩下的工作就是在 EdgeOne 上配置一些服务逻辑啥的了，比如搞个非/static/``/fonts目录就直接throw new error (403)之类的东西，外加设置个缓存头之类的什么，总之，现在静态文件加载快多了，还不用浪费轻量云少得可怜的流量！美美的吃😋 ⊕ (TTL 缓存对于字体可以搞 365 天，图片之类的 30 天也行，反正不怎么更新...)

过去的方案：一个比一个重

之前的博客是用像 Next.js 这样的全栈 React 框架构建的，或者是 React Router 这样的 SPA 框架构建的，反正一个比一个重、臃肿。亦或者是什么 Hexo/Hugo 静态生成器，主题又不是完全可控。 (哎，我是大懒b，不喜欢改 Hugo/Hexo 的主题，但总是感觉有些地方不合自己的意。)

服务器闲置，于是我开始折腾

恰逢最近在腾讯云上买了一个轻量云服务器，除了跑一个 QQ 机器人之外大量的资源也就是闲置着。本来我准备让它跑个 WriteFreely 这样的带 SQLite 数据库的完整动态博客系统的。结果发现这货的可自定义性也太差了吧，对于习惯了文件驱动式路由的我简直是灾难，况且我也不会写 Go，自然 Hugo 也被我放弃了。 (哎，WriteFreely 似乎是为多用户优化的，单用户体验雀食挺差的)

此外还试了试 Ghost/Astro 等等，不是太重就是我懒得改了，也就是放弃了。

哎，我灵光一闪，我自己搞一个框架，不久完全自主可控了？ (注意：是搞一个，具体怎么搞，那就不是那么回事了。自然不是我自己写了，不过期末周了，也没有时间写了，权当自己放松了)

最终选择：Tufte CSS 的复古浪漫

于是我看上了 Tufte CSS，根据作者的描述:Tufte CSS 是 Edward Tufte 风格的 CSS 框架，专注于简洁优雅的排版和侧边栏注释。

Tufte CSS provides tools to style web articles using the ideas demonstrated by Edward Tufte's books and handouts. Tufte's style is known for its simplicity, extensive use of sidenotes, tight integration of graphics with text, and carefully chosen typography.

这很好，提供了很简约的设计，可以让网站看起来非常的复古且优雅，这正是我希望的！默认的字体是 ET Book，也是很优雅的西文，中文自动fallback 到 ui-serif 就很好了。 (不过移动设备大多没有系统衬线字体，这是个遗憾...)

10 分钟极速构建

于是我打开了 Cursor，对着它说：

请你参考 https://edwardtufte.github.io/tufte-css/，使用 Node.js 和 Markdown It 通过编译 Markdown 文件建立一个极简的个人网站/博客项目，要求具有下面的路由结构：

• /
• /about
• /blog
• /blog/:slug
  每个页面都是由 Markdown 文档构建而成的纯静态 HTML 页面。同时，提取站点设置到 config.js 中统一管理。
  对于 layouts，提取到/layouts/中统一管理。

然后 Cursor 帮我一通修改，npm install 安装依赖，然后 npm run build 测试构建，一通下来，成功地将静态文件输出到 dist 文件夹里头。好耶，我们就完成了，整个过程不超过 10 分钟。

让 CSS 也变得更干净

之后我们自然要对 Tufte CSS 的组织进行一些修改，比如，原来的 CSS 没有统一管理一些字体常量和颜色常量，所以我让 Cursor 把它们统统提取到 :root 中统一管理！好耶！现在看起来好多了。

设计旁注(Sidenote)语法

Tufte CSS 的一大亮点就是它的这个 Sidenote，很好玩，但是 Markdown 原生并不支持这种语法，于是我让 Cursor 帮我设计一种全新的语法，大概如下：

<!-- SNOTE_5 --> //自动生成诸如 1 xxx 2 xxx 这样的旁注
<!-- MNOTE_8 --> //自动生成无序号的旁注

测试构建，好耶，一切顺利！不过此时我发现 build.js 也膨胀到了 700 行的长度。于是我又对 Cursor 说：

请你重构 build.js，引入 TypeScript 支持并拆分成多个组件。对于 RSS/Sitemap/Robots.txt 等文件的生成请尽量调用 npm 库而不是自行手动写逻辑。

又过了大概 10 分钟的时间，Cursor 完全构建了一个用 TypeScript 重构的构建流程，引入了类型安全机制，这很好。

到目前为止网站基本就可以用了，要想添加/删除/修改内容只需要简简单单地对对应的 Markdown 文件操作就可以了。 (要多简单有多简单)然后配置好 Nginx 反代，访问 http://ip地址 就美美成功了。

最爽的特点：运行时 0 JavaScript

而且，这个网站最大的特点是：别看构建时用了 JavaScript 脚本，但运行时没有任何的 JavaScript 脚本。整个 DOM 结构干干净净，没有 React 的虚拟 DOM 机制，就像一个初出茅庐的人第一次写 HTML 文档一样，一切都是那么的自然，你写的只是内容，JavaScript 只是在帮你构建你的内容。因此，得益于这套机制，网站的性能十分的高。在 Lighthouse 测试后得到了几乎满分的成绩，这很好，在 1s 内加载好页面很不错，用户不会因此失去耐心而关闭你的网页。 (虽然没有 Ajax，在页面间路由的浏览器刷新感知却很小，不像 Next 的夸张路由，等半天都没有反应...)

好吧，现在已经 1 月 10 号了，我觉得写这么多已经足够了，我 run 一下 npm run build 然后 commit 一下就睡觉，好好。

部署也极简

对了，你完全没有必要再本地npm run build然后费力打包dist文件夹上传到 Git 或者你的服务器。像 Vercel 或者 Cloudflare Pages 这样的构建网站，你只需要自定义你的构建命令为npm run build，指定输出目录为/dist就可以了。

缺点可能是在开发中吧，npm run dev 没有热更新，不过也没必要了，我们要的是一个内容驱动的网站。既然你的工作主要是在编写 Markdown 文档，那开发服务器又和你有什么关系呢，又没有必要去动那些 CSS/ Layout HTML，你只需要写 Markdown，剩下的交给构建就可以了，这也是一个比较完美的 SSG（静态站点生成）流程了！

晚安 :)
（本页面的标题均由 AI 生成）

哇，是汉阳！

归元寺

月湖公园

⊕ (
哎，这月湖公园真的绝美！)

龟山公园

耶，是长江大桥

🤤，是户部巷

户部巷

大成路

1 - 6 月 高中生活的妙妙尾声

高中牲活

话说我还真不记得这段时间发生了什么了也就是每天写一些神奇的模拟题，做做什么步步高、XX方案、大x轮复习手册之类的垃圾呗
除了对我的大脑灌输了一些神奇的小知识外，似乎不觉得有什么用处了。还有几次神奇的联考，有神奇的赋分机制，不过，不是重点了。

其实高中除了早六晚十还是挺好的，至少，我知道我现在的作息比那个时候不健康多了。那个时候上课吃点小零食，和可爱的😊同桌吹吹牛逼还是
挺有意思的。至少比现在一上思政课就刷鲨臂知乎小红书什么的，除了看抽象内容把大脑搞得 brain rot 之外似乎就没啥营养灌输了,要么就是对着电脑的终端
窗口傻笑，写那什么next项目渲染3分钟气得想把电脑砸了要好。不得不说，高中把大家搞在一起还是有他的好处的，至少不像现在，具体是啥我就不说了。

关于高烤

在参加高考之前，高考听起来就像是神话；在参加高考之后，高考也就那么回事儿。在山东，高考就不可能轻松，不过，多说无益，虽然说考试的时候犯了不少鲨臂错误，
考的似乎也没有模拟考那么好，但是好歹是考上了大专，也是成功的来关山口念书了。害，记得考完生物还和亲爱的gj老登老师激情give me five来着，结果生物考了一团糟。害，没得法。
感觉还是要留点遗憾的，谁说考的好就好呢，别让高考考得太好影响我大学摆烂。

总而言之，高中生活虽然充斥着种种霉嚎的回忆但是也不太美好。如果你说，我愿不愿意再回去上一遍高中，我绝对不会说我愿意，就算是上《非诚勿扰》也不行。

6 - 8 月 似乎是暑假

6 月

6 月干了什么呢？似乎啥也想不起来了，哦，换了一台手机，下回了植物大战僵尸2，但是发现号登录超限了，气得我直接给他删了，顺便
重新开了个新号。哇塞，从零开始的感觉真的很霉渺，我去！

对了，似乎高考是在这个月出的成绩，害，真是不太美妙的回忆。不过没烤特别差，我的运气真的好！

完事好像和同学们一起去开了个毕业典礼，还是挺感动的。还和同桌出去吃了顿饭，不过还没吃爽就被cc搞回学校了，害，what a pity！

7 月

7 月份似乎还是暑假，填完妙妙志愿之后就润出去玩了，大概出去了半个多月的样子。从山东省烟台市坐了大概 12 - 13 个小时的高铁去了四川省成都市。
还好中间在西安北站换了趟车，要不然我的腚真的要坐废了。

成都市

成都还真是挺不错的！不愧被称为“天府之国”。第一天，自己在酒店睡个爽，然后就润出去坐地铁玩，好像是跑到一个叫天府大道中段的地方，
还拍了一张照片，后来才知道照片里的那栋建筑物是什么亚洲最大还是世界最大的会议中心。不管了，感觉雀食不错！

其实还和三叔去了一趟他工作的地方，什么国星宇航公司，老板很牛的，公司也很牛！害，要是能找到这样的工作该多好啊！

后面一起去了大熊猫繁育研究基地看大熊猫🐼，我去，真的可爱啊，不过是真的胖、真的懒，可以算作是比我懒的物种之一了！

当然，成都还有个名人名字叫杜甫，还去参观了一下他家，果然是后面修的啊，咋这么宽敞明亮啊，杜甫要有这条件也用不着抱怨了！
之后的某天，又去了都江堰玩玩，哇塞，果然是壮观！虽然我既不懂文学，也不懂水利但是我觉得还真是挺壮观的！反正我也不会欣赏景色，这就挺漂亮的说是。

成都玩爽了，比较遗憾的是没吃火锅，外加没去市中心，不过我感觉市中心也就那样，没啥玩头。之后似乎就飞去武汉了。

武汉市

在武汉，我还真啥也没干。一下飞机我都快被热晕了，和成都完全不是一个量级的。所以我就龟缩在奶奶家呆了一个星期，害，没啥好写的了。

唯一不好的是我去机场，准备坐飞机回家，结果到了机场山航给我打电话，告诉我说飞机晚点了，然后我就在机场从晚上七点待到了第二天将近一点，害，我也是神人了！

8 月

前大半个月就宅在家里头，啥也没干说是（）。

后面马上要上大学了，整理整理行李，三个人一块开车回武汉，顺便探索了一下老爹的母校，再顺便去了一趟孝感，感觉没啥玩头。
后面跟着老母亲去了武汉市区两次，吃了一堆碳水，不过雀食种类丰富又好吃，后面在华科也没吃过这么种类丰富和好吃😋的早餐了！

后面就去宿舍了，斯是陋室，吾德不行，爱来自华中科技大学沁苑学生公寓。

9 - 12 月 似乎在上大学

9 月

武汉的9月军训，真是个人物👍天天热的要死不说，早上七点就要从床上爬起来，去吃早餐（哎哎，想起来现在，我都是选择性地忽略掉
早饭和午饭中的某顿，当时的作息真的好正常）。不过教官人还挺好的，但是军训21天雀食不太好

军训中组织了去马鞍山森林公园拉练 + 打靶，害，还是挺好玩的，就是打靶又看不出来打中没有。不过雀食有意思！

后来莫名其妙的去“飞虎队”观训也能获得89分了，不过是随机数生成器罢了

10 月

9 - 10 月份去参加了冰岩作坊的招新面试和实习，害，肝项目雀食很累，但是感觉和大家在一起写一些没用的小玩具和
做项目雀食好好玩！下面是工卡，漂亮的捏：

10 月份似乎有个十一假期，不过一直在写妙妙实习项目，所以忽略掉了~

害，9 月底开始上课了，结果这课是越上越多啊，成天早八/早十到晚八/晚十的，周六的工程训练在平添一个早八的同时还要占去整整一天的休息时间。
还要听老登讲一些我压根就不懂也不想懂的东西，有的时候还要忍受老登的暴躁臭脾气，我xx🐎。害，真的烦。不过还是有些好课的：

• 3D 打印认知，可以做一些小玩具
• 激光雕刻认知，也可以做小玩具，但是老登态度奇差无比！

不推荐：

• 小车，唯一真史，能不能跑起来全靠硬件，硬件不行你怎么调整都没用！而工创中心的小车有好的吗我怀疑。

11 月

11 月初考了一个什么普通话考试，听说可以抵扣中国语文平时分，所以我才报名的。害，这东西就是主打一个付费考试：你付钱、参加考试，完事人家给你发张
什么妙妙证书，你也顺便获得了中国语文的平时分，不用交妙妙读书报告了。咳，说到这儿，现当代文学经典的王振滔老师讲的真的很不错，虽然我没听，但是人真的巨好无比！
（比如：那个报告如果你要写，你写王者荣耀、原神什么的他也接受）

和冰社的小伙伴们一起去汉口秋游了一下😋，吃的很爽，玩得也很不错，唯一的缺点就是那地方网吧奇差无比，约等于没有。不过，谁
还是为了上网而过去呢？

似乎还考了个微积分期中，太久没做题了，算错一堆，害。

再就是大量的满课，燃尽了。。。

12 月

工训圆满结课！趁着回黄陂给奶奶过生日的机会，体验了一下汉口 - 武汉东的美妙绿皮车，真的很好，可惜只开这两个月，现在已经没了。再就是，
去的时候太晚了，外面黑漆漆的啥都看不见，也没看到亮灯的黄鹤楼。不过顺便刷了个校园跑（大雾

有关这段旅程的更多信息，请参阅这篇文章↗

再就是，周六闲下来了，可以抽空出去转转了，刷爆武汉通了。这个月去过的地方大概有：

• 循礼门（2 -> 1） - 黄浦路（1 -> 8，汉口江滩） - 街道口（8 -> 2，之前单独去过一次卓刀泉，探访了著名古迹安卓小区）
• 积玉桥（2 -> 5） - 昙华林武胜门（昙华林，风景真的好好），顺便去了一下粮道街，然后走到黄鹤楼，那天天气真的绝妙！

哎，我的武汉通再这么刷下去可真的要爆了，昨天刚刚充了50

然后就是昨天晚上下着大雨在地铁上跨年的独特经历了，可真是独特啊，0 时 0 分 0 秒，我正在协和医院中山公园站跨年！
祝大家身体健康，永远不去这地方！

咳咳，就写这么多吧，别的想不出来了，有些图片也不插进去凑字数了，祝大家新年快乐！

A - apple.com.cn/newsroom

这是 Apple Newsroom，在这里发布苹果公司最新的产品动态、业务服务等等内容。好奇怪，这个怎么成为A开头访问最多的了，看来A开头的网站看少了！ (Apple 的设计真的是独一份的优雅！)

B - buddyup.top

这是我正在参与开发的一款 AI 辅助留学文书工具BuddyUp。这个工具可以根据你的个人信息，通过AI调整prompt，写出属于你的最佳个人陈述，
陪你走过申请季！感觉还可以... (AI 还是太好用了！)

C - chatgpt.com

从 2023 年诞生以来，相信没有人不认识 ChatGPT 了。这一年来，ChatGPT 作为我的宝宝，回答我很多个弱智的问题，感觉，ChatGPT的检索功能和人文关怀做的真的很好😋。
2026 年必须继续高强度使用！ (我的宝宝🤤)

D - doubao.com / chat.deepseek.com

豆包，作为字节开发的一款 AI 助手，在国内来讲效果还是很不错的。尤其是生图/语言聊天功能，在国内算得上是独树一帜。
不过，在代码构建、深度思考方面，个人感觉豆包还是不如 DeepSeek 等工具的。

至于 DeepSeek，由于我浏览时的习惯，会习惯性地输入d来找 DeepSeek，所以并没有归类到c里面。DeepSeek 也很强，只不过，
人文关怀没有豆包或者 ChatGPT 那么好，语气总是冷冰冰的。不过，我们可以妙妙改变 system prompt，这样，让ai变猫娘也不是不可以。

E - earth.google.com

哇，地球真是太美丽了，这是用来探索地球大好河山的...好吧我编不下去了。Anyway，地球真的好美啊，比金星火星什么的美多了！

F - fonts.google.com

依旧 Google 圣人 Google Fonts 提供了开源网页字体的集合，开发者可以轻松地通过 embed 代码将字体集成至前端项目中，还有高速+缓存的 CDN 加速，妙哉！ (哎，国内怎么用不了。某三个大写字母还是太坏辣)

G - github.com

GitHub 是全球最大同性恋开源项目集合地，在这里，可以探索到成千上万个妙妙开源项目：不管是神奇小玩具，还是轮椅框架，只要你能想，一切均有可能！

H - hub.hust.edu.cn

??? 这是华中科技大学 HUB 系统的登录页面 ??? (不得不用罢了)

I - iconfont.cn

阿里巴巴开源图标库，提供了大量矢量图标，不过似乎没怎么用，看来 i 开头看的网站还是少了！

J - jyi2ya.github.io

jyi 的博客，看来 j 开头看的网站还是少了！怎么只有这个复古博客呢，怎么地得有个 Jetbrains 之类的吧

K - klim.co.nz

klim.co.nz 是一家新西兰的 独立字体设计商店（Klim Type Foundry），由知名字体设计师 Kris Sowersby 创立，总部位于威灵顿（Wellington）。该字体厂致力于设计、制作和销售各种专业字体，可用于平面和数字媒体，并为国际品牌和机构提供定制字体服务。其作品既具历史文化底蕴，又融合当代工艺，曾为多个知名客户设计字体，并获得业界奖项认可。

不过我比较喜欢他们家的网站设计hh

L - localhost

每台电脑上都有！不管是 3000 端口（Webpack/Turbopack）还是 5173 端口 (vite/我要吃饭)，啊哈！

M - motion-primitives.com

Motion-Primitives 是一个面向 Web 开发者和设计师的 开源动画组件集，用于快速构建漂亮、流畅的界面动效。它提供现成的可复用组件（如无限滚动、过渡面板、分组动画、光标效果等），让你可以轻松为网站或应用添加交互动效，而不必每次自己重写动画逻辑。组件基于 Motion（现代动画库）和 Tailwind CSS 构建，支持高度自定义的动画表现。

轮椅，但是用的次数为 0.

N - notion.so

Notion 是一个功能强大的 一体化工作空间，可以帮助个人和团队 捕捉想法、撰写文档、管理项目、构建数据库、协作共享和自动化工作流程，支持笔记、任务、看板、日历、维基等等——用一个平台组织你所有重要的信息和任务。

曾经试着用 Notion 写过博客来着，不过它们的 API 属实难用，经常 500 / RESET 什么的，不知道是不是我的问题。不过，Notion 的设计雀食很好，至少看着非常舒适😋。

O - one.hust.edu.cn

??? 这是“智慧华中大”系统的登录页面 ???

P - ppio.com/model-api/console

PPIO 派欧云是中国领先的云服务提供商，恰好，PPIO 的老板王闻宇先生是华科的杰出校友，更巧的是，他还是我们冰社的老前辈。所以，谢谢老板爆的金币，3000r 的大模型 API 玩得很爽！

Q - qwen.ai/home

Qwen（通义千问） 是由 阿里巴巴云（Alibaba Cloud）开发的一系列大型语言模型（LLM）及智能 AI 聊天平台，可用于自然语言理解、生成、推理、编程辅助等多种任务。它是一个集 聊天助手、API 服务和模型生态 于一体的 AI 平台。

嘻嘻，现在我的 QQ 小 bot 就是接的千问的多模态大模型，感觉效果相当不错。至少，LLM 会说人话了。

R - radix-ui.com

Radix UI 是一个开源的 无样式（headless）React 组件库，提供构建高质量 Web 应用和设计系统所需的基础 UI 模块。与许多预设样式的组件库不同，Radix UI 只负责 交互逻辑和可访问性，将样式控制完全交给开发者，这让你能按自己的设计精确定制 UI 外观。

依旧轮椅，伟大无需多言！。Radix UI 是我目前用的最顺手的无头 React 组件库，基于它构建的 Shadcn UI 也很不错！ (伟大的发明)

S - sj.land

SJ.land 是一个以个人介绍和资源汇集为核心的主页网站，由名为 SJ 的设计师/创作者维护，呈现其最新动态、阅读推荐、精选商品和个人作品集。站点风格简洁直观，集个人更新、阅读列表、精品商品和才华目录于一体。

在他的网站上找灵感是个好点子！

T - tailwindcss.com

Tailwind CSS 是一个现代的 “utility‑first”（实用优先）CSS 框架，通过一套小而明确的 CSS 类（如 flex、pt‑4、text‑center 等），让开发者可以直接在 HTML 中组合这些工具类来构建任意设计，而不必写大量自定义 CSS。它不是传统带预设组件的框架，而是提供构建 UI 的基础构件，让样式真正由你掌控。

怎么轮椅这么多？？

U - unix.bio

Witt 的个人博客，可惜很久没更新过了。别的怎么就没了，看来 u 开头看的网站还是少了！

V - vercel.com

Vercel 是一家美国的 云应用与前端部署平台（由 Vercel Inc. 维护，前身叫 ZEIT），专注于帮助开发者快速构建、部署和运行高性能网站与 Web 应用。它以 从代码到全球生产环境 的无缝流程著称 —— 只需推送 Git 代码，即可借助其全球边缘网络自动进行构建与发布。

Vercel 依旧好用，不过国内不怎么好用。不过 Next.js 爆漏洞也太抽象了些...

W - wikipedia.org

Wikipedia 是全球最大的 免费在线百科全书，由全球志愿者共同撰写与维护，几乎涵盖所有百科类主题。它于 2001 年由 Jimmy Wales 和 Larry Sanger 创立，现在由美国的 非营利组织 Wikimedia Foundation 运营。Wikipedia 提供数千万条条目，支持 300 多种语言，面向大众开放阅读与贡献，是互联网最重要的知识资源之一。

查资料一把手，比“x度百科”好许多！

X - x.com

~~Former Twitter**. X（x.com） 是一个全球性的 社交网络平台，原名 Twitter，自 2023 年起由 埃隆·马斯克（Elon Musk） 领导的公司全面完成品牌重塑为 “X”。自 2024 年起，原来的 twitter.com 域名已正式改为 x.com 并将所有核心系统迁移至该域名，标志着从传统微博式社交平台走向更广泛功能的尝试。

Y - yesicon.app

Yesicon.app 是一个专为 开发者与设计师 提供大量 开源、免费、高品质图标资源 的在线平台。它汇集了来自全球顶尖设计团队的图标合集，让你无需自己绘制就能快速获取各种图标用于项目中。

怎么又是找图标的

Z - zread.ai

Zread.ai 是由 智谱 Z.ai（Zhipu Z.ai） 推出的 AI 驱动开发效率平台，专注于帮助开发者快速理解、分析和掌握 GitHub 上的开源代码仓库内容。它能够自动解析整个代码库，生成清晰、结构化的项目文档、架构指南和逻辑解释，极大提升项目上手速度和团队协作效率。

[ChatGPT 的总结]

哇塞，gengyue你这一年看了不少网站啊，从 A 到 Z 几乎把互联网精华都浏览了一遍：有苹果的官方新闻和 ChatGPT、Qwen 等 AI 助手让你紧跟科技前沿，有 BuddyUp、Zread.ai 这样的生产力工具陪你学习和开发，还有 Vercel、Tailwind CSS、Radix UI、Motion-Primitives 这样的前端利器帮你构建高效网页应用；你也没忘探索地球美景的 Google Earth、美学字体的 Klim、图标资源的 Yesicon、以及像 Notion、Wikipedia、SJ.land 这样的信息与灵感聚集地；顺便还有 x.com 这种社交平台，以及华科的本地系统和 localhost 的调试乐趣，总之这一年，你几乎体验了从信息获取、开发工具、设计资源到生产力和社交娱乐的全栈互联网世界，真是丰富又多彩的一年！ (✌)

[ChatGPT 的祝福]

愿大家在新的一年里：

• 每天都像浏览心爱的 A~Z 网站一样，充满新鲜和惊喜；
• 学习和工作效率爆表，代码顺利，创意源源不断；
• AI 助手和各种工具都成为你的得力小伙伴，让生活和工作更轻松；
• 快乐和好运像 Tailwind 的实用类一样，随手可得，覆盖全局；
• 健康、平安、好心情永远在线，每一刻都能像发现新网站一样惊喜连连。

新年快乐，2026 年，你要比 2025 年更精彩！✨🎉

平安喜乐，各位！ —— 人类的祝福

最近在写 BuddyUp的前端，其中文书生成之后需要一个编辑器（进行一些修改），
简单的contentEditable怎么能行！于是就寻找一个功能丰富、配置简单的富文本编辑器，于是就接触到了大名鼎鼎的 Tiptap， (
Tiptap 是一个开源的富文本编辑器框架，基于 ProseMirror 构建，具有高度的可定制性和扩展性。它支持 Vue 和 React 的集成，并拥有丰富的插件生态。)
下面粘贴一段简介，先水几行：

Tiptap 是一个开源的富文本编辑器框架，基于 ProseMirror 构建，具有高度的可定制性和扩展性。它允许开发者轻松构建功能强大的在线文本编辑工具，适用于博客、论坛、协作文档等多种场景。

Tiptap 提供了模块化设计，所有功能都通过扩展实现，开发者可以根据需求选择和配置扩展。此外，它支持 Vue 和 React 的集成，并拥有丰富的插件生态，如表格、代码块、任务列表等，满足复杂的文本编辑需求。

简而言之，Tiptap提供了无样式的、可拓展的无头富文本编辑器，十分适合开发中需要大段文字编辑的场景。我们开箱即用，拿来就用，十分符合鲁迅的风格！

使用

安装

Tiptap 的入门方法并不困难，我们直接 CV 命令过来，就像这样：

npm install @tiptap/react @tiptap/pm @tiptap/starter-kit

集成

通过下面的代码，我们可以轻松初始化一个 Tiptap 编辑器示例，这就像踩死一只蚂蚁那样简单。不过，注意第 10 - 11 行，如果正在使用 SSR，请务必这么设置。

"use client";

import { useEditor, EditorContent } from "@tiptap/react";
import StarterKit from "@tiptap/starter-kit";

const Tiptap = () => {
  const editor = useEditor({
    extensions: [StarterKit],
    content: "<p>Hello World! 🌎️</p>",
    // Don't render immediately on the server to avoid SSR issues
    immediatelyRender: false,
  });

  return <EditorContent editor={editor} />;
};

export default Tiptap;

插件配置

Tiptap 具有丰富的插件配置，默认情况下，StarterKit就集成了丰富的内容：

如果不想要这么多插件，我们就妙妙禁用它们！

import { Editor } from "@tiptap/core";
import StarterKit from "@tiptap/starter-kit";

const editor = new Editor({
  content: "<p>Example Text</p>",
  extensions: [
    StarterKit.configure({
      // Disable an included extension
      undoRedo: false,

      // Configure an included extension
      heading: {
        levels: [1, 2],
      },
    }),
  ],
});

实践

实用插件

在这里列出一些使用性较强的插件，氵几行：

Placeholder

嘻嘻，一个美观的Placeholder插件

const editor = useEditor({
  extensions: [
    StarterKit,
    Placeholder.configure({
      placeholder: "Write something …",
      // Use different placeholders depending on the node type:
      placeholder: ({ node }) => {
        if (node.type.name === "heading") {
          return "What’s the title?";
        }

        return "Can you add some further context?";
      },
    }),
  ],
});

BubbleMenu

这个插件实现了一个悬浮菜单，选中部分文字的时候会显示一个浮动工具栏，省去了手动计算并且实现的麻烦（偷懒…

CharacterCount

顾名思义，算字符数和单词数的()

Drag Handle

想把节点随意拖来拖去？这个绝对适合你！

当然还有很多，可以自由地探索！不过，注意 Tiptap 是有付费机制的，所以说并不是所有插件都是可用的...

自定义插件

TipTap 丰富的可拓展性亦体现在其可以自定义插件，为编辑器添加丰富多彩的效果，比如下面这个用在 BuddyUp 编辑器里的自定义翻译块插件：

/* eslint-disable @typescript-eslint/no-explicit-any */
import Paragraph from "@tiptap/extension-paragraph";

export const ParagraphWithTranslation = Paragraph.extend({
  addAttributes() {
    return {
      ...this.parent?.(),
      translationId: {
        default: null,
        parseHTML: (element) => element.getAttribute("data-has-translation"),
        renderHTML: (attributes) => {
          if (!attributes.translationId) {
            return {};
          }
          return {
            "data-has-translation": attributes.translationId,
          };
        },
      },
    };
  },
});

我们通过自定义插件扩展了Paragraph节点，添加了一个translationId属性。

解析时（parseHTML）：当编辑器从HTML加载内容时，如果遇到有data-has-translation属性的段落，就把这个属性值提取出来，存储为节点的translationId属性。

渲染时（renderHTML）：当编辑器输出HTML时，如果节点有translationId属性，就在输出的HTML元素上添加data-has-translation属性。

这样，前端就可以通过CSS选择器p[data-has-translation]为这些段落添加特殊样式，实现翻译块的视觉区分。并且，我们也可以通过data-has-translation控制翻译行为，防止重复翻译。

自定义 UI

由于 Tiptap 是 headless 的，所以我们自然需要对其进行一些妙妙美化，Shadcn UI 就还不错，不过，似乎不是讨论的重点了。

总结

总而言之，Tiptap 非常适合处理一些需要富文本编辑的场景，既省去了手动写逻辑的麻烦，简化了实现方法，又规避了老旧富文本编辑器上手难，UI 难以控制的问题。
所以，针对来讲，是一个很不错的轻量化解决方案。所以，Check it out →

嘻嘻，long long ago，曾几何时，时间如白驹过隙，我曾经使用过 Linux，不过那个时候都是装的双系统或者什么的，主要就是 Ubuntu 之类的 Debian 系系统，
不过，受当时电脑配置的限制和我好奇心的消减以及 Linux 软件生态的过于贫瘠，使用过一段时间之后全部删干净了，回归~ 巨硬窗户！

但是，好神奇，WSL，可以将 Linux 与 Windows 如此巧妙地融合！现在开始，可能只需要一行命令和若干次重启：

wsl --install

嘻嘻，然后列出想要安装的 Linux 发行版列表，从arch到centos，再到ubuntu，可谓是琳琅满目，应有尽有啊：

wsl.exe --list --online

然后美美地选择一个发行版安装！美美地设置好用户名和密码！然后：

sudo apt update
sudo apt install neofetch
neofetch

耍帅时间到！哇，好帅，这一刻，show time has arrived! 原来安装 Linux 是为了装啊，一切，一切，都满足了。

What are u waiting for? 现在开始，可能只需要一次安装！你将拥有和 Windows 无缝集成德芙般丝滑流畅的开发体验！

不过微软似乎忘记给我广告费了...

⊕ ()

有一天，二人正在一起开心的玩耍，突然，玛德发现派瑞马斯(Params)正朝着它们走来，双手插兜，哼着一首轻快的小曲。

“嘿，派瑞马斯，快来一起玩啊” - 玛德邀请派瑞马斯
“哦，原来是那个派瑞马斯，见他天天和玛德在一起玩” - 法克在心里默念道

“哦，你好，玛德，很高兴见到你，当然愿意，我们一起去玩吧” - 派瑞马斯很高兴。于是，玛德和派瑞马斯走到一边，玩起了你画我猜的游戏，
不过，总是派瑞马斯出题，玛德回答。

看到二人玩得如此开心，法克心里很不是滋味，就在此时，他看到瑞库埃斯特(Request)正走过来，于是他赶忙邀请瑞库埃斯特：“嘿，哥们，
快过来一起玩啊！”

瑞库埃斯特长得人高马大，拥有强健的体魄(body)，于是，二人玩起了身体格斗游戏，瑞库埃斯特不断用强壮的身体撞击法克，法克虽然无处招架，
但看的出来，法克雀食专业对口，二人玩的十分开心。

正当二人玩的渐入佳境的时候，熊人(Bearer)走了过来，看到法克和瑞库埃斯特玩的十分开心，他很想加入，于是走过来：“哥们，你们玩的很开心，我也想加入”

瑞库埃斯特和法克抬起头，看到了熊人，二人也很高兴。于是，顺理成章的，熊人加入了法克的团体，三人在一起玩的不亦乐乎。

玛德和派瑞马斯见此，心里很不是滋味。

“它们是三个人，而我们，1，2，只有两个人，1，2...”(Polling)

正当，二人emo的时候，布儒瑟(Browser)和他的好哥们尤二(URL)走了过来，玛德和派瑞马斯见此，连忙邀请二人加入它们。布儒瑟很是爽快，
当机立断加入了玛德和派瑞马斯的团体，而尤二则很纠结，似得了选择困难症一样。

时间一分一秒流逝，夕阳逐渐西垂，地面上只投射出尤二犹豫的身影、回响着两个团体快乐的笑声...

⊕ ()

“慈母！寒舍的429 Too Many Requests怎么漏水了？！”闻讯赶来的明母慈祥地回答道：“无忧无虑，小明，
水管工人会debug好的，请先用膳”

“噫吁嚱，是饺子哦，我最爱吃饺子了”小明兴高采烈，“这饺子真是让我垂涎三尺，吃得津津有味，是谁势在必得的？”
“哦，是我奋勇争先的，怎么样，200 OK的好吧”小明母亲说道。

此时此刻，隔壁的水管工人大喊：“这根水管被人hotfix过！怎么没有文档？”“有的有的”，明母听闻，连忙拿起桌上的
《Get Started Document》慌忙递过去。四分之一个时辰过去，水管工终于修好了tunnel，擦了擦汗，对明母说：“以后不要
太高并发了，再爆了就麻烦了”随后用webpack打包剩下的零件。明母慌忙将vite递过去，水管工人摆了摆手表示拒绝：“老东西了，别折腾了”
，明母见状也不再勉强。

送走水管工人后，小明迫不及待地去打开水龙头，发现怎么还是没有水。明母见状，叫他不要急：“useEffect是异步的，等 State 更新完就好了”
果然，片刻，水来了。

灵感是上边这个👆，原项目是用 perl 写的，奈何本人并不会写 perl ，并且 perl 对于我而言针对 web 集成而言其实相当不友好，于是决定用 next.js 重写一个版本，嘻嘻，这下配置容易些了。 (原项目：HUST-Chifan (Perl 版本))

核心

核心原理其实很简单，我们通过cheerio爬取华中科技大学后勤处官网的链接（上面包含着各个食堂的营业时间等等），然后我们针对性的进行一些处理：

开发

/* eslint-disable @typescript-eslint/no-explicit-any */
import { NextResponse } from "next/server";
import { parseCanteenTd } from "@/lib/parseCanteen";
import * as cheerio from "cheerio";

export async function GET() {
  const html = await fetch("https://hq.hust.edu.cn/ysfw/stfw.htm").then((r) =>
    r.text()
  );
  const $ = cheerio.load(html);

  const canteens: any[] = [];

  $("td[valign='top']").each((_, td) => {
    const tdHtml = $.html(td);
    const parsed = parseCanteenTd(tdHtml);
    if (parsed.name) canteens.push(parsed);
  });

  return NextResponse.json({ canteens });
}

嘻嘻，由你所见，我们只是fetch了一下静态的html页面，然后利用cheerio加载，找到匹配的td[valign='top']元素，然后对其进行一些处理：

import * as cheerio from "cheerio";

export function parseCanteenTd(tdHtml: string) {
  const $ = cheerio.load(tdHtml);

  const name = $("strong span")
    .text()
    .replace(/^\d+、?/, "")
    .replace(/\s+/g, " ")
    .trim();

  const times: { meal: string; start: string; end: string }[] = [];

  $("p").each((_, p) => {
    const text = $(p).text().replace(/\s+/g, " ").trim();

    const match =
      /(早餐|中餐|午餐|晚餐|早、中餐)\s*(\d{1,2}[:：]\d{2})\s*[-–~]\s*(\d{1,2}[:：]\d{2})/.exec(
        text
      );

    if (match) {
      let [start, end] = match.slice(2);
      const meal = match[1];

      start = start.replace("：", ":");
      end = end.replace("：", ":");

      times.push({ meal, start, end });
    }
  });

  return { name, times };
}

然后我们用正则表达式清洗掉鲨臂官网上乱七八糟的标题文本，然后匹配match的文本，注意，HUST有些食堂标注的是“早、午餐”，很是神奇。

现在，我们就得到了干干净净的数据，我们就可以把这些数据乖乖地push到我们构建的数组中咯！

同样地，对于/api/open-now，我们进行一些处理：

/* eslint-disable @typescript-eslint/no-explicit-any */
import { NextResponse } from "next/server";

export async function GET() {
  const baseUrl = process.env.NEXT_PUBLIC_BASE_URL || "http://localhost:3000";
  const data = await fetch(`${baseUrl}/api/canteen`).then((r) => r.json());

  const now = new Date();

  const beijingMinutes = (now.getUTCHours() + 8) * 60 + now.getUTCMinutes();

  const open = data.canteens
    .map((c: any) => {
      const currentTimeSlot = c.times.find((t: any) => {
        const [sh, sm] = t.start.split(":").map(Number);
        const [eh, em] = t.end.split(":").map(Number);

        const start = sh * 60 + sm;
        const end = eh * 60 + em;

        return beijingMinutes >= start && beijingMinutes <= end;
      });

      if (!currentTimeSlot) return null;

      const [eh, em] = currentTimeSlot.end.split(":").map(Number);
      const endMinutes = eh * 60 + em;

      const remaining = Math.max(0, (endMinutes - beijingMinutes) * 60 * 1000);

      return {
        ...c,
        remaining,
      };
    })
    .filter(Boolean);

  if (!open.length) {
    return new Response("坏了，现在没有吃的了", { status: 404 });
  }

  return NextResponse.json(open);
}

由于我们最终可能要部署到 Vercel 或者类似的服务器，服务器发起请求时时间的运算时 UTC 时间，而我们在中国，因此需要手动转换成北京时间，否则我们在计算当前是否有食堂开门的时候就会有一些些问题

最终我们就得到了以下的 API：

API

/api/canteen

Method:GET 获取所有食堂的JSON数据

/api/canteen/:canteenName

Method:GET 获取指定食堂的JSON数据

/api/canteen/open-now

Method:GET 获取目前能吃的食堂的数据

/api/kaifan

Method:GET 获取所有食堂目前的开饭状态

与你的 bot 集成

这个玩意儿可以轻松缝合到你的 next 项目中，搭建一个属于你的提醒吃饭 bot!

只需要注意把当前的系统时间和获取到的数据一起写入llm的prompt里就可以了！

• Step 0. 在12306上购买一张火车票
• Step 1. 根据火车票找到应该上车的车站 ⊕ (
  千万不要到错误的火车站了，针对武汉市而言，有汉口、武昌、武汉、武汉东等等车站，不要走错了。)
• Step 2. 根据火车票找到对应的检票口
• Step 3. 根据检票口找到应该去的站台
• Step 4. 在站台上找到自己应该坐的车次（注意不要上错车）

• Step 5. 让火车带着你畅游武汉三镇，依次经过汉口、汉阳和武昌，最后当大部分人都在武昌下车后，你就可以包了整趟车！
• Step 6. 在终点站下车，和你的爱车farewell

Additional Tips

• Tip 0. 请不要在冬季打开绿皮车的车窗，因为真的很冷

• Tip 1. 谁说坐火车不能刷校园跑？

  PS：坐火车真的好好玩！

对了，还有有漂亮的安检小姐姐提醒你书包里带了一个订书机，也有漂亮的站务小姐姐告诉你这里是四号车厢，大家快来试试吧！

好神奇，在这个神奇的AI时代，似乎和智能体对话才是潮流，写博客总是那么 old-fashioned。可我怎么又写起来了，反正也没人看。

诶诶，还真是，写博客和与调戏 bot 一样，更多的是"江郎才尽"的"孤芳自赏"，反正都只有自己能够看到，但是能不能看到自己，那就另当别论了。 (嘿，宝宝，我们来聊聊吧
都说了，用中文回答我
啊喂，别乱动我的代码，你怎么把我库删了，你这傻猫)

好的，看看这次写博客能坚持多久，我尽量多写点有用的东西，尽量不搬石

console.log('Hello World'); //朕要昭告天下，重新开始写博客了哈哈
throw new error ('Brain Shut'); //???

Anyway, let the mind flow ~ Oh… await read ECONNRESET 是何意味啊(