企业官网建设流程全解析

1. 一个反直觉的发现：给 AI 贴个"多动症"标签，Token 消耗直接砍半

先说结论。我在 Cursor 里做日常开发辅助时，习惯在对话开头加一句自我状态描述。某天随手写了一句"我有 ADHD，注意力容易散，请把回答压缩到最短、只给可执行结论"，结果那一整轮对话的 Token 消耗比我平时的习惯用法少了将近一半，而且我拿到答案的速度明显变快。这不是玄学，背后是提示词工程里一个被严重低估的杠杆：用"人设约束"反向压缩模型的输出空间。

这篇内容适合三类人看。第一类是靠 Cursor、各类 AI 编程助手吃饭的开发者，每天要跑几十上百轮对话，Token 就是真金白银；第二类是在做 AI Agent、Skill 编排的人，需要控制单次调用的上下文成本；第三类是对提示词工程感兴趣、想搞明白"为什么同样的问题，别人问就是比我便宜"的人。我会把这件事从现象、原理、实操、踩坑到可复用的模板全部拆开讲，你看完可以直接抄作业。

需要先澄清一点：这里的"多动症"不是医学诊断，而是一种提示词层面的角色设定技巧。它的本质是给模型一个明确的"输出预算约束"，让模型在生成时主动做减法。很多人以为省 Token 要靠换更便宜的模型、靠精简上下文、靠缓存，这些都对，但都忽略了最直接的一环——你让模型说多少话，模型就烧多少 Token，而"说多少"是你可以用一句话控制的。

我实测下来，同一批任务（代码解释、报错定位、重构建议），加上这句约束后，输出 Token 平均下降 40% 到 60%，输入侧几乎不变。对于按量计费或者有额度上限的编程助手来说，这个降幅意味着你一天能多跑将近一倍的对话轮次。下面我把这件事掰开揉碎讲清楚。

2. Token 到底烧在哪里：先搞懂账单的构成再谈省钱

2.1 输入 Token 和输出 Token 是两笔账

很多人一提到省 Token 就想着"少贴点代码"，这其实只解决了输入侧。一次对话的账单由两部分组成：输入 Token（你发过去的内容，包括系统提示、历史对话、粘贴的代码和报错）和输出 Token（模型生成的内容）。两者的计价方式在不同平台不一样，但有一个共同规律：输出 Token 通常比输入 Token 贵，而且输出是"滚雪球"的。

为什么说输出会滚雪球？因为多轮对话里，模型上一轮生成的内容会作为历史上下文，在下一轮被重新计入输入。也就是说，模型这一轮多废话了 500 Token，下一轮这 500 Token 会以输入的形式再收你一次费，再下一轮还是。一轮啰嗦，后面每一轮都在为它买单。这就是为什么"让模型少说话"的收益是复利式的，而不是一次性的。

2.2 模型的"默认话痨模式"从哪来

你可能会问，模型为什么不能默认就简洁？原因在于训练和对齐阶段。绝大多数对话模型在 RLHF（基于人类反馈的强化学习）阶段，被人类标注员偏好"详细、完整、有礼貌"的回答。于是模型学到的策略是：宁可多说，不可少说。它会自动加上"好的，我来帮你分析一下""首先我们需要理解……""总结一下"这类填充语，还会把同一个结论用三种方式重复表达。

这些内容对模型来说是"安全"的，因为它降低了"回答不完整被差评"的概率。但对你来说，全是成本。你要做的不是抱怨模型话痨，而是用提示词把它的默认策略覆盖掉。而"ADHD 人设"之所以有效，就是因为它给模型提供了一个非常具体、非常强的行为约束信号。

2.3 一个粗略的量化：废话占了多少

我做过一个小统计，拿 20 个常见的编程问题（解释一段函数、定位一个报错、给一个重构方案）分别用默认问法和加约束问法跑，记录输出 Token。结果大致是这样的：

这个数据不是精确基准测试，样本也小，但趋势非常稳定：降幅集中在 50% 上下。而且我注意到一个细节，加约束后模型并不是"少给了信息"，而是"去掉了包装信息"。核心结论、关键代码、必要步骤一个没少，少的是铺垫、重复和客套。

3. "ADHD 人设"为什么能生效：三个机制叠加的结果

3.1 机制一：把模糊的"简洁"变成具体的"行为约束"

你可能试过直接说"请简洁回答"，效果一般。为什么？因为"简洁"是个形容词，模型对形容词的响应很弱，它不知道简洁到什么程度算简洁。但"我有 ADHD，注意力容易散，长回答我看不下去"是一个场景化的行为约束，它给了模型一个可推理的目标：如果回答太长，用户会读不下去，所以必须短。

这就像你跟一个助理说"报告写短点"，他可能给你砍掉 20%；但你说"我只有五分钟看报告，超过一页我就扔了"，他会直接给你一页纸的要点。约束越具体、后果越明确，模型的执行力度越强。

3.2 机制二：触发模型的"共情式对齐"

现在的对话模型都经过共情训练，对"用户有某种困难"这类描述会做出适应性调整。当你描述自己有注意力方面的困难时，模型会主动切换到"辅助模式"：短句、分点、先给结论、减少修饰。这不是模型真的理解 ADHD，而是它在训练数据里学到"面对这类用户描述，应该这样回应"。

我对比过几种说法，"请简洁"、"我很忙"、"我有 ADHD"，实测约束强度是递增的。前两个是任务指令，第三个是身份描述，身份描述对模型行为的影响更持久，因为它会贯穿整轮对话，而不只是影响当前这一条回复。

3.3 机制三：压缩了模型的"自我解释"空间

模型话痨的一大来源是"自我解释"——它要向你证明自己的推理是对的，所以会把思考过程也写出来。而 ADHD 人设隐含了一个信号：用户没耐心看你的推理过程，只要结论。这会显著抑制模型输出中间步骤的倾向。

这一点在代码任务上尤其明显。默认情况下，模型会先复述你的问题，再分析可能原因，再给方案，最后总结。加了约束后，它往往直接给"问题在第几行、改成什么、为什么"三句话搞定。省下来的全是 Token。

提示：这套方法的核心不是"装病"，而是"用具体身份描述替代抽象指令"。你完全可以用"我是新手，看不懂长解释""我在赶 deadline，只要结论"来达到类似效果，ADHD 只是其中约束力比较强的一种说法。

4. 在 Cursor 里怎么落地：从系统提示到单轮对话的完整配置

4.1 把约束写进项目级规则，而不是每轮重复

Cursor 支持项目级规则文件（不同版本叫法可能是 Rules、Custom Instructions 或 .cursorrules 之类），这是最省事的位置。把约束写进去，之后这个项目里的每一轮对话都会自动带上，你不用每次手动加。

我自己的规则文件里关于输出风格的部分大概是这样：

输出风格约束： - 用户注意力容易分散，长回答会被跳过 - 默认只给结论和可执行步骤，不写铺垫和总结 - 代码解释控制在 5 行以内，除非用户明确要求详细 - 报错定位直接给"文件:行号 + 原因 + 改法" - 禁止使用"首先/其次/最后""综上所述""希望对你有帮助"这类填充语 - 如果答案超过 10 行，先给一句话结论，再问是否需要展开

注意最后一条很关键：给模型一个"超长就停下来问"的出口。这样既控制了单轮输出，又不会因为强行压缩而丢信息，需要细节时你再让它展开。

4.2 单轮对话里的临时加强

项目规则是基线，遇到特别啰嗦的任务（比如让它读一大段代码给方案），我会在当轮再加一句强化：

这轮请极限压缩：我有 ADHD，超过 8 行我就看不完了。 先给结论，再给最关键的 1 到 2 个改动点，其他一律省略。

实测这种"基线 + 当轮强化"的组合，比只写项目规则效果更稳。因为模型对"当前这条消息里的指令"权重更高，临时加强能压住它在复杂任务上的话痨冲动。

4.3 不同任务类型的约束模板

不是所有任务都适合极限压缩。我按任务类型整理了几个模板，你可以直接拿去改：

这套模板的逻辑是一样的：用格式约束替代长度约束。你告诉模型"用表格""用行内注释""每格 10 个字"，比说"简短点"有效得多，因为格式是可执行的，长度是模糊的。

5. 实测中踩过的坑：这些情况下压缩会反噬

5.1 复杂调试任务压太狠会丢关键信息

我踩过最典型的一个坑：有一次排查一个异步竞态问题，我用了极限压缩约束，模型只给了"在 X 函数加锁"这一句。结果我照着改，问题没解决，因为真正的根因在另一个调用链上。模型其实"知道"更多，但被我的约束逼着只说了最表层的一条。

教训是：调试类任务，尤其是涉及多文件、多调用链的，不要用极限压缩。这类任务的 Token 该花就得花，省下来的钱不够你返工的。我的做法是给这类任务单独开一个"详细模式"，约束改成"先给最可能的 3 个原因，按可能性排序，每个原因给验证方法"。

5.2 约束写太死会让模型不敢问澄清问题

另一个坑是，当我把约束写成"禁止任何反问，直接给答案"时，遇到需求本身模糊的情况，模型会硬着头皮猜，猜错了浪费更多轮次。后来我把约束改成"如果需求不明确，先用一句话确认，再给答案"，效果好很多。

省 Token 的前提是不增加对话轮次。如果为了压缩单轮输出导致要多问两轮，总账反而是亏的。这一点很多人算不明白，只盯着单轮输出长度，忽略了总轮次。

5.3 不同模型对同一约束的响应差异很大

我在几个不同的模型上试过同一套 ADHD 约束，响应差异明显。有的模型对身份描述很敏感，一句话就切到极简模式；有的模型对身份描述几乎无感，但对格式约束（"用表格""每行不超过 20 字"）响应很好。

所以我的建议是：身份约束 + 格式约束一起上。身份约束负责定调，格式约束负责兜底。单靠任何一个都不够稳。你可以先小范围试，看你的主力模型吃哪一套，再固化到规则文件里。

注意：约束强度要跟任务重要性匹配。日常问答、代码解释可以压到极限；架构设计、复杂调试、安全相关的问题，宁可多花 Token 也要拿全信息。省 Token 是手段，不是目的。

6. 把技巧升级成系统：Skill 化与 Agent 场景下的成本控制

6.1 为什么这件事值得做成 Skill

如果你只是偶尔用 AI，手动加一句约束就够了。但如果你每天跑几十上百轮，或者在做 Agent、Skill 编排，手动加约束既累又容易忘。这时候应该把它固化成一个可复用的 Skill 或提示词模板。

所谓 Skill，本质就是一段封装好的、可被反复调用的提示词逻辑。你可以把"输出压缩"做成一个独立的 Skill，在任何需要省 Token 的场景里挂上去。它的输入是用户的原始问题，输出是加了约束的完整提示词。这样你既保留了压缩能力，又不用每次手写。

6.2 Agent 场景下的特殊考量

在做 Agent 的时候，Token 成本会被放大，因为 Agent 往往要自主跑很多步，每一步都是一次模型调用。这时候"输出压缩"的收益是成倍放大的：每一步省 50%，十步就省下大量额度。

但 Agent 场景有个额外约束：压缩不能破坏结构化输出。Agent 之间靠结构化数据（JSON、特定格式的文本）通信，如果你把输出压得太随意，解析会失败，反而增加重试成本。所以 Agent 场景下我推荐用"格式约束"而不是"长度约束"，明确要求"只输出 JSON，不要任何解释文字"，这样既省 Token 又保证可解析。

6.3 一个可复用的压缩提示词骨架

我把这套东西整理成一个骨架，你可以直接改成自己的版本：

[角色约束] 用户注意力容易分散，长回答会被跳过，请默认极简输出。 [输出规则] 1. 先给一句话结论 2. 只给可执行步骤或关键代码 3. 禁止铺垫、重复、总结、客套 4. 超过 10 行时，先给结论并询问是否展开 [格式约束] 按任务类型选择：报错用"文件:行号 + 原因 + 改法"， 对比用表格，代码解释用行内注释。 [例外] 需求不明确时，先用一句话确认再回答。

这个骨架的好处是模块化：角色约束定调，输出规则控长度，格式约束保结构，例外条款防反噬。你可以按自己的模型和任务类型微调每一块。

7. 关于"省 Token"这件事，我最后想说的几句实在话

这套方法我用了几个月，最大的感受不是省了多少钱，而是它逼着我把问题问得更清楚。当你要求模型极简输出时，你自己也得想清楚到底要什么，否则模型给你的极简答案可能不是你要的。某种程度上，约束模型的过程也是约束自己。

另外提醒一句，别把"省 Token"当成唯一目标。我见过有人为了省 Token，把该给的上下文砍掉，结果模型答非所问，来回好几轮，总成本反而更高。Token 优化的正确姿势是在保证任务完成质量的前提下减少浪费，而不是无脑压缩。浪费在哪？在模型的客套话、重复表达、自我解释上，这些才是该砍的。

最后分享一个小习惯：我会定期回看自己的对话记录，找出那些"输出特别长但实际没用上"的轮次，分析当时是不是约束没加到位。这个复盘做几次之后，你对什么样的任务该配什么样的约束会越来越有感觉。工具是死的，手感是练出来的。