排查#

尝试了众多方法无果之后，我在想是不是waline server端的代码本身出了问题，于是就去翻看了一下他们官方的源代码，打开 packages/server/src/controller/user.js，定位到用户列表接口 getAction 里生成头像的这一行：

1
user.avatar ||= await think.service('avatar').stringify(user);

再看 avatar 服务内部的模板：

1
{%- elif qqMailExp.test(mail) -%}
2
  ...{{mail|replace('@qq.com', '')}}...
3
{%- else -%}
4
  https://seccdn.libravatar.org/avatar/{{mail | trim | lower | md5}}
5
{%- endif -%}

模板取的是 mail 字段，但 user 表里邮箱字段叫 email，不叫 mail。直接把 user 对象传进去，模板里 mail 是 undefined，执行 mail|replace(...) 时报错：

1
TypeError: Cannot read properties of undefined (reading 'replace')

跟控制台报错完全对上。跟数据库类型、部署平台没有任何关系。

定位根因#

全局搜了一下项目里所有调用 avatar 服务的地方，发现 token.js（登录）和 base.js（评论列表）在处理同一张 user 表时，都做了字段映射：

1
await think.service('avatar').stringify({
2
  mail: user.email,
3
  nick: user.display_name,
4
  link: user.url,
5
});

只有 user.js 这一处漏了映射，直接传了原始对象。是官方代码里孤立的一处遗漏。

修复#

把 user.js 改成和另外两处一致的写法：

1
user.avatar ||= await think.service('avatar').stringify({
2
  mail: user.email,
3
  nick: user.display_name,
4
  link: user.url,
5
});

重新部署waline服务，用户列表恢复正常。

小结#

最后改完之后也是把修复补丁重新pr回上游了。

开发历程#

然后我又看到了一个项目Open-AutoGLM,这个项目是在电脑上基于Python，通过有线或者无线ADB连接手机，然后让AI操作手机，是一个现成的操作控制系统，但是我要如何把这套系统移植到安卓手APP上来呢？

1
plugins {
2
    alias(libs.plugins.android.application)
3
    alias(libs.plugins.kotlin.compose)
4
    id("com.chaquo.python")
5
}

1
val py = Python.getInstance()
2
val module = py.getModule("main")
3

4
val result = module.callAttr(
5
    "main",
6
    "--adb-path", adbPath,
7
    "--base-url", baseUrl,
8
    "--model", model,
9
    "--apikey", apiKey,
10
    "--device-type", "adb",
11
    task
12
)

1
android {
2
    packaging {
3
        jniLibs {
4
            // 强制将 .so 文件提取到磁盘上，而不是留在 APK 中
5
            // 这样 context.applicationInfo.nativeLibraryDir 目录下才会有真实文件
6
            useLegacyPackaging = true
7
        }
8
    }
9
    ...
10
    defaultConfig {
11
        ndk {
12
            abiFilters += listOf("arm64-v8a")
13
        }
14
        ...
15
    }
16
}

1
class ADBConnection:
2
    def __init__(self, adb_path: str | None = None):
3
        self.adb_path = adb_path or os.getenv("PHONE_AGENT_ADB_PATH", "adb")
4

5
    def connect(self, address: str, timeout: int = 10) -> tuple[bool, str]:
6
        ...
7
        result = subprocess.run(
8
            [self.adb_path, "connect", address],
9
            capture_output=True,
10
            text=True,
11
            timeout=timeout,
12
        )

1
private fun runPython(
2
    context: Context,
3
    baseUrl: String,
4
    model: String,
5
    apiKey: String,
6
    task: String,
7
    onLog: (String) -> Unit,
8
    onFinish: () -> Unit
9
) {
10
    thread {
11
        val wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "Python:Run").apply { acquire(15*60*1000L) }
12
        try {
13
            val adbPath = File(context.applicationInfo.nativeLibraryDir, "libadb.so").absolutePath
14
            val py = Python.getInstance()
15
            val module = py.getModule("main")
16

17
            val result = module.callAttr(
18
                "main",
19
                "--adb-path", adbPath,
20
                ...
21
                task
22
            )
23
            onLog("任务结束：\n$result\n")
24
        } catch (e: Exception) {
25
            onLog("运行错误：\n${e.message}\n")
26
        } finally {
27
            if (wakeLock.isHeld) wakeLock.release()
28
            onFinish()
29
        }
30
    }
31
}

1
os.environ["PHONE_AGENT_ADB_PATH"] = args.adb_path or "adb"

1
object Adb {
2
    fun exec(
3
        ctx: Context,
4
        args: List<String>,
5
        input: String? = null,
6
        onLine: ((String) -> Unit)? = null
7
    ): String {
8
        val adbPath = File(ctx.applicationInfo.nativeLibraryDir, "libadb.so").absolutePath
9
        val process = ProcessBuilder(listOf(adbPath) + args)
10
            .redirectErrorStream(true)
11
            .start()
12
        ...
13
    }
14

15
    fun connect(ctx: Context, addr: String, onLine: ((String) -> Unit)? = null) =
16
        exec(ctx, listOf("connect", addr), onLine = onLine)
17

18
    fun pair(ctx: Context, addr: String, code: String, onLine: ((String) -> Unit)? = null) =
19
        exec(ctx, listOf("pair", addr), input = code, onLine = onLine)
20
}

后记#

这种项目本质上是把安卓系统上的操作截图让ai理解，然后返回相应的指令模拟人为的触屏操作，这种方法过于低效，而且容易让ai陷入死循环，无法执行正确的决策。不过最新的安卓应用开发标准，已经支持应用对外暴露函数接口和方法让ai智能体直接调用，不需要模拟人为的触屏。相信不久的将来马上会出现更为高效的Ai控制手机的方案。

项目地址#

https://github.com/iliaoke/AutoGlm/tree/main

代码#

先解析 URL 上的参数:code、state,还有可能出现的 error。这里有个容易漏掉的点——用户在授权页点”取消”的时候,GitHub 不会给 code,而是直接带 error=access_denied 跳回来,所以必须先判断 errorParam,不然后面拿着空 code 去请求 GitHub,只会得到一个莫名其妙的报错。

1
if (errorParam) {
2
  return redirectToApp(env, {
3
    error: errorParam,
4
    error_description: errorDescription || "",
5
    state: state || "",
6
  });
7
}

拿到正常的 code 之后,就是 POST 请求打到 https://github.com/login/oauth/access_token,body 里带上 client_id、client_secret、code、redirect_uri,这一步是服务端对服务端换 token,client_secret 只能放在这里,绝对不能出现在 App 里,不然反编译一下就全露了。这里踩了个小坑<请求头一定要加> Accept: application/json,不加的话 GitHub 默认返回的是 key=value&key2=value2 这种查询字符串格式,还得自己手动解析,挺麻烦的。

换完之后,不管是换 token 失败、GitHub 返回业务错误（比如 bad_verification_code，也就是 code 过期或者已经被用过了）、还是成功拿到了 access_token,最后都统一走 redirectToApp 这一个函数 302 回 App:

1
function redirectToApp(env, params) {
2
  const target = new URL(env.APP_SCHEME);
3
  for (const [k, v] of Object.entries(params)) {
4
    if (v !== undefined && v !== null && v !== "") {
5
      target.searchParams.set(k, v);
6
    }
7
  }
8
  return Response.redirect(target.toString(), 302);
9
}

这样设计的好处是,App 那边只需要检查跳转回来的 URL 上有没有 access_token,就能判断整个流程走没走通,完全不用关心中间到底是哪个环节出的问题。

后记#

弄完之后，才发现其实连服务器都不需要,浏览器是支持输入应用app scheme的,在浏览器通过这个跳转到应用内部，让应用接收code，然后在应用内部实现code转access token的过程。不过这样的话，就得把客户端id和客户端密钥写进应用内部，如果被人反编译出来，就会有密钥泄露的风险。而且如果是设计更复杂的应用，涉及到第三方账号的绑定，数据库的查询读写，这些操作都应该放到云端认证回调服务器上去执行，而不应该放在本地客户端里面。把认证回调服务器写成本地APP scheme这种方案只能临时用于没有服务器的情况，不能放在正式的生产环境。

index.js#

1
/**
2
 * GitHub OAuth 回调 Worker（简化版，仅用于拿到 access_token）
3
 *
4
 * 流程：
5
 * 1. App 用系统浏览器打开 GitHub 授权页
6
 *    https://github.com/login/oauth/authorize?client_id=...&redirect_uri=<本Worker的/callback地址>&scope=repo&state=xxx
7
 * 2. 用户同意后，GitHub 302 重定向到本 Worker 的 /callback，带上 code、state
8
 * 3. 本 Worker 用 code 向 GitHub 换取 access_token（服务端对服务端，带 client_secret）
9
 * 4. 本 Worker 302 重定向到 App 的自定义 scheme，把 access_token 直接带回去
10
 *    myapp://oauth/callback?access_token=xxx&state=xxx
11
 * 5. App 拦截该 scheme，取出 access_token，存到本地安全存储，之后用它直接调 GitHub API
12
 *
13
 * 需要在 wrangler 中配置以下变量：
14
 * - GITHUB_CLIENT_ID      GitHub OAuth App 的 Client ID
15
 * - GITHUB_CLIENT_SECRET  GitHub OAuth App 的 Client Secret（用 secret 存储）
16
 * - APP_SCHEME            App 自定义 scheme，例如 "myapp://oauth/callback"
17
 */
18

19
export default {
20
  async fetch(request, env) {
21
    const url = new URL(request.url);
22

23
    console.log(`[REQUEST] ${request.method} ${url.pathname}${url.search}`);
24

25
    if (url.pathname === "/callback" && request.method === "GET") {
26
      return handleCallback(request, env);
27
    }
28

29
    console.log(`[REQUEST] 未匹配任何路由，返回默认响应`);
30
    return new Response("GitHub OAuth callback worker is running.", {
31
      status: 200,
32
    });
33
  },
34
};
35

36
async function handleCallback(request, env) {
37
  const url = new URL(request.url);
38
  const code = url.searchParams.get("code");
39
  const state = url.searchParams.get("state");
40
  const errorParam = url.searchParams.get("error");
41
  const errorDescription = url.searchParams.get("error_description");
42

43
  console.log(
44
    `[CALLBACK] 收到回调参数: code=${code ? code.slice(0, 8) + "..." : "null"}, ` +
45
      `state=${state || "null"}, error=${errorParam || "null"}, ` +
46
      `error_description=${errorDescription || "null"}`
47
  );
48

49
  // 用户在 GitHub 授权页点击了"取消"
50
  if (errorParam) {
51
    console.log(`[CALLBACK] 用户拒绝授权或GitHub返回错误: ${errorParam} - ${errorDescription}`);
52
    return redirectToApp(env, {
53
      error: errorParam,
54
      error_description: errorDescription || "",
55
      state: state || "",
56
    });
57
  }
58

59
  if (!code) {
60
    console.log(`[CALLBACK] 缺少code参数，终止处理`);
61
    return new Response("缺少 code 参数", { status: 400 });
62
  }
63

64
  try {
65
    console.log(
66
      `[TOKEN] 开始向GitHub换取access_token, client_id=${env.GITHUB_CLIENT_ID}, ` +
67
        `redirect_uri=${url.origin}/callback`
68
    );
69

70
    const tokenRes = await fetch("https://github.com/login/oauth/access_token", {
71
      method: "POST",
72
      headers: {
73
        "Content-Type": "application/json",
74
        Accept: "application/json",
75
        "User-Agent": "cloudflare-worker-github-oauth",
76
      },
77
      body: JSON.stringify({
78
        client_id: env.GITHUB_CLIENT_ID,
79
        client_secret: env.GITHUB_CLIENT_SECRET,
80
        code,
81
        redirect_uri: `${url.origin}/callback`,
82
      }),
83
    });
84

85
    console.log(`[TOKEN] GitHub token接口HTTP状态码: ${tokenRes.status}`);
86

87
    if (!tokenRes.ok) {
88
      const bodyText = await tokenRes.text();
89
      console.log(`[TOKEN] 请求失败，响应体: ${bodyText}`);
90
      return redirectToApp(env, {
91
        error: "token_exchange_failed",
92
        error_description: `GitHub token endpoint returned ${tokenRes.status}`,
93
        state: state || "",
94
      });
95
    }
96

97
    const tokenData = await tokenRes.json();
98

99
    // 注意：access_token 只打印前几位，避免完整token出现在日志里
100
    console.log(
101
      `[TOKEN] GitHub返回内容: ` +
102
        `access_token=${tokenData.access_token ? tokenData.access_token.slice(0, 8) + "..." : "null"}, ` +
103
        `scope=${tokenData.scope || "null"}, ` +
104
        `token_type=${tokenData.token_type || "null"}, ` +
105
        `error=${tokenData.error || "null"}, ` +
106
        `error_description=${tokenData.error_description || "null"}`
107
    );
108

109
    if (tokenData.error) {
110
      // 常见：bad_verification_code（code过期/已用过）、incorrect_client_credentials（client_id或secret错）
111
      console.log(`[TOKEN] GitHub返回业务错误: ${tokenData.error}`);
112
      return redirectToApp(env, {
113
        error: tokenData.error,
114
        error_description: tokenData.error_description || "",
115
        state: state || "",
116
      });
117
    }
118

119
    if (!tokenData.access_token) {
120
      console.log(`[TOKEN] 异常：GitHub未返回error，但也没有access_token`);
121
      return redirectToApp(env, {
122
        error: "no_access_token",
123
        error_description: "GitHub未返回access_token",
124
        state: state || "",
125
      });
126
    }
127

128
    console.log(`[TOKEN] 换取成功，即将302重定向回App`);
129

130
    // 直接把 GitHub 的 access_token 带回 App
131
    // 注意：GitHub 传统 OAuth App 签发的 token 默认长期有效，没有 refresh_token
132
    return redirectToApp(env, {
133
      access_token: tokenData.access_token,
134
      scope: tokenData.scope || "",
135
      state: state || "",
136
    });
137
  } catch (err) {
138
    console.log(`[ERROR] 处理过程中抛出异常: ${err && err.stack ? err.stack : err}`);
139
    return redirectToApp(env, {
140
      error: "internal_error",
141
      error_description: String(err && err.message ? err.message : err),
142
      state: state || "",
143
    });
144
  }
145
}
146

147
/**
148
 * 把结果通过 302 重定向带回 App 自定义 scheme
149
 * env.APP_SCHEME 形如："myapp://oauth/callback"
150
 */
151
function redirectToApp(env, params) {
152
  const target = new URL(env.APP_SCHEME);
153
  for (const [k, v] of Object.entries(params)) {
154
    if (v !== undefined && v !== null && v !== "") {
155
      target.searchParams.set(k, v);
156
    }
157
  }
158

159
  // access_token 是敏感信息，日志里只打印前几位，避免完整token写入日志
160
  const loggedUrl = target.toString().replace(
161
    /access_token=([^&]+)/,
162
    (_, t) => `access_token=${t.slice(0, 8)}...`
163
  );
164
  console.log(`[REDIRECT] 302重定向回App: ${loggedUrl}`);
165

166
  return Response.redirect(target.toString(), 302);
167
}

wrangler.toml#

1
name = 'oauth-woker'
2
main = "index.js"
3
compatibility_date = "2026-07-24"
4
# 非敏感变量可以直接写在这里
5
[vars]
6
APP_SCHEME = "xxx://xx/xx"
7

8
# 以下敏感信息不要写在 toml 里，改用 wrangler secret 命令设置：
9
#
10
#   wrangler secret put GITHUB_CLIENT_ID
11
#   wrangler secret put GITHUB_CLIENT_SECRET
12
#
13
# 设置后 Cloudflare 会加密存储，不会出现在代码仓库或部署日志中
14
[observability]
15
enabled = true          # 总开关必须是 true，下面的子配置才会生效
16

17
[observability.logs]
18
enabled = true
19
head_sampling_rate = 1
20
invocation_logs = true
21

22
[observability.traces]
23
enabled = false          # 你现在确实不需要traces，关掉没问题

一、协议适配#

这次的目标很明确：

1. 复用网页端已有会话与鉴权流程
2. 把上游 SSE 数据流转换成标准 OpenAI 返回结构
3. 对外暴露常见 OpenAI 接口，做到低改造接入

最终本地服务提供了这些路由：

• GET /health
• GET /v1/models
• POST /v1/chat/completions
• POST /v1/responses
• POST /v1/files
• GET /v1/files
• GET /v1/files/{file_id}
• GET /v1/files/{file_id}/content
• GET /v1/files/{file_id}/url
• DELETE /v1/files/{file_id}

二、链路分析：从网页请求里抽象最小参数集#

在网页端实际请求里，可以定位到这几个关键参数：

• clerk_active_context
• projectId
• userId
• __client

其中：

• projectId 来自对话创建后的项目上下文
• clerk_active_context 与 __client 用于会话鉴权
• userId 用于拼接上游请求体

这四个参数就是整个中转服务的最小可用配置。程序启动时交互输入，避免硬编码到源码里。

三、程序架构#

四、协议转换：把 Orchids SSE 映射成 OpenAI 语义#

上游事件流里主要有三类信息：

• 文本增量（text_delta）
• 思考增量（thinking_delta）
• 最终结果与 usage

程序分两套解析逻辑：

• parseOrchidsSSEForFinalResult：非流式聚合
• parseOrchidsSSEStream：流式逐段回传

再映射为：

• Chat Completions：chat.completion / chat.completion.chunk
• Responses API：response.output_text.delta / response.completed

并且 reasoning 开关打开时，会把 thinking 内容透传到对应字段，保证“思考模式”可用。

五、文件能力：兼容 OpenAI Files 接口#

除了聊天接口，程序还实现了文件链路：

1. POST /v1/files 接收 multipart 文件上传
2. 本地落盘并生成 file-xxxx 形式的 file_id
3. 在消息输入中提取 input_file 的 file_id
4. 映射为上游可访问的 attachmentUrls

这意味着可以兼容部分依赖 Files API 的客户端工作流，而不只是纯文本对话。

六、支持模型#

当前版本内置模型列表如下：

• claude-sonnet-4-6
• gpt-5.4
• gpt-5.3-codex
• claude-opus-4.6
• claude-opus-4.5
• gpt-5.2-codex
• gpt-5.2
• gemini-3-flash
• gemini-3-pro
• gemini-3.1-pro

可通过 GET /v1/models 查询。

七、实际体验与边界#

这个方案的优点：

• 对接现有 OpenAI 生态方便
• 协议统一后可被多数工具直接消费
• 流式和 reasoning 都可跑通

但边界也很明显：

• 依赖网页会话参数，稳定性受平台变更影响
• 额度和速度都不适合当号池
• 上游接口一旦改字段，网关要同步维护

所以它更适合作为逆向与协议适配实践，而不是生产级高可用方案。

总结#

其实本质上是：
把“网页端调用流程”重构成“标准 API 服务”。

从工程角度看，真正有价值的是：

• 能否抽象出最小参数集
• 能否稳定解析 SSE 并保持语义一致
• 能否用统一接口服务不同客户端

如果只是临时脚本，那是一次调用；
完成了协议映射、错误模型和流式对齐，才算一个可复用的接口封装方案。

程序下载链接：
https://www.123865.com/s/vxarVv-o7yHH

仅用于学习逆向、协议理解和网关设计；
如果想直接拿来做业务化池子，建议降低预期。

思考#

不过很可惜，原项目是完全基于网页dom文本化的操作方案，网页上的图片信息并不会输出在给ai的文本信息里面，也就是说无法识别网页图片，并且在在网页的文字识别上也加了很多限制，有时候有一些网站的有效信息无法被正常识别。于是乎我想研究一下，看一下能不能在原项目的基础上，让它支持识别图片，并且可以识别更多的网页文字。在经过几天的努力，也是终于把这两个问题给搞定了。

改进方法#

1
recognize_image: {
2
  description: '识别指定 URL 的图片内容，将识别结果写入该图片的 alt 属性，并返回描述文本。',
3
  inputSchema: z.object({
4
    imageUrl: z.string().url(),
5
  }),
6
  execute: async function (input, { signal }) {
7
    const { imageUrl } = input;
8
    // 优先尝试直接使用 URL，失败则转换为 Base64
9
    // 调用视觉 API（如 Qwen-VL、GPT-4V 等）
10
    const response = await fetch('...', { ... });
11
    const description = ...; // 从 API 响应中提取描述
12
    // 查找页面中对应的 img 元素，写入 alt
13
    const img = document.querySelector(`img[src="${imageUrl}"]`);
14
    if (img) img.alt = description;
15
    return `图片识别完成，描述为：“${description}”`;
16
  }
17
}

总结#

于是乎，在经过了以上这些操作，成功让原项目支持了图片识别以及解除了一些网页文字识别的限制。以下是我改进版的仓库地址 https://github.com/iliaoke/page-agent

机会#

在上了大学之后，我换了新手机一加15T，芯片骁龙8 Elite5。而在这一代手机刚好引入了esp分区，而且由于高通的疏忽，没有验证esp分区，导致部分版本的系统可以执行任意efi底层代码，于是便有了这个项目。简单来说，这个项目可以在手机启动前无论手机有没有解锁bl，都返回bl已经上锁的信息，来通过手机的keystore效验。于是我尝试了这个项目的magisk模块，但是在APatch上发现模块的WebUI无法初始化成功。

解决#

于是乎，我翻了一下APatch和这个项目的源代码，我发现了问题的原因，这个项目模块在初始化的时候会调用KSU里面内置的一些函数方法，但是APatch并没有内置这个方法函数，所以会导致在APatch上面，这个模块会初始化失败，于是乎，我改了一下项目的源代码，当检测到没有这个方法函数的时候，将会采取手动历遍，并且返回相对应的数据结构的方法来兼容APatch。

灵机一动#

当我完成了以上事宜之后，突然想到，我做的这些不正好可以提交一个Pr来改进项目吗？于是乎抱着坎坷的心情，我提交了我第1个Pr。

结果#

在怀着坎坷的心情等了几天之后，原作者受理并成功通过了我的PR请求，这次经历无疑是圆了我初中时一直有的一个愿望。

原因解析#

1. 当电脑连接WIFI的时候,网络适配器中的wlan网卡便是已连接的状态
2. 此时我们打开热点,在网络适配器中会自动创建一个新的本地连接的网卡
3. 在默认情况下,热点的网卡会自动寻找可以访问互联网的网卡，作为上级网卡.
4. 但是由于校园网有检测,当热点网卡的流量转发到wlan时,校园网就会检测到有多个设备，从而断开访问

解决方法#

1. 通过手动设置热点网卡的上级网卡到其他的网卡,然后其他网卡的流量(经过这个网卡，对流量进行处理)再流入wlan,这样便不会被校园网检测.
2. 于是我们便要用到clash/singbox这样的代理工具的tun模式创造另外一个网卡(其实也可以用wintun驱动手动创建,不过得手动配置一些东西，比较麻烦)
3. 不一定需要添加clash的代理配置文件,只要打开tun模式即可.
4. 此时网络适配器中将会多出一张其他的网络设备
5. 此时右击该网卡属性点击共享，然后设置共享的网络为本地连接(相当手动指定热点的上级网络),便可以实现绕过校园网检测

具体操作#

1. 在房间的子路由中把wan接口删除,只留lan口,然后在设备中添加连接网线的网口的vlan设备,然后把这个设备添加到br-lan的网桥设备集合之中

2. 在光猫的管理员后台(不同的型号的光猫进入管理员后台的方法不同，有一些甚至进不去管理员后台，这里就不细讲了),把对应连接方式的lan口绑定全部取消,然后设置对应网口的vlanid和vlan绑定 以上这张图中，网络连接二是用于主路由和光猫拨号的，而网络连接五则是用于设置vlanid来实现单线复用的。

3. 在主路由进行和子路由中一样的操作,只是这一次不用把wan口删除了,把wan口对应的连接端口设置vlanid,然后也一并添加到br-lan中即可完成配置

完成了以上三个步骤,就可以实现光猫在桥接模式下，房间的子路由仍然可以接收到主路由下发的ip了

三大系统简述#

• ikuai系统不开源,可玩性和软件生态上比openwrt和RouterOS差,但是稳定,适用于对稳定性和兼容性要求比较高的工作环境，比如说企业.
• Routeros系统是开源的,基于linux,但是软件生态和可玩性也不如openwrt,Linux内核版本也较低,主打的也是偏稳定向的.
• openwrt系统是开源的,相当于阉割魔改版之后的linux（linux可以干的,openwrt通过补全环境和其他方法，基本都可以干,如docker,php,python等）,且积极更新Linux内核和对应s组件依赖,社区力量和软件包是远远大于另外两个软路由系统的,由于openwrt系统非常轻量，所以适配的硬件特别广.而另外两个软路由系统对硬件的要求多相对较高,而openwrt各种嵌入式设备也可以刷入,很多厂商的硬路由openwrt也会适配.所以对于个人玩家来说,强烈推荐openwrt系.

openwrt系分支#

而openwrt系又主要分openwrt官方系统,immortalwrt,kwrt,lead,x-wrt,istoreos

结论#

综上所述目前软路由系统，我个人推荐openwrt系,openwrt系里面结合更新速度和软件包数量以及稳定性,lede基于的主线版本太老,istoreos更新上游的速度较慢,kwrt魔改openwrt有点多(不是基于源代码魔改),稳定性较差.x-wrt特色不是很强,所以我个人综合起来更推荐immortalwrt

1.Tool Calls(很少使用)#

这个是一些大语言模型本身自带的功能,可以让用户自定义一段工具介绍，然后让LLM在适当的时候返回工具调用的结构体,然后由用户解析结构体执行程序之后，再返回获取到的结果来完善上下文

缺点: LLM和工具的衔接部分需要自己人为书写,比如需要判断LLM有没有返回工具调用信息,如果返回了，要根据返回的信息进行选择调用,写的工具越复杂，衔接部分需要花费的时间就越大,并且不同的模型的Tool Calls返回的信息可能还有所不同，不同模型的Tool Calls标准不一样，同一个工具需要对不同的模型单独做适配,所以并不流行(不过算是最早的给llm扩展工具的方法)

2.Mcp(流行)#

这是一套严格的标准,不会像Tool Calls一样可能因为模型的问题，返回的结构体有所差异,有mcp客户端,还有mcp服务器,工具的连接方式有远程，也有本地调用,是一套很完善的规则.

缺点: 因为调用流程过于严谨和繁琐,所以很容易引起llm上下文直接爆炸,让llm抓不到重点,对话越到后面效果越差。部署和开发也相对麻烦,因为有服务端，客户端，还有一些七七八八.而Tool Calls,可以直接在一个片段代码里面完成开发.

3.Skills(流行)#

这个是最近claude推出,我对他的理解是最高级别的prompt,这个严格来说并不是一个标准,而是共识,更偏向于一个技术理念,需要IDE自己去实现这个理念（Claude开源了他们官方skills的实现）,不像mcp和Tool Calls是有一定的标准的,要严格按照官方的标准来。

Skills某种程度上来说和Tool Calls有点类似,但是他不需要写LLM和工具之间的桥接代码,并且还可以完成一些prompt才可以做的事，比如说自定义一下语气和注意事项.

Tool Calls每写一个工具，我需要自己再写程序去判断LLM返回的工具调用信息，然后再去执行运算(并且还可能因为不同的模型返回的信息有差异而导致兼容性问题),而放到Skills,我只需要自定义一段话,不需要写具体的代码(工具本身是要写代码的，只是调用不需要写代码),比如在特定的时候执行某个文件目录下面的某个代码片段传入某些参数,相当于把桥接部分交由了程序本身(如Vscode和windsurf)去执行,所以说需要程序去适配Skills,它是共识和理念，而不是一套标准.(不过当流行起来的时候，共识理念最终也会成为大家默认的标准)

总结#

总结<以上三种给llm扩展工具的方式>,我个人对未来最看好的是Skills,我认为把这套逻辑和共识再进行优化加强是完全可以比过Tool Calls和mcp。Tool Calls桥接部分比较麻烦,一切运转都要依靠代码,还有兼容性问题;mcp开发部署繁琐,且容易引起上下文爆炸,LLM运行缓慢.Skills恰好能解决这两者的缺点

Hugo 支持的修改时间来源#

• :filemodtime
  使用文件本身的最后修改时间作为文章的修改时间。

• lastmod
  需要在文章 Front Matter 中手动维护 lastmod 字段。

• :git
  使用 Git 中该文件的最后一次提交时间作为修改时间（依赖 gitinfo）。

• date
  使用文章的发布时间作为修改时间。

各方案的自动化可行性分析#

在上述方案中：

• ✅ 可自动化

  • :filemodtime
  • :git

• ❌ 不适合全自动

  • lastmod（需要人工维护）
  • date（语义不符）

在 Serverless 场景下的问题#

使用 Hugo 的一个重要原因，正是为了 方便地将网站部署到 Serverless 平台（如 Cloudflare Pages、Vercel、Netlify 等）。

然而在 Serverless / CI 场景中：

• 每次部署都会重新 git clone 仓库
• 所有文件的 文件系统修改时间 都会变成「拉取时间」
• 这会导致：
  • 所有文章的修改时间被错误地更新为“本次部署时间”
  • 完全失去文章真实修改时间的意义

因此，:filemodtime 在默认情况下并不适合 Serverless 场景。

方案的现实问题#

理论上，:git 是最理想的方案：

• 修改时间与 Git 提交严格一致
• 完全自动化
• 不依赖文件系统时间戳

但在实际使用中：

• 即使开启了 enableGitInfo = true
• 某些情况下 :git 无法正确生效
• 在 CI / Serverless 环境中尤为明显

不确定这是环境限制、Git shallow clone、还是 Hugo 本身的 Bug，但结果是：该方案在实践中不够稳定。

最终解决方案：修改文件时间戳为Git 提交时间 + #

综合以上问题，我最终总结出了一套最适合 Serverless 管理的全自动方案：

1
[frontmatter]
2
lastmod = [':fileModTime']

1
git fetch --unshallow && chmod +x 1.sh && ./1.sh && hugo

自动同步 Git 提交时间到文件修改时间的脚本#

下面的脚本用于：

将当前目录下所有文件的最后修改时间，统一修改为对应的 Git 最后提交时间

1
# （此处放置你的脚本内容）
2
#!/bin/bash
3
# 功能：将 git 仓库中所有被追踪文件的修改时间改为最后一次提交时间
4

5
# 确保当前目录是 git 仓库
6
if [ ! -d ".git" ]; then
7
    echo "Error: 当前目录不是 git 仓库根目录"
8
    exit 1
9
fi
10

11
# 获取所有被追踪文件（包含特殊字符/空格/中文）
12
git ls-files -z | while IFS= read -r -d '' file; do
13
    # 获取最后一次提交的 Unix 时间戳
14
    timestamp=$(git log -1 --format="%ct" -- "$file")
15

16
    if [ -n "$timestamp" ]; then
17
        # 使用 touch 修改文件修改时间
18
        # -d "@$timestamp" 表示从 Unix 时间戳设置时间
19
        touch -d "@$timestamp" "$file"
20
        echo "Updated: $file -> $(date -d "@$timestamp" '+%Y-%m-%d %H:%M:%S')"
21
    else
22
        echo "Skipped (not tracked): $file"
23
    fi
24
done
25

26
echo "All tracked files' modification times updated."

我的认知#

我始终认为Ai始终是作为一个工具,用来提升工作效率,而非核心.大模型本身的特点就注定了有一些工作是无法代替人类.比如项目的一些宏观设计和管理,一些最新的技术的使用和获取.它是一个超大知识的集合体,它的作用是降低我在知道该怎么做的情况下，让我避免去查代码文档，一步一步慢慢实现功能所带来的时间成本.而不是想做什么，跟AI说一句话，让他帮我实现就行了,我们要做的是工程师，是设计师，而不是让AI作为核心，我们负责提要求。不然就相当于我们是甲方，AI是乙方。我们应该当的是boss，是甲方,AI当我们底下的员工，来负责完成我设计的东西（乙方需求）。

所以在我看来,使用AI无非就两个档次#

• 初级者<什么都不懂>,只知道自己想要什么,反正让AI完成就行了。(这在学习的初期确实可以很快带来成就感,但始终无法避免一个问题,你不懂的始终不懂，懂的是AI而不是你,你并没有任何的核心竞争力)
• 真正掌握AI的人<自己设置架构>，自己设置语法要求,自己设置UI层级和UI设计风格,规定使用的技术栈,让AI按照自己的规定去完成对应的工作。AI是提升效率的工具，而不是自己的大脑,真正应该怎么做，应该是自己知道，而不是AI知道。

所以在这个时代,有人害怕ai,有人依赖AI,那我的答案是掌握AI.#

一、Root 实现思路：按技术路线分类#

二、按时间线看典型方案#

三、综合对比与结论#

为什么使用 AI IDE？#

• 传统 AI 聊天无法：
  • 实时读取本地文件
  • 兼顾项目的宏观框架管理
• 偏商业化的 AI IDE：
  • 一般不允许自定义第三方服务商接口
  • 强制使用平台模型收取订阅费
  • 实时读取本地文件
  • 适配开发的执行流程与逻辑

因此，为了高效开发和项目管理，需要使用 AI IDE。

AI IDE 的能力评价指标#

1. 硬实力：自带模型能力
2. 软实力：上下文补全与逻辑能力
   • 通过插件、执行策略、隐藏的上下文prompt 等实现

• 两者缺一不可

AI 编程工具分类#

国内 AI IDE#

• Trae
  • 特有 Solo 模式（和普通模式感觉主要是 UI 差别，在功能上感觉差的不是很大，可能隐藏 prompt 有所优化）
  • 可使用规定的国内其他服务商接口
• Qoder
  • 无特色
  • 上下文消耗快
  • 无法使用国外模型或其他接口
• 通义灵码
  • 无特色
  • 无法使用国外模型或其他接口

国外 AI IDE#

• GitHub Copilot★★

  • VSCode 插件形式
  • 适合片段式的文件
  • 上下文补全能力较弱
  • 无法全面定制化

• Cline★★（开源）

  • 可自定义任意服务商
  • VSCode 插件形式
  • 适合片段式的文件
  • 上下文补全能力较弱
  • 无法全面定制化

• Kilo（开源）

  • 可使用规定的第三方服务商api
  • VSCode 插件形式
  • 适合片段式的文件
  • 上下文补全能力较弱
  • 无法全面定制化

• Cursor★★★

  • 基于 VSCode 深度定制
  • 自研模型 Composer 1 (专为编程训练, 功能强大)
  • 可使用规定的其他服务商 API
  • agent可以直接连接github远程储存库(特色功能)
  • 预设 Prompt 优秀输出质量高，但免费额度少，订阅贵
  • 亮眼功能：
    • 浏览器设计模式：可以直接在ide里面打开网页，并且选择元素，方便设计网页
    • debug：可以根据log寻找隐藏bug

• kiro 电脑安装闪退，我用不了(哭)

• Windsurf★★★

  • 基于 VSCode 深度定制
  • 自研模型 SWE-1.5 (专为编程训练, 功能强大)
  • 亮眼功能：
    • Memories：可以根据对话和习惯生成对应的记忆（ai自动生成记忆，以在对话之间保持上下文连贯性）
    • DeepWiki：独家功能,定位项目中关键函数或变量，了解用途和在项目其他地方引用 (方便学习他人的开源项目)
    • CodeMap：独家功能,用于分析现有项目代码结构,可以根据输入的问题生成项目代码实现的流程图,点击流程图可以定位对应代码实现的部分（对于解剖他人项目的功能实现很有用）
    • 浏览器设计模式：可以直接在ide里面打开网页，并且选择元素，方便设计网页
    • 对话消息互通：独家功能,不同对话之间可以选择互通消息，如两个不同的项目,具有一定的关联性，我们就可以通过这个功能实现两个项目在对话层面上的互通，而不需要ai去研究另外一个项目的代码，防止添加过多的内容，导致上下文混乱
  • 免费额度高，价格便宜
  • 支持规定的其他服务商 API

• Zen Editor（开源）

  • 可使用任意服务商接口
  • 自带免费额度高
  • 上下文补全能力较弱

总结推荐#

• 综合价格、模型能力和上下文补全能力，我个人首推 Windsurf
• DeepWiki、CodeMap 和消息互通是其最大亮点，让其上下文补全能力非常强大
• 其他 AI IDE 在 UI 功能上同质化严重，差别主要在 AI 模型、执行逻辑和预设 Prompt
• 如果不考虑开发效率，单论编码能力,openai的codex和claude code这种命令行式开发可能是最强的一批,其次就是cursor和windsurf

linux系统#

• 各大Linux系统(Ubuntu系/arch系/fedora系/Wsl2)都可以，网上教程多以Ubuntu lts版本为例(便于找依赖和教程)

内核源代码#

从github上搜索自己机型的内核源代码
如https://github.com/Evolution-X-Devices/kernel_xiaomi_sm8450(项目名一般采用 kernel_厂家名_芯片组代号 的形式,5.10之后都是gki内核,所以内核名称基本是以芯片组命名如sm8450,有些项目也可能是按机型代号命名，而不是芯片组)

编译链工具#

5.10以上的内核一般采用纯clang/llvm进行编译(低版本内核也可尝试，但有可能能成功编译但会开不了机)

编译过程#

1
sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 libncurses5 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc tar xz-utils cpio findutils

1
export PATH="$PATH:/../../编译链工具文件夹/clang-rxxxx/bin"

1
export ARCH="arm64"
2
export SUBARCH="arm64"
3
export CC="clang"
4
export LLVM=1
5
export LLVM_IAS=1
6
export HOSTCC=clang
7
export LD=ld.lld
8
export CLANG_TRIPLE="aarch64-linux-gnu-"

1
export LTO=thin

1
make ARCH="arm64" gki_defconfig
2
make -j$(nproc --all)

打包内核#

由于没有编译kernel-devicetree,也没ramdisk,所以无法和内核二进制文件打包成boot.img刷入手机分区(也可以用magiskboot把手机原本的boot.img进行解包，把其中的内核二进制文件替换之后,再打包就行了)
这个时候就需要AnyKernel3对内核二进制文件进行打包
详细教程参考
https://github.com/tiann/KernelSU/discussions/952

刷入内核#

可以在twrp或一些用于刷写内核的app中刷入打包后的AnyKernel3.zip

注意#

不同型号内核以及不同版本的编译器，可能对依赖和代码语法要求也有所不同，需要自行解决。

Clash(更新停滞)#

Clash 是一个最初由 Go 编写的多协议代理核心（原项目已删除）。
使用广泛，生态庞大。

特点：

• 使用统一的 YAML 配置，无需因平台不同而修改
• GUI 客户端数量最多、生态最大
• 跨平台兼容性极强

缺点：

• 原项目已停止维护
• 新协议支持较慢（如 Reality、Hysteria2 等）

Mihomo（Clash Meta）★★★#

MetaCubeX 社区维护的 Clash 增强版，也是目前最主流的 Clash 继承者。

特点：

• 完全兼容 Clash 配置
• 支持现代协议（Reality、Hysteria2、TUIC 等）
• 活跃维护，性能更高

Sing-Box（sb）★★#

由 SagerNet 开发的现代化代理核心，目前增长最快、架构最先进。

特点：

• 极度轻量，理论性能高
• 高度可定制的网络与路由配置
• 支持大量现代协议
• 跨平台优秀

缺点：

• 配置难度高，对新手不友好
• GUI 生态较少

V2Ray(更新缓慢)#

由 v2fly 社区维护的原始 V2Ray 核心。

特点：

• 配置灵活
• 结构成熟
• 较为轻量

缺点：

• 开发速度慢
• 新协议支持不佳
• 配置复杂
• GUI 生态弱

Xray#

V2Ray 的增强版核心，由 XTLS 项目维护。

特点：

• 完全兼容 V2Ray 配置
• 支持 Reality
• 支持 XTLS，性能大幅提升
• 性能明显高于官方 V2Ray

缺点：

• 配置复杂
• GUI 生态较弱

dae#

基于 eBPF 的 Linux / 路由器高性能代理引擎，更像“下一代分流框架”。

特点：

• 基于 eBPF，性能极高
• 几乎不占 CPU
• 延迟极低
• 路由分流能力极强

缺点：

• 仅支持 Linux / OpenWRT
• 配置复杂
• GUI少

各操作系统主流GUI代理客户端(整体按照知名度排序)#

总结#

小白无脑选择clash系客户端，有其他要求可自定义选择。

假入库原理分析:#

Steam购买游戏相当于购买游戏的游玩资格，购买完成后，将会下载游戏的清单文件(相当于下载列表),然后steam会用游戏的depot key(正版购买用户自动下发)对清单文件进行解密下载,下载完成后，打开游戏会调用steamwork api进行验证当前运行的steam账号是否拥有该游戏,认证通过后即可正常游玩。

我们可以在其中做些手脚,便可以实现假入库。

1. 游戏清单文件是可以公开找到的，但是需要正版账号的depot key解密才可以解密下载(游戏每一个版本的清单文件对应着一个depot key,所以想要玩到最新的游戏内容，密钥文件也需要及时更新)。假入库的商家可能会根据爬虫或者其他技术手段(如通过木马病毒从其他steam玩家账号中提取depot key)，可以搞到最新的游戏depot key

2. 通过解密清单将游戏完整下下来后,通过steamtool/GreenLuma hook注入自己的.dll文件,对steam原有的steamwork api进行劫持,便可以实现让游戏认为账号已经获取了该游戏的游玩权限。

于是乎通过以上手段，便实现了一套完整的steam游戏假入库

在steam游戏破解游玩方面,主要有两种破解方法

一是对steam客户端进行crak#

让steam认为你拥有该游戏的游玩权限,再搭配实时获取别人最新的depot key,便可实现几乎与正版购买一致的游戏体验(云存档,成就系统等等)

二是对游戏文件本身进行修改#

对游戏文件夹本身进行修改,内置一个模仿steam api行为的第三方轻量steam client,实现steam游戏脱离steam官方客户端运行,方便游戏在互联网上传播

其他:#

• steamlan/gbe 通过模仿steam lan api,可以实现游戏在线/离线模式下局域网联机,而不需要走steam官方服务器
• steamless 移除steam端的d加密(不会绕过游戏游玩验证,并且非steam的d加密无法破解，比如说黑猴,需要使用别人的d加密密钥才可以认证游玩)

总结:#

Steam假入库商家通常通过劫持steam根目录的hid.dll文件进行自定义操作,hook核心一般采用steamtool,加上不知道哪里搞来的清单depot key源,由于是黑箱代码,无法准确判断是否含有其他的木马病毒,来获取自己steam的一些信息,对账号造成隐性风险,所以不建议使用淘宝上的 steam假入库。

动态博客的优缺点:#

静态博客的优缺点:#

动态博客框架#

1
  世界知名动态博客框架，主题资源插件丰富，教程多。

1
 轻量级动态博客框架，主打一个快速部署，快速上线

1
 界面很漂亮，资源插件相对来说比较丰富，社区正在逐步发展，安装部署方法较为麻烦，比较吃服务器性能

静态博客框架#

1
 node.js开发,教程很多，社区插件主题资源丰富，缺点是当文章数量>1k时，构建速度会显著减缓

1
 go语言开发,使用go template模板，学习门槛相对其他的来说高点。运行build效率很高,支持热加载,更改不需要刷新网页页面即可生效。教程资源丰富,社区插件资源也很多，稍逊hexo,最大的优势是当文章数量很多时，构建静态网站的速度可以快其他框架几倍.

1
 资源插件相对较少,界面简洁直观,但有github官方支持,可以直接将存入仓库的md文件转换成网页

1
 资源插件丰富，可扩性强,常用于构建文档，不用于博客

1
新一代静态框架,0 javascript的技术理念让网站首页加载起来非常快,采用服务端渲染的技术理念
2
可局部初始化组件为spa,增强网站运行效率,可搭配其他前端框架组件使用，但主题资源相对较少。

总结#

对于零基础的小白，想搭建博客，首先推荐动态博客框架，首选wordpress,有一定技术基础，搭建自己个人的轻量博客推荐静态框架,首选hexo/hugo,想要更快的构建速度和热加载，选择hugo.如果想尝试更先进的技术理念和更快的首页加载速度，可以尝试astro

杂谈#

本站采用hugo构建,github仓库储存,cloudflare远程克隆部署,评论功能对接waline。

实现原理#

我们在聊天机器人的界面发送命令：

1
/chat 聊天内容

通过设置 Webhook 地址指向 Worker，Worker 中写好处理指令的代码，截取 /开始 后面的文字，然后转发给 Cloudflare 官方提供的免费的大语言模型后端，然后再处理返回的信息，最后再通过 Telegram Bot API 再返回消息到客户端。

这样便实现了无服务器的聊天 AI Bot，但是这有个缺点：用户的每一次聊天都是单独的一次请求，bot没有上下文记忆,因为 Worker 本身是个无状态的js执行器，所以这个 Bot 其实相当于是一个图形化的终端命令请求器。

但是 Cloudflare 有提供免费的额外的 KV 数据库，于是我们再改动一下代码：#

1. 用户发来的文字不直接请求大语言模型后端
2. 而是先存入 KV 数据库
3. 最后将 KV 数据库里的数据一起再发给大语言模型后端
4. 处理返回的信息
5. 返回 Telegram 客户端

于是Worker通过外挂KV数据库，最终便实现了带有记忆的无服务器聊天 AI 机器人。

实现源代码#

1
const TELEGRAM_BOT_TOKEN = "";
2
const CF_API_TOKEN = "";
3

4
async function run(model, input) {
5
  const response = await fetch(
6
    `https://api.cloudflare.com/client/v4/accounts/1f5b3d5417456835c8191a2ec42f449e/ai/run/${model}`,
7
    {
8
      headers: { Authorization: `Bearer ${CF_API_TOKEN}` },
9
      method: "POST",
10
      body: JSON.stringify(input),
11
    }
12
  );
13
  return await response.json();
14
}
15

16
async function sendTelegramMessage(chat_id, text) {
17
  try {
18
    await fetch(`https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage`, {
19
      method: "POST",
20
      headers: { "Content-Type": "application/json" },
21
      body: JSON.stringify({
22
        chat_id,
23
        text,
24
        parse_mode: "MarkdownV2",
25
      }),
26
    });
27
  } catch (err) {
28
    console.error("发送 Telegram 消息失败:", err);
29
  }
30
}
31

32
export default {
33
  async fetch(request, env, ctx) {
34
    if (request.method !== "POST") return new Response("ok", { status: 200 });
35

36
    try {
37
      const data = await request.json();
38
      console.log("Telegram Update:", JSON.stringify(data));
39

40
      const message = data.message;
41
      if (!message?.text) return new Response("ok", { status: 200 });
42

43
      const text = message.text;
44
      const match = text.match(/^\/chat(?:@\w+)?(?:\s+([\s\S]+))?$/);
45
      const arg = match ? (match[1] || "").trim() : "";
46

47
      console.log("完整消息文本:", text);
48
      console.log("命令参数:", arg);
49

50
      if (!arg) {
51
        await sendTelegramMessage(message.chat.id, "请在 /chat 后输入要生成的内容，例如：/chat 写一个小故事");
52
      } else {
53

54
        let history = await env.bot.get(message.chat.id);
55
        history = history ? JSON.parse(history) : [];
56
        history.push({ role: "user", content: arg });
57
        await env.bot.put(message.chat.id, JSON.stringify(history));
58

59
        const aiResponse = await run("@cf/openai/gpt-oss-120b", {
60
          instructions: '你是liaoke的私人中文AI助手，简洁地回答用户的问题。',
61
          reasoning: { "effort": "medium" },
62
          input: history,
63
        });
64

65
        console.log("AI 原始响应:", JSON.stringify(aiResponse));
66

67

68
        const reasonText = aiResponse?.result?.output
69
          ?.filter(o => o.type === "reasoning")
70
          ?.map(o => o.content?.map(c => c.text).join("\n"))
71
          .filter(Boolean)
72
          .join("\n\n") || "AI 无法生成内容";
73

74
        const outputText = aiResponse?.result?.output
75
          ?.filter(o => o.type === "message")
76
          ?.map(o => o.content?.map(c => c.text).join("\n"))
77
          .filter(Boolean)
78
          .join("\n\n") || "AI 无法生成内容";
79

80

81
        const escapeMD = (text) => {
82
          if (!text) return "";
83
          return text
84
            .replace(/\\/g, "\\\\")
85
            .replace(/`/g, "\\`")
86
            .replace(/_/g, "\\_")
87
            .replace(/\*/g, "\\*")
88
            .replace(/\[/g, "\\[")
89
            .replace(/\]/g, "\\]")
90
            .replace(/~/g, "\\~")
91
            .replace(/>/g, "\\>")
92
            .replace(/#/g, "\\#")
93
            .replace(/\+/g, "\\+")
94
            .replace(/-/g, "\\-")
95
            .replace(/=/g, "\\=")
96
            .replace(/\|/g, "\\|")
97
            .replace(/\{/g, "\\{")
98
            .replace(/\}/g, "\\}")
99
            .replace(/\./g, "\\.")
100
            .replace(/!/g, "\\!");
101
        };
102

103

104
        const messageMD = `
105
🧠 推理过程：
106
\`\`\`
107
${escapeMD(reasonText)}
108
\`\`\`
109

110
💬 最终回答：
111
${escapeMD(outputText)}
112
        `;
113

114

115
        await sendTelegramMessage(message.chat.id, messageMD);
116
        history.push({ role: "assistant", content: outputText });
117
        await env.bot.put(message.chat.id, JSON.stringify(history));
118
        console.log("AI 输出发送给用户:", messageMD);
119
      }
120

121
      return new Response("ok", { status: 200 });
122
    } catch (err) {
123
      console.error("解析 JSON 或处理失败:", err);
124
      return new Response("error", { status: 400 });
125
    }
126
  },
127
};