AI IDE使用技巧分享

我爱免费

作者：微信文章
国内可用AI IDE

我比较认真体验过的国产AI IDE有三个，分别是trae cn（字节）、codeBuddy cn（腾讯）、qoder（阿里）。

三个工具功能大同小异，基于vscode二开的（vscode的很多使用技巧都能复用）。其中前两者目前是免费的，内嵌多个厂家的模型，可以根据自己需要灵活选择。trae甚至可以使用自定义的大模型。

qoder是付费的，每个月10、30、100美元套餐任选，不同套餐功能是一样的，只是资源包大小不一样。

qoder也可以免费使用，但免费的只能使用最傻的模型，且不支持多模态，并且免费用户不支持Repowiki功能。

目前使用体验，模型聪明度感觉是qoder的极致模型>codeBuddy的Kimi2.5>trae的Kimi2.5，最傻的感觉是trae，有时经常一个小问题改几次没改好，找其他工具一下子就改好了。

界面舒适度，感觉是trae做得最好。尤其是solo模型的plan功能，让ai先出规划，程序员看了满意再执行，非常有掌握感。

目前Kimi2.5模型容易出现排队或者限流情况，建议日常使用选择codeBuddy的Kimi 2.5，codeBuddy限流后切到trae，如果再用到限流再切回自动选择模型。



使用技巧

1 建议目录结构


使用ai工具开发，建议把单独创建一个目录，把系统涉及的所有git项目（仓库）放在同一个目录下面。在项目根目录创建docs文件夹，把业务文档、接口说明、需求文档（转成txt）放进去，后续ai输出比较高质量的回答也可以复制出来放到docs目录下，这样ai对项目理解会越来越准确。再创建一个temp目录，准备存放一些临时文件，例如错误日志，或者某个任务规划，正在做的需求文档等，这个目录建议定期清理，避免知识污染。

https://doc.weixin.qq.com/mind-addon

第一次打开目录时，建议先让ai进行整体分析扫描
扫描项目全部目录结构 + 核心文件代码，从技术架构 + 业务逻辑双维度分析，按以下点简洁输出（标注关键文件 / 路径，拒绝空泛）：
项目介绍；
架构模式 + 程序启动入口（含路径）；
5 个核心文件 / 文件夹（路径 + 核心作用）；
核心数据流转链路；
项目核心业务领域 + 1-2 个核心业务流程；
维护最易出问题的 3 个风险点；
新增业务接口的优先查看文件（路径 + 顺序）。

扫描结果放到docs目录下面，可以做为后续沟通基础。

新开项目时，我一般还会把公司的业务介绍，名词术语，入职指南等文档丢进去。
2 提示词


跟ai沟通不需要特别注意提示词，就像跟同事聊天一样就行，例如这样

[img=604.733,150.711]https://mmbiz.qpic.cn/mmbiz_png/YtlK8JuUUWN8c844HL4XE1QmWiaruSbhSdyOD0uYWGh5Cro6nXnibUcnpuvxomx0uR1TdaQPR90RLzuSD8icTXRiaQ/640?wx_fmt=png&from=appmsg[/img]


如果有词不达意的情况下，可以使用提示词优化功能，让ai帮你写提示词。

只有给ai布置复杂任务时，才需要注意。建议使用总分结构，先给它说一下整体背景和需求，然后再将任务拆细，跟ai迭代沟通，最后确保ai理解了任务需求，生成任务计划后再行动。（具体例子可以让ai给个示范）
3 善用git工具


有时候让ai改一个小功能，它可能出错，改了一大堆文件。所以让ai改代码前要建议先在git上进行commit(暂时不要push)，等ai修改完后，再检查一下改得对不对，如果改对了就再及时commit。

现在三个aiide都会可以显示ai修改的内容，但合适的是diff视图，我不太习惯。我还是喜欢beyondcompare视图。推荐装一个TortoiseGit，用它看代码变更比较方便。（似乎vscode也有类似的插件叫Git Graph，不过我没用过）

不过这样会产生较多细碎 commit，可通过三种方式整理：1. commit --amend 追加提交；2. rebase -i 合并提交；3. reset 基准 commit（保留代码）后重新提交。
4 idea与ai ide联用技巧


日常写码、读码还是更习惯用 IDEA，想让 AI 复核代码时，不用再到 AI IDE 里翻找对应代码打开后再提问。

直接用 IDEA 的复制引用功能，把代码位置传给 AI，就能让它基于对应代码精准复核，跨工具协作更高效。
5 定期删除过期的记忆


qoder有记忆功能，在跟它对话过程中可以让它记忆一些重点知识，它也会自动挑重点记忆。但有时它会记了一些错误信息，所以建议定时看看它记了哪些内容，如果有错误及时删除，避免影响ai回答问题准确度。
6 使用TDD开发模式


项目新功能开发得差不多时，建议让ai给系统各个业务和重要接口增加单元测试用例。并且要求它以后修改完代码后要运行一次单元测试用例，保证用例都通过。

新加复杂需求，怕ai理解出错，也可以让它先写一些测试用例，人工审核后觉得没有问题再让ai开发并自测。

（注意，trae有时改完代码单元测试跑不过，就会偷改测试用例。要特别注意单元测试的改动）
7 qoder的Repowiki功能


Qoder 的 Repo Wiki 是主打工程文档化的核心功能，可一键为代码仓库生成架构图谱、依赖关系、API 手册等结构化文档，还能挖掘代码中的隐性设计知识并实现显性化。它会随代码提交自动增量更新，始终保持文档与代码同步，支持手动编辑、多格式导出，还能在仓库生成专属目录，轻松实现团队间的文档共享，高效沉淀工程知识，大幅降低陌生代码理解和项目交接的成本。

后续代码有修改时，ai会检测出来并提醒用户重新生成文档，保证代码和文档一致性。

（生成的文档数量很多，建议提交到git成为项目公共文件。不然建议在.git/info/exclude里面加上忽略选项，否则太多没有加到git的文件会造成混乱）



指令、规则、记忆、Skills相关知识点

指令、规则、记忆、Skills区别联系


有满意或高频使用的提示词，可将其制作成指令，用户自己按需使用；希望 AI 所有输出都遵守的要求指令，可添加为全局规则；若有包含提示词和配套工具的完整 SOP，还能封装成 Skills，让 AI 按需自主调用。

记忆是重要的项目知识或者沟通偏好，一般靠AIIDE会在交流过程中自动生成即可，用户也可按需自行添加或者删除记忆。


推荐的指令

1 整理流程图

请梳理【XX业务】（替换为具体业务）的完整流程，生成Mermaid**时序图**（或流程图/架构图），要求：
1. 步骤简洁，避免冗余节点；
2. 每个节点标注对应的核心代码位置；
3. 突出核心业务步骤和异常处理节点；
4. 仅输出Mermaid源码，无需其他多余内容。
5. 节点名称不能有小括号或者中括号，避免图渲染失败。

生成的结果，如果比较满意，可以保存到docs目录下，给ai按需参考。

目前几个ide生成的mermaid图表在ide工具本身查看都不方便，建议将 AI 生成的 Mermaid 源码复制到以下工具，进行自动排版、调整样式，提升可读性：

Mermaid Live Editor（首选）：https://mermaid.live/，支持所有 Mermaid 图类型，实时预览；（首推，支持下载成svg图片）

Draw.io：支持 Mermaid 源码导入，可手动调整节点位置，适配复杂图；

Typora：本地编辑器，支持 Mermaid 实时预览，可直接嵌入 Markdown 文档。
2 查bug

我在进行【XX业务】业务操作时出现错误，错误日志我已经放在temp/【XX业务】业务错误【日期】.txt，请你读取文件分析错误原因并修复。


推荐的规则

1 项目技术栈

项目后端代码要使用javajdk8，前端使用vue和TailWindcss
2 注释要求

请你记住这几条修改代码原则
1 只改必要改的 除此外不要改原来的代码和注释
2 代码里面的注释不要写修改的内容，或者问题回答。这些内容应该在代码外的回答里面。
像这样的注释是错误的“以下为新增方法，原有方法未修改”，这里是回答问题，不应该在代码注释中出现。
又例如下面也是错误的注释：“已严格按要求修改，不使用jdk8以上版本的函数”，这是给提问者的回复，不应该出现在注释。
这个也是错误的注释：“新增：泛型类型支持”，正确写法可参考：“以下函数支持泛型类型”
这也是错误提注释：“测试String和Number类型操作（无修改，保持原逻辑）”，正确应该是“测试String和Number类型操作”，因为“（无修改，保持原逻辑）”是给提问人看的，注释是要面向后面代码维护人员看的
这也是错误的注释：“ 修正点：使用正确的泛型类型引用定义方式”，注释是要面向后面代码维护人员看的，不是给提问人看的，后来维护的人看到这个注释会觉得不理解，为什么会冒出修正点
这也是错误的注释：“测试详情模型（增加更多调试字段）”，“增加更多调试字段”是给提问人看的，不应该在注释中出现，可以在代码外的问题回答中说明
这也是错误的注释：“如果已有 cleanup 逻辑，可以直接调用 customizeConsumerAfter 或者直接在此处编写资源释放逻辑”，代码有cleanup就写，没有就不写，根据事实来，不根据猜测来，不要出现如果的注释。如果有不确定逻辑，可以先向提问人问清楚。
这也是错误的注释：“建议添加序列化版本号，确保兼容性”，已经加了，就写上说明“添加序列化版本号，确保兼容性”，不要加建议字样。如果没加，就不要在注释里面写，在代码之外的回答正文写建议
3  代码注释应仅描述代码本身的功能、逻辑或特性，示例用法，容易踩的坑，辅助其他人阅读等，，如 "以下函数支持泛型类型"；而不应包含与代码功能无关的、用于向提问者说明的内容，例如关于代码修改情况（如 "以下为新增方法，原有方法未修改"）、对修改要求的回应（如 "已严格按要求修改，不使用 jdk8 以上版本的函数"）等这类属于回答问题范畴的内容，这些内容应放在代码之外的回答中。
4 该使用常量地方尽量使用常量，不要出现很多重复数字，字符串（这条适用于新写代码，修改代码要保持原来风格，并且只改必要的地方）
5 如果你需要在回答里面省略一些已有代码，请在注释格式里面加上明显的@note，并在后面加上一行文字“。。。 这里省略了原来代码”（注意是独立不可编译的一行文字，非注释），并且在代码输出后提醒提问人，代码中有省略
6 再次强调：注释应面向代码后续的维护人员，而非针对提问者或修改过程的说明。不能在注释中出现对问题的回答、对修改要求的回应等与代码功能说明无关的内容，例如 “已严格按要求修改” 等。注释应聚焦于代码本身的功能、逻辑、作用等，仅对代码内容进行解释说明，如 “以下函数支持泛型类型”“测试 String 和 Number 类型操作” 等。
让代码注释回归其本质功能 —— 仅作为代码的 “说明文档”，服务于后续的代码维护者，而非用于记录修改过程或向提问者传递沟通信息。
7 注释里面不要出现序号，例如“1. 捕获主线程上下文（深拷贝，避免子线程修改影响主线程） 2. 包装任务：”，因为这样修改代码在中间加逻辑时，需要重新调整注释里面的序号。
8 注意你是写商业代码 不要有这种情况: "这里只是示例，实际应该解析JSON响应"，在注释里面写几句话代替代码实现，这是不负责任的行为。如果确实不知道怎么写，你可以先提问，交流清楚。
9 修改代码时要注意原来的风格，例如原来输出日志是用System.out.，新代码就用System.out，如果原来是用log，新代码就用log
10 Linux Shell 中，反斜杠\作为行继续符时，其后必须直接跟换行，不能有任何字符（包括空格、注释、符号等）；作为转义符时，其后需紧跟要转义的特殊字符（如*、$）。所以如果有命令行的注释需要在命令行前面写，不能在命令的\后面补充。例如
例如不能这样写：
docker run --rm -d \
# 映射端口：主机5432端口 → 容器5432端口（PostgreSQL默认端口）
  -p 5432:5432 \
  -e POSTGRES_PASSWORD=temp123 \ # 设置超级用户密码（首次初始化必需，避免启动报错）
# 指定容器名，便于后续操作（如复制配置文件）
  --name temp-postgres \
  timescaledb-base:pg17
需要改为（所有注释在命令前面，在\后面不加任何字符，包括注释 ）：

# 映射端口：主机5432端口 → 容器5432端口（PostgreSQL默认端口）
# 设置超级用户密码（首次初始化必需，避免启动报错）
# 指定容器名，便于后续操作（如复制配置文件）
docker run --rm -d \
  -p 5432:5432 \
  -e POSTGRES_PASSWORD=temp123 \
  --name temp-postgres \
  timescaledb-base:pg17

我个人建议规则不要太多也不要太长，一是占用大模型计算资源，响应变慢，二是长了影响上下文，有可能还有反效果。


推荐的记忆

1 用户沟通核心约束：禁虚假认错、禁幻觉与强制核查

用户对AI沟通设定以下刚性约束，必须严格遵守：

**禁用虚假认错话术**：
- 禁止使用'你说得对，我承认我之前的理解有误'等形式化、非实质性的认错表达；
- 所有回应须言行一致，不因礼貌或缓和语气而牺牲准确性；

**禁止幻觉与强制核查**：
- 所有响应必须严格基于实际文件/代码内容，禁止任何推测或虚构（如声称存在某枚举类型而实际不存在）；
- 对不确定信息必须主动反问确认，不得输出假设性结论；

**问题分析与修改的严谨性要求**：
- 回复必须基于可验证的证据给出明确结论（如存在bug则指出位置并修复，不可凭空臆测问题）；
- 禁止推测性描述、模糊表述或添加无关干扰信息。
2 沟通风格要求

用户要求回答问题必须实事求是、专业严谨，禁止使用主观评价或拍马屁式回应，强调技术求真。




用好AI IDE建议

1先整体阅读一下官方的帮助文档，了解ide的功能及推荐用法

2关注官方微信公众号，会定时推出新功能介绍及实践分享

3可以关注一些知名的博主，看他们分享的使用技巧（如秋芝2046、数字游牧人）

4另外还有一些做aiagent、rag的产品经理或者技术人员会在抖音分享他们一些大模型使用经验、这些通用的知识也可以借鉴

5多安装skills

skills技术方兴未艾，目前很多技术博主都推荐，觉得这个技术是未来。而且skills适合多装，因为不使用时占用的资源比较少，多装几个，技不压身。说不定哪天跟ai对话过程中就用上了。这里有人整理了现在的skills清单Skills榜单-腾讯云开发者社区-腾讯云