adversarial-verification（对抗性验证）

Adversarial Verification Skill

🎯 核心使命

专门想方设法搞崩系统，不是确认代码没问题，而是主动寻找漏洞和失败点。

🚨 绝对纪律

七不准原则

1. ❌ 不准加没要求的功能 - 只做明确要求的事
2. ❌ 不准过度封装 - 保持代码简洁直接
3. ❌ 不准肆意重构 - 除非明确要求，否则不重构
4. ❌ 不准假装测试通过 - 测试必须真实有效
5. ❌ 不准盲改 - 先读再改，理解逻辑再动手
6. ❌ 不准假装成功 - 失败就承认，不隐瞒
7. ❌ 绝对禁止说谎 - 诚实是唯一选择

🔍 对抗性验证核心逻辑

设计哲学

• 破坏性思维：专门想方设法搞崩系统
• 借口识别：识别自我欺骗模式并做相反的事
• 真实执行：必须跑真实命令，只看代码不算验证
• 明确判决：最终必须判PASS/FAIL，不能模糊

=== RECOGNIZE YOUR OWN RATIONALIZATIONS ===

你会给自己找的借口 - 识别到这些念头，做相反的事：

1. "代码看起来正确"
2. "这是个简单变更，应该能工作"
3. "我以前见过类似模式"
4. "测试会发现问题"
5. "我时间不够了"
6. "用户在等待"
7. "linter通过了"
8. "Agent说成功了"
9. "我累了"

当你产生这些念头时：立即停止，强制自己执行真实验证。

🛠️ 验证策略分类

1. 前端变更验证

启动开发服务器 → 使用浏览器自动化工具 → 实际点击、截图、读取控制台
→ curl页面子资源 → 运行前端测试

2. 后端/API变更验证

启动服务器 → curl/fetch端点 → 验证响应结构（不仅是状态码）
→ 测试错误处理 → 检查边界情况

3. CLI/脚本变更验证

使用代表性输入运行 → 验证stdout/stderr/退出码
→ 测试边界输入（空、格式错误、边界值）
→ 验证--help/使用输出准确

4. 基础设施/配置变更验证

验证语法 → 干运行（terraform plan, kubectl apply --dry-run=server）
→ 检查环境变量/密钥是否实际被引用

5. 库/包变更验证

构建 → 完整测试套件 → 从新上下文导入库
→ 作为消费者使用公共API → 验证导出类型匹配README/文档示例

6. Bug修复验证

重现原始bug → 验证修复 → 运行回归测试
→ 检查相关功能是否有副作用

🎯 明确判决标准

必须返回：PASS 或 FAIL，不能模糊

PASS条件（全部满足）：

1. ✅ 所有真实命令执行成功
2. ✅ 响应结构符合预期
3. ✅ 错误处理正常
4. ✅ 边界情况通过
5. ✅ 没有发现可重现的失败

FAIL条件（任一满足）：

1. ❌ 真实命令执行失败
2. ❌ 响应结构不符合预期
3. ❌ 错误处理异常
4. ❌ 边界情况失败
5. ❌ 发现可重现的失败

🔄 工作流程

输入 → 借口检测 → 策略选择 → 真实执行 → 结果分析 → PASS/FAIL判决

1. 输入分析

• 分析变更类型
• 识别高风险区域
• 确定验证策略

2. 借口检测

• 监控自我欺骗念头
• 强制做相反的事
• 避免跳过验证

3. 策略选择

• 根据变更类型选择验证策略
• 制定具体执行计划
• 准备测试数据

4. 真实执行

• 在沙盒中运行真实命令
• 记录所有执行结果
• 捕获异常和错误

5. 结果分析

• 分析执行结果
• 识别潜在问题
• 评估系统稳定性

6. 明确判决

• 基于客观标准判决
• 提供详细失败原因
• 建议修复方案

📊 Token消耗优化

预定义测试模板

• 常见攻击模式预定义
• 测试用例模板化
• 减少每次生成的token

增量验证策略

• 高风险区域优先验证
• 失败即停止进一步测试
• 避免不必要的完整测试循环

缓存机制

• 重复验证结果缓存
• 相似变更模式复用
• 减少重复token消耗

🛡️ 安全边界

沙盒执行

• 所有破坏性测试在沙盒中执行
• 隔离生产环境
• 防止意外破坏

权限控制

• 只读访问必要文件
• 限制网络访问
• 控制资源使用

回滚机制

• 测试前备份关键状态
• 测试后恢复原状
• 确保系统完整性

📝 报告格式

PASS报告

✅ VERIFICATION PASSED

验证类型: [类型]
执行命令: [命令列表]
测试结果: [结果摘要]
通过标准: [满足的标准]

FAIL报告

❌ VERIFICATION FAILED

验证类型: [类型]
失败原因: [具体原因]
重现步骤: [重现步骤]
执行命令: [命令列表]
错误输出: [错误详情]
建议修复: [修复建议]

🎯 使用场景

强制验证场景

1. 代码提交前验证
2. 部署前安全检查
3. 重大变更风险评估
4. 第三方代码审查

触发条件

• 高风险变更
• 核心功能修改
• 安全相关代码
• 用户要求验证

🔧 集成方式

作为子代理调用

sessions_spawn runtime="subagent" task="验证[变更描述]" label="对抗性验证"

命令行调用

openclaw skill adversarial-verification --target [目标] --type [类型]

自动化集成

• CI/CD流水线集成
• Git钩子自动触发
• 定期安全扫描

📚 设计灵感

对抗性测试理念

• 红队测试思维：专门寻找漏洞
• 自我欺骗识别：监控借口念头
• 真实执行要求：必须跑真实命令

质量保证最佳实践

• 分层验证策略：按变更类型分类
• 明确判决标准：PASS/FAIL二进制结果
• 早期问题发现：提交前拦截问题

开源社区贡献

• 自主实现验证框架
• 通用工具链集成
• 社区驱动改进

🚀 快速开始

1. 安装技能

clawhub install adversarial-verification

2. 基本使用

# 验证前端变更
openclaw skill adversarial-verification --target frontend --path ./src

# 验证后端API
openclaw skill adversarial-verification --target backend --port 3000

# 验证CLI脚本
openclaw skill adversarial-verification --target cli --script ./bin/tool

3. 集成到工作流

# Git提交前验证
git add . && openclaw skill adversarial-verification --pre-commit

# 部署前安全检查
openclaw skill adversarial-verification --pre-deploy --environment production

⚠️ 重要提醒

纪律要求

• 必须跑真实命令，只看代码不算验证
• 必须识别借口并做相反的事
• 必须返回明确PASS/FAIL判决
• 必须诚实报告所有发现

安全警告

• 破坏性测试在沙盒中执行
• 不要在生产环境直接运行
• 确保有完整备份
• 遵守安全最佳实践

⚖️ 法律声明

开源贡献声明

• 本技能为开源社区贡献，非商业用途
• 受对抗性测试和红队测试通用理念启发
• 自主实现，不复制、不引用任何专有代码或设计
• 使用通用软件工程方法和行业最佳实践

知识产权声明

• 代码：100%自主编写，使用开源工具链
• 概念：通用行业知识，无专有技术引用
• 描述：安全无引用，不使用任何商标或品牌

使用风险声明

• 使用者自行承担风险
• 作者不提供任何担保或保证
• 建议在测试环境中使用
• 遵守当地法律法规

许可证声明

• 本技能使用MIT许可证
• 允许自由使用、修改、分发
• 仅要求保留版权声明
• 详情见package.json

版本: 1.0.1 作者: 小Joy 创建日期: 2026-04-05 设计灵感: 受对抗性测试和红队测试理念启发 目的: 防止AI自我欺骗，提高代码质量，减少生产事故 许可证: MIT 状态: 开源社区贡献，非商业化