柴家琪的博客 | Blog of ChaiJiaqi

👋 欢迎访问 | Welcome

Posted on 2022-07-20 Edited on 2026-04-11 In Meta

欢迎访问此站点！你可以先查看关于页面了解更多。| Welcome to this site! You can start by checking the About page to learn more.

OpenClaw Tricks

Posted on 2026-03-29 Edited on 2026-04-11 In AI , OpenClaw

For basic knowledges and usages about openclaw just check its github page

Empowerment

To make it really open claw, it’s necessary to grant it the access to exec command, otherwise it’s just a chatter.
To do so, edit the openclaw.json:

"tools": {
   "profile": "full",
   "allow": ["*"],
   "exec": {
     "host": "gateway",
     "security": "full",
     "ask": "off"
   }
 }

Skills

Skills can be found at clawhub, skills.sh, etc. They have guides about how to install.

Model Config

You can edit the openclaw.json directly to add models, but it’s more suggested to use the openclaw onboard command instead, even though it feels a litter semantically incorrect.

Channel Config

Add any social media channel will give you the ability to dictate that lobster remotely.

QQ Bot

Get an app id and app secret first at here, then:

# Install the plugin
openclaw plugins install @tencent-connect/openclaw-qqbot@latest
# Bind the robot
openclaw channels add --channel qqbot --token "$appId:$appSecret"
# Restart service
openclaw gateway restart

OAuth2 Device Code 授权工作流

Posted on 2026-03-18 Edited on 2026-04-11 In OAuth2 , Device Code

技术规范

OAuth2 的技术规范和本文用到的相关术语定义可参考 RFC 8628

通用授权时序图

对于无法直接调用浏览器的程序，比如命令行，通常使用 Device Code 授权类型（Grant Type）。

sequenceDiagram
    autonumber
    participant c as 客户端（CLI/设备）
    actor u as 用户
    participant ua as 用户代理（浏览器）
    participant a as 授权服务
    participant b as 平台后端

    c ->> a: 请求 device_code（client_id/scope）
    a ->> c: 返回 device_code/user_code/verification_uri/expires_in/interval

    c ->> u: 展示 verification_uri 与 user_code（或 verification_uri_complete）
    u ->> ua: 在浏览器打开验证地址并登录
    ua ->> a: 提交 user_code 并确认授权

    loop 按 interval 轮询（直到成功/过期）
        c ->> a: device_code 换 token（grant_type=device_code）
        a -->> c: authorization_pending / slow_down / access_token
    end

    c -->> b: 携带 access_token 获取资源

可同时参考 RFC 8628 的流程说明。

关键参数和步骤

客户端调用 device authorization endpoint，获取：
- device_code：设备端轮询 token 接口时使用
- user_code：用户在浏览器输入的短码
- verification_uri：用户需要访问的验证地址
- verification_uri_complete：可直接完成验证的地址（如服务端提供）
- expires_in：device_code 过期时间（秒）
- interval：建议轮询间隔（秒）
用户在浏览器完成登录与授权确认
客户端按 interval 轮询 token endpoint，直到拿到 access_token 或超时**

轮询错误码处理建议

authorization_pending：用户尚未完成授权，继续按间隔轮询
slow_down：客户端轮询过快，增加轮询间隔后重试
expired_token：device_code 已过期，需重新发起设备授权流程
access_denied：用户拒绝授权，结束流程并提示用户重试或退出

安全与体验建议

不要在日志中记录完整的 device_code、access_token、refresh_token
user_code 展示给用户时，建议分组显示（如 WDJB-MJHT）并给出过期倒计时
若服务端返回 verification_uri_complete，优先展示，减少用户手动输入成本
对于 CLI，可在轮询期间提供进度提示，并支持用户主动取消登录

Token 保存和更新

Device Code 获取 token 后的保存与刷新策略，与 Authorization Code 基本一致：可参考 OAuth2 Authorization Code 授权工作流中的 Token 保存和更新 章节。

获取授权相关配置

如果服务支持 OIDC Discovery，可通过 $baseUrl/.well-known/openid-configuration 获取端点元数据（如 device authorization endpoint、token endpoint 等）；也可参考 OAuth 2.0 Authorization Server Metadata（RFC 8414）约定。更通用的配置获取建议可参考 OAuth2 Authorization Code 授权工作流中的 获取授权相关配置 章节。

OAuth2 Authorization Code 授权工作流

Posted on 2026-03-18 Edited on 2026-04-11 In OAuth2 , Authorization Code

借鉴了这里

技术规范

OAuth2 的技术规范和本文用到的相关术语定义可参考 RFC 6749，以及针对原生应用的 RFC 8252

通用授权时序图

业界普遍使用 Authorization Code 授权类型（Grant Type）。不同客户端的登录流程大致是一致的：

sequenceDiagram
    autonumber
    participant c as 客户端
    actor u as 用户
    participant ua as 用户代理（浏览器）
    participant a as 授权服务
    participant b as 平台后端
    
    c ->> ua: 进入浏览器
    ua ->> a: 发起授权请求
    a ->> ua: 重定向到登录页

    u ->> ua: 用户输入账号密码并登录
    ua ->> a: 发送登录信息

    critical 重定向地址不同导致不同客户端接收 code 的方式不同
    a ->> c: 携 code 重定向到 redirect_uri，客户端接收
    end
    
    c ->> a: code 换 access_token
    a ->> c: access_token

    c -->> b: 携带 access_token 获取资源

可同时参考 RFC 6749 的流程图

有些应用在发送登录信息后，还会进入授权页，让用户确认具体需要授权哪些 scope。如暂时不需要细分 scope，可配置取消此门槛

客户端授权流程差异

Authorization Code 授权类型要求必须通过浏览器进行授权。对于 Web 客户端，使用浏览器重定向即可实现以上流程。而对于非页面项目，就需要在登录时打开浏览器，并等待回调。切换应用导致了客户端授权流程的差异，即上图中标为 critical 的部分。

授权流程差异

授权流程基本和通用授权时序图一致，客户端 和 用户代理 其实都是浏览器，只是在不同的地址

环回地址重定向回调流程

一般授权服务会支持环回地址重定向。使用环回地址回调时，客户端会监听本地回调地址，比如 http://127.0.0.1:65143/auth/callback（端口通常由客户端动态分配并在发起授权时带上）。对应地，授权服务需要允许 http://127.0.0.1:{port}/auth/callback 这类回调地址模式。

如果你在开发 JetBrains IDE 插件，可以使用其内置的服务器（常见端口是 63342）

授权回调部分流程是：

 sequenceDiagram
    autonumber
    participant c as Jetbrains 插件
    participant ua as 用户代理（浏览器）
    participant a as 授权服务

    a ->> ua: 302 重定向到环回回调地址（携带 code/state）
    ua ->> c: 访问本地回调地址
    c ->> ua: 返回登录成功/失败页（或再 302 到展示页）

环回回调地址类似于：GET http://127.0.0.1:65143/auth/callback?code=...&state=...

环回地址重定向是 RFC 8252 推荐的一种桌面应用接收 OAuth 回调的方式

使用环回地址的好处是：客户端可直接、稳定地收到 code；同时客户端可向服务端上报登录结果用于观测与审计

中间页重定向回调流程

有些程序会在系统中注册自定义协议。以 VSCode 为例，使用浏览器访问 vscode://... ，浏览器会弹框提示打开对应的应用。利用这一技术可以实现更流畅的 OAuth2 桌面应用的登录

但是直接使用会带来一个体验问题。浏览器跳转到自定义协议后会切到客户端，浏览器页签可能停留在空白页、提示页或中断态。为避免此问题，我们使用中间页方案：回调时先跳转到中间页，再由中间页访问自定义协议打开客户端，并在浏览器展示明确的成功/失败提示

因此，中间页重定向回调流程是：

 sequenceDiagram
    autonumber
    participant c as 客户端
    participant ua as 用户代理（浏览器）
    participant a as 授权服务

    a ->> ua: 重定向到中间页
    ua ->> c: 访问自定义协议打开客户端

自定义协议也是 RFC 8252 推荐的一种桌面应用接收 OAuth 回调的方式

PKCE

虽然各个客户端被注册成使用 BASIC 认证，但实际上管理平台、插件等都属于公开客户端。在进行获取 access_token 时，全程都在用户可感知的客户端进行，所以用户或黑客程序有能力轻松地获取到 Header 中的客户端 id 和密钥信息。所以，为了保证授权流程的安全，以上客户端必须使用 PKCE 技术

PKCE（Proof Key of Code Exchange）工作流程如下：

生成 PKCE 相关参数
- 生成一个高熵的随机字符串作为 code_verifier
- 选择一个 hash 算法，一般是 SHA-256
- 通过 BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) 获取 code_challenge（无 = padding）
发起请求授权时携带 code_challenge 和 code_challenge_method。如果 hash 算法是 SHA-256，则 code_challenge_method 是 S256
在使用 code 换取 access_token 时携带 code_verifier。授权服务将结合两步接收的 PKCE 相关参数进行校验

Token 保存和更新

Web 客户端可以使用加密的 HTTP Cookie（iron-session）保存 token。桌面客户端可以使用系统钥匙串保存 token。

更新 token 需要用到 grant_type=refresh_token 刷新流程，携带 code 换 access_token 时返回的 refresh_token 调用 token 接口即可

State

state 参数是防止 CSRF 攻击的重要机制：客户端生成随机 state 并保存，发起授权时携带此参数，回调时客户端需验证 state 是否匹配

获取授权相关配置

授权流程涉及到多个 URL 的调用，可能还需知道授权服务支持的授权类型、PKCE 支持的算法等。若服务提供 OIDC Discovery，可通过 $baseUrl/.well-known/openid-configuration 获取元数据；若非 OIDC，也可参考 OAuth 2.0 Authorization Server Metadata（RFC 8414）端点约定。

Font, Charset & Encoding

Posted on 2026-03-11 Edited on 2026-04-11 In Web , Text & Encoding

For text shown on the internet (blogs, instant messages, etc.), have you ever wondered how it is displayed?

It relates to three basic concepts, from frontend to backend: Font, Character set (charset), and Encoding.

Font

On digital devices, text is ultimately rendered into images (a matrix of pixels). A font describes how characters are drawn.

A font typically stores outlines as vector graphics (often Bézier curves), so glyphs can be drawn at many sizes and in different styles.

Common font file types are OpenType (OTF), TrueType (TTF), and WOFF/WOFF2.

Character set (charset)

How does a program know which glyph in the font to draw?

You need a mapping between characters and numbers. Take Unicode as an example, each character is assigned a code point (for example, ‘你’ is U+4F60, and ‘A’ is U+0041).

Fonts don’t store “characters” directly; they store glyphs (shapes). A font’s cmap table maps code points → glyphs. Not every glyph necessarily has its own code point (for example, ligatures and stylistic alternates).

A charset is not a physical thing; it’s a standard/specification that everyone follows. The most widely used character set today is Unicode. Older/legacy character sets include ASCII and many regional standards.

Encoding

Computers store and transmit bytes, so we need an encoding: a rule for turning code points into bytes (and back). Without knowing the encoding, a byte sequence can’t be interpreted correctly.

Some encodings are fixed-length (for example, UTF-32 uses 4 bytes per code point). Others are variable-length: UTF-8 uses 1–4 bytes, and UTF-16 uses 2 or 4 bytes (surrogate pairs for code points above U+FFFF). Variable-length encodings are efficient for common text, especially when most characters are in the ASCII range.

The most common encoding on the web is UTF-8, a Unicode-based variable-length encoding. For example, ‘你’ (U+4F60) is encoded in UTF-8 as the bytes E4 BD A0.

This article demonstrates the three basic concepts behind text rendering. In real systems there are more steps, like shaping, layout/positioning, and rasterization.

Prompt Engineering

Posted on 2026-03-07 Edited on 2026-04-11 In AI , Prompt Engineering

Inspired by this site
Last updated at: 2026-03-07

概念概述

Zero Shot 直接提问
Few Shot 给出问答示例，然后提问
Chain-of-Thought Prompting 思考链提示。ZeroShot-CoT 是添加一行 “Let’s think step by step”，FewShot-CoT 是在示例回答中添加思考步骤
Auto CoT。阶段一，模型将数据集中的问题按语义进行分组，从每组中采样代表性问题，使用 ZeroShot-CoT 为挑选的问题生成推理路径。阶段二，从示例库中挑选问题作为 FewShot，可添加 ZeroShot-CoT
Meta Prompting 元提示。结构化输入，引导结构化输出
Self Consistency 自我一致性。多次输出，少数服从多数。用于提高结果准确度
Generated Knowledge Prompting 先让模型生成知识，再回答问题。前提是假设模型内部已有相关知识
Prompt Chaining 提示链。拆解任务，将前面任务输出作为后面任务的 Prompt 的输入
Tree of Thoughts 思考树。不同于 CoT，对于每一步输出都要求给出多个输出，选择正确输出并继续
Retrieval Augmented Generation。向量检索相关内容并作为上下文传给模型
Automatic Reasoning and Tool-use (ART)。类似于 Auto CoT，不同的是，它问题检索范围较为精确，而且强调工具调用能力
Automatic Prompt Engineer (APE)。模型遵循生成-评估-迭代闭环来自主更新优化 Prompt。多发生在离线优化时，也可以在 pre-response 时优化用户输入，以及在 post-response 后验证输出并迭代
Active-Prompt。让模型挑出最难或不确定的问题，由人类进行标注。用以提升复杂、垂直领域的准确率
Directional Stimulus Prompting (DSP)。先生成暗示（Hint/Stimulus），再用这个暗示来引导模型生成最终结果。
PAL (Program-Aided Language Models)。类似于 CoT，但是解决步骤是以编程语言形式展示，在模型输出后，需要调用对应的运行时计算出结果
ReAct Prompting。模型按思考-行动-观察循环逻辑工作，强调外部交互。为 ART 提供了逻辑框架
Reflexion 反思。Actor 执行，Evaluator 打分或检测，有问题则交给 Self-Reflection 重新审视并在下轮优化
Multimodal CoT Prompting 多模态思维链提示。将 CoT 拓展到了多模态，生成思维链时要结合多模态信息

Hexo + GithubPages

Posted on 2022-07-21 Edited on 2026-04-11 In Hexo , GitHub Pages

创建和部署：
https://hexo.io/docs/github-pages.html

文章置顶：
https://zhuanlan.zhihu.com/p/33617563