技巧：需求有歧义先确认再动手
说明：需求没说清就让 AI 开工，它往往按最新一句话执行，改完才发现和原方案冲突。在规则里写明「需求有歧义时必须先问我」，能省下大量返工。
2 个赞
技巧：别堆砌过多 rules 和 skill
说明：很多 rules 其实是副作用，skill 处理小问题还很墨迹。按需保留、宁少勿滥，把规则留给真正高频且必要的流程，上下文更干净、更省 Token。
2 个赞
技巧：按依赖拆模块独立验证
说明：拆分时让每个模块依赖尽量少、能独立跑、能独立验证。先规划出「模块 → 依赖 → 复杂度」表，再逐个施工，出错时也好定位是哪一块。
2 个赞
技巧：大改动前先出方案，确认再动手。
说明：改核心逻辑时，先让 TRAE 输出改动方案和影响范围，人工确认方向对了再生成代码，避免白烧积分重做。
2 个赞
技巧：只喂最小必要上下文，别全丢。
说明：排查报错时只贴相关文件和完整报错栈，不要把整个项目拖进对话。上下文越小，响应越快、积分消耗越少。
2 个赞
技巧：需求写清验收标准，一次做对。
说明：提需求时附上“怎样算完成”，比如“运行后不报错、接口返回 200”，模型会自查，返工次数明显减少。
2 个赞
技巧：从脚手架开始别从零搭
说明：基于固定的技术栈和脚手架起项目，而不是每次都从零开始。约定好的结构能减少重复搭建，AI 也更容易对齐项目规范。
2 个赞
技巧：subagent 只用来探索
说明：子 Agent 只用来探索、查资料；写代码交给主 Agent。子 Agent 会重建缓存、丢失全局关联，容易「局部没问题、全局翻车」，返工反而更多。
2 个赞
技巧：机械批量活用轻量模型。
说明：批量重命名、格式统一、生成注释这类机械修改用轻量模型就够；架构设计、疑难 Bug 再切强模型，积分能省一半。
2 个赞
技巧：报错先让 AI 诊断，再修。
说明：遇到报错先让 TRAE 复述错误原因并定位到具体行，确认诊断正确再让它改，防止瞎改一通引入新 Bug。
2 个赞
技巧：重复流程沉淀成 Skill。
说明：常做的事（项目骨架、爬虫模板、部署脚本）写成 Skill，下次一句话直接套用，比每次重新描述需求快得多。
2 个赞
技巧：一个任务一个对话。
说明：不同功能、不同项目分开开对话，避免上下文互相污染；切新任务前让 TRAE 总结当前进度，新对话粘上就能接着干。
2 个赞
技巧：新项目先要目录结构再写码。
说明：搭建项目别让 AI 一口气全生成，先让它给出目录结构和每个文件的职责，确认后再逐文件生成，出错好定位。
2 个赞
技巧：核心逻辑先写测试再实现。
说明：让 TRAE 先生成测试用例，再写功能代码，跑不过就继续修，能显著减少隐蔽 Bug，后期回归验证也省事。
2 个赞
技巧：改完让 AI 自查一遍再提交。
说明：重要改动完成后补一句“以 Code Review 视角审查刚才的改动，列出潜在问题”，经常能抓出边界条件和遗漏的错误处理。
2 个赞
新建任务顶上可以选择模式哦
Word：办公专属
Code：软件开发、代码变成
Design：图片、视频设计创意
2 个赞
聊天记录不要删，一句话唤醒沉睡的巧思关联。
2 个赞
技巧：先要计划，再让动手。
说明：复杂任务开工前先说“先给方案，别急着改代码”，确认步骤靠谱再让它执行，方向错了也不会白改一大堆。
2 个赞
技巧：提需求带上验收标准。
说明：比如“修这个 bug，改完跑测试必须全绿”。把做完的标准写进需求，AI 会自己验证，省掉来回返工。
2 个赞
技巧：报错贴原文，别只截图。
说明：把终端里的完整报错和复现步骤直接粘给 TRAE，截图经常丢关键行。信息越全，一次改对的概率越高。
2 个赞