Qoder Quest 1.0：把执行交给 AI，把选择留给人类
本文摘要：
- 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 模式的差异，以下是我的理解。
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 的用户是非专业开发人士。
其二是专业研发边界的延伸，我作为一个后端研发，在 Vibe Coding 前端代码时，也同样觉得前端代码是一件很“恐怖”的事情。并且个人的技术栈往往会左右代码设计，只懂 Java，就更倾向于用 Java 去解决问题，而仅仅是把问题抛出给 Qoder，它可能会选择用 Python、用 Rust，事实是，我们不应该让我们的知识储备成为 AI 的上限。
Quest 舍弃文件树导航，本质上是在传达一个信号：未来的开发者可能不再需要”阅读代码”，而是”阅读意图”。Spec 文档、测试用例、运行结果，这些才是需要人类关注的产物。代码本身变成了”中间产物”，就像汇编代码一样，专业人士偶尔会看，但大多数时候不需要。
human in the loop
人类在 AI Coding 中究竟应该扮演什么样的角色？我在实际开发过程中，Quest 和 Editor 模式的使用场景各占 50%，从我个人的感受上，Quest 模式下我会更像一个架构师，关注 Spec 设计、交付产物、提出问题，如此循环；而 Editor 模式下，我会更像导师，提出需求，验收代码。这实际上对应我不同的工作场景：
- 存量生产项目：我往往不追求方案的最优，更加追求少量改动带来的确定性，更适合 Editor 模式
- 非存量项目：我往往追求更高的交付效率，可以引入更加 AI 原生的技术栈，更适合 Quest 模式
这也并非说明 Quest 模式无法开发存量生产项目，更多是一种行为的偏好。
我相信产品的设计品味会使得其寻找到与其品味相符的用户。
自主编程 or 协同编程
诸如 spec、plan、interview 的实践，在 Quest 模式中都有对应的实现。
interview 机制
可以帮助模糊意图下用户需求的澄清：
spec 机制
既可以手动勾选，也可以靠模型决策自动触发
在 Quest 1.0 中，spec 依旧是非常重要的一个设计，但已不再是一个死板的 SOP。
在完成 interview 和 spec 后，Quest 模式表现出了区别于 Editor 模式的 Agent 流程，总体而言会更少地需要人类介入，更多的 AI 自主编程，而 Editor 模式中的 Agent 则表现为较强的人机协同。
实践案例：AI 网关压测项目
我选择了最近使用 Quest 模式比较多的一个 AI 网关压测项目来介绍 Quest 模式的实践。
项目背景
传统 API 网关的压测关注 QPS（每秒请求数） 和 RT（响应时间），但这套指标体系不适用于 AI 网关场景：
| 维度 | 传统 API 网关 | AI 网关 |
|---|---|---|
| 请求特征 | 短连接、快速响应（ms 级） | 长连接、流式响应（秒级到分钟级） |
| 响应模式 | 一次性返回完整响应 | SSE 流式传输，逐 Token 返回 |
| 核心指标 | QPS、RT | TTFT、TPOT、并发连接数 |
这使得常规的压测方案都不太适用于 AI 网关的压测，于是我打算用 Qoder Quest 从 0 到 1 构建一个压测方案。
由于篇幅限制，我不会完整地记录整个过程，而是挑选其中值得分享的经验跟大家进行探讨。
起手范式：spec driven
尤其是对于一个新项目，起手一定是 spec driven 模式，可以手动指定 spec driven 或者自然语言描述要求 spec 来触发。
在进行一系列需求澄清和执行后，Quest 产出了完整的方案。包含了以下几个主要组成部分：
- 一个施压程序
- 一个 mock-llm-server 用于模拟大模型
- 一个 report-server 用于展示最后的压测报告
- 一系列触发脚本
这里我并没有要求它指定 mock-llm-server 的技术栈实现，它选择了 Python 语言的 fastapi 构建，从最后的结果来看，这个选择是非常正确的，既轻量，也方便后续迭代。而作为对 Python 基本语法都不了解的我来说，基本告别了理解代码的可能性。
工程的持续迭代
而实际上，无论是因为需求一开始没有完全澄清，还是 AI 代码的缺陷，初版代码虽然可以运行，但的确有很多问题
- 未记录 mock 数据的 token，后续引入了 tiktoken 记录真实的 token usage
- 压测脚本存在拼接数据的 O(n²) 问题，大并发下一直超时
- 压测导致大量数据写入 pvc，导致高并发高 input/output 压测下任务一直失败
- …
问题一定会存在，而我想分享的是排查问题的过程，我发现我不再关注代码，仅仅是通过 Quest 把问题描述出来，以及提供现场运行时环境，大概率 AI 就能一次性修复正确。
skill 提升 Qoder 对环境的感知
为了提高 Qoder 对压测方案的开发效率，我做了几件事：
- 为所有需要部署的组件：压测任务、mock LLM 服务、压测报告服务，提供了 Dockerfile
- 项目的 helm chart
- 预置推送 ACR 的脚本
- 配置开发机器连接云端 K8s 集群
这样的好处是，可以直接通过跟 Quest 进行自然语言对话的方式完成代码变更后的自动构建、部署到环境中，并且发起压测任务，查看报告。
借助于 skill，Qoder 可以直接感知到我电脑连接的 K8s 集群，并下发压测任务
在需要修改代码后，也可以自动执行构建 -> 推送 -> k8s rollout，完成组件的更新。
整个过程其实是对 devops 的一次重构，Qoder 已经不再仅仅是一个 AI Coding 的工具：
- 从助手到执行者的角色升级。从辅助编码转向独立完成端到端的任务，支持自然语言驱动编码、测试、部署、调试的闭环
- 任务窗口的重构。对话界面成为任务中枢，Qoder 可以直接操作 K8s、调用 API、读取环境数据并生成报告
- 任务闭环实现无人干预。在无人工介入下，完成复杂的运维任务，验证端到端自动化的可行性。
而这一切，只需要 Quest 配合一点富有想象力的 skill 即可实现。而这个实践其实可以运用到任意的项目中，未来 devops 的流程都可能会发生变化。
为什么我不选择手动执行构建脚本、推送脚本、压测命令，可能这也很简单，但通过自然语言触发任务，可以让 Quest 获得更多的上下文，当压测失败时，可以自主进行探索，完成问题的修复，整个过程不会打断 AI Agent 的心流。随着这个实践，我也开始越来越不关注过程和手段，更加关注目标。
skill 的演进推演
能够实现上述的自然语言压测，主要还依赖我自己提供的 skill
当然，这么长的 skill 不会是我自己写的，目前 Qoder 还不支持自然语言生成 skill，不过可以直接把 Claude 官方的 skill-creator 这一 skill 引用进来，就可以达到自然语言创建 skill 的效果。
https://github.com/anthropics/skills/tree/main/skills/skill-creator
如果你是在 2 周之后看到我这篇文章，相信也不需要引用这个外部的 skill-creator 了，Qoder 应该很快就会支持自然语言创建 skill。
一个可以预见的未来是伴随着持续的自然语言对话和迭代，skill 的优化应该是自主沉淀和优化的，类似于被动记忆一样，这样才能完美契合 Quest 自主进化的宣传标语。
从写代码到设计反馈回路
这样一套具备环境感知力的设计，本质不是让 AI 写更多代码，而是让 AI 能够自己验证、自己修正。搭建这套环境（Dockerfile + Helm + 推送脚本 + skill），本质上是在构建一个反馈回路：AI 写代码 → 自动构建 → 自动部署 → 运行压测 → 看到结果 → 根据结果修正。这个回路里，人类只需要在”结果不符合预期”时介入。这让我想起一个类比：过去我们是”手工匠人”，一行一行写代码；现在我们更像”工厂设计师”，设计的是生产线本身，而不是产品。当为 Qoder 配置好 skill，让它能感知 K8s 集群、能下发任务、能读取报告，实际上是在设计一条”AI 驱动的 DevOps 流水线”。流水线一旦建好，生产就变成了自然语言驱动的事情。
报告总结
经过 3 天 + 8000 credits 的投入，最终的压测产物有两份：
一个是用于详细对比经过 AI 网关和直连 mock LLM 服务的报告
压测任务列表：
挑选两份报告进行对比：
一个是用于展示 AI 网关压测结果和用于指导容量评估的文档，没有任何意外也是靠 Quest 产出的：《Higress AI 网关性能评估报告》
一些感慨
我自身对于 AI Coding 的认知升级一直是螺旋式上升的过程，现在的自己也在否定过去两个月的一些认知，AI 发展实在太快了。
软件行业正面临一个奇怪的拐点，未来也充满着不确定性。
随着 AI 包办大部分代码，人类的核心编程技能可能退化，更多转向监督验收的角色，大多数人的代码技能可能会永远停留在此刻。过去我们说”技术债”：为了快速交付而留下的代码质量问题。AI 时代会出现一种新的债务：因为 AI 代劳而失去的认知能力。比如，如果你从来不手写 SQL，你可能永远不理解索引优化的原理；如果你从来不手写并发代码，你可能永远不理解死锁是怎么发生的。这些”理解”在大多数时候看起来不重要——直到你遇到一个 AI 解决不了的问题。认知债务的可怕之处在于：你不知道自己欠了多少债，直到你需要还的那一天。所以，一个实用的建议是：偶尔关掉 AI，手写一些代码，保持对底层的敏感度。不是为了效率，而是为了在 AI 失灵的时候，你还有能力接管。
再回到开头的话题，人类区别于 AI 的核心能力，我的答案是“品味”。
品味的本质不是”选择做什么”，而是”选择不做什么”。AI 是没有边界感的。你让它加一个功能，它就加；你让它重构，它就重构。它不会问”这个功能真的需要吗”、”这个重构值得吗”。它没有”够用就好”的概念，因为它没有为结果负责的利益相关性。而品味，恰恰来源于我曾经做了不该做的事，踩过的坑、背过的锅、半夜被叫起来修的 bug。这些痛苦的记忆形成了一种直觉——“这么做会出事”。AI 可以从海量代码中学习模式，但它学不到”凌晨三点被 oncall 电话吵醒”的那种刻骨铭心。所以，当在 AI Coding 时思考”我可以选择不做这个事吗”，实际上是在行使一种 AI 永远无法拥有的能力：为结果负责的审慎。
品味来源于经验、来源于对业务的理解、来源于你踩过的坑。Qoder Quest 的设计哲学，本质上就是在说：把执行交给 AI，把选择留给人类。
Qoder Quest 1.0：把执行交给 AI，把选择留给人类
