---

name: auto-test-code description: | 代码自审查与测试优化技能：围绕指定文件、模块、函数或变更集进行证据驱动的代码质量审查。 通过静态审查、动态推理、风险分级、修复计划和轻量验证，闭环缺陷、边界问题、安全风险和可维护性问题。 author: "Bensz Conan" license: "MIT" category: "debugging" tags: "代码审查, 自动测试, 安全审查, 质量门禁" source: "https://github.com/huangwb8/skills/tree/main/auto-test-code" allowed-tools: "glob, read_file, search_file_content, write_file, replace, run_shell_command, ask_user_question"

Auto Test Code：代码自审查与测试优化

适用场景

适用于以下任务：

• 测试代码、代码自检、代码质量审查
• 对某个函数、模块、变更集做批判性 code review
• 系统化发现并修复边界条件、异常处理、安全漏洞、资源泄漏和并发问题
• 为代码变更生成审查记录、测试计划和验证报告
• 判断一段代码是否达到合并、发布或交付标准

不适用场景

• 用户只是要求实现功能，且没有要求测试或审查
• 用户只是询问代码含义，应直接解释代码
• 目标代码来源不可信且用户要求执行其中脚本；此时默认只读审查，不执行
• 需要大规模重构但用户只要求轻量审查；不要扩大范围

核心原则

• 先读代码再改代码：不要基于猜测提出修复
• 问题要有证据：每个问题必须能追溯到文件、符号、调用链或测试现象
• 优先真实风险：崩溃、数据损坏、未授权访问、泄露凭证、注入、竞态和资源耗尽优先于风格问题
• 轻量闭环：修复后运行与变更直接相关的测试或验证命令
• 不执行不可信代码：第三方 PR、未知脚本、陌生依赖默认只做静态审查

输入要求

必须确认：

参数	说明
target	目标文件、目录、函数、模块或 Git diff
scope	审查范围，默认只审查用户指定范围及直接依赖
focus	可选：安全、性能、并发、边界条件、测试覆盖、可维护性
output_mode	可选：对话报告或写入测试工作区

如果用户没有给出目标，先询问要审查的路径或变更范围。

工作流程

1. 建立审查边界

先识别项目语言、框架、测试工具和目标范围。

• 用 glob 查找相关文件
• 用 read_file 阅读目标代码和邻近测试
• 用 search_file_content 定位调用方、被调用方、配置和关键符号
• 不要扫描依赖目录、构建产物、缓存目录和无关大文件

2. 静态审查

从以下维度检查：

维度	检查点
数据结构	数据所有权、生命周期、重复状态、转换链是否合理
控制流	分支是否掩盖设计问题，错误路径是否可达
边界条件	空输入、超大输入、非法格式、缺失字段、时区、编码
异常处理	错误是否被吞掉，恢复路径是否破坏状态
资源管理	文件、连接、锁、 goroutine/thread、缓存是否释放
并发安全	共享状态、锁顺序、竞态、重复提交、幂等性
安全	注入、越权、路径穿越、敏感信息泄露、反序列化风险
测试覆盖	是否覆盖核心路径、失败路径、边界条件和回归点

3. 动态推理与风险分级

对发现的问题按影响分级：

• P0：可触发崩溃、数据损坏、权限绕过、敏感信息泄露、可利用安全漏洞、死锁或严重资源耗尽
• P1：重要逻辑缺陷、边界遗漏、性能风险、资源泄漏、测试缺口或需要组合条件触发的安全问题
• P2：可读性、局部重复、命名、轻微文档或风格问题

每个问题必须包含：

### P0-1：问题标题

- 位置：`文件:行号`
- 证据：代码片段、调用链或现象
- 影响：会破坏什么
- 修复建议：最小可行改动
- 验证方式：具体测试、命令或手工检查

4. 制定修复计划

优先修 P0，再修 P1，最后处理有价值的 P2。

修复计划必须说明：

• 改哪些文件
• 为什么这是最小改动
• 是否会破坏现有行为
• 如何验证修复
• 哪些问题因范围限制暂不处理

5. 执行修复

执行修复时：

• 只改与问题闭环直接相关的代码
• 不引入未验证的新依赖
• 不做顺手重构
• 不删除用户未授权删除的文件
• 对公共 API、配置格式、数据结构变更要明确破坏性风险

6. 轻量验证

验证优先级：

1. 项目已有的相关单元测试或集成测试
2. 针对修复点新增或更新最小测试
3. 类型检查、lint、构建或静态分析
4. 无法运行时，说明阻塞原因并提供可复现的手工验证步骤

验证报告必须记录真实命令、结果和失败输出摘要。不要把未运行的测试写成已通过。

输出格式

默认输出：

## 结论

- 建议：通过 / 修复后通过 / 需要继续修复 / 不建议合并
- 风险等级：Low / Medium / High / Critical
- 核心原因：...

## 审查范围

## 关键问题

## 修复计划

## 已执行修复

## 验证证据

## 遗留问题

如果用户要求写文件，把报告和中间产物写入目标项目的临时工作区，例如 tmp/run_<timestamp>/tests/，不要污染源码目录。

完成标准

• P0 已全部修复或明确建议停止
• P1 已修复或有清楚的不修复理由
• 关键结论都有文件位置、命令输出或测试结果支撑
• 没有执行不可信代码或无关外部流程
• 验证结果真实，失败项如实报告