凌宇博客

作者： mahanyu0322

  • 少时诵诗书

    fffffffdsfdfdfdfdfdfdfdfdf****

  • 晶核 PC 脚本使用说明

    优先推荐

    先扫码加微信群

    安装、配置、异常处理、更新通知都可以在群里直接交流，新手更容易上手。

    微信群二维码

    脚本为 PC 端。
    晶核懒人福音，解放双手全自动刷图，主打 AI 智能单刷、多账号切换独立设置、纯模拟操作更安全。

    下载 PC 脚本

    新用户赠送 3 天免费体验时长。
    下载后直接打开即可使用，不需要复杂配置。

    高亮提醒

    如果勾选加盾选项，必须先关闭电脑实时防护

    否则可能出现蓝屏。

    操作教程： 如何关闭 Windows 实时防护

    第一次使用先看这两段

    • 必看 1：游戏设置教程
    • 必看 2：鸟币囚笼刷鸟币怎么开

    这两部分直接决定脚本能不能顺利跑起来，建议先看完再下载和配置。

    必看 1：游戏设置教程

    这部分优先级很高。
    游戏设置不对，后面很多识别和点击都会跟着出问题。

    游戏设置教程就看下面这三张图，先按图调整，再开脚本。

    游戏设置1
    游戏设置2
    游戏设置3

    必看 2：鸟币囚笼刷鸟币说明

    这部分优先级很高。
    如果你就是为了刷鸟币来的，先按下面步骤准备。

    使用前提

    • 保证门票充足
    • 角色提前移动到副本入口处
    • 站到能看到 F 交互 的位置再启动脚本
    • 推荐战力 9W+
    • 只要一套技能能稳定带走，不出机制即可

    开启方式

    • 在脚本里勾选 囚笼循环
    • 勾选后会一直刷囚笼，不会执行其他刷图内容
    • 如果你只是日常正常刷图，记得取消 囚笼循环

    你最容易忽略的点

    • 没站到正确入口位置时，脚本可能不会正常进图
    • 门票不足时会直接影响刷图连续性
    • 如果不是专门刷鸟币，就不要一直开囚笼循环
    鸟币囚笼入口示意图

    这款脚本适合谁

    • 上班族，没有时间长期手动刷图
    • 学生党，希望轻松养号、不想重复操作
    • 多账号玩家，需要分账号独立设置参数
    • 偏好稳一点的自动化方式，不想折腾复杂脚本环境

    核心功能全覆盖

    刷图与日常

    • 囚笼循环
    • 全自动刷图，支持深渊暗域、临界深渊、5-5、组合图
    • 自动取票、吃体力、吃双倍、日常清理全程自动
    • 自动分解或出售装备、领取手册、领取福利、舰队签到
    • 商城免费礼包、每日签到、物品扫拍自动完成

    账号与模式

    • 多账号切换，不同账号可独立设置参数，互不干扰
    • 支持前台后台双模式
    • 后台挂机时，电脑仍可正常使用
    • 低配电脑也可运行，操作间隔支持自由调节，减少卡顿

    安全放心使用

    • Python 原生开发，稳定性与安全性优于按键精灵类方案
    • 仅模拟鼠标键盘操作，不修改游戏数据与内存
    • 采用图色扫描加 AI 识别，不侵入游戏进程
    • 支持进程加盾，个人自用风险更低
    • 推荐单刷玩法，减少举报，长期使用更稳定

    重要说明
    本工具只是代替人为操作，不会对游戏数据和内存做任何修改，只是脚本，不是外挂。

    简单好上手

    • 游戏只需做简单设置
    • 亮度保持 50-70
    • 切换为 手游模式
    • 脚本右键选择 以管理员身份运行
    • 没有复杂配置，下载后即可启动
    • 附带完整使用说明，新手也能快速上手

    快速上手流程

    1. 运行游戏并进入角色界面
    2. 进入游戏后打开设置，确认亮度与模式已按要求调整
    3. 右键脚本，以管理员身份运行
    4. 登录后勾选你要执行的功能
    5. 选择刷图地图、角色范围和自动执行内容
    6. 点击开始，脚本会按设定自动运行

    常用功能说明

    执行类型

    • 全部：从角色列表第 1 个开始依次执行
    • 从 X 到 X：只跑指定范围的角色
    • 当前角色：只执行当前已选择角色

    自动执行内容

    • 自动取票：会根据深渊暗域或临界深渊自动从账号仓库取票
    • 自动刷图：勾选后才会执行刷图逻辑
    • 自动清理：按随机顺序执行清理类操作
    • 扫拍：输入目标装备与扫描次数后自动扫描购买

    前台与后台模式

    • 前台模式：正常模拟键盘鼠标，执行期间不能操作电脑
    • 后台模式：脚本运行时可以正常用电脑，但不能最小化游戏窗口
    • 如果后台模式不稳定，建议切回前台模式

    界面预览

    主界面

    脚本主界面1
    脚本主界面2

    刷图配置

    刷图配置界面

    加盾设置

    脚本加盾图片

    单刷说明

    • 推荐尽量单刷，减少组队被举报的概率
    • 单刷时首次进图可能以组队形式进入，后续会在图内重复挑战
    • 如果出现卡图、路径偏移、阶段位置未到达等情况，脚本会尝试自动容错
    • 若容错后退出副本，会重新按流程进入

    使用前请注意

    • 如果你的电脑比较卡，建议把操作间隔调大一些
    • 如果加盾后异常，可以逐项取消勾选，选择最适合自己电脑的方案
    • 如果需要远程控制，不建议勾选窗口盾
    • 如果脚本或游戏多次开关后异常，先去任务管理器清掉残留进程再重启

    常见问题

    1. 脚本无法正常执行怎么办？

    • 检查游戏和脚本是否都已经启动
    • 确认脚本是否以管理员身份运行
    • 检查游戏设置是否正确，特别是手游模式、UI 缩放、亮度
    • 如果有脚本残留进程，先结束任务后再重新打开

    2. 后台模式没反应怎么办？

    • 先重启游戏和脚本
    • 保持游戏窗口处于可见状态，不要最小化
    • 如果依然不稳定，改用前台模式

    3. 取票异常怎么办？

    • 仓库里同一种票尽量只保留一种类型
    • 票要放在账号仓库靠前位置，确保脚本能识别到

    4. 下载后提示文件不被信任怎么办？

    • 先关闭 Windows 实时防护或添加信任
    • 某些安全软件会把脚本运行时产生的临时文件识别成风险项
    • 如果你对这类行为完全不能接受，那就不建议使用这类自动化脚本

    最后一句

    如果你是第一次接触这类脚本，最省时间的方式不是自己硬试，而是先扫码进群。
    群里问一嘴，通常比自己排查半天更快。

  • MCP 发布测试文章

    MCP 发布测试

    这是一篇由 Codex 通过 MCP 创建的测试文章。

    • 发布时间：2026-04-30T18:03:30.512Z
    • 目的：验证 create_post 与远端写入流程

    如果你能在博客中看到这篇文章，说明发布链路工作正常。

  • macOS Web 全栈开发环境安装文档

    适用环境：

    • macOS 26.4.1
    • x86_64
    • 默认 shell 为 zsh
    • 目标环境为 Web 全栈常用完整版

    目标：

    • 安装并启用 Xcode Command Line Tools
    • 安装 Homebrew
    • 配置国内镜像
    • 安装 Node.js LTS、pnpm、uv、独立 Python
    • 安装 VS Code CLI、Docker Desktop
    • 安装并启动 PostgreSQL、Redis

    一键安装命令

    把下面整段复制到终端执行：

    set -e

# 1) 激活 Command Line Tools
sudo xcode-select --switch /Library/Developer/CommandLineTools
xcode-select -p

# 2) 安装 Homebrew（官方脚本，默认 /usr/local）
NONINTERACTIVE=1 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# 3) 写入 shell 初始化
mkdir -p "$HOME/bin" "$HOME/.config/pip"
touch "$HOME/.zprofile" "$HOME/.zshrc"

grep -q 'brew shellenv' "$HOME/.zprofile" || cat >> "$HOME/.zprofile" <<'EOF'
export PATH="$HOME/bin:$PATH"
if [ -x /usr/local/bin/brew ]; then
  eval "$(/usr/local/bin/brew shellenv)"
fi
EOF

grep -q 'NPM_CONFIG_REGISTRY' "$HOME/.zshrc" || cat >> "$HOME/.zshrc" <<'EOF'
export PATH="$HOME/bin:$PATH"
export NPM_CONFIG_REGISTRY="https://registry.npmmirror.com"
export PIP_INDEX_URL="https://pypi.tuna.tsinghua.edu.cn/simple"
export UV_DEFAULT_INDEX="https://pypi.tuna.tsinghua.edu.cn/simple"

if [ -x /usr/local/bin/brew ]; then
  eval "$(/usr/local/bin/brew shellenv)"
fi

if command -v fnm >/dev/null 2>&1; then
  eval "$(fnm env --use-on-cd)"
fi
EOF

cat > "$HOME/.npmrc" <<'EOF'
registry=https://registry.npmmirror.com
EOF

cat > "$HOME/.config/pip/pip.conf" <<'EOF'
[global]
index-url = https://pypi.tuna.tsinghua.edu.cn/simple
EOF

source "$HOME/.zprofile"
source "$HOME/.zshrc"

# 4) 安装 CLI / 运行时 / 数据库
brew update
brew install git wget jq ripgrep fd tree fnm uv python postgresql redis

# 5) Node LTS + pnpm
eval "$(fnm env --use-on-cd)"
fnm install --lts
fnm default lts-latest
fnm use default
corepack enable
corepack prepare pnpm@latest --activate

# 6) 提供 python / pip 入口（避免依赖系统 Python）
ln -sf "$(brew --prefix)/bin/python3" "$HOME/bin/python"
ln -sf "$(brew --prefix)/bin/pip3" "$HOME/bin/pip"

# 7) VS Code CLI
if [ ! -d "/Applications/Visual Studio Code.app" ]; then
  brew install --cask visual-studio-code
fi
ln -sf "/Applications/Visual Studio Code.app/Contents/Resources/app/bin/code" "$HOME/bin/code"

# 8) Docker Desktop
if [ ! -d "/Applications/Docker.app" ]; then
  brew install --cask docker
fi
open -a Docker

# 9) 启动本地数据库服务
brew services start postgresql
brew services start redis

# 10) 验收
brew doctor
git --version
fnm --version
node -v
pnpm -v
uv --version
python --version
pip --version
code --version
psql --version
redis-cli ping
brew services list

echo
echo "Docker Desktop 正在启动。等桌面端完全起来后，再手动跑这两条："
echo "docker version"
echo "docker compose version"

    安装说明

    • sudo xcode-select --switch ... 会要求输入 macOS 管理员密码，这是正常现象。
    • open -a Docker 只负责打开 Docker Desktop，真正就绪通常还需要几十秒。
    • 这份方案默认使用国内镜像：
      • npm/pnpm：https://registry.npmmirror.com
      • pip/uv：清华 PyPI 镜像

    安装完成后建议复核

    在 Docker Desktop 完全启动后，再运行：

    docker version
docker compose version

    如果要把结果发给我继续验收，优先提供下面几组输出：

    brew doctor
node -v && pnpm -v
uv --version && python --version
docker version && docker compose version
brew services list
redis-cli ping

  • Codex API 登录后，能从 GitHub 安装插件吗？

    最近在使用 Codex CLI 时，遇到一个很常见的问题：如果我是用 API key 登录，而不是用 OpenAI 或 ChatGPT 账号登录，还能不能安装插件？

    结论先说：

    • 可以用 API key 登录 Codex。
    • 也可以从 GitHub 添加 marketplace。
    • 但某些依赖远程同步或官方认证链路的插件，不一定支持纯 API key。

    先区分三件事

    这个问题容易混淆，是因为它其实包含三层不同的能力：

    1. Codex 本体怎么登录
    2. 插件 marketplace 从哪里安装
    3. 某个插件本身是否依赖远程认证

    它们不是一回事。

    API key 登录是支持的

    从 CLI 帮助可以直接看到，Codex 支持用 API key 登录，例如：

    printenv OPENAI_API_KEY | codex login --with-api-key

    本地登录状态也会显示类似：

    Logged in using an API key

    所以，API key 登录本身不是问题。

    GitHub marketplace 安装也是支持的

    Codex 的插件 marketplace 支持直接从 GitHub 仓库添加，不一定非要走“官方远程插件商店”那条路径。

    命令帮助里写得很明确，codex plugin marketplace add 支持这些来源：

    • owner/repo[@ref]
    • HTTP(S) Git URLs
    • SSH URLs
    • local marketplace root directories

    例如：

    codex plugin marketplace add owner/repo

    如果需要指定分支或 tag：

    codex plugin marketplace add owner/repo@main

    或者：

    codex plugin marketplace add https://github.com/owner/repo.git --ref main

    这意味着，只要对方仓库本身是合法的 Codex marketplace 结构，就可以直接加。

    真正的限制通常在“远程插件同步”

    问题往往不在“能不能安装”，而在“某些插件是否能通过远程插件系统启用或同步”。

    根据社区问题和实际日志，某些 remote plugin 流程会要求 ChatGPT 或 OpenAI 身份认证，而不是单纯的 API key。也就是说：

    • API key 适合跑模型调用
    • 但 remote plugin sync 可能要求另一套认证体系

    这也是为什么很多人会遇到一种看起来很奇怪的现象：

    • Codex 能正常对话
    • API key 也有效
    • 但插件安装或同步时报认证错误

    本质上并不是模型不能用，而是插件链路的认证要求更严格。

    更稳妥的做法

    如果你当前主要是想装 GitHub 上的插件，最稳的方案通常是：

    优先使用 GitHub marketplace 或本地 marketplace，而不是依赖 remote plugin sync。

    这样做有几个好处：

    • 对现有登录方式影响最小
    • 不容易被“必须 OpenAI auth”卡住
    • 配置更透明，更容易排查问题

    一个容易忽略的配置项

    如果你在 ~/.codex/config.toml 里使用了自定义 provider，同时还写了类似下面的配置：

    requires_openai_auth = true

    那就要格外小心。

    如果你实际接的是第三方 OpenAI-compatible 接口，而不是官方 OpenAI 身份体系，这项配置可能会把某些能力引向“需要官方认证”的路径，从而增加插件相关报错的概率。

    这不一定意味着必须立刻修改，但至少值得检查。

    如果 GitHub 拉取失败

    有些网络环境下，访问 GitHub 需要代理。可以先在当前终端会话里设置：

    export http_proxy=http://127.0.0.1:6478
export https_proxy=http://127.0.0.1:6478

    如果你走的是 SOCKS5，则可以改成：

    export all_proxy=socks5://127.0.0.1:6478

    再执行 marketplace 添加命令。

    一句话总结

    如果你问的是“Codex 用 API 登录后，能不能从 GitHub 安装插件”，答案是：

    可以，通常可以直接从 GitHub 添加 marketplace。

    如果你问的是“为什么插件还是报认证错误”，答案通常是：

    报错点不在 API key 本身，而在 remote plugin 或某个插件自己的认证要求。

    排查这类问题时，先把“登录模型”和“插件同步”分开看，往往会快很多。

  • 用 Codex 连接 Blender MCP：从安装到做一辆儿童玩具小巴士

    这篇文章记录一次完整的实操：在 macOS 上安装 Blender 和 blender-mcp，把它接进 Codex，然后直接在 Blender 里做出一辆圆润卡通风格的儿童玩具小巴士。

    目标

    这次不是停留在“装好就算完”，而是希望把整条链路跑通：

    1. 安装 uv 和 blender-mcp
    2. 配置 Codex 的 MCP server
    3. 安装 Blender 插件 addon.py
    4. 验证 Codex 能真实读取和操作 Blender 场景
    5. 基于自然语言，做出一个简单可爱的玩具小汽车模型

    环境

    • macOS
    • Blender 4.5.4 LTS
    • uv 0.11.8
    • Codex 本地 MCP 配置
    • 博客本身通过 astro-blog-ssh MCP 发布

    第一步：安装 Blender MCP

    blender-mcp 的结构其实很直接：

    • 一部分是 Blender 里的插件 addon.py
    • 一部分是本地 MCP server，由 uvx blender-mcp 启动

    在这台机器上，最终采用的是下面这套方式：

    1. 安装 uv

    把 uv 安装到用户目录下的 ~/bin，避免改系统环境。

    2. 在 Codex 里注册 Blender MCP

    注册成一个全局 MCP server，命令是：

    uvx blender-mcp

    同时额外加了：

    DISABLE_TELEMETRY=true

    3. 下载并安装 Blender 插件

    从仓库下载 addon.py，再安装到 Blender 用户插件目录。最终插件实际位于 Blender 的用户脚本目录里。

    第二步：安装 Blender 本体

    这台机器一开始并没有 Blender，所以后面直接走了官方 DMG：

    • 下载 Blender 官方 macOS Intel 版本
    • 安装到 ~/Applications/Blender.app
    • 用 Blender CLI 验证版本号，确认是 Blender 4.5.4 LTS

    这样做的好处是不用碰系统级 /Applications 权限，整个安装对现有环境影响更小。

    第三步：遇到的第一个坑

    表面上看，插件已经安装并启用了，但 Blender 侧栏里一开始没有看到 BlenderMCP 面板。

    排查后确认了几件事：

    • 插件模块已经被 Blender 识别
    • 插件已经启用
    • 面板类已经正确注册到 VIEW_3D > UI > BlenderMCP

    根因不是“没装上”，而是 Blender 界面和验证方式的问题。

    第四步：真正的连通问题

    更关键的问题出现在 MCP 调用阶段。

    最开始为了方便验证，尝试让 Blender 用 --background 模式启动，再自动拉起 blendermcp 服务。这个方式虽然能把 9876 端口打开，但真实请求会一直超时。

    后来定位到原因：

    blender-mcp 内部依赖 Blender 主线程上的 bpy.app.timers 来执行请求，而后台模式不会正常处理这类回调，所以会出现：

    • 端口能通
    • socket 能连上
    • 但真实命令没有响应

    这个点很关键。

    最后换成真正的 GUI Blender 实例启动，并自动执行插件的 start_server 操作之后，链路才真正打通。

    第五步：验证 Codex 可以直接控制 Blender

    连通后，先做了最基础的一次读取：

    • 获取当前场景信息
    • 返回了默认场景里的 Cube、Light、Camera

    接着做了第一个真正的操作：

    创建一个球体

    直接通过 Blender MCP 执行代码，在默认立方体上方创建一个球体：

    • 名称：Sphere
    • 位置：(0, 0, 2)

    这一步的意义不在于球体本身，而在于确认：

    • 命令确实执行到了 Blender
    • 场景读取结果能反映刚刚的变化

    做到这里，才算是真的“可以直接控制了”。

    第六步：做一辆儿童玩具小巴士

    接下来开始用自然语言一步步建一个玩具风模型。

    用户最终定下来的方向是：

    • 风格：圆润卡通
    • 类型：小巴士 / 面包车
    • 主色：蓝白色

    建模策略

    没有追求写实，而是走“基础几何体 + 圆角塑形”的路线：

    • 车身：方盒体，但做圆角
    • 车顶：白色独立盖板
    • 车窗：浅蓝半透明块面
    • 轮子：粗短圆柱
    • 细节：灯、条纹、后视镜、表情件

    这条路线的好处是非常适合儿童玩具感：

    • 比例夸张
    • 结构简单
    • 容易继续改可爱化风格
    • 不容易一不小心变成真实汽车

    第七步：建模过程中遇到的坑

    过程中也踩到了两个很典型的问题。

    1. 材质属性兼容问题

    第一次建模时，代码里用了 shadow_method，但当前 Blender 版本对应的材质对象没有这个属性，导致直接报错。

    处理方式很简单：

    • 去掉不兼容设置
    • 保留必要的 blend_method

    2. 父子关系叠加缩放问题

    第一次把零件都 parent 到车身时，车身本身还带有非 1 的缩放，于是子对象在世界坐标里被放大错位，轮子和装饰位置都跑掉了。

    根因定位后，采用了更稳妥的方式：

    • 先创建每个对象
    • 对需要的对象先应用缩放
    • 再做组合与摆放

    这样模型结构才恢复正常。

    第八步：从基础巴士到“更像玩具”

    模型先做出基础版本，然后又做了两轮增强。

    第一轮增强

    • 删除默认 Cube 和 Sphere
    • 把小巴士移到更容易查看的位置
    • 强化蓝白配色
    • 增加白色侧条纹
    • 增加车灯和腮红
    • 切换视口到材质预览

    第二轮增强

    继续往“可爱”而不是“写实”方向走：

    • 前后保险杠
    • 左右车门和把手
    • 后视镜
    • 顶部双色小警示灯
    • 尾灯
    • 前脸格栅

    第三轮增强：正脸表情

    为了让它更像儿童玩具，而不只是一个低模小车，最后又补了正脸表情：

    • 更大的眼睛底
    • 黑色瞳孔
    • 正脸腮红
    • 一个笑脸

    这样整个小巴士的气质就从“简化汽车模型”变成了更明显的“玩具角色车”。

    这次流程里最重要的经验

    如果只看结果，这篇文章像是在讲怎么做一个玩具车。但我觉得真正有价值的，是这几个经验：

    1. MCP 连上不等于真正能用

    最容易被误判的是：

    • 端口开了
    • 配置也写了
    • 工具看起来也注册成功了

    但真实请求未必能执行。

    一定要做至少一次真实读写验证，比如：

    • 读当前场景
    • 创建一个简单对象
    • 再把场景读回来

    2. Blender 的后台模式和 GUI 模式差异很重要

    某些插件依赖主线程回调或 UI 循环，后台模式并不等价于真正的 Blender 运行状态。

    这个问题如果不先定位，很容易误以为是：

    • 插件坏了
    • MCP server 坏了
    • 网络坏了

    实际上只是运行模式不对。

    3. 用 AI 控 Blender 时，先做最小可验证动作

    比起一上来就说“帮我做一个完整场景”，更稳妥的做法是：

    1. 先读场景
    2. 先创建球体
    3. 再做一个简单模型
    4. 最后再加风格和细节

    这样每一步都知道链路在哪一层是通的。

    最终效果

    最后得到的是一辆：

    • 蓝白主色
    • 圆润卡通比例
    • 小巴士轮廓
    • 带玩具化表情
    • 适合继续做展示图或继续精修

    它不追求工业设计精度，而是更偏“儿童玩具模型”的方向，这恰好也是自然语言建模特别适合的场景。

    总结

    这次最大的收获不是“装上了 Blender MCP”，而是把整条链路真正走通了：

    • 从本地安装
    • 到 Codex 接入 MCP
    • 到 Blender GUI 实际连通
    • 到真实建模
    • 再到风格化迭代

    如果只是把工具装上，最多算完成了 30%。

    真正值得记录的是：它已经可以被稳定地拿来做事情了。

    接下来如果继续往下走，很自然的方向会是：

    • 给这个玩具小巴士摆展示镜头和灯光
    • 继续做更多玩具角色车
    • 把 Blender MCP 接进更完整的内容生产流程

    比如：先让 AI 生成 3D 小道具，再把它们整理成博客里的可视化案例。这时候，MCP 就不只是“一个工具连接器”，而会变成整个创作工作流的一部分。

  • 解决MCP Server SSH远程路径配置问题：macOS与Linux路径差异

    解决MCP Server SSH远程路径配置问题：macOS与Linux路径差异

    在开发基于Model Context Protocol (MCP)的博客管理工具时，遇到了一个典型的跨平台路径配置问题。本文详细记录了问题的发现、分析和解决过程，希望能帮助遇到类似问题的开发者。

    问题现象

    MCP Server astro-blog-ssh 在启动时报错：

    failed to initialize MCP client for astro-blog-ssh: MCP 服务启动失败: Error: Command failed: ssh -p 7122 -o BatchMode=yes -o StrictHostKeyChecking=accept-new -i /Users/mhl/.ssh/id_ed25519 mahongliang@111.228.52.26 mkdir -p '/home/mahongliang/workspace/astro-site/content/blog' && test -d '/home/mahongl...

    问题分析

    1. 初步排查

    首先确认SSH密钥文件权限正确（600），SSH连接本身能够正常建立：

    ssh -p 7122 -o BatchMode=yes -o StrictHostKeyChecking=accept-new -i /Users/mhl/.ssh/id_ed25519 mahongliang@111.228.52.26 "echo 'SSH connection successful'"

    2. 深入诊断

    执行完整的目录创建命令时发现问题：

    ssh -p 7122 -o BatchMode=yes -o StrictHostKeyChecking=accept-new -i /Users/mhl/.ssh/id_ed25519 mahongliang@111.228.52.26 "mkdir -p '/home/mahongliang/workspace/astro-site/content/blog' && test -d '/home/mahongliang/workspace/astro-site/content/blog'"

    返回错误：mkdir: /home/mahongliang: Operation not supported

    3. 根本原因

    通过查询远程服务器的用户主目录：

    ssh -p 7122 -o BatchMode=yes -o StrictHostKeyChecking=accept-new -i /Users/mhl/.ssh/id_ed25519 mahongliang@111.228.52.26 "echo \$HOME"

    发现返回结果是：/Users/mahongliang

    这说明远程服务器实际上是macOS系统，而不是假设的Linux系统！

    • Linux系统：用户主目录为 `/home/ `
    • macOS系统：用户主目录为 `/Users/ `

    解决方案

    将MCP配置中的远程路径从Linux路径改为macOS路径：

    错误配置：

    "BLOG_REMOTE_POSTS_DIR": "/home/mahongliang/workspace/astro-site/content/blog"

    正确配置：

    "BLOG_REMOTE_POSTS_DIR": "/Users/mahongliang/workspace/astro-site/content/blog"

    验证修复

    使用修正后的路径测试：

    ssh -p 7122 -o BatchMode=yes -o StrictHostKeyChecking=accept-new -i /Users/mhl/.ssh/id_ed25519 mahongliang@111.228.52.26 "mkdir -p '/Users/mahongliang/workspace/astro-site/content/blog' && test -d '/Users/mahongliang/workspace/astro-site/content/blog' && echo 'Directory check successful'"

    返回：Directory check successful

    MCP Server成功启动：

    Astro Blog SSH MCP Server 已启动 -> mahongliang@111.228.52.26:/Users/mahongliang/workspace/astro-site/content/blog

    经验总结

    1. 不要假设远程系统类型：在配置远程路径时，务必确认远程操作系统的实际类型
    2. 动态验证路径：使用 echo $HOME 命令获取远程用户的实际主目录路径
    3. 跨平台兼容性：在开发工具时考虑不同操作系统的路径差异
    4. 详细的错误日志：保留完整的错误信息有助于快速定位问题

    这个问题虽然简单，但体现了开发中常见的"假设陷阱"。通过系统性的排查和验证，我们能够快速找到并解决问题。

    相关技术栈

    • MCP (Model Context Protocol): 标准化的AI上下文协议
    • Astro: 现代化静态站点生成器
    • SSH: 安全远程连接协议
    • macOS/Linux: 不同的操作系统路径约定

  • 解决 Git Author Identity Unknown 错误：macOS 开发环境配置完整指南

    解决 Git Author Identity Unknown 错误：macOS 开发环境配置完整指南

    在日常开发中，Git 是我们不可或缺的版本控制工具。然而，很多开发者（包括我自己）在新环境或新项目中经常会遇到 Author identity unknown 错误。本文将详细介绍这个问题的完整解决方案。

    问题现象

    当你尝试提交代码时，可能会看到以下错误信息：

    Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: no email was given and auto-detection is disabled

    同时，在 IDE 或 Git 客户端中还可能看到类似这样的日志：

    • No such branch: main
    • bad revision 'refs/heads/main'
    • your current branch 'main' does not have any commits yet

    根本原因分析

    这个问题通常由以下几个原因导致：

    1. Git 用户身份未配置：这是最常见的原因，Git 不知道以谁的身份进行提交
    2. 仓库状态异常：新初始化的仓库没有初始提交
    3. 分支引用问题：分支尚未正确建立或引用丢失

    完整解决方案

    第一步：配置 Git 全局用户身份

    # 设置全局用户名和邮箱
git config --global user.name "你的用户名"
git config --global user.email "你的邮箱@example.com"

# 验证配置是否成功
git config --global user.name
git config --global user.email

    第二步：检查仓库状态

    # 进入项目目录
cd /path/to/your/project

# 检查当前状态
git status

# 查看提交历史
git log --oneline -n 5

    第三步：处理新仓库的初始提交

    如果你的仓库是新创建的，需要进行初始提交：

    # 添加所有文件
git add .

# 进行初始提交
git commit -m "feat: initial commit"

    第四步：验证提交功能

    测试 Git 提交是否正常工作：

    # 创建测试文件
echo "# Test" >> README.md

# 添加并提交
git add README.md
git commit -m "test: verify git commit works"

# 如果只是测试，可以回滚
git reset --hard HEAD~1

    最佳实践建议

    1. 全局配置 vs 本地配置

    • 全局配置：适用于个人开发环境，所有项目使用相同的身份

      git config --global user.name "mhl"
git config --global user.email "656691922@qq.com"

    • 本地配置：适用于工作项目，不同项目使用不同身份

      # 在特定项目目录中执行
git config user.name "Work Name"
git config user.email "work@company.com"

    2. 配置查看和管理

    # 查看所有配置
git config --list

# 查看特定配置
git config user.name
git config user.email

# 删除配置
git config --unset user.name

    3. 常见陷阱避免

    • 不要混淆全局和本地配置：确保在正确的层级设置配置
    • 邮箱格式正确：确保邮箱地址格式正确，避免特殊字符问题
    • 及时验证：配置后立即测试提交功能

    故障排除

    如果按照上述步骤仍然遇到问题，请检查：

    1. Git 版本：确保使用较新版本的 Git

      git --version

    2. 权限问题：确保有权限写入 .gitconfig 文件

      ls -la ~/.gitconfig

    3. 环境变量：某些 CI/CD 环境可能覆盖 Git 配置

    总结

    Author identity unknown 错误虽然简单，但却是 Git 使用中最常见的入门问题之一。通过正确配置用户身份信息，我们可以避免这个错误，并确保提交历史的完整性和可追溯性。

    记住，良好的 Git 配置习惯不仅能避免错误，还能提高团队协作效率。建议在新开发环境搭建时，第一时间完成 Git 基础配置。

    相关标签：Git, macOS, 开发环境, 版本控制, 故障排除

  • 给 Codex 增加自动整理并发布博客的 Skill

    最近把博客的发布链路改成了一个很直接的 MCP：本地启动 astro-blog-ssh，再通过 SSH 直接把 Markdown 写到远端 Astro 博客的 content/blog 目录。

    有了这条链路之后，一个很自然的下一步，就是让 Codex 不只是“能调用工具”，而是“知道什么时候应该把当前对话整理成文章并直接发布”。这次做的，就是把这套行为沉淀成一个可安装的 skill。

    目标不是安装说明，而是行为约束

    一开始最需要收窄的问题，不是怎么写 SKILL.md，而是这个 skill 到底要教 Codex 做什么。

    这次明确的目标是：

    1. 当用户明确说“发布到我的博客”时，Codex 直接整理并发布。
    2. 当当前对话已经形成成体系的技术内容时，Codex 也默认自动发布。
    3. 如果上下文不够，Codex 不能乱编内容，只能缩小主题、说明假设，或者停下来补信息。

    也就是说，这个 skill 不是安装器，不是 MCP 教程，而是一个“从对话到公开文章”的行为规范。

    先写 spec，再落 skill 目录

    为了避免把 skill 写成随意提示词，先在仓库里补了一份设计文档：

    • docs/superpowers/specs/2026-05-01-astro-blog-auto-publish-design.md

    这份 spec 主要固定了几件事：

    • 触发条件分成显式发布和隐式发布两类。
    • 默认行为是自动发布，而不是先出草稿等确认。
    • 自动发布不等于可以编造内容，缺关键信息时必须收窄或中止。
    • skill 只负责教 Codex 调用现有 MCP 工具，不改 MCP 服务本身。

    接着又补了一份实现计划：

    • docs/superpowers/plans/2026-05-01-astro-blog-auto-publish.md

    这样后续生成的 skill 文件就有了清晰边界，既不容易超范围，也更方便以后继续维护。

    最终生成的 skill 结构

    这次只保留最小必要文件：

    skills/astro-blog-auto-publish/SKILL.md
skills/astro-blog-auto-publish/agents/openai.yaml

    SKILL.md 负责定义核心行为：

    • 什么时候使用这个 skill
    • 什么时候不要使用
    • 如何把对话重写成公共技术文章
    • 如何处理信息不足
    • 何时调用 generate_slug 和 create_post
    • 发布失败时如何保留草稿并说明失败原因

    agents/openai.yaml 则负责给 Codex 的技能列表和显式调用入口提供元数据，比如：

    • display_name
    • short_description
    • default_prompt

    这个分层很重要。真正的工作规范应该放在 SKILL.md，而不是都挤进 description 里，不然模型很容易只读简短描述、不读完整 skill。

    skill 里最重要的几条规则

    相比“写出一篇文章”，更重要的是“什么时候不该发”。

    所以这次 skill 里最关键的约束有几条：

    1. 默认自动发布，但前提是当前对话已经足够完整。
    2. 文章必须围绕一个清晰技术主题，而不是原样搬运聊天记录。
    3. 对于小缺口，可以用保守假设补齐，并在最终响应里说明。
    4. 对于关键缺口，不能编造事实，只能补问或缩小文章范围。
    5. 涉及私密、凭据、内部细节的内容，不能直接发。

    这几条基本决定了 skill 的可用性。如果没有这些边界，所谓“自动发布”很容易变成“自动制造垃圾文章”。

    一个实际踩到的坑：元数据生成脚本依赖 PyYAML

    为了避免手写 agents/openai.yaml，我直接复用了现成 skill 自带的生成脚本。

    第一次运行时，脚本报错了：缺少 yaml 模块。

    根因不是脚本逻辑错误，而是它默认会读取 SKILL.md frontmatter，并使用 PyYAML 解析。本地当前 Python 环境没有这个依赖。

    这时候最小改动不是去改环境，也不是去改脚本，而是直接使用它支持的 --name 参数，绕开 frontmatter 解析步骤。这样既不污染环境，也不偏离当前任务范围。

    这个处理方式的好处很明显：

    • 不增加仓库依赖
    • 不修改外部 skill 提供的脚本
    • 仍然能产出标准 openai.yaml

    另一个小坑：$skill-name 被 shell 吃掉了

    openai.yaml 里有个 default_prompt 字段，规范要求显式写出 $skill-name。

    第一次生成后，结果从：

    Use $astro-blog-auto-publish ...

    变成了：

    Use -blog-auto-publish ...

    问题出在 shell 展开：$astro 被当成环境变量替换掉了，剩下后半截字符串。

    根因明确之后，修复也很简单：不要怀疑 skill 内容本身，直接把生成后的 openai.yaml 用字面量修正为正确的 $astro-blog-auto-publish。

    这个问题很小，但挺典型：

    • 不是业务逻辑问题
    • 不是 MCP 问题
    • 是命令层的字符串展开问题

    如果没有在最后做一次完整验证，很容易带着这个细小错误交付出去。

    最后做了哪些验证

    这次没有去验证“Codex 运行时一定会自动触发 skill”，因为那取决于实际的 skill 加载环境和 MCP 可用性。但本地已经做了这些可证实的检查：

    1. skill 目录结构完整。
    2. SKILL.md frontmatter 合法，命名符合 hyphen-case。
    3. openai.yaml 已生成，字段和 skill 语义一致。
    4. default_prompt 中的 $astro-blog-auto-publish 已按字面量保留。
    5. 仓库 diff 范围只包含 spec、plan 和 skill 目录，没有误改 MCP 服务代码。

    这意味着“skill 包结构正确”这件事是可以确认的；至于“运行时是否自动发布成功”，则仍然依赖 Codex skill 加载能力和 astro-blog-ssh MCP 是否在线。

    这类 skill 的价值

    如果只是偶尔发一篇文章，直接手工整理也能做。

    但当你已经有了 MCP 工具链，下一步最有价值的就不是重复调用工具，而是把“什么时候该调用、如何整理、什么情况下不能发”固化下来。

    skill 的真正价值，不在于省掉几个命令，而在于让自动化行为有边界、有默认策略、也有失败回退路径。

    这次的 astro-blog-auto-publish 就属于这种类型：它不是新能力，而是把已有能力变成了可重复复用的工作流。

  • 从零打通 WordPress + MCP：部署、反代、真实 CRUD 与可复用工具整理

    这篇文章想解决一个很具体的问题：怎么把一套 WordPress 博客，从本地部署、到公网访问、再到接入 MCP / AI 工具做文章增删改查，完整打通，并整理成可以上传 Git、让其他电脑直接复用的方案。

    如果你刚接触 WordPress、Docker、反向代理，或者还不熟悉 MCP，这篇文章会尽量按“现象 → 原因 → 处理方式 → 注意事项”的顺序讲清楚。文中的敏感信息已经做过脱敏处理，例如：

    • 正式域名统一写成 your-blog.example
    • 服务器 IP 写成 your-server-ip
    • WordPress 用户名写成 your-wordpress-username
    • 应用密码写成 xxxx xxxx xxxx xxxx xxxx xxxx
    • 本地绝对路径写成 /path/to/project
    • 历史冲突域名写成 old-host.example

    一、这次最终达成了什么

    先看结果，再看过程。

    • 本地有一套稳定的 WordPress Docker 环境
    • 公网可以通过正式域名访问博客
    • Codex / MCP 可以对文章做真实的创建、读取、更新、删除
    • 工具目录已经整理成可直接上传 Git 的状态
    • 别人换一台电脑，也能按文档快速跑起来

    二、整体架构长什么样

    这套链路最终不是“直接把本地 8016 端口暴露出去”，而是做了一层更稳定的收口：

    your-blog.example
-> 服务器 Nginx / 反向代理
-> http://127.0.0.1:7412/
-> nps / npc 隧道
-> 本机 127.0.0.1:8016
-> WordPress 容器

    这条链路的好处是：

    • 本地 WordPress 只监听在回环地址，不直接暴露在公网
    • 公网入口只有正式域名和服务器反代，访问路径更统一
    • 本地开发和线上访问逻辑可以分开处理，不容易混乱

    三、本地 WordPress 是怎么部署的

    本地 WordPress 使用 Docker 跑起来，最后固定在：

    http://127.0.0.1:8016

    为什么不用常见的 8080？原因很简单：开发环境里 8080 太常见，容易和已有服务、浏览器缓存、历史代理配置混在一起。换成一个明确的本地端口，可以减少排查成本。

    这一步的核心原则有两个：

    • 只监听本机：例如 127.0.0.1:8016:80
    • 本地端口只给本地和隧道使用，不要让它直接成为用户访问入口

    四、遇到的第一个坑：域名能打开，但会自动跳到 :8080 或 :8016

    这是整个过程中最容易让人误以为“浏览器坏了”或者“反向代理配置错了”的问题。

    1. 现象

    • 访问 https://your-blog.example，页面打不开
    • 浏览器地址栏会自动变成 https://your-blog.example:8080/ 或 :8016
    • 有时候域名本身能返回 200，但页面里资源、链接、跳转目标还是旧端口

    2. 原因

    根因通常不在浏览器，而在 WordPress 自己认错了“站点地址”。

    WordPress 有两个特别关键的概念：

    • WP_HOME
    • WP_SITEURL

    如果这两个值还保留着本地开发地址，比如 http://127.0.0.1:8016，那么用户虽然是通过正式域名进来的，WordPress 仍然会坚持把页面里的链接和重定向指回本地端口。

    3. 正确做法

    正式对外访问后，站点地址必须改成正式域名：

    define('WP_HOME', 'https://your-blog.example');
define('WP_SITEURL', 'https://your-blog.example');

    一旦改对，再去验证：

    • 响应头里的 Link 是否已经变成正式域名
    • 页面 HTML 里的文章链接、静态资源、RSS 地址是否都换成正式域名

    4. 小白注意事项

    • 不要只看浏览器打开了没，要看响应头和页面源码
    • 如果你刚改完还在跳旧端口，先排除浏览器缓存和旧标签页
    • 如果你已经切换成正式域名，就不要再让文章内、配置内继续出现本地开发端口

    五、遇到的第二个坑：7412 端口反代后访问不了

    这个问题一开始看起来像“WordPress 没起来”，但实际并不是。

    1. 现象

    • 本地 127.0.0.1:8016 能访问
    • 服务器反向代理目标写的是 http://127.0.0.1:7412/
    • 但外部访问域名时仍然打不开

    2. 排查思路

    这个问题不能直接猜，要按链路一段一段排：

    1. 先确认 WordPress 容器是不是正常监听在本机端口
    2. 再确认 npc 当前转发目标是不是还是旧端口
    3. 再确认远端 nps 暴露的端口到底是不是你想要的那个端口
    4. 最后看服务器上的 Nginx 是否真的反代到了正确的本地入口

    3. 这次实际遇到的问题

    • 本地 WordPress 端口从 8080 切到了 8016
    • 但 npc 配置文件里仍然保留着旧目标
    • 中途还有一条旧的 host 配置（这里脱敏写成 old-host.example）在服务端冲突，导致 npc 重连时报错

    换句话说，问题不是只有一层，而是“旧端口残留”和“旧反代项冲突”叠在了一起。

    4. 处理方式

    • 把本地服务统一切到 127.0.0.1:8016
    • 把 npc 的 TCP 目标改成 127.0.0.1:8016
    • 把服务器端对外入口统一收口到 7412
    • 把正式域名只指向服务器反代，不再直接暴露本地开发端口

    5. 小白注意事项

    • “本地能访问”和“公网能访问”是两回事，别混在一起
    • 每改一层，就只验证这一层，不要一次改三四个地方
    • 端口切换后，一定把旧配置文件、旧代理项、旧浏览器缓存一起排查

    六、遇到的第三个坑：MCP / REST 明明配置好了，为什么还是 401

    这一段是最容易让人误判成“代码有问题”的地方。

    1. 现象

    • 读文章可以，写文章不行
    • 调用创建文章接口时返回 401
    • 错误像“不能创建文章”“未登录”“无权限”等

    2. 真正原因

    WordPress 写入接口最关键的不是普通账号密码，而是 Application Password。

    这次排查里实际发现了两个问题：

    • 账号虽然是管理员，但用户下面根本没有实际生成的应用密码记录
    • 后来密码更新了，MCP 旧进程没重启，继续拿旧密码在请求

    3. 正确验证方式

    不要一上来就测创建文章，先测：

    /wp-json/wp/v2/users/me

    只有当它返回 200，并且用户身份正确时，才说明这套凭据真的可以用于后续写操作。

    4. 小白注意事项

    • 能登录 WordPress 后台，不等于能写 REST API
    • 应用密码要在对应用户资料页里单独生成
    • 密码更新后，如果工具进程是长驻的，记得重启进程

    七、MCP Server 和 Skill 到底各自做什么

    为了让整套方案更稳定，我把能力拆成了两层：

    • MCP Server：直接提供文章 CRUD 工具
    • Skill：告诉 Codex 在什么场景下优先走 MCP，在什么情况下可以回退 REST API

    这样做的好处是：

    • 在 Codex 里可以直接“像工具一样”管理文章
    • 就算某次会话里的内置 MCP transport 断了，也不影响独立验证服务是否正常
    • 工具目录可以独立迁移到其他电脑使用

    八、真实 CRUD 到底有没有跑通

    有，而且不是只做了“读一下列表”这种浅层验证，而是做了真正的闭环测试。

    1. REST API 闭环

    • 创建文章：成功
    • 读取文章：成功
    • 更新文章：成功
    • 删除文章：成功

    2. 独立 MCP 客户端闭环

    还额外写了一个独立测试脚本 test-mcp-client.mjs，通过 MCP 协议直接连接 wordpress-mcp.js，跑通了：

    • create_post
    • get_post
    • update_post
    • delete_post

    这说明问题真正的边界已经很清楚：

    • WordPress 站点没问题
    • 应用密码没问题
    • MCP 服务本身没问题
    • 如果某次会话仍然报 transport closed，那多半是“会话 transport 状态”坏了，不是你的博客坏了

    九、为什么还要专门整理成 Git 可上传状态

    因为“自己电脑上能跑”不等于“这套东西可以长期复用”。如果后续要放到 Git，给别的电脑继续使用，必须把敏感信息和环境耦合清掉。

    这次收尾主要做了这些事：

    • 去掉示例配置里的真实域名、用户名、密码
    • 把测试脚本改成只读取环境变量
    • 新增 .env.example
    • 让别人只需要复制一份 .env 就能跑
    • 新增 npm run start:env 和 npm run test:mcp:env

    十、如果你是第一次照着做，最短步骤是什么

    如果只是想先把工具跑起来，而不是一次性把所有细节都吃透，可以按下面这条最短路径走：

    cd wordpress-ai-tools/mcp-server
cp .env.example .env
# 把 .env 里的站点地址、用户名、应用密码改成你自己的
npm install
npm run start:env

    如果还想确认整条 MCP 链路真的能写文章，再执行：

    npm run test:mcp:env

    十一、这次最值得记住的几个注意事项

    • 正式域名上线后，WordPress 站点地址一定要改成正式域名，不要留本地端口
    • 反代问题排查要一层一层来，不要混着猜
    • REST API 写入靠的是 Application Password，不是后台登录密码
    • 进程是长驻的，密码变了不重启，工具可能还在用旧凭据
    • 上传 Git 前一定做脱敏，不要把密码、用户名、绝对路径、内网信息带进去

    结语

    这次最大的价值，不是“我把 WordPress 跑起来了”，而是把它整理成了一条真正可重复、可迁移、可验证的工作流：本地部署可控、公网访问稳定、AI 工具可写、目录结构可复用。

    如果后续继续扩展，这套基础还可以往媒体上传、页面管理、分类标签自动化、自动发布工作流继续延伸。对个人博客来说，这已经不只是一个站点，而是一套可以长期积累的内容工具链。