代码自动生成框架实战：从大模型到可落地的工程化流水线

去年开始，我就在团队里折腾各种“代码自动生成”的落地方式。最开始的想法很简单，让AI写代码嘛，大家都会，接个大模型API，写几句提示词，让它生成个函数、补个单元测试，demo跑得飞起。但真正推到一个中型项目、多人协作的环境里，问题马上就来了：生成的代码风格不统一、经常用一些莫名其妙的API、没法做自动化校验，更别说接进CI流程里做增量检查了。折腾了几个月，踩了不少坑，最后沉淀出来的经验就是——光有模型远远不够，你需要一个能把“理解需求—检索上下文—生成代码—校验修正—输出产物”串起来的代码自动生成框架。

这篇文章不聊那些PPT层面的概念，直接讲清楚一个能落地的代码自动生成框架到底应该怎么搭。我会把自己在这套框架设计上的思路、每个模块怎么选型、关键代码怎么写、实际运行起来遇到过哪些幺蛾子，全部整理出来。如果你也准备在团队里引入AI辅助编码，或者想把现有的编码流程做成半自动甚至全自动，这篇内容应该能帮你少走不少弯路。

1. 为什么需要一个“框架”，而不是直接调大模型

先说个颠覆很多人直觉的结论：直接用大模型API写代码，在小范围试用的时候很爽，但一旦要稳定地产出可合并的代码，问题就全部暴露了。

1.1 直接调API的痛点

我之前试过几种方式。最简单的是在IDE里装个插件，选中一段代码，让它重写或者补全，这个对单个函数的帮助确实有，但很难保证全局一致性。比如它会自己发明一个错误的方法名，或者为了满足你的注释要求，把函数参数强行改了，连带调用方的代码却不知道要不要同步改，编译过不了。

更麻烦的是上下文问题。比如你让大模型生成一个订单状态流转的工具类，它不了解你们项目里已经存在的状态枚举、底层存储抽象、异常处理规范，它生成的代码可能逻辑上没错，但和你现有的工程体系完全割裂。你给它的上下文太少，它就靠常识猜；给多了，又超过模型上下文窗口，根本塞不进去。

还有个致命问题——不可重复。同一个需求，模型每次生成的代码都不一样，这在有代码评审和规范审查的团队里非常致命。你没法跟评审说“这次生成的代码和上次稍微不一样，但也能跑”，对于一致性要求高的场景（比如对外API、数据模型定义），这不是能商量的空间。

1.2 用“框架思维”解决工程问题

后来我意识到，核心矛盾不是模型不够聪明，而是缺少一层工程化约束。大模型本身是概率输出，但工程上需要的是稳定产物。问题的解法就是：中间加一个框架，让模型在给定的边界内生成内容，并且对输出做自动校验和修正。

这个思路其实跟传统代码生成器一脉相承。以前我们用模板引擎（比如Jinja2、MyBatis Generator）生成代码，预先把结构定死，改变的是数据；现在换成大模型，模板不再只有静态结构，而是变成了“提示词模板+动态上下文+校验规则”的组合，灵活性更高，但同样需要框架来做流程编排。

所以我理解的代码自动生成框架，本质上是一套流程系统：它把需求输入、上下文准备、模型调用、输出校验、错误修正这五个环节固化下来，让每一次代码生成不再是一次“碰运气”，而是一次可控的流水线作业。从这个角度看，这套框架与某个具体的大模型厂商完全解耦，也不绑定某种IDE，它是一个独立于开发流程之外的代码生产工具链。

1.3 什么样的团队适合用框架

如果你的团队有下面任一特征，我比较推荐花时间搭一套自己的框架：

• 项目代码量大，但存在大量样板化代码（比如CRUD接口、数据模型、DTO互换、单元测试）
• 团队对代码规范有硬性要求，需要自动生成的代码跟手写代码风格一致
• 有稳定的大模型API预算，希望把它从“有趣的尝试”变成“每天都要用的生产力工具”
• 项目里已经建立了良好的编译、静态检查、单测机制，可以让框架自动调用这些工具来做校验反馈

如果只是偶尔让AI写个脚本，那确实不需要折腾框架。但如果你指望它在生产环境持续产出代码，框架这层东西迟早要补上。

2. 代码自动生成框架的整体设计

这一节是全文的核心。我把自己在框架设计上的模块划分讲清楚，包含每个模块的作用和设计思路。整个框架我按照流水线的方式组织，一共分五个核心模块：任务解析、上下文采集、生成引擎、校验修正、产物输出。

2.1 模块总览：五段式流水线

我最开始设计的版本没有这么清晰，是随着迭代慢慢拆成这个结构的。

2.2 关键是“任务解析”，不是直接丢需求

很多人做代码生成框架的时候，第一步就把需求原文直接扔给模型，这是很偷懒的做法，效果也不好。真实开发的需求往往是模糊的，比如一句话需求“给用户模块加一个列表接口”，这里面缺了太多信息：是按什么字段筛选？分页怎么做？返回给前端的结构是啥？权限要求是什么？

所以在生成代码之前，必须先有一个任务解析步骤。这一步本质上是在做需求澄清，它可以由人来做，也可以由模型来做。实操中我是两层结合：用户先用一个结构化的表单填写需求要素，框架再调用模型补全缺失的细节。

我之前设计过一套简单的任务描述模板，大致长这样：

json复制{
  "task": "generate_crud_api",
  "target_module": "order",
  "fields": [
    { "name": "id", "type": "string", "primary_key": true },
    { "name": "status", "type": "int", "default": "0" },
    { "name": "amount", "type": "decimal", "note": "订单金额" }
  ],
  "framework": "springboot",
  "api_version": "v1",
  "constraints": [
    "所有对外返回字段必须使用VO对象，不直接返回Entity",
    "分页参数标准为page和size，默认page=1, size=20",
    "状态变更需要写操作日志"
  ]
}

框架拿到这个结构化任务之后，再结合项目上下文生成代码，会比直接往提示词里塞一句话可靠得多。任务解析的本质是把开放问题变成闭合问题，让生成过程有边界。

2.3 上下文采集：决定代码质量的隐形天花板

上下文采集是我在这套框架里花时间最多的模块。它的目的就是解决我前面说的“模型不了解项目现状”的问题。

实操下来，上下文采集要考虑三个层面：

• 工程结构上下文：项目用的框架（Spring Boot / Vue / React）、目录结构、核心依赖
• 领域规则上下文：代码里已有的枚举定义、业务状态机、领域服务接口、命名规范
• 即时任务上下文：本次要改动的文件、相关调用链路上游和下游代码

框架要做的事，是把这三个层面的信息封装成上下文包（Context Bundle），再传给生成引擎。能不能有效“裁剪”上下文，很大程度上决定了模型生成出来的代码是贴着你工程走的“内行代码”，还是那种看起来正确但放进去就违和的“外行代码”。

上下文采集在设计时有几个关键决策：

1. 优先采集接口签名而不是整个文件内容。我把项目里的Controller、Service接口、Mapper接口解析出来，建立索引，调用时只把相关接口签名放进去，减少无关内容。
2. 对于枚举、常量类，全量保留。这些内容通常很小，但对于生成代码时避免硬编码有奇效。
3. 依赖关系要拉一跳。比如你让它生成订单Service，至少要看看订单Controller引用了哪些方法，保证接口对得上。

2.4 生成引擎：让模型在“边界”内发挥

生成引擎是整个框架的中枢，出门调模型、进门接校验。这一层最关键的控制点是提示词模板和模型参数。

我发现很多人对大模型生成代码的理解是“自然是越少限制越好”，其实反了。对于代码生成，我建议大家尽量把边界条件写得细。边界包括输出格式（完整代码块还是Diff）、代码风格（分号、引号风格）、依赖限制（使用哪个版本API）、禁用项（禁止使用反射优化、禁止外部调用等）。

另外，温度参数对代码生成的影响非常明显。我实测下来，生成代码场景下温度最好不要超过0.2，否则很容易“即兴发挥”，凭空捏造一些不存在的API。但也要区分任务类型，比如让模型生成算法demo的时候，温度高一点反而更容易出现更优解。我在框架里做了一个参数模板，不同任务类型绑定不同参数。

2.5 校验修正：把正确性兜底回来

大模型生成代码，一次跑通是运气，你如果想要在生产环境用，就必须在校验修正环节下功夫。这一层我接了三道防线：

• 静态规则检查：调用项目已有的ESLint、Checkstyle、golangci-lint等工具，自动跑一遍规范检查，把报错信息回传。
• 编译/语法校验：如果是Java项目就尝试编译相关模块，如果是Python项目就尝试import或编译。这一步很硬核，但很有效。
• 单测/冒烟验证：如果任务带单元测试生成，框架会尝试跑一下生成的测试代码，把结果反馈给模型做修正。

整个流程长这样：模型生成代码，进入校验，如果有问题，把“错误信息+对应代码”打包，回到模型让它针对性地修，循环最多三次。超过三次还不行，就标记为人工待审。

这个修正循环是整个框架里最体现工程价值的部分。它有两点跟直接让AI写代码完全不同：一是错误信息被结构化地反馈给了模型，而不是人眼去看控制台；二是循环次数限制，避免模型无限自我纠错、越修越乱。

3. 从零搭建一套最小可用的代码自动生成框架

概念讲了一堆，下面进入实操。我们用一个实际场景来走一遍：做一个数据库表定义到CRUD接口代码的自动生成工具。这个例子很典型，因为CRUD接口生成是门槛最低、收益最明显、也是最容易验证效果的场景。整个框架我选择用Python来实现，因为生态里调用大模型API方便、做模板渲染也顺手。

3.1 准备工作：环境与依赖

先交代一下我这边的环境，方便你对照参考。

• 系统：macOS / Ubuntu 22.04 均可
• Python：3.10+
• 大模型API：以OpenAI兼容格式为主（如gpt-4o-mini、qwen-plus、deepseek-chat等），通过OpenAI SDK调用
• 项目侧代码：使用一个简化版的Spring Boot工程做演示，方便验证编译逻辑

依赖安装：

bash复制pip install openai jinja2 pydantic

这里解释下每个库的作用：

• openai：调用大模型API的SDK，现在很多国内模型也兼容这个格式，选它通用性最好。
• jinja2：模板引擎，用来渲染系统提示词和代码模板。
• pydantic：做结构化的数据校验，比如任务参数的字段解析、生成产物的格式校验。

3.2 核心数据结构：任务模型与上下文包

我这里定义两个核心数据类，相当于整个框架的“接口契约”。第一个是任务模型（TaskModel），用来承载任务解析阶段的结构化需求；第二个是上下文包（ContextBundle），用来承载上下文采集阶段的产物。

python复制from pydantic import BaseModel
from typing import List, Optional

# 字段定义
class FieldDef(BaseModel):
    name: str
    type: str
    primary_key: bool = False
    default: Optional[str] = None
    comment: Optional[str] = None

# 自动生成任务
class CrudTask(BaseModel):
    task_type: str = "generate_crud_api"
    module_name: str        # 例如 order
    table_name: str         # 例如 t_order
    entity_name: str        # 例如 Order
    fields: List[FieldDef]
    framework: str = "springboot"
    api_version: str = "v1"
    constraints: List[str] = []

# 采集到的上下文包
class ContextBundle(BaseModel):
    project_framework: str
    base_package: str
    controller_style: str       # 例如 "RESTFul, 返回值统一R对象"
    existing_entities: List[str]  # 已有实体类名列表
    existing_apis: List[str]      # 已有API方法签名列表
    code_snippets: List[str]      # 关键代码片段

这些数据结构在后面会有很大用处。你没看错，框架的输入不是一段自由文本，而是一个结构化的任务对象，这个过程就是前面说的“任务解析”产物。

3.3 提示词模板设计：这是手艺活

提示词模板是整个框架里最需要反复调试的部分，我直接贴一套我调过相对成熟的模板。模板分三段：系统指令、任务上下文、输出要求。

jinja2复制你是一名资深后端工程师，擅长使用 {{ bundle.project_framework }} 开发高质量、符合团队规范的代码。

请根据以下任务要求生成代码。

## 任务描述
模块名称：{{ task.module_name }}
表名：{{ task.table_name }}
实体名：{{ task.entity_name }}
功能要求：生成 {{ task.entity_name }} 的CRUD接口（新增、删除、修改、分页查询），包含Controller、Service、Mapper三个层次。

## 字段定义
{% for field in task.fields %}
- {{ field.name }} ({{ field.type }}){% if field.primary_key %} [主键]{% endif %}{% if field.default %} [默认值: {{ field.default }}]{% endif %}{% if field.comment %} ({{ field.comment }}){% endif %}
{% endfor %}

## 工程约束
- 基础包名：{{ bundle.base_package }}
- 代码风格：{{ bundle.controller_style }}
- 不允许使用lombok以外的代码生成插件
- 所有对外返回字段使用VO对象，不允许直接返回Entity
- 分页参数统一为page和size，默认page=1, size=20
- 状态变更需要记录操作日志

## 已有工程相关内容（参考，不要重复定义）
{% for snippet in bundle.code_snippets %}
{{ snippet }}
{% else %}
（无）
{% endfor %}

## 输出格式要求
- 按文件路径+代码内容的方式输出，例如：
### MainController.java
```java
{代码内容}

• 只输出代码，不要额外解释。

code复制
这套模板里面有几个值得留意的设计点：

第一，把“字段定义”明确地列成列表，而不是放在一段描述里，这能让模型更准确理解每个字段的角色。

第二，在“工程约束”里加入“不允许使用lombok以外的代码生成插件”，这个细节很关键，它能防止模型去生成一些并不符合团队规范的注解依赖。

第三，在“已有工程相关内容”里给了一个“不要重复定义”的提示，示例里是空的，但实际采集到代码片段后，这个位置会填上真实的Controller/VO风格，让模型模仿。

### 3.4 核心流程实现：采集、生成、校验三段式

下面代码是整个框架的执行主线。我精简了异常处理，保留核心逻辑，方便你理解流程。

```python
import openai
from jinja2 import Environment, FileSystemLoader

class CodeGenFramework:
    def __init__(self, api_key, base_url, model_name):
        self.client = openai.OpenAI(api_key=api_key, base_url=base_url)
        self.model_name = model_name
        self.env = Environment(loader=FileSystemLoader("./templates"))

    # 1. 上下文采集
    def collect_context(self, task: CrudTask) -> ContextBundle:
        bundle = ContextBundle(
            project_framework="Spring Boot 3.x",
            base_package="com.example.demo",
            controller_style="RESTFul, 统一返回R<T>对象",
            existing_entities=[],
            existing_apis=[],
            code_snippets=[]
        )
        # 实际项目中，这一步会解析工程源码，抽取重要类和方法签名
        return bundle

    # 2. 生成
    def generate(self, task: CrudTask, bundle: ContextBundle):
        template = self.env.get_template("crud_template.jinja2")
        prompt = template.render(task=task, bundle=bundle)

        resp = self.client.chat.completions.create(
            model=self.model_name,
            messages=[
                {"role": "system", "content": "你是一名严谨的代码生成助手。"},
                {"role": "user", "content": prompt},
            ],
            temperature=0.1,
        )
        return resp.choices[0].message.content

    # 3. 校验
    def validate(self, generated_code: str) -> list:
        errors = []
        if "TODO" in generated_code:
            errors.append("代码中包含TODO占位符，需补充完整")
        if "lombok" not in generated_code:
            errors.append("实体类未使用lombok注解")
        # 实际项目中：调用本地编译、静态检查，把错误信息收集起来
        return errors

    # 4. 执行修复循环
    def run_with_fix_loop(self, task: CrudTask, max_loop: int = 3):
        bundle = self.collect_context(task)
        current_code = self.generate(task, bundle)

        for i in range(max_loop):
            errors = self.validate(current_code)
            if not errors:
                return current_code

            print(f"[修复循环] 第{i+1}轮，发现 {len(errors)} 个问题")
            # 把错误信息回传给模型，要求修复
            current_code = self.repair(task, current_code, errors)

        return current_code

整个骨架就这么清晰。上下文采集和真实工程结合的部分会比较繁重，但接口已经很稳定：输入一个CrudTask，输出一串代码。校验环节你可以接上你自己项目的Checkstyle、FindBugs、Go vet等工具，这里只是用简单规则示意。

3.5 真实运行实测：一次生成的产物长什么样

我用一个虚拟的订单模块跑了一次框架，顺便把生成的代码关键片段贴出来。下面的代码是框架输出的Controller层代码。

java复制@RestController
@RequestMapping("/api/v1/orders")
public class OrderController {

    @Autowired
    private OrderService orderService;

    @PostMapping
    public R<OrderVO> create(@RequestBody @Valid OrderCreateReq req) {
        return R.ok(orderService.create(req));
    }

    @PutMapping("/{id}")
    public R<OrderVO> update(@PathVariable Long id, @RequestBody @Valid OrderUpdateReq req) {
        return R.ok(orderService.update(id, req));
    }

    @DeleteMapping("/{id}")
    public R<Void> delete(@PathVariable Long id) {
        orderService.delete(id);
        return R.ok(null);
    }

    @GetMapping
    public R<PageResult<OrderVO>> page(@RequestParam(defaultValue = "1") int page,
                                       @RequestParam(defaultValue = "20") int size) {
        return R.ok(orderService.page(page, size));
    }
}

整体风格和团队规范对齐：R统一返回、PageResult分页结构、@Valid参数检查。这就是上下文采集+约束模板带来的效果——如果只给模型一句话让它写订单接口，它大概率生成的返回类型五花八门。

当然，框架生成的代码也不是说完美无缺。上面这个Controller里，create方法没有返回OrderCreateReq里各字段的校验规则，这就得靠单元测试或接口测试来发现了。所以我一直强调，框架的作用是“把低质量变成合格”，而不是“把合格变成完美”，后面的人工评审和质量保障环节仍然不能少。

4. 技术选型与不同场景的取舍

很多人看完上面这套架构，会问我一个问题：模型用什么？Agent框架用不用？要不要上RAG？我统一回答下。

4.1 模型层：开源还是闭源

我自己的经验是：如果预算充足、API调用稳定，优先用闭源模型。代码生成这种任务对大模型的理解能力和上下文长度要求很高，领先的闭源模型确实有碾压级别的体验。但如果数据敏感、必须私有化部署，那只能上开源模型。开源模型方面，目前来看主流的Qwen系列、DeepSeek系列在代码生成上都已经能扛事。

用开源模型的话要注意一个问题：上下文窗口如果偏小，那么上下文采集阶段的“裁剪”策略要更激进。我建议在开源模型场景下，单次任务给模型的代码片段不要超过5个，每个片段不要超过50行，质量优先。

补充一个参数建议：不管用哪个模型，模型版本不要频繁切换，尽量固定住。我遇到过版本升级之后，生成的代码风格突变，导致团队里连续一周出现大量无意义的Diff，排查了挺久才发现是模型版本变了。

4.2 Agent编排：从小步快跑开始

热词里提到的Agent框架确实很火，但我的观点比较务实：先从无状态、单步骤、可套模板的流程开始，等需求复杂了再上Agent编排。 代码生成这种场景，它的核心价值在可控性，而Agent的自主性越强，越难做精细控制。

我的框架早期版本没有接入任何Agent编排框架，就是一个串行函数调用流程。后来加了“根据静态检查结果自动修复”的能力，才引入了轻量级的状态机，让“生成—校验—修复”这三步能循环起来。再往后，如果要做多文件协同、跨模块改动、自动生成测试代码并跑测试，那就需要引入更通用的Agent编排能力了。

什么时候需要上重型Agent框架？ 我个人的判断是：当生成任务需要多轮规划、多个工具交叉使用（比如改了代码还要去改数据库迁移脚本、改前端调用、跑测试、提交PR），并且这些步骤之间有复杂依赖时，才值得引入。纯CRUD生成场景用重型Agent框架反而会拖慢速度、增加不稳定点。

4.3 RAG与上下文工程的关系

很多人一上来就想着上RAG，把代码库向量化、建立索引，检索相关代码再扔给模型。这个方向没问题，但不要把它当成代码生成框架的第一步。

实际项目里，代码比文档更容易被精简，因为代码有明确的依赖关系图。与其把代码库全部向量化，不如先用语法分析器把关键符号（类、方法、接口）抽出来，做一个轻量级索引。更实际的上下文获取方式包括：

• 读取当前工作区变更文件及其直接依赖
• 利用export、import、require等语句找到相关联的内部模块
• 通过配置文件和统一规范文档补充团队约定

向量化RAG适合在代码库很大、且用户需要模糊搜索语义相近代码的时候用。比如“找出项目里所有处理超时重试的代码”，这种问题用向量搜索效果很好。但若要生成“订单模块的CRUD接口”，轻量级静态索引比RAG更准确、更快，也更容易控制token成本。

4.4 输出形态：直接写文件还是生成Diff

这也是框架设计中的一个决策点。我在实验阶段的版本是直接把生成的代码写到指定目录，结果经常出现“改错了位置、覆盖了已有文件”的惨剧。后来改成生成Diff，人工确认后合入，安全多了。

建议路径：

1. 框架生成产物：多文件代码结构化输出到一个staging目录
2. 由引擎把staging目录和目标工程做diff，产出补丁文件
3. 开发者review补丁，确认后应用

这样既保留了自动化的效率，又把最终决定权放回人手里。即使模型在某些地方生成得不对，也不会直接污染核心代码。

5. 实操中遇到的坑与排查经验

这部分内容是我最想分享的。真正把这个框架用在日常开发里，会遇到很多文档之外的麻烦，我把常踩的坑整理成了一份速查表。

5.1 上下文越权与信息过载

最开始我把整个项目的目录树和常用类名全塞给模型，结果它不仅没更好用，反而开始在各种不相关的地方“引用”无关类，甚至在输出里捏造了一些从目录名里“看”到的类。后来我意识到问题出在信息过载上——模型会把上下文里所有命名当作“可用的工具”，但你的上下文其实只是让它参考，并不代表这些都能直接import。

解决办法：严格限制上下文类别，只放需要的接口签名、常量定义和风格示例。如果你不确定某个类是否被引用，宁可先不问模型，让它把引用的地方写出来，方便你人工补齐。

5.2 模型“幻觉”出的API

这是所有AI写代码场景下最让人头大的问题，没有之一。大模型在生成时经常会使用一些看起来存在、实际不存在的库或方法。比如我遇到过让它用Java生成调用某个内部RPC的代码，它凭空给方法加了一个重试参数，而这个参数的规范根本不存在。

解决思路有两个层面。第一个层面靠提示词约束，明确禁止使用未在上下文中出现的依赖类，引用外部API必须匹配上下文给出的签名。第二个层面靠校验修正，我在validate阶段做了一个“依赖白名单”机制：解析生成代码里的import语句，凡是上下文和项目依赖里没有的，一律标记为错误并回传给模型修正。这个机制上线后，无效import的问题大幅减少。

5.3 初始化表达式和默认值问题

生成代码里常见的另一类Bug是默认值设置不合理。比如生成Java实体类时，对Integer字段给了= 0，看起来没啥问题，但某些支付场景里0可能表示“无效”，而不是“未设置”，这时生成代码反而引入了业务Bug。

我的建议：对于有业务含义的字段，强制约束“不得自动设置默认值”；对于纯技术字段（比如重试次数、创建时间），可以允许默认值，但也要根据项目模板来定。这个约束我会直接写在提示词的“工程约束”里，避免模型自由发挥。

5.4 循环修复不收敛

修复循环设计不好，容易变成“模型越改越错，错上加错”。比如我先让它修一个编译错误，它可能为了修这个错误，把另一个正常逻辑也改掉了，产生新的错误。这样循环三轮输出出来的代码比第一版还不如。

控制方法：

1. 每次修复只允许一个目标：把错误列表里的第1个错误作为当前唯一修复目标，修复完再进入下一轮。
2. 给模型回传错误时，附上“禁止改动无关代码”的指令。
3. 设定最多3轮上限，超出后终止并标记人工介入。不要开成无限循环。

5.5 生成的代码风格不一致

团队里如果同时有多人使用这套框架，很容易出现“同一个功能，每个人生成的代码长得不一样”的情况。这个问题的根因是提示词里没有给足“风格锚点”。工程化的做法是：在上下文包里固定提供1-2个项目内的范例文件，让模型去模仿，而不是靠语言描述“请按照团队规范写代码”。

我实测下来，“给范例”比“描述规范”的效果好得多。也就是说，与其说“返回对象统一为R对象”，不如直接把一个现有的Controller文件片段放上去，模型自然会模仿它的包名、注解写法、返回结构。

5.6 安全审计与密钥泄漏

代码生成框架自动化程度越高，越要注意安全问题。我至少碰过两次生成代码里出现了Base64编码的“假密钥”，还有一次模型在生成配置类时，试图把数据库连接信息以明文方式写进代码。虽然这些是测试数据，但放在生产环境就严重了。

框架里必须做好两件事：一是对输出内容做敏感词和密钥模式扫描（比如检测AK/SK、密码字段、私钥块等），二是如果检测出可疑内容，直接把该文件标记为“人工审核”。这个机制不复杂，但必须要有。

5.7 本地编译速度拖垮反馈循环

校验环节如果依赖全量编译，每次生成都要跑一次构建，耗时太长，半天等不到反馈，体验非常糟糕。我后来优化成“最小编译集”：只编译生成代码涉及到的模块，以及这些模块直接依赖的下游模块。

在Maven项目里用-pl和-am参数，在Gradle里用compileJava任务，都能有效缩小编译范围。实在复杂的项目，也可以退回语法层面的解析（比如用Tree-sitter提取语法树），虽然覆盖不到的编译错误会变多，但反馈速度能提升一个量级。

6. 框架的后续演进方向

代码自动生成框架不是搭完就能一劳永逸的东西，它会随着模型能力和项目需求不断演进。这里聊几个我实际正在尝试的方向，也供你参考。

6.1 从CRUD生成到代码评审辅助

框架最成熟的场景是CRUD接口生成，但它的价值远不止于此。我目前正在把框架扩展成代码评审辅助工具：读取提交Diff，调用模型做变更分析，给出潜在风险点、遗漏边界、测试建议。输出是结构化的Markdown报告，直接贴在PR描述里。

这个场景同样收益很高。之前人工评审一个大型PR，可能需要半小时，框架辅助后，初次分析只需要两三分钟。虽然不能替代人的判断，但可以把明显的低级问题先拦下来，让人把精力花在更有价值的设计层面。

6.2 建立团队代码规范知识库

代码自动生成框架的上下文采集模块，天然适合沉淀团队知识。我现在把团队的编码规范、架构决策记录（ADR）、常用组件使用说明都结构化存起来，在生成代码时按需注入。这样一来，新人也能在AIGC帮助下直接产出符合老团队风格的代码，这是对团队协作效率很有价值的一件事。

6.3 与CI/CD和自动化测试联动

再进一步，可以把框架接入CI流水线，让每次提交后的代码变更自动生成对应的单元测试，并跑一遍。目前这个方向的主要难点是生成的测试代码稳定性还不够高，偶尔会出现“测试代码为了通过而写得没有意义”的情况，需要配合覆盖率指标和变异测试来做质量验证。这个方向我已经在持续迭代，等打磨到可以稳定跑的时候，会单独写一篇专门讲。

6.4 最后说点大实话

如果你问我现在这套框架值不值得投入，我会说：值，但前提是你得清楚地知道它到底解决什么问题。如果你的目标是减少样板代码的手写量、统一团队风格、加快日常开发节奏，那这种“轻量级、以模板和上下文为核心”的框架，投入产出比非常高。但如果你指望它把所有业务逻辑都自动写出来，那还远得很——至少在我实际过的所有项目里，复杂业务里真正难的部分从来不是代码怎么写，而是需求本身该怎么拆解和建模，这部分还是要靠人来想清楚。

现在我开始做代码自动生成框架，我会从一个具体的痛点场景（CRUD生成）做起，一步一步把上下文采集和校验修正打磨成熟，再向评审辅助、测试生成这些更复杂的场景扩展。上面这些过程中踩过的坑总结成了一句：给模型越多结构、越少自由，生成结果就越可靠。这句话如果你能记住，就已经能少踩一多半坑了。