1. 这周代码大模型圈子里值得细看的三篇论文每周追代码大模型方向的论文，最头疼的不是找不到论文，而是找到的太多、太杂，不知道哪些值得花时间精读。我自己的习惯是每周固定花两三个小时，把主要来源的更新过一遍，筛出三到五篇真正有信息量的，剩下的只扫摘要。这周（0225到0305）的更新里，有几篇在方法设计上确实动了脑筋，不是那种换个数据集刷个点的水文，值得展开聊聊。这篇速递适合两类人看：一类是正在做代码生成、代码补全相关工程落地的开发者，想知道学术界最近在解决什么实际问题；另一类是刚进入这个方向的研究生，需要快速建立对领域当前关注点的判断。我不会逐篇翻译摘要，而是把每篇的核心思路、方法上真正有意思的地方、以及我自己读完之后觉得可以借鉴或者需要警惕的点讲清楚。代码大模型这个方向变化很快，但底层的问题其实就那么几个：怎么让模型理解长距离的代码依赖、怎么处理仓库级别的上下文、怎么在推理效率和生成质量之间找平衡。这周的几篇论文基本都在这几个问题上做文章。2. 仓库级代码理解的新思路：从文件依赖图到分层注意力2.1 为什么仓库级理解一直是个硬骨头单文件代码生成和仓库级代码生成完全是两个难度量级的事情。单文件场景下，模型只需要关注当前文件的语法和局部逻辑，上下文窗口塞个几千token基本够用。但真实开发场景里，一个函数调用可能跨越三四个文件，一个类的继承链可能分布在不同的目录下，更不用说配置文件、接口定义、类型声明这些散落在各处的信息。模型如果只看当前编辑的文件，生成的代码大概率是能跑但接不上现有系统的。这周有一篇论文专门针对这个问题提出了一个基于文件依赖图的分层注意力机制。核心想法不复杂：先把仓库里的文件按照import和调用关系构建成一张有向图，然后让模型在生成代码时，注意力不是均匀地铺在整个上下文窗口上，而是按照依赖图的层级结构来分配。直接依赖的文件获得更高的注意力权重，间接依赖的权重递减。这个思路其实和人在读代码时的行为很像——你改一个函数的时候，会先看它直接调用了谁、谁调用了它，然后才可能去翻更上层的模块。2.2 分层注意力的具体实现和参数选择论文里把依赖图分成了三层：第一层是当前文件的直接导入和直接被导入文件，第二层是这些文件的直接依赖，第三层是更远的传递依赖。注意力权重的分配按照层数递减，具体来说第一层权重设为1.0，第二层0.5，第三层0.25，再远的直接截断不纳入上下文。这个衰减系数的选择论文里做了消融实验，0.5的衰减比0.3和0.7都好，0.3衰减太快导致第二层信息利用不足，0.7衰减太慢导致远距离噪声干扰。上下文窗口的分配也做了调整。传统做法是把所有相关文件拼接成一个长序列喂给模型，但这样会导致真正重要的直接依赖被淹没在大量无关代码里。这篇论文的做法是给每一层分配固定的token预算，第一层占60%，第二层占30%，第三层占10%。如果某一层的文件总token数超过预算，就按照与当前编辑位置的语义相似度排序，取top-K个文件。这个预算分配比例也是实验调出来的，我看了下消融数据，第一层预算低于50%的时候效果下降很明显，说明直接依赖的信息确实是最关键的。注意：这个方法的依赖图构建依赖于静态分析工具，对于动态语言比如Python，import关系在运行时才能完全确定，静态分析会有遗漏。论文里也承认了这一点，他们在Python项目上的提升幅度明显小于Java和TypeScript项目。2.3 实际落地时需要注意的工程细节如果你想把类似思路用到自己的代码补全系统里，有几个工程上的坑需要提前知道。依赖图的构建不是一次性的，代码在编辑过程中依赖关系会变化，你需要一个增量更新的机制。论文里用的是每次编辑后重新计算受影响节点的依赖关系，而不是全量重建图，这个在工程上是必须的，否则每次编辑都全量分析一遍仓库，延迟根本扛不住。另外就是缓存策略。直接依赖的文件内容变化频率其实不高，你可以把第一层文件的编码结果缓存起来，只对发生变化的文件重新编码。论文里没有详细讲这部分，但从我自己的工程经验来看，不做缓存的话推理延迟会增加三到五倍，完全不可接受。缓存失效的策略可以简单一点，按照文件的修改时间戳来判断，文件没变就直接复用之前的编码结果。3. 代码生成中的推理效率优化：投机解码在代码场景的适配3.1 投机解码为什么在代码生成里特别有搞头投机解码（Speculative Decoding）这两年在通用文本生成里已经比较成熟了，核心思路是用一个小模型快速生成多个候选token，然后让大模型一次性验证这些候选，验证通过的直接采纳，不通过的再回退到大模型重新生成。这样做的收益来自于大模型验证多个token的成本远低于逐个生成token的成本。代码生成场景下这个方法的收益比通用文本更大，原因有两个。第一，代码的局部确定性很强，比如你写了def calculate_，后面大概率是sum、average、total这几个词之一，小模型猜中的概率很高。第二，代码里有大量模板化的结构，比如try-except块、for循环、if-else分支，这些结构的token序列非常固定，小模型很容易预测准确。这周有一篇论文专门研究了投机解码在代码生成场景下的适配问题，提出了一些针对性的改进。3.2 草稿模型的选择和训练策略论文里对比了几种草稿模型的方案：直接用一个小号的语言模型、用代码专用的小模型、以及在目标模型上做蒸馏得到的小模型。结论是代码专用的小模型效果最好，接受率比通用小模型高了将近15个百分点。这个结论其实不意外，代码的分布和自然语言差别很大，通用小模型在代码上的预测能力本身就弱一截。草稿模型的规模选择也有讲究。论文里测试了从100M到1B参数范围的草稿模型，发现300M到500M是一个比较甜的区间。太小的模型接受率低，投机解码的收益被抵消；太大的模型虽然接受率高，但验证成本也上去了，整体加速比反而下降。具体来说，300M的草稿模型在HumanEval上达到了2.3倍的加速比，500M的是2.1倍，1B的降到了1.7倍。这个数据是在A100上测的，不同硬件上最优的草稿模型大小可能会有差异。3.3 代码场景下的验证策略调整通用投机解码的验证策略是逐个token验证，但代码场景下可以做更粗粒度的验证。论文提出了一种基于语法结构的验证方法：先把草稿模型生成的token序列按照代码的语法结构切分成块，比如一个完整的表达式、一个语句、一个代码块，然后以块为单位进行验证。这样做的好处是减少了验证次数，因为大模型一次前向传播可以验证多个token，按块验证比按token验证的效率更高。但这个方法有个前提，你需要一个轻量级的语法分析器来实时切分草稿模型的输出。论文里用的是基于规则的分词加括号匹配，对于大多数编程语言来说够用了。不过对于语法比较灵活的语言比如JavaScript，括号匹配有时候会出错，论文里也提到了这个问题，他们的解决方案是加了一个回退机制，语法分析失败的时候就退回到逐token验证。验证策略加速比接受率适用场景逐token验证1.8x72%通用，稳定按语句验证2.3x68%语法结构清晰的语言按代码块验证2.1x61%缩进严格的语言混合策略2.4x70%需要额外语法分析器实操心得：如果你在自己的代码补全服务里用投机解码，建议先从逐token验证开始，稳定之后再尝试按语句验证。按代码块验证的收益提升有限，但引入的复杂度不低，性价比一般。4. 代码审查场景的自动化：从缺陷检测到修复建议生成4.1 代码审查自动化的真实需求是什么代码审查自动化这个方向其实做了很多年了，但之前的方案大多是基于规则的静态分析，能查出来的问题类型有限，而且误报率很高。这周有一篇论文用大模型来做代码审查，思路和传统方案不太一样：不是去匹配预定义的缺陷模式，而是让模型理解代码的意图，然后判断实现是否符合意图。这个思路的转变很关键。传统的静态分析工具能查出空指针引用、资源泄漏这类模式化的问题，但对于逻辑错误、边界条件处理不当、并发安全问题这类需要理解代码意图的缺陷，基本无能为力。而大模型恰恰擅长理解意图，所以这个方向是有搞头的。论文里把代码审查任务拆成了三步：先让模型总结代码的功能意图，然后让模型找出实现和意图不一致的地方，最后针对每个不一致生成修复建议。4.2 三步走的具体实现和prompt设计第一步的意图总结，论文里用的prompt模板大致是让模型用自然语言描述这段代码做了什么、输入输出是什么、有哪些边界条件需要处理。这一步的输出质量直接影响后续两步的效果，所以论文里在prompt里加了一些约束，比如要求模型必须列出所有的输入参数和返回值，必须说明每个分支条件的含义。第二步的不一致检测，核心是让模型对比意图描述和实际实现。论文里用了一个比较巧妙的做法：让模型分别从意图和实现两个角度生成测试用例，然后对比两组测试用例的差异。如果意图角度的测试用例在实现上跑不通，那就说明实现和意图不一致。这个方法比直接让模型判断“这段代码有没有bug”要可靠得多，因为直接判断很容易受模型幻觉影响。第三步的修复建议生成，论文里强调了修复建议必须包含具体的代码修改，而不是只给一个方向性的描述。比如不能只说“需要增加空值检查”，而要给出具体的代码片段，说明在哪一行加什么检查。这个要求对模型的代码生成能力要求比较高，论文里用的是经过代码审查数据微调过的模型，在修复建议的准确率上比通用模型高了20多个百分点。4.3 实际使用中的误报和漏报分析论文里报告的数据是在一个内部数据集上测的，精确率大概在65%左右，召回率在58%左右。这个数据说实话不算特别亮眼，但考虑到代码审查本身就是一个主观性很强的任务，不同审查者对同一个问题的判断都可能不一致，这个数据已经有一定实用价值了。误报的主要来源是模型对业务逻辑的理解偏差。比如有一段代码看起来像是漏了错误处理，但实际上调用方已经保证了不会出错，模型不知道这个上下文就会误报。漏报的主要来源是模型对某些编程语言特性的理解不够深入，比如C++里的移动语义、Rust里的生命周期标注，这些特性相关的缺陷模型很难识别出来。注意：如果你打算把这类工具引入到团队的代码审查流程里，建议先作为辅助工具使用，不要直接作为合并代码的门禁。让模型给出建议，由人来判断是否采纳，这样既能利用模型的效率，又能避免误报导致的阻塞。5. 这周论文里反复出现的一个信号：上下文管理比模型规模更重要5.1 从三篇论文看当前的技术共识把这周的三篇论文放在一起看，会发现一个共同点：它们都没有去卷模型规模，而是在上下文管理、推理效率、任务分解这些工程层面的问题上做优化。仓库级理解那篇的核心是依赖图引导的注意力分配，投机解码那篇的核心是草稿模型和验证策略的适配，代码审查那篇的核心是任务分解和prompt设计。这些工作的共同前提是：底层模型的代码能力已经到了一定水平，现在的瓶颈不在于模型能不能写出正确的代码，而在于模型能不能在正确的上下文中写出正确的代码。这个信号其实挺重要的。过去两年大家一直在追更大的模型、更多的训练数据，但现在来看，至少在代码生成这个方向上，模型规模的边际收益在递减。一个7B的代码模型在HumanEval上的表现已经能到70%以上，再往上堆规模，提升幅度有限，但推理成本是线性增长的。反而是上下文管理做得好不好，对实际效果的影响更大。5.2 对工程落地的启示如果你在做代码大模型的工程落地，这周的论文给了一个很明确的信号：不要在模型选型上纠结太久，选一个中等规模、代码能力过关的模型就行，把精力花在上下文构建和推理优化上。具体来说，仓库级的依赖分析、编辑历史的利用、相关代码片段的检索和排序，这些工程层面的工作对最终效果的贡献可能比换一个更大的模型要大得多。另外就是推理效率的优化要尽早做。代码补全是一个交互式场景，用户对延迟非常敏感，超过500毫秒的延迟就会明显影响使用体验。投机解码、KV缓存复用、增量编码这些技术，能早做就早做，不要等到模型上线了再回头优化，那时候改造成本会高很多。5.3 下周值得关注的方向从这周的论文趋势来看，接下来值得关注的方向有几个。一个是多文件编辑的连贯性，现在大部分工作还是聚焦在单文件生成上，但真实开发场景里一次修改往往涉及多个文件，怎么保证跨文件修改的一致性是个还没被很好解决的问题。另一个是代码审查和代码生成的结合，让模型在生成代码的同时就考虑到审查环节可能提出的问题，从源头上减少缺陷。还有一个是推理效率的进一步优化，特别是针对长上下文场景的KV缓存压缩，这个在仓库级代码理解里会越来越重要。我自己这周读下来，最大的收获是重新审视了上下文管理在代码大模型里的位置。以前总觉得模型能力是决定性的，现在越来越觉得，在模型能力达到一定水平之后，怎么给模型提供正确的上下文、怎么让模型高效地利用上下文，才是真正拉开差距的地方。下周继续追，有新发现再聊。
1. 这周代码大模型圈子里值得细看的三篇论文每周追代码大模型方向的论文，最头疼的不是找不到论文，而是找到的太多、太杂，不知道哪些值得花时间精读。我自己的习惯是每周固定花两三个小时，把主要来源的更新过一遍，筛出三到五篇真正有信息量的，剩下的只扫摘要。这周（0225到0305）的更新里，有几篇在方法设计上确实动了脑筋，不是那种换个数据集刷个点的水文，值得展开聊聊。这篇速递适合两类人看：一类是正在做代码生成、代码补全相关工程落地的开发者，想知道学术界最近在解决什么实际问题；另一类是刚进入这个方向的研究生，需要快速建立对领域当前关注点的判断。我不会逐篇翻译摘要，而是把每篇的核心思路、方法上真正有意思的地方、以及我自己读完之后觉得可以借鉴或者需要警惕的点讲清楚。代码大模型这个方向变化很快，但底层的问题其实就那么几个：怎么让模型理解长距离的代码依赖、怎么处理仓库级别的上下文、怎么在推理效率和生成质量之间找平衡。这周的几篇论文基本都在这几个问题上做文章。2. 仓库级代码理解的新思路：从文件依赖图到分层注意力2.1 为什么仓库级理解一直是个硬骨头单文件代码生成和仓库级代码生成完全是两个难度量级的事情。单文件场景下，模型只需要关注当前文件的语法和局部逻辑，上下文窗口塞个几千token基本够用。但真实开发场景里，一个函数调用可能跨越三四个文件，一个类的继承链可能分布在不同的目录下，更不用说配置文件、接口定义、类型声明这些散落在各处的信息。模型如果只看当前编辑的文件，生成的代码大概率是能跑但接不上现有系统的。这周有一篇论文专门针对这个问题提出了一个基于文件依赖图的分层注意力机制。核心想法不复杂：先把仓库里的文件按照import和调用关系构建成一张有向图，然后让模型在生成代码时，注意力不是均匀地铺在整个上下文窗口上，而是按照依赖图的层级结构来分配。直接依赖的文件获得更高的注意力权重，间接依赖的权重递减。这个思路其实和人在读代码时的行为很像——你改一个函数的时候，会先看它直接调用了谁、谁调用了它，然后才可能去翻更上层的模块。2.2 分层注意力的具体实现和参数选择论文里把依赖图分成了三层：第一层是当前文件的直接导入和直接被导入文件，第二层是这些文件的直接依赖，第三层是更远的传递依赖。注意力权重的分配按照层数递减，具体来说第一层权重设为1.0，第二层0.5，第三层0.25，再远的直接截断不纳入上下文。这个衰减系数的选择论文里做了消融实验，0.5的衰减比0.3和0.7都好，0.3衰减太快导致第二层信息利用不足，0.7衰减太慢导致远距离噪声干扰。上下文窗口的分配也做了调整。传统做法是把所有相关文件拼接成一个长序列喂给模型，但这样会导致真正重要的直接依赖被淹没在大量无关代码里。这篇论文的做法是给每一层分配固定的token预算，第一层占60%，第二层占30%，第三层占10%。如果某一层的文件总token数超过预算，就按照与当前编辑位置的语义相似度排序，取top-K个文件。这个预算分配比例也是实验调出来的，我看了下消融数据，第一层预算低于50%的时候效果下降很明显，说明直接依赖的信息确实是最关键的。注意：这个方法的依赖图构建依赖于静态分析工具，对于动态语言比如Python，import关系在运行时才能完全确定，静态分析会有遗漏。论文里也承认了这一点，他们在Python项目上的提升幅度明显小于Java和TypeScript项目。2.3 实际落地时需要注意的工程细节如果你想把类似思路用到自己的代码补全系统里，有几个工程上的坑需要提前知道。依赖图的构建不是一次性的，代码在编辑过程中依赖关系会变化，你需要一个增量更新的机制。论文里用的是每次编辑后重新计算受影响节点的依赖关系，而不是全量重建图，这个在工程上是必须的，否则每次编辑都全量分析一遍仓库，延迟根本扛不住。另外就是缓存策略。直接依赖的文件内容变化频率其实不高，你可以把第一层文件的编码结果缓存起来，只对发生变化的文件重新编码。论文里没有详细讲这部分，但从我自己的工程经验来看，不做缓存的话推理延迟会增加三到五倍，完全不可接受。缓存失效的策略可以简单一点，按照文件的修改时间戳来判断，文件没变就直接复用之前的编码结果。3. 代码生成中的推理效率优化：投机解码在代码场景的适配3.1 投机解码为什么在代码生成里特别有搞头投机解码（Speculative Decoding）这两年在通用文本生成里已经比较成熟了，核心思路是用一个小模型快速生成多个候选token，然后让大模型一次性验证这些候选，验证通过的直接采纳，不通过的再回退到大模型重新生成。这样做的收益来自于大模型验证多个token的成本远低于逐个生成token的成本。代码生成场景下这个方法的收益比通用文本更大，原因有两个。第一，代码的局部确定性很强，比如你写了def calculate_，后面大概率是sum、average、total这几个词之一，小模型猜中的概率很高。第二，代码里有大量模板化的结构，比如try-except块、for循环、if-else分支，这些结构的token序列非常固定，小模型很容易预测准确。这周有一篇论文专门研究了投机解码在代码生成场景下的适配问题，提出了一些针对性的改进。3.2 草稿模型的选择和训练策略论文里对比了几种草稿模型的方案：直接用一个小号的语言模型、用代码专用的小模型、以及在目标模型上做蒸馏得到的小模型。结论是代码专用的小模型效果最好，接受率比通用小模型高了将近15个百分点。这个结论其实不意外，代码的分布和自然语言差别很大，通用小模型在代码上的预测能力本身就弱一截。草稿模型的规模选择也有讲究。论文里测试了从100M到1B参数范围的草稿模型，发现300M到500M是一个比较甜的区间。太小的模型接受率低，投机解码的收益被抵消；太大的模型虽然接受率高，但验证成本也上去了，整体加速比反而下降。具体来说，300M的草稿模型在HumanEval上达到了2.3倍的加速比，500M的是2.1倍，1B的降到了1.7倍。这个数据是在A100上测的，不同硬件上最优的草稿模型大小可能会有差异。3.3 代码场景下的验证策略调整通用投机解码的验证策略是逐个token验证，但代码场景下可以做更粗粒度的验证。论文提出了一种基于语法结构的验证方法：先把草稿模型生成的token序列按照代码的语法结构切分成块，比如一个完整的表达式、一个语句、一个代码块，然后以块为单位进行验证。这样做的好处是减少了验证次数，因为大模型一次前向传播可以验证多个token，按块验证比按token验证的效率更高。但这个方法有个前提，你需要一个轻量级的语法分析器来实时切分草稿模型的输出。论文里用的是基于规则的分词加括号匹配，对于大多数编程语言来说够用了。不过对于语法比较灵活的语言比如JavaScript，括号匹配有时候会出错，论文里也提到了这个问题，他们的解决方案是加了一个回退机制，语法分析失败的时候就退回到逐token验证。验证策略加速比接受率适用场景逐token验证1.8x72%通用，稳定按语句验证2.3x68%语法结构清晰的语言按代码块验证2.1x61%缩进严格的语言混合策略2.4x70%需要额外语法分析器实操心得：如果你在自己的代码补全服务里用投机解码，建议先从逐token验证开始，稳定之后再尝试按语句验证。按代码块验证的收益提升有限，但引入的复杂度不低，性价比一般。4. 代码审查场景的自动化：从缺陷检测到修复建议生成4.1 代码审查自动化的真实需求是什么代码审查自动化这个方向其实做了很多年了，但之前的方案大多是基于规则的静态分析，能查出来的问题类型有限，而且误报率很高。这周有一篇论文用大模型来做代码审查，思路和传统方案不太一样：不是去匹配预定义的缺陷模式，而是让模型理解代码的意图，然后判断实现是否符合意图。这个思路的转变很关键。传统的静态分析工具能查出空指针引用、资源泄漏这类模式化的问题，但对于逻辑错误、边界条件处理不当、并发安全问题这类需要理解代码意图的缺陷，基本无能为力。而大模型恰恰擅长理解意图，所以这个方向是有搞头的。论文里把代码审查任务拆成了三步：先让模型总结代码的功能意图，然后让模型找出实现和意图不一致的地方，最后针对每个不一致生成修复建议。4.2 三步走的具体实现和prompt设计第一步的意图总结，论文里用的prompt模板大致是让模型用自然语言描述这段代码做了什么、输入输出是什么、有哪些边界条件需要处理。这一步的输出质量直接影响后续两步的效果，所以论文里在prompt里加了一些约束，比如要求模型必须列出所有的输入参数和返回值，必须说明每个分支条件的含义。第二步的不一致检测，核心是让模型对比意图描述和实际实现。论文里用了一个比较巧妙的做法：让模型分别从意图和实现两个角度生成测试用例，然后对比两组测试用例的差异。如果意图角度的测试用例在实现上跑不通，那就说明实现和意图不一致。这个方法比直接让模型判断“这段代码有没有bug”要可靠得多，因为直接判断很容易受模型幻觉影响。第三步的修复建议生成，论文里强调了修复建议必须包含具体的代码修改，而不是只给一个方向性的描述。比如不能只说“需要增加空值检查”，而要给出具体的代码片段，说明在哪一行加什么检查。这个要求对模型的代码生成能力要求比较高，论文里用的是经过代码审查数据微调过的模型，在修复建议的准确率上比通用模型高了20多个百分点。4.3 实际使用中的误报和漏报分析论文里报告的数据是在一个内部数据集上测的，精确率大概在65%左右，召回率在58%左右。这个数据说实话不算特别亮眼，但考虑到代码审查本身就是一个主观性很强的任务，不同审查者对同一个问题的判断都可能不一致，这个数据已经有一定实用价值了。误报的主要来源是模型对业务逻辑的理解偏差。比如有一段代码看起来像是漏了错误处理，但实际上调用方已经保证了不会出错，模型不知道这个上下文就会误报。漏报的主要来源是模型对某些编程语言特性的理解不够深入，比如C++里的移动语义、Rust里的生命周期标注，这些特性相关的缺陷模型很难识别出来。注意：如果你打算把这类工具引入到团队的代码审查流程里，建议先作为辅助工具使用，不要直接作为合并代码的门禁。让模型给出建议，由人来判断是否采纳，这样既能利用模型的效率，又能避免误报导致的阻塞。5. 这周论文里反复出现的一个信号：上下文管理比模型规模更重要5.1 从三篇论文看当前的技术共识把这周的三篇论文放在一起看，会发现一个共同点：它们都没有去卷模型规模，而是在上下文管理、推理效率、任务分解这些工程层面的问题上做优化。仓库级理解那篇的核心是依赖图引导的注意力分配，投机解码那篇的核心是草稿模型和验证策略的适配，代码审查那篇的核心是任务分解和prompt设计。这些工作的共同前提是：底层模型的代码能力已经到了一定水平，现在的瓶颈不在于模型能不能写出正确的代码，而在于模型能不能在正确的上下文中写出正确的代码。这个信号其实挺重要的。过去两年大家一直在追更大的模型、更多的训练数据，但现在来看，至少在代码生成这个方向上，模型规模的边际收益在递减。一个7B的代码模型在HumanEval上的表现已经能到70%以上，再往上堆规模，提升幅度有限，但推理成本是线性增长的。反而是上下文管理做得好不好，对实际效果的影响更大。5.2 对工程落地的启示如果你在做代码大模型的工程落地，这周的论文给了一个很明确的信号：不要在模型选型上纠结太久，选一个中等规模、代码能力过关的模型就行，把精力花在上下文构建和推理优化上。具体来说，仓库级的依赖分析、编辑历史的利用、相关代码片段的检索和排序，这些工程层面的工作对最终效果的贡献可能比换一个更大的模型要大得多。另外就是推理效率的优化要尽早做。代码补全是一个交互式场景，用户对延迟非常敏感，超过500毫秒的延迟就会明显影响使用体验。投机解码、KV缓存复用、增量编码这些技术，能早做就早做，不要等到模型上线了再回头优化，那时候改造成本会高很多。5.3 下周值得关注的方向从这周的论文趋势来看，接下来值得关注的方向有几个。一个是多文件编辑的连贯性，现在大部分工作还是聚焦在单文件生成上，但真实开发场景里一次修改往往涉及多个文件，怎么保证跨文件修改的一致性是个还没被很好解决的问题。另一个是代码审查和代码生成的结合，让模型在生成代码的同时就考虑到审查环节可能提出的问题，从源头上减少缺陷。还有一个是推理效率的进一步优化，特别是针对长上下文场景的KV缓存压缩，这个在仓库级代码理解里会越来越重要。我自己这周读下来，最大的收获是重新审视了上下文管理在代码大模型里的位置。以前总觉得模型能力是决定性的，现在越来越觉得，在模型能力达到一定水平之后，怎么给模型提供正确的上下文、怎么让模型高效地利用上下文，才是真正拉开差距的地方。下周继续追，有新发现再聊。