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