用 WorkBuddy 做长期项目(不是一次性问答)时,积分不是"用得快",而是被三种隐性开销吃掉的:重复开工、重复自证、重复测量。真实开发只占其中一小部分。下面这套办法来自连续几周、几十个卡(任务)的实操收敛,按"最省→次省"排序。
把一次对话轮次拆开,成本大致是:
类型 | 典型开销 | 是否必要 |
|---|---|---|
开工自证("我理解的任务是…我准备这样做…") | 每轮固定成本 | 大部分不必要 |
重复跑同一条测试 | 一次几分钟,还要读日志 | 常常不必要 |
长篇解释与自我复盘 | 输出越长越贵 | 大部分不必要 |
子代理并行拆任务 | 每个子代理一份独立消耗 | 多数场景不必要 |
挂起→重启→重来 | 最贵,且经常白干 | 完全可以避免 |
真实写代码 + 真实验收 | 必要成本 | 必要 |
结论很清楚:把"流程开销"压到接近零,代码本身的开销就降下来了。
拆成五张小卡的活儿,等于五次开工、五次自证、五次收尾。合并成一张卡、一次交付,固定开销只付一次。
反面案例:为了让进度看起来"细",把一个模块拆成"接口→实现→联调→自测→报告"五张卡,结果光自证和收尾就花掉一半额度。
每一轮纠偏,都要它重新理解、重新说明、重新开始。把验收判据(指标名、阈值、轮次、采样方式、环境门槛、禁止项)一次性写进任务卡,后面就只剩执行。
最容易出事的两种纠偏:
要求它每轮只写一行:本轮任务=<卡号> 依据=<指令编号>。这一行同时起到两个作用:证明它没跑偏、成本几乎为零。
历史结论不要靠聊天上下文传递,落成文件:验收结论、基线状态、信箱(异步指令文件)。下一轮只说"读这个文件",比把三千字贴进对话便宜一个数量级,而且不会因为上下文被截断而失真。
配套做法:让它把验证写成可重复执行的脚本(一条命令出结论),而不是每次重新组织测试流程。脚本跑一百次几乎不额外花钱,重新组织流程每次都要花钱。
它自测三轮、你复核三轮,等于六轮。正确分工:它交一次原值 + 证据文件,你独立复核一次。判据只认你自己跑出来的数,这一点同时也解决了"它自报达标"的信任问题。
并行子代理看起来快,实际是"N 份上下文 + N 份自证"。一个中等规模的模块,单线程做完往往比并行便宜。真正需要并行的场景只有:互不依赖、且都能一次成型的两三块。
真实踩坑:让它"并行交给两个子代理产出两份脚本",结果两个子代理都先读了一遍项目结构,光预热就烧掉一大截,产出还没人合并。
最常见的大额浪费:窗口安静 → 以为卡住 → 重启 → 它重新读一遍项目 → 从头再来。一次这种循环能顶十次正常迭代。
判活四件套(都低成本):
四项都静默再谈处置,不要一安静就重启。
叫醒只需一句"继续,从 X 处接续"。贴一整段需求过去,它会重新规划一遍,等于重新开工。
另外:定时唤醒频率要收敛。分钟级的靠系统计划任务,小时级的靠平台定时,别开着好几层轮询互相叠加。
把报告格式固定成三块:
不要"心得体会""后续展望""风险提示"这类段落——它们不加分,只花钱。需要复盘时,单独开一小段"长期口径",一次写清,后面每张卡引用,不重复解释。
开工前问自己五句:
交付后问自己三句:
省积分的本质不是少让它干活,而是别让它重复理解同一件事、别让它重复证明同一件事、别让它重复测量同一件事。把这三件事各压到一次,额度就能撑住一个长项目。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。