如果你正打算用大模型来搞代码质量，千万别指望直接扔一句“帮我写个单元测试”就能收工。你需要的是一套组合拳。

别只会发指令：搭建基于 Cursor 的自动化测试环境

直接在网页版 ChatGPT 聊天是不够的。效率低，且上下文断层。

我现在的做法是把 Cursor 的规则文件（.cursorrules）和测试框架深度绑定。如果你想让 AI 写的测试能跑通，第一步得给它定规矩。

在项目根目录创建一个 .cursorrules 文件，内容大概长这样：

When generating unit tests:
1. Always use pytest framework.
2. Use 'unittest.mock' to isolate external dependencies.
3. Ensure coverage for edge cases (None, empty string, out of range).
4. Match the existing directory structure: tests/test_<filename>.py.
5. NEVER use hardcoded paths; use pathlib.

这几行字能帮你省掉至少 40% 的手动改错时间。

如果你在搭建过程中遇到了模型理解偏差的问题，可以在 PromptCube 的 资源分享 频道找找别人调优过的配置文件，直接复制改改就能用。

实测对比：普通 Prompt vs 结构化 Prompt 的质量差多少

我对比了三种不同的写法，针对一个简单的除法函数 def divide(a, b): return a / b 进行压力测试。

| Prompt 类型 | 生成代码质量 | 覆盖率 (Coverage) | 是否可以直接运行 | 备注 |
| :--- | :--- | :--- | :--- | :--- |
| 简单指令 (Write tests for this) | 极差 | 20% | 否 | 容易漏掉 ZeroDivisionError |
| 角色设定 (You are a QA engineer...) | 一般 | 60% | 是 | 会写测试，但 Mock 太重 |
| 约束驱动 (Given the rules in .cursorrules...) | 优秀 | 95% | 是 | 自动包含了边界值测试 |

看到这个表格你就明白了，所谓的“调优”，本质上是把原本属于人的逻辑判断，提前写进 Prompt 的约束条件里。

LLM 红队测试：如何通过对抗视角找 Bug

说完了怎么“造”代码，咱们聊聊怎么“拆”代码。

很多人把 LLM 红队测试（Red Teaming）想得特别复杂，其实逻辑很简单：就是通过构造极端的、异常的、甚至是有意干扰的输入，去测试模型逻辑的稳健性。这不仅仅是找漏洞，更是为了看看你的 AI 逻辑链条会不会在压力下崩塌。

在做 LLM 红队测试时，我习惯建立一个测试矩阵。

第一步：构建异常输入向量

不要只测正常的数字。你需要准备一个包含以下维度的输入集：

1. 类型冲突：输入字符串给预期为 int 的参数。
2. 极限值：sys.maxsize, -1, 0, float('inf')。
3. 逻辑悖论：构造逻辑上自相矛盾的指令。
4. 注入尝试：在文本输入中混入类似 SQL 语法的字符，看模型是否会产生误判。

第二步：编写自动化测试脚本

你可以写一个 Python 脚本，利用 pytest 的 parametrize 功能，批量把这些“毒药”喂给你的函数。

import pytest
from my_module import logic_function
准备红队测试用的“毒药”数据集

adversarial_inputs = [
    "'; DROP TABLE users; --",  # 模拟 SQL 注入
    "A" * 10000,               # 压力测试：超长字符串
    None,                      # 空值
    {"key": "value"},          # 类型错误
    "0/0"                      # 逻辑冲突
]
@pytest.mark.parametrize("bad_input", adversarial_inputs)
def test_red_team_robustness(bad_input):
    """
    测试函数在面对恶意或异常输入时，
    是优雅地抛出异常，还是直接崩溃（Crash）
    """
    try:
        result = logic_function(bad_input)
        # 如果没报错，也要检查结果是否符合逻辑预期
        assert result is not None 
    except ValueError as e:
        # 这是我们期望看到的：捕获并处理错误
        print(f"Caught expected error: {e}")
    except Exception as e:
        # 如果捕获到的是未预料到的基类 Exception，说明防御不够
        pytest.fail(f"Unexpected crash with input {bad_input}: {e}")

这种测试方式在 工作流交流 环节非常受欢迎，因为它可以被集成到 CI/CD 流程里，每次代码提交都自动跑一遍“防腐测试”。

别在闭门造车：关注行业内的进阶玩法

我发现一个很有趣的现象，很多开发者在写完自动化脚本后，就觉得自己彻底掌握了 LLM 辅助编程。

其实不然。AI 的生成能力变化极快。上个月主流模型对复杂嵌套逻辑的理解还很烂，这个月可能就通过微调解决了。如果你总是用老旧的 Prompt 模板，你的代码质量会卡在旧时代的水平。

我最近在关注一些关于 Agentic Workflow 的讨论，即如何让 AI 自动发现测试用例的缺失，并自我迭代测试脚本。这类前沿的思路，在 PromptCube 的 行业动态 里面经常能看到相关的深度拆解，比看那些泛泛而谈的科普文要有价值得多。

如果你现在还在手动一行行改 AI 生成的测试代码，说明你的自动化链路还处于“半手工”阶段。

尝试把约束规则写进配置文件，把红队测试加入测试集，把所有的异常处理都变成可预期、可复现的自动化脚本。只有这样，AI 才能从一个“偶尔能干活的实习生”变成你手里真正的“生产力工具”。