写在前面

AI Coding 交流群中最老生常谈的一个问题便是，大家都是订阅的什么工具，这个问题太频繁了，以至于我觉得有必要写一篇文章，如果愿意拿出 200 美元左右订阅 AI 工具，这笔钱到底该怎么花？

这事儿放在半年前，我可能会说：挑一个顺手的工具，买些额度就行。但现在我的答案变了。

AI 编程工具和通用 AI 产品在过去半年迭代得太快，已经不是简单的“买 Token”问题。尤其是 200 美元这个预算，对大多数个人开发者来说并不便宜，所以它必须同时回答两个问题：第一，能不能实实在在提升我的生产力；第二，能不能帮我建立对 AI 工具和工作流的判断力。

我觉得订阅几款头部产品至少有四层价值。

第一，是直接提升生产力。 这不是一个虚的理由。一个靠谱的 AI 编程工具，确实能帮你更快读懂陌生代码库、更稳地改跨文件需求、更省力地写测试、补文档、做调研。只要你每周有几次真实开发任务能被它加速，订阅费就不只是“尝鲜成本”，而是实打实的工具投入。

第二，是认知层面的更新。 AI 编程工具的变化速度非常夸张，每家的产品设计、Agent 架构、上下文管理方式都不一样。光看博客、发布会和评测，拿到的是二手信息；亲手用一个月，得到的是肌肉记忆。这种“知道”和“用过”的差距，在你和团队讨论方案、和客户聊产品、判断技术趋势时会立刻显现出来。

第三，是看看最先进的 AI 产品长什么样。 MCP、Skill、Plugin、Cowork、Spec Workflow、Harness Engineering 这些正在影响行业的新范式，很多都是 Anthropic、OpenAI 这类一线团队率先推出来的。订阅它们的产品，不只是为了多一个工具，而是为了第一时间摸到最新的产品边界。

第四，是看清 AI 当下的能力上限。 AI 时代选工具不是挑一把瑞士军刀，而是要在关键场景里用最强的那一档：写复杂代码看 Claude，做图片和多模态创作用 ChatGPT，做深度调研可以用 Deep Research，长任务自治可以看 Kiro。只有亲手体验过每家最强的部分，你才会真正知道当下 AI 能做到什么程度，否则很容易被零散评测或单个观点带偏。

所以下面这篇不是严格意义上的工具横评，而是我自己花钱、花时间订阅和使用之后的体感总结。按推荐顺序聊一下。

---

Claude —— 如果只能订一个，闭眼选它

前言

这是我”AI Coding 经验总结”系列的第五篇文章。前几篇聊的是工具选型、工作流范式、Harness Engineering 这些偏宏观的话题，这篇回到一个更具体的问题：怎么写好一份 AGENTS.md？

「在代码仓库中放一份上下文文件，告诉 AI 工具这个项目是什么、怎么构建、有什么规矩」——这个做法现在已经有了一个统一的名字：AGENTS.md。在展开实践之前，先花一点篇幅介绍它的前世今生，已经了解的同学可以跳过。

AGENTS.md 是什么？

AGENTS.md 是一个简单的开放格式，用于指导 AI Coding Agent 在你的项目中工作。你可以把它理解为给 AI 看的 README——README.md 是给人类看的项目说明，AGENTS.md 则是给 AI Agent 看的项目指令，包含构建命令、编码规范、测试要求、安全注意事项等 AI 需要知道的上下文。

官方建议的使用方式很简单：

1. 在仓库根目录创建一个 AGENTS.md 文件
2. 写上对 Agent 有用的内容：项目概述、构建测试命令、代码风格、安全注意事项
3. 补充额外指引：commit 规范、部署步骤、安全陷阱——任何你会告诉项目新成员的东西
4. 大型 monorepo 可以在子目录放嵌套的 AGENTS.md，Agent 会读最近的那个（OpenAI 自己的仓库有 88 个 AGENTS.md）

格式上没有任何强制要求，就是标准的 Markdown，用什么标题、写什么内容完全自由。

前世今生

这个概念最早由 Anthropic 通过 Claude Code 的 CLAUDE.md 普及。Claude Code 运行时会自动加载当前目录下的 CLAUDE.md，把内容注入到发给模型的请求中。这个设计简单而有效——维护好一份上下文文件，Agent 的表现就会变好；表现变好了，你就更愿意用它，进而更愿意维护这份文件，形成正向循环。

随后各家 AI Coding 工具跟进了自己的版本，一度各自为政：

工具	上下文文件
Claude Code	CLAUDE.md
Cursor	.cursorrules / .cursor/rules
Copilot	.github/copilot-instructions.md
Gemini CLI	GEMINI.md
Cline	.clinerules
AMP (Sourcegraph)	AGENT.md（单数）
OpenAI Codex	AGENTS.md（复数）

这种碎片化意味着团队需要为不同工具维护多份内容相同的配置文件，改一次规则要同步好几个地方。

2025 年 5 月，Sourcegraph 旗下的 AMP 率先提议统一标准，建议用 AGENT.md（单数），并注册了 agent.md 域名。随后 OpenAI 宣布买下了 agents.md 域名，提议用 AGENTS.md（复数），理由是多个 Agent 会共用同一份配置。AMP 随即主动让步对齐，将 agent.md 重定向到 agents.md。

最终 AGENTS.md 成为事实标准，由 Linux Foundation 下属的 Agentic AI Foundation 托管。截至 2026 年初，GitHub 上已有超过 6 万个开源项目使用这个格式。Cursor、Kiro、灵码、Qoder、Copilot 等主流工具均已支持。Claude Code 虽然仍用 CLAUDE.md，但内容完全通用，一个软链接即可兼容：ln -s AGENTS.md CLAUDE.md。

过去半年里，我为手头的多个项目都维护了 AGENTS.md——有管控系统、有内核引擎代码、有产品基线、也有文档系统。不同项目的技术栈、仓库结构、团队规模各不相同，但在 AGENTS.md 的实践上逐渐收敛到了一套相似的方法论。这篇文章我挑了其中投入最多、也最通用的一个场景——管控系统（Spring Boot + React 的前后端分离项目）来展开介绍，希望对正在写或者想写 AGENTS.md 的同学有参考价值。

本文摘要：

• 从零配置一台博客服务器的完整实践：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 插件服务器。