代码生成：模型如何写程序
直觉版：从代码里学代码
Section titled “直觉版：从代码里学代码”代码生成模型的核心直觉很简单：代码也是一种”语言”，有语法、语义和上下文依赖。通过在大量代码（GitHub、Stack Overflow、文档）上训练，模型学会了变量命名、控制流、API 调用和调试模式。你给模型一个函数签名和注释，它就能补全实现；给一段有 bug 的代码，它有时能指出问题。
工程版：从补全到 Agent
Section titled “工程版：从补全到 Agent”工程上，代码生成已从简单的自动补全发展到复杂的软件工程 Agent：
- 代码补全：IDE 插件根据光标位置和上下文预测下一行或下一个 token。关键在于上下文窗口要足够覆盖相关函数定义和导入语句。
- 单元测试生成：根据函数签名和注释自动生成测试用例，减少 boilerplate 编写时间。
- 代码审查：自动检测常见 bug、安全漏洞和风格问题，但无法替代人类对业务逻辑的理解。
- SWE Agent：如 SWE-agent，能自主浏览代码库、定位 bug、编写修复并运行测试。这要求模型具备长上下文理解、工具调用和多步规划能力。
评估代码生成不能只看语法正确性：HumanEval 测函数级补全，SWE-bench 测真实 GitHub issue 修复能力。生产中使用时要关注：幻觉 API（调用不存在的函数）、安全漏洞（注入、越界）、以及代码风格与现有库的一致性。
研究版：代码理解的本质
Section titled “研究版：代码理解的本质”研究上，代码生成引发了一个根本问题：模型是否真正”理解”了代码的语义和执行流程，还是只是在模式匹配？证据是混合的：模型在常见模式上表现优异，但在需要深层推理、多文件协调或复杂算法设计时仍会失败。
前沿方向包括：执行引导生成（用实际运行结果反馈修正代码）、形式化验证结合（让模型生成附带证明的代码）、以及从自然语言需求到可部署系统的端到端生成。代码可能是检验 LLM”推理能力”的最严格基准之一，因为代码的执行结果是非黑即白的。
🔬 开放研究问题
该领域的关键问题与研究方向：
- 代码生成模型在真实软件工程任务中的瓶颈是什么？SWE-bench 揭示了哪些关键差距？
- 如何评估代码模型对大型代码库的理解能力？现有 benchmarks 的覆盖度是否足够？
- Agent-based 代码生成（如 SWE-agent）与传统端到端生成在可靠性和可维护性上的权衡是什么？
本文引用论文
- Evaluating Large Language Models Trained on Code
提出 Codex 模型 + HumanEval 基准（164 道编程题）。HumanEval 至今是 coding 模型的"心电图指标"；这篇论文也是 GitHub Copilot 的根。
- SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
用 12 个真实 Python 仓库 2294 个 issue 评测代码模型"端到端解决 bug"的能力。一夜成为 coding agent 行业标准评测，几乎每篇 coding agent 论文都报 SWE-bench 分数。
- SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering
提出 ACI（Agent-Computer Interface）概念，强调"agent 用什么工具/界面 ≥ 用什么模型"。把 GPT-4 + 良好 ACI 在 SWE-bench 提升 6 倍，奠定 coding agent 工程方法论。
- OpenAI o1 System Card
OpenAI o1 的系统卡，展示了通过大规模强化学习训练"慢思考"模型的路线： 模型在回答前进行长时间的内部推理链，在数学竞赛和代码题上大幅超越 GPT-4。 这标志着 LLM 从"快思考"到"慢思考"的范式转变，也是 DeepSeek-R1 等模型的直接先驱。
- DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning
DeepSeek-R1 展示了纯粹通过强化学习（无监督微调启动）就能涌现出类 o1 的链式推理能力， 且主要使用 GRPO（组相对策略优化）而非 PPO。完全开源（权重 + 训练细节）， 在多项推理基准上与 OpenAI o1 持平，是 2025 年最重要的开源 LLM 成果之一。