我上一份工作，也是大学毕业后的第一份工作，在深圳南山某不知名科技公司，部门加班文化严重，组内更是严重（主要是由于那个恶心的组长喜欢无差别PUA所有组员导致，这个事我想可以单开一篇来讲），周内八九点下班是常态，周六日加班也不在少数，那会头痛的频率非常高，但是，哪怕是这种状况下，周六日还是会逼着自己学点东西，总认为不进步就会落后，后面就找不到好工作，一系列想法让自己变得很焦。

辞职后，在家休息了一小段时间，开始投递简历，最终选择了一家北京的公司（很大一部分原因是有两个大学室友都在北京，有玩伴），这家公司面试结束后hr就说明了加班很少，几乎不加班，来了之后也确实如此，工作半年了，除了部分时候觉得工作完成的不满意主动带电脑回家办公，其余时候都是到点下班。奇怪的是，在这种空闲时间很多的情况下，反而不愿意主动学习了（当然，也不是完全不学习，只是主动性少很多），脑子里也有了很多摆烂似的想法，比如“这样也挺好的，为什么非要一直进步呢，能养好自己，每个月存点钱，开开心心”。

高压情况下，反而促进自己主动学习，现在想来，当时的心态，很大部分原因是觉得学了更多东西，能去到更好的企业，逃离那个让自己产生大量负面情绪的地方。

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://bambooo.top/posts/fiddle/circle

览毕，何不一言？

前言

日常使用编程 Agent 的时候，总会考虑到上下文窗口的大小，首先，不同厂商模型的上下文长度不一样，我日常使用 Claude Code（以下简称cc），搭配 GLM5.1、Deepseek-v4-pro，前者支持最大上下文窗口200k，后者能支持长达1M。

对其他领域不太了解，拿编程来说，当你上下文达到1M，前期任务对话的注意力已经被稀释了，200k的上下文超出后，在经过多次compact后，早期内容也会被截断，而且还会有幻觉累计的风险，长会话中如果某个错误理解没被纠正，后续会在错误基础上叠加；再者，一个会话只能做一件事，无法并行（当然，并不是说短会话就可以并行，还得看你的项目是否足够模块化，各层之间边界是否清晰），可见一直在一个会话中对话的性价比并不高。那是不是应该一个任务开一个会话呢，当然也不是，这种做法很容易想到的一点就是，重复喂上下文，每次都要重新解释项目背景、架构、约定...，效率极低，而且缺乏连贯性，模型不知道之前做了哪些决策，容易走回头路甚至错路。

可参考方案

核心思路是：用文件代替会话记忆，上下文存在于代码库本身，而不是对话历史里

维护好 CLAUDE.md

众所周知，cc有一个很核心的文件 —— CLAUDE.MD，你在项目根目录下进入cc，执行/init，大模型就会读取项目内容自动创建这个文件

如果你的项目已经有框架了，那么直接让大模型生成会比较省事，如果是新项目，则需要你手动编写好背景、架构、约束等

这个文件不仅是一个项目说明，更是一个项目记忆文件，cc每次启动都会读取它，建议 每完成一个阶段任务就更新这个文件，新会话一开始就有完整上下文，这一步也可以让大模型来帮你做，不过还是建议 review 一下

按"工作单元"切割会话，而不是按功能

不是"每个功能开一个会话"，而是一个聚焦的任务开一个会话：

✅ 好的会话边界
- "实现订单创建的 API + service + 数据库 migration"
- "修复购物车计算逻辑的 3 个 bug"
- "重构用户模块，拆分成更小的 service"

❌ 不好的边界  
- "帮我开发整个电商后台"（太大）
- "改一行代码"（太小，不值得切换）

第一个 prompt 规范好边界

新会话开头不要直接说"帮我写XXX"，而是：

背景：我在开发电商项目（Next.js + PostgreSQL），CLAUDE.md 里有架构细节。
当前任务：实现订单状态流转逻辑（待付款→已付款→已发货→已完成）
相关文件：/app/api/orders/, /lib/services/orderService.ts
约束：状态流转需要记录操作日志，不能直接改 status 字段

利用 /clear 而不是开新窗口

当一个任务完成、要切换到另一个任务时，在同一个 Claude Code 实例里用 /clear 清空对话历史，项目文件仍然在，只清掉对话噪音，比重开一个会话更高效。

总结

核心其实就是一句话，上下文应该活在代码和文档里，而不是活在对话历史里。

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://bambooo.top/posts/fiddle/record_llm

览毕，何不一言？

以下为 Shiro 闭源版本 Yohaku 部署方案，可能随着版本更新而不再适用

安装 1Panel

curl -sSL https://resource.fit2cloud.com/1panel/package/quick_start.sh -o quick_start.sh && sudo bash quick_start.sh

配置镜像输入 y（安装openresty需要），其他一律 enter 即可

安装完成后，打开1panel网址，进入应用商店，安装openresty

后端部署

正常需要安装 docker，不过由于 1Panel 面板默认会安装 docker，所以这里不需要，如果使用宝塔面板或其他方式，请自行安装docker

拉取并修改配置文件

#回到根目录并创建mx-space/core的文件夹，并跳转至core文件夹下
cd && mkdir -p mx-space/core && cd $_ 
# 拉取 docker-compose.yml 文件
wget https://fastly.jsdelivr.net/gh/mx-space/core@master/docker-compose.yml

主要修改ALLOWED_origins和JWT_SECRET

# Shared env block — mx-migrate boots a full Nest context (it now runs the
# combined schema + app-data migration phases), so it must receive the same
# config the runtime app needs (Redis, snowflake worker id, jwt secret, …).
x-mx-env: &mx-env
  TZ: Asia/Shanghai
  NODE_ENV: production
  REDIS_HOST: redis
  PG_HOST: postgres
  PG_PORT: "5432"
  PG_USER: mx
  PG_PASSWORD: mx
  PG_DATABASE: mx_core
  SNOWFLAKE_WORKER_ID: "1"
  ALLOWED_ORIGINS: bambooo.top,localhost:*,127.0.0.1:*
  JWT_SECRET: xxxxxxxx

services:
  app:
    container_name: mx-server
    image: innei/mx-server:latest
    environment: *mx-env
    volumes:
      - ./data/mx-space:/root/.mx-space
    ports:
      - '2333:2333'
    depends_on:
      mx-migrate:
        condition: service_completed_successfully
      redis:
        condition: service_started
    networks:
      - mx-space
    restart: unless-stopped
    healthcheck:
      test: [CMD, curl, -f, 'http://127.0.0.1:2333/api/v3/health']
      interval: 1m30s
      timeout: 30s
      retries: 5
      start_period: 30s

  # One-shot release-phase migration runner. Runs schema migrations (drizzle)
  # then app-data migrations (Nest-bootstrapped registry). Exits 0; the `app`
  # service waits for completion via `service_completed_successfully` before
  # starting. See docs/superpowers/specs/2026-05-05-database-migration-release-phase-design.md.
  mx-migrate:
    container_name: mx-migrate
    image: innei/mx-server:latest
    command: ['node', 'migrate.mjs']
    environment: *mx-env
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_started
    networks:
      - mx-space
    restart: 'no'

  postgres:
    container_name: postgres
    image: postgres:16-alpine
    environment:
      - POSTGRES_USER=mx
      - POSTGRES_PASSWORD=mx
      - POSTGRES_DB=mx_core
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U mx -d mx_core']
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 10s
    networks:
      - mx-space
    restart: unless-stopped

  redis:
    image: redis:alpine
    container_name: redis
    volumes:
      - ./data/redis:/data
    healthcheck:
      test: [CMD-SHELL, 'redis-cli ping | grep PONG']
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 3s
    networks:
      - mx-space
    restart: unless-stopped

networks:
  mx-space:
    driver: bridge

启动 core

docker compose up -d

这里需要几分钟时间，耐心等待

网站创建

以下步骤均在 1Panel 中进行

证书申请

先创建Acme账户，账号类型建议选ZeroSSL，省事

创建完后申请证书 → 填写主域名 → Acme账户 → 秘钥算法（EC 256） → 验证方式（HTTP） → 自动续签 → 确认

创建网站

创建 → 静态网站 → 监听IPV6 → 配置 → HTTPS（开启，选择刚才的证书） → 配置文件（将下面内容插入到中间）

我是单域名配置，如果你是双域名，参考官方文档

双域名配置

# WebSocket 地址
location /socket.io {
    proxy_set_header Upgrade $http_upgrade; 
    proxy_set_header Connection "Upgrade"; 
    proxy_buffering off; 
    proxy_set_header Host $host; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    proxy_set_header X-Forwarded-Proto $scheme; 
    proxy_pass http://127.0.0.1:2333/socket.io; 
}
# API 地址
location /api/v3 {
    proxy_pass http://127.0.0.1:2333/api/v3; 
}
# 简读 render 地址
location /render {
    proxy_pass http://127.0.0.1:2333/render; 
}
# Shiro 地址
location / {
    proxy_pass http://127.0.0.1:2323; 
}
# 后台地址
location /proxy {
    proxy_pass http://127.0.0.1:2333/proxy; 
}
location /qaqdmin { #如果需要修改自己的后台地址可以改这里
    proxy_pass http://127.0.0.1:2333/proxy/qaqdmin; 
}

修改完毕，点击保存并重载

访问 https://你的域名/qaqdmin 就可以正常进入博客后台（如果碰到问题也不要急，可以在评论区留下你的问题，或许可以给你提供一些帮助），然后就是简单的填写博客基本信息

前端部署

这一步中间可能会出现各种错误，建议在服务器上安装 Claude Code，让大模型帮你分析排查问题，一般都能解决

我采用的是 Innei 提供的自动部署工作流方式

Fork

yohaku-deploy-action

打开github，fork上面的仓库

设置 Secrets

打开仓库，进入 Settings → Secrets and variables → Actions → Repository secrets → 挨个添加下面的参数

• HOST 服务器地址
• USER 服务器用户名
• PASSWORD 服务器密码
• PORT 服务器 SSH 端口
• KEY 服务器 SSH Key（可选，密码 key 二选一）
• GH_PAT 可访问之前 repository 内填写仓库的 Github Token

配置 .env

在服务器 root 下创建 yohaku 文件夹，并在其下创建 .env

cd root/
mkdir yohaku
cd yohaku/
touch .env
vim .env

填写以下内容

BASE_URL=

NEXT_PUBLIC_API_URL=
NEXT_PUBLIC_CLIENT_API_URL=
NEXT_PUBLIC_GATEWAY_URL=

NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=
CLERK_SECRET_KEY=

NEXT_PUBLIC_CLERK_SIGN_IN_URL=/sign-in
NEXT_PUBLIC_CLERK_SIGN_UP_URL=/sign-up
NEXT_PUBLIC_CLERK_AFTER_SIGN_IN_URL=/
NEXT_PUBLIC_CLERK_AFTER_SIGN_UP_URL=/

TMDB_API_KEY=

GH_TOKEN=
API_URL=

修改 deploy

打开 .github/workflows/deploy.yml 进行修改

name: Build and Deploy

on:
  push:
    branches:
      - main
  # schedule:
  #   - cron: '0 3 * * *'

  repository_dispatch:
    types: [trigger-workflow]

permissions: write-all
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

env:
  HASH_FILE: build_hash
  SOURCE_REPO: innei-dev/Yohaku
  BUILD_COMMAND: pnpm --filter @yohaku/web build:ci
  STANDALONE_SUBPATH: standalone/apps/web

jobs:
  prepare:
    name: Prepare
    runs-on: ubuntu-latest
    if: ${{ github.event.head_commit.message != 'Update hash file' }}

    outputs:
      hash_content: ${{ steps.read_hash.outputs.hash_content }}

    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Read HASH_FILE content
        id: read_hash
        run: |
          content=$(cat ${{ env.HASH_FILE }}) || true
          echo "hash_content=$content" >> "$GITHUB_OUTPUT"
  check:
    name: Check Should Rebuild
    runs-on: ubuntu-latest
    needs: prepare
    outputs:
      canceled: ${{ steps.use_content.outputs.canceled }}

    steps:
      - uses: actions/checkout@v4
        with:
          repository: innei-dev/Yohaku
          token: ${{ secrets.GH_PAT }} # `GH_PAT` is a secret that contains your PAT
          fetch-depth: 0
          lfs: true
          submodules: recursive

      - name: Use content from prev job and compare
        id: use_content
        env:
          FILE_HASH: ${{ needs.prepare.outputs.hash_content }}
        run: |
          file_hash=$FILE_HASH
          current_hash=$(git rev-parse --short HEAD)
          echo "File Hash: $file_hash"
          echo "Current Git Hash: $current_hash"
          if [ "$file_hash" == "$current_hash" ]; then
            echo "Hashes match. Stopping workflow."
            echo "canceled=true" >> $GITHUB_OUTPUT
          else
            echo "Hashes do not match. Continuing workflow."
          fi

  build:
    name: Build artifact
    runs-on: ubuntu-latest
    needs: check
    if: ${{needs.check.outputs.canceled != 'true'}}

    strategy:
      matrix:
        node-version: [lts/*]
    outputs:
      sha_short: ${{ steps.store.outputs.sha_short }}
      branch: ${{ steps.store.outputs.branch }}
    steps:
      - uses: actions/checkout@v4
        with:
          repository: ${{ env.SOURCE_REPO }}
          token: ${{ secrets.GH_PAT }} # `GH_PAT` is a secret that contains your PAT
          fetch-depth: 0
          lfs: true
          submodules: recursive

      - name: Checkout LFS objects
        run: git lfs checkout
      - uses: pnpm/action-setup@v2

      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'pnpm'
      - uses: jongwooo/next-cache@v1
      - name: Install dependencies
        run: pnpm install
      - name: Build project
        env:
          BASE_URL: ${{ secrets.BASE_URL }}
          NEXT_PUBLIC_API_URL: ${{ secrets.NEXT_PUBLIC_API_URL }}
          NEXT_PUBLIC_GATEWAY_URL: ${{ secrets.NEXT_PUBLIC_GATEWAY_URL }}
        run: |
          ${{ env.BUILD_COMMAND }}
          cd apps/web/.next
          rm -rf cache
          cp -r ../public ./standalone/public
          mv ./static ./standalone/apps/web/.next/static
          cd ./standalone
          echo ';process.title = "Yohaku (NextJS)"' >> server.js
          cd "$GITHUB_WORKSPACE"
          mkdir -p assets
          rm -f assets/release.zip
          (cd apps/web/.next && zip --symlinks -r "$GITHUB_WORKSPACE/assets/release.zip" ./* -x "dev/*" -x "cache/*")

      # - uses: actions/upload-artifact@v4
      #   with:
      #     name: dist
      #     path: assets/release.zip
      #     retention-days: 7
      - name: Cache Build Artifacts
        id: cache-primes
        uses: actions/cache/save@v4
        with:
          path: assets
          key: ${{ github.run_number }}-release

      - name: Store artifact commit version
        shell: bash
        id: store
        run: |
          sha_short=$(git rev-parse --short HEAD)
          branch_name=$(git rev-parse --abbrev-ref HEAD)
          echo "sha_short=$sha_short" >> "$GITHUB_OUTPUT"
          echo "branch=$branch_name" >> "$GITHUB_OUTPUT"

  deploy:
    name: Deploy artifact
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v4
      
      - uses: actions/cache/restore@v4
        with:
          path: assets
          key: ${{ github.run_number }}-release

      - name: Restore cached Build Artifacts
        id: cache-primes-restore
        uses: actions/cache/restore@v4
        with:
          path: |
            assets
          key: ${{ github.run_number }}-release
      - name: Move assets to root
        run: mv assets/release.zip release.zip

      - name: Prepare standalone PM2 config
        run: cp pm2/ecosystem.config.js ecosystem.config.js

      - name: copy file via ssh password
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          password: ${{ secrets.PASSWORD }}
          key: ${{ secrets.KEY }}
          port: ${{ secrets.PORT }}
          source: 'release.zip'
          target: '/tmp/yohaku'

      - name: copy PM2 config via ssh password
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          password: ${{ secrets.PASSWORD }}
          key: ${{ secrets.KEY }}
          port: ${{ secrets.PORT }}
          source: 'ecosystem.config.js'
          target: '/tmp/yohaku'

      - name: Exec deploy script with SSH
        uses: appleboy/ssh-action@master

        with:
          command_timeout: 5m
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          password: ${{ secrets.PASSWORD }}
          key: ${{ secrets.KEY }}
          port: ${{ secrets.PORT }}
          script: |
            set -e
            source $HOME/.bashrc
            basedir=$HOME/yohaku
            workdir=$basedir/${{ github.run_number }}
            mkdir -p $workdir
            mkdir -p $basedir/.cache
            mv /tmp/yohaku/release.zip $workdir/release.zip
            install -m 644 /tmp/yohaku/ecosystem.config.js $basedir/ecosystem.config.js
            cd $workdir
            unzip -qq -o $workdir/release.zip
            rm -r /tmp/yohaku
            rm -rf $workdir/${{ env.STANDALONE_SUBPATH }}/.env
            ln -s $HOME/yohaku/.env $workdir/${{ env.STANDALONE_SUBPATH }}/.env
            export NEXT_SHARP_PATH=$(npm root -g)/sharp
            # https://github.com/Unitech/pm2/issues/3054
            # symlink workdir node entry file to basedir
            ln -sf $workdir/${{ env.STANDALONE_SUBPATH }}/server.js $basedir/server.js
            mkdir -p $workdir/${{ env.STANDALONE_SUBPATH }}/.next
            rm -rf $workdir/${{ env.STANDALONE_SUBPATH }}/.next/cache
            ln -sf $basedir/.cache $workdir/${{ env.STANDALONE_SUBPATH }}/.next/cache
            cd $basedir
            if pm2 describe Yohaku >/dev/null 2>&1; then
              pm2 reload ecosystem.config.js --update-env
            else
              pm2 start ecosystem.config.js --update-env
            fi
            rm $workdir/release.zip
            pm2 save
            echo "Deployed successfully"

      - name: After deploy script
        run: |
          hash=${{ needs.build.outputs.sha_short }}
          # curl -X "POST" "https://mx.innei.in/api/v2/fn/shiro/new-version-hook" -H 'Content-Type: application/json' -d "{\"hash\": \"$hash\", \"key\": \"\"}"
          ${{ secrets.AFTER_DEPLOY_SCRIPT }}
  store:
    name: Store artifact commit version
    runs-on: ubuntu-latest
    needs: [deploy, build]
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal token
          fetch-depth: 0 # otherwise, you will failed to push refs to dest repo
      # Get the commit version from the build job
      - name: Use outputs from build
        env:
          SHA_SHORT: ${{ needs.build.outputs.sha_short }}
          BRANCH: ${{ needs.build.outputs.branch }}
        run: |
          echo "SHA Short from build: $SHA_SHORT"
          echo "Branch from build: $BRANCH"
      - name: Write hash to file
        env:
          SHA_SHORT: ${{ needs.build.outputs.sha_short }}

        run: echo $SHA_SHORT > ${{ env.HASH_FILE }}
      - name: Commit files
        run: |
          git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git config --local user.name "github-actions[bot]"
          git add ${{ env.HASH_FILE }}
          git commit -a -m "Update hash file"
      - name: Push changes
        uses: ad-m/github-push-action@master
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          branch: ${{ github.ref }}

如果直接使用 Innei 的部署过程中出现报错，可以参考我的进行修改，或者询问大模型，github自带的 Copilot 也挺好用的

改完之后 commit，会自动跑，可以进入Actions查看流程

配置云函数

进入博客后台，附加功能 → 配置与云函数

创建一条 theme 引用、名称为 shiro 的配置项（数据类型 JSON 或 YAML），这里贴上官方提供的案例

{
  "footer": {
    "otherInfo": {
      "date": "2020-{{now}}",
      "icp": {
        "text": "萌 ICP 备 20236136 号",
        "link": "https://icp.gov.moe/?keyword=20236136"
      }
    },
    "linkSections": [
      {
        "name": "关于",
        "links": [
          { "name": "关于本站", "href": "/about-site" },
          { "name": "关于我", "href": "/about" },
          {
            "name": "关于此项目",
            "href": "https://github.com/Innei/Yohaku",
            "external": true
          }
        ]
      },
      {
        "name": "更多",
        "links": [
          { "name": "时间线", "href": "/timeline" },
          { "name": "友链", "href": "/friends" }
        ]
      },
      {
        "name": "联系",
        "links": [
          { "name": "写留言", "href": "/message" },
          { "name": "GitHub", "href": "https://github.com/innei", "external": true }
        ]
      }
    ]
  },
  "config": {
    "color": {
      "light": ["#33A6B8", "#FF6666", "#26A69A", "#fb7287", "#69a6cc"],
      "dark": ["#F596AA", "#A0A7D4", "#ff7b7b", "#99D8CF", "#838BC6"]
    },
    "site": {
      "favicon": "/favicon.svg",
      "faviconDark": "/favicon-dark.svg"
    },
    "hero": {
      "title": {
        "template": [
          {
            "type": "span",
            "text": "Hi, I'm ",
            "style": { "fontWeight": 300, "opacity": 0.85 }
          },
          {
            "type": "span",
            "text": "Innei",
            "style": {
              "fontWeight": 500,
              "color": "var(--color-accent)",
              "letterSpacing": "-0.02em"
            }
          },
          {
            "type": "span",
            "text": " 👋",
            "style": {
              "fontWeight": 300,
              "display": "inline-block",
              "transform": "rotate(-8deg)"
            }
          },
          { "type": "br" },
          {
            "type": "span",
            "text": "A NodeJS Full Stack ",
            "style": { "fontWeight": 300, "opacity": 0.8 }
          },
          {
            "type": "code",
            "text": "<Developer />",
            "style": {
              "display": "inline-block",
              "fontFamily": "var(--font-mono)",
              "fontSize": "0.72em",
              "fontWeight": 500,
              "padding": "0.25em 0.55em",
              "borderRadius": "0.35em",
              "backgroundColor": "color-mix(in srgb, var(--color-accent) 10%, transparent)",
              "color": "var(--color-accent)",
              "border": "1px solid color-mix(in srgb, var(--color-accent) 22%, transparent)"
            }
          },
          {
            "type": "span",
            "style": {
              "display": "inline-block",
              "width": "2px",
              "height": "0.9em",
              "backgroundColor": "var(--color-accent)",
              "marginLeft": "2px",
              "animation": "blink 1.2s linear infinite"
            }
          }
        ]
      },
      "description": "An independent developer coding with love."
    },
    "module": {
      "activity": {
        "enable": true,
        "endpoint": "/fn/ps/update"
      },
      "donate": {
        "enable": false,
        "link": "",
        "qrcode": []
      },
      "bilibili": {
        "liveId": 0
      },
      "openpanel": {
        "enable": false,
        "id": "",
        "url": ""
      },
      "posts": {
        "mode": "loose"
      },
      "signature": {
        "svg": "",
        "animated": true
      }
    }
  }
}

修改好后保存

都完成后，访问前端，没问题的话，恭喜你部署成功

TLDR

mx-space 支持博主点击头像右下角发布个人状态

官方功能描述如下：

个人状态展示

但是按照官方提供方法配置完后，发布状态时肯定会失败，控制台报错大致是：

95900-30e790acc8113b00.js:1
   GET https://bambooo.top/api/v3/fn/shiro/status?lang=zh 404 (Not Found)

也就是找不到 status 这个函数

修复方法

云函数复制我的粘贴过去保存

interface Status {
    emoji: string
    icon?: string
    desc?: string
    ttl: number
    untilAt: number
  }

  function assetAuth(ctx: Context) {
    const body = ctx.req.body
    const authKey = ctx.secret.key
    if (ctx.isAuthenticated) return
    if (body.key !== authKey) {
      throw new Error('Unauthorized')
    }
  }

  export default async function handler(ctx: Context) {
    const method = ctx.req.method.toLowerCase()

    switch (method) {
      case 'get': {
        return GET(ctx)
      }
      case 'post': {
        assetAuth(ctx)
        return POST(ctx)
      }
      case 'delete': {
        assetAuth(ctx)
        return DELETE(ctx)
      }
      case 'options': {
        return null
      }
      default: {
        throw new Error('Method Not Allowed')
      }
    }
  }

  const cacheKey = 'shiro:status'

  async function DELETE(ctx: Context) {
    await ctx.storage.cache.del(cacheKey)
    ctx.broadcast('shiro#status', null)
  }

  async function POST(ctx: Context) {
    const body = ctx.req.body

    const { emoji, icon, desc } = body as Status
    const ttl = body.ttl || 86400

    const status = {
      emoji,
      icon,
      desc,
      ttl,
      untilAt: Date.now() + ttl * 1000,
    } as Status
    await ctx.storage.cache.set(cacheKey, JSON.stringify(status), ttl)
    ctx.broadcast('shiro#status', status)
    return null
  }

  async function GET(ctx: Context) {
    const status = await ctx.storage.cache.get(cacheKey)
    return status
  }

大模型（LLM）支持的“上下文长度（Context Length / Context Window）”本质上是模型一次能够“看到”和“记住”的 token 数量。它由多个因素共同决定：

1. Transformer 架构本身

绝大多数大模型基于 Transformer。

Transformer 的核心是 Attention：

\mathrm{Attention}(Q,K,V)=\mathrm{softmax}\left(\frac{QK^T}{\sqrt{d}}\right)V

这里的问题在于：

• 每个 token 都要和之前所有 token 做 attention
• 序列越长，计算量越大
• 显存占用增长极快

经典 Attention 的复杂度：

O(n^2)

其中：

• ( n ) = 上下文 token 数量

这意味着：

所以最根本的限制来自：

• Attention 计算量
• Attention 显存消耗

([Hugging Face][1])

2. Position Encoding（位置编码）

模型不仅要知道“词是什么”，还要知道“词在第几个位置”。

上下文长度很大程度取决于：

• Position Embedding 的设计
• 是否支持长距离位置泛化

早期：绝对位置编码

比如 GPT-2：

• 训练时只支持 2048
• 超过直接崩

因为位置 embedding 表是固定大小。

后来：RoPE（旋转位置编码）

现在主流模型：

• Llama
• Qwen
• DeepSeek
• Mistral

基本都用 RoPE。

RoPE 可以更容易扩展上下文。([Reddit][2])

为什么 RoPE 还能继续扩？

因为它不是：

“第 100 个 token 用第 100 个 embedding”

而是：

“通过旋转角度表达相对位置关系”。

所以：

• 可以做插值（Position Interpolation）
• 可以做 RoPE Scaling
• 可以 NTK-aware scaling

这也是为什么很多模型：

• 训练时 8K
• 推理时能魔改到 32K / 128K

3. 训练数据长度

这是一个经常被忽视但很关键的问题。

模型不是“理论支持 128K”就真懂 128K。

如果训练时：

• 大部分样本只有 2K
• 很少出现长文档

那么：

即使技术上塞进去 128K， 模型也会：

• 注意力退化
• 遗忘前文
• 中间内容丢失
• 出现 “Lost in the Middle”

所以：

真正有效的上下文长度 ≠ 宣称的上下文长度

4. KV Cache（最核心的工程瓶颈）

推理时最重要的是 KV Cache。

Transformer 会缓存：

• Key
• Value

避免每次重新计算历史 token。([Hugging Face][1])

KV Cache 大小基本和：

• context length
• layer 数
• head 数
• hidden size

线性相关。

大致公式：

\mathrm{KV\ Cache}\propto L\times H\times D\times T

其中：

• (L)：层数
• (H)：注意力头数
• (D)：head dimension
• (T)：context length

为什么长上下文特别吃显存？

因为：

上下文每增加一个 token：

• 每一层都要多存 KV
• 所有历史 token 都要保留

KV Cache 会线性爆炸。([LLMHardware.io][3])

例如：

所以很多时候：

限制长上下文的不是模型，而是显存。

5. 推理框架优化

现代框架会做很多优化：

FlashAttention

降低 Attention 显存占用。

PagedAttention（vLLM）

像虚拟内存一样管理 KV Cache。

GQA / MQA

减少 KV Head 数量。

比如：

• Multi-Head Attention：每个头都存 KV
• Grouped Query Attention：多个 Query 共用 KV

能显著降低长上下文成本。([InsiderLLM][4])

6. 模型训练方式

长上下文模型通常会专门训练：

• Long context finetune
• YaRN
• NTK scaling
• Position interpolation
• LongLoRA

否则模型虽然“能吃进去”，但理解效果会很差。

7. 理论上还有更深层限制

目前 Transformer 长上下文仍有根本问题：

• 信息稀释
• 注意力退化
• 中间遗忘
• Memory bandwidth 瓶颈

甚至学术界现在都在研究：

• KV Cache Compression
• Sparse Attention
• Linear Attention
• State Space Model（Mamba）
• RWKV

因为传统 Transformer 长上下文成本太高。([arXiv][5])

简单总结

大模型上下文长度主要由：

可以把它理解成：

“上下文长度”本质上是： 模型结构 + 位置编码 + 显存容量 + KV Cache 管理 + 长文本训练能力 的综合结果。

参考链接

"Caching · Hugging Face"

I don't understand context window extension"

"KV Cache and VRAM: How Context Length Blows Up Your GPU Memory (2026)"

["KV Cache: Why Context Length Eats Your VRAM (And How to Fix It) | InsiderLLM"](

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://bambooo.top/posts/tech/RL-MDP

览毕，何不一言？

这篇文章目的是方便更通俗、更简单的理解KL散度，所以会尽可能减少公式推导，更多的阐述KL的理论知识和应用。

介绍

KL散度（Kullback–Leibler Divergence），通常简称 KL Divergence，中文叫：

• 相对熵
• KL距离（严格来说它不是“距离”）
• K-L散度

它是信息论中的核心概念之一，用来衡量：

“一个概率分布，相对于另一个概率分布，损失了多少信息。”

或者更直观一点：

“如果真实世界遵循分布 P，但你错误地使用了分布 Q 去描述它，会多付出多少代价。”

直观理解

假设：

• P：真实分布（真实世界）
• Q：你的模型认为的分布（预测世界）

KL散度衡量：

“Q 对 P 的描述到底有多差。”

一个简单例子：

假设真实分布 P：

而你的模型 Q：

那么：

• 真实世界里几乎总是“猫”
• 但你的模型认为“猫狗一样多”

于是：

• 你的预测浪费了大量信息
• 编码效率下降
• 模型认知错误

KL散度会很大。

如果模型 Q：

那么：

• Q 很接近 P
• KL散度就很小

KL散度的本质：信息损失

KL散度来自信息论。

信息论里有一个核心思想：

概率越小，信息量越大。

比如：

• “太阳明天升起” → 信息量很小
• “明天外星人降临” → 信息量巨大

因为后者概率低。

KL散度本质上衡量：

“你因为使用错误概率模型，而额外浪费的信息量。”

所以：

• KL越小 → 模型越接近真实分布
• KL越大 → 模型偏差越严重

KL散度的重要性质

1. KL ≥ 0

KL散度永远非负：

DKL(P∣∣Q)≥0D_{KL}(P || Q) \ge 0DKL(P∣∣Q)≥0

只有：

P=QP = QP=Q

时才等于 0。

即：

完全一致时，没有信息损失。

2. KL不是对称的

这是最重要性质之一。

一般：

DKL(P∣∣Q)≠DKL(Q∣∣P)D{KL}(P || Q) \neq D{KL}(Q || P)DKL(P∣∣Q)\=DKL(Q∣∣P)

即：

• “Q 用来近似 P”
• 和
• “P 用来近似 Q”

完全不是一回事。

为什么不对称很重要？

因为：

场景1：覆盖真实分布

如果真实分布有多个峰：

• 你漏掉一个峰
• KL惩罚会非常大

这叫：

mode covering（模式覆盖）

场景2：只抓最主要模式

有些任务更关注：

• 最重要概率区域

而不是覆盖所有区域。

于是另一方向KL会有不同效果。

这直接影响：

• VAE
• GAN
• 扩散模型
• 强化学习
• RLHF

中的训练行为。

KL散度的应用

1. 分类任务

例如：

• 图像分类
• NLP分类
• LLM next-token预测

模型输出：

softmax概率分布

真实标签：

one-hot分布

训练目标：

让预测分布接近真实分布

于是使用：

• Cross Entropy
• 本质就是KL优化

举例

真实：

猫 = 1
狗 = 0

模型：

猫 = 0.7
狗 = 0.3

训练会推动：

猫 -> 1
狗 -> 0

即：

例如：

• 图像分类
• NLP分类
• LLM next-token预测

模型输出：

softmax概率分布

真实标签：

one-hot分布

训练目标：

让预测分布接近真实分布

于是使用：

• Cross Entropy
• 本质就是KL优化

举例

真实：

猫 = 1
狗 = 0

模型：

猫 = 0.7
狗 = 0.3

训练会推动：

猫 -> 1
狗 -> 0

即：

$Q \to P$

2. LLM

LLM本质是：

下一个token概率预测器。

例如：

输入：

今天天气真

模型预测：

真实token：

好

训练目标：

• 最大化正确token概率
• 等价于最小化KL散度

3. 知识蒸馏（Distillation）

KL散度经典应用。

Teacher → Student

大模型：

Teacher

小模型：

Student

Teacher输出：

猫:0.7
狗:0.2
狐狸:0.1

Student学习：

尽量模仿Teacher概率分布

这里不能只学：

正确类别

而是要学习：

整个概率结构。

因此使用：

$D_{KL}(Teacher || Student)$

为什么有效？

因为Teacher包含：

• 类别相似性
• 不确定性
• 结构知识

例如：

猫 和 狐狸 有点像

这些信息：

one-hot标签无法表达。

4. RL

PPO中的KL约束

PPO不允许策略突然变化太大。

否则：

• 训练崩溃
• reward hacking
• 模型退化

因此：

新策略必须接近旧策略：

DKL(πnew∣∣πold)D{KL}(\pi{new} || \pi_{old})DKL(πnew∣∣πold)

本质

KL在这里扮演：

“刹车系统”

避免：

• policy collapse
• 梯度爆炸
• 行为突变

5. RLHF

RLHF中：

• 有一个Reference Model
• 一个正在训练的Policy Model

训练时：

不能让模型偏离原模型太远。

因此加入：

KL penalty。

为什么？

否则模型可能：

为了奖励：

• 胡说八道
• 极端输出
• reward hacking

KL约束：

保持语言能力稳定。

RLHF目标本质

不是：

最大化reward

而是：

在不偏离原模型太远情况下提高reward

因此：

KL是核心稳定器。

公式

一、离散分布的KL散度

对于两个离散概率分布：

• $P(x)$：真实分布
• $Q(x)$：近似分布

KL散度定义为：

$D{KL}(P\parallel Q)=\sumx P(x)\log\frac{P(x)}{Q(x)}$

含义解释

公式可以拆成三部分理解：

1. $P(x)$

表示：

真实世界中事件x出现的概率

2. $\frac{P(x)}{Q(x)}$

表示：

真实概率 和 模型概率 的比值

如果：

• Q低估了真实概率
• 比值会很大
• 惩罚会增加

3. $\log \frac{P(x)}{Q(x)}$

表示：

信息量差异

因为信息论里：

• log体现编码长度
• 信息增益
• 熵变化

4. 最外层求和

表示：

对所有可能事件做期望

即：

平均信息损失。

二、连续分布形式

如果是连续概率分布：

例如：

• 高斯分布
• 连续latent space

则KL散度写成积分：

$D_{KL}(P\parallel Q)=\int P(x)\log\frac{P(x)}{Q(x)},dx$

此渲染由 Yohaku API 生成，或存排版之虞，最佳体验请往：https://bambooo.top/notes/4

览毕，何不一言？