示例：修复损坏构建的修复任务
场景
用户：“我的 Vercel 部署失败了。构建错误：找不到模块 ‘@/components/ProposalResult’”
这是一个针对性修复——最少代理、最少配额。
任务简报
任务简报 ───────────────────────────────────────── 目标：修复导致 Vercel 构建失败的损坏导入。不要碰任何其他东西。 代理总数：1 配额策略：仅 FLASH 预计 Token 成本：低 代理： [1] ID: repair-001 角色：修复代理 范围：仅包含损坏导入的文件 + 缺失的文件（如果需要创建） 模型：Gemini Flash 输入：确切的错误消息、导入的文件路径 输出：修复后的导入或创建的缺失文件——仅此而已 依赖：无 ─────────────────────────────────────────修复协议
第 1 步：读取确切的错误——不要假设上下文 错误："Cannot find module '@/components/ProposalResult'" 第 2 步：检查文件是否存在 → 如果存在：修复导入路径（大小写问题、错误的别名等） → 如果缺失：创建最小可用文件（即使只是带正确导出的空文件） 第 3 步：在心中验证修复能编译 → 检查所有导入同一模块的其他文件 → 确认 tsconfig.json 的路径别名正确 第 4 步：报告改了什么以及为什么——每条一句话修复任务中不要做的事
- 不要为了"理解上下文"而重读整个代码库
- 不要顺手重构相邻文件
- 不要"为了保险"切换到更强大的模型
- 不要打开浏览器代理去查看 Vercel 控制台
- 不要为单个损坏的导入生成额外代理
配额日志
| 事件 | 影响 |
|---|---|
| 1 个 Flash 代理 | 低 |
| 读取 2–3 个文件 | 低 |
| 写入 1–2 个文件 | 低 |
| 预计总计 | < 5% 冲刺配额 |
修复任务几乎绝不应超过 10% 的冲刺配额。
如果修复变得复杂，停下来——把它作为新的完整任务来分解。
