如何调教一名合格的“编程搭子”

大家好，我是来自阿里云智能集团的王月成，今天我分享的主题是：如何调教一名合格的编程搭子。

在使用 Qoder 之前，我接触 AI 编程工具并不多。主要原因有两个：一是出于安全考虑，一些外部工具因网络限制无法访问；二是成本问题，很多工具价格较高。因此，此前我主要使用的是通义灵码的 JetBrains 插件。

最初，我对 AI 编程工具的定位很明确：它应该能辅助完成一些简单的编码或调试任务。抱着这个预期，我在 Qoder 内测上线时第一时间试用了。整体体验下来，感觉Qoder 更像是一个完整的产品，而不仅是一个辅助插件。

接下来，我会从入门、进阶两个阶段，结合实际使用场景，分享如何高效使用 Qoder。

入门：选择适合你的形态

在 Qoder 入门这一块，我主要分享下作为一个普通用户怎么去使用、怎么入门这款产品。它的定位就是帮助我、辅助我完成一些日常的开发工作，提高开发效率。

建议新手先选择自己熟悉的形态入手，不必一开始就让它承担复杂模块的开发任务。可以从辅助日常工作开始，比如补全单元测试、实现工具类、协助 Debug 等，逐步熟悉它的"习性"。

目前 Qoder 产品有三种形态：

**第一个是 Qoder IDE。**这是我最早下载内测时用的形态。它的功能目前来看是最全的，包括 Quest 模式、Repo Wiki 等，都在 IDE 里面支持。
**第二个是 Qoder JetBrains 插件。**这对 JetBrains 全家桶的铁粉来说是个福音，我也是 JetBrains 全家桶的铁粉。
第三个是 Qoder CLI ，这个也是刚推出的**。**我觉得 CLI 对运维工程师或者端到端产品解决方案来说，是非常重要的一环，因为它能集成到你的工作流或各种场景里，实现更好的自动化。

首先入门是先选一个你合适的形态。其次，我觉得不用一开始就让它去做一个非常大的功能模块开发，而是从辅助日常工作开始上手，去了解它的"习性"。我最开始用的时候，主要是让它在现有项目里补全单元测试、实现一些工具类、做些 debug。这里有一个经验是：这个交互过程是需要你逐步引导它去完善的，在整个流程中，你要一步步告诉它"我要干嘛"，把需求描述清楚，并在过程中引导它一步一步完成。

这里要避免让它一开始就上手复杂的、大规模的工程，甚至"祖传代码"。

实战案例：从简单任务开始

案例1：生成单元测试

内测初期，我让 Qoder 为某个类生成全部单元测试。初始提示非常简单："请为 XXX 类完成所有单元测试。"它确实快速生成了代码，但存在明显问题：缺少必要的 import、未遵循项目规范，甚至没有验证测试是否能通过。于是我补充反馈："代码存在编译错误，请按项目规则重新生成，并确保测试能通过。"随后，Qoder 开始反思并迭代修改，最终通过 Maven 命令验证了测试的正确性。这个过程让我意识到：不要期待一次到位，而是要把它当作一个可协作的伙伴，逐步引导。

案例2：构建复杂测试环境

在一些场景中，我们常需模拟用户的离线调度 SQL 环境。这类 SQL 往往包含复杂的表、字段依赖关系和加工逻辑。手动构造测试数据耗时极长，既要理解血缘关系，又要匹配字段类型（如 bigint、string 等），还要还原业务逻辑。

我将原始 DDL 和待改造的 SQL 提供给 Qoder，让它帮忙生成符合业务逻辑的测试数据。结果令人惊喜：它不仅梳理出了表与字段间的依赖关系，还用 Python 脚本注入了结构合理、逻辑正确的模拟数据。整个过程仅需几分钟，而人工可能需要半天甚至一天。这显著提升了我们在真实业务场景中的开发效率。

使用技巧：让 AI 更懂你

在使用过程中，我们会慢慢发现一些小技巧，可以更好地跟它对话、引导它做得更好。

技巧1：优化输入提示（Prompt）

Qoder 的聊天界面右下角提供"优化输入"功能。点击后，模型会自动帮你润色提示词，使其更清晰、结构化。

例如，上图所示优化前后的需求说明。优化后的提示显著提升了输出质量，也更利于大模型理解意图。体现如下：

实现目标：实现 XX 功能；
中间产出：设计文档、代码实现、单元测试；
代码质量：遵循现有代码风格，测试必须通过；
额外约束：禁止随意假设，需自行验证逻辑。

技巧2：善用规则 Rules

Qoder 支持自定义规则，相当于预设上下文。比如我的项目要求：

Java 代码提交前必须格式化
单元测试必须覆盖核心路径

我可以创建一条规则："每次生成 Java 代码后，请运行 formatter 并补充测试。"在后续对话中 @ 该规则，Qoder 就会主动遵守。社区也有用户整理了常用规则模板，非常实用。通过规则，可以让 AI 的输出更贴合团队规范。

进阶：Quest 模式 ---你的"赛博正式员工"

据我使用，Qoder 目前有三个入口：Agent、Quest 和ASK。其中，Agent 和 Quest 是我用得最多的。而 Quest 模式，我愿称之为"赛博牛马"。

为什么叫"赛博牛马"？因为它可以 7×24 小时工作。只要你把需求（比如 Spec 文件）定义好，提交后就可以去睡觉，第二天来"收菜"。

我对它的定位是：通过 Quest 模式，把 Qoder 调教成一个更懂你的正式员工。为什么是"正式员工"？因为：

它会先输出一份详细的设计文档
你可以修改文档中不妥的地方，让它重做或手动调整
整个过程是 Spec 驱动的

值得一提的是，Quest 支持 Human-In-The-Loop。在 Agent 模式中，你给它一个任务后，中途不能再打断，必须等它做完上一个任务才能响应新需求。但在 Quest 的迭代过程中，你可以随时介入。比如它执行到一半，你发现漏了一个点，说"给我补一下"，它能立刻 get 到，并在后续执行中纳入你的新需求。

Quest 的执行流程是：Plan & Act。它会根据设计文档生成 To-Do List，挨个打勾执行，并留下操作轨迹供你 review 或审计。过程中你也可以让它暂停，或追加新需求。

最重要的是，它支持 7×24 小时运行。目前有两种执行模式：Local（本地）和 Remote（远程）。

实战案例：存量项目功能扩展