我一直觉得，AI对话里的“铺垫式回答”是很多人没意识到的高频痛点。尤其是当你急着要一个结论时，它先给你来一段背景介绍、概念澄清、边界说明，甚至把各种可能性都铺一遍，才慢吞吞落到答案上。对于一般用户，这可能只是“多读两行”；但对于注意力容易分散、工作记忆容量有限的人群——比如ADHD群体，这种输出形态几乎是灾难性的：你还没读到重点，注意力已经被消耗完了。
我折腾了一个叫i-have-adhd的模拟项目，目标很单纯：想办法让 AI 学会“先说重点”。不是靠用户每次在对话框里打字“请简短回答”，而是通过一套可复用的提示词协议和交互策略，让模型在长对话里稳定地保持“结论先行、细节殿后”的输出习惯。这个项目很适合两类人参考：一是本身有注意力管理困扰，希望用 AI 提升信息获取效率的人；二是做提示词工程、AI 应用封装，想让产品输出更符合特定用户群体习惯的开发者。这篇文章会把我从 0 到 1 的完整思路、踩坑记录和最终落地方案都摊开讲。
1. 为什么“先说重点”是刚需：ADHD 的信息接收模型
1.1 工作记忆是“小杯子”，装不下长篇铺垫
ADHD 不是一个“坐不住”那么简单，它和大脑的执行功能密切相关，其中一个很关键的点是工作记忆的容量和处理效率。你可以把工作记忆想象成一只很小的杯子：普通人一次性能接住七八个信息单位的“水”，而 ADHD 的杯子可能只有三四个单位，还时不时漏水。处理一句话、跟踪一段论述的逻辑线索，靠的就是这只杯子。
当 AI 回答一个“线程安全怎么理解”的问题时，如果回答是：
“在并发编程中，多个线程共享资源时容易出现竞态条件，而竞态条件会导致数据不一致，为了解决这个问题，行业里引入了同步机制，其中一种重要的设计就是线程安全……”
这段信息流对 ADHD 用户来说是持续的压力：每个分句都占据工作记忆资源，还要不断修正“这段话到底想说什么”的临时假设。普通用户可以在脑中缓存这些信息片段，等最后一句“所以说线程安全就是资源访问的原子性保证”出来后再整合。但 ADHD 用户很可能在读到“竞态条件”时就已经走神了，后面的一切都白搭。
所以“先说重点”不是礼貌，而是降低认知负载的核心手段：先把结论放进杯子里，再往里填支撑性细节。这样一来，哪怕后面走神了，手里也已经握着最重要的信息。
1.2 传统对话 AI 的“铺设式”输出为什么对注意力不友好
我统计过不少主流对话 AI 的默认回答风格，发现它们普遍存在三个对 ADHD 不友好的特征：
| 特征 | 表现 | 对 ADHD 的影响 |
|---|---|---|
| 背景先行 | 先给概念定义、历史来源、适用边界 | 浪费工作记忆容量，延迟主信息出现 |
| 面面俱到 | 把相关场景、例外情况全部罗列 | 重要信息被淹没，需要额外筛选 |
| 缓冲式句式 | “这是一个很好的问题”“让我们一步步来看” | 产生“话还没开始”的错觉，注意力更容易漂移 |
更隐蔽的一点是，很多 AI 的回答喜欢用“总—分—总”结构，但把“总”放在了最后，或者“分”的篇幅过于庞大，导致结论出现时已经被大量中间信息稀释了。这套写法来自训练数据里的文章体裁——正式文本讲究推演过程、背景交代再到结论收束，这没问题。但对话场景和书面文章的信息消费方式完全不同：对话是即时性的，用户要的是当前这一个问题的答案，不是一篇完整论文。
1.3 i-have-adhd 要解决的问题边界
坦白说，我最初的设想是“做一个 AI 开关，每次回答都强制一句话先说答案”。但实测后发现，硬性“一句话总结”在很多场景下反而有害：有些复杂问题需要先给出结论，再马上给出关键理由，否则用户根本不敢信这个结论。
因此这个项目的目标被修正为：
- 任何回答的前两句内，必须出现用户问题的直接答案（如果问题可答）；
- 结论之后，再按“关键依据 → 次要细节 → 扩展阅读”的层级展开；
- 多轮对话中持续维持这个模式，而不是只在第一轮生效；
- 在用户明确表示“我只要结论”时，进一步压缩次要细节。
说白了，“先说重点”不是“只说重点”，而是在信息结构上做重排，把认知负担最高的部分放到用户的注意力还充足时。
2. 给 AI 立规矩：为什么系统提示词才是“先说重点”的根
2.1 靠对话时反复说“请简短”是治标不治本
很多人试过在提问后面加一句“请简短回答”“不要废话”。实测下来，这种临时指令的稳定性很一般：模型可能这次照做了，下次又忘了；也可能真的变得过于简短，把必要的推理过程也删掉了。原因是这种追加指令属于“对话尾部信息”，它在生成时的约束权重比系统级指令弱，一旦问题本身比较复杂，模型会倾向于恢复默认的长文输出模式。
另一个原因是“简短”这个词太模糊。模型不确切知道“多短算短”，也不知道“重点”指什么。如果你只说“简短点”，它可能会输出四个字“可以，注意线程安全”，然后没有任何依据——这种回答你也不敢用。所以核心策略应该是：在系统提示词里定义好输出结构，而不是每次在用户消息里临时提需求。
2.2 系统提示词的写法：结构约束大于形容词约束
我在 i-have-adhd 项目里用的第一版系统提示词经历过反复迭代，最终稳定下来的核心版本长这样：
你是我的信息助理。你输出的每一条回答，必须遵守以下结构协议： 1. 结论先行：在回答的前两句话内，直接给出当前问题最核心的答案。禁止以背景介绍、概念定义、历史渊源、泛泛的开场白作为回答开头。 2. 分层展开：给出结论后，如果需要进一步说明，按三级组织信息： - 核心依据：支撑这个结论的最关键理由（最多3条）； - 补充细节：边缘背景、使用注意、例外场景等； - 参考与延伸：相关概念、资源、深入阅读方向。 3. 长度适配：除非用户要求“详细展开”，否则省略可被推断的常识性背景，只写与该问题直接相关的信息。 4. 面对无法直接回答的问题时，前两句话内也要先说“我不能确定/无法回答”，再说明原因。这里有个关键的写作技巧：每一条都用“行为+边界+例子”的组合。比如“禁止以背景介绍作为开头”是行为约束，“前两句话内”是边界定义，加上示例片段后模型更容易理解你要的到底是什么。光写“要简洁”没有用，要写“前两句话内给出直接答案”这种可执行的动作描述。
2.3 为什么前两句话是“黄金窗口”
你可能想问：为什么是“前两句话”，不是“第一句”？我在实验中发现，强制“第一句话就是结论”会让模型在回答一些需要限定条件的问题时出错。比如你问“Python 的 GIL 一定会导致多线程无法并行吗”，如果强制第一句给结论，它可能会说“是”——但更准确的回答是“不一定，要看任务类型”。
给出两句话的缓冲后，模型能先做一个简短限定（“要看具体场景”），第二句马上给出实质结论。这既保留了“结论先行”的节奏，又避免了一句话导致的过度简化。
我还用了一个小技巧：在系统提示词最后嵌一个“示例对”：
示例： 问题：什么是死锁？ 不合格回答：死锁是并发编程中一个常见的问题，它指的是多个线程或进程……（开始背景展开） 合格回答：死锁是指多个线程互相等待对方持有的资源，导致程序永久阻塞。举个例子：线程A持有锁1等待锁2，线程B持有锁2等待锁1，两边都不释放，程序就卡死了。这种 Few-shot 示例，比任何形容词都更能锁定模型的输出风格。后面我会专门展开讲它的作用原理。
3. 让“先说重点”从偶然变稳定：参数与结构设计的配合
3.1 温度参数：别让“创意”破坏输出纪律
我曾经以为“先说重点”只需要改提示词就够了，参数不用动。结果在测试开放性问题上翻车了：模型在温度偏高时，会用一些绕来绕去的过渡句开场，比如“这个问题本质上涉及到一个更深层的讨论”。虽然系统提示词禁止了背景开头，但它学会了用“元评论”来绕开约束。
后来我把生成参数里的温度调低（具体值取决于你用的接口，一般从默认的 0.7 往下降到 0.3 左右），输出明显更“听话”了。原理是低温会让模型更倾向于选择概率最高的下一个 token，而违反系统指令的“创意性表述”概率不高，自然就不容易冒出来。这是一个容易被忽略的点：提示词管“方向”，采样参数管“纪律”，两者要配合。
3.2 max_tokens 与输出结构的关系：长度限制不是万能的
另一个踩过的坑是：我最初以为只要把 max_tokens 调小（比如强制限制 100 token），模型自然就会“先说重点”。实际效果是，它确实变短了，但短得莫名其妙：
“关于GIL，它会影响多线程并行。但要看场景。具体涉及很多东西。想了解更多可以问我。”
它没有省略细节，而是把所有细节都压缩成了“泛指词”——这种回答根本没法用。这说明：长度上限只能裁掉“尾部内容”，不能重塑“信息优先级”。真正决定先说什么是你给它的结构协议，而不是长度上限。
所以我的建议是：max_tokens 可以适当调大一点（保证细节层有输出空间），同时用输出格式协议来控制结构。比如在复杂问题场景下，我会在系统提示词里额外加一段：
如果问题需要多个步骤才能回答完整，请先给出最终结论，再列出“关键执行步骤”。 禁止在最终结论出现之前，插入任何逐步推导过程。3.3 “固定骨架”与“自由发挥”的平衡床
我在项目里给系统提示词设计了三种回答模式：短回答、标准回答和详细展开。这三种模式不是靠用户每次临时指定，而是由我问答循环首轮自动判断：问题是否包含“怎么做”“原因”“对比”这类关键词。
| 问题特征 | 默认模式 | 回答结构 |
|---|---|---|
| 事实型疑问（“什么是”“是否”） | 标准回答 | 结论 → 依据 → 例子 |
| 操作型提问（“怎么做”“如何实现”） | 标准回答 | 结论 → 步骤流 → 常见坑 |
| 开放讨论（“怎么看”“为什么值得”） | 详细展开 | 结论 → 多角度依据 → 反面观点 |
| 即时确认（“对吗”“能不能”） | 短回答 | 直接给对错 → 一句话理由 |
这个设计磨合了比较久才顺。最初我试图让模型自动判断“该用哪种”，但判断经常出错，后来改成在用户消息模板里隐式带上模式标签，比如“（回答模式：标准）请解释……”。效果稳定多了。
4. 多轮对话防“复发”：如何维持“先说重点”的习惯不反弹
4.1 问题出在“用户消息模板”上
第 1 轮对话里模型表现很好，每句话都先给结论。但到了第 3、4 轮，尤其用户追问“你能再展开讲讲第一步吗”之后，模型又开始长篇铺垫了。我观察了很久，发现根因是：追问消息里没有附带任何结构约束，模型默认把“展开讲”理解成了“详细地从头讲起”。
解决办法挺朴素：在调用 API 组装对话上下文时，给每条用户消息都贴上同样的协议尾巴：
（提示：即使这是追问，也请遵守“结论先行”协议，前两句话内给出直接回答，再进入细节展开。）每轮都贴，像给模型打了一个持续存在的“结构记忆点”。实测下来，这个简单动作比任何“记忆增强”都有效，因为大语言模型本身没有状态记忆，它靠的是上下文里的所有 token 共同约束输出。只要协议尾巴一直在上下文里，它的约束就一直生效。
4.2 “刚刚不是说过了吗”——递归压实的追问技巧
另一种常见场景是：第 1 轮给了一个标准回答，包含结论、依据、例子；用户觉得还不够，追问“那你说的这个例子里的那个参数，如果设成 0 会怎样”。
如果模型此时重新展开一遍第一轮已经讲过的背景，那就违背了“先说重点”的初衷。我的处理方式是：在追问发送前，程序先把前一轮的回答压缩成一句摘要（用简单的截断或者再调用一次模型做摘要），然后把它和追问语句一起发给模型。
示例：
上一轮回答摘要：线程安全由锁机制保证，核心是在资源访问前加锁、访问后解锁。 用户追问：那锁的粒度设成接口级别会怎么样？这样模型就知道“背景我已经讲过了，不需要再重复”，可以直接进入增量回答。这个“递归压实”的机制在长对话里非常管用：每一轮都只处理新增信息，而旧信息以摘要形式保留锚点。
4.3 防“复发”的兜底：回答后自检钩子
我在项目里还加了一个很容易被忽略的步骤——在拿到模型生成结果后，用一个非常精简的规则做后置校验：
- 结果开头两个字是不是“是的”“不是”“可以”“不可以”“需要”“不需要”“建议”“不建议”等结论触发词；
- 如果开头是“首先”“关于”“说到”“让我们”这类铺垫词，就标记为不合格，自动把这一轮重发一次（在用户消息前额外附上“你上一轮违反了结论先行协议，请重新回答，必须在开头两句话内直接给结论”）。
这些规则本身不需要第二个模型，用少量关键词匹配就能完成。虽然语法上朴素，但作为兜底校验效果很好——它把“提示词工程”和“程序化控制”结合了起来，不再完全依赖模型的自觉。
5. 落地过程里踩过的坑：这些反例可能比正面经验更值钱
5.1 结论过猛，丢了“条件限定”
我第一次把结论先行协议做得非常强硬时，测试了这样一个问题：
“用 Python 写爬虫会被封 IP 吗？”
模型第一句话回答：“会。”第二句话开始解释反爬机制。这个答案从语用上讲是错的——真实情况是“取决于目标网站的防护策略、请求频率、你是否模拟真实浏览器等”。模型为了满足“第一句给结论”的指令，倾向于选一个高概率的短词，抹掉了必要的条件限定。
这就需要在提示词里加一条：
如果问题的真实答案依赖于多个条件，那么在给出结论时，请使用“在……情况下会，在……情况下不会”的句式，而不是强行只给一个绝对词。有条件的结论依然是结论，它只是自带限定范围。这条补丁后来被证明非常重要，它让协议不至于牺牲准确性。
5.2 整个回答变成“三句话”，反而丢了关键证据
另一个极端是：协议把模型“管”得太死，导致它不敢展开细节。有次我测试“为什么说虚拟内存能跑比物理内存大的程序”，它只回答：
“因为虚拟内存允许换页，把不常用的数据放到磁盘上。所以程序可以使用比物理内存更大的地址空间。”
严格来说，这已经是一个合格的“先说重点”回答了，但它漏了一个关键支撑点：进程看到的地址空间和物理内存的关系，以及换页对性能的影响。对于想看结论的人来说够用，但如果用户后续需要根据这个回答做技术决策，它显然不够。
所以我后来引入了一个“证据最低数量”条款：
当你的回答中包含需要被信任的结论时，必须至少给出1条可验证的依据或一个具体例子；如果结论涉及关键技术选型，至少给出2条依据。这等于在“简洁”和“可采纳性”之间画了一条底线：结论先行不代表结论悬浮。
5.3 系统提示词与用户消息中的“临时指令”打架
还有一个场景特别容易翻车：用户自己很喜欢在消息里写“请详细解释一下，最好从头说起”。这时候用户指令的约束方向是“详细展开”，而系统提示词要求“结论先行”。在不少模型上，这会产生“先结论，但马上又从头展开”的混合体，逻辑上很怪。
我的处理是：在系统提示词里显式声明优先级——
如果用户明确要求“从背景开始解释”或“详细展开”，你可以先给出结论提示（例如“先给结论：……”），随后按用户要求从头展开。如果用户明确要求“只要结论”，则删除所有细节层。也就是说，“结论先行”不是永远绝对，而是让用户始终能第一时间抓到主信息，同时保留表达上的灵活性。把这个优先级写清楚之后，指令冲突导致的四不像回答明显减少了。
5.4 医疗、安全类问题，不能只追求“结论快”
做这类提示词项目，有一条红线必须自己画清楚：对于医疗建议、法律建议、危险操作指导，结论先行是危险的。
如果你的系统提示词强制“先给出直接答案”，模型很可能为了讨好这个格式，把“我建议不要自行操作”这种安全回答变成“可以试试，但……”之类的危险内容。所以我在 i-have-adhd 的协议里专门加了一个豁免条款：
如果用户的问题涉及医疗、法律、金融投资、身体安全或任何可能导致人身或财产损失的行为，优先输出风险提示和免责声明，可以不遵守结论先行协议。这不是技术问题，是伦理边界。任何做 AI 提示词工程的人，都应该在动手前把这条款写进去。
6. 可直接复制的基础提示词模板与提示
如果你不想重新造轮子，这里给出一个我项目里最基础的完整模板。它适用于大多数支持系统提示词的对话模型，你可以根据自己的场景微调。
【系统提示词】 你是我的信息助理。你必须遵守以下输出协议： 1. 结论先行：每次回答的第一句话或第二句话内，必须直接给出当前问题的核心答案。 禁止使用“关于这个问题”“首先我们来了解一下”“这是一个经典问题”等铺垫开场。 2. 有条件结论：如果答案依赖具体场景，请使用“在……情况下成立，在……情况下不成立”的句式，不要给出绝对化的单一结论。 3. 分层结构（按需输出）： - 给出结论后，如果还需要支撑信息，按顺序组织：【核心依据】【补充细节】【参考延伸】。 - 不要为了展示知识量而补充无关背景。 4. 长度规范：除非用户明确说“详细展开”，否则所有背景性信息都用1-2句带过，把篇幅留给与问题直接相关的内容。 5. 安全优先：医疗、法律、金融、人身安全类问题，必须优先提示风险与免责声明，可以不受结论先行约束。 6. 当用户追问“展开讲”时，解释性的细节可以从头展开，但在段落开头用黑体或加粗式提示句（如“给结论：……”）写明本轮最终结论。 【用户消息模板】 请回答：{用户问题} （注意：即使这是追问，边界条件或背景不需要重复，请增量回答。如需要重复背景，请先给结论再补充。）这套模板我自己用了很久，实际体验是：模型在绝大多数问题类型下都能稳定做到“前两句话出结论”。如果你接入的是可调参数的 API，记得把温度往低调一些，并且建议把max_tokens控制在能覆盖“结论+依据+细节”的范围，不要过于紧张地压缩长度，否则模型容易把该给的依据挤掉。
最后分享一个题外但很实用的体验：这套“结论先行”协议，后来也被我反向用到了日常阅读和学习中。AI 可以按指令改变输出结构，但人脑不会自动改变接收策略——当我读一篇长文章时，我会用这套思路先去找文章的结论、再看论据、最后才看背景。注意力资源的调度方式，本身就是一种可以被优化的系统设计。i-have-adhd 这个名字可能有点自嘲，但它提醒我的其实是一件很通用的事：信息爆炸时代，每个人都需要“先说重点”的能力——无论是给 AI 下指令，还是给自己定阅读策略。
