代码生成的工程：做自己的 Copilot

用 Copilot、Cursor、Claude Code 很爽，但很多团队会想：能不能做一个"懂自己代码库"的代码生成助手？ 比如内部框架的智能补全、特定语言的代码生成、垂直领域的代码 Agent。

代码生成产品看着是"调模型"，工程内核其实不少。这篇拆解。

一、代码生成的三种形态

先分清形态，决定架构差异：

1. 行内补全（inline completion）。用户打字时，模型实时建议后续几行（Copilot 式）。特点：

• 延迟敏感（< 300ms 才不打断思路）。
• 上下文 = 当前文件 + 光标前后 + 少量相关文件。
• 输出短（几行到一个函数）。

2. 编辑/重构（edit）。选中一段或描述意图，模型改代码（Cursor 的 edit、Claude Code 的多文件改）。特点：

• 延迟宽容（几秒可接受）。
• 上下文 = 选中代码 + 相关文件 + 用户指令。
• 输出可能是多文件改动。

3. Agent（autonomous）。给一个任务，Agent 自主探索代码库、改代码、跑测试（Claude Code 式）。特点：

• 长任务、多步、自主。
• 上下文 = 自主检索的相关文件 + 任务历史。

三种形态，上下文构建和生成策略完全不同。做产品先定形态。

二、上下文构建：代码生成的命门

模型生成代码的质量，80% 取决于你给了它什么上下文。代码上下文的构建：

1. 当前文件 + 光标上下文。 补全场景的核心。光标前（要续写的）+ 光标后（要衔接的）。

2. 相关文件检索。 当前文件 import 了什么、调用了什么——把这些文件的内容也喂进去。用 LSP（语言服务器）拿引用关系，比"全文搜"准。

3. 代码库语义检索。 对"用户描述意图，要找相关代码"的场景，用 embedding 检索（语义搜代码）。比关键词/AST 搜能找到"功能相关但名字不同"的代码。

4. 项目约定。 项目的 lint 规则、命名规范、框架用法（"我们用 Next.js App Router，不用 pages"）。这部分常驻 system prompt 或文档检索。

上下文排序：当前文件 > 直接 import/调用 > 语义相关 > 项目约定。优先级错了，关键信息被冲掉。

三、代码库感知：内部助手的关键差异

通用 Copilot 不知道你的私有代码库/内部框架。内部代码助手的核心价值就是代码库感知：

• 索引私有代码。把公司全部仓库入向量库 + AST 索引，检索时能找到内部 API/约定。
• 理解内部框架。fine-tune 或 few-shot 内部框架的用法（"我们自研的 X 框架，路由这么写"）。
• 集成内部工具。接内部 CI、内部文档、内部代码搜索。
• 遵循内部规范。安全合规（不生成带漏洞的代码）、内部 lint/格式。

这是内部助手相对通用工具的护城河——通用工具拿不到你的私有代码和约定。

四、生成质量护栏

模型生成的代码，不能直接进生产，要过几道关：

1. 语法检查。生成完先过 parser（tree-sitter / tsc / eslint），语法错的直接拒绝重生成。这是最低成本的护栏。

2. 类型检查（TS/Java 等强类型语言）。生成的代码能不能通过类型检查。类型错的重生成或自动修。

3. 测试验证。如果项目有测试，生成后跑相关测试。测试挂的重生成。

4. diff 审查。生成的 diff 自动审查（AI code review 或规则），高风险改动（删文件、改 public API）标记需人工确认。

这套"生成 → 验证 → 修复"的循环，是代码生成可靠性的核心。没有护栏的代码生成，是给开发者添乱。

五、FIM（Fill-in-the-Middle）：补全的关键技术

行内补全有个细节：光标在代码中间，模型要"看前后填中间"。直接把代码喂给模型，它不懂"哪里要填"。

FIM（Fill-in-the-Middle）格式：把代码拆成 prefix（光标前）和 suffix（光标后），用特殊标记包起来喂模型：

<prefix>光标前的代码</prefix><suffix>光标后的代码</suffix>

训练时用 FIM 格式的模型（Code Llama、DeepSeek-Coder、StarCoder 等）能理解这个结构，准确填中间。做行内补全，必须用支持 FIM 的模型 + 格式，否则补全质量差一截。

六、延迟优化：补全的生死线

行内补全延迟 > 500ms 用户就嫌卡。优化：

• 流式输出。第一个 token 出来就显示（边生成边显示）。
• 小模型 + 量化。补全用小模型（快），复杂编辑才用大模型。
• 上下文精简。别把整个文件塞进去，只取相关片段。
• 预请求。用户打字时预测性预生成（预测 ta 要补全的位置），打完字直接显示。
• 缓存。相同 prefix 的补全缓存。

补全产品的体验，延迟比质量更敏感——快但略糙 > 慢但完美。

七、从 demo 到产品的路线

1. 形态聚焦：先做一种（补全 or 编辑 or Agent），别全做。
2. 代码库索引：搭好语义检索 + AST，这是代码库感知的基础。
3. 护栏：语法/类型/测试验证，保证基本质量。
4. 延迟优化：补全场景必须做。
5. 场景收敛：聚焦几个高频场景（内部框架补全、特定语言生成），做深。

小结

做代码生成产品，核心不是"调模型"，而是：

• 形态先定（补全/编辑/Agent，架构差异大）。
• 上下文构建是命门（当前文件 + 相关 + 约定，按优先级）。
• 代码库感知是内部助手的护城河（索引私有代码/框架/规范）。
• 质量护栏（语法/类型/测试/diff）保证不添乱。
• FIM + 延迟优化是补全场景的关键。

记住一句：通用代码工具拼模型能力，垂直/内部代码工具拼代码库感知和场景闭环。 在大厂统治通用代码生成的当下，"懂特定代码库/框架/场景"才是独立代码生成产品的立足点——把通用工具做不到的纵深做透，就是你的差异化。