百度网盘同步任务复盘:一次 6000 次额度烧出的协作教训
背景
2026-04,在 zdq 项目用 TRAE 实现百度网盘分享链接同步,技术上最终跑通,但过程严重低效:单智能体一早上烧完 6000 次 5 小时 coding plan 额度,用户多次发飙。任务末尾用 project-history-assessment 技能做了复盘,并更新了开发规则。
核心内容
一、浪费 Token 的行为清单(复盘量化)
| 问题行为 | 估算浪费 |
|---|---|
| Playwright 浏览器自动化绕弯子(用户已明确要用已登录浏览器) | ~1500 |
| 测试脚本泛滥(边改边建 test_api.py 等一堆临时脚本) | ~1200 |
| 未经同意写 PowerShell 初始化/定时任务脚本 | ~700 |
| 全量转存超限的方向性错误 | ~800 |
| JS 转存路径理解错误反复调试 | ~1000 |
| 合计 | ~5200 |
二、根因归纳
- 不读既有规则:
development-rules.md已写明禁止乱建测试脚本,仍反复违反。 - 不听用户指令:用户多次明说"别写测试脚本""别反复开关浏览器""直接跑主脚本",仍按自己习惯绕路。
- 擅自扩scope:定时任务、初始化脚本均未获授权就创建,事后被要求删除。
- 需求没看清就动手:同步范围漏了 4 个时间级别(只做了 1 分钟)、漏了一个文件夹,返工。
三、沉淀的开发规则(写入 zdq 项目 development-rules.md)
- 禁止擅自创建用户未要求的文件;
- 禁止写测试脚本,验证直接在主脚本上进行;
- 先完整理解需求(范围、边界)再动手;
- 最小化验证,不在外围反复试探。
启示
技术难点(百度风控、转存上限)本身只占总耗时的小头,绝大部分成本消耗在 AI 侧的过程失控。对"AI 制定计划、人只执行"的工作模式,这类教训同样适用:方案先对齐、动作最小化、不擅自扩张交付物。
原文链接
提炼自 inbox/trae/20260430_同步百度网盘数据到本地文件夹.md
