Repo Wiki ：让隐性知识自动浮现

---

desc: 支持repo wiki 共享和导出
category: 产品
img: https://img.alicdn.com/imgextra/i2/O1CN01c6LKGp1NGHqns4lxb_!!6000000001542-0-tps-1712-1152.jpg
time: 2025年9月11日 · 3分钟阅读

Repo Wiki 能为你做什么？

Repo Wiki 能基于代码自动为你的项目生成结构化的文档知识库，涵盖项目架构、引用关系图谱、技术文档等内容，并持续跟踪代码与文档的变更。让隐藏在代码中的经验性知识，变为团队可共享的显性知识，把经验沉淀为可复用的工程资产。在使用 Qoder 开发过程中 Repo Wiki 可以帮助你：提升与智能体的协作效率结构化且完整的工程知识让智能体更深入理解上下文，提供更准确、详尽的回答，显著提升研发效率。快速理解陌生项目通过查阅清晰完整的工程文档，让你快速掌握项目结构与实现细节，轻松上手开发，降低协作与维护成本。

Repo Wiki 是如何生成的？

Repo Wiki 采用多 Agent 架构，分阶段逐步生成工程知识。Repo Wiki会自动为代码库建立索引，从而通过工具为 Agent 提供强大的工程感知能力。多 Agent 系统会对代码库进行分析建模，规划文档结构，平衡知识深度和阅读效率，将工程知识合理刻画到各类文档中。

Repo Wiki 是如何维护和共享的？

知识共享为了让知识更好地在团队中流转，我们提供了 Wiki 共享能力。当你在本地生成 Wiki 时，系统会自动在代码库中创建一个专属目录（.qoder/repowiki）。只需将该目录推送至远程分支，即可将生成的文档轻松共享给团队成员，实现协作共建。内容维护及导出

为确保 Wiki 与代码始终保持一致，我们内置了自动检测机制。当发现代码变更导致文档滞后时，系统会及时提醒你更新 Wiki。同时，为了支持灵活的自定义维护，你也可以直接修改 .qoder/repowiki 目录下的内容，修改后可同步 Wiki， 实现自行维护的诉求。

最佳实践 

• 智能对话场景

查询代码库信息时，智能体会自动查阅 Repo Wiki 相关知识，结合上下文信息，为开发者提供准确的代码解释、相关的技术文档、完整的实现细节等，智能体可以基于 Repo Wiki 的知识库，快速且准确地回答开发者的各类问题。在新增功能或修复缺陷时，智能体会自动查阅 Repo Wiki 的顶层架构设计，结合实时的工程感知信息，提供符合项目架构的解决方案，这样可以确保新增的代码与现有系统保持一致性，同时提高开发效率。

• 代码库阅读场景

开发者可以在日常开发中通过 Repo Wiki 快速了解项目的整体架构、模块依赖关系和技术实现细节。它提供了结构化的文档知识库，如项目架构说明、模块间引用关系图谱、详细的技术文档等，这些信息可以帮助开发者更快地理解陌生的代码库，提高开发效率。

Qwen-Coder-Qoder：针对真实软件场景定制快速进化的前沿模型

---

desc: 揭秘 Qwen-Coder-Qoder：为 Qoder 量身定制的强化学习模型
category: 产品
img: https://img.alicdn.com/imgextra/i3/O1CN01fbHceT1K4t9NQua1T_!!6000000001111-2-tps-1712-1152.png
time: 2026年2月1日 · 5分钟阅读

引言

今天，我们很高兴地发布一款为提升 Qoder 端到端编程体验而打造的定制模型——Qwen-Coder-Qoder。

这款模型基于 Qwen-Coder 基座，并紧贴 Qoder 的 Agent 框架、工具与场景进行了大规模强化学习训练。在我们的面向真实软件工程任务的评测集 Qoder Bench 上，Qwen-Coder-Qoder 的任务解决率超过了 Cursor Composer-1，尤其在 Windows 系统下的终端命令准确率方面，领先幅度达到 50%。

同时，Qwen-Coder-Qoder 也为 Qoder 的线上用户体验带来了切实的、数据可证的提升。在过去数周，得益于我们对模型的快速迭代，我们观察到线上代码留存率提升了 3.85%，工具异常率下降 61.5%，Token 消耗下降 14.5%，数据整体已接近世界顶级模型水平。

除了效果上的优异表现，Qwen-Coder-Qoder 在许多方面都展现出更接近资深开发者的"品味"和"思维"。我们认为，一个优秀的 AI 编程伙伴，不仅要能解决问题，更要解决得漂亮、解决得地道。

• 遵循软件工程规范：许多通用模型在训练时以"解决问题"为唯一目标，倾向于"另辟蹊径"，绕开现有框架。而 Qwen-Coder-Qoder 在训练中被引导去严格遵循工程规范，保持与项目一致的代码风格，确保代码质量。
• 理解完整项目上下文：通过学习 Qoder Agent 特有的工具和上下文数据（如代码图谱、项目记忆、Repo Wiki 等），Qwen-Coder-Qoder 能够从全局视角理解代码仓库，精准地使用工具完成任务。
• 高效的并行处理能力：它能够识别逻辑上无依赖关系的工具调用任务，并行执行代码检索、任务规划、多位置代码修改等操作，显著提升执行效率。
• 坚韧的问题解决能力：在面对复杂或棘手问题时，通用模型在多次失败后往往会放弃。而 Qwen-Coder-Qoder 则展现出更强的"开发者思维"：持续尝试，直至问题解决。

我们的模型理念："模型-智能体-产品"的智能进化体系

Qwen-Coder-Qoder 的诞生并非偶然，它是 Qoder 智能进化体系的必然产物。

当前 AI Coding 领域正在快速发展，我们着力构建了一个"模型即 Agent，Agent 即产品，产品增强模型"的智能进化体系。模型是这一切的基础，我们将 Qoder Agent 需要的各种能力都训练到 Qwen-Coder-Qoder 中，这个模型直接驱动 Agent 来执行任务。在产品设计上，Agent 是我们的核心，一切功能都围绕 Qoder Agent 展开。产品触达万千用户，可以感知用户的真实行为和偏好，从中我们发掘出"软件工程的最佳开发实践"来作为奖励信号，增强模型的训练。

这形成了一个大模型软件工程智能的进化体系。Qwen-Coder-Qoder 正是基于真实产品环境、真实软件开发任务、真实软件开发奖励而训练的大规模强化学习模型。

背后探秘：我们如何实现这一切

实现这一切，需要一套扎实且先进的训练方案。我们将此归结为三个核心要素：

真实的 Qoder Agent 作为沙盒环境

我们让模型充分学习综合使用 Qoder 的 Knowledge、Memory、Tools/MCP、Context 等来解决真实编程任务，相比通用模型，我们的模型和我们的产品能够做到最好的契合，随着模型训练的不断迭代演进，这种优势正在不断释放出价值。我们还打造了一条完整的自动化可执行环境构建链路，产出大量真实项目的可执行环境。在训练过程中，依靠强大的虚拟化容器技术，可快速拉起和销毁数万级别的容器，以满足大规模强化学习训练的需求。

真实的软件工程最佳实践作为奖励信号

Reward 在智能体的训练中尤为重要，我们启用了多种正确性的验证方式，包括单元测试验证、命令行验证、多维任务验证等，确保智能体正确地解决问题。与此同时，我们还对过程做了更多的约束，确保变更符合软件工程规范，如：编码风格、复用性和耦合度等，使解决方案无论是方案思路、编码风格均与资深开发者对齐。

在 Reward 的构建过程中，Reward Hacking 是绕不开的话题，比如我们想提高模型并行度，如果只要并行调用就得到奖励，那么模型为了骗取奖励就会搜索大量不相关或者弱相关的文件，使得并行度大幅提升，但对最终的正确性没有带来实质的贡献。Reward Hacking 的解决过程就是与大模型强化学习"斗智斗勇"的过程，为此我们专门构建了一套 "Rewarder - Attacker" 对抗式审查机制，这套机制有效地提升了 Reward 系统构建的速度和健壮性。

大规模高效的强化学习训练框架

Qwen-Coder-Qoder 使用 ROLL 训练。ROLL 通过一系列系统级优化，让数千卡规模集群能够高效完成数千亿参数 MoE LLM 的 RL 后训练。在每轮包含 rollout 与 training 的流程中，rollout 往往占用 70% 以上时间。为提升端到端吞吐，我们一方面优化 rollout 阶段本身（异步调度减少等待、prefix/KV cache 复用消除冗余计算、冗余环境对抗长尾等），另一方面优化 rollout–training 协同（放宽 on-policy 约束、支持跨版本样本生成、training 与 rollout 异步并行、等待时让渡 GPU 给 rollout 等）。综合这些优化，实际获得 10× 以上吞吐提升，显著缩短训练周期。

未来展望

今天发布的 Qwen-Coder-Qoder，是我们基于"模型即 Agent，Agent 即产品，产品增强模型"的智能进化体系打造的初版模型。在过去短短几个月的过程中，我们已经看到了模型对整体端到端体验提升的巨大潜力。

这只是一个开始。我们将继续坚定地沿着这条路，通过周级别的快速迭代进化，不断提升模型的效果和使用体验，朝着"Agentic Coding Platform for Real Software"的目标不断迈进。

Qoder 重磅升级，推出 Quest Remote 功能，像发邮件一样将任务委派到云端

---

desc: 云端处理代码任务
category: 功能
img: https://img.alicdn.com/imgextra/i4/O1CN01rVNSWR22RBWIKqmk8_!!6000000007116-2-tps-1712-1152.png
time: 2025年10月22日 · 3分钟阅读

近期，Qoder 核心功能 Quest 模式迎来里程碑式升级，推出全新的“远程委派”功能，允许开发者将复杂的、耗时的开发任务一键委派至云端沙箱环境中异步执行，彻底解放本地计算资源，为全球开发者带来高效与安全的 AI 原生开发体验。远程委派功能的上线，将开发者从这些“后台噪音”中解放出来，回归编码的纯粹乐趣与价值创造的核心。

什么是远程委派？

我们有必要重温 Quest 的核心设计哲学——“任务委派”（Task Delegation）心智。在 Qoder 里，我们将每一个开发需求，无论大小，都抽象为一个“Quest”的任务。一个任务可以是一次Bug修复、一个新功能开发，甚至是一次复杂的代码重构。传统的开发模式，是开发者一步步完成 Quest 中的所有环节。

而 Qoder 的 Quest 模式，旨在引入一位能力出众的编码 Agent，将开发者从“执行者”提升为“指挥官”，在本地与智能体对话生成 Spec，然后通过 Spec 驱动编码智能体完成开发任务。 开发者不再需要关注每一个琐碎的实现细节，而是将意图清晰地传达给系统，由系统来规划路径并执行任务。这便是“任务委派”心智的雏形。

此前，Quest 模式更多地是将开发任务委派给本地环境中的智能体，通过智能体生成代码、自动化测试等方式，辅助开发者完成任务。它极大地提升了编码阶段的效率，但对于环境、资源、安全等更深层次的束缚，仍有待突破。

今天，“远程委派”功能的发布，正是对“任务委派”心智的终极诠释。它将委派的边界，从本地辅助彻底拓展到了云端执行。

远程委派的操作流程

想象一下，你正在面对一个极度复杂的任务：需要为一个拥有海量陈年代码的项目，进行全面的依赖升级和性能重构。在过去，这意味着你需要在本地克隆整个仓库，小心翼翼地安装陈旧的依赖，然后开始一场漫长且充满不确定性的“战斗”。

现在，有了 Qoder 的远程委派功能，你的操作将是：

1. 创建 Quest

   在 Qoder 中创建一个新的 Quest，用自然语言描述你的任务目标。

2. 产出设计文档

   Quest 根据和你的对话生成对该任务的详细设计文档。

3. 一键委派

   你确认设计文档没有问题后，直接点“Start”将任务直接委派到云端执行。

4. 回归专注

   接下来你就可以继续处理其他更需要你创造力的工作。

背后发生了什么？

当你点击“委派”的瞬间，Qoder 已经为你做了以下所有事情：

• 智能环境配置

  Qoder 在云端瞬时启动一个隔离的、安全的、高性能的沙箱环境。它会自动分析你的项目代码库，智能识别所需的开发环境、语言版本、工具链和所有依赖项，并在沙箱中完成预配置。

• 异步任务执行

  一个强大的云端代理（Agent）接管了你的任务。它会像一位资深的开发者一样，克隆代码、分析依赖、执行升级、运行编译、定位并尝试修复错误、循环执行测试……所有这一切，都在云端服务器上以最高效率异步进行。

• 实时状态追踪

  你可以随时在 Qoder IDE 中，像查看物流信息一样，清晰地看到任务的实时进展。当前正在执行哪个步骤？遇到了什么障碍？AI 代理正在尝试何种解决方案？一切尽在掌握。

• 人机协作无缝切换

  当云端代理遇到无法自主决策的难题时，它会暂停任务并通过 Qoder 通知你，请求你的决策。你可以在 Qoder IDE 中查看上下文，给出指令，然后让代理继续执行。

• 成果审查与合并

  当整个 Quest 完成后，Qoder 会为你准备好一份详尽的报告，包括任务总结、代码变更等等。最终的代码会以一个 Pull Request 的形式提交到你的代码仓库，等待你的最终审查和合并。

远程委派的核心价值

Quest Remote 模式，将为开发者带来巨大的价值。

• 解放生产力：将繁重、重复的任务委派出去，让你专注于最富创造性的工作——思考、设计和创新。

• 加速学习与探索：想要尝试一门新的技术或框架？无需在本地搭建复杂的环境，一键委派，即可在云端沙箱中快速验证你的想法和代码，极大降低了新技术的学习成本。

• 拓宽边界：将一个开发任务委派给 Remote Agent，当你合上电脑的时候，它依然在云端勤奋地执行，进一步拓宽了 AI Coding 的时空边界。

• 拥抱未来：远程委派功能，本质上是将开发工作流本身进行了“云原生”改造。它让开发过程与最终的应用部署环境更加贴近，是通往真正的 DevOps 和云原生开发文化的关键一步。

将重复交给云端，把专注还给思考。欢迎升级 Qoder 到最新版本 0.2.4，体验 Quest Remote 新能力。

自进化的自主编程：Quest 如何重构了 Quest

---

desc: Token 产出的不是代码，而是可交付的产物
category: 技术
img: https://img.alicdn.com/imgextra/i2/O1CN01dz3f931IyBjmbJ4B0_!!6000000000961-2-tps-1712-1152.png
time: 2026年1月15日 · 8分钟阅读

上周，Quest 团队用 Quest 1.0 完成了一项长达 26 小时的复杂任务：重构自身的长程任务执行逻辑。这个任务不是简单的功能迭代，因为涉及到交互层的流程优化、中间层的状态管理、Agent Loop 的逻辑调整，以及长程任务执行能力的验证。

从需求定义到代码合入主干，整个过程中 Quest 团队只做了三件事：描述需求、审查最终代码、验证实验结果。

这就是自主编程的定义：AI 不只是辅助或者结对，而是自主完成任务。

Token 产出的不是代码，而是可交付的产物

Copilot 能补全代码，但你需要逐行确认。Cursor 或 Claude Code 能重构逻辑，但调试、处理报错仍然是你的工作。这些工具提升了效率，但人依然是执行主体。

Quest 要解决的问题是：Token 产出的必须是可交付的产物。如果 AI 写了代码，最后还需要人来调试、测试、兜底，那这些 Token 的价值就大打折扣。当 AI 能稳定产出完整、可运行、可交付的成果时，才算实现自主编程。

Agent 效果 = 模型能力 × 架构设计

从工程实践出发，我们总结出一个公式：

Agent 效果 = 模型能力 × Agent 架构（上下文 + 工具 + Agent Loop）

模型能力是基础，但同样的模型在不同架构下表现天差地别。Quest 通过上下文管理、工具选择、Agent Loop 三个维度优化架构，充分释放模型能力。

上下文管理：Agentic 而非机械

随着任务推进，对话不断膨胀。全部保留会淹没模型，机械截断会丢失关键信息。Quest 采用"Agentic 上下文管理"：让模型自主判断何时压缩总结。

模型自主压缩

在长程任务中，Quest 让模型在合适时机总结已完成的工作。不是"保留最近 N 轮对话"，而是让模型理解哪些信息对后续任务重要，哪些可以压缩。

压缩的触发时机基于多个因素：

• 对话轮数达到阈值
• 上下文长度接近限制
• 任务阶段切换（如从调研阶段进入实现阶段）
• 模型检测到上下文冗余

模型根据当前任务状态自主决策，而非机械地按固定规则执行。

动态 Reminder 机制

传统做法是将所有注意事项写进系统提示词。但这导致提示词臃肿、模型注意力分散，以及缓存命中率下降。

以语言偏好为例：

传统方案：系统提示词中硬编码"请用中文回复"。每次用户切换语言，整个提示词缓存就失效，成本成倍增加。

Quest 方案：通过 Reminder 机制动态注入需要关注的上下文。语言偏好、项目规范、临时约束等信息按需添加到对话中，既保证信息及时传递，又避免系统提示词无限膨胀。

这样做的好处：

• 提高缓存命中率，降低推理成本
• 保持系统提示词简洁，提升模型注意力
• 灵活适配不同场景的需求

工具选择：为什么 Bash 是最佳拍档

如果只能保留一个工具，那一定是 Bash。这个决定可能反直觉。市面上多数 Agent 提供丰富的专用工具：文件读写、代码搜索、Git 操作等。但工具数量增加会提高模型选择复杂度和出错概率。

Bash 的三个优势

大而全。Bash 几乎能完成所有系统级操作：文件管理、进程控制、网络请求、文本处理、Git 操作。一个工具覆盖大部分场景，模型无需在众多工具中选择。

可编程、可组合。管道、重定向和脚本机制让简单命令组合成复杂工作流。这与 Agent 的任务拆解高度契合：将大任务拆成小步骤，每个步骤用一行或几行命令完成。

模型天生熟悉。大模型预训练时已见过大量 Unix 命令和 Shell 脚本。遇到问题时，模型往往能自行找到解决路径，无需在 Prompt 中详细教学。

Less is More

Quest 仍保留少量固定工具，主要用于安全隔离和 IDE 协同。但原则始终是：能用 Bash 解决的，不造新工具。

每增加一个工具，就增加模型的选择负担和出错可能。简洁的工具集反而让 Agent 更稳定、更可预测。通过实验反复验证，移除多余的专用工具后，在任务完成率保持不变情况下，上下文 Token 消耗却降低了 12%。

Agent Loop：Spec > Coding > Verify

自主编程的 Coding Agent 需要完整闭环：收集上下文 → 制定计划 → 执行编码 → 验证结果 → 迭代优化。

观察市面上的 Coding Agent，用户最常说"跑起来..."、"能运行就行"、"帮我调这个报错"。这恰恰暴露了能力短板：它们在验证环节偷懒了。AI 写代码、人来测试，不算自主编程。

Spec 驱动的开发流程

Spec 阶段：动手前先澄清需求，明确验收标准。对于复杂任务，Quest 生成详细技术规格书，确保双方对"完成"的定义达成共识。

Spec 包含的要素：

• 功能描述：实现什么功能
• 验收标准：如何判断完成
• 技术约束：使用哪些技术栈、遵循哪些规范
• 测试要求：需要通过哪些测试

Coding 阶段：根据 Spec 实现功能。这个阶段 Quest 自主推进，无需用户持续监督。

Verify 阶段：自动运行测试，验证实现是否符合 Spec。验证类型包括语法检查、单元测试、集成测试等。如果不符合，自动进入下一轮迭代，而非把问题抛给用户。

通过 Hook 机制，这三个阶段可灵活扩展组合。比如在 Verify 阶段接入自定义测试框架或 lint 规则，确保每次交付符合团队工程标准。

对抗模型的"退缩"倾向

当前多数模型为 ChatBot 场景训练。面对长上下文或复杂任务时，它们倾向于"退缩"，给出模糊回答或询问更多信息来拖延执行。

Quest 通过架构设计帮助模型克服这种倾向：在合适时机注入必要的上下文和指令，推动模型完成完整任务链路，而非中途放弃或把问题甩回用户。

自动适配复杂度，而非堆砌功能

Quest 面对的不只是代码补全，而是完整的工程任务。这些任务可能涉及多个模块、多种技术栈，需要长时间持续推进。

设计原则是：根据任务复杂度自动适配策略，用户无需关心背后如何调度。

动态加载 Skills

当任务涉及特定框架或工具时，Quest 动态加载对应的 Skills。Skills 封装了经过验证的工程实践，比如：

• TypeScript 配置最佳实践
• React 状态管理模式
• 数据库索引常见陷阱
• API 设计规范

这不是让模型每次从零推理，而是直接复用沉淀的经验。

团队也可以将工程规范封装成 Skills，让 Quest 按团队方式工作。例如：

• 代码风格指南
• Git 提交规范
• 测试覆盖率要求
• 安全审查清单

智能模型路由

当单一模型能力不足以覆盖任务需求时，Quest 自动调度多个模型协同工作。有的模型擅长推理，有的擅长写作，有的擅长处理长上下文。

智能路由根据子任务特性选择最合适的模型，对用户来说面对的始终是一个 Quest。

多 Agent 架构

当任务复杂到需要并行推进、分模块处理时，Quest 启动多 Agent 架构：主 Agent 负责规划协调，子 Agent 执行具体任务，伴随 Agent 负责监督。但这个能力保持克制使用。因为多 Agent 不是银弹，上下文传递有损耗，任务拆分门槛也高。只在确实需要时才启用。

为未来模型而设计

Quest 从第一天起就为 SOTA 模型设计。架构不为过去的模型打补丁，而是确保随着底层模型能力提升，Agent 能力水涨船高。

这就是为什么 Quest 没有提供模型选择器。用户不需要在不同模型间纠结选择，这个决策由系统自动完成。用户只需描述任务，Quest 负责调度最合适的能力完成它。

换句话说，Quest 不只是适配今天模型的 Agent，而更是为 6 个月后的模型准备的 Agent。

为什么不暴露文件编辑过程

Quest 没有文件树，也不支持用户直接修改文件。这是一个反直觉的产品决策。

很多 Coding Agent 实时展示每次文件修改，让用户随时介入编辑。Quest 选择不这样做，原因有三：

不打断 Agent 的执行心流。用户介入会打断任务连贯执行，也容易引入不一致。

让用户从"盯代码"转向"关注问题本身"。既然目标是自主编程，就应该让用户将注意力放在需求定义和结果审查上。

这是自主编程的发展方向。未来用户关心的是"任务完成了没有"，而不是"这行代码改了什么"。Quest 的界面围绕最终产物设计，而非围绕执行过程。

自进化：越用越强

Quest 的技术突破之一是自主进化能力。它能深度分析项目的代码结构、架构演进、团队规范，将这些信息内化为"项目理解"。

具体表现为：

• 理解项目模块划分和依赖关系
• 识别代码风格和命名习惯
• 学习项目特定的架构模式
• 掌握团队的工程实践

面对陌生的 API 或新框架，Quest 通过探索和实践进行自我学习：阅读文档、尝试调用、分析错误、调整方案。使用时间越长，它对项目理解越深，表现也越好。

Skills 系统进一步扩展了这种能力。团队可以将工程规范、常用模式封装成 Skills，让 Quest 持续习得新技能。Quest 不仅执行任务，还会在执行中不断学习。

我们用 Quest 构建 Quest

Quest 团队自己是 Quest 的深度用户。文章开头提到的"用 Quest 重构 Quest"不是案例包装，而是日常工作的真实写照。

在产品邀请测试阶段，用户就通过 Quest 处理过 80 万镜像的构建、验证与校验，通过 Quest 画原型图做设计稿。Quest 在改变我们自己的工作方式。

在工程架构上，我们保持足够的容错和泛化能力。一个常见的诱惑是：为了某个产品效果在工程上做妥协，把 Agent 做成 Workflow。Quest 的选择是：产品展示从用户视角出发，工程实践则坚定采用 Agentic 架构。这样不限制模型能力的发挥，为未来模型升级做好准备。

从结对到自主

AI 辅助编程经历了三个阶段：代码补全、结对编程、自主编程。Quest 正在探索第三阶段的可能性。

当开发者的角色从"代码编程者"转变为"意图定义者"，软件开发的范式将发生根本性改变。开发者将从繁琐的编码细节中解放出来，专注于更高层次的问题定义和架构设计。

这就是 Quest 正在构建的未来：一个自进化的、自主编程的 Coding Agent。

自主编程（Quest Mode）：将任务委派给智能体

---

desc: Spec驱动的任务委派开发
category: 产品
img: https://img.alicdn.com/imgextra/i4/O1CN0103AFeh1vZhZmtD0wg_!!6000000006187-0-tps-1712-1152.jpg
time: 2025年8月21日 · 3分钟阅读

Quest Mode：任务委派给智能体

随着大模型编程能力的快速进步，尤其是在 Claude 4 系列模型发布之后，我们惊喜的发现大模型在复杂长程任务的表现出现了大幅度的增强。许多开发者开始习惯于为 AI 描述一个复杂的功能、缺陷、重构或者测试任务，让 AI 长时间的自由探索去解决问题，最后再去校验其生成结果。这种开发模式的应用让 AI 编程效率大幅提升，核心在于以下几点变化带来的收益：

1. 更清晰的软件设计描述让大模型可以充分理解开发者的意图，并且始终围绕目标工作，代码生成质量大幅提升。

2. 开发者可以在更高层次上通过自然语言去设计软件复杂逻辑，或者进行精细化的微调，从而减少关注代码细节以提升效率。

3. 异步化的工作模式让开发者可以从反复与 AI 互动中解放出来，多线程的工作带来了成倍的效率提升。

我们认为这些变化代表着一种全新的软件开发模式，彻底改变了过去 Vibe Coding 在复杂软件开发中无法有效落地的痛点，带领着我们进入到自然语言编程的新时代。我们称之为 Quest Mode，这是一种全新的 AI 自主编程模式。

Spec First

当智能体编程能力快速增长后，影响 AI 任务执行效果的瓶颈，已经变成开发者如何更加清晰地表达任务要求。粗糙的目标描述一定带来粗糙、无法预测的执行结果。因此我们期望在执行复杂长任务之前，开发者可以详尽的、准确的表达软件逻辑，描述清楚变更细节和验证标准，以指导智能体更准确的完成任务。

当然，我们可以依赖 Qoder 强大的软件知识理解和代码检索能力，可以快速、准确的根据开发者意图编写出完善的 Spec，开发者再做微调即可。这一份文档将成为开发者与 AI 目标对齐的核心。

Action Flow

当与 AI 约定好 Spec 后，可以放手给智能体去执行。此时开发者可以通过 Action Flow 来观测智能体的计划和执行进展。通常情况下，并不需要人们去主动监视智能体的执行过程，如果智能体遇到不清晰的问题或者阻塞，会主动向开发者发送 Action Required。我们期望 Action Flow 的界面，可以让开发者在 10 秒钟之内，便能明白智能体过去做了什么，遇到了什么问题，以及决定如何解决问题，以继续当前任务。

Task Report

对于长编程任务来说，大量的代码变更会让开发者有巨大的审查负担。此时完善的测试验证不但可以让智能体具备自我验证和迭代修复能力，最终也可以形成一个完善的验证报告给到开发者。

在 Quest Mode 中我们单独为此设计了 Task Report， 用于呈现编码任务的执行概况、验证步骤和结果、代码变更列表，用于帮助开发者快速的了解任务执行是否可靠，以最终决定采纳与否。

What’s next

我们还在不断的探索和完善 Spec-Driven Development 的软件研发模式，希望这种模式可以提升真实软件研发的效率。Spec Driven 是在编码过程中保障智能体生成效果的一种手段，我们的目的是实现将编程任务委托给智能体，使其可以异步执行，从而实现十倍以上的编程效率提升。未来我们一方面会继续优化开发者与 AI 协同编写 Spec 的效率和质量，另一方面我们会提供智能体云端运行能力，让 AI 可以无时无刻、无处不在的为我们提供服务。

别把所有工具定义都塞给模型

---

desc: 93.5% 的 context 是用不上的工具定义。这是我们的解法。
category: 技术
img: https://img.alicdn.com/imgextra/i3/O1CN01XjwNoT26FyIKVEFRP_!!6000000007633-2-tps-1712-1152.png
time: February 25, 2026 · 5min read

Quest 支持通过 Skills 和 MCP Server 扩展能力。上线后不久，我们从一次异常的 token 分布里，发现了一个大多数 AI Agent 都可能存在的问题。

起因

Quest 1.0 上线后没多久，有用户反馈：一次任务把大量积分烧掉了，结果还不满意。

我们把那次对话的 token 分布数据拉出来看。12 万个 input token 里，93.5% 是工具定义。这些工具，在整次任务中一次都没被调用过。

这是个极端案例，那个用户挂载了好几个 MCP Server。但它暴露了一个普遍问题：context 里堆满了"以防万一"的工具定义，大多数时候根本用不着。

我们团队里有人之前配置了 playwright-mcp 做前端自动化测试，测试结束后就再没碰过。它的工具定义还是在每次对话的 context 里出现，没人注意到，一放就是几周。

做了个对照实验：同样的任务，一组挂载两个 MCP Server（全程没用到），一组完全不挂。只是挂在那里，积分消耗就多了 10% 以上。两个 MCP Server 贡献了将近一百条工具定义，消耗接近 2000 个 token。

内部做了个小调查：80% 的同事至少配置了一个 MCP Server，但实际使用频率不足 10%。

问题摆在那里：不想删工具，但不能让它们一直占着 context，怎么办？

从 Skills 优化中找到思路

解决 MCP 之前，我们在另一个功能上已经碰过类似的墙：Skills。

Quest 的 Skills 功能让用户定义专项知识和工作流，Agent 按需加载。但用户反映 Skills 的自动触发率很低，经常需要手动输入 /skills 才能用到。

我们在 28 个 Skills 的环境下测了一下：模型的自主触发率不到 50%。

触发率为什么低？

模型调用 Skills 需要完成三件事：

1. 理解当前任务需要什么能力（意图识别）
2. 在已知 Skills 列表中找到匹配的那个（能力匹配）
3. 判断什么时候加载、怎么用（时机判断）

第 1 步和第 3 步靠模型的推理能力，随着模型升级会自然变好。瓶颈在第 2 步：模型怎么知道有哪些 Skills 可以用？

最直接的做法是把所有 Skills 的完整定义塞进 system prompt。有效，但代价是 context 膨胀：28 个 Skills 的完整描述轻松消耗几千个 token，而单次任务通常只用得上 1-2 个。

Skills 路由索引

我们的做法：在 System Reminder 里放一个轻量级的 Skills 索引，而不是完整定义。

索引里只有每个 Skill 的名称和一行描述，几百个 token。模型用这个索引做意图匹配，判断需要某个 Skill 的时候，再通过索引去定位和加载完整内容。

这个方案有几个约束要同时满足。索引本身要够轻，否则只是把负担从工具定义转移到索引上。一行描述要足够准确，让模型能做出正确的意图匹配。另外，注入方式要保住 Prompt Cache 命中率，所以 Tools Definition 的结构不能动，只通过 System Reminder 动态注入。

背后有个假设：模型不需要看完整定义，就能判断自己是否需要某个 Skill。告诉它"有个工具叫 X，能做 Y"，它就能在合适的时机决定要不要加载。

结果

Skills 自主触发率从不到 50% 提升到 90% 以上，总 token 消耗下降了约 12%。

Round	Invoked / Should Invoke	Pre-optimization Input Tokens	Post-optimization Input Tokens	Reduction
1	2/2	65,799	53,842	18.2%
2	3/3	28,850	27,466	4.8%
3	4/4	67,639	53,479	20.9%
4	0/1	79,032	79,012	0.02%

Round 4 失败值得单独说：那次任务需要的 Skill，和它在索引里的描述相似度太低，模型没有识别出来。索引质量比我们预想的要重要得多。一行描述写偏了，按需加载就永远不会触发。

扩展到 MCP：动态加载

Skills 的经验证明了这个思路可行：轻量索引 + 按需加载，功能不打折，context 能压下来。

MCP 工具面对同样的问题，能用同样的方案吗？

理论上可以，但 MCP 多了一层复杂性。Skills 本质上是文本指令，格式宽松。MCP 工具需要精确的 JSON Schema 才能正确调用：参数名、类型、嵌套结构，缺一个字段或类型不对，调用就会失败。所以 MCP 的动态加载对"注入精度"要求更高。

我们的方案分两个阶段。

第一步，发现：System Reminder 只展示 MCP 工具的摘要索引（名称 + 一行描述），不包含完整 Schema，和 Skills 方案一样。

第二步，注入：模型判断需要某个具体工具时，调用一个叫 LoadMcpTool 的元工具，后者把该工具的完整 JSON Schema 动态注入当前 context。注入完成后，模型按正常流程调用工具。

LoadMcpTool 本身是个轻量工具，Schema 始终在 context 里（只占几十个 token）。它是入口：模型用它把其他工具的完整定义"拉"进来。

初始 context 只有摘要索引，需要时注入完整 Schema（不做任何简化），模型调用时看到的始终是完整的定义。

关联预加载

有个实际问题：MCP Server 通常包含一组相关工具。比如 browser-use Server 里有 click、fill、navigate、screenshot，十几个工具。涉及浏览器操作的任务，模型往往需要其中好几个，逐一通过 LoadMcpTool 加载会产生多轮调用开销。

借鉴 CPU 缓存里的空间局部性原理：模型加载某个 Server 里的任意工具时，顺带把同一 Server 里最常用的几个工具也预加载进来。原本需要多次 LoadMcpTool 调用的浏览器任务，现在通常只触发一次。

测试结果

测试环境：67 个 MCP 工具。任务：构建一个网站，并用浏览器工具测试。

初始 context 减少了 32%，整体费用降低了 10.4%，MCP 工具调用成功率维持 100%。

Metric	Full Loading	Dynamic Loading	Change
Initial Input Tokens	27,972	18,964	32.2%
Final Credits Consumed	29.52	26.45	10.4%
MCP Tool Call Success Rate	100%	100%	No change

回头看：这其实是渐进式披露

两个优化都做完之后，我们往后退了一步，发现这是同一个解法。

1984 年，IBM 的研究员 John Carroll 提出了 Progressive Disclosure（渐进式披露）：不要一次把所有功能都展示给用户。先把常用的露出来，剩下的等用到时再给。Word 的折叠菜单、Notion 的 / 命令、iOS 的多层设置，都是这个原则在 UI 上的体现。

我们对 context window 做的是同一件事。轻量索引放在前面，让模型知道有什么可用；完整定义只在需要时加载。"用户"是 AI 模型，"界面"是 context，但问题本质一样：功能要全，信息量要小，怎么两头都顾到。

Carroll 在 1984 年用命令菜单解决这个问题，我们在四十年后用 JSON Schema 解决了同一个问题。

给 Agent 开发者的参考

Quest 1.0 的这两项优化已经上线，不需要改任何设置。如果你在自己搭 AI Agent，下面几点值得参考：

1. 跑一下 context 的 token 分布分析，你可能会发现大头是从来没被调用过的工具定义。
2. 意图匹配不需要完整定义，模型从简短描述就能判断需不需要某个工具。
3. 索引质量决定上限。一行描述写得不准，就没有匹配。
4. 动态内容放 System Reminder，不要放 System Prompt，这样不会破坏 Prompt Cache 的命中率。
5. 动态注入完成后，跑一遍完整的工具调用测试。索引描述写偏了不会有任何报错，只会安静地不触发。

那个 93.5% 的数字，我们自己看到时也愣了一下。如果你在自己的 Agent 上跑同样的分析，token 分布通常是找到 context 被谁吃掉的最快路径。

QoderWork：不只是聊天，帮你把事情做完的 AI 工作助手

---

desc: QoderWork——一个运行在你桌面上的 AI 智能工作助手
category: 产品
img: https://img.alicdn.com/imgextra/i4/O1CN01K21tPZ1NxnTzJ0DfN_!!6000000001637-2-tps-1712-1152.png
time: 2026年2月12日 · 3分钟阅读

当 AI 助手还停留在"聊天窗口"里时，我们已经在思考一个不同的问题：如果 AI 不只是回答问题，而是真正坐在你旁边，帮你把事情做完呢？

今天，我们正式推出 QoderWork——一个运行在你桌面上的 AI 智能工作助手。它不是又一个聊天机器人，而是一个能操作你的文件、连接你的工具、替你完成实际工作的协作伙伴。

从"对话"到"协作"

过去几年，大语言模型已经证明了自己在理解和生成文本方面的惊人能力。但对于大多数人来说，日常工作远不止"写一段文字"这么简单——你需要整理文件、生成报告、管理项目、查阅资料、处理数据，这些任务散落在十几个不同的工具和窗口之间。

传统的 AI 助手能帮你起草一封邮件，但它没办法帮你打开本地的 Excel 表格、把数据整理成一份漂亮的 PPT。这中间的断层，正是我们想要弥合的。

QoderWork 的核心理念很简单：AI 应该在你工作的地方工作，用你的工具工作，以你的方式工作。

QoderWork 能做什么

本地文件，直接操作

QoderWork 将任务执行环境部署在本地虚拟机中，可以直接访问你授权的本地文件夹。你不需要把文件上传到某个云端，也不需要来回复制粘贴——只需要告诉它你想做什么，它就能直接在你的文件系统中完成操作。

无论是读取一份合同的关键条款、批量重命名文件，还是把几张截图整理成文档，QoderWork 都能胜任。它像一个就坐在你隔壁工位的同事，你把文件夹往他桌上一放，说一声"帮我整理一下"，事情就办好了。

专业级文档生成

这是 QoderWork 最让人惊喜的能力之一。它内置了一套精心打磨的专业技能系统（Skills），涵盖日常工作中最常见的文档格式：Word 文档不再只是简单的文字导出，而是带有专业排版、目录结构和样式的成品；Excel 电子表格支持公式、图表、数据验证和复杂格式；PowerPoint 演示文稿可以从零开始构建，包含布局、配色和内容结构；PDF 文件支持生成、解析、表单填写和页面操作。

这些不是"差不多就行"的输出，而是可以直接拿去开会、交给客户的专业文档。每种格式背后都有一套经过实战验证的最佳实践，确保输出质量稳定可靠。

无缝连接你的工具链

工作者的一天通常在多个工具之间切换：任务管理、设计协作、团队文档、在线平台。QoderWork 通过 MCP（Model Context Protocol）协议与这些工具深度集成，让你在一个界面中就能完成跨平台的工作流。

它可以查找你的待办事项、读取设计稿数据、在团队文档中创建内容，甚至查询天气和规划出行路线。但这不是简单的"快捷方式"——QoderWork 理解这些工具之间的关系，可以从一条任务出发，起草对应的方案，提取相关素材，最后生成一份完整的项目交付文档。整个流程一气呵成。

浏览器自动化

有时候，你需要的信息在网页上。QoderWork 内置了完整的浏览器控制能力，可以访问网站、填写表单、点击按钮、提取数据、截取页面。这意味着它可以帮你做网络调研、测试 Web 应用、从网页抓取结构化数据，甚至自动完成一些重复性的在线操作。它运行在自己的隔离环境中，安全且可控。

信息检索与研究

QoderWork 可以搜索网络获取最新信息，查阅学术论文，甚至调用地图服务查询地理信息和路线规划。当你需要为一份报告做背景调研，或者想快速了解某个领域的最新进展，你不再需要自己逐个打开浏览器标签页——让 QoderWork 帮你完成信息收集和初步整理。

图像生成

需要一张配图？QoderWork 可以根据你的描述直接生成高质量图像，并将其保存到你的项目目录中。无论是文档插图、演示配图还是概念设计，都可以在工作流中自然地完成，无需切换到其他工具。

我们如何思考安全与信任

将 AI 助手引入本地文件系统是一件需要慎重对待的事情。我们在设计 QoderWork 时，将安全性作为基础架构的一部分，而非事后补丁。

权限边界明确。 QoderWork 只能访问你明确授权的文件夹。它不会在你的硬盘上四处游荡，也不会在你不知情的情况下读取敏感文件。

文件保护优先。 QoderWork 对用户目录采用"保护区"策略。当需要删除文件时，它不会直接执行不可逆操作，而是将文件移入安全回收区，确保你始终拥有恢复的机会。

透明可追溯。 QoderWork 在执行任务时会通过进度列表实时展示当前正在做什么、已完成什么、接下来要做什么。你可以随时了解 AI 的工作状态，而不是面对一个"请等待"的黑盒。

一个真实的工作场景

想象一下这样的场景：你是一个产品经理，明天有一个重要的评审会议。

你对 QoderWork 说："帮我准备明天的产品评审材料。在我的项目文件夹里有最近的用户调研数据和竞品分析文档，我需要一份 PPT 演示文稿和一份详细的 Word 报告。"

QoderWork 会先向你确认关键细节——演示文稿面向谁？需要多少页？是否需要包含数据图表？然后它会读取你文件夹中的原材料，提炼关键发现，生成一份结构清晰的 PowerPoint 演示文稿和一份图文并茂的 Word 报告。整个过程中，你可以通过进度面板实时了解它的工作进展，在关键节点进行确认或调整方向。

完成后，文件会直接出现在你的工作文件夹中——打开就能用，不需要额外的格式调整。

加入公测

我们今天开放 QoderWork 公测，因为我们相信最好的产品是和真实用户一起打磨出来的。这是一个早期版本，我们非常期待看到你会如何使用它，也期待你告诉我们哪里还不够好。

如果你对一个能真正帮你干活的 AI 助手感兴趣，欢迎访问 qoder.com/qoderwork 开始体验。

我们迫不及待地想看到，当 AI 真正成为你的工作伙伴时，你会用它创造出什么。

QoderWork 目前已在 macOS 平台全面开放，Windows 版本即将发布。

Qoder 订阅计划上线

---

desc: 感谢支持，Qoder 订阅计划正式上线
category: 产品
img: https://img.alicdn.com/imgextra/i4/O1CN013ovXdd1suozbE0qsr_!!6000000005827-2-tps-1712-1152.png
time: 2025年9月15日 · 5分钟阅读

感谢你对 Qoder 的鼎力支持和积极参与。在预览期间，我们收到了大量宝贵的反馈和鼓励。你的意见是我们不断改进和优化功能的指南。

我们了解到，社区中的许多用户都渴望突破预览版的使用限制，更自由地使用 Qoder 来加速工作流程。为了确保我们能够长期持续地提供高质量的服务，经过慎重考虑，我们很高兴地宣布正式推出我们的定价方案。

方案与定价

我们目前提供两种方案供你选择。付费方案为月度订阅，Qoder 中的资源使用量以积分（Credits）计量。各方案的详细信息如下。

针对个人用户，Qoder 提供 Free、Pro 、Pro+ 和 Ultra 计划。我们也在计划为团队推出 Teams 计划，敬请期待。选择最适合你需求的方案。

个人方案

各方案的内容如下，付费方案按月订阅并自动续费。Credits 用作 Qoder 的资源计量单位。

Plan	Free	Pro	Pro+	Ultra
价格	免费	限时优惠： 10 USD/月（原价：20 USD/月）	限时优惠： 30 USD/月（原价：60 USD/月）	限时优惠： 100 USD/月（原价：200 USD/月）
功能	• Pro 试用 2 周 • 无限次代码补全与行间建议预测（NES） • 限量智能问答和智能体请求	• 无限次代码补全与行间建议预测（NES） • 为智能问答和智能体请求提供限量的 Credits • Quest Mode，Repo Wiki	• 无限次代码补全与行间建议预测（NES） • 为智能问答和智能体请求提供限量 Credits • Quest Mode，Repo Wiki	• 无限次代码补全与行间建议预测（NES） • 为智能问答和智能体请求提供限量 Credits • Quest Mode，Repo Wiki
资源额度	使用基础模型，用户消息条数受限。	• 每月 2,000 Credits（用于高级模型） • 当 Credits 用尽后，Qoder 将切换为基础模型，基础模型的用户消息条数受限。	• 每月 6,000 Credits（用于高级模型） • 当 Credits 用尽后，Qoder 将切换为基础模型，基础模型的用户消息条数受限。	• 每月 20,000 Credits（用于高级模型） • 当 Credits 用尽后，Qoder 将切换为基础模型，基础模型的用户消息条数受限。

注意：你的 Pro、Pro+ 和 Ultra 方案配额包含与订阅费用等值（Pro 为 20 美金，Pro+ 为 60 美金，Ultra 为 200 美金）的高级模型资源，加上我们提供的额外赠送资源。方案内的 Credits 仅在当前订阅周期内有效。订阅周期结束时，这些 Credits 将自动重置为 0。Pro 试用（2 周）包含：

• 300 Credits

• 无限次补全与行间建议预测（NES）

• 智能问答和智能体

• Quest Mode

• Repo Wiki

我应该选择哪个方案？

如果你主要使用代码补全和基础的 Agent 辅助，Pro 方案非常适合你的日常开发。如果你高度依赖智能体进行自主编码，Pro+ 方案更能满足你更高强度的需求。如果你经常运​​行 Quest 这类长时间的任务，Ultra 套餐中的大量资源更适合你。

查看你的 Credits 使用情况

你可以随时在个人设置中的 Usage 页面查看当前订阅周期内 Credits 使用情况。不同功能 Credits 消耗速率各不相同。详情请参阅 Credits 部分。

当你的 Credits 用完时会发生什么？

当你的 Credits 即将用尽时，你会在个人用量页面和 Qoder 内看到明确的提示。此时你可以选择升级到更高的订阅方案。如果你的 Credits 配额完全耗尽，你将自动切换到基础模型，基于基础模型服务仍会继续提供。基础模型设有每日使用上限；一旦达到上限，你需要等到次日才能继续使用。如果你使用的是 Free、Pro Trial 、Pro 或 Pro+ 方案，你可以随时升级到更高档位以获得更多 Credits 配额。如果你已在 Ultra 方案，请等待我们即将推出的资源附加包选项来提升配额。

Pro 试用规则

我们很高兴为首次登录 Qoder 客户端的新用户提供为期 14 天的免费 Pro 试用（需使用 Qoder 最新版本；通过非虚拟机方式登录），并附赠 300 个 Credits，便于体验我们的 Pro 方案功能。为确保所有用户都能获得公平且顺畅的体验，我们设定了合理的使用上限。本优惠每位用户限领一次，任何额外创建的试用账户将被冻结。

升级订阅方案

你可随时升级订阅。当前方案中未使用的 Credits 将自动结转，不会丢失。请注意，一旦 Credits 结转完成，该操作不可撤销。

• 从 Pro 试用版升级：若在试用期内升级，未使用的赠送 Credits 将自动以附加包形式转入你的账户，并保留原有到期日期。

• 从 Pro 升级到 Pro+：若在订阅周期中从 Pro 升级到 Pro+，Pro 方案中未使用的 Credits 将自动以附加包形式转入你的账户，并保留原有到期日期。你的原 Pro 方案将立即失效，新 Pro+ 方案的订阅周期将开始计算。

因此，你可随时升级，无需担心未使用的 Credits 资源会丢失。

降级你的订阅方案

你可随时取消订阅。当前方案将在本计费周期结束前继续保持有效，计费周期结束后你的账户将自动降为免费方案。请注意，任何未使用的 Credits 在降级后将过期且不可转移。我们不支持在订阅周期内立即降级方案。

高级功能

与 Free 方案相比，付费方案支持以下高级功能：

• Quest Mode：一种面向复杂、长周期开发任务的 AI 辅助编程功能。请参见 Quest Mode。

• Repo Wiki：为你的项目自动生成结构化文档，并持续跟踪代码与文档变更。请参见 Repo Wiki。

面向团队

面向团队使用的 Teams 方案正在规划中，敬请期待！

Qoder 上线提示词增强功能，将开发者从“提示词”的负担中解放出来

---

desc: 将开发者从提示词负担中解放出来
category: 功能
img: https://img.alicdn.com/imgextra/i1/O1CN01QmlmHd24XiOs1BdmN_!!6000000007401-2-tps-1712-1152.png
time: 2025年10月22日 · 3分钟阅读

在 Agentic Coding 时代，我们常常面临一个核心悖论：

想要获得顶尖的回答，你必须先提出一个顶尖的问题。 对于开发者而言，这意味着需要花费大量精力去构思、打磨给 基于这个AI 的“提示词”。一个模糊的指令，如“帮我写个函数”，可能会得到一段过于简单甚至不安全的代码；而一个详尽、结构清晰的提示词，则能直接生成生产环境级别的、考虑周全的解决方案。

如今，这个阻碍开发效率的最后一道壁垒，被 Qoder 彻底打破了。Qoder 平台正式上线 “一键增强提示词（One-click enhancement for prompts）” 功能，将每一位开发者从“提示词”的负担中解放出来，让 Agentic Coding 变得前所未有的轻松和强大。

痛点：当你的想法，跑在了表达能力前面

你是否也曾经历过以下场景？

• 灵感一闪，却难以言表： 脑子里有一个复杂的需求轮廓，但不知道如何将其拆解成AI能理解的步骤和约束条件。

• 反复试错，消耗耐心： 不断修改提示词，与AI进行多轮“拉锯战”，只为了让它输出你真正想要的东西。

• 知识壁垒，限制想象： 不确定某个功能的最佳实践或最安全的实现方式，导致提示词本身存在缺陷。

这些正是 Qoder 提示词增强功能要解决的精准靶点。

解决方案：什么是“一键增强提示词”？

Qoder 的 “一键增强提示词”是一个内置于代码编辑器和聊天界面中的提示词优化功能，只需点击“增强”按钮，Qoder 的背后模型就会在瞬间对你的原始意图进行深度理解和结构化重构。

它不仅仅是同义词替换或简单扩写，而是从多个维度对提示词进行智能升级：

1. 需求明确化： 自动识别模糊描述，并将其转化为具体、可执行的任务。例如，将“弄个排序”增强为“使用Python编写一个快速排序算法，要求处理整数列表，包含详细的注释，并考虑输入为空或含重复元素的情况。”

2. 场景上下文化： 根据你当前项目的工程结构、对话、相关上下文等重要信息作为额外输入，让优化的提示词更具有针对性。

3. 约束条件完善化： 自动补充开发者容易忽略的关键约束，如性能要求、边界条件、错误处理、安全性考量（如SQL注入预防）、代码规范（如PEP8） 等。

4. 结构化输出： 将增强后的提示词组织成清晰的模块，如“任务目标”、“输入输出”、“约束条件”、“示例参考”等，让AI模型能够更精准地解析并执行。

功能演示：从“小白”到“专家”的瞬间蜕变

假设你正在开发一个 Python 网络请求功能，原始提示词是：

“Use the requests library to crawl the title of a web page.”

这个提示词缺失了大量关键信息（如URL、错误处理、编码问题等）。点击“增强”后，你可能会得到如下优化版本：

【增强后提示词】Write a Python script using the requests library to fetch the HTML content of a web page and extract its title. The script should handle potential errors such as network issues or missing title tags gracefully. Include appropriate headers in the request to mimic a standard web browser, and print the extracted title to the console. Use the following URL as an example target: https://www.example.com.

对比之下，后者几乎是一个资深开发者才会写出的完整任务说明书。用增强提示词，Qoder Agent 将能生成一段可直接使用的生产级代码。

（补充：如果你对增强的提示词不满意，可以选择右下角撤回，并进行重新优化）

立即尝试

“一键增强提示词”的上线，让开发者更好地与 AI 对话。工具的进化不应该是增加用户的负担，而是通过智能化的方式，消除摩擦，放大创造力。

• 极大提升效率： 节省反复构思和修改提示词的时间，让你更专注于核心逻辑和架构设计。

• 降低使用门槛： 无论是编程新手还是资深专家，都能借此功能释放AI的全部潜力，写出更高质量的代码。

• 学习最佳实践： 通过观察增强后的提示词，你可以快速学习如何向AI清晰地表达复杂需求，无形中提升自己的设计和沟通能力。

未来，我们将继续围绕提示词优化、上下文理解等核心能力进行深度探索，让 Qoder 成为你编码过程中不可或缺的“第二大脑”。

立即体验 Qoder，点击那个神奇的“增强”按钮，感受AI编程效率的质的飞跃！

迈向智能编辑的下一代演进：Qoder NEXT 模型与 ActionRL 偏好对齐实践

---

desc: 从“代码补全”到“编辑预测”，解读背后Qoder NEXT 模型能力及优势
category: 技术
img: https://img.alicdn.com/imgextra/i2/O1CN01EUNmOu1x2Nzu5tRuw_!!6000000006385-2-tps-1712-1152.png
time: 2026年1月6日

引言：从“代码补全”到“编辑预测”

在过去的两年中，大语言模型（LLMs）从根本上重塑了软件开发的工作流程。“智能体编码”（Agentic Coding）等新范式使开发者能够根据高层指令快速生成整个代码仓库级别的代码，显著提升了开发速度。然而，社区中逐渐流行起一个说法——“AI 善后工程师”：Agentic Coding 虽能迅速完成 80%的任务，但剩下的 20%——那些涉及逻辑校准、边界处理、跨模块协调与工程细节打磨的部分——往往仍需人工介入。

尽管如此，传统的代码补全工具仍局限于“中间填充”（Fill-In-the-Middle, FIM）范式。这类模型通常仅基于局部上下文，在光标位置预测一段连续的代码片段，缺乏对整体编辑意图的全局理解。这种单步、静态的方法在现实场景中表现不足——例如多行代码修改、函数重构或跨文件依赖调整——无法支持连贯且结构化的开发操作序列。

我们推出了 Qoder NEXT 模型。Qoder NEXT 的核心理念是：代码开发本质上是一系列连续的、上下文感知的编辑动作（Action Sequence），而非孤立的 Fill-In-the-Middle 生成任务。 

为解决这一局限性，我们提出一个端到端的框架，其建立在三大关键组件之上：

1. 冷启动训练：通过抽象语法树（AST）精确模拟真实世界的代码编辑轨迹；

2. 数据飞轮机制：从高探索性部署的原型模型中捕获真实的编辑行为；

3. ActionRL：一种新颖的偏好对齐算法，确保在序列化决策层面深度契合开发者的意图。

---

一、 破局 FIM：基于 AST 解析的编辑轨迹模拟

传统的 FIM 训练模式通常是将代码随机掩盖一段，让模型预测空缺内容。这种方式学习到的是代码的“静态概率分布”，而非“动态修改逻辑”。为了让 Qoder NEXT 模型学会“如何编辑”，我们放弃了随机掩码，转而利用 AST（抽象语法树） 来逆向构造真实的编辑轨迹。

1.1 结构化意图的抽象

在真实开发中，一个意图往往关联着多处改动。我们利用 AST 解析器（如 Tree-sitter）在数百万行高质量代码库中识别出核心编辑场景，并自动化地模拟用户的操作链条。

以标识符重命名（Identifier Renaming）为例，这不仅是文本替换，而是一个典型的结构化编辑动作：

1. 动作触发（Trigger Action）：我们定位到一个变量、函数或类的声明位置，并模拟用户对其进行重命名。

2. 联动推荐（Ripple Effect）：利用 AST 的作用域分析（Scope Analysis）和引用链（Reference Chain），自动找出该标识符在当前项目中的所有调用点。

3. 轨迹构建：我们将后序的系列改动转化为有序的动作序列：[Edit Action 1] -> [Edit Action 2] -> ...。

1.2 模拟复杂的真实编辑

除了标识符重命名，Qoder NEXT 的冷启动数据还涵盖了以下高阶场景：

• Signature Change（签名变更）：当用户在函数定义中增加一个参数时，模型在所有调用处，自动插入占位符或匹配局部变量；

• Logic Extraction（逻辑提取）：将一段代码块重构为独立变量/函数，模型在原位置调用独立变量/函数；

• Type Refinement（类型细化）：从接口类型到接口的具体实现；

• **Method Override（方法覆写）：**在父类或接口中新增一个方法签名时，自动识别子类并生成符合语义的覆写实现；

• **Error Refactoring（错误重构）：**将LSP暴露的异常或错误代码片段，重构为逻辑正确的代码片段；

• **Automatic Import（自动导入）：**引用一个尚未导入的类型、函数或常量时，在正确作用域插入符合项目风格的导入语句；

通过 AST 模拟，Qoder NEXT 模型在预训练阶段接触的就是**“有因果关系的修改”**，这奠定了它处理跨行、跨语义编辑的基础。

---

二、 构建数据飞轮：从原型模型到偏好捕获

轨迹模拟解决了“从 0 到 1”的问题，但真实的开发场景远比 AST 模拟复杂。开发者的长程历史编辑是什么？他们为什么拒绝某个补全？这些信息只能从真实交互中获取。

2.1 高探索性的交互设计

我们将 Qoder NEXT 原型模型集成到 IDE 中，作为一个高探索性（High Exploration）的功能组件。Qoder NEXT 始终在预测开发者的“下一步动作”。当用户进行一次编辑后，模型会立即计算出潜在的后续编辑点，并及时展示给用户。

这种设计允许我们收集（在用户隐私策略允许的情况下）到极高质量的用户行为日志：

• 显式采纳（Explicit Accept）：用户通过Tab键接受了整串编辑建议。

• 局部修正（Partial Edit）：用户接受了前两个动作，但对第三个动作进行了手动微调。

• 显式拒绝（Explicit Reject）：用户直接忽略建议继续输入，或者按下 Esc 键。

2.2 信号收集与偏好建模

通过对原型模型的数据标注，我们将显式行为转化为 (Context, Response_Accepted 1, Response_Accepted 2, ..., Response_Rejected 1, Response_Rejected 2, ...) 的多元组。

传统的模型优化只关注“采纳”的正例，但在 Qoder NEXT 的进化中，“拒绝”信号蕴含的信息量更大。如果模型推荐了 obj.getName()，而用户手动改成了 obj.getDisplayName()，这说明模型在特定语义场景下缺乏对业务逻辑的判断。这种细微的偏好差异，正是提升模型“准确率”的关键。

---

三、 突破对齐困境：ActionRL 的诞生

在利用用户反馈进行 RLHF（强化学习）时，传统的对齐算法展现出了明显的副作用。在连续动作序列中，正例和负例往往高度耦合，这要求我们必须进行更细粒度的损失计算。

3.1 序列耦合带来的“过度抑制”

在代码编辑中，一组对齐序列中，正例序列 $y^w$ 和负例序列 $y^l$ 通常具有极长的公共子串。一个案例如下：

• Context: user = User.find(id)

• 用户真实意图 $y^w$ : user.update(name: "New"); user.save(); print("Done");

• 模型错误预测 $y^l$ : user.update(name: "New"); user.delete(); print("Done");

在这里，第一个动作 user.update(name: "New")和第三个动作print("Done")是完全正确的，分歧点出现在第二个动作。

• 朴素对齐算法的局限：它将 $y^l$ 作为一个整体进行惩罚。由于 $y^l$ 包含了正确的 user.update; print，模型在优化过程中会降低对这部分正确动作的概率分配。

• 结果：模型变得“畏缩”，甚至不敢给出任何建议，因为它害怕后续某个微小的错误导致整个补全路径被否定。

3.2 ActionRL 的方案设计

为解决这一问题，我们提出 ActionRL，一种聚焦于关键分歧动作的细粒度偏好优化算法。其核心思想是：将学习目标从“整个序列的优劣”细化为“在首个错误决策点上做出更优选择”。

A. 定位关键分歧动作

给定一组偏好样本——其包含标注为“采纳”的轨迹（chosen trajectory）与标注为“拒绝”轨迹（rejected trajectory），ActionRL 首先对每条轨迹进行逐 action 对齐，识别出它们首次出现差异的位置。该位置即为行为分歧点（Behavioral Divergence Point, BDP），代表模型在该时刻做出了不同的动作选择。

值得注意的是，分歧点之前的上下文完全一致，意味着模型在此前的推理路径上并无偏差。因此，性能差异可归因于该点的动作选择。

B. 截断似然估计

不同于朴素对齐算法对整条序列计算似然，ActionRL 将优化目标局部化至分歧点处的条件分布。模型被鼓励在共享上下文条件下，赋予采纳或修正动作更高的概率，同时抑制拒绝动作的似然。这一设计确保梯度更新直接作用于导致结果分化的决策节点，而不会被后续action所干扰。

C. 损失函数重构

在许多实际场景中，拒绝轨迹在分歧点之后包含部分正确的子序列，ActionRL 通过截断损失计算范围，有效屏蔽了此类后置信息的干扰，使对齐训练信号更加聚焦且鲁棒。通过这种形式化处理，ActionRL 确保了：

分歧点惩罚：模型明确感知到 $y_{<t^}$（共有前缀）是中性的或受保护的，真正的惩罚集中在 $y^l_{t^}$ 这个错误的决策点上。

后缀忽略：对于 $t > t^*$ 的部分，由于负例序列已经偏离意图，其后续内容（即便可能包含正确动作）也不会对模型产生错误的干扰。

---

四、 实验结果与工程思考

在实践中，Qoder NEXT 模型展现出了显著优越的灵活性。

4.1 模型效果优化

经过 ActionRL 对齐后，Qoder NEXT 模型的关键性能指标显著提升：

• 代码生成比例提升超过 53%;

• 执行一致性显著增强：模型能够遵循“启动重构即完成全套动作”的内在逻辑，显著减少不完整执行的问题；

这些技术进步直接转化为实际的用户价值：

• 代码采纳率提高 65%；

• 细粒度推理准确率持续稳步提升;

实验结果验证 Qoder NEXT 在应对专业软件开发中复杂、精细需求方面的可靠性与实用性显著提升。

4.2 避免过度保守的预测

在对比实验中，我们观察到，采用朴素对齐算法训练的模型虽在首Action准确率上略有提升，但其在多样化场景下的覆盖率显著下降，模型表现出为避免生成错误输出而倾向于抑制预测行为。相比之下，ActionRL 在维持高准确率的同时，显著提升了模型的预测活跃度与场景覆盖能力，避免了因局部错误惩罚而导致的全局保守行为。

4.3 实时反馈循环

目前，Qoder NEXT 模型的数据飞轮每 24 小时循环一次。我们从原型环境日志中提取分歧样本，经过自动化的 ActionRL 训练后，次日便能观察到模型在真实场景下的效果改进。

---

五、 总结与未来展望

从 FIM 到 Qoder NEXT 的转变，是从“代码补全”走向“编辑预测”的关键一步。Qoder NEXT 模型不只是在帮你写代码，它是在理解编辑逻辑，并基于理解进行预测。

通过 AST 注入结构化知识，再通过 ActionRL 在序列层面精细化地对齐用户偏好，我们正在构建一个能够真正理解“下一步该做什么”的 AI 伙伴。在未来，随着动作空间的进一步扩展，Qoder NEXT 将具备完整覆盖研发流程（如完整的功能编写、测试用例生成及执行、代码提交、Bug修复）的能力。