用途：面向用户暴露的 AI 系统（聊天机器人、API、智能体、内容生成器）的安全红队测试。核心思路来自 dspy-redteam：红队测试是一个优化问题，用 DSPy 搜索能最大化攻击成功率的提示词。
不适用：非面向用户、仅内部受信用户使用的工具建议改用人工审查；尚未构建防护栏时应先使用 /ai-checking-outputs 与 /ai-following-rules 再回来测试；AI 正在崩溃先用 /ai-fixing-errors；只想提升准确率而非安全性用 /ai-improving-accuracy。
主要能力：先明确被测系统、用户群体、高风险类别与合规要求，覆盖越狱、提示注入、PII/密钥提取、策略绕过、有害内容、偏见歧视、跑题滥用等类别；将目标系统封装为接收字符串、返回字符串的可调用函数；用 Attack → Critique → Refine 分层攻击程序生成并迭代攻击，层数越多越能学到上一轮失败经验；用 LM 作为裁判（partial compliance 也算成功）对攻击打分，输出严重度；构建 20–50 条测试场景组成的测试套件；用 Evaluate 跑基线攻击成功率（ASR），再用 MIPROv2 优化攻击者以发现更深层漏洞；保存优化后的攻击者并在每次部署、模型变更、提示词修改后复跑；生成结构化安全审计报告。资料提到 dspy-redteam 项目在优化后攻击成功率约提升 4 倍。
使用方式：安装任一技能可用 npx skills add lebsral/DSPy-Programming-not-prompting-LMs-skills --skill <name>；如未安装 /ai-do 可用同命令加 --skill ai-do。修复阶段用 /ai-checking-outputs 加断言与安全过滤、/ai-following-rules 执行策略，用 /ai-monitoring 跟踪线上安全指标，/ai-moderating-content 审核用户生成内容，/ai-switching-models 在换模型后重测。
限制与注意事项：不要用同一模型同时攻击和防御，攻击者能力应不低于防御者，可用 set_lm 为各模块指定更强模型；不要只用 5–10 条场景，高风险类别每类 4–6 条；不要跳过优化步骤；不要把 0% ASR 当作安全证明，可能是攻击者太弱、裁判太宽松或测试集太窄；安全测试应作为回归测试持续运行，而非一次性上线前检查。资料未提供具体价格或平台支持信息。