「你骂它两句，它就变聪明了。」这个说法在群里传了很久，而且大家都有体感支持——骂完那一轮，回答确实好了。
体感是真的，归因大概错了。
拆开看，你骂的时候通常顺手带进去了一句具体指正。「我问的是苹果公司股价，你给我扯水果」，这半句才是起作用的东西。至于「你真笨」那半句，模型读到的是一串 token，它不会抖三抖。
更麻烦的是纯情绪那一半可能倒扣分。过激辱骂在对齐数据里常跟「用户不满意，模型给短回答或者道歉」这个模式绑在一起，有时候换回来的是拒答或者过度保守。
所以那句话得改一个字：骂在点上有用，而点上那部分跟骂无关。
一、真正起作用的是解空间被你收窄了
具体的指正在语义空间里形成一个高权重标记，逼模型回溯前面的推理路径，定位到出偏差的那一环。「你忽略了第二步的边界条件」这样的话，能让它当轮重新分配注意力。
换个说法更好理解——你在替它缩小可行解空间。具体的纠错信息直接抬高了任务相关那部分 continuation 的概率，采样自然就更集中在你想要的方向上。
所以把「你怎么又错了」换成「第二步的逻辑不对，应该先判断空指针再取值」，它立刻知道边界在哪。同一件事的两种说法，一种给了坐标，一种只给了音量。
顺着这个机制，最省事的做法是把抱怨直接写成验收标准加反例。这比事后纠正更早介入，也不用赌安全侧会不会误判成攻击。
二、「越用越好用」是两套机制叠在一起
这条也有体感支持，也一样容易归错因——它其实是两件事，很多人把它们当成一件。
第一件在当前对话窗口里发生。上下文学习让模型看得见你之前所有的交流，你纠正它，它实时调整。部分模型还会显式存一些关键偏好，比如「我习惯用 TypeScript」，之后的对话自动适配。这一层是当场生效的。
第二件在版本之间发生。你的点赞、点踩、复制、采纳，进厂商的数据池，经过人类反馈强化学习或者 DPO 这类对齐算法，影响下一个版本。典型路径是人类反馈到偏好数据到奖励建模到新模型发布。
对个人来说，第二件是间接的、滞后的、聚合的。你的每一次使用都在为下一代模型投票，但这一代不会当场翻盘。
两层叠在一起就很容易产生因果错觉——当场变好其实来自第一层，而你把它记在了第二层账上。拆开看就清晰了。
三、先复述再写代码，便宜在自回归上
「别一上来就要一整坨代码，先让它用两句话复述改哪里、输入输出是什么、哪些不能动。」这条建议听着像开工前对表的礼节，它的收益其实很硬。
模型的生成是自回归的。前面几个 token 走错分支，后面所有 token 都会沿着错误方向狂奔，而且越写越自洽，越自洽越难看出来。先复述任务，本质上是把走错分支的概率压在最前面那几步。
这一个小动作，能省掉后面大部分「不对不对，我不是这个意思」。结构化的需求还会持续约束后续生成的条件分布，一次对表管很多轮。
同一条道理的另一个用法是要小步。先设计、先写测试、再实现，大改拆成多轮。每一轮的分支都短，走歪了也就歪一小段。
四、写代码的六条
| # | 动作 | 怎么做 | 示例 |
|---|---|---|---|
| 1 | 给边界 | 说清能改什么、不能改什么、用什么版本 | 只能动这个函数内部，接口签名不改，Python 3.10 |
| 2 | 给例子 | 一对「输入 → 期望输出」胜过十句吐槽 | 输入 [1,2,3] 返回 [2,4,6]，不要用循环 |
| 3 | 要小步 | 先设计、先写测试、再实现，大改拆多轮 | 先写这个函数的测试用例，再实现它 |
| 4 | 先复述 | 写代码前让它先确认任务边界 | 你先用两句话复述一下我要你改什么 |
| 5 | 可验证 | 贴终端报错，让它自己跑检查 | 这是报错 KeyError: 'user_id'，帮我定位 |
| 6 | 固定规则 | 项目里写清目录和风格，减少重复说明 | 这个项目用 black 格式化，变量用 snake_case |
六条的共同点是都在给约束，一条比一条更早介入。第 6 条最省事，一次写好，每次生效。
五、收个口
急眼不犯法——你拍桌子、骂两句，只要不砸电脑，没人拦着。
但要是真想少返工，更划算的动作是具体指出错在哪、说清想要什么样。纯情绪对模型没作用，对你的血压有作用。
这件事的机制说到底只有一句话——模型对语义和结构约束敏感，对情绪 token 不敏感。高质量的反馈能压低跑题和幻觉的后验概率，而这才是你体感里「它变聪明了」的主要来源。
你可以骂，骂在点上才值回票价。只给约束不带火气的那种，票价更高。