当 AI Agent 接手博客运维：从零信任到自动化发布的完整实战
前言把个人博客的运维工作交给 AI Agent，听起来像科幻情节，但今天它真实发生了。 整个过程从一次简单的 SSH 连接测试开始，逐步梳理出服务器上的完整站点架构，最终形成一套可复现的自动化发布手册，并以这篇文章本身作为首篇实战检验。以下记录全流程，供同样想尝试「AI 运维托管」的开发者参考。 安全声明：本文已对所有敏感信息（服务器 IP、密钥指纹、内部路径细节等）做脱敏处理，仅保留方法论层面的参考价值。 一、运维交接的第一步：建立安全连接任何远程运维的前提是可控的访问通道。在正式操作前，需要完成三件事： 1.1 验证 SSH 连通性通过本地 ~/.ssh/config 中预配置的主机别名，测试与云服务器的连通性。关键检查项： 密钥认证是否正常（RSA 4096 密钥对） known_hosts 指纹是否匹配 防火墙是否放行 TCP 22 端口（云厂商控制台 + 本地 ufw 双重确认） 1.2 摸清站点家底连通后立即执行架构普查，绘制出完整的站点地图： 路径 服务 技术栈 / 主站首页 静态 HTML /blog/ 技术博客 Hexo + Butte...
胶水代码：分析、策略与利弊
胶水代码：分析、策略与利弊 基于 O2O 平台政策汇总项目的真实解剖 一、什么是胶水代码胶水代码 指主要作用是连接不同系统/API/库、自身几乎不产生核心业务价值的代码。典型特征： 特征 说明 调用外部服务 核心能力来自第三方 API，项目只负责传参数和收结果 格式转换 A → B → C 的数据搬运，没有注入新的业务价值 无领域建模 数据从头到尾以原始形态传递（dict → dict → dict） 模块间复制 同样的解析逻辑重复出现在多个文件中 意图隐匿 代码只表述”怎么做”，不表述”为什么这么做” 本项目的胶水成分解剖12345678整个数据链路：assets/*.png ──→ OCR API ──→ 解析 ──→ CSV ──┬──→ Excel (openpyxl) ├──→ JSON (json.dumps) └──→ HTML ...
Vibe Coding 编排实现：AI Agent 的六阶段开发执行手册
本文档描述 Hermes Agent（AI 编排者） 如何具体编排六阶段 Vibe Coding 全过程，包含入口判断、todo 追踪、每个阶段的精确工具调用序列、阶段间自动推进、反馈循环与异常处理。 为什么需要编排手册？AI 编程正从”单轮对话生成代码”进化为多 Agent 协作的工程化流程。一份精确的执行手册让 AI Agent 在独立运行时保持一致的行为模式： 阶段解耦：每阶段有明确输入/输出，互不干扰 质量门禁：每个产出经过对抗性审阅 上下文治理：防止长流程中记忆偏差与幻觉 反馈循环：自动检测失败并修复，而非盲目继续 入口触发与初始化触发条件以下任一情况进入 Vibe Coding 模式： 12341. 用户说"启动项目"、"开始开发"、"做这个项目"、"vibe coding"2. 用户说"我们做 X 项目" — 明确要建一个完整项目3. 用户发来一个文档/截图/链接说"帮我实现这个"4. 用户说"继续上次的项目&quo...
首页重构：用 Claude + MiMo 打造 Linear 风格的数字分身
首页重构：用 Claude + MiMo 打造 Linear 风格的数字分身 旧首页像一份精致的简历，新首页才是我的数字分身。 今天下午，我把 liclaw.site 的首页彻底换了。 不是改颜色、不是调间距，是从架构到视觉、从单文件到三文件、从 Apple 浅色到 Linear 深色的完整重构。整个过程由 Claude Code CLI (v2.1.123) + 小米 MiMo V2.5 Pro 驱动，我负责决策和验收，Agent 负责编码和迭代。 为什么必须换？旧版首页 (felix-homepage.html) 是单文件内联方案，Apple 浅色风格，四个能力卡片 + 三个统计数字，很干净，但问题也很明显： 叙事断层：看完首屏和四张卡片，访客没有任何路径深入了解我是谁、我做了什么、怎么联系我。 视觉同质化：浅色 + 大留白 + 圆角卡片，这是 2024 年每一个 Notion 风站点的标配，缺乏辨识度。 交互单薄：只有卡片 3D 倾斜和数字滚动，没有系统级的反馈层。 工程化不足：单文件 800+ 行内联 CSS，维护成本随内容增长指数级上升。 我需要一个有灵魂的站点，...
OpenClaw Agent 服务器从零搭建：Lighthouse 方案实操手册
读完这篇文章，你会得到什么？ 一台跑着 OpenClaw Agent 的腾讯云 Lighthouse 服务器——有自己的域名、HTTPS 证书、Nginx 反向代理，能通过飞书向它下指令，让它自动部署网站、更新博客。 需要的只有三样东西：一台服务器（~100 元/年）、一个域名、一个下午的时间。 1. 成品预览：搭完是什么用一句话描述：你有一台腾讯云服务器，出厂就预装了 OpenClaw（一个 24 小时在线的 AI 管家）。你把域名指向它，备案通过后，在飞书上对它说一句”帮我部署一个博客”，它就帮你做了。 这套系统的实际形态： 1234567graph LR A[你的飞书/微信] -->|发指令| B[Nginx 反向代理] B --> C[OpenClaw Agent] C -->|读写| D[服务器文件系统] C -->|调用| E[大模型 API] C -->|部署| F[静态网站] D --> G[博客 / 壁纸站 / 工具页面] 你在聊天框里输入需求，Agent 出代码、建目录、...
SEO 到 GEO：一个技术博客的结构化数据升级实录
背景我的博客运行了不到一个月，16 篇文章，每天几十个 PV——其中大量来自爬虫。SEO 做得粗糙：大部分文章的 description 和 keywords 是空的，标签膨胀到 42 个（文章数量的 2.6 倍），结构化数据只有 1 篇有。 但真正推动这次升级的，不是传统搜索引擎，而是 AI。 2026 年 3 月，搜索引擎的核心更新方向已经明确：结构化数据不再是”提升展示”的加分项，而是 AI 抓取和引用的基础信号。如果你的文章没有清晰的机器可读标记，GPT、Perplexity、搜索引擎的 AI 模式看不见你。 于是周末花了一晚上做了一次全站结构化数据升级。这篇文章记录过程和收获。 第一步：诊断现状先过一遍博客的 SEO 基线： 指标 优化前 JSON-LD 覆盖率 1/16 description 覆盖率 3/16 keywords 覆盖率 6/16 内链 0 标签数量 42 个 llms.txt 不存在 42 个标签对 16 篇文章，意味着平均每个标签只被 1.5 篇文章使用——搜索引擎会判定这个站点主题...
DeepSeek V4 reasoning_content 400 错误排查与修复
问题摘要：DeepSeek V4（flash / pro）在 OpenClaw 中进行多轮对话时，第二轮开始 API 返回 HTTP 400 “The reasoning_content in the thinking mode must be passed back to the API”。根因是 OpenClaw 的 parseThinkingSignature 函数无法处理 DeepSeek 的非 JSON 签名字段，导致 thinking block 被丢弃。本文提供 3 种修复方案。 发生了什么错误DeepSeek V4 是当前性价比最高的推理模型之一。但在 OpenClaw 中接入后，单轮对话正常，一到第二轮就报错： 1400 The `reasoning_content` in the thinking mode must be passed back to the API. 这个错误说明：第一轮 DeepSeek 返回了思考内容（reasoning_content），但第二轮请求中缺少了这个字段。 为什么单轮正常，多轮就报错因为单轮对话不需要上下文...
free-claude-code 深度分析：给 Claude Code 套上免费代理的正确方式
Claude Code 是 Anthropic 推出的终端 AI 编程助手，功能对标 GitHub Copilot CLI 和 OpenClaw 的 coding agent 模式——直接在终端里读取项目、修改文件、执行命令。但官方 API 按量计费，重度使用一天烧掉几十美元并不稀奇。如何免费使用 Claude Code 成为许多开发者关注的问题。 free-claude-code（MIT 协议）是一个 Claude Code 免费代理工具，它截获 Claude Code 的 Anthropic Messages API 请求，路由到六种替代后端——包括 NVIDIA NIM 的免费接口、OpenRouter 的免费模型、以及本地运行的推理引擎。简言之：保留 Claude Code 的客户端体验，后端换成免费或自建的模型服务，实现零成本或极低成本的 Claude Code 日常使用。 本文从架构、部署、提供商标配三个维度分析该项目，并给出适用场景判断和踩坑提示。 架构：一个 FastAPI 代理的灵活设计整个项目核心是一个 FastAPI 应用（约 30 行入口 + 多层模块）...
Store 站点动效优化实践：从独立实现到共享组件化
背景Store 站点作为门店资源中心，承载着会议记录、营销素材等重要内容。为了提升用户体验，我决定为站点添加动效，让页面更加生动、交互更加自然。 本文记录了 Store 站点动效优化的完整过程，包括动效设计、实施过程、性能优化以及最终的共享组件化。 动效设计设计原则在设计动效时，我遵循以下原则： 零依赖：使用纯 CSS + 原生 JavaScript，不引入额外的动画库 性能优先：使用 GPU 加速（transform + opacity），避免重排重绘 移动端友好：支持触摸交互，提供触觉反馈 可访问性：尊重用户的 prefers-reduced-motion 设置 动效类型我设计了以下几种动效： 渐入动画（Fade-in）：页面加载时，元素依次渐入 涟漪效果（Ripple）：点击时产生涟漪扩散效果 触摸反馈（Touch Feedback）：移动端点击时轻微缩放 实施过程阶段一：首页动效实现首先，我为 Store 首页添加了动效。关键代码如下： 123456789101112131415161718192021222324252627282930313233/* 渐入动画...
Store 门店资源中心搭建实录
今天搭了一个门店资源中心，把会议记录和营销素材都搬上去了。之前这些东西散落在各处——会议记录没地方存，营销素材堆在飞书文档里翻半天找不到。现在总算有个统一的地方了。 怎么选的技术我看了一圈，最后定下来这套门店资源管理方案： 飞书多维表格存营销素材。能筛选、能协作，比文档好管理 JSON + JavaScript做前端。纯静态文件，不用搞数据库，Nginx 一挂就能跑 Python调飞书 API。主要是下载图片用 HTML/CSS写页面。响应式，手机上也能看 说白了就是：飞书管数据，JSON 做中间层，前端动态加载。 架构长这样12345飞书多维表格（团队在这添加素材） ↓ 导出marketing.json / meetings.json（中间数据层） ↓ JS 加载Store 首页（用户看到的页面） 这个设计有个好处：团队在飞书中改东西，JSON 文件一更新，页面就跟着变。不用每次都改代码。 💡 相关阅读：飞书定时推送工作流完整指南 - 了解如何使用飞书 API 实现自动化推送 会议记录怎么做的数据结构很简单： 1234567{...