本人做软件开发的，主要以编码工程的角度分享稳定性，准确性的功能开发技巧。trae solo不管是写代码，分享源码还是整理资料，首先进行如下2个配置，1. 规则和技能配置；2. 具体场景的智能体创建；。
1. 设置->规则和技能配置
-
回答之前先想清楚，不要着急输出，宁可先问我两个关键问题确认需求对齐，也不要给我一堆正确的废话，我要的是具体、能用、针对我的情况的答案，不是放之四海皆准的建议，回答的时候先翻翻我们的对话，记忆中有没有相关背景，能联网就深入搜索相关资料，能写代码就写一个，把你能用的能力都用上，如skil和智能体，如果我说不满意，不要只换个说法，要换个思路重新想。
这段话可以保证需求和ai在执行任务前尽量对齐，避免出现和需求不一致的问题。
-
开发项目必须要保证编译正确，开发完成后要保证项目编译通过且功能和需求对齐，开发的springboot则通过curl测试先关接口，返回的字段和微信小程序端要求的字段是否对齐。
这段话是为了让开发完成后，自己完成初级的闭环测试，如程序编译通过，接口字段和前端对齐等
-
控制复杂度扩散，系统要收敛，通过控制入口和出口，将核心全部收敛到核心模块中；
这段是保证修改代码尽量收敛，避免功能分散在各个类中。
-
将每次用户输入的需求的实现方式都记录在根目录的requirements文件夹中，文件名为(日期+需求名.md)文档中，内容包括但不限于：
- 功能描述
- 架构图
- 技术实现
- 接口定义
- 数据库设计
- 前端页面设计
- 后端接口设计
这段是记录每次功能开发的文档比例，避免后期超过上下文200K后上下文找不回来的问题
2. 设置->智能体
我的项目存在多种技术栈，例如python，java，vue3.微信小程序，抖音小程序，android compose等，如果直接使用solo 模式很难高质量的完成各种任务，所以在智能体中针对不同的问题创建对应的智能体，我一般选择智能生成的方式，然后在进行稍微的修改。
3. 使用技巧
-
spec模式：在每次执行任务时使用/spec模式，该模式主要区别在于不是依赖上就上ai开始干活，而是先让ai给出他准确怎么做的详细步骤，跟你把需求对齐后再开始干。如果发现给出的spec不完整或者不符合你的预期，修改后再让ai开始干活。
-
需求粒度：现在很多工作本质不是ai干不了，而是和ai的需求粒度没有对齐，针对这种情况问的问题要越具体越好。如果遇到自己不是很懂的场景，则让ai搜索资料给出具体的方案后再执行。如果是代码这清楚说明那个类那个函数怎么修改，而不是说某某功能不对。
-
测试环境配置：ai现在能干很多活，但是很多时候给出的结果是错误的，怎么让ai自己检查是否正确呢？那就是给ai搭建一个他自己可以闭环测试的环境；举2个例子；
- 我在开发springboot后端服务时，在本地搭建了一个docker+redis+mysql+minio+app的完整环境，并且在项目规则中清楚的介绍了当前项目环境，当测试redis缓存时，在docker中查询redis-cli，账号和密码多少。这些技术配置都在规则中写好。当需要验证redis缓存是否有效时则可以完整自己闭环的测试。
- android语音转文字ncnn集成；我当时遇到一个speech 2 text的需求，首先我让trae solo在网上找了5个方案。然后让trae solo模式选择其中一个方案进行开发，开发完成后测试的规则为，当前电脑连接的设备2，在设备1中安装语音识别的app，然后在设备2中播放声音进行测试。这里面有个有意思的分享，在测试过程中，ai觉得自己已经写正确了，但是始终不能正确解析，ai认为两个设备离的太远，然后写了 一个测试声音的程序，他自己完成测试时，大概输出了一句，我能听到声音但是不能正确解析。
-
前后端项目开发：针对多端项目我通常放在一个目录下面，在规则中指定那个目录是什么写清楚，例如a目录是后端springboot项目，b目录是android compose项目，c目录是抖音小程序。这样每次修改就能准确的保证修改代码的位置是正确的。否者我让修改首页某某功能时，他搞不清楚是后端还是抖音小程序还是android compose，避免ai改错了。
-
新项目：如果拿到一个新项目，不要着急让ai直接开始改，而是让ai从不同的角度扫描工程先整理成文档，例如当要查询某个数据流时，先让ai将该数据流从接收，处理，发送整个流程先读清楚制作成文档。必要时绘制相关的流程图，在执行相关任务时先读取相关文档后再进行开发。
-
提示词：写提示词时不只是让ai做某个事情，而是要将怎么验证闭环相关的提示词也明确写入，这里可以制作成skill，skill可以针对某个特定场景进行深入处理。避免写规则或者提示词写不全且难以复用的问题。
-
闭环测试：针对不同的测试场景，定义对应的测试skill，严格限定测试结果，如果测试通过才进行下一阶段的开发，如果没有通过则深入分析原因后并修复，然后再进行测试，直到测试通过再进行下一个任务。
-
问题反向问：问一个问题时让ai按照你的意图给出答案后，再让ai分析给出的方案是否有漏洞，根据分析出来的漏洞在重新设计方案。
-
整体代码质量检查：由于工程整体由ai接管开发，长期会导致代码很少有真正的review，这种情况就需要定期的检查代码的质量，可以通过定义代码质量检查的skill进行定期的扫描，同时对项目中的文档和实际架构进行验证，是否有跑偏的情况。如果有则需要细粒度的对齐进行调整。这里的skill不是prompt，而是prompt+script
