li旭旭1. 测试策略驱动的LLM代码生成：架构对齐新范式
最近在重构一个遗留系统时，我遇到了一个典型问题：新设计的微服务架构需要与旧有的单体应用代码保持功能一致性。传统的手动代码迁移不仅耗时，还容易引入难以察觉的边界条件错误。这时我想到了用LLM（大语言模型）来辅助生成对齐代码，但很快发现单纯的提示词工程效果并不理想——生成的代码要么偏离架构约束，要么无法通过核心用例的测试。
经过多次迭代，我发现将测试策略作为驱动力的方法显著提升了代码生成质量。具体来说，就是先定义好测试用例和架构规范，再让LLM基于这些约束条件生成代码。这种方法不仅适用于新老系统对齐，在跨语言移植、协议适配等场景也同样有效。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 测试策略作为LLM的"指南针"
2.1 为什么测试用例比注释更有效
传统做法是给LLM提供大量代码注释和架构说明，但实践中发现三个主要问题：
- 模型容易过度关注局部代码模式而忽略全局约束
- 架构决策点（如并发模型选择）经常被错误实现
- 生成的代码需要通过反复调试才能满足基本要求
而将测试用例作为主要输入时：
- 每个测试案例明确定义了输入输出边界
- 集成测试可以直接验证组件交互是否符合架构
- 性能测试能约束资源使用模式
例如在生成gRPC服务桩代码时，我首先准备了三类测试：
python复制# 接口一致性测试
def test_service_method_signature():
assert hasattr(GeneratedStub, 'get_user')
sig = inspect.signature(GeneratedStub.get_user)
assert str(sig) == '(self, request: UserRequest, context)'
# 协议缓冲测试
def test_protobuf_serialization():
test_request = UserRequest(user_id="123")
assert GeneratedStub().get_user(test_request, None).user_id == "123"
# 性能约束测试
@pytest.mark.benchmark
def test_response_time():
result = benchmark(GeneratedStub().get_user, UserRequest(user_id="123"))
assert result.stats['mean'] < 50 # 50ms阈值
这些测试用例作为提示词的一部分提供给LLM后，生成的代码第一次就能通过90%以上的测试用例。
2.2 架构约束的机器可读表达
除了测试用例，我们还需要将架构级约束转化为LLM可理解的规范。实践中我采用OpenAPI规范描述服务接口，用PlantUML描述组件关系，再用JSON Schema定义数据契约。例如：
yaml复制# OpenAPI片段
paths:
/users/{id}:
get:
parameters:
- name: id
in: path
required: true
schema:
type: string
pattern: '^[a-f0-9]{24}$' # MongoDB ID格式约束
responses:
'200':
content:
application/json:
schema:
$ref: '#/components/schemas/User'
配合这样的提示词模板：
code复制你是一个资深后端工程师，需要基于以下约束生成Python gRPC服务代码：
1. 接口规范：{openapi_spec}
2. 数据契约：{json_schema}
3. 必须通过的测试用例：{test_cases}
首先生成满足所有约束的代码骨架，然后解释关键设计决策。
这种结构化输入使LLM生成的代码在架构一致性上有显著提升。
3. 构建高效的提示词工作流
3.1 分层提示词设计
通过实践我总结出一个四层提示词结构：
-
角色定位层：明确LLM需要扮演的专家角色
code复制
你是一个有10年经验的系统架构师，擅长在严格约束条件下设计可维护的代码 -
约束声明层：列出所有必须遵守的硬性约束
code复制必须遵守： - 所有数据库访问通过Repository模式抽象 - 错误处理使用Result模式而非异常 - 并发控制采用乐观锁机制 -
示例演示层：提供输入输出的理想示例
code复制输入测试用例： When GET /users/123 Then response.status = 200 And response.body matches UserSchema 期望代码结构： class UserController: @inject def __init__(self, user_repo: UserRepository) -
验证要求层：指定代码需要通过的验证标准
code复制生成的代码必须： 1. 通过所有单元测试 2. 通过SonarQube静态扫描 3. 符合团队代码风格指南
3.2 动态上下文管理
为了处理复杂系统的代码生成，我开发了一个上下文管理系统：
python复制class PromptContext:
def __init__(self):
self.architecture_rules = []
self.test_cases = []
self.examples = []
def add_rule(self, rule):
self.architecture_rules.append(rule)
return self
def add_test(self, test):
self.test_cases.append(test)
return self
def build_prompt(self):
return f"""
架构约束：
{self._format_rules()}
验证用例：
{self._format_tests()}
生成满足以上所有要求的代码，并用<!-- THINKING -->标签展示设计过程。
"""
这种方法允许我们逐步构建复杂的提示词，同时保持各部分的可维护性。
4. 典型问题与解决方案
4.1 边界条件处理
LLM容易忽略边缘情况，我的解决方案是：
-
在测试用例中明确包含边界条件：
python复制@pytest.mark.parametrize("input", ["", "a"*256, None]) def test_input_boundary(input): assert validate_input(input) is False -
使用突变测试验证生成的代码：
bash复制
pip install mutmut mutmut run --paths-to-mutate=generated_code.py -
在提示词中强调防御性编程要求：
code复制特别注意： - 所有字符串输入必须验证长度和字符集 - 数值参数必须检查范围 - 外部调用必须处理超时和重试
4.2 架构模式一致性
当系统使用特定架构模式（如CQRS、Event Sourcing）时，可以采用以下策略：
-
提供架构决策记录(ADR)作为上下文：
code复制ADR-003: 我们采用CQRS模式分离读写操作 - 命令：改变系统状态的操作 - 查询：不改变状态的数据检索 -
生成代码后运行架构一致性检查：
bash复制
archunitcli check --rules=cmd_query_separation ./generated_code -
在提示词中嵌入模式验证：
code复制请确保： - 命令Handler不包含查询逻辑 - 查询Service不包含修改操作 - 事件定义在shared/events模块中
5. 进阶技巧与工具链集成
5.1 测试覆盖率引导的迭代
我建立了一个自动化工作流：
- 初始生成代码
- 运行测试套件收集覆盖率数据
- 识别未覆盖的分支/条件
- 生成补充测试用例
- 重新生成代码
使用如下工具链：
bash复制# 生成初始代码
llmgen --template=spring --constraints=constraints.json > temp.java
# 运行测试并收集覆盖率
mvn test
jacoco report
# 分析缺口并生成新测试
cov2test coverage.xml > new_tests.java
# 迭代生成
llmgen --previous=temp.java --new-tests=new_tests.java > final.java
5.2 架构守护自动化
将生成的代码提交到代码库前，自动执行：
- 架构合规性检查（使用ArchUnit等工具）
- 设计模式验证
- 依赖关系分析
示例验证规则：
java复制@ArchTest
static final ArchRule layer_dependencies_are_respected = layeredArchitecture()
.layer("Controller").definedBy("..controller..")
.layer("Service").definedBy("..service..")
.layer("Repository").definedBy("..repository..")
.whereLayer("Controller").mayNotBeAccessedByAnyLayer()
.whereLayer("Service").mayOnlyBeAccessedByLayers("Controller")
.whereLayer("Repository").mayOnlyBeAccessedByLayers("Service");
6. 实际案例：订单系统迁移
最近将一个单体订单系统迁移到微服务架构时，我们：
- 从原系统提取了300+核心测试用例
- 定义了新的服务边界和接口规范
- 使用测试策略驱动生成新代码
关键指标对比：
| 指标 | 传统手动迁移 | LLM驱动迁移 |
|---|---|---|
| 代码生成时间 | 2周 | 3天 |
| 首次测试通过率 | 65% | 89% |
| 架构违规数量 | 17处 | 3处 |
特别值得注意的是，通过将性能测试作为硬性约束，生成的代码在TPS（每秒事务数）指标上比手动编写的版本高出15%，因为LLM严格遵循了我们提供的缓存模式和连接池配置。
7. 经验总结与持续改进
经过多个项目的实践，我总结了以下关键经验：
-
测试用例的质量决定生成代码的上限：投入时间设计全面的测试套件，特别是：
- 故障注入测试
- 混沌工程场景
- 幂等性验证
-
反馈循环至关重要：建立自动化流程持续：
- 收集生成代码的问题模式
- 更新提示词模板
- 优化测试用例集
-
人类专家的不可替代性：LLM在以下方面仍需人工干预：
- 架构权衡决策
- 非功能性需求平衡
- 领域知识注入
我现在的典型工作流是：
- 人工定义核心测试用例和架构约束
- LLM生成候选代码
- 人工评审关键设计点
- 自动化验证所有约束
- 将问题反馈到提示词优化
这种协作模式既保证了代码质量，又显著提升了开发效率。随着工具链的完善，我们现在可以在一周内完成过去需要一个月的工作量，同时保持更高的架构一致性。