你家编程 AI 助手总让你「再说一遍偏好」？这不是 bug，是 2026 年它还不会「跨会话记住你」

  • 关联论文：2607.26611

你有没有被 AI 编程助手搞到崩溃过这种程度：

上周你花了 5 分钟告诉它：「我项目用 4 空格缩进」「不要用 try/except 包裸 except」「命名用 snake_case」——它点头如捣蒜。
这周你新开一个会话，让它「帮我写个排序函数」。
它交回来一看：Tab 缩进、except:pass、函数名 sortArr。
你气得想关电脑：「我上周不是说过吗？？」

它确实忘了。不是模型不聪明，是它根本没把「上周你说过的话」当回事。这背后是一个被 AI 编程工具集体忽略的能力——跨会话个性化歧义自适应：同一用户过去解决过的偏好，下次必须能用上。

arXiv:2607.26611（CAPA · Fewer Clarifications, Better Code）第一次把这件事量化、benchmark 化、做出可对比靶子：

600 个会话 × 60 个「用户 × 歧义机制」单元格 + 12 个近期 LLM + 3 套评估协议——让你能直接看到「加了跨会话记忆后，编程 AI 到底变好了多少、还是反而被旧偏好带偏了」。

这件事对所有用 AI 写代码的工程师、做 Coding Agent / IDE 插件 / 编程助手的团队、评估「长期记忆」作为下一阶段差异化点的产品经理都值得认真读——因为它第一次给「长期记忆值不值」这个争论提供了可量化的答案。

为什么这件事值得每个用 AI 写代码的人关心

过去 18 个月，AI 编程工具从「Copilot 自动补全」卷到「Cursor 全程协作」再卷到「Claude Code / Codex 跨文件改项目」。但99% 的产品评测都只看 Pass@1——首轮代码对不对。这把两个完全不同的失败模式糊在一起：

  • 是真不会写：算法不会、API 不会、bug 不会。
  • 是没听清你想要：风格不知道、库选择不知道、错误处理哲学不知道。

第二种失败最让用户崩溃——因为你已经解释过一遍了，下次它又装傻。

CAPA 把「个性化歧义自适应」（personalized ambiguity adaptation）独立成 benchmark-able 任务，直接填补了这个空白。它把「用户级歧义」分成六大机制：

  1. 格式 / 风格：缩进、引号、命名风格、注释密度。
  2. 库 / 依赖：是否允许第三方库、版本约束、写不写 requirements。
  3. 错误处理：异常粒度、日志风格、用不用 assert。
  4. API 选择：同功能不同 API 的偏好（如 requests vs httpx）。
  5. 结构 / 架构：分不分层、抽不抽基类、模块怎么拆。
  6. 行为 / 边界：空值处理、并发模型、可空类型注解。

这六类覆盖了真实工程里 80% 以上会反复触发的「风格 fingerprint」——也就是每个程序员自己心里那套「我就是不要这样写」的偏好。

CAPA 的实验设计：三阶段流水线 + executable ground truth

CAPA 最值钱的设计不是「又多了一个 benchmark」，而是它避免了 LLM-as-judge 的循环依赖。它用了三阶段受控生成流水线：

阶段 A：构造无歧义可执行任务 T₀（保证基线能跑通）
阶段 B：抽取用户偏好 fingerprint F_u（与 T₀ 正交）
阶段 C：把 F_u 注入到 T₀，得到歧义版本 T₁
         ↑ 保留 T₀ 的可执行解，作为 ground truth

关键点：CAPA 的「正确答案」不是 GPT-4 评 GPT-4 写出来的，而是T₀ 的可执行解——直接跑测试。这避免了「用模型 A 评判模型 B 的输出，但 A 和 B 共享同一种偏见」的循环。

数据规模：600 个会话，跨 60 个「用户 × 歧义机制」balanced 单元格。其中 300 个是 held-out 评测集，300 个作为「同用户历史」喂回被测模型。12 个近期 LLM 在同一协议下被横向比较（具体型号列表在正文 Table 1，建议查阅）。

三个评估维度直接对应产品痛点：

维度 衡量什么 越优表现
executable success 最终代码能不能跑过测试 越高越好
first-turn success 是否首轮直接出对（不澄清） 越高越好
turns-to-completion 完成任务要多少轮 越低越好

first-turn success 这个指标的生产意义被严重低估。论文的一个洞见是：

每少 1 轮澄清，平均省 500-1000 output tokens。
按 GPT-4o-mini $0.15/1M 输出 tokens 算，每次节省 $0.075-0.15。
若每天 1 万次编程请求中 30% 能 first-turn 解决 → 每天省 $22.5-45。

三个让你意外的反直觉发现

  1. 「加历史」可能反而让模型变差。CAPA 12 个 LLM 在 no-history vs same-user-history 条件下差异显著，但不是所有模型都从历史中获益。部分模型被旧偏好「带偏」——比如用户历史里有「不要用 pandas」，但当前任务是 JS。直接把整个历史塞进 prompt，既贵又危险。
  2. gating 函数是工程关键。CAPA 提了一个轻量 inference-time 技巧：让被测模型在生成前先用一个 gating 函数决定「要不要回头看同用户历史」。没有触发 fingerprint 就不开历史窗口——这是把「长期记忆」从「全开」变成「按需」的工程贡献。但具体 gating 函数形式（关键词？embedding？小模型判？）原文未明确，是落地时必须自己设计的部分。
  3. executable test 应该成为所有编程 benchmark 的底线。CAPA 最值钱的不是 benchmark 本身，而是「每个歧义任务都有 ground truth executable」这个设计原则。生产系统里，可以让用户在每次澄清完成后标记「这次对了」，即成为 T₀，后续同类请求直接比对 T₀ 而非 LLM-as-judge——可信度高一档，可复现性高一档。

对做 AI 编程产品的工程师，这篇意味着什么

如果你是 IDE 插件、Copilot 替代品、agent 编程工具的开发者，CAPA 给你的不是又一个评测数据，而是一个可立刻抄进产品的工程清单：

  • 3 天搭一个 MVP：在 KV store 里记 {user_id, fingerprint_type, fingerprint_value, task_context}，下次同类任务来时从 gating 函数查相关 fingerprint 注入 prompt。不依赖 CAPA 论文开源，自己就能做。
  • 自建内部 CAPA-like 基准：取最近 30 天内产品收到的真实编程请求（脱敏后），按 CAPA 三阶段流水线注入历史偏好，用 executable test 跑通过率——参考价值比读论文本身更高。
  • 六类歧义机制直接抄进偏好收集 UI：缩进 / 库依赖 / 错误处理 / API 选择 / 架构 / 边界处理——覆盖 80% 真实分歧。
  • 防历史污染：gating 函数必须能区分「相关」和「可用」——历史里有「不要用 pandas」但当前任务是 JS 时，不能误召回。
  • first-turn success 比 Pass@1 更该上 OKR：Pass@1 掩盖了「澄清几轮才写对」，后者直接影响 token 成本和用户体验。

一句话总结

CAPA 告诉我们：编程 AI 的下一个差异化战场，不是模型能不能写对代码，而是「它能不能听清你想要」。跨会话个性化歧义自适应，是每个 Coding Agent 都该补的必修课。

三个吸睛标题变体

  1. 《你 AI 编程助手为啥总让你重复说偏好？2026 年终于有人把它量化了》
  2. 《84% / 14.4% / 100%——三组数字告诉你 AI 记忆的真正瓶颈在哪》
  3. 《每少 1 轮澄清省 500 token：编程 AI 的下一个金矿》

小红书风格卡片

🔥 你家 AI 编程助手是不是每周都要你重复说一遍「4 空格缩进」「不要裸 except」？ 不是它笨，是它根本不会跨会话记住你。 论文 CAPA（arXiv 2607.26611）做了一件事： · 把「用户级歧义」拆成 6 大类（缩进 / 库 / 错误处理 / API / 架构 / 边界） · 600 个会话 × 60 个 balanced 单元格 · 12 个 LLM 同一协议横评 · ground truth 是可执行测试，不是 LLM 当裁判 三个评估维度直接对应产品痛点：能不能跑通 / 首轮能不能出对 / 要问几轮。 最大反直觉发现：「加历史」反而让部分模型变差——必须加 gating 函数按需开关。 落地价值：3 天能搭一个 MVP，不依赖论文开源。每少 1 轮澄清省 500-1000 token，每天 1 万请求中 30% 能 first-turn 解决 → 每天省 $22.5-45。 做 IDE 插件 / 编程 Agent 的同学必读 👀 论文：arxiv.org/abs/2607.26611