双重验证技能 / Double-Check Skill#
本技能适用于 任何文件修改场景,包括代码、文档、配置、资源文件的添加、修改、删除、重构与更新等。 核心要求:只要用户请求修改任何文件,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、 mkdocs build、 markdownlint 等),优先使用这些命令进行验证。
- 如果没有标准验证命令,则与用户协商一个可执行的检查方式(如运行主程序、执行构建脚本、或使用已存在的校验脚本),通过退出码(0 表示成功)和错误输出来判断是否正常。 注意:这种方式只能发现运行时/构建层面的错误,不能保证逻辑或内容正确性,需告知用户。
4. 第一次验证#
- 运行确定的验证命令。
- 捕获输出,判断是否通过(测试通过/编译成功/运行无报错且退出码为0)。
5. 结果处理#
-
如果验证失败:
- 向用户报告错误详情(错误信息、行号等)。
- 根据错误修正相关文件变更。
- 返回步骤 4(第一次验证)重新开始, 计数重置。
-
如果验证成功:
6. 第二次验证(同样严谨)#
- 立即再次运行相同的验证命令(使用相同的方式,例如同样包含
--no-cache 等选项)。
- 捕获输出,判断是否通过。
7. 最终判断#
-
如果第二次验证也成功:
- 向用户报告:✅ 双重验证通过!修改已完成且连续两次验证无错误。
- 结束任务。
-
如果第二次验证失败:
- 向用户报告失败详情(可能是偶发性问题或修改引入的新错误)。
- 根据错误修正相关文件变更。
- 返回步骤 4(第一次验证), 计数重置,重新开始双重验证流程。
🔧 验证方式示例#
项目类型推荐验证命令说明Node.js (有测试)npm test运行测试Node.js (无测试)node index.js运行主程序,检查是否报错Python (有测试)pytest 或 python -m unittest运行测试Python (无测试)python main.py运行主程序,检查是否报错Rustcargo test 或 cargo check运行测试或编译检查Gogo 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 负责确保修改后的文件质量。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.