1. 一个反直觉的发现给 AI 加“人设”反而更省 Tokens先说结论我最近在 Cursor 里做项目重构无意间在系统提示词里加了一句“我有注意力缺陷多动障碍ADHD请用最短路径回答我”结果单次会话的 Token 消耗直接降了将近四成。这不是玄学背后有非常清晰的提示词工程逻辑。这个发现来自一次很普通的调试。当时我在用 Cursor 处理一个中型前端项目的组件拆分对话轮次一多上下文窗口很快就满了每次都要手动清理历史记录。我试过各种“请简洁回答”“不要废话”之类的指令效果都一般——AI 还是会先复述一遍我的问题再给一段总结最后才进入正题。直到我换了一种说法把“简洁”换成了“我有多动症看不了长段落”AI 的输出结构立刻变了它开始用短句、分点、直接给代码几乎不再做任何铺垫和收尾。这个现象值得拆开讲。它涉及三个层面的东西提示词的角色设定如何影响输出长度、Tokens 消耗的真实构成、以及在 Cursor 这类 AI 编程工具里怎么把这个技巧落地。如果你每天都在跟 AI 对话不管是写代码、写文案还是做分析这套方法都能直接抄作业。注意这里说的“多动症”是一种提示词策略不是医学诊断也不涉及任何健康建议。它的本质是利用大模型对“用户画像”的敏感度来约束输出风格。2. 为什么“多动症”比“请简洁”更管用2.1 大模型对“人设”的响应机制大语言模型在生成回复时并不是单纯执行指令而是在“预测下一个最合理的词”。当你告诉它“请简洁回答”它理解的是一个风格要求但当你告诉它“我有 ADHD看长文本会走神”它理解的是一个用户状态。这两者对模型的影响权重完全不同。风格要求是软约束模型可以在开头加一句“好的我来简洁说明”然后继续写三段。用户状态是硬约束模型会主动判断如果输出太长这个用户可能根本读不完那我的回答就是失败的。所以它会优先保证信息密度砍掉所有社交性铺垫。我实测过一组对比。同一个问题“帮我写一个 React 的防抖 Hook”两种提示词的结果如下提示词类型输出字数包含铺垫包含总结代码可用性“请简洁回答”约 320 字有“好的以下是一个…”有“总结一下…”需要手动删减“我有 ADHD请用最短路径”约 180 字无无直接复制可用字数少了 44%但代码质量没有任何下降。省下来的全是“好的”“以下”“希望对你有所帮助”这类无效 Token。2.2 Tokens 到底花在哪里了很多人以为 Tokens 主要花在代码上其实不是。在一个典型的 Cursor 会话里Token 消耗的大头往往是对话历史和模型的冗余输出。假设你问了一个问题模型回复了 500 个 Token。下一轮对话时这 500 个 Token 会作为历史记录再次被送入模型。如果你问了 10 轮光是模型自己的历史回复就可能累积到 3000-5000 Tokens。这些历史里如果有一半是“好的我来帮你”“希望这个回答对你有帮助”那就是纯浪费。“ADHD 人设”的作用是从源头压缩每一轮的输出长度。单轮看起来只省了 100-200 Tokens但 10 轮下来就是 1000-2000 Tokens 的差距。对于 Cursor Pro 用户来说额度是有限的省下来的额度可以多跑好几轮复杂重构。2.3 这个技巧的适用边界不是所有场景都适合用“多动症”人设。我总结了一个简单的判断标准适合代码生成、命令查询、API 用法、报错排查、快速翻译、格式转换。这些场景你要的是答案本身不需要 AI 陪你聊天。不适合方案评审、架构设计、创意发散、教学讲解。这些场景需要 AI 展开论述强行压缩反而会丢失关键信息。慎用涉及安全、医疗、法律等需要严谨表述的领域。过度压缩可能导致歧义。实操心得我通常会在 Cursor 的 Rules for AI 里设置两套提示词一套是“ADHD 模式”用于日常编码一套是“详细模式”用于方案讨论。切换成本很低但效果差异很明显。3. 在 Cursor 里落地这套提示词的具体步骤3.1 Cursor 的提示词入口在哪里Cursor 的提示词配置分几个层级从全局到项目级依次是Settings General Rules for AI全局生效所有项目共用。项目根目录的.cursorrules文件只对当前项目生效优先级高于全局。对话中的临时指令在 Chat 或 Composer 里直接输入只对当前会话生效。我建议把“ADHD 模式”写在全局 Rules for AI 里然后在具体项目里用.cursorrules做微调。这样既保证了默认行为是简洁的又能在需要详细讨论的项目里覆盖掉。3.2 具体的提示词写法不要只写“我有 ADHD”。这句话单独放进去模型可能会理解成你在寻求医疗建议。要把它和输出要求绑定在一起。我实测下来最稳的写法是这样的用户有注意力缺陷倾向阅读长文本困难。请遵循以下输出规则 1. 直接给答案不要复述问题。 2. 不要写“好的”“以下”“希望有帮助”等铺垫和收尾。 3. 代码优先解释控制在必要范围内。 4. 如果需要分点用短句每点不超过两行。 5. 不确定的地方直接说“不确定”不要编造。这段提示词的关键在于把“ADHD”翻译成了可执行的输出规则。模型不需要理解 ADHD 是什么它只需要知道短、直接、代码优先、不废话。3.3 配合 Cursor 的哪些功能效果更好Cursor 有几个功能和这套提示词是绝配ComposerCtrlI多文件编辑时输出越短diff 越清晰。ADHD 模式能让 Composer 直接给修改后的代码而不是先解释一遍它要改什么。Inline EditCtrlK选中代码后直接说“改成防抖”配合 ADHD 提示词它几乎只输出代码不输出解释。Chat 的 Codebase当它检索完整个代码库后ADHD 模式能防止它把检索到的内容全部复述一遍直接给结论。我自己的.cursorrules里还会加一条“如果我的问题可以用一行命令解决不要给我三段解释。”这条规则帮我省了很多查 Docker 命令、Git 操作时的 Token。3.4 一个完整的配置示例这是我目前在用的全局 Rules for AI 配置你可以直接复制你是一个极简风格的编程助手。用户阅读长文本困难请遵守 - 禁止任何形式的问候、铺垫、总结、免责声明。 - 代码块之外的解释不超过三句话。 - 优先给出可复制运行的代码而不是描述代码。 - 如果用户的问题有歧义用一句话确认不要展开分析。 - 报错排查时直接给最可能的原因和修复命令不要列五种可能性。配合这套配置我在 Cursor 里问“这个 TypeScript 报错怎么修”得到的回复通常就是一行命令或者一个代码片段没有多余内容。4. 实测数据与常见问题排查4.1 我做的三组对比测试为了验证效果我用同一个 Cursor 会话做了三组测试每组问 10 个编程问题统计 Token 消耗和回答可用性。测试组提示词总 Tokens平均每轮可用性评分A 组无特殊提示约 1280012808/10B 组“请简洁回答”约 1050010508/10C 组ADHD 人设 规则约 76007609/10C 组不仅 Token 最少可用性反而最高。原因是它的回答里没有需要手动删除的废话复制粘贴就能用。A 组虽然回答详细但每次都要花时间跳过铺垫找重点。4.2 常见问题速查表问题现象可能原因解决方法AI 还是写很长提示词只写了“ADHD”没写具体规则把输出规则逐条列出来AI 变得太简略漏掉关键信息压缩过度在规则里加“关键步骤不能省”不同项目效果不一样项目.cursorrules覆盖了全局检查项目级配置中文回答还是啰嗦模型对中文的“简洁”理解偏弱用英文写规则或者明确字数上限代码注释也被删了规则太激进加一条“代码内注释保留”4.3 几个我踩过的坑第一个坑是把“ADHD”写得太靠后。提示词的位置会影响权重放在最前面效果最好。我试过放在 Rules 的最后一行模型经常忽略。第二个坑是没有区分“简洁”和“不完整”。有一次我让它写一个完整的 Express 中间件它只给了核心逻辑错误处理全没了。后来我在规则里加了一句“完整性优先于简洁性但不要解释”问题就解决了。第三个坑是在需要详细讨论时忘了关掉。有一次做架构评审AI 只给了三行结论我完全没法判断它的推理过程。所以我现在养成了习惯写代码用 ADHD 模式讨论方案切回普通模式。提示如果你用的是 Cursor 的免费额度这套方法能让你多撑好几轮对话。Pro 用户虽然额度多但省下来的 Token 可以用来跑更复杂的 Codebase 检索。5. 把这套思路迁移到其他 AI 工具5.1 在 ChatGPT 和 Claude 里的用法同样的逻辑可以迁移到任何对话式 AI。在 ChatGPT 里你可以把规则写在 Custom Instructions 的“How should ChatGPT respond”一栏。在 Claude 里可以写在 Project 的 System Prompt 里。我实测下来Claude 对“用户状态”类提示词的响应比 GPT 更敏感。同样一句“我有 ADHD”Claude 的输出压缩幅度更大但偶尔会过于简略。所以我在 Claude 里会加一句“如果问题复杂可以先给一句话结论再给必要细节”。5.2 在 AI Agent 和自动化流程里的应用如果你在用 AI Agent 做自动化比如自动生成周报、自动回复工单这套提示词的价值更大。因为 Agent 的输出往往是批量处理的单次省 200 Tokens1000 次就是 20 万 Tokens。我在一个自动代码审查的 Agent 里用了类似的规则让它“假设审查者只有 30 秒时间”结果它从原来每条评论 80 字压缩到了 25 字而且问题定位更准了。因为强制压缩会逼着模型做优先级排序只保留最关键的问题。5.3 提示词工程的一个通用原则这件事让我重新理解了一个提示词工程原则约束输出格式比约束输出内容更有效。你说“请简洁”模型不知道简洁的标准是什么。你说“每点不超过两行不要铺垫和总结”模型就有了明确的边界。ADHD 人设之所以有效是因为它把模糊的风格要求转化成了具体的格式约束。这个原则可以套用到很多场景。比如你想让 AI 写邮件不要说“写得专业一点”而要说“三段以内第一段说明来意第二段给方案第三段问是否可行”。你想让 AI 写代码不要说“写得好一点”而要说“给完整代码不要伪代码不要解释”。5.4 关于 Tokens 消耗的进一步优化除了压缩输出还有几个省 Tokens 的实操技巧定期清理对话历史Cursor 的 Chat 可以手动开新会话不要让一个会话跑几十轮。用 精确引用文件不要让它自己检索整个代码库直接 你需要的文件。把常用规则写进.cursorrules不要每次都在对话里重复。代码和解释分开问先要代码再针对不懂的地方追问比一次性要“代码加详细解释”更省。我自己的习惯是简单问题用 Inline Edit中等复杂用 Chat大重构才用 Composer。不同工具的输出长度天然不同选对了工具本身就省 Tokens。6. 我对这套方法的个人体会用了大概两个月之后我最大的感受不是省了多少 Tokens而是对话效率的整体提升。以前我经常要在一大段回复里找关键信息现在 AI 直接把答案放在第一行我扫一眼就能判断有没有用。当然这套方法也有代价。它会让 AI 变得“冷淡”少了那种被帮助的感觉。如果你习惯 AI 跟你寒暄几句可能会觉得不适应。但如果你每天要处理几十个编程问题这种冷淡反而是效率。另外我想说的是ADHD 这个标签本身不重要。你可以换成“我很忙”“我看不了长文”“请用电报体”效果类似。关键是让模型意识到输出太长会导致任务失败。一旦模型建立了这个判断它就会主动压缩。最后分享一个我最近在试的变体把“ADHD”换成“我在用手机看屏幕很小”。这个说法对输出长度的影响也很明显而且适用场景更广不涉及任何健康相关的联想。如果你觉得“多动症”这个说法在团队里不好解释可以试试这个替代方案。
给AI加ADHD人设省40% Tokens：Cursor提示词工程实战
1. 一个反直觉的发现给 AI 加“人设”反而更省 Tokens先说结论我最近在 Cursor 里做项目重构无意间在系统提示词里加了一句“我有注意力缺陷多动障碍ADHD请用最短路径回答我”结果单次会话的 Token 消耗直接降了将近四成。这不是玄学背后有非常清晰的提示词工程逻辑。这个发现来自一次很普通的调试。当时我在用 Cursor 处理一个中型前端项目的组件拆分对话轮次一多上下文窗口很快就满了每次都要手动清理历史记录。我试过各种“请简洁回答”“不要废话”之类的指令效果都一般——AI 还是会先复述一遍我的问题再给一段总结最后才进入正题。直到我换了一种说法把“简洁”换成了“我有多动症看不了长段落”AI 的输出结构立刻变了它开始用短句、分点、直接给代码几乎不再做任何铺垫和收尾。这个现象值得拆开讲。它涉及三个层面的东西提示词的角色设定如何影响输出长度、Tokens 消耗的真实构成、以及在 Cursor 这类 AI 编程工具里怎么把这个技巧落地。如果你每天都在跟 AI 对话不管是写代码、写文案还是做分析这套方法都能直接抄作业。注意这里说的“多动症”是一种提示词策略不是医学诊断也不涉及任何健康建议。它的本质是利用大模型对“用户画像”的敏感度来约束输出风格。2. 为什么“多动症”比“请简洁”更管用2.1 大模型对“人设”的响应机制大语言模型在生成回复时并不是单纯执行指令而是在“预测下一个最合理的词”。当你告诉它“请简洁回答”它理解的是一个风格要求但当你告诉它“我有 ADHD看长文本会走神”它理解的是一个用户状态。这两者对模型的影响权重完全不同。风格要求是软约束模型可以在开头加一句“好的我来简洁说明”然后继续写三段。用户状态是硬约束模型会主动判断如果输出太长这个用户可能根本读不完那我的回答就是失败的。所以它会优先保证信息密度砍掉所有社交性铺垫。我实测过一组对比。同一个问题“帮我写一个 React 的防抖 Hook”两种提示词的结果如下提示词类型输出字数包含铺垫包含总结代码可用性“请简洁回答”约 320 字有“好的以下是一个…”有“总结一下…”需要手动删减“我有 ADHD请用最短路径”约 180 字无无直接复制可用字数少了 44%但代码质量没有任何下降。省下来的全是“好的”“以下”“希望对你有所帮助”这类无效 Token。2.2 Tokens 到底花在哪里了很多人以为 Tokens 主要花在代码上其实不是。在一个典型的 Cursor 会话里Token 消耗的大头往往是对话历史和模型的冗余输出。假设你问了一个问题模型回复了 500 个 Token。下一轮对话时这 500 个 Token 会作为历史记录再次被送入模型。如果你问了 10 轮光是模型自己的历史回复就可能累积到 3000-5000 Tokens。这些历史里如果有一半是“好的我来帮你”“希望这个回答对你有帮助”那就是纯浪费。“ADHD 人设”的作用是从源头压缩每一轮的输出长度。单轮看起来只省了 100-200 Tokens但 10 轮下来就是 1000-2000 Tokens 的差距。对于 Cursor Pro 用户来说额度是有限的省下来的额度可以多跑好几轮复杂重构。2.3 这个技巧的适用边界不是所有场景都适合用“多动症”人设。我总结了一个简单的判断标准适合代码生成、命令查询、API 用法、报错排查、快速翻译、格式转换。这些场景你要的是答案本身不需要 AI 陪你聊天。不适合方案评审、架构设计、创意发散、教学讲解。这些场景需要 AI 展开论述强行压缩反而会丢失关键信息。慎用涉及安全、医疗、法律等需要严谨表述的领域。过度压缩可能导致歧义。实操心得我通常会在 Cursor 的 Rules for AI 里设置两套提示词一套是“ADHD 模式”用于日常编码一套是“详细模式”用于方案讨论。切换成本很低但效果差异很明显。3. 在 Cursor 里落地这套提示词的具体步骤3.1 Cursor 的提示词入口在哪里Cursor 的提示词配置分几个层级从全局到项目级依次是Settings General Rules for AI全局生效所有项目共用。项目根目录的.cursorrules文件只对当前项目生效优先级高于全局。对话中的临时指令在 Chat 或 Composer 里直接输入只对当前会话生效。我建议把“ADHD 模式”写在全局 Rules for AI 里然后在具体项目里用.cursorrules做微调。这样既保证了默认行为是简洁的又能在需要详细讨论的项目里覆盖掉。3.2 具体的提示词写法不要只写“我有 ADHD”。这句话单独放进去模型可能会理解成你在寻求医疗建议。要把它和输出要求绑定在一起。我实测下来最稳的写法是这样的用户有注意力缺陷倾向阅读长文本困难。请遵循以下输出规则 1. 直接给答案不要复述问题。 2. 不要写“好的”“以下”“希望有帮助”等铺垫和收尾。 3. 代码优先解释控制在必要范围内。 4. 如果需要分点用短句每点不超过两行。 5. 不确定的地方直接说“不确定”不要编造。这段提示词的关键在于把“ADHD”翻译成了可执行的输出规则。模型不需要理解 ADHD 是什么它只需要知道短、直接、代码优先、不废话。3.3 配合 Cursor 的哪些功能效果更好Cursor 有几个功能和这套提示词是绝配ComposerCtrlI多文件编辑时输出越短diff 越清晰。ADHD 模式能让 Composer 直接给修改后的代码而不是先解释一遍它要改什么。Inline EditCtrlK选中代码后直接说“改成防抖”配合 ADHD 提示词它几乎只输出代码不输出解释。Chat 的 Codebase当它检索完整个代码库后ADHD 模式能防止它把检索到的内容全部复述一遍直接给结论。我自己的.cursorrules里还会加一条“如果我的问题可以用一行命令解决不要给我三段解释。”这条规则帮我省了很多查 Docker 命令、Git 操作时的 Token。3.4 一个完整的配置示例这是我目前在用的全局 Rules for AI 配置你可以直接复制你是一个极简风格的编程助手。用户阅读长文本困难请遵守 - 禁止任何形式的问候、铺垫、总结、免责声明。 - 代码块之外的解释不超过三句话。 - 优先给出可复制运行的代码而不是描述代码。 - 如果用户的问题有歧义用一句话确认不要展开分析。 - 报错排查时直接给最可能的原因和修复命令不要列五种可能性。配合这套配置我在 Cursor 里问“这个 TypeScript 报错怎么修”得到的回复通常就是一行命令或者一个代码片段没有多余内容。4. 实测数据与常见问题排查4.1 我做的三组对比测试为了验证效果我用同一个 Cursor 会话做了三组测试每组问 10 个编程问题统计 Token 消耗和回答可用性。测试组提示词总 Tokens平均每轮可用性评分A 组无特殊提示约 1280012808/10B 组“请简洁回答”约 1050010508/10C 组ADHD 人设 规则约 76007609/10C 组不仅 Token 最少可用性反而最高。原因是它的回答里没有需要手动删除的废话复制粘贴就能用。A 组虽然回答详细但每次都要花时间跳过铺垫找重点。4.2 常见问题速查表问题现象可能原因解决方法AI 还是写很长提示词只写了“ADHD”没写具体规则把输出规则逐条列出来AI 变得太简略漏掉关键信息压缩过度在规则里加“关键步骤不能省”不同项目效果不一样项目.cursorrules覆盖了全局检查项目级配置中文回答还是啰嗦模型对中文的“简洁”理解偏弱用英文写规则或者明确字数上限代码注释也被删了规则太激进加一条“代码内注释保留”4.3 几个我踩过的坑第一个坑是把“ADHD”写得太靠后。提示词的位置会影响权重放在最前面效果最好。我试过放在 Rules 的最后一行模型经常忽略。第二个坑是没有区分“简洁”和“不完整”。有一次我让它写一个完整的 Express 中间件它只给了核心逻辑错误处理全没了。后来我在规则里加了一句“完整性优先于简洁性但不要解释”问题就解决了。第三个坑是在需要详细讨论时忘了关掉。有一次做架构评审AI 只给了三行结论我完全没法判断它的推理过程。所以我现在养成了习惯写代码用 ADHD 模式讨论方案切回普通模式。提示如果你用的是 Cursor 的免费额度这套方法能让你多撑好几轮对话。Pro 用户虽然额度多但省下来的 Token 可以用来跑更复杂的 Codebase 检索。5. 把这套思路迁移到其他 AI 工具5.1 在 ChatGPT 和 Claude 里的用法同样的逻辑可以迁移到任何对话式 AI。在 ChatGPT 里你可以把规则写在 Custom Instructions 的“How should ChatGPT respond”一栏。在 Claude 里可以写在 Project 的 System Prompt 里。我实测下来Claude 对“用户状态”类提示词的响应比 GPT 更敏感。同样一句“我有 ADHD”Claude 的输出压缩幅度更大但偶尔会过于简略。所以我在 Claude 里会加一句“如果问题复杂可以先给一句话结论再给必要细节”。5.2 在 AI Agent 和自动化流程里的应用如果你在用 AI Agent 做自动化比如自动生成周报、自动回复工单这套提示词的价值更大。因为 Agent 的输出往往是批量处理的单次省 200 Tokens1000 次就是 20 万 Tokens。我在一个自动代码审查的 Agent 里用了类似的规则让它“假设审查者只有 30 秒时间”结果它从原来每条评论 80 字压缩到了 25 字而且问题定位更准了。因为强制压缩会逼着模型做优先级排序只保留最关键的问题。5.3 提示词工程的一个通用原则这件事让我重新理解了一个提示词工程原则约束输出格式比约束输出内容更有效。你说“请简洁”模型不知道简洁的标准是什么。你说“每点不超过两行不要铺垫和总结”模型就有了明确的边界。ADHD 人设之所以有效是因为它把模糊的风格要求转化成了具体的格式约束。这个原则可以套用到很多场景。比如你想让 AI 写邮件不要说“写得专业一点”而要说“三段以内第一段说明来意第二段给方案第三段问是否可行”。你想让 AI 写代码不要说“写得好一点”而要说“给完整代码不要伪代码不要解释”。5.4 关于 Tokens 消耗的进一步优化除了压缩输出还有几个省 Tokens 的实操技巧定期清理对话历史Cursor 的 Chat 可以手动开新会话不要让一个会话跑几十轮。用 精确引用文件不要让它自己检索整个代码库直接 你需要的文件。把常用规则写进.cursorrules不要每次都在对话里重复。代码和解释分开问先要代码再针对不懂的地方追问比一次性要“代码加详细解释”更省。我自己的习惯是简单问题用 Inline Edit中等复杂用 Chat大重构才用 Composer。不同工具的输出长度天然不同选对了工具本身就省 Tokens。6. 我对这套方法的个人体会用了大概两个月之后我最大的感受不是省了多少 Tokens而是对话效率的整体提升。以前我经常要在一大段回复里找关键信息现在 AI 直接把答案放在第一行我扫一眼就能判断有没有用。当然这套方法也有代价。它会让 AI 变得“冷淡”少了那种被帮助的感觉。如果你习惯 AI 跟你寒暄几句可能会觉得不适应。但如果你每天要处理几十个编程问题这种冷淡反而是效率。另外我想说的是ADHD 这个标签本身不重要。你可以换成“我很忙”“我看不了长文”“请用电报体”效果类似。关键是让模型意识到输出太长会导致任务失败。一旦模型建立了这个判断它就会主动压缩。最后分享一个我最近在试的变体把“ADHD”换成“我在用手机看屏幕很小”。这个说法对输出长度的影响也很明显而且适用场景更广不涉及任何健康相关的联想。如果你觉得“多动症”这个说法在团队里不好解释可以试试这个替代方案。
