前言

最近 AI 热点实在太多了，我的钉钉工作群、朋友圈基本被 Claude Cowork、OpenClaw 这些新产品、新概念刷屏了，想不关注到都难。就在 1月底，Qoder 发布了 QoderWork 新产品， 跟上边两个工具定位类似，但做了国内适配，免去了复杂的安装步骤，我也是迫不及待试用了一下，跟大家一起看看是怎么一回事。

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

QoderWork 是什么？

QoderWork 定位是桌面级通用智能体助手，slogan 叫 “为真实工作而生”。Qoder IDE/Qoder CLI/Qoder JB 更多还是开发者在使用，QoderWork 则覆盖到日常办公场景的所有人群。与传统 AI 助手的对话式交互不同，QoderWork 是”任务驱动”的工作流引擎。

可以在左下角切换【语言】，在【设置】中配置 Skill 和 MCP。可以看到内置的 Skill 包含了 word、pdf、ppt 等常见办公场景涉及到的文档格式。也支持自定义 Skill，在本文后边的章节里面我也会分享我个人的一些工作流和自定义 Skill。

官方给出的三类主要场景：

• 文件整理：智能整理和管理本地文件。提示词示例：扫描我的 Downloads 文件夹，找出所有重复的文件，保留最新版本。
• 内容创作：创作演示文稿、文档和多媒体内容。提示词示例：生成一个用于演示光的折射原理的动画视频，并帮我制作一个 PPT 课件，将这个视频作为素材插入 PPT 中。
• 文档处理：处理和分析文档数据。提示词示例：将『提案文件』文件夹中的 10 份 Word 文档统一调整为：标题宋体加粗 18 号、正文宋体 12 号、1.5 倍行距、首行缩进 2 字符。

文件整理

如果没有 QoderWork，我更倾向于把所有日常工作用到的文件全堆到 Download 目录下，寻找最近使用的文件还可以按照时间排序，但是想要定位一些之前的文件，就很麻烦了。经过 QoderWork 整理后，瞬间清爽多了。可能这么一项技能还不足以打动你，不过这只是开胃菜。

制作 PPT

作为一个知识分享博主，我比较熟练的是进行文字内容的创作，但是偶尔也会进行一些现场技术交流，这里就涉及到将 markdown 格式的文字稿转成 PPT 的工作了，如果没有 QoderWork，我需要自己完成：观点提取、章节拆分、内容精简、排版等一系列复杂的工作，在 QoderWork 下一切变得简单了。

可以发现基本已经能用了，但排版和配色缺乏品牌调性，而且有浓浓的 AI 味道——没错，是 AI 偏爱的渐变紫。不过别急，我们可以通过 Skill 来定制特定风格。比如我这里准备了一个 Qoder 品牌风格的 Skill 来指导 QoderWork 生成 PPT。

这给我一个启发：有没有 Skill 差距很大。未来即使使用相同的 QoderWork 产品，不同人搭配不同的 Skill，制作出来的产物质量也会有显著差异。

Quest 1.0 的底座架构：为 SOTA 模型而生

任何一个产品都有其发展历史，Editor 模式是 Qoder 产品的立身之本，这要求 Editor 模式遵循一个渐进式演进的规则，典型的差异就是 Editor 模式需要适配不同模型，提供 Auto、极致、性能、经济、基础不同模式供用户选择，而 Quest 模式则更加幸福，没有提供切换模型的选项，尽管对于其背后实际使用的模型不得而知，但基本可以猜想到是 opus、codex、gemini 的组合，这就意味着 Quest 模式只需要为 SOTA 进行适配，这与我之前文章提出的“Token 效率法则”理念不谋而合，不关注模型单价，而转向追求 Token 效率及最终产物的质量。

这样的选择可以让 Quest 模式的 Agent 架构可以专注于 SOTA 模型，随着 SOTA 模型的发展，使其最快地接近 SOTA Coding Agent。

Quest 1.0 的品味：有些东西可以选择不做

Quest 1.0 舍弃了文件树导航，单文件代码对比等 Editor 模式中常用的功能，Quest 的对话窗口则占据了 IDE 较大的视图占比，对于专业开发来说似乎是一件反直觉的事情，而如果换一个角度来思考又似乎代表了 Quest 自身的品味。

其一是对非专业开发的吸引力，代码和文件导航对于非专业人士来说是一件很“恐怖”的事情。以 AI Coding 产品老大哥 Cursor 的用户画像来看，已经有相当一部分 Cursor 的用户是非专业开发人士。

Quest 舍弃文件树导航，本质上是在传达一个信号：未来的开发者可能不再需要”阅读代码”，而是”阅读意图”。Spec 文档、测试用例、运行结果，这些才是需要人类关注的产物。代码本身变成了”中间产物”，就像汇编代码一样，专业人士偶尔会看，但大多数时候不需要。

human in the loop

人类在 AI Coding 中究竟应该扮演什么样的角色？我在实际开发过程中，Quest 和 Editor 模式的使用场景各占 50%，从我个人的感受上，Quest 模式下我会更像一个架构师，关注 Spec 设计、交付产物、提出问题，如此循环；而 Editor 模式下，我会更像导师，提出需求，验收代码。

实践案例：AI 网关压测项目

传统 API 网关的压测关注 QPS（每秒请求数） 和 RT（响应时间），但这套指标体系不适用于 AI 网关场景：这使得常规的压测方案都不太适用于 AI 网关的压测，于是我打算用 Qoder Quest 从 0 到 1 构建一个压测方案。

工程的持续迭代

而实际上，无论是因为需求一开始没有完全澄清，还是 AI 代码的缺陷，初版代码虽然可以运行，但的确有很多问题。1. 未记录 mock 数据的 token，后续引入了 tiktoken 记录真实的 token usage。2. 压测脚本存在拼接数据的 O(n²) 问题，大并发下一直超时。3. 压测导致大量数据写入 pvc，导致高并发高 input/output 压测下任务一直失败

问题一定会存在，而我想分享的是排查问题的过程，我发现我不再关注代码，仅仅是通过 Quest 把问题描述出来，以及提供现场运行时环境，大概率 AI 就能一次性修复正确。

Agentic Coding 是一种新范式

Agentic Coding 不仅仅是代码补全，更是一种全新的开发范式。从 Prompt Engineering 到 Context Management，这里有你在使用 Qoder 开发真实项目时需要知道的一切避坑指南。传统的 IDE 辅助开发更多是“补全”，而 Agentic 开发则是“意图实现”。你不再是输入代码片段，而是输入业务逻辑和约束条件。

在实践中，我们发现很多开发者习惯于直接让 AI 生成大段代码，却忽视了上下文管理。Qoder 的核心优势在于它能够理解整个工程的结构，而不仅仅是当前打开的文件。因此，如何构建高质量的 Context，成为了新一代开发者必须掌握的技能。

Prompt Engineering 的重要性

一个好的 Prompt 应该包含明确的目标、清晰的约束以及必要的上下文。比如，“实现一个用户登录功能” 是一个糟糕的 Prompt，而 “基于 Spring Security 实现一个支持 JWT 认证的用户登录接口，Token 有效期为 1 小时，需要处理账号锁定逻辑” 则是一个高质量的 Prompt。

此外，迭代式的 Prompt 交互往往比一次性生成效果更好。先让 Agent 生成接口定义，确认无误后再生成实现逻辑，最后补充单元测试。这种分步走的策略能显著提高代码的可维护性。

深度使用心得

深度使用 Qoder 两个月后的心得体会。它不仅仅提高了编码速度，更改变了我的设计思维。在接触 Qoder 之前，我习惯先写代码再重构；而现在，我更倾向于先写文档，让 Qoder 理解我的设计意图，然后再生成代码。这种“文档驱动开发”的模式，让我的代码结构更加清晰。

日常开发中，遇到复杂的正则表达式、SQL 查询优化，甚至是老旧代码的重构，Qoder 都是得力助手。例如，有一次我需要将一个几千行的遗留类拆分为多个单一职责的类，手动操作可能需要半天，而 Qoder 配合适当的 Prompt，仅用了十分钟就完成了初版重构。

设计思维的转变

最大的改变在于，我开始更多地关注“做什么”而不是“怎么做”。具体的实现细节可以交给 AI，而我会把精力集中在系统架构、核心业务逻辑以及边界条件的定义上。这种思维转变让我从繁琐的 coding 中解脱出来，有更多时间去思考更高层面的问题。

什么是 MCP？

Higress 作为云原生网关，正式引入 MCP (Model Context Protocol) 支持。这意味着你现在可以轻松地管理和分发你的 AI 插件，构建企业私有的 MCP 市场，赋能内部 AI 应用开发。MCP 是 Anthropic 推出的一套标准协议，旨在标准化连接大模型与外部上下文的方式。

Higress 的 MCP 支持

通过 Higress，企业可以统一管理所有的 MCP Server，无论是连接数据库、知识库，还是内部 API。Higress 提供了开箱即用的 MCP 适配器，能够将传统的 HTTP 接口自动转换为 MCP 协议，大大降低了 MCP 生态的接入门槛。

不仅如此，Higress 还提供了完善的鉴权、限流、可观测性能力，确保 MCP 服务在生产环境中的稳定运行。对于希望构建企业级 AI Agent 平台的团队来说，Higress 无疑是一个强有力的基础设施。

Wasm 插件的挑战

Wasm 插件为网关扩展带来了无限可能，但私有化部署一直是个痛点。开发环境与生产环境的异构、编译工具链的复杂性，都阻碍了 Wasm 插件的广泛应用。Higress Plugin Server 的出现解决了这一难题，提供了标准化的 Wasm 插件运行环境和管理能力。

解决方案

Higress Plugin Server 提供了一套完整的工具链，支持 Go, Rust, C++ 等多种语言编写插件，并能够一键编译、打包、推送到私有仓库。在运行时，Plugin Server 负责插件的动态加载、热更新以及资源隔离，确保了网关核心进程的稳定性。

通过这种解耦的设计，开发者可以专注于业务逻辑的实现，而无需关心底层的 Wasm 运行时细节。这对于需要在私有环境下定制网关逻辑的企业来说，是一个巨大的利好。

加入开源社区

想要参与 Higress 社区贡献却无从下手？这篇全攻略为你梳理了从代码环境搭建、Issue 认领到 PR 提交的完整流程，带你一步步成为 Higress Contributor。参与开源不仅是贡献代码，更是与全球优秀开发者交流学习的机会。

贡献流程

1. Fork 仓库并 Clone 到本地。
2. 阅读用于指南，配置开发环境。
3. 在 Issue 列表中寻找 `good first issue`。
4. 提交 PR 并参与 Code Review。

Higress 社区非常欢迎各类贡献，包括但不限于文档改进、Bug 修复、新特性开发以及测试用例补充。我们相信，开源的力量在于协作，每一个 PR 都是对生态的一份贡献。

网关的核心职责

微服务网关是微服务架构中的守门员。它负责请求路由、负载均衡、认证鉴权、限流熔断等核心功能。本文深入结合生产实践，探讨 SpringCloud Gateway 的路由配置、限流熔断、鉴权认证等核心场景的最佳实践配置。

性能优化

在生产环境中，Gateway 的性能至关重要。我们建议使用 Reactor Netty 作为底层容器，并开启连接池复用。对于高并发场景，合理的线程池配置和内存调优也是必不可少的。

高可用部署

Gateway 自身必须是高可用的。通常我们会采用多节点部署 + Nginx 负载均衡的方案。同时，配置动态路由存储（如 Nacos 或 Redis），实现配置的热更新，避免重启网关导致的服务中断。

EDAS 赋能网关

在阿里云 EDAS 环境下运行 Spring Cloud Gateway 需要注意什么？如何利用 EDAS 提供的无损上下线、全链路灰度等能力增强网关的稳定性与可观测性？EDAS 提供了一整套微服务治理能力，能够极大地简化 Gateway 的运维工作。

无损上线

网关作为流量入口，发布时的抖动是不可接受的。EDAS 通过小流量预热、就绪检查等机制，确保新节点完全 ready 后才承接流量，实现了真正的无损发布。

全链路灰度

基于网关的灰度发布是常见的需求。EDAS 支持通过 Header、Cookie 等条件进行流量染色，并透传至后端整个微服务链路，实现全链路的灰度验证。这对于复杂微服务架构的新版本验证非常有效。

CORS 原理

跨域资源共享 (CORS) 是前端开发中绕不开的话题。本文从原理出发，详细解释了简单请求与预检请求的区别，以及如何在后端正确配置 CORS 策略。CORS 全称 Cross-Origin Resource Sharing，是浏览器的一种安全机制，用于限制不同源之间的资源交互。

预检请求 (Options)

当请求满足一定条件（如使用了自定义 Header，或者 Put/Delete 方法）时，浏览器会先发送一个 Options 请求询问服务器是否允许。只有服务器返回了正确的 Access-Control-Allow-Origin 等头信息，浏览器才会发送真正的业务请求。

最佳配置实践

在 SpringBoot 中，我们可以通过 filter 或者 WebMvcConfigurer 来全局配置 CORS。建议在生产环境中不要简单地配置为 *，而是通过白名单机制精确控制允许的域名，以确保安全性。