一句话技巧金句：先做计划，优化提示词，再开始任务。
一段技巧说明：先给项目做完整的计划步骤和节点验证，再去优化提示词内不必要的因素和多余的重复，然后开始任务并时刻监控完成进度和上下文达到最优的使用体验。
2 个赞
一句话技巧金句：优秀内容留存，方便后续使用。
一段技巧说明：当抽卡效果好或者满意度高的项目进行标注留存，可以让模型学习之前的项目经验去完成新的内容不会重复消耗Token。
2 个赞
技巧：复杂任务列计划拆分工作项
说明：对于复杂任务拆分出plan，然后再分别对于计划的步骤，使用不同角色进行任务分工。
2 个赞
技巧：建立测试用例
说明：在使用trae时，对于一些功能完成之后需要进行测试验证，可以使用AI测试，可以保留测试用例便于之后测试能有统一的测试用例。
2 个赞
一句话技巧金句：适当中断，及时止损。
一段技巧说明：当某个任务卡在自己不懂的部分一直不动或者不断重复消耗Token时要懂得及时止损停止任务并更换高智力模型分析之前的问题，很可能是模型能力导致的重复不要一味的等待导致积分耗尽。
2 个赞
一句话技巧金句：蒸馏重复内容，生成Skills。
一段技巧说明：通过把重复性高的日常流程进行Skills大幅优化实际工作和生活中的使用体验和复用性，以及体现真正的价值。
2 个赞
一句话技巧金句：但行Trae，莫问Token。
一段技巧说明：用就完事了，TRAE的好，会如涓流的溪水灌溉你的心田。让你无法自拔，难以言喻。AI工具的0到1，从打开Trae开始。
2 个赞
技巧： 长对话先总结，再开新任务。
说明： 当上下文变长时，先让 TRAE 总结目标、已完成内容和剩余任务，再开启新对话继续推进，可以减少信息丢失，也更省 Token。
技巧： 小任务先用轻量模型。
说明： 格式整理、简单改写、信息提取等任务，可以先用轻量模型；复杂排错、架构设计、多文件改动，再切换更强模型。
技巧： 需求先说目标，再补边界。
说明： 写 Prompt 时先讲清要实现什么效果，再补充技术栈、文件范围、禁止事项和验收标准，TRAE 生成结果更稳定。
技巧： 报错先贴堆栈，再讲现象。
说明： 遇到 Bug 时把完整报错堆栈、复现步骤、期望结果一起发给 TRAE，比只描述“运行不了”更容易一次定位问题。
技巧： 大改动先让模型列计划。
说明： 涉及多文件重构或功能开发时，先让 TRAE 输出修改计划和影响范围，确认后再执行，能减少返工和误改。
技巧： 常用流程沉淀成 Skill。
说明： 把重复性工作（如生成组件、写接口文档、检查代码风格）整理成固定提示词或 Skill，下次直接调用，效率更高。
技巧： 上下文只带关键文件。
说明： 不要一次性塞整个项目，优先提供相关文件、核心配置和必要依赖说明，既省 Token，也能让模型更聚焦。
技巧： 生成代码后要补验收用例。
说明： 让 TRAE 写完功能后，顺便生成测试用例或自测步骤，你可以直接按用例验证，发现问题再精准回改。
技巧： 评审模式先分优先级。
说明： 做 Code Review 时先让 TRAE 按“阻断问题 / 建议优化 / 风格问题”分类输出，修复顺序更清晰，避免被低优先级意见带偏。
技巧： 卡住时先缩小范围。
说明： 如果 TRAE 修改结果不理想，先把问题拆小：只改一个函数、一个页面或一个报错点，确认无误后再逐步扩大范围。
2 个赞
一句话技巧金句：及时存档，好过追悔莫及。
一段技巧说明：关键内容和备份一定要及时存档，避免整个工作区被错改或者出现问题后有48小时内可以恢复的内容作为补偿机制，有些代码一旦改错影响非常大。
2 个赞
技巧：报错给全，再让 TRAE 定位。
说明：遇到 Bug 时，把完整报错、复现步骤、相关代码文件、期望结果和不能改的边界一起发给 TRAE，并要求它先定位原因，再给最小改动方案。不要只发“帮我修一下”，这样能减少来回追问，排查更快，也更省积分。
2 个赞
技巧：动手前先让 TRAE 复述。
说明：提完需求后补一句：“先别改代码，复述我的目标、约束和验收标准，再列执行计划。”确认理解一致后再让它执行。适合复杂需求、跨文件改动和重构，能减少跑偏、返工和无效积分消耗。
2 个赞
还有尾班车可以搭吗？。。。
现在包括trae在内的各种ai工具，对大模型的选择和使用，普遍都默认个auto模式，即可能在你不知情的情况下，多次切换其实际使用的大模型。如果你正在执行的是一个较长的连续任务，建议不要用auto模式，而是直接指定一个自己认为合适的大模型。
因为各个模型的上下文长度，有可能不同，自动切换大模型的时候，如果正好从长上下文切换到短上下文的大模型，则上下文会强制进行压缩或者截断，损失部分上下文。如果你正在执行的是一个长任务，就可能碰上这种情况。有时候我们做长任务，一天一夜之后觉得模型突然变蠢了，可能就跟上下文被截断或压缩有关。
2 个赞
技巧：脚本分存，减少重写耗 token
说明：AI其实挺聪明的，但是也很笨的，比如一个硬件项目开发过程中，它可能需要写很多临时脚本来解决问题，比如解决网络，进程守护，测试等等，但是它对话窗口久了就忘了，或者同一个对话窗口多轮对话后，就忘了，一些临时脚本就开始重新写，功能跟以前的临时脚本一样啊，这样不是费token吗
2 个赞
技巧：用到的环境变量本地文件记录
说明：有的环境变量在系统环境变量中，AI开发的时候直接就能获取，但是有时候，你让AI下载一个工具安装了之后，或者自己写的脚本加入到环境变量中，你对话长了或者换个对话，AI又要下载类似的工具，AI只管解决问题，不管下载了多少个类似的工具来解决问题，所有它查不到对应的工具的时候，又要对话半天，去解决工具链相关的问题，又费时间又费token
2 个赞
执行之前一定要让它找你确认！！！
2 个赞
这不是鼓励我去用别的平台吗？
3 个赞
技巧：实测追理论，分层破短板
说明：做固件开发的时候，其实调优非常难，下面是我的提示词原话：你知道木桶效应吗，所以只要渲染最不流畅的地方没有达到 26fps，人眼就会觉得很卡，所以我们考虑的时候一定先从硬件层，传输层，渲染层，系统架构层考虑，然后得到理论渲染帧率，和实际渲染帧率，然后不断的调整实现渲染帧率往理论值走，这每一层你都可以上 github 调研或者自研算法架构来进行优化
你知道木桶效应吗，所以只要渲染最不流畅的地方没有达到 26fps，人眼就会觉得很卡，所以我们考虑的时候一定先从硬件层，传输层，渲染层，系统架构层考虑，然后得到理论渲染帧率，和实际渲染帧率，然后不断的调整实现渲染帧率往理论值走，这每一层你都可以上 github 调研或者自研算法架构来进行优化
2 个赞
估计搞忘记了
2 个赞
都结束了，你还写？
2 个赞