文章背景图

AICoding企业级实战分享--基于qoder官方文档展开

2026-03-09
24
-
- 分钟

本文主要是基于qoder的官方文档,其他ai ide其实都大同小异的,可以参考着配置。

创建索引

Qoder 会自动为代码库建立索引,方法是生成文件嵌入向量。这使基于 AI 的代码理解、智能推荐和语义搜索成为可能。索引以增量方式进行,因此新建或已修改的文件会实时处理——无需人工干预。

注意: 支持最多 100,000 个文件的代码库。对于少于 10,000 个文件的代码库,自动更新默认开启。对于更大的代码库,需要手动启用索引。

30a2403f-0429-4c38-8611-fcc08fdce83a.png

当不开启索引的时候,我们可以看到,系统寻找文件的方式,基本上是用通配符,比如你如果想找支付的逻辑,它就会去查找pay**,如果你的命名不太那么符合规则的话,那就可能会有遗漏。

如果创建了索引之后,就不再是通过通配符的方式去查找了,而是直接找到对应的文件

这是没有建立索引的搜索结果

2f68de17-bc8e-48f6-bf1d-fd94b6a5f67b.png

以下是建立索引后的搜索结果

1baefe92-7b89-4dce-893a-5776d09fe4b5.png

而且从速度上来说,建立索引之后也快了很多,并且也更加全面

配置索引

1. 在 Qoder IDE 右上角,点击用户图标,或使用键盘快捷键(  ,(macOS)或 Ctrl Shift ,(Windows)),然后选择 Qoder 设置

2. 在左侧导航栏中,点击 代码库索引

3. 选择以下之一:

· 若要手动启用索引,点击 代码库索引 旁的 创建

· 若要启用持续的后台索引,将 自动更新 切换为开启。

提高 Qoder 检索准确率的方法

1. 配置 .qoderignore(效果最显著)

排除不相关的噪音文件,让索引聚焦于有价值的代码:

target/        # 编译产物
*.class        # 字节码
*.jar / *.war  # 打包文件
document/      # 非代码文档
*.log          # 日志文件


2. 添加业务语义注释(核心业务代码优先)

帮助语义索引理解代码的业务含义,尤其适合:

  • 类/接口级注释:描述整体职责

  • 复杂方法注释:说明业务功能

  • 字段注释:解释缩写或专业字段含义(如 PH_CERTI_CODE → 投保人证件号)


3. 规范命名

使用有业务含义的名称,让索引能通过名称推断语义:

// 差 ❌
String s1, List<Object> getList()
// 好 ✅
String claimNo, List<TWfInstance> getTasksByReportDate()

4. 清理废弃代码

删除或归档不再使用的代码,避免检索时返回过时的错误结果。


优先级建议

优先级

操作

成本

效果

🥇 最高

配置 .qoderignore

🥈 高

核心业务类加注释

🥉 中

规范方法/字段命名

参考

清理废弃代码

记忆

Qoder 提供长期记忆功能。随着开发者与 Qoder 互动,它会逐步构建一套全面的记忆库,涵盖个人开发者、特定项目以及遇到的问题等信息。这些记忆会随时间自动整理并更新。

ec435a0e-a1c0-43a0-831d-264afe401da5.png

如果不记忆的话,一般是当前项目内有效的,如果需要记忆的话,可以主动让ide记住

比如我让它记住赔案号是claimNo

d34f1dd2-9be2-4390-8df2-fd29c8d699cf.png

然后可以看到记忆里面生成了一条这样的内容

7b264fa4-6ea9-4d1b-a382-6b0e8f6beabf.png

规则

如果记忆和规则冲突,则规则优先。

Qoder 支持为每个项目配置专属规则。规则存放于 .qoder/rules 目录中,仅对当前项目生效。它们可优化模型对你的编码偏好的适配,包括项目所用框架与代码风格。

大型语言模型(LLMs)依赖通用知识,因此缺乏项目特定的上下文和规则。Qoder 的规则通过将预定义的上下文有策略地注入到提示中来弥补这一不足,从而引导 AI 的回答更一致地符合你项目的标准和要求。

最佳实践

· 保持简洁:让规则聚焦且明确无歧义。

· 结构清晰:使用项目符号、编号列表或 Markdown 格式以提升可读性。

· 包含示例:提供“良好”的代码示例以指导模型。

· 迭代与优化:根据模型输出和反馈不断完善规则。

 

记忆(Memory)- 长期知识和偏好

适用场景:

1️⃣ 用户偏好设置

· 语言偏好(如"使用中文沟通")

· 代码风格偏好(如"注释用英文,业务逻辑用中文")

· 沟通方式偏好(如"简洁直接"或"详细说明")

2️⃣ 项目背景知识

· 技术栈信息(Spring Boot、MyBatis 等)

· 项目结构说明

· 构建工具和依赖管理方式

· 环境配置(JDK 版本、数据库类型等)

3️⃣ 业务领域知识

o tClmCase = 赔案表

o tClmObject = 索赔人层级的表

o claimNo = 赔案号

· 这些是 Claims 系统的核心业务概念

4️⃣ 开发规范和经验

· 代码命名规范

· 测试规范

· 注释规范

· 常见陷阱和最佳实践

特点:

·  跨会话持久化保存

·  可以主动检索和更新

·  帮助 AI 理解项目和用户习惯

·  分类组织(user_info, project_tech_stack, development_code_specification 等)


规则(Rules)- 行为约束和工作流程

适用场景:

1️⃣ 全局行为约束

规则示例:

- "永远不要删除文件前不先备份"

- "修改代码前必须先查看完整的文件内容"

- "执行危险命令前必须征得用户同意"

2️⃣ 工作流程规范

规则示例:

- "创建新功能时必须先写单元测试"

- "提交代码前必须运行所有测试"

- "API 变更必须先更新文档"

3️⃣ 特定文件类型的处理规则

规则示例:

- "*.java 文件:遵循阿里巴巴 Java 开发手册"

- "*.yml 文件:保持缩进一致"

- "配置文件:不能硬编码敏感信息"

4️⃣ 沟通和输出格式

规则示例:

- "代码审查结果必须按严重程度分类"

- "提供修复建议时必须包含具体代码示例"

- "禁止使用 emoji,除非用户明确要求"

特点:

·  定义"应该怎么做"和"不应该怎么做"

·  可以是全局的,也可以针对特定文件类型

·  通常包含强制性约束(MUST/MUST NOT)

·  影响 AI 的决策和行为模式


两者的配合使用

实际工作流:

记忆(Memory)提供背景知识:

→ 知道 tClmCase 是赔案表

→ 知道项目使用 Spring Boot 3.x

→ 知道用户偏好中文沟通

 

规则(Rules)约束行为:

→ 修改数据库相关代码时,必须检查表名是否正确

→ 必须先读取完整文件再进行修改

→ 发现严重问题必须立即告知用户

举例说明:

假设您要修改一个赔案查询功能:

记忆的作用:

· 我会从记忆中提取:tClmCase 是赔案表,claimNo 是赔案号

· 确保使用正确的表名和字段名

规则的作用:

· 根据代码审查规则,我必须检查:

o SQL 是否有注入风险

o 是否有事务控制

o 是否有适当的错误处理

o 是否使用了正确的表名和字段名(基于记忆)


简单总结

维度

记忆(Memory)

规则(Rules)

是什么

知识和信息的存储库

行为和决策的约束条件

作用时间

长期、跨会话

即时、当前任务

内容类型

"是什么"(事实、偏好、规范)

"怎么做"(流程、约束、要求)

更新方式

用户可以主动添加/修改/删除

通常预定义,也可动态添加

使用方式

主动检索或被动触发

自动应用于每个操作


存储与共享

· 规则文件直接存放在项目目录中,并通过 Git 等版本控制系统与团队成员共享,与代码库一同管理。

· 对于仅本地使用(不共享)的规则,请将 .qoder/rules 目录添加到项目的 .gitignore 文件中。

智能体

内置智能体

浏览器智能体

浏览器智能体是在智能体模式下使用浏览器完成任务的能力扩展。它可以在受控环境中打开网页、浏览内容、点击按钮、填写表单、滚动页面,并在必要时截图反馈页面状态,从而帮助你完成「需要实际访问网页」的自动化任务。只需在智能会话中用自然语言描述你的需求(例如“去官网查一下最新价格并总结差异”),智能体会在需要时自动调度 Browser 智能体,无需你手动切换模式或编写脚本。

 

核心能力

浏览器智能体主要具备以下能力:

打开与导航网页

根据你给出的 URL 打开指定网页。

在同一站点内跳转到新的页面或标签,例如点击导航栏链接、分页链接等。

支持多步导航任务,例如“依次打开 A 页面 -> 点击 B 菜单 -> 进入 C 详情页”。

阅读与提取信息

读取当前页面的可见文本内容,如标题、段落、列表和表格等。

从页面中提取关键信息,并用自然语言为你总结或对比。

根据你的指令在页面中“查找”相关信息,例如“在这个页面上找一下价格相关的内容”。

交互与操作页面

点击按钮、链接、切换标签页或展开/收起折叠内容。

在输入框、搜索框等表单元素中输入文字,并提交表单。

通过滚动页面浏览更多内容,避免遗漏关键信息。

可视反馈与状态感知

在执行复杂步骤时,按需截图当前页面状态,用于后续判断与说明。

感知页面是否加载完成、表单是否提交成功、是否跳转到了新的页面等,以便决定下一步操作。

适用场景示例

你可以在以下场景中考虑使用浏览器智能体:

信息检索与对比

访问产品官网、文档站点或博客,提取关键信息并生成总结。

对多个页面或多个方案进行对比,例如价格、功能或配置差异。

在线操作与流程演练

演练一个「基于网页」的操作流程,例如注册账号、提交工单(在权限允许和风险可控的前提下)。

帮助你梳理某个 Web 后台系统的典型使用步骤,并输出操作说明草稿。

辅助开发与测试

打开线上文档或 API 参考,提炼出与你当前代码相关的部分。

浏览 Web 应用的界面,帮助你检查页面结构、文案或交互逻辑,并给出优化建议。

建议在任务描述中说明目标和约束(例如“只阅读不提交任何表单”“只访问公开文档页”),帮助智能体更安全、稳定地完成任务。

如何在智能体模式中使用

浏览器智能体已内置于智能体模式中,无需单独配置。你可以通过两种方式调用它:

1. 自动调用:智能体模式会根据你的请求智能判断何时需要浏览器智能体。

2. 显式调用:使用 /browser 命令显式请求浏览器智能体。

详细使用步骤如下:

1进入智能体模式

打开 Qoder 的聊天面板并切换到智能体模式

2描述你的任务

选择使用 /browser 显式调用,或直接用自然语言描述你的需求,例如:

/browser 打开 https://example.com 并总结主要功能

/browser 查看 2025 年的定价计划并整理成表格

/browser 分析这个组件库中的主题自定义选项

查看结果

浏览器智能体将会:

· 执行必要的网页交互

· 提供所采取操作的详细说明

· 分享屏幕截图以供视觉验证

· 以结构化格式呈现提取的数据

使用建议与最佳实践

明确目标与边界

尽量用一句话说明“要达成的结果”,而不是只描述某一步操作。

对安全或权限敏感的操作,明确说明“不执行提交/支付/删除等操作”。

提供稳定的入口链接

优先提供具体页面 URL,而不是模糊的搜索词,这样可以减少跳转干扰。

如果需要跨多个页面操作,可以在提示中列出关键页面或路径。

适度拆分任务

对于非常长的流程(例如复杂配置向导),可以拆分成多个小目标,逐步执行并确认中间结果。

在每一阶段结束后,根据 Browser 智能体返回的结果,适当调整下一步的指令。

安全与限制

在使用 Browser 智能体时,需要注意以下事项:

· 权限与隐私

o 避免让 Browser 智能体在网页中输入或暴露任何敏感信息(如密码、访问令牌、个人隐私数据等)。

o 对涉及账号登录、支付或写入数据的操作,请优先采用手动方式完成,再让智能体进行只读验证或说明。

· 页面兼容性与稳定性

o 某些高度依赖前端框架或复杂交互的站点,可能存在加载缓慢或元素难以识别的情况。

o 页面结构或文案如果频繁变更,可能导致部分步骤执行失败,此时你可以补充更明确的描述或换一个更稳定的入口页面。

· 结果可信度

o Browser 智能体的回答基于实时访问到的网页内容,但网页本身可能并非权威信息,建议在关键决策前自行复核。

o 对于需要法律、合规或高风险业务判断的场景,不应仅依赖 Browser 智能体的自动化结果。

规划智能体

概述

Planning 功能让智能体模式在修改代码或执行命令之前,前置成一份实施方案与计划
对于中大型任务(如跨多文件的功能开发、重构或高风险变更),Planning 能提供清晰的可见性、可控的执行流程以及明确的落地路径。开启 Planning 后,Qoder 会基于你的自然语言需求生成一份结构化的方案与规划。你可以先审阅和调整这份计划,再让智能体按步骤自动执行。

适用场景

推荐在以下场景中启用 Planning:

· 处理复杂功能,涉及多个模块或多个文件。

· 预期会经历多轮迭代(设计、实现、测试、清理等)。

对于较小小的改动(例如“修正一个拼写错误”“重命名一个变量”等),你可以直接使用智能体执行,以节省时间,无需使用规划。

如何在智能体模式中使用

规划智能体已内置于智能体模式中,无需单独配置。你可以通过两种方式调用它: 自动调用:智能体模式会根据你的请求智能判断何时需要进行规划。 显式调用:使用 /plan 命令显式请求规划智能体。 详细使用步骤如下:

1. 描述你的任务

选择使用 /plan 显式调用,或直接用自然语言描述你的需求。在描述时,建议包含以下信息:

· 变更的目标或要实现的功能。

· 任何限制条件(例如”不能破坏现有 API""对于旧版路径需保持当前行为”等)。

· 可选:提及重要的文件或模块路径。

你的描述越清晰、越具体,生成的计划就会越贴合实际需求。

2. 生成计划

当会话中启用 Planning 时,Qoder 会:

· 分析你的需求以及相关工程上下文。

· 根据需求为您生成一份完整的规划,包含目标、技术方案、技术栈、实施计划等内容。

此阶段不会修改任何文件,也不会执行任何命令——产出仅是一份可审阅的计划。

3. 审阅并调整计划

在执行开始前,你可以根据自己的预期对计划做修改,例如:

· 编辑方案内容,使其更加精确、易懂。

· 补充 AI 未覆盖但你认为重要的步骤。

你也可以直接通过自然语言和 Qoder 协作调整计划,例如:“最后加一步更新文档”。

4. 启动执行

当你确认计划无误后,可以启动执行:

· 智能体会像普通 Agent 模式那样读取文件、修改代码、运行命令,或调用 MCP 工具。

· 待办事项的状态会在聊天底部实时更新(未开始/进行中/已完成)。

根据你的设置,某些操作(尤其是终端命令或 MCP 工具调用)在执行前可能仍需要你手动确认。

5. 执行过程中的调整

在计划执行过程中:

· 你可以随时查看每个待办事项的状态变化。

· 若发现计划本身或执行结果有问题,可以暂停、在聊天中说明新的要求,然后让 Qoder 更新计划后继续。

· 对于阻塞性问题(例如测试失败、依赖缺失等),Qoder 会在对话中明确指出,并规划相应的下一步。

这样,你始终保持决策权,而智能体负责具体的机械工作。

6. 收尾与回顾

当所有待办事项执行完毕(或你主动终止执行)后:

· Qoder 可以按步骤总结本次执行中完成了哪些工作(例如每个 To-do 具体修改了哪些文件)。

· 你可以结合 diff 视图、本地测试或 PR 流程,对最终结果进行正常的代码评审。

· 如有后续工作需求,可以再次开启一个新的 Planning 流程,继续迭代。

最佳实践

· 清晰描述目标:像给同事派任务那样写你的第一个提示词,说明范围、限制条件和验收标准。

· 对高风险任务默认开启 Planning:例如重构、接口调整、涉及核心路径的改动等。

· 迭代优化计划:如果第一版计划不理想,可以让 Qoder 调整,例如“更关注测试部分”“尽量减少对公共接口的改动”等。

· 保持每一步足够小:一个好的待办事项,应该能在一个较小的 diff 中看清它的影响范围。

自定义智能体

/create-agent 代码审查专家

下面是它创建的一个智能体的md文件内容

---

name: code-reviewer

description: 代码审查专家。主动审查代码质量、安全性、可维护性和最佳实践。在编写或修改代码后立即使用。

tools: Read, Grep, Glob, Bash

---

 

# 角色定义

 

您是一位资深代码审查专家,专注于确保代码质量、安全性和可维护性。您擅长发现潜在问题并提供具体的改进建议。

 

## 核心能力

 

- 代码质量检查: 清晰度、可读性、命名规范

- 安全性审查: 漏洞检测、敏感信息保护、输入验证

- 架构评估: 设计模式、模块化、职责分离

- 性能优化: 资源管理、算法效率、并发处理

- 错误处理: 异常捕获、日志记录、容错机制

- 测试覆盖: 单元测试、边界条件、集成测试

 

## 工作流程

 

1. 理解上下文:

   - 阅读相关文件,了解代码的业务场景

   - 如果是修改,运行 git diff 查看变更内容

   - 确定代码所属模块和功能定位

 

2. 全面审查:

   - 逐行阅读代码,理解实现逻辑

   - 对照审查清单逐项检查

   - 标记所有发现的问题

 

3. 分类整理:

   - 按严重程度分类问题(严重/警告/建议)

   - 为每个问题提供明确的修复方案

   - 优先关注高风险和核心业务逻辑

 

4. 输出报告:

   - 结构化呈现审查结果

   - 提供具体代码示例和修复建议

   - 给出总体评价和改进方向

 

## 审查清单

 

### 代码质量

- [ ] 代码清晰易懂,逻辑简洁

- [ ] 变量、函数、类命名语义化且符合规范

- [ ] 函数职责单一,长度适中(建议不超过 50 行)

- [ ] 没有重复代码,遵循 DRY 原则

- [ ] 适当的注释说明复杂逻辑(但避免过度注释)

- [ ] 遵循项目的代码规范和约定

 

### 安全性

- [ ] 没有硬编码的密码、密钥、token 等敏感信息

- [ ] 用户输入已验证和过滤(防止 SQL 注入、XSS 等)

- [ ] 权限校验到位,没有越权访问风险

- [ ] 敏感操作有审计日志

- [ ] 没有使用不安全的 API 或过时的依赖

 

### 错误处理

- [ ] 异常情况有适当的捕获和处理

- [ ] 错误信息明确,便于排查问题

- [ ] 关键业务逻辑有事务控制

- [ ] 资源使用后有正确释放(数据库连接、文件流等)

- [ ] 日志记录完整(包含关键变量、堆栈信息)

 

### 性能优化

- [ ] 没有明显的性能瓶颈(如循环内查询数据库)

- [ ] 集合操作选择合适的数据结构

- [ ] 大对象处理考虑内存占用

- [ ] 并发场景考虑线程安全

- [ ] 数据库查询有必要的索引优化

 

### 可维护性

- [ ] 代码分层清晰,职责明确

- [ ] 模块间耦合度低,依赖关系合理

- [ ] 配置与代码分离

- [ ] 有充足的单元测试覆盖核心逻辑

- [ ] 代码易于扩展和修改

 

## 输出格式

 

总体评价

简要总结代码质量和主要问题

 

---

 

严重问题(必须修复)

```

文件路径:行号

问题描述:[详细说明]

风险影响:[可能的后果]

修复建议:[具体代码示例]

```

 

⚠️ 警告(建议修复)

```

文件路径:行号

问题描述:[详细说明]

改进建议:[优化方案]

```

 

 优化建议(可选改进)

```

文件路径:行号

建议内容:[提升方向]

参考实现:[代码示例]

```

 

---

 

审查总结

- 发现严重问题 X 个,警告 Y 个,建议 Z 个

- 代码整体质量评级:[A/B/C/D]

- 优先处理建议:[下一步行动]

 

## 约束原则

 

必须执行:

- 对每个问题都提供具体的修复方案或代码示例

- 优先关注业务逻辑正确性和安全性

- 结合项目实际场景(Claims 自动化系统)进行审查

- 使用专业但友善的语气

 

禁止行为:

- 不要只指出问题而不给解决方案

- 不要过度批评,聚焦于代码本身

- 不要忽略文化差异(使用中文沟通)

- 不要假设代码有明显问题,先理解意图

 

## 特殊说明

 

如果发现以下情况,立即标记为严重问题:

1. 缺少关键的事务控制

2. 敏感数据未加密存储或传输

3. 权限校验缺失导致越权风险

试验一下

然后我让它审查我的代码,它给出了很多点问题,并评分为B-

19c5c91c-852e-4ffc-85b1-869fae7bcaee.png

 

MCP

配置一个链接数据库的mcp,可以用自然语言和数据库交互,我们使用oracle官方推出的工具SQLcl 

首先去下载对应的工具

然后在MCP中配置

418db21d-43a4-4d8e-9fb1-f4ff672c1725.png

配置后可以在我的服务中看到。

接下来测试一下

d6bf13d0-aa07-42cf-83b7-d09dfcb59019.png

 

75c07bb6-7df1-4754-acca-7f444e682732.png

 

如果数据库有慢sql,也可以用这个分析,它可以从索引,计划等角度来帮我们分析

e734140e-918f-40c6-bb66-22f03fff94cb.png
783fea52-c2c2-4e65-98be-5759cc0dcafa.png

 

这对于我们处理慢sql是非常有效的。

评论交流

文章目录