1.开始编写项目时，推荐写一个需求文档，不要求你对你的项目理解需求有多少，可以让ai参与到需求文档的编写中，推荐一些推理能力强的模型编写文档，当然最好的方法集思广益，多问几轮问题，换几个不同模型去问需求。在之后的code review环节，不仅仅要review diff代码，也要对功能验收一下.
2.在编写项目的过程中，当上下文溢出一次或者两次时，写一个交接文档，这里推荐github上的handoff，每次新开一个对话，让agent读一下handoff交接文档，便知道我们当前的进度到哪里了，下一步应该该做那一步，之前已经对那些功能验收了.
3.一次任务，不要放太多的skills，甚至我觉得不要用skills，我目前skills就两个，handoff，research两个skills。太多的skills，反而影响模型的思维散发能力，限制agent的创造性.
一句话技巧金句：记忆文件需要适时整理
说明：trae的记忆是一个markdown文件，实际上是AI自动记录的rules，需要像其他rules文件一同维护，避免过期、过时或AI理解不准确的规则影响任务执行。
一句话技巧金句：策划和编码双窗口同步执行
一段技巧说明：
技巧：在一个工作目录中，同时开策划和编码双窗口，可以保持编码任务对话的指令干净、上下文稳定，避免讨论过程产生的指令信息污染和干扰编码主线。
说明：执行代码编辑任务时，可以同时在一个工作目录下开两个同步窗口，一个用于写plan、沟通技术路线、优化提示词和草拟伪代码，另一个编码窗口只给干净准确的编码指令。
技巧：不要一次性堆太多提示词。
说明：太多会忘记。提示词越长、要求越多，模型越可能忽略中间或靠后的指令。尤其是同时塞进格式、语气、长度、角色、禁忌、示例等，很容易顾此失彼。另外，如果一句话里既有“要简洁”又有“要详细”，既有“正式”又有“幽默”，模型只能猜你真正想要什么。更稳的做法是先给核心任务，再补关键约束。如果需要，再逐步追加要求。复杂任务拆成多轮对话
提示词设计：明确说明让AI去权威网站查询（列出具体名字）
提示词设计：要求AI用客观的态度回答
重复流程沉淀成 Skill。 说明：凡是每周都要做的流程（生成周报、Code Review 模板、批量处理等），用 Skill 创作把步骤固化，下次一句话触发，效率翻倍。
一句话说清：
收尾让它自检一遍。
一段技巧说明：
TRAE 完成任务后，追加一句"请检查是否有遗漏的边界情况、未导入的依赖、语法错误"，常能抓出它自己刚写的 bug，省下手动 review 的时间。
复杂任务，先确定方案，方案定下来后，拆分为可以小步执行的任务。
高质量方案设计：用多agent并行，一个设计评价体系，一个设计方案，一个根据评价体系为方案打分
说明：这个方案被我设计为一个skill，参考来自吴恩达的一次AI使用技巧视频
git clone https://github.com/neko-622/iterative-evaluation-skill.git技巧：脚本用python处理
说明：别再让 AI 硬写 cmd、PowerShell 或 bash 命令，而是让它把任务写成 Python 脚本。Python 语法统一，Windows、macOS、Linux 基本都能跑，AI 对它的训练也更充分，所以很少出现 ls/rm/cat、%PATH%、$env:PATH 这类 shell 混淆。文件操作用 pathlib、shutil，环境变量用 os.environ，调用系统命令用 subprocess.run，参数用 argparse，异常也能清楚处理。写完后保存成 .py，随时能复用、审查和修改；Windows 上装好 Python 后，用 py 脚本.py 运行即可。注意：删除、覆盖、管理员权限等危险操作仍要人工确认；必须调用 Windows 专有命令时，用 subprocess.run 显式调用，并处理好编码和路径空格。这样 AI 帮你干活会稳定很多。
技巧：升级依赖，先列破坏点。
说明：让 TRAE“把 XX 库升到最新版”，经常一升级满屏报错，边跑边修很被动。我的做法分两步：先让它查新版官方迁移指南，输出 Breaking Changes 清单加项目内受影响的文件和行号，我评估完工作量再决定升不升、怎么升。上次升级前它列出 3 处废弃 API 用法，其中 1 处在核心导出函数里，提前改比事后修省了一个下午。
可直接用的 Prompt：“先别动 package.json。查官方迁移指南，列出：①新版 Breaking Changes；②本项目受影响的文件与行号；③每处的改法建议。”
技巧：交付前，先扫一遍残留。
说明：AI 写完的功能能跑，但里面常藏着“施工垃圾”：调试用的 console.log、写死测试数据和 mock 地址、注释掉的旧代码、没用的临时脚本。这些留在生产里就是隐患。我收尾固定加一句，让它全局扫描后列清单，由我决定删留，而不是它自作主张。有一次它扫出了写死的本地数据库密码，当场避免一次事故。
可直接用的 Prompt：“交付前全局扫描并列清单：①调试日志和打印语句；②写死的测试数据、mock 地址；③注释掉的代码块；④临时脚本和未使用的导入。只列清单，不要自行删除。”
技巧：易错逻辑，先列用例再写码。
说明：日期计算、金额分摊、正则替换、分页边界这类代码，AI 一把扫经常在边界上翻车，而且事后不容易测出来。我的做法是让它先别写实现，列 5-8 个测试用例：正常值加我能想到的最刁钻边界（闰年、月末、空输入、超长字符串），每个用例写明预期输出；我确认后按用例实现，最后逐条自验。等于把“改 bug”前置成了“对答案”。
可直接用的 Prompt：“第一步只输出测试用例清单：输入、预期输出、考察的边界点。我确认后，按用例实现并逐条自验。”
技巧：文案先定受众和平台。
说明：用 TRAE 写文案、邮件、公告，只说“写得专业一点”，出来的东西永远四不像。我的做法是开头先交代四件事：发给谁、发在哪、多少字、什么语气——最好再贴一段你认可的旧文案当样板。同一个需求，补上“发给已有客户的续费通知、邮件、200 字内、语气参考这段旧文案”，第一次输出就能用。
可直接用的 Prompt：“这份内容：受众是____，发布在____，字数____，语气参考下面的样例：……”
技巧：没报错的 Bug，加日志二分。
说明：最头疼的不是报错，是“没报错但结果不对”——数据在中间某一步悄悄变了。让 TRAE 全链路排查既慢又烧 Token。我的做法是让它沿数据流在 3-5 个关键节点加打印点，跑一次看输出从哪一步开始偏离预期，二分缩小范围，定位后删日志、修问题。比让它瞎猜快得多，基本一轮定位。
可直接用的 Prompt：“不要改逻辑。沿这条数据流的关键节点加 3-5 个打印点，我跑一次后对比实际输出，定位第一个偏离预期的环节。”
技巧：多窗口并行，先发分工单。
说明：项目大了想开多个会话并行赶进度，结果两个窗口改了同一个文件，后提交的把先提交的覆盖了。我的做法是开工前给每个会话发“分工单”：本会话只负责哪个模块、允许改哪些文件、禁止碰哪些；并要求它开工前先列出实际要改的文件清单和我核对。有交集先协调，改起来互不踩脚。
可直接用的 Prompt：“本会话只负责____模块，仅可修改____目录下的文件。开工前先列出你预计要改的全部文件清单与我确认，清单外文件一律不动。”
技巧：批量数据，先跑十行。
说明：让 TRAE 清洗、导入、转换批量数据（CSV、Excel、日志）时，它经常猜错字段含义，全量跑完才发现映射错了，几万行白处理。我的做法是先让它只处理前 10 行，输出“字段 → 含义判断 → 处理结果”对照表；我确认映射无误，再全量执行。多花一分钟，避免整批返工。
可直接用的 Prompt：“先别全量跑。取前 10 行处理，输出：每个字段你的理解、处理逻辑、结果样例。我确认字段映射无误后再全量执行。”
技巧：Review 时只审本轮增量。
说明：连续多轮修复时，可以明确告诉 TRAE：「只复核上一轮发现是否关闭，不重新审已经通过的内容。」这样能避免每轮 Review 都冒出新的旁支问题，让任务长期无法收口。