说实话我一开始看到这个说法的时候第一反应是“又是什么玄学技巧”。但我自己最近在整理一个长文档、反复跟 AI 来回改格式的时候顺手试了一下“我有多动症你回复别写太多废话”结果那次会话的 Tokens 肉眼可见地降下来了。这个技巧本身其实不玄它背后就是很朴素的 prompt 工程你给模型一个“人设约束”它就会主动改变输出习惯把客套话、重复解释、结构化总结这些“费 token 的废话”砍掉一部分。对普通用户来说最直接的好处是同样的上下文能多聊几轮上下文窗口没那么快爆对拿 API 做应用的开发者来说这就是实打实地降低成本。这篇就把这个玩法的原理、实测数据、可抄的 prompt 模板以及在 API 调用里怎么落地讲清楚。不管你是天天跟 ChatGPT、Claude 这类产品聊天的人还是自己在做 AI 应用开发后面几节都有可以直接用的东西。1. 先算账一句“多动症”到底能省多少 Tokens1.1 一次对话的 Tokens 都花在哪了很多人在意 Tokens但搞不清楚一次对话到底哪里在烧钱。实际上任何一次大模型对话的计费基本可以拆成三部分输入部分你发给模型的 system prompt、历史对话消息、当前的问题这些都要按 Tokens 计费。输出部分模型生成的回复内容同样按 Tokens 计费而且很多模型的输出单价高于输入单价。上下文累积每一轮新请求都会把前面的历史消息重新发送一次所以对话越长每一轮的实际消耗就越大。这里有个容易被忽视的点上下文累积消耗是按“轮次 × 历史消息长度”增长的。如果你的 AI 特别喜欢写冗长回复那么每多一轮历史里的“废话 Tokens”就会跟着一起重复计费。所以控制输出长度不只是省当前这一轮的钱而是给整个会话的后续轮次减负。1.2 我这边测出来的大概变化我当时做的测试很简单把一段大约 3000 字的项目资料交给 AI要求它整理成要点。第一轮用的是很普通的指令“请帮我整理这份资料的要点”。第二轮我加了一句“我有多动症阅读长文本很吃力请你用最短的句子直接给要点不要任何铺垫和总结。”同样是整理同一份资料两轮结果对比下来第一轮回复大约 1200 字里面包含“以下是整理结果”“这份资料主要介绍了……”这种明显的结构铺垫结尾还附带了一段“如果需要进一步分析可以随时告诉我”。第二轮回复大约 700 字开头直接是“关键点”然后列条目每条一句话结尾没有任何客套。按中文大约 1 个汉字对应 1 到 1.5 个 Token 估算不同分词器有差异这一轮输出端省下的 Tokens 大约在 30% 到 40%。如果只看那些特别爱“打官腔”的模型省下来的比例可能更高我见过输出长度直接砍半的情况。1.3 输出端才是“可压水分的重灾区”普通人最容易忽视的一点是输入 Tokens 基本都是你写的内容这部分的压缩空间很有限。真正的水分在输出端。大模型天生倾向于生成结构完整、逻辑自洽、有头有尾的回答这种倾向的代价就是“结构性废话”——开场白、过渡句、总结段、补充建议这些都是模型为了“显得完整”而输出的 Tokens。这些内容单个看起来不多但如果你在做一个长对话的 Agent或者用 API 批量处理文档输出端多出来的 30% 废话就等于纯成本。这也是为什么“人设约束 格式约束”这种手段在抠成本的人眼里是刚需而不是什么花活。2. 原理拆解为什么“有多动症”比“请你简短回答”更管用2.1 大模型本质上是一个“顺着指令圆场”的系统要理解这个技巧为什么有效得先放下一个直觉我们总以为大模型是在“理解”你的需求然后“决定”怎么回答。实际上大模型更接近一个根据输入内容预测下一个词的概率系统。你给它的指令本质上是给它创设了一个“对话场景”和“人物设定”它会基于这个设定去生成最合理的回答。所以当你只说“请简短回答”时模型得到的是一个很模糊的偏好。它可能会把回复缩短那么一点但仍然会保留“好的我明白了”这类客套话因为它觉得一个礼貌的助手就该这么说话。但你加上“我有多动症”这个设定后模型的“人设”就变了它面对的是一个无法阅读冗长文本的用户那么它认为“合理”的回答就应该是极度精简、去掉所有非必要信息的格式。2.2 具象人设比抽象指令更能约束输出风格这里面的差别本质上就是“抽象形容词”和“具象场景”的差别。抽象要求请简短回答。具象要求我有注意力缺陷请用电报体回复每句话不要超过 20 个字不要任何客套话。“简短”这个词在不同模型、不同上下文里的理解差异很大。但“每句话不要超过 20 个字”“不要客套话”“直接给结论”这些约束定义边界要清晰得多。“我有多动症”这种具象人设则相当于把“为什么需要简短”这个理由一并给了模型它模仿这种口吻时的贴合度明显更高。这不是我瞎说你可以做个对照实验。同一个问题分别用“请简短回答”和“我有多动症请简短回答”问同一款模型比较两轮回复的 Tokens 消耗。我试过多次绝大多数情况下第二种说法的输出长度都会更短而且信息密度更高。2.3 替代人设如果不想提“多动症”可以用什么有人可能会说我不想虚构自己有注意力问题那也没关系。这套技巧的核心方法是“通过人设或场景约束输出格式”表达方式可以随便换。下面这几个都是我实测有效的替代方案人设/场景约束效果侧重点适用场景我有多动症没法读长文砍掉客套话、过渡句强制短句信息整理、要点提取请用给 10 岁小孩讲课的口吻解释强制通俗化缩短从句和修饰语概念学习、科普、阅读基础你只剩 30 秒时间回答我制造急迫感模型会优先保核心信息快速决策、临场查询用“电报体”输出每句话不超过 15 字极强行文约束几乎不留废话空间摘要、日志、关键信息罗列直接给结论不许解释原因砍掉论证过程适合需要结论的场景判断题、数值查询、状态确认每个模型对不同场景的敏感度略有差别但总体规律是一致的越是“有画面感”的约束越能直接影响模型输出的概率分布。这比我天天念叨“你回复真啰嗦”有效得多。3. 实操落地从聊天框到 API 调用怎么把 Tokens 降下来3.1 普通用户这几条 Prompt 模板可以直接抄如果你只是日常使用 ChatGPT、Claude、Kimi 这类产品不需要任何技术基础只需要把下面这些模板复制过去根据情况改一改就行。第一类通用精简模板我有多动症读不了长文本。每次回复请控制在 150 字以内用短句直接给结论不要任何开场白、客套话和结束语。第二类列点强制模板我有注意力问题。回答时必须用列表每条不超过 15 个字最多 5 条。禁止出现“首先”“其次”“最后”这类连接词。第三类角色扮演模板适合场景解释假设我是个小学生你有 20 秒时间把这个问题讲清楚。不要用术语不要用长句直接说最核心的因果关系。这三个模板的效果差异在于第一类侧重长度控制第二类侧重格式控制第三类侧重通俗化控制。实际使用中你可以把“我有多动症”替换成任何符合你习惯的人设然后把控制要求加在后面。注意这个技巧要放在一次新会话的开头或者作为对话里的一条消息发出去之后模型会倾向于在这个人设下继续对话。3.2 开发者把约束写进 System Prompt并配合参数如果你在用 OpenAI、Claude、DeepSeek 或其他模型提供商的 API那这个思路可以做得更系统化。关键是不要只依赖对话里的随机发挥而是把“输出控制”写进 System Prompt并跟 API 参数里的 max_tokens、temperature 配合使用。下面是一个用 Python 伪代码表达的消息结构示例messages [ { role: system, content: ( 你是一个给用户压缩信息的助手。 用户有注意力缺陷无法阅读长文本。 你的输出必须符合以下规则 1. 每条回复不超过 150 字 2. 优先使用列表或短句 3. 禁止出现‘好的’‘当然’‘以下是’‘如果你需要’等客套话 4. 核心结论必须出现在回复前两行。 ), }, { role: user, content: 请把下面的资料压缩成要点..., }, ]这样写的好处是每次调用 API 时模型都会在系统层面接收到这套“人设 格式约束”不会因为对话太长而逐渐跑偏。然后看参数层面max_tokens如果你的业务场景不需要长回答可以把 max_tokens 设成一个合理的上限比如 300。这能避免模型偶尔“抽风”输出一大段内容。temperature把它调低一点比如 0.2 到 0.4模型在输出时会更保守不容易因为发散而增加额外内容。上下文裁剪如果你做的是多轮应用历史消息不要无限制堆积。超过一定轮次就该做摘要压缩否则 Tokens 消耗是指数级上涨的。3.3 不同模型的“听话”程度不一样我在几个主流模型上试过这套组合拳效果从好到差的顺序大致是Claude 系列对“人设约束”的跟随度最高GPT 系列和 DeepSeek、Kimi 这类模型也都能明显缩短输出只是偶尔需要你把约束说得更硬一点比如明确加一句“如果违反规则用户会流失”。有个细节值得提醒把约束写在 System Prompt 里效果要远好于写在用户消息末尾。因为 System Prompt 的优先级和对模型行为的影响权重更高。如果你只在某一轮聊天里随口说“请简短回答”模型大概率会在下一轮又恢复长篇大论。3.4 一个容易忽略的边界别把“人设”用在严肃场景上这套技巧的本质是角色扮演式 prompt而不是真的让 AI 给你做医疗判断。所以有两个注意事项不要真的在正规客服、法务、医疗咨询这些严肃场景里为了“省 Tokens”编造自己有注意力障碍。这种场景下信息的准确性远比 Tokens 重要你应该优先使用语义精准的指令而不是人设压长度。也不要用“有多动症”这个说法去诱导模型给出它本来不该给的内容。它只是一个输出长度控制工具跟其他格式约束没有本质区别。说白了这是一项“文本格式控制技术”跟健康话题无关也不该被用来获取任何特殊服务。你在自己产品里使用类似思路时建议直接用“输出字数限制”这种中性表述一样能达到效果还能避免不必要的误解。4. 哪些场景最适合这套技巧按 Tokens 消耗量排序4.1 长文档压缩和资料整理最值得用这是 Tokens 消耗最大的场景之一。你丢一篇几千字的文档进去如果不做约束模型会习惯性地给你生成一段“引言 主体分析 总结建议”每一个环节都在消耗 Tokens。而且这种整理类任务模型特别喜欢在结尾补一句“希望这些信息能帮到你”之类的废话。用上“多动症约束”之后最常见的现象是开头没有“以下是”结尾没有“希望”中间没有“首先其次最后”信息密度翻倍。我处理项目周报、合同摘要、论文阅读笔记时长期使用这类约束每次会话能明显感觉到上下文窗口空出来很多。4.2 Agent 多轮工具调用省的是“循环次数”的钱如果你在做 Agent 应用比如一个会调用搜索、读网页、写文件的多步任务工作流那输出长度的影响会被放大。每轮工具调用之后Agent 都要把历史记录重新发一次给模型历史越长后面每一轮的输入 Tokens 就越高。这种情况下就算每一轮输出只省 200 个 Tokens经过 10 轮工具调用省下的总量就是 2000 个 Tokens 的“基础费”加上多次重复计费的“放大效应”。对于那些做 AI Agent、AI 编程辅助、自动化工作流的人来说输出控制不只是一个省钱技巧更是提高任务成功率的手段——上下文一旦被废话塞满模型反而容易丢失关键信息。4.3 代码辅助和日志分析格式约束价值最高代码场景里“多动症约束”也一样有效但侧重点要调整。你不需要让 AI 把回复压到 150 字以内而是要约束它“不要解释只输出代码”“报错信息只给关键行”。这种约束能有效避免 AI 在代码答案前面写一大段“这个问题的原因可能是……”或者在你只想要一行命令时给出一整个教程。这里有个具体建议代码场景下把“不要解释”写进 System Prompt 的优先级设置里比你说一百句“简短一点”都管用。因为在代码辅助模型的对齐训练里“解释清楚”的权重很高你需要用一个更强的指令去覆盖它。5. 我踩过的坑关于省 Tokens 的几条避坑经验5.1 模型“假装答应但行为不变”怎么办有时候你设定了人设模型嘴上说“明白我会注意简短”然后照样给你输出一大段。这多半是因为你的约束不够具体。只写“请简短回答”这类模糊要求模型很容易忽略但如果你写了“回复不得超过 150 字每条列表项不得超过 15 字”模型的格式约束响应会好很多。解决办法把长度、格式、禁止项全部量化。不是“别啰嗦”而是“每个要点一句话最多 5 条总字数不超过 150”。越接近一个可以校验的格式规则模型就越容易执行这对不同模型几乎都有效。5.2 输出太短导致信息丢失控制输出长度有一个副作用如果压得过狠模型可能为了满足字数限制而丢关键信息。比如你让它压缩一份合同它可能把责任条款给省了。这种场景下我会在约束后面加一句“只保留最核心的事实和数字不要省略具体日期、金额、责任人”。这个补充非常重要。因为 Tokens 省下来的前提是“该有的信息还在”而不是变成一段没有营养的口号。尤其在法律、财务、技术方案这种场景宁可稍微多花一点 Tokens也不能让关键信息被“剪切掉”。5.3 历史消息会把你的约束“冲淡”很多人设约束只在当前这条消息里生效到了第 5 轮、第 10 轮对话模型会越来越像最初的默认状态回复又开始长篇大论。这是因为上下文里的历史消息对冲了 System Prompt 的控制力模型越往后越倾向于“跟随对话惯性”。解决办法并不复杂每隔几轮对话重新强调一次约束。最好的位置是在一条新用户消息的开头加一句“记住回复保持简短不要客套”。开发者则可以在代码里设计一个“约束注入”机制定期把 System Prompt 的关键规则重新拼接进新一轮请求。5.4 不同的模型敏感度差异很大最后分享一个直接实测结论人设类约束对输出长度的控制力在不同厂商模型上的排序基本是 Claude 最强GPT 系列次之部分轻量级模型和开源模型最弱。这跟模型的对齐训练方式有关有的模型更优先“取悦用户”有的模型更优先“保持完整表达”。如果你用的是开源模型或者国产 API效果不理想时不要硬刚同一个 prompt可以换个思路在参数层面把 max_tokens 卡死同时把 temperature 调低。这种“物理限制”比任何 prompt 都可靠。毕竟输出上限是你自己控制的模型再能写也绕不过这个硬顶。我自己现在的习惯是只要是偏重“信息提取”“要点整理”的对话一律开启“多动症人设 格式约束 max_tokens 上限”三件套只有在需要模型写文案、做头脑风暴、生成创意内容时才会把这些约束关掉让它自由发挥。最后再分享一个小技巧如果你发现自己写的 System Prompt 本身就特别长——注意这也会占用 Tokens——你可以用同样的思路去压缩它。把你那版“长篇大论的 System Prompt”丢给模型告诉它“我有注意力缺陷请你把这套规则压缩成 100 字以内的指令”得到的结果可能比你手写的更精炼。等压缩完再审视一遍保留真正影响行为的句子你可能会发现原来有 30% 的规则描述是模型根本不会执行的水分。这就是一种“拿魔法打败魔法”的省钱法。