面向日常开发场景的实用手册。目标是：更快得到正确结果，同时减少不必要的 token 消耗。

---

目录

1. 先理解 Token 花在哪里
2. 提问方式：越具体，越省钱
3. 上下文管理：只给必要信息
4. 选对模式：Agent / Ask / Plan / Debug
5. 用 Rules 和 Skills 减少重复解释
6. 代码任务的高效写法
7. 审查与调试：避免无效往返
8. 省 Token 的 20 条实操清单
9. 常见浪费 Token 的反例
10. 推荐工作流模板

---

1. 先理解 Token 花在哪里

每次对话，token 主要来自：

来源	说明	是否可控
你的输入	问题、粘贴的代码、日志	✅ 高
自动附加上下文	当前打开文件、光标位置、项目结构	✅ 中
AI 读取的文件	Agent 主动 Read / Grep 搜索的内容	✅ 中
AI 回复	解释、代码、工具调用结果	⚠️ 部分可控
历史对话	多轮聊天会累积进上下文	✅ 高
Rules / Skills	用户规则、项目规则自动注入	✅ 高

核心原则：

Token 不是“字数”，而是“进入模型的全部文本”。
减少无关上下文 + 减少无效轮次 = 最省钱的办法。

---

2. 提问方式：越具体，越省钱

❌ 低效提问（贵、慢、容易跑偏）

帮我看看这个项目
这个 bug 怎么修？
优化一下代码

✅ 高效提问（便宜、快、一次到位）

在 `assemble_tcam_926_2748.py` 里，函数 `build_tcam()` 在处理 index=2748 时
返回空列表。期望是返回 64 项。请定位原因并只改必要代码。

约束：
- 不要重构无关模块
- 不要新增测试文件
- 改完后说明根因

好问题的 5 要素

1. 目标：要做什么（修 bug / 加功能 / 解释逻辑）
2. 范围：哪个文件、哪个函数、哪段逻辑
3. 现象：现在发生什么（报错、日志、错误输出）
4. 期望：正确结果应该是什么
5. 约束：不要动什么、用什么风格、是否允许改多个文件

---

3. 上下文管理：只给必要信息

3.1 用 @ 精确引用，而不是整库搜索

方式	适用场景	Token 成本
@文件名	已知目标文件	低
@文件夹/	限定搜索范围	中
@Codebase	不知道在哪，需要全局找	高
粘贴 500 行日志	大多无关	很高

建议：

• 已知文件 → 直接 @file
• 已知模块 → @folder
• 只有“不知道在哪”时才用 @Codebase

3.2 不要一次性打开/引用过多文件

Cursor 会把当前打开的文件作为上下文。开发时：

• 只保留与当前任务相关的 1～3 个文件
• 无关的大文件、生成物、日志先关掉

3.3 日志和报错：给“关键片段”，不是全文

推荐格式：

报错：
  File "assemble_tcam_926_2748.py", line 142, in build_tcam
    assert len(result) == 64
  AssertionError

相关输入：
  index = 2748
  mode = "rerun"

我已确认：
  - index < 3000 时正常
  - 只有 2748 失败

比粘贴 2000 行 log 便宜一个数量级。

3.4 长对话要“开新会话”

当话题已经切换（例如从 MBIST 脚本切到完全另一个模块）：

• 开新 Chat，不要在一个线程里堆 50 轮历史
• 新会话用 3～5 句话总结前情即可

---

4. 选对模式：Agent / Ask / Plan / Debug

模式	用途	Token 特点
Ask	只问不改代码、读代码、解释逻辑	最省（无工具写文件）
Plan	大改动前先设计方案	中等，但能避免错误实现
Agent	直接改代码、跑命令、修 CI	较高，但一轮完成往往更省
Debug	有明确 bug，需要系统性排查	中等，依赖你是否给足线索

选用建议

只是问“这段代码干什么”        → Ask
要改 1 个文件、逻辑清楚         → Agent（附文件 + 约束）
要重构/架构调整/多种方案        → 先 Plan，再 Agent
报错明确、有堆栈               → Agent 或 Debug

常见误区：
为了“省 token”强行用 Ask，结果你自己改半天；实际上 Agent 一次改对 往往更便宜。

---

5. 用 Rules 和 Skills 减少重复解释

如果你每次都重复说：

• “用中文回答”
• “不要自动 commit”
• “遵循我们项目的命名规范”
• “测试目录不要动”

应写进 Cursor Rules（.cursor/rules/ 或 User Rules），而不是每轮聊天重复。

Rules 适合放什么

• 语言偏好（中文/英文）
• 代码风格（缩进、命名、是否写注释）
• 安全边界（禁止 force push、禁止改某些目录）
• 项目约定（测试框架、分支策略）

Skills 适合放什么

• 重复性流程（创建 PR、跑某套测试、查 Jira）
• 团队标准操作手册

收益： 规则只注入一次，后续每轮不用你重复打字。

---

6. 代码任务的高效写法

6.1 小改动：一次说清

在 `assemble_tcam_926_2748.py` 第 120-150 行：
把硬编码的 64 改成从参数 `width` 读取。
不要改其他函数。

6.2 大任务：拆成可验收的小步

第 1 步：只分析 `build_tcam()` 为何 index=2748 失败，不要改代码。
第 2 步：给出最小修复 diff。
第 3 步：我确认后再跑相关脚本验证。

拆步的好处：

• 每步上下文更小
• 减少“改错方向后全部推翻”的浪费

6.3 明确“不要做”的事（很重要）

要求：
- 只改 assemble_tcam_926_2748.py
- 不要新增 markdown 文档
- 不要重构无关函数
- 不要提交 git

这会显著减少 AI 的“过度发挥”。

6.4 引用代码用行号

如果你已知位置，直接说：

请看 assemble_tcam_926_2748.py:120-150

比让 AI 全文件搜索更省 token、更快。

---

7. 审查与调试：避免无效往返

7.1 Code Review 请求

低效：

review 一下我的改动

高效：

请 review 我未提交的改动，重点关注：
1. index 边界处理是否正确
2. 是否有 off-by-one
3. 是否引入性能回退

不需要风格吹毛求疵，不要建议大规模重构。

7.2 Debug 请求

把下面 4 项一次给出：

1. 复现步骤（1-2-3）
2. 实际结果
3. 期望结果
4. 你已经排除的可能性

复现：python assemble_tcam_926_2748.py --index 2748
实际：输出 list 长度 0
期望：长度 64
已排除：输入文件存在且非空；index=2747 正常

---

8. 省 Token 的 20 条实操清单

1. 问题写清楚：目标 + 范围 + 现象 + 期望 + 约束
2. 用 @文件 代替 @Codebase（能定位时）
3. 关闭无关打开文件
4. 日志只贴关键 20～50 行
5. 长对话换新 Chat
6. 静态问题用 Ask，改代码用 Agent
7. 大改动先 Plan，避免返工
8. 重复偏好写进 Rules，不重复打字
9. 说清“不要做什么”
10. 大任务拆成可验收小步
11. 已知行号就直接给行号
12. 不要粘贴整文件，除非必要
13. 不要让 AI 读二进制/生成物/巨大 tarball
14. 一次只做一个主题（不要一条消息里塞 5 个无关需求）
15. 确认后再要“详细解释”（解释也耗 token）
16. 修复后说“已通过，不用解释”可省回复
17. CI 失败时贴失败 job 名 + 关键错误段
18. 用项目内已有函数，而不是让 AI 重写一套
19. review 时限定关注点，避免泛泛而谈
20. 团队共用的流程做成 Skill/Rule

---

9. 常见浪费 Token 的反例

反例	为什么浪费	替代做法
“帮我理解整个仓库”	触发大量文件读取	指定模块/目录
粘贴 1 万行 log	90% 无关	提取错误前后 30 行
同一问题反复问 10 轮	历史上下文膨胀	合并信息，开新会话
不说约束	AI 过度修改	明确 scope 和禁止项
每轮都重复项目背景	重复输入	写到 Rules
既要详细教程又要立刻改代码	回复变长	分两步请求
让 AI 扫描 .tar.gz / 巨大 .v 全文件	读取成本高	指定函数/行范围
“你觉得怎么最好”	方案发散	先给选项 A/B 让你选

---

10. 推荐工作流模板

模板 A：快速修 Bug

【目标】修复 xxx 报错
【文件】@path/to/file.py
【现象】<报错 5-10 行>
【期望】<正确行为>
【约束】最小改动；不改测试；不 commit

模板 B：新增小功能

【目标】在 X 中增加 Y 能力
【位置】@path/to/module
【接口】函数签名建议：...
【约束】复用现有 Z；不加新依赖；补 1 个单测即可

模板 C：代码理解（Ask 模式）

【问题】build_tcam() 的 index 边界逻辑是什么？
【范围】@assemble_tcam_926_2748.py
【输出】用中文，300 字内，附关键函数调用链

模板 D：大改动（先 Plan）

【目标】把硬编码配置改成 YAML 驱动
【范围】仅 tmm2_mbist_scan 目录
【要求】先给 2 套方案对比（改动量、风险、回滚方式），不要直接写代码

模板 E：CI 失败排查

【失败任务】unit-test / lint / build
【错误摘要】<关键报错>
【最近改动】<相关 commit 或文件>
【请求】定位根因 + 最小修复，不要重构