double-check

# 双重验证技能 / Double-Check Skill 本技能适用于**任何文件修改场景**，包括代码、文档、配置、资源文件的添加、修改、删除、重构与更新等。**核心要求**：只要用户请求修改任何文件，AI 应**自动应用本技能**，并在每次修改后执行以下双重验证流程： **激活标识**：每次启用本技能的回复以 ✅✅ 开头，便于你确认本技能已被调用。 - **连续两次验证**：修改后立即进行两次验证，**两次均无错误**才能结束。 - **同样严谨**：两次验证使用相同的方式（如相同的测试命令或运行命令），确保结果可靠。 - **自动触发**：无需用户额外提示，AI 应主动遵循本流程。 - **验证目标**：确保修改后的文件变更能够**顺利通过对应检查**（无编译/运行/构建/文档校验错误，且原有功能或内容不受影响）。 ## 📌 适用场景 / Applicable Scenarios 本技能应默认应用于所有涉及文件修改的请求，包括但不限于： - **修复 Bug** 后运行测试用例或运行程序检查。 - **添加新功能**后确保原有功能正常。 - **删除功能**后验证剩余代码是否能顺利运行，无残留错误。 - **重构代码**后检查编译/类型错误或运行程序。 - **调整代码风格**后验证 lint 规则。 - **更新依赖**后检查构建是否正常。 - **更新文档**后验证文档构建或校验规则。 - **修改配置**后验证构建/运行流程是否正常。 - 任何其他文件变更后需要保证正确性的任务。 ## 🧠 核心原则 / Core Principles 1. **自动应用**：AI 应识别出“修改文件”的意图，并自动激活本技能。 2. **修改 → 验证 → 修正 → 再验证**：任何文件修改都必须经过验证环节。 3. **两次连续成功**：必须连续两次验证均无错误，才能视为最终成功。 4. **同样严谨**：两次验证采用**完全相同的方式**（例如都运行 `npm test` 或 `python main.py`），确保一致性。 5. **独立验证**：尽管命令相同，但两次运行在逻辑上是独立的（例如不使用缓存结果，或使用 `--no-cache` 等选项），避免偶然因素。 6. **清晰报告**：每次验证后向用户报告结果（成功/失败，错误详情）。 ## 📋 执行步骤 / Execution Steps ### 1. 理解任务 - 明确用户希望修改的文件（增、删、改、重构等）。 - 确认项目类型和可用的验证方式（测试命令、构建命令、运行命令、文档/配置检查等）。 ### 2. 执行修改 - 按照用户要求修改文件（包括删除功能时，需一并移除相关调用、引用等）。 - 记录修改内容（便于回溯）。 ### 3. 确定验证方式 根据项目情况选择合适的验证方式： - **如果有标准测试/构建/文档校验命令**（如 `npm test`、`pytest`、`cargo check`、`make test`、`mkdocs build`、`markdownlint` 等），优先使用这些命令进行验证。 - **如果没有标准验证命令**，则与用户协商一个可执行的检查方式（如运行主程序、执行构建脚本、或使用已存在的校验脚本），通过退出码（0 表示成功）和错误输出来判断是否正常。**注意**：这种方式只能发现运行时/构建层面的错误，不能保证逻辑或内容正确性，需告知用户。 ### 4. 第一次验证 - 运行确定的验证命令。 - 捕获输出，判断是否通过（测试通过/编译成功/运行无报错且退出码为0）。 ### 5. 结果处理 - **如果验证失败**： - 向用户报告错误详情（错误信息、行号等）。 - 根据错误修正相关文件变更。 - 返回步骤 4（第一次验证）重新开始，**计数重置**。 - **如果验证成功**： - 记录“第一次成功”。 - 进入步骤 6。 ### 6. 第二次验证（同样严谨） - **立即再次运行相同的验证命令**（使用相同的方式，例如同样包含 `--no-cache` 等选项）。 - 捕获输出，判断是否通过。 ### 7. 最终判断 - **如果第二次验证也成功**： - 向用户报告：✅ **双重验证通过！修改已完成且连续两次验证无错误。** - 结束任务。 - **如果第二次验证失败**： - 向用户报告失败详情（可能是偶发性问题或修改引入的新错误）。 - 根据错误修正相关文件变更。 - 返回步骤 4（第一次验证），**计数重置**，重新开始双重验证流程。 ## 🔧 验证方式示例 | 项目类型 | 推荐验证命令 | 说明 | |----------|--------------|------| | Node.js (有测试) | `npm test` | 运行测试 | | Node.js (无测试) | `node index.js` | 运行主程序，检查是否报错 | | Python (有测试) | `pytest` 或 `python -m unittest` | 运行测试 | | Python (无测试) | `python main.py` | 运行主程序，检查是否报错 | | Rust | `cargo test` 或 `cargo check` | 运行测试或编译检查 | | Go | `go test ./...` | 运行测试 | | Go (无测试) | `go run main.go` | 运行主程序，检查是否报错 | | Java (Maven) | `mvn test` | 运行测试 | | Java (无测试) | `java -jar target/app.jar` | 运行打包后的程序，检查是否报错 | | 通用 (有 Makefile) | `make test` 或 `make check` | 自定义测试 | | 通用 (无测试) | 与用户协商运行命令 | 例如运行脚本、启动服务等 | ## 💬 用户交互示例 ### 示例 1：删除功能（有测试） **用户**：请删除用户登录功能，用不到它了。 **AI（自动应用本技能）**： 1. 定位并删除登录功能的相关代码（文件、函数、调用等）。 2. 运行 `npm test`（第一次验证）→ 测试通过（原有测试不受影响）。 3. 再次运行 `npm test`（第二次验证）→ 测试通过。 4. 报告：✅ **双重验证通过！登录功能已删除，剩余代码运行正常，所有测试通过。** ### 示例 2：删除功能（无测试，运行检查） **用户**：删掉设置页面的主题切换功能，没用了。 **AI（自动应用本技能）**： 1. 删除主题切换的相关代码。 2. **由于没有找到测试命令，与用户协商**：“我没有找到标准的测试命令。我可以运行 `python main.py` 来检查是否有运行时错误，这种方式只能发现程序崩溃，无法验证逻辑正确性。你同意吗？或者你有其他验证方式？” - 用户回复：“可以，就运行看看。” 3. 运行 `python main.py`（第一次验证）→ 程序正常运行，退出码 0。 4. 再次运行 `python main.py`（第二次验证）→ 程序正常运行，退出码 0。 5. 报告：✅ **双重验证通过！主题切换功能已删除，程序运行无报错。请注意，这仅验证了运行时错误，未检查其他功能是否受影响。** ### 示例 3：验证失败并修正（添加功能） **用户**：添加一个计算器函数。 **AI**： 1. 添加函数及相关代码。 2. 运行 `pytest`（第一次验证）→ 失败（新函数测试未通过）。 3. 报告错误详情，修正代码。 4. 再次运行 `pytest`（第一次验证重置）→ 通过。 5. 再次运行 `pytest`（第二次验证）→ 通过。 6. 报告：✅ **双重验证通过！计算器函数添加成功，所有测试通过。** ## ⚠️ 注意事项 / Important Notes - **自动应用**：本技能旨在**默认应用于所有文件修改任务**。AI 应主动识别文件修改意图并遵循本流程。 - **删除功能的特殊考虑**：删除功能时，需确保移除了所有相关引用（如调用、导入、配置），避免残留代码导致错误。 - **验证方式协商**：如果项目没有标准的验证命令，AI **必须**与用户协商确定验证方式（如简单的运行命令或构建脚本），并告知用户该方式的局限性（只能发现运行时/构建错误，不能保证逻辑或内容正确）。 - **验证命令可用性**：确保验证命令在环境中可用。如果无法执行（例如没有运行环境），应与用户协商替代方案（如人工审查）。 - **连续两次**：强调“连续”意味着两次验证之间**没有新的文件修改**，只有验证执行。 - **同样严谨**：两次验证应使用**完全相同的方式**（包括命令、参数、环境等），以确保结果一致且可靠。 - **验证独立性**：如果工具存在缓存机制可能影响结果，建议使用清除缓存的相关选项（如 `npm test -- --no-cache`、`pytest --cache-clear` 等）确保两次验证真实独立。 - **超时处理**：如果验证命令运行时间过长（例如超过 5 分钟），可提示用户并建议手动检查，或允许用户中断。 - **与版本控制结合**：建议在修改前创建提交点或暂存更改，以便回滚。 ## 🚀 与现有技能结合 如果你已在用 `answer-framework` 技能，本技能可与它自然衔接。例如，`answer-framework` 负责分析问题、组织回答，而 `double-check` 负责确保修改后的文件质量。AI 在收到文件修改请求时，应同时融合两个技能的指导。 --- > **记住：文件质量不是偶然，而是双重验证的结果。本技能应默认应用于每次文件修改。** > **Remember: File quality is not an accident; it's the result of double-checking. This skill should be applied by default to every file modification.**