一、核心原则

  1. Web = 长对话、探索、低精度
  2. Cursor = 工程修改、短指令、高相关
  3. API = 高价值推理、最终产出

token 不是平均分配，而是按“价值密度”分配

二、三栈分工总览表

场景 首选栈 为什么
想法探索 / 头脑风暴 Web 上下文裁剪激进，free 容错高
技术方案对比 Web → API Web 粗筛，API 精推
代码重构 / 修 bug Cursor repo-aware，token 内部消化
多文件一致性修改 Cursor Diff 而非全文
制度 / 标准 / 报告 API 可控、可复现
最终交付文本 API 稳定、低返工
反复微调 ❌ Cursor token 黑洞
长推理 + 输出 ❌ Web 不可控

三、具体执行流程

1️⃣ Web：只做“模糊阶段”

用 Web 做什么

  • 判断值不值得做
  • 明确问题边界
  • 得到 2–3 个可行方向

禁忌

  • ❌ 长代码
  • ❌ 完整文档
  • ❌ 精确结论

Web 的角色是：“低成本顾问”

2️⃣ Cursor：只干“工程内的事”

Cursor 最优使用姿势

- Scope: only files A/B/C
- Goal: X → Y
- Output: unified diff
- Do not refactor unrelated code

强制习惯（省 token）

  • 不让 Cursor 自由扩展 scope
  • 不连续追问
  • 失败直接改 prompt

Cursor = “带上下文的 diff 生成器”

3️⃣ API：只留给“不可替代的判断”

API 适合的任务

  • 架构决策
  • 风险分析
  • 报告定稿
  • 技术路线选择

API Prompt 结构（固定模板）

Input:
- Facts:
- Constraints:
- Options:

Task:
- Choose / Evaluate / Decide

Output:
- Conclusion
- Reasoning (short)
- Risks

👉 预期效果：

  • token 用得慢
  • 结果可复用
  • 几乎不用返工

四、省 token 流水线

以 制度 / 技术方案 为例：

Step 1｜Web
“这类制度修订常见争议点是什么？”

Step 2｜本地 / fast 模型
→ 压缩成 10 条 bullet

Step 3｜API
“在以下约束下，给出最稳妥修订方案”

Step 4｜API
“按正式报送口径润色，不新增事实”

📉 token 消耗： ≈ 直接丢全文的 20%–30%

五、什么时候“三栈失衡”了

出现以下情况，说明正在浪费 token：

  • Cursor 对同一问题修改 ≥ 3 次
  • Web 对话超过 30 轮
  • API 在帮你“读材料”

修正方法只有一个：

往前移一层

结合你长期做的事（制度、平台、工程、决策）：

  • Web：30% 使用
  • Cursor：50% 使用
  • API：20% 使用

AI 不是一个入口，而是一个流水线。