1. 一个反直觉的发现：给 AI 加人设反而更省 Tokens
第一次听到“跟 AI 说自己有多动症，竟然能节省 Tokens”这个说法，我的反应和大多数人一样——这不是段子吗？多动症意味着注意力涣散、思维跳跃、表达啰嗦，怎么可能跟“节省”扯上关系？但真正在 Cursor、ZCode 这类 AI 编程工具里反复折腾过几轮之后，我发现这个说法背后藏着一个非常实在的工程逻辑：你不是在给 AI 加病，你是在给 AI 加约束。
先把结论摆出来：这里的“多动症”不是医学意义上的诊断，而是一种提示词（Prompt）策略的拟人化说法。它的核心是让 AI 在回答时保持“短、碎、跳、直给”的风格——不要长篇大论的铺垫，不要礼貌性的寒暄，不要“首先、其次、最后”的八股结构，直接给结论、给代码、给下一步动作。这种风格恰好命中了当前主流 AI 编程工具（Cursor、ZCode、各类 Agent Skill 插件）的 Token 消耗机制：输出 Token 往往比输入 Token 更贵，而啰嗦的输出是 Token 浪费的重灾区。
这篇文章适合三类人看：一是每天在 Cursor 里跟 AI 结对编程、月底看着额度心疼的开发者；二是刚开始接触 ZCode、Agent Skill 这类工具，搞不清楚 Token 到底花在哪的新手；三是想把这套方法迁移到自己工作流里的效率爱好者。我会把“为什么有效”“怎么落地”“踩过哪些坑”全部拆开讲，参数、步骤、对比数据都给到，你照着抄作业就行。
需要提前说明的是，下面提到的所有工具操作和参数，都是基于我在实际项目中的常见实践总结，不同版本的工具界面可能有差异，但底层逻辑是通用的。
2. 先搞懂 Tokens 到底是怎么被烧掉的
2.1 Token 不是字数，但和字数强相关
很多人以为 Token 就是“字数”，其实不准确。对于英文，1 个 Token 大约对应 4 个字符，也就是 0.75 个单词左右；对于中文，1 个汉字通常要占 1 到 2 个 Token，具体取决于分词器的实现。你在 Cursor 里敲一段 200 字的中文需求，可能就消耗了 300 到 400 个输入 Token。
关键在于，AI 的回复也是按 Token 计费的。你问一句“帮我写个排序函数”，AI 如果回你 800 字的解释加代码，那 800 字全部算输出 Token。而输出 Token 在绝大多数 API 定价里，单价是输入 Token 的 2 到 4 倍。这就意味着：让 AI 少说废话，比让你自己少打字更省钱。
我做过一个粗略的实测对比。同一个需求“用 Python 写一个带缓存的斐波那契函数”，在默认提示词下，AI 回复了大约 620 个 Token，包含原理讲解、代码、复杂度分析、使用示例。而在我加了“多动症式”约束提示词之后，回复压缩到了 180 个 Token 左右，只给了代码和一行关键注释。输出 Token 直接砍掉了 70%。如果按每天 50 次交互算，一个月下来省下的额度相当可观。
2.2 上下文累积才是隐形杀手
比单次输出更可怕的，是上下文窗口的累积消耗。在 Cursor、ZCode 这类工具里，AI 不是只看到你当前这一句话，它看到的是整个对话历史加上你打开的文件内容。你每多问一轮，之前的对话就多累积一次。如果 AI 之前的回复很啰嗦，那这些啰嗦内容会在后续每一轮请求里被重复计费。
举个例子：你第一轮问了个问题，AI 回了 600 Token 的长篇大论。第二轮你追问，这时候请求里包含了第一轮的 600 Token 历史。第三轮又包含前两轮的全部内容。啰嗦的回复不是花一次钱，而是花 N 次钱。这就是为什么“让 AI 说话简短”这件事的收益，会随着对话轮数增加而指数级放大。
理解了这一点，你就明白“多动症提示词”为什么有效了：它从源头上掐断了啰嗦输出的产生，让每一轮的历史都保持精简，从而在整个对话生命周期里持续省钱。
2.3 不同工具的 Token 计费差异
| 工具/场景 | 输入 Token 计费 | 输出 Token 计费 | 上下文累积 | 备注 |
|---|---|---|---|---|
| Cursor 内置对话 | 按请求计 | 按请求计 | 是 | 打开的文件也计入 |
| ZCode CLI | 按 API 计 | 按 API 计 | 是 | 可配置上下文裁剪 |
| 通用 Agent Skill | 按 API 计 | 按 API 计 | 视实现 | Skill 描述本身也占 Token |
| 网页版对话 | 通常免费 | 通常免费 | 是 | 但有长度上限 |
这张表想说明的是：只要涉及 API 计费，输出 Token 和上下文累积就是两个必须盯住的点。而“多动症提示词”恰好同时优化了这两者。
3. “多动症提示词”到底该怎么写
3.1 核心原则：短、碎、跳、直给
所谓“多动症风格”，翻译成提示词工程的语言，就是四条约束：
- 短：每句话不超过 20 个字，禁止长段落。
- 碎：用列表、短句、关键词，不用完整论述。
- 跳：跳过铺垫和过渡，直接给结论和代码。
- 直给：不要“我认为”“可能”“建议你考虑”，直接说“这样做”。
这四条约束的本质，是压缩 AI 的“表达自由度”。AI 默认的训练目标是“有帮助、有礼貌、解释清楚”，所以它会不自觉地展开、铺垫、总结。而你要做的，是用提示词把它的输出空间强行收窄。
3.2 一段可直接复制的提示词模板
下面这段是我在 Cursor 和 ZCode 里反复调优后固定下来的模板，你可以直接拿去用：
你现在的输出风格要求： 1. 每句话不超过20字。 2. 禁止使用“首先、其次、最后、总之、综上所述”。 3. 禁止解释你已经知道的东西，除非我明确问。 4. 代码优先，解释最多一行。 5. 不确定的地方直接说“不确定”，不要编。 6. 不要问我“是否需要进一步帮助”。 7. 回复总长度控制在150字以内，代码除外。这段提示词本身大约 120 个 Token，但它能在后续每一轮对话里帮你省下几百个 Token。这是一笔一次投入、长期回报的买卖。
3.3 为什么“多动症”这个说法比“请简短回答”更有效
你可能会问：我直接说“请简短回答”不行吗？实测下来，效果差很多。原因是**“简短”是一个模糊指令，AI 对它的执行力度很弱**。而“多动症”是一个具象的人设，它激活了 AI 对“注意力涣散、说话跳跃、不爱铺垫”这类行为的联想，执行力度明显更强。
这背后是提示词工程里的一个经典技巧：用具体人设替代抽象指令。你说“请专业一点”，AI 不知道什么叫专业；你说“你是一个有十年经验的急诊科医生，说话直接、不废话”，AI 立刻就懂了。同理，“多动症”比“简短”更具体、更有画面感，所以更管用。
注意：这里说的“多动症”纯粹是一种修辞手法，用于描述输出风格，不涉及任何医学判断。如果你觉得这个说法不舒服，完全可以换成“急性子程序员”“不耐烦的资深工程师”等人设，效果类似。
4. 在 Cursor 和 ZCode 里怎么落地
4.1 Cursor 里的配置位置
Cursor 的提示词配置分几个层级，优先级从高到低大致是：
- 单次对话输入框：临时指令，只对当前这轮有效。
- Rules for AI（规则）：在设置里配置，对整个项目生效。
- .cursorrules 文件：放在项目根目录，随项目走，团队可共享。
我的建议是：把“多动症提示词”写进 .cursorrules 文件。这样每个打开这个项目的人、每次对话都自动生效，不用反复粘贴。具体操作是在项目根目录新建.cursorrules文件，把上面那段模板粘进去，保存即可。
如果你只是想临时试一下，直接在对话开头粘贴模板也行，但记得每开一个新对话都要重新粘。
4.2 ZCode 里的 Skill 配置思路
ZCode 这类工具引入了 Skill（技能）的概念，你可以把一套提示词和行为逻辑打包成一个可复用的 Skill。这比每次手动粘贴提示词更优雅。
配置思路是这样的：新建一个 Skill，命名为“精简输出”或“急性子模式”，在 Skill 的描述里写清楚触发条件和输出约束。Skill 的描述本身也会占用 Token，所以描述要短，别写一大段。我一般控制在 50 字以内：
触发：任何代码相关请求。 行为：短句输出，代码优先，解释不超过一行，总长150字内。然后在需要的时候激活这个 Skill。ZCode 的 Skill 机制好处是可以按需开关，写文档的时候关掉，写代码的时候打开，灵活度比全局规则高。
4.3 一个完整的实操流程
假设你现在要在 Cursor 里写一个用户登录模块，完整流程是这样的：
- 在项目根目录创建
.cursorrules，粘贴精简提示词模板。 - 打开对话窗口，输入需求：“写一个 Flask 登录接口，带密码哈希。”
- AI 回复（预期）：直接给代码，加一行注释说明用了什么哈希算法。
- 如果 AI 还是啰嗦，追加一句：“再短点，只要代码。”
- 拿到代码后，如果需要解释，单独问：“解释第 3 行。”
这个流程的关键是把“要代码”和“要解释”拆成两次请求。因为解释性内容只在你需要的时候才产生 Token，不需要的时候一个字都不花。很多人习惯一次性问“写代码并解释”，结果解释部分你根本没看，Token 却已经烧掉了。
4.4 参数层面的微调
除了提示词，还有一些参数可以配合调整：
| 参数 | 建议值 | 理由 |
|---|---|---|
| 最大输出长度 | 500-800 Token | 防止 AI 突然长篇大论 |
| 温度（Temperature） | 0.2-0.4 | 降低随机性，输出更稳定精简 |
| 上下文裁剪 | 开启 | 自动丢弃过老的历史 |
| 流式输出 | 开启 | 方便你随时中断啰嗦回复 |
温度这个参数特别值得说一句。温度越高，AI 越“发散”，越容易展开论述；温度调低，AI 更倾向于给最直接、最保守的答案。写代码场景下，温度 0.2 到 0.4 是甜点区，既不会太死板，也不会太啰嗦。
5. 实测数据与效果对比
5.1 单次对话的 Token 对比
我用同一个需求做了 10 次对比测试，需求是“写一个 Python 函数，读取 CSV 并返回按某列排序的结果”。结果如下：
| 测试组 | 平均输出 Token | 平均输入 Token | 总 Token |
|---|---|---|---|
| 默认提示词 | 580 | 210 | 790 |
| 多动症提示词 | 165 | 330 | 495 |
| 节省比例 | 71.6% | -57%（因提示词本身） | 37.3% |
注意看输入 Token 那一栏：加了提示词之后，输入反而增加了，因为提示词本身要占 Token。但输出省下的量远大于输入增加的量，总账还是划算的。而且随着对话轮数增加，提示词只在第一轮占额外开销，后续轮次的收益会越来越大。
5.2 多轮对话的累积效果
更明显的差异出现在多轮对话里。我模拟了一个 8 轮的调试过程：
| 轮次 | 默认组累积 Token | 精简组累积 Token | 差距 |
|---|---|---|---|
| 第1轮 | 790 | 495 | 295 |
| 第3轮 | 3200 | 1400 | 1800 |
| 第5轮 | 6800 | 2400 | 4400 |
| 第8轮 | 12500 | 3800 | 8700 |
到第 8 轮，差距已经拉到了 8700 个 Token。这就是上下文累积的威力。默认组因为每轮都啰嗦，历史越滚越大；精简组每轮都短，历史增长缓慢。如果你每天有几十次这样的多轮对话，月底的额度差距会非常明显。
5.3 效果不只是省钱
省 Token 只是表面收益，实际用下来还有两个附加好处：
- 阅读负担降低：AI 回复短了，你扫一眼就能抓到重点，不用在废话里找代码。
- 决策速度加快：没有“你可以考虑 A 也可以考虑 B”这种模棱两可的话，AI 直接给一个方案，你快速验证，不行再问。
我个人的体会是，精简提示词带来的效率提升，比省下的 Token 更值钱。Token 是钱，注意力也是钱，而且更贵。
6. 常见问题与避坑指南
6.1 AI 还是啰嗦怎么办
这是最常见的问题。原因通常有三个：
- 提示词没生效：检查
.cursorrules是否在正确位置，或者 Skill 是否真的激活了。 - 提示词被后续指令覆盖：如果你在对话里又说了“详细解释一下”，AI 会优先执行最新指令。
- 模型本身风格顽固：某些模型对精简指令的服从度较低，可以尝试换模型或加大约束力度。
我的做法是在提示词里加一条“违反上述风格要求视为错误”，这句话能显著提升 AI 的服从度。听起来有点强硬，但实测有效。
6.2 精简过头导致代码质量下降
有人担心：AI 说话短了，是不是代码也变敷衍了？实测下来，只要你在提示词里明确“代码优先、代码要完整”，代码质量不会下降。精简的是解释文字，不是代码本身。但如果你发现代码开始缺胳膊少腿，就在提示词里补一句“代码必须完整可运行”。
6.3 什么时候不该用精简模式
精简模式不是万能的。以下场景建议关掉：
- 学习新概念：你需要 AI 展开讲，这时候啰嗦是好事。
- 写文档、写注释：需要完整句子，短句反而费劲。
- 架构设计讨论：需要 AI 给出多个方案和权衡，精简模式会限制它的思考广度。
所以最好的做法是把精简模式做成一个开关，而不是全局默认。ZCode 的 Skill 机制天然适合这种按需切换，Cursor 里则可以通过不同的.cursorrules文件或手动粘贴来切换。
6.4 常见问题速查表
| 问题 | 可能原因 | 解决方法 |
|---|---|---|
| 提示词不生效 | 位置错误/未激活 | 检查 .cursorrules 或 Skill 状态 |
| AI 回复仍然很长 | 约束力度不够 | 加“违反视为错误”条款 |
| 代码不完整 | 精简过度 | 补“代码必须完整可运行” |
| 输入 Token 反而增加 | 提示词太长 | 压缩提示词到 100 Token 内 |
| 多轮后还是费 Token | 上下文未裁剪 | 开启上下文裁剪或定期新开对话 |
| 换项目后失效 | 规则未随项目走 | 用 .cursorrules 而非全局设置 |
6.5 几个我踩过的坑
第一个坑：提示词写太长。我一开始把提示词写了 400 多个 Token，结果输入成本大增，省下的输出还不够补输入的。后来压缩到 120 Token 左右，才真正划算。提示词本身也要精简，这是个递归问题。
第二个坑：忘了关掉旧对话。Cursor 的对话历史会一直累积，我有时候一个对话开了几十轮，历史长得吓人。后来养成习惯，每完成一个独立任务就新开对话，避免无关历史污染上下文。
第三个坑：在需要详细解释时忘了关精简模式。有一次我在学一个新的框架，AI 回复短得我看不懂，还以为是 AI 变笨了，后来才想起来精简模式还开着。开关意识很重要。
7. 把这套方法迁移到其他场景
7.1 不只是编程
“多动症提示词”这套逻辑，其实适用于任何按 Token 计费、且你只需要结论不需要铺垫的场景。比如：
- 数据分析：让 AI 直接给 SQL 和结果，不要解释每个字段。
- 文案初稿：让 AI 直接给 5 个标题，不要分析目标受众。
- 翻译：让 AI 直接给译文，不要附上原文对照。
核心判断标准是：你需要的是“答案”还是“讲解”。要答案，就开精简模式；要讲解，就关掉。
7.2 和 Agent Skill 的结合
如果你在用 Agent Skill 这类自动化工具，可以把精简提示词写进 Skill 的系统提示里，让每次自动调用都走精简风格。这样你连手动开关都省了。ZCode 的 Skill 机制、Cursor 的 Rules，本质上都是这个思路的不同实现。
7.3 团队协作中的价值
在团队里，Token 额度通常是共享的。如果每个人都用默认的啰嗦模式，额度消耗会非常快。把精简提示词写进项目的.cursorrules并提交到代码仓库，相当于给整个团队装了一个省 Token 的默认配置。新成员拉下代码就自动生效，不用每个人单独教。
我在实际项目里推这套方法时，遇到的最大阻力不是技术问题，而是习惯问题。很多人习惯了 AI 的长篇回复，觉得短回复“不踏实”。但用了一周之后，大部分人都回不去了——因为短回复确实更快、更直接、更省心。
7.4 后续可以怎么扩展
这套方法还有几个可以继续深挖的方向：
- 按任务类型配置不同的 Skill：写代码一个 Skill，写文档一个 Skill，调试一个 Skill，各自有不同的输出约束。
- 结合上下文裁剪策略：定期清理无关历史，进一步压缩输入 Token。
- 监控 Token 消耗：大部分工具都有用量统计，定期看一眼，找出消耗大户，针对性优化。
最后分享一个我自己的小习惯：每次开新对话前，先想清楚“我这次要的是代码还是解释”。要代码，就确保精简模式开着；要解释，就关掉。这个两秒钟的判断，一个月能帮你省下不少额度，也能让你的 AI 协作体验顺畅很多。
