#TRAE 技巧便利店
一、省钱的不是“少问”，而是“别让 AI 乱联想”
第一次意识到“计费方式会改变使用习惯”，是在一个再普通不过的场景里： QC 脚本跑到一半报错，指向一行很常见的调用—— summary = _summarize(…) 。
当时我还沿用以前“按次数计费”的心态：反正一次对话算一次，那就把需求写得越完整越好，顺带让 AI 扫一扫代码，寻思还能“顺便”帮我加点功能或者找点隐藏BUG。
结果是问题确实修了，但额度掉得也很真实。
那种感觉就像是：你本来只想修个水龙头，师傅却顺手把你家管线全巡检了一遍，还给你写了份未来三年装修规划。专业是专业，消耗也是真的快。
trae 现在走的是 Token 逻辑——你给模型多少上下文、它输出多少内容，都会算在账里（每条请求会记录输入/输出 Token 并折算成本）【参考：https://www.trae.ai/pricing】。
所以我现在的使用方式被迫重塑**【任务要拆小，指令要克制，尤其要禁止 AI 过度联想。】**
二、学会“一次只讲一件事”
按次数计费时，我的典型提问风格大概是这样，如：
-
“帮我修这个报错，顺便优化下性能”
-
“你扫一下整个项目，看看还能加哪些功能”
-
“把这个脚本做成通用工具，最好再给个可视化面板”
-
“如果你觉得还有别的隐患，也一并处理掉”
说实话，这种体验很爽，像在雇一个精力旺盛、还愿意主动加班的牛马搭档。
问题在于： 它会把“主动性”变成“上下文膨胀”。
一旦 AI 开始扫描更多文件、更多文档、更多可能性，它就会读取更多、推断更多、输出更多——而 Token 计费把这些“更多”统统换算成成本[新月脸]。
所以现在我基本换成另一套思路，如：
-
一个请求只解决一个问题
-
只给必要的代码片段，不给整份文件
-
明确写：不要扫描仓库、不要扩展功能、不要给我做“你觉得更好”的版本
这看起来像在压制 AI 的创造力，但实际效果是： 解决速度反而更稳定，成本也更可控。
因为我把 AI 的注意力从“想象空间”拉回到“证据链”。
三、Token 消耗最常见的坑，不是你问了十次，而是你让它做了这些事
-
扫项目 ：为了“更懂上下文”，它会把更多文件纳入阅读范围
-
扫文档 ：为了“更完整”，它会把更多说明、README、注释当成必读材料
-
发散功能 ：为了“更好用”，它会输出很多你没要求、也不一定需要的功能方案、边界处理、架构建议
-
长篇解释 ：为了“更清楚”，它会写一大段背景科普（很多时候你并不需要）
最要命的是，这些行为很隐蔽：你觉得它是在“帮你多想一步”，但在账单上，它是在“帮你多花一块”。
结合上面的坑，我现在最有效的省 Token 心得：多次分小任务 + 明确禁止过度联想
给AI立了个简单到近乎粗暴的规则：
目标：修复这个报错，让脚本能跑完。
范围：只看 XXXX_qc.py 和它直接调用的函数；不要扫描仓库其它文件。
输入：我只提供相关 60 行代码 + 报错首尾 20 行。
输出：只给最小补丁（unified diff）+ 3 条说明；不要扩展功能，不要写长解释。
这段话的关键不在“格式”，而在三条约束：
- 范围钉死 ：不许乱扫
- 输入变短 ：不喂整份文件
- 输出变短 ：不写你没要的功能
四、两轮工作法：把“定位”和“动刀”分开
我现在遇到代码问题，基本不让 AI 一上来就改，而是分两轮：
1第一轮只做定位
目标很明确： “你告诉我该看哪 1–3 个文件、哪段行号、哪条调用链。”
这一步如果 AI 开始讲原理、讲架构、讲可能性，我会直接打断：
“停，先给定位清单，不要解释。”
2第二轮只做修补
我把定位到的那 40–120 行贴出来，再让它出 patch。
这时 AI 已经没什么“自由发挥空间”，输出会更短、更贴题。
你会发现一个很反直觉的结果： 轮次变多了，但 Token 总量反而下降。
因为每轮都很轻，且不会被历史对话拖着越滚越大。
五、使用SKILLS技能
创建skills技能
---
name: "token-saver"
description: "压缩上下文并输出最省 token 的行动方案与补丁。用户要省 token、对话变长、要贴大文件/长日志/长报错时调用。"
---
# Token Saver
## 目标
在保证任务质量的前提下，尽可能减少输入与输出 Token：
- 控制上下文体积（只带必要信息）
- 优先用工具/命令产出“结构化结果”而不是长篇解释
- 优先输出可直接执行的补丁、命令、或最短结论
## 触发条件（何时使用）
- 用户明确要求“省 token / 控制成本 / 减少对话消耗”
- 用户准备粘贴大文件、长日志、长报错、长表格
- 同一对话上下文明显变长，单次请求越来越慢/越来越贵
- 需要跨仓库检索、批量重构、或多步调试，但希望每步都短
## 工作流程（强制）
### 1) 先定“最小目标”
用 1 句明确本轮目标，只允许以下三类之一：
- 修复：让 X 不报错 / 让测试通过 / 让脚本跑通
- 改动：实现 Y 功能（限定文件/模块范围）
- 分析：定位根因 + 给出最小复现/最小改动建议
### 2) 只取“最小上下文”
只允许携带以下信息（按需取用）：
- 文件路径 + 行号范围（优先 20–120 行）
- 报错的首尾关键 20 行（不要全量堆栈/日志）
- 依赖/版本信息（仅当与报错相关）
- 期望输入/输出样例（尽量 1 个）
禁止：
- 贴整份文件
- 贴整段训练日志/大表格
- 要求模型“通读全仓库后再说”
### 3) 先用检索，再用阅读
默认顺序：
1. 代码搜索（定位位置与调用链）
2. 只读必要片段
3. 直接出补丁或最短行动清单
### 4) 输出风格（强制简短）
- 默认不解释背景，不复述用户输入
- 优先输出 diff/patch、命令、或 3–7 条 bullet
- 需要解释时只解释“为什么这样改能解决问题”，不做长科普
### 5) 控制长链路与 Max
- 不主动建议开启 Max 模式
- 只有在“必须引入超大上下文/跨大量文件改动”时才建议 Max
- 若开启 Max，必须先给出“裁剪后上下文清单”，并说明预期收益
## 可直接复制的提问模板（给用户）
### Bug 修复（最省 token）
```
目标：修复 <一句话>。
环境：OS=<>, Python/Node/…=<>, 关键依赖版本=<可选>。
复现：运行命令：<一行>。
报错：只贴首尾关键 20 行（含异常类型与文件/行号）。
相关代码：<file_path>#Lx-Ly（或粘贴 40–120 行）。
限制：不要复述背景；只给最小补丁 + 1 句原因。
```
### 重构/批量修改（最省 token）
```
目标：把 <规则> 应用到 <范围>。
范围：仅限这些目录：<dir1, dir2>；不要扫全仓库。
约束：保持行为不变；只改必要文件；输出 unified diff。
验证：跑 <命令>，失败就只贴失败摘要与相关片段。
```
## 上下文裁剪清单（给用户）
- 只贴“错误类型 + 出错文件/行号 + 关键变量值”
- 栈追踪保留第一段与最后一段，删除中间重复
- 日志按时间窗口截取：错误前 5–20 行 + 错误后 5–20 行
- 数据样例最多 5 行；其余转为“统计摘要”（行数、列名、缺失比例）