夜雨聆风
注：这个课程是24年的，比较早了，不过可以了解下代码提示的原理。看看上图，估计其他没必要看。
AI发展真快，在24年的时候SWE-bench 分数也就20-30分，现在已经90了。
以下是内容：
引言：代码补全远比你想象的复杂
你有没有过这种体验——AI代码补全写了两行之后完全停不下来，刷刷刷给你补出一整段根本不需要的代码，你只能狂按撤销。
或者更糟的：你已经写完了当前代码块，光标下一个位置应该是空的，AI 却「热心」地给你塞了一行完全不该存在的东西。
这真不是 AI 蠢。这是模型在训练时没学过「适可而止」。
一、代码补全，远不止「猜下一个字」
1.1 日常编程最痛的两件事
1.重复性代码——getter/setter、模板代码，写着写着就怀疑人生
2.查资料切窗口——切到浏览器查 API 文档，再切回来已经忘了刚才写到哪了
通义灵码要解决的就是这两件事。但背后的技术挑战远比想象中大：
1.2 两大核心挑战
•多语言多框架：Java/Python/Go/前端，每个生态都有各自的框架规范和三方包。模型需要同时掌握多个语言世界
•上下文极其复杂：补全一行代码可能需要跨文件理解类定义、函数签名、三方包版本特性。不是只看当前文件的上下文就够了
这就是为什么简单的「Next-Token Prediction」（预测下一个 token）远远不够。代码补全和写文章不一样——补全发生在代码中间，你需要同时看上文和下文。
1.3 关键洞察：Fill-in-Middle 训练
普通的语言模型训练是「给前半句，猜后半句」。但代码补全是「给前后文，猜中间缺了什么」。这是两种完全不同的能力。
通义灵码的做法是：在训练阶段就引入 Fill-in-Middle 机制，让模型学着在已知上文和下文的条件下填补中间。这是代码补全模型和通用语言模型最本质的区别。
二、让模型「看懂」整个项目
代码补全的更高境界不是「补一行代码」，而是「理解你整个项目在干什么」。
2.1 当前已具备的四大感知能力
•补全位置可感知：光标在类定义里？在循环里？在函数参数里？模型知道
•项目调用文件可感知：当前文件 import 了哪些类，它们的方法签名是什么
•相似代码可感知：项目中是否有风格类似的代码模式可供参考
•三方包依赖可感知：你用了什么库，API 长什么样
2.2 未来将补齐的两种能力
•数据结构可感知：类对象的字段和方法全貌
•执行环境可感知：项目已安装了哪些包、什么版本
2.3 RAG 在代码场景的独特之处
很多人以为 RAG 就是「文档问答里的向量检索」，但代码场景下的 RAG 完全不同：
代码 RAG 的本质是「代码搜代码」，不是「自然语言搜自然语言」。
举个例子：你在写 `dwc_report.getXxx()`，模型需要知道 `dwc_report.java` 里到底定义了哪些 getter 方法。如果只是泛泛地检索文档，一定会产生幻觉。
通义灵码的做法：
1.项目结构化解析 + 数据分块（按类/函数粒度切分）
2.对代码做 embedding 向量化
3.取光标附近的代码作为 query → 向量库检索 → 返回多条相似代码拼入 prompt
4.模型需要「双能力配合」——既会检索，又会参考检索结果生成代码
三、为什么要重新定义「好补全」？——CodeDevBench 评测集
聊完训练方法，下一个问题自然就是：怎么评估一个代码补全模型好不好？
现有的评测集（HumanEval、MBPP 等）都是基于「函数签名 → 生成函数体」的模式——这其实只是补全场景的一个极小子集。
3.1 真实补全的丰富程度远超想象
现实中的补全场景至少包括：
•补完整代码块（for/if/函数体）
•补单行或多行
•行中间补全（光标在一行中间，前后都有内容）
•补空——光标处代码已写完，模型应该预测为空
最后一种尤其重要。很多模型就是败在「不知道什么时候该闭嘴」上。
3.2 CodeDevBench 三大设计亮点
特点 | 说明 |
真实业务驱动 | 从近期高 star GitHub 仓库中抓取，覆盖真实业务代码 |
场景丰富 | 基于 AST 解析识别 for/if/函数/单行等结构，构建多元补全场景 |
单测通过率评估 | 爬取带单元测试的仓库，自动装环境跑单测，比「相似度计算」客观得多 |
而且这套评测器已经开源了（arXiv / GitHub / HuggingFace），任何人都可以去跑自己的模型。
3.3 评测发现的两个模型通病
第一，生成停不下来——写完两行又往下写一堆，用户体验极差。
第二，错误跨越代码块——当前代码块已经写完了，模型还继续往下一行补，应该预测为空。
这两个问题不是通义灵码独有的，而是整个代码大模型领域都面临的问题。
四、AI 程序员：不只是补全，而是端到端开发
如果说代码补全是「辅助驾驶」，AI 程序员就是「代驾」——你给一个 GitHub Issue 链接或自然语言需求，它直接从拉代码到推 diff 全包了。
4.1 完整流程
用户提需求 → 拉取项目 → 需求理解 → 任务拆解 → 探索定位待改代码 → 决定改法 → 生成 diff → 用户审阅 → push
关键设计：计划可由用户编辑修改，强调人机协同，不是 AI 一言堂。
4.2 核心技术：Lingma-SWE-GPT
这是通义灵码团队开源的一个模型，专门用于 AI 编程的端到端任务。训练数据是 GitHub 仓库的 Issue-PR-代码修改三元组，执行三步骤：
5.项目理解：读懂仓库结构、关键文件和类
6.缺陷定位：找到需要修改的具体代码位置
7.Patch 生成：生成标准的 Git diff
Agent 形态下，模型可以调用三类工具：
•项目结构工具——查看有哪些文件/类/函数
•搜索工具——按 class/function/代码片段搜索
•Git 工具——checkout、apply diff
最核心的能力：模型能自主学习「什么时候该用什么工具」。这不是写死的规则，而是训练出来的。
4.3 SWE-bench 成绩单
开源模型已经逼近闭源 Agent 的水平——这是一个非常有信号意义的里程碑。
五、三个让我印象最深的技术细节
5.1 用户行为建模：先推签名再补体
长函数不一次性推 100 行代码——先推一个方法签名让用户接受，确认这是你要写的东西，再继续补完函数体。这种做法既减少了生成时间，又避免了「生成一大段用户不采纳」的浪费。
5.2 RLHF 解决「停不下来」
这是整个分享里最让我惊艳的一个解法。模型为什么停不下来？因为训练数据里没有「应该停在这里」的负例。
解决方案：通过 RLHF 后训练，把「停不下来 / 无限循环」的结果设为负例，让模型学会正确的停止时机。
这个思路不仅适用于代码补全，对任何生成式 AI 的「过度输出」问题都有借鉴意义。
5.3 代码补全不是调用千问就能解决的
曹博士特别强调了一个很多人搞混的概念：通义灵码插件里的补全模型，是内部 Code 模型经过二次训练的产物，和直接调千问 API 完全不同。
代码补全模型是「领域专家」，通用模型是「通才」。让通才去干专家的活，效果差太远。
· · ·
六、产品矩阵：一次看全
产品 | 形态 | 能力 | 状态 |
通义灵码插件 | IDE 插件 | 补全 + 问答 | 公测免费 |
AI 程序员 | 官网独立产品 | 端到端开发+修缺陷 | 公测免费 |
Lingma-SWE-GPT | 开源模型 | Agent 修 Issue | GitHub 开源 |
CodeDevBench | 开源评测 | 代码补全评测 | arXiv/HF |
@workspace | 插件内对话 | 轻量版 AI 程序员 | VS Code |
· · ·
七、展望：AI 不会取代你，但会用 AI 的人会
曹博士在结尾的总结很实在——
AI 程序员不是取代人类，而是为程序员减少错误、提高效率、补充知识。
通义灵码未来的路线图是覆盖软件研发全流程：
•已在做：编码开发（补全、修缺陷、单测）+ 集成测试（扫描修复）
•将覆盖：需求阶段（PRD）、产品分析、开发部署、效能管理、代码库理解、学习培训
还有一个信号值得关注：曹博士提到「长推理能力（OE 方向）在数学和代码上最关键」，同时暗示 Cursor 类似能力正在开发中。AI 编程的竞争还会继续升级。
八、关键金句
「代码补全的挑战不是'写一个函数'，而是'理解用户当前到底要写什么'。」
「模型生成结果不一定是完全 OK 的——当前 AI 能力有限，需要强代码能力者与 AI 一起构建。」
「通过 RLHF 解决'停不下来'——负例让模型学正确停止。」
「代码补全模型是'领域专家'，通用模型是'通才'。各干各的。」