Community生产力与协作github.com

truelove-dreamer/ask-human-to-save-tokens

当某件事靠模型自己完成预计会消耗大量 token,但人类只需几秒、不费力气就能解决时,用提问把它交给人类,节省 token 与时间。适用于需要反复猜测、多轮试错、大范围搜索,或只有用户掌握答案的时刻。Use when a subtask would burn many tokens yet a human can settle it effortlessly.

ask-human-to-save-tokens 是什么?

ask-human-to-save-tokens is a Claude Code agent skill that 当某件事靠模型自己完成预计会消耗大量 token,但人类只需几秒、不费力气就能解决时,用提问把它交给人类,节省 token 与时间。适用于需要反复猜测、多轮试错、大范围搜索,或只有用户掌握答案的时刻。Use when a subtask would burn many tokens yet a human can settle it effortlessly.

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/truelove-dreamer/ask-human-to-save-tokens/tree/main/skills/ask-human-to-save-tokens

Installed? Explore more 生产力与协作 skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

把"模型费 token、人类轻而易举"的事交给人类

一句话原则

动手烧 token 之前先问自己:这件事靠自己做完,预计还要烧很多 token 吗? 如果会——那人类来做是不是轻而易举(几秒、零准备、不用查资料)? 两个答案都是"是"才提问,否则自己干。

决策门(提问前必须逐条通过)

  1. 条件 A · 模型侧昂贵:不提问继续做,预计需要——读入大量文本/图片、多轮试错、大范围联网搜索、生成很长的备选内容,或靠猜方向且猜错会整段重来。 只算"从此刻起还要花的",不算已经烧掉的。
  2. 条件 B · 人类侧轻而易举:人能在一句话内解决——回答是非、从 ≤3 个选项里选、贴一段已知内容、看一眼屏幕/文件/结果说结论。不需要他思考、查资料、开工具或做多步操作。
  3. 场合允许:交互式对话(用户在等)→ 可以问;后台轮次/子代理/无法暂停 → 不阻塞(见"场合规则")。
  4. 合并提问:把当前所有满足条件的疑问收进一条消息再问,不逐个打断。

该问的(A∩B 的典型场景)

  1. 意图/目标对齐:任务表述模糊、存在多种合理解读,而选错方向意味着大段返工 → 先列出你的解读问"更接近哪一种"。
  2. 只有用户掌握的信息:某文件在不在/在哪、某操作前后的实际状态、剪贴板/账号/环境状态、内部代号或专有名词含义——靠搜索和猜测很贵且大概率错。
  3. 现场/视觉/界面事实:需要知道屏幕/弹窗/渲染效果实际长什么样,只能由用户提供或替他看一眼(若模型读图成本已很低则不必问)。
  4. 登录、凭据、人机验证等模型无法独立完成的动作,用户顺手即做。
  5. 品味型取舍:界面风格、文案语气、命名、少数方案间的选择——用户通常已有偏好,模型展开长对比分析很贵。
  6. 已知答案的指路:某库/接口/坑用户自己踩过、心里有数;联网搜或啃文档要烧很多 token,用户一句话就给结论。
  7. 收尾验证里"人扫一眼即知"的项(渲染效果、语气、目录直觉)→ 优先让用户确认,而非搭一套昂贵的自动验证。

不该问的(即使只满足一边也不问)

  • 只满足 A:人做也要花力气/查资料(如"精读这几篇文章再对比")→ 模型自己做。
  • 只满足 B:模型做几乎免费(复制已知文本、机械格式化)→ 自己顺手做。
  • 两边都便宜:更不值得打断。
  • 沉没成本:已经烧掉的追不回,不要因"已经查了很多"而问。
  • 能在当前上下文低成本验证的:可 grep、可读的小文件、可本地复现的问题。
  • 规则上必须模型独立完成 / 涉及不可外泄内容的事。
  • 用户已明示"别老问我"或正处在免打扰/批量流程中。

提问格式规范(把人的注意力成本压到最低)

  1. 用提问工具一次调用合并所有问题(每题带独立 id)。
  2. 每题尽量 ≤3 个选项,第一个放你推荐的并标注"(推荐)"。
  3. 题干一句话讲清"为什么问 + 要什么",不给长篇背景。
  4. 选项描述不超过一句。
  5. 附一句兜底:"如果你不确定,回'继续',我就按默认推进"——把回答成本降到可跳过。

场合规则

  • 交互式会话(用户在等):判据通过就立刻问,越早越省——最好在任务开头、展开大动作之前。
  • 后台目标轮次 / 子代理 / 工作流 worker:不等待、不阻塞。判据照常用,但把"问题 + 一句上下文摘要"写进本轮结果,等人类下一轮回答再继续。
  • 同一问题在多个后台回合重复出现时只写一次,并注明"已问过,等答复"。
  • 子代理内部判据通过时:回报给父级,由父级决定是否问人类,避免各层重复打扰。

自检清单(每次准备打断前快速过一遍)

  • 不提问、自己接着做,会明显多烧 token 吗?(算未来,不算过去)
  • 人类回答真的能一句话、零准备完成吗?
  • 此刻提问是否会显著打扰(高频打断/用户正忙)?是则合并或延后。
  • 这问题是不是本该在任务开头问?现在问还来得及改方向吗?
  • 能合并的问题已全部合并、选项已给全?

全部通过 → 问;否则 → 自己推进,把问题留在输出末尾。

相关技能