双重验证技能（代码版） / Double-Check Skill (Code Edition)

本技能适用于修改代码后需要确保质量的场景。核心要求：每次修改后，必须连续执行两次验证（如测试、编译、代码检查），且两次均无错误，才能结束任务；否则继续修正并重新验证。

📌 适用场景 / Applicable Scenarios

• 修复 Bug 后运行测试用例。
• 添加新功能后确保原有测试通过。
• 重构代码后检查编译/类型错误。
• 调整代码风格后验证 lint 规则。
• 任何代码修改后需要保证正确性的任务。

🧠 核心原则 / Core Principles

1. 修改 → 验证 → 修正 → 再验证：任何代码修改都必须经过验证环节。
2. 两次连续成功：必须连续两次验证均无错误，才能视为最终成功。
3. 独立验证：两次验证应是独立执行的（例如间隔几秒，或使用不同验证方式），避免偶然因素（如缓存、随机失败）。
4. 验证方式应与项目匹配：根据项目类型选择合适的验证命令（测试、构建、lint 等）。
5. 清晰报告：每次验证后向用户报告结果（成功/失败，错误详情）。

📋 执行步骤 / Execution Steps

1. 理解任务

• 明确用户希望修改的代码文件/功能。
• 确认项目类型和可用的验证命令（可询问用户或根据文件推断）。

2. 执行修改

• 按照用户要求修改代码。
• 记录修改内容（便于回溯）。

3. 第一次验证

• 运行与项目匹配的验证命令（见下文示例）。
• 捕获输出，判断是否通过。

4. 结果处理

• 如果验证失败：
  • 向用户报告错误详情（错误信息、行号等）。
  • 根据错误修正代码。
  • 返回步骤 3（第一次验证）重新开始，计数重置。
• 如果验证成功：
  • 记录“第一次成功”。
  • 进入步骤 5。

5. 第二次验证（独立执行）

• 等待片刻（建议至少 2-3 秒），确保与第一次验证有时间间隔，避免缓存影响。
• 再次运行相同的验证命令（或可选的替代验证，例如以不同顺序运行测试）。
• 捕获输出，判断是否通过。

6. 最终判断

• 如果第二次验证也成功：
  • 向用户报告：✅ 双重验证通过！修改已完成且连续两次验证无错误。
  • 结束任务。
• 如果第二次验证失败：
  • 向用户报告失败详情（可能是偶发性问题或修改引入的新错误）。
  • 根据错误修正代码。
  • 返回步骤 3（第一次验证），计数重置，重新开始双重验证流程。

🔧 常见项目验证命令示例

项目类型	验证命令	说明
Node.js (npm)	npm test	运行测试
	npm run lint	代码风格检查
	npm run build	构建检查
Python	pytest	运行测试
	flake8 或 pylint	代码风格检查
	mypy .	类型检查
Rust	cargo test	运行测试
	cargo check	快速编译检查
	cargo clippy	Lint 检查
Go	go test ./...	运行测试
	go vet	静态检查
Java (Maven)	mvn test	运行测试
	mvn verify	集成测试+验证
通用	make test	自定义测试
	make check	自定义检查

如果项目没有标准验证命令，必须先与用户协商确定验证方式（例如：手动检查点、运行特定脚本、在沙箱中运行等），然后才能开始修改。

💬 用户交互示例

用户：帮我修复这个函数，它在输入负数时会崩溃。（附代码）

AI（应用本技能）：

1. 分析问题，修改函数使其能处理负数。
2. 运行 npm test（第一次验证）→ 测试通过。
3. 等待 3 秒，再次运行 npm test（第二次验证）→ 测试通过。
4. 报告：✅ 双重验证通过！函数已修复，连续两次测试无错误。

---

用户：把这个 Python 脚本的循环改成列表推导式。

AI：

1. 修改代码。
2. 运行 pytest（第一次验证）→ 失败（某个测试用例断言错误）。
3. 报告错误详情，修正代码。
4. 再次运行 pytest（第一次验证重置）→ 通过。
5. 等待 3 秒，第二次运行 pytest → 通过。
6. 报告：✅ 双重验证通过！修改已完成，所有测试通过。

---

用户：更新这个 Go 模块的依赖版本，确保不破坏构建。

AI：

1. 更新 go.mod。
2. 运行 go build ./...（第一次验证）→ 成功。
3. 等待 3 秒，再次运行 go build ./...（第二次验证）→ 成功。
4. 报告：✅ 双重验证通过！依赖更新后构建正常。

---

⚠️ 注意事项 / Important Notes

• 验证命令可用性：本技能需要验证命令在环境中可用。如果无法执行（例如没有测试环境），应与用户协商替代方案（如模拟运行、人工审查）。
• 连续两次：强调“连续”意味着两次验证之间没有新的代码修改，只有等待。
• 超时处理：如果验证命令运行时间过长（例如超过 5 分钟），可提示用户并建议手动检查，或允许用户中断。
• 测试依赖：对于依赖外部服务（如数据库、网络）的测试，提醒用户确保环境正确。
• 与版本控制结合：建议在修改前创建提交点或暂存更改，以便回滚。

🚀 与现有技能结合

如果你已在用 answer-framework 技能，可以这样结合：

“请用 answer-framework 先帮我分析这个 Bug，然后用 double-check-code 确保修改正确。”

---

记住：代码质量不是偶然，而是双重验证的结果。
Remember: Code quality is not an accident; it's the result of double-checking.