Trae使用技巧

技巧分享
, , , ,
1

你在使用trae时都有哪些提高需求颗粒度的技巧？

1 个赞
2
  1. 开发前后端项目时，将前后端项目放在一个文件夹下，在规则中添加每个文件夹的说明，例如a目录是springboot后端，使用了mysql+redis等b目录为微信小程序，c目录为flutter跨平台项目，d为vue后端管理系统。
  2. 遇到新项目，首先让trae从不同的角度扫描项目，例如先扫描后端，在扫描前端，分别画出架构图，详细接口等并让他们记录成文档
  3. 在规则中让每次执行任务前先扫描生成的相关文档，并把执行过程中改动的内容全部记录在文档中
  4. 解决上下文爆了的问题：在规则中添加每次执行任务将执行的修改项全部记录在一个文件中，在下次执行任务时先读取相关内容
1 个赞
3

1. 每次的修改将记录在changelog.md文件中，在工程根目录下创建名为changelog的文件夹，将相关日志文件放在changelog文件夹下，changelog.md文件夹下记录每次修改的内容,如修改了哪些文件，那些类，哪些方法，哪些变量，，目的要写清楚，文档格式要便于后续快速读取；

2. 当changelog.md文件超过1M时则生成一个新的文件，每次回话前先读取changelog.md文件中跟当前需求有关联的部分再进行问题分析；

3. 当每次执行新任务是先读取changelog.md文件中跟当前需求有关联的部分再进行问题分析；

1 个赞
4

不同角度扫描？是指？？

1 个赞
5

先扫描整体的架构，然后再扫描具体的功能流程。

6

一个项目有几十上百个具体的功能，把这些功能怎么做的，架构是什么样的，用到了那些类，那些方法，有什么需要注意的，全都让ai总结一遍，然后再让ai复制开始写，而不是直接让ai开始写。

1 个赞
7

我是使用trae开发项目的的步骤

  1. 创建对应场景的agent
 1. 例如我要开发springboot服务，则创建一个顶级的springboot智能体 
 2. 调用trae系统默认的skill-creator创建对应的skill
  1. 定义规则：在规则中说明项目时干什么的，有哪些规则
1. 回答之前先想清楚，不要着急修改，宁可先问我两个关键问题，也不要给我一堆正确的废话我要的是具体、能用、针对我的情况的答案，不是放之四海皆准的建议，回答的时候先翻翻我们的对话，记忆有没有相关背景，能联网就搜一下，能写代码就写一个，把你能用的能力都用上如skill和agent等，如果我说不满意，不要只换个说法，要换个思路重新想。要保证和我的需求相符，改动范围不能影响其他正确的功能（这段话来着网上一个博主，做了一些调整）

2. 每一个函数的修改都要写单元测试，同时对有影响的模块也要一起做测试，保证每一步正确且不影响其他模块

3. 项目技术介绍

例如我项目不指定“项目中的pcap是Linux cooked v2"格式的pcap文件，而不是标准的以太网帧格式。这种格式没有以太网头，而是有一个特殊的Linux cooked header。”这个背景ai在执行的过程中就会不停的重试，这种情况比较吃ai调用请求数。

一、pcap 是什么？

PCAP = Packet Capture，中文：数据包捕获文件 / 抓包文件格式。 简单说： 就是把网络上一来一往的流量（数据包）原样 “录下来” 存成的文件，用来分析网络、排查问题、逆向、攻防。 二、用来干什么？ 1 抓包 / 看网络流量看软件发了什么请求、传了什么数据、协议是什么。 2 排查网络问题卡、丢包、连不上、延时高，都可以看 pcap 定位。 3 协议分析、逆向、安全测试分析游戏封包、接口、漏洞、攻击流量。

项目中的pcap是Linux cooked v2"格式的pcap文件，而不是标准的以太网帧格式。这种格式没有以太网头，而是有一个特殊的Linux cooked header。

4. 项目说明

1. 项目为解析pcap的工程，首先通过实现一个python脚本能够解析每帧pcap中的数据;
2. 工程根目录protocol目录为pcap的proto文件工程
3. proto项目如果在本机macOs上编译不过，直接取出protocol目录中的所有proto文件直接在工程中安装当前机器环境进行编译，或者登录ssh server机器，该机器为linux,将项目打包push到linux上进行编译；
4. 开发的C++后端程序，在ssh server的linux机器上进行编译，不考虑mac电脑
5. C++解析pcap项目最后是部署在Linux上的，也就是ssh seerver这台机器上。/root/pcap/目录下，linux是不能上外网的，可以在macOs上下载好后推送到linux上。
6. C++服务是部署在linux上的，也在linux开发
8

这串回复里已经有一些很实用的细节了，我归纳一个更通用的 Pattern：

多人提到了一个核心问题：上下文越来越长，AI 开始迷失。

你们各自给的解法其实可以归到同一个框架里：

分层文档策略

第一层：架构速查表

  • 让 AI 扫描后，把项目结构、模块关系、技术栈快速写成一份 1~2 页的文档
  • 不写细节，只写"是什么"和"怎么连"
  • 这份文档在每次开新任务前必读

第二层：变更日志

  • 每次改了什么、为什么改、影响了什么，强制要求 AI 记进 CHANGELOG
  • 这个日志文件是当上下文中转站，不直接塞进主对话

第三层：单次任务上下文

  • 每次新任务开始时，只把 CHANGELOG 里跟本次任务相关的片段提取出来
  • 而不是把整个项目历史全部塞进去

这三个分层做好之后，你会发现 AI “迷路”的概率会明显下降，因为每次它看到的都是“跟这件事有关的东西”，而不是“项目全部历史”。

另外，你提到的“pcap 文件格式特殊”这种背景知识，建议直接写进项目根目录的 README 或者一个单独的 tech-context.md 里，让 AI 一上来就读到，而不是靠对话过程中慢慢理解——后者很容易反复踩坑。

2 个赞
9

高手，高手，一下子就get到我要说的了

1 个赞
10

这个是每次执行前会默认读的文件还是要在规则里写清楚？

1 个赞
11

你可以手动读取

1 个赞