LLM代码生成质量提升：测试思维与CoT提示词实践

1. 项目概述：当代码生成遇上测试思维

去年在给团队做自动化工具链升级时，我发现一个有趣现象：工程师用LLM生成的代码虽然语法正确，但总存在边界条件缺失、异常处理不完整等问题。这促使我开始尝试将测试思维前置到代码生成环节，而CoT（Chain-of-Thought）提示词模板就是实现这个想法的关键技术桥梁。

传统LLM代码生成就像让新手直接写实现代码，而加入测试工序的CoT模板相当于配备了一位经验丰富的代码审查员。通过分步引导模型思考输入验证、异常场景和边界条件，我们能让生成的代码具备更强的鲁棒性。实测在Python数据处理脚本场景中，这种方法使首次运行通过率从63%提升到了89%。

2. 核心设计思路拆解

2.1 CoT模板的测试工序注入原理

测试工序注入的本质是改变LLM的思考路径。普通提示词如"生成一个文件读取函数"会让模型直接输出最终代码，而我们的模板会拆解为：

1. 功能需求确认（明确输入输出）
2. 典型异常场景列举（文件不存在/无权限等）
3. 防御性编程要点
4. 单元测试用例设计
5. 最终代码实现

这种结构化思考过程显著提升了代码质量。例如在数据库连接场景，标准提示生成的代码往往忽略连接超时处理，而测试工序引导的版本会自动包含retry机制。

2.2 模板要素设计要点

一个完整的测试工序模板包含以下核心部分：

python复制"""
请按步骤完成[功能描述]的代码开发：
1. 输入验证需求（类型/范围/必填字段等）
2. 主要异常场景（至少列出3类）
3. 日志记录关键点
4. 单元测试用例（正常流+异常流）
5. 最终实现代码（含必要注释）
"""

实测发现几个优化技巧：

• 异常场景数量明确要求（3-5个效果最佳）
• 要求测试用例包含具体输入输出示例
• 对关键防御点用emoji标注（如🔐权限检查）
• 最后要求模型自我评审代码

3. 典型场景实现案例

3.1 文件处理函数生成

原始需求："写一个Python函数读取CSV文件"

改进后的CoT提示：

markdown复制请逐步开发安全的CSV读取工具函数：
1. 输入要求：路径(str)、编码(str, 默认utf-8)
2. 异常处理：文件不存在、编码错误、空文件、权限不足
3. 测试用例：
   - 正常：demo.csv(3列数据)
   - 异常：不存在的路径→FileNotFoundError
4. 实现要求：使用with语句、带行数统计

生成的代码会自动包含try-catch块和参数校验：

python复制def read_csv_safe(filepath, encoding='utf-8'):
    if not isinstance(filepath, str):
        raise TypeError("文件路径必须是字符串")
    
    try:
        with open(filepath, 'r', encoding=encoding) as f:
            reader = csv.reader(f)
            return list(reader), len(list(reader))
    except FileNotFoundError:
        logging.error(f"文件不存在: {filepath}")
        raise

3.2 API客户端生成

对于更复杂的场景如REST API客户端，模板需要分层设计：

python复制"""
开发Twitter API客户端：
1. 认证层：
   - 密钥存储方案
   - 过期处理策略
2. 请求层：
   - 重试机制（503/429处理）
   - 超时设置
3. 数据层：
   - 响应解析
   - 速率限制提醒
4. 测试方案：
   - Mock服务配置
   - 错误注入测试
"""

这种分层引导能使生成的代码具备生产级可靠性，避免常见问题如硬编码密钥、缺少重试逻辑等。

4. 效果评估与调优

4.1 质量评估指标

我们定义了三个维度的评估体系：

4.2 模板优化技巧

通过AB测试发现的改进方法：

1. 示例反哺：将模型之前生成的错误案例加入提示词

   python复制# 之前缺少编码处理导致的问题案例
   "避免直接使用open(filepath)而忽略encoding参数"
   

2. 模式强化：对关键模式使用固定句式

   python复制"所有网络请求必须包含：超时设置、重试机制、错误日志"
   

3. 领域知识注入：

   python复制"针对金融数据需要：数值精度校验、操作审计日志、双因素验证"
   

5. 常见问题解决方案

5.1 模型忽略测试用例

现象：模型直接跳过测试步骤
解决：在提示词中加入强制约束：

python复制"必须完成所有测试用例设计后才能输出实现代码"

5.2 异常处理过于笼统

现象：所有异常都用Exception捕获
优化：指定具体异常类型：

python复制"分别处理：FileNotFoundError, PermissionError, csv.Error"

5.3 边界条件缺失

对策：添加触发条件示例：

python复制"考虑：空文件、超大文件(>1GB)、特殊字符(emoji/换行符)"

6. 进阶应用模式

6.1 与CI/CD流水线集成

将CoT模板作为代码审查的第一道关卡：

mermaid复制graph LR
    A[提交请求] --> B{CoT检查}
    B -->|通过| C[MR创建]
    B -->|拒绝| D[返回改进建议]

6.2 多阶段验证流程

对于关键系统采用三段式验证：

1. 静态检查（模板合规性）
2. 动态测试（自动运行生成用例）
3. 人工复核（重点场景确认）

6.3 领域特定模板库

按领域积累专用模板：

• Web开发模板
• 数据科学模板
• 嵌入式模板

每个模板包含该领域特有的测试要点，如Web开发会强调XSS防护、CSRF检查等安全项目。

7. 工具链实践建议

7.1 提示词版本管理

像管理代码一样管理模板：

bash复制├── templates
│   ├── v1.0
│   │   ├── data_processing.md
│   │   └── web_api.md
│   └── v1.1
│       ├── with_security.md
│       └── with_perf.md

7.2 自动化测试集成

将生成的测试用例自动转换为pytest脚本：

python复制# 从模型输出提取测试用例
def convert_to_test(code):
    test_cases = re.findall(r"测试用例：(.+?)→(.+)", code)
    for input_, output in test_cases:
        yield f"def test_{hash(input_)}():"
        yield f"    assert func({input_}) == {output}"

7.3 效果监控看板

建立质量追踪指标：

• 首次运行通过率
• 测试覆盖率提升
• 缺陷逃逸率变化

这套方法在团队落地半年后，代码返工率降低了42%，特别是边缘场景的缺陷数量显著减少。最让我意外的是，新人通过这种模式产出的代码质量甚至超过了部分资深工程师的手写代码。