本文摘要：

• 从零配置一台博客服务器的完整实践：SSH 免密登录、Nginx 部署、Cloudflare DNS、GitHub Webhook 自动部署
• 全程没有离开 Qoder 终端，涉及 5 个外部系统的联动操作
• Qoder 的能力边界远不止写代码，它可以操作你能 SSH 到的任何机器、调用任何有 API 的服务
• AI First 思维：遇到任何事情，先想想能不能用 AI 解决

又要配服务器了

我的博客一直部署在自己的 ECS 上，最近旧的那台到期了，续费价格看了一眼就没有续费的欲望，索性买了一台新的。

熟悉我博客的读者可能知道，这已经不是我第一次折腾博客服务器了。上一次配这套环境的时候，我开了四五个终端窗口，一边翻 Nginx 文档一边调配置，中间还要切到浏览器登录 Cloudflare 控制台改 DNS、登录 GitHub Settings 配 Webhook，前前后后折腾了大半天。流程我都很熟，但就是琐碎，每次换服务器都得把这些步骤重新走一遍，属于那种”会做但不想做”的事情。

但这次情况不一样了——我手边有 Qoder。

既然日常写代码都在 Qoder 里，配服务器这种事情不妨也试试全程在 Qoder 里完成。不是让它帮我写一个部署脚本，而是让它直接操作——SSH 到服务器装软件、调用 Cloudflare API 改 DNS、通过 GitHub CLI 创建 Webhook。整个过程还挺顺畅的，这篇文章就是把这个过程完整记录下来。

如果你还把 AI Coding 工具仅仅当作”写代码的助手”，希望这篇文章能帮你打开一些思路。

前言

这是我”AI Coding 经验总结”系列的第四篇文章，距离上一次分享《Qoder Quest 1.0：把执行交给 AI，把选择留给人类》正好又过去了 2 个月，我对 AI Coding 的认知又进行了一次刷新。

这两个月内，Qoder Quest 依旧是我日常开发的主力，但为了避免自己的认知被单一产品绑定，我也强迫自己试用了很多其他产品：Kiro、Claude Code、Codex 等。这些产品并不是工作在同一维度，我甚至会同时使用它们，本文我也会基于个人使用体验来分析一下。本文所有的对比和评价，都是以 Qoder（Quest + CLI）作为基准参照——它是我最熟悉的工具，也是我衡量其他产品时的默认坐标系。

TL;DR

• QoderWork 是 Qoder 推出的桌面级通用智能体助手，将 AI 能力从代码开发扩展到日常办公
• 核心能力覆盖文件整理、PPT 生成、信息图批量制作、视频合成等场景
• 本文分享了我结合自定义 Skill 的实战技巧：批量信息图制作、特定风格 PPT 生成等
• 关键洞察：Skill 是差异化的关键——同样的产品 + 不同的 Skill = 完全不同的产出质量
• 我的 Skill 合集：https://github.com/lexburner/skill-collection

前言

最近 AI 热点实在太多了，我的钉钉工作群、朋友圈基本被 Claude Cowork、OpenClaw 这些新产品、新概念刷屏了，想不关注到都难。

就在 1月底，Qoder 发布了 QoderWork 新产品， 跟上边两个工具定位类似，但做了国内适配，免去了复杂的安装步骤，我也是迫不及待试用了一下，跟大家一起看看是怎么一回事。

目前 QoderWork 还在内测阶段，一周内估计就会正式开放，申请邀测：https://qoder.com/qoderwork

本文摘要：

• Quest 1.0 只为 SOTA 模型优化，不做向下兼容
• 舍弃代码导航是一种设计”品味”，面向解决问题而非面向代码
• 结合 skill 可以让 Qoder 操作你的整个 DevOps 环境
• “品味”可能是未来人类 vs AI 的核心差异

前言

距离我上一篇文章《使用 Qoder 2 个月，我总结了一些经验》正好又过去了 2 个月，这段时间我对于 AI Coding 的实践有了更多的体会，今天再次对自己的认知升级做一次总结。

AI 能干的事情很多，AI 产品的能力也越来越强，现在我已经坚信一个事实，一件事情只要具备可验证性，AI 就一定能给你搞定。AI 放大了可做的范围，却也带来了选择的焦虑。我会去优化很多没有 AI 的时候不会优化的代码，创造很多没有 AI 的时候不会创造的功能，创造一些有意思但不具备生产价值的玩具。而特别是交付到生产的代码，我会极力避免做出很多功能而每个功能最后 20% 公里没有走完，而往往是这 20%的功能花费了我们 80% 的时间。

我在 AI Coding 时也总结了一些第一性原理：

• 价值：这个功能一定需要吗
• 优先级：有比这个事情更重要的事情吗
• 认知边界：这个任务是否超出了我固有的技术栈认知？AI 能否帮我突破这个限制？
• 品味：在众多可行方案中，哪个是对的选择？这需要人类的偏见来决策

Qoder Quest 1.0 升级

如果你对 Qoder Quest 模式的体验还停留在仅仅是 Spec Driven Development 的感受，按照固定的设计 - 执行 - 总结三步骤去运行，那是时候进行一次认知升级了，在最近，Qoder Quest 正式发布了 1.0 版本，此前是 0.1 版本。这次升级使得 Quest 模式跟此前常用 Editor 模式（Agent/Ask），形成 Qoder 的两大主要入口。

我试图对比 Quest 模式和 Editor 模式的差异，以下是我的理解。

使用 Qoder 开发真实项目

本文整理自《Qoder Together 上海站 | 2025/12/20》的直播分享。

我今天分享的主题是 Agentic Coding 认知升级与实践避坑指南。我相信大家都能感受到，AI 编程的浪潮已经拍在了我们的键盘上，问题不是”用不用”，而是”怎么用才能让它成为真正的生产力，而不是解决了代码的产出，又引入了新的麻烦”。

自我介绍

首先进行下自我介绍，我是徐靖峰，花名是岛风，来自阿里云专有云 PaaS 中间件团队，主要负责网关产品的研发工作。同时我也是一个开源贡献者，主要参与 Higress 和 Himarket 项目。

我并不是 Qoder 团队的同学，所以可以更加客观地去评价 Qoder。

大家好，我是岛风。订阅了两个月 Qoder 之后，我想通过这篇文章分享一些个人使用心得和感受，希望能和大家交流 AI 编码的经验。

Qoder 是什么

Qoder 是阿里在 Agentic Coding 赛道上交出的一份答卷，一个对标 Cursor、Claude Code 的智能编码平台。官网链接：https://qoder.com/referral?referral_code=giB4Qp8oAraMl3HnoBEqCoIavUwbZJPO

目前提供了几种不同的形态供用户选择

Qoder IDE：一个独立的、拥有图形化界面的 IDE，核心功能包括 Agent 模式、问答模式、Quest 模式。

Qoder CLI：命令行工具，为喜欢终端操作的开发者准备。

Qoder JetBrains 插件：对于离不开 JB 全家桶的开发者，Qoder 提供了无缝集成的插件。

我为什么用 Qoder

AI Coding 产品作为一个消费级的产品，除去公司采购报销场景，自行使用基本都是付费上班模式，所以还是会用脚投票的。

公司已经对部分部门开放了 Cursor 的申请入口，但很不巧我所在的部门还没有开放申请入口。

于是便采取了比价模式，以 Curosr 和 Qoder 对比为例，二者同样采取订阅制，同样的 Pro 订阅 Qoder 的价格是 Curosr 的一半，再叠加上新用户赠送 2000 credits 和首次订阅 2 刀的“真香”福利，不动心真的很难。

至于为什么没考虑其他工具：

• Claude Code。口碑虽好，但国内使用据说极易被封，加上公司强大的安全扫描，用“黑科技”强行上车，风险未知，得不偿失。
• 字节 Trae 和美团的 Catpaw。主要是产品成熟度和友商因素。在没有形成压倒性口碑之前，没必要投入太多精力去“陪跑”。

前言

今年 3 月份 MCP 协议成为了 AI 的新一轮热点，被大多数人所熟知，彼时 Higress 快速进行跟进，新增了 MCP 协议转换功能，详见：https://higress.cn/ai/mcp-quick-start ，该方案解决了以下问题：

1. 引入 Redis，借助其 pub/sub 特性，解决了 SSE 协议会话保持的问题
2. 提供了 OpenAPI 转换成 MCPServer 的能力，仅需提供符合 OAS 3.0 规范的 OpenAPI 文档，即可自动转换成网关托管的 MCPServer
3. 提供了 Go Template 和 GJSON 表达式，来对请求和响应模版进行精细化处理，这使得用户只需要变更配置即可完成对 MCPServer 的调优，且变更过程流量完全无损，SSE 连接也不会断开。

该功能一经推出，迅速在开源社区引起了用户广泛的关注，同时在交流群中，也有大量用户反馈了配置失败的问题，因为该功能过于原子化且配置复杂，用户很容易遇到配置失败的问题，为进一步增加用户体验，我们决定将 Higress MCP 相关的能力以场景化的方式，集成在 Higress Console 中，即 MCP 服务管理模块。

用户可以在 Higress 2.1.5 版本中正式体验该文中提及的所有特性。

Higress MCP 服务管理介绍

Higress MCP 服务管理功能概览

Higress MCP 服务管理模块提供了以下能力：

• OpenAPI 转换 MCP。根据用户提供的 OAS 3.0 文档，连接网关已有的 HTTP 后端服务，即可自动转换成 MCPServer。
• DB 转换 MCP。用户仅需将数据库实例配置为网关的后端服务，即可自动转换成 MCPServer，目前支持 MySQL、PostgreSQL、Clickhouse、Sqlite。
• MCP 直接路由。可以直接代理 SSE/Streamable 协议的后端服务。
• MCP 认证授权能力。

站在一个 Higress 开源贡献者的视角，我还是先澄清下 Higress 本身的定位，其主要还是承担 AI 网关/MCP 网关的职责，作为一个基础设施，帮助企业更好地构建自身的 MCP 市场，其提供的 MCP 特性支持，可以非常友好地跟 MCP 应用商店（如 mcp.so）、MCP 客户端市场（Cline、Cursor、Cherry Studio）、平台型市场（百炼、魔搭、Dify）等场景结合，Higress 跟这些场景并不是竞争关系。

这篇文章将向大家介绍 Higress 近期在 Wasm 插件生态方面的一个进展——Higress Wasm 插件服务器（Higress Plugin Server）。这个新的组件解决了用户在私有化部署 Higress 网关时拉取插件的痛点，优化了插件的下载与管理效率。

一、Wasm 插件：Higress 的扩展能力与挑战

Higress 自开源以来就一直将 Wasm 技术视为核心的网关扩展手段。Wasm 带来的工程可靠性、沙箱安全性、热更新能力以及 Higress 团队在此基础上构建的域名/路由级生效、Redis 访问能力、AI 特性支持等，都丰富了网关的扩展性，并为企业用户带来了性能提升和成本降低。通过自定义 Wasm 插件，用户可以根据自身的业务需求，在网关层完成鉴权、加解密、会话管理等逻辑，减少了额外资源的小号，降低了后端服务的处理负担。

尽管 Wasm 插件技术本身具备优势，但在实际的企业级部署和大规模应用场景中，我们依然面临一些实际的挑战，主要体现在以下几个方面：

1. OCI 机制带来的私有化部署挑战

当前，Higress Wasm 插件的下载和管理主要依赖 OCI（Open Container Initiative）仓库。

关于 OCI、oras 和 Docker

• OCI (Open Container Initiative)： OCI 旨在为容器镜像和运行时定义开放标准，以确保不同容器技术之间的互操作性。在云原生生态中，OCI 镜像仓库（如 Docker Hub、Harbor、registry.k8s.io 等）是分发容器镜像的标准方式。Higress 最初将 Wasm 插件作为 OCI Artifacts 发布，即将其打包成符合 OCI 规范的制品并存储在 OCI 仓库中。
• Docker： Docker 是目前最流行的容器平台，它使用 OCI 镜像作为其核心分发格式。通常，我们使用 docker pull 和 docker push 命令来拉取和推送容器镜像。
• oras (OCI Registry As Storage)： oras 是一个命令行工具，它允许用户在 OCI 仓库中存储和管理任意内容，而不仅仅是容器镜像。对于 Higress Wasm 插件这类非标准的容器镜像（Wasm 模块），oras 提供了一种方便的方式来与 OCI 仓库进行交互（例如拉取、推送 Wasm 插件）。

OCI 机制的挑战

虽然 OCI 机制在云原生环境中是标准且高效的方式，但对于一些企业，尤其是对网络安全性有严格要求的私有化部署场景来说，OCI 仓库的引入成了一个不小的门槛，并带来了以下问题：

• 技术门槛与工具使用不便： 许多用户可能习惯于应用程序的直接安装或通过简单的包管理器进行部署，而对容器镜像、OCI 标准、以及 oras 这类专门用于非镜像内容的 OCI 工具的使用并不熟悉。这增加了 Wasm 插件的上手难度和运维复杂度。
• 网络限制与私有化部署： 许多企业内部网络严格，对外部公共网络（如 Docker Hub、GitHub Container Registry等）的访问有严格限制。私有化部署环境下，更是会因为无法访问外部公开仓库而导致无法配置插件和更新插件。
• 额外的基础设施搭建： 为了在私有环境中拉取插件，用户可能需要单独部署和维护一个内部 OCI 仓库。这无疑增加了部署的复杂度和运维成本，对于仅需简单使用 Wasm 插件的用户而言，为了几个插件去搭建和管理一套完整的 OCI 生态，显得过于笨重。
• 插件迁移困难： 在不同私有化环境（如开发、测试、生产）之间迁移 Wasm 插件时，由于 OCI 仓库的独立性，往往需要用户手动进行插件的拉取、推送和版本管理，且需要适配不同仓库的认证和网络配置，这增加了操作的复杂性和出错的可能性。

2. 重复下载与性能开销：Always 策略的隐忧

Higress 网关拉取 Wasm 插件时，支持插件拉取策略的配置，默认为 IfNotPresent，即本地存在则不重新拉取。这在大多数情况下是合理的。但当用户希望 Wasm 插件能够及时更新（例如在开发测试环境中频繁迭代）或者希望确保始终使用最新版本的插件时，会倾向于将策略设置为 Always，导致以下问题：

• 网络延迟与带宽消耗： Always 策略意味着每次 Wasm 插件被引用或网关 Pod 重启时，都会尝试从 OCI 仓库重新下载插件。会引入不必要的网络延迟，并消耗带宽资源。
• 冗余操作： 即使插件内容没有变化，Always 策略也会触发下载。尽管 OCI 协议本身支持内容哈希校验，但客户端依然需要与仓库进行通信以确认。

3. 用户体验与操作复杂度：

上述问题共同导致了用户在配置和使用 Wasm 插件时，可能会面临不必要的复杂性。我们希望能够提供一种更简单、更符合直觉的插件分发方式，让用户能够更专注于业务逻辑的实现。

正是基于这些痛点，我们开发了 Higress Wasm 插件服务器。

概述

Higress 是一个基于 Istio 和 Envoy 的云原生 API 网关，具备先进的 AI 功能。通过 Go/Rust/JS 编写的 Wasm 插件提供可扩展的架构，并提供了基于 Node 和 Java 的 console 模块，使得用户可以可视化使用 Higress。

Higress 最初由阿里巴巴研发，旨在解决 Tengine 配置 reload 对长连接造成影响，以及 gRPC/Dubbo 服务负载均衡能力不足的问题，于 2022 年开源。如今，阿里云云原生 API 网关、MSE 云原生网关、专有云飞天企业版 API 网关等网关产品系列均采用了 Higress 的统一架构，它已成为阿里云 API 网关产品的基础。

本文主要面向开发者和开源爱好者，围绕 Higress 基本的架构，分享一些 Higress 的基本原理，欢迎一起共建 Higress。

Higress 产品介绍

网关产品在不同场景，不同发展阶段可能会加上很多修饰词前缀，这本质上是网关主要是一层代理，伴随着应用架构的演进，网关的身份也会发生转变。

正如单体式应用到 SOA 架构时 ESB 总线的称谓，微服务架构阶段时的微服务网关，K8s 云原生架构下的云原生网关，再到现如今 AI 时代的 AI 网关。可以发现不仅仅是 Higress 如此，传统的 API 网关产品以及国内外的 API 网关云厂商，都非常默契地将自家用户页面的入口换上了 AI 网关的皮肤。按照用户场景，Higress 可以有以下几种定位：

AI 网关

AI 网关相比传统 API 网关有了一些本质的变化：

	传统 API 网关	AI 网关
请求响应模型	无流式处理需求，多为 HTTP	流式处理，SSE/Streamable 协议支持
内容感知深度	根据 header/query/path 等部分进行流量转发	支持 OpenAI 协议，多模型协同，提示词改写，可能对流量需要有语义级别的理解
流控差异	Query Per Second	Token Per Second
内容安全	防御 DDos、SQL 注入等攻击手段	防御提示词注入、数据和模型投毒、无限资源消耗等攻击手段

AI 网关伴随 AI 原生架构演进，会提供各类 AI 原子能力和场景化能力，助力企业应用完成智能化升级。同时，随着越来越多 AI 的概念被提出，例如 MCP、A2A，为了解决对应的场景的问题，Higress 也提供了对应的解决方案，在这些场景下我们也可能会称呼 Higress 为 MCP 网关、Agent 网关。

作为一个 Web 开发，一定不会对下面的跨域报错陌生。

当一个资源从与该资源本身所在的服务器不同的域或端口请求一个资源时，资源会发起一个跨域 HTTP 请求。例如站点 http://www.aliyun.com 的某 HTML 页面请求 http://www.alibaba.com/image.jpg。

出于安全原因，浏览器限制从页面脚本内发起的跨域请求，有些浏览器不会限制跨域请求的发起，但是会将结果拦截。 这意味着使用这些 API 的 Web 应用只能加载同一个域下的资源，除非使用 CORS 机制（Cross-Origin Resource Sharing 跨源资源共享）获取目标服务器的授权来解决这个问题。

这也是本文将要探讨的主要问题，需要额外强调的是，跨域问题产生的主体是“浏览器”，这也是为什么，当我们使用 curl、postman、各种语言的 HTTP 客户端等工具时，从来没有被跨域问题困扰过。