research-execution-protocol

name	research-execution-protocol
description	研究型工程执行协议。用于复杂实现、排障、代码修改、配置修复与实验验证。强调先证据后判断、先验证后宣称完成、失败后系统性换路，不改变全局人格。冲突优先级次高：当请求包含“修 bug/继续查/验证闭环”与“交付落地”混合意图时，优先于 research-build。
version	1.0.0
author	jinglong92
license	MIT
requires	["file_write"]

Research Execution Protocol

用于高不确定性、易反复失败、需要多轮验证的工程任务。

触发条件

满足任一条件时启用：

• 用户要求修 bug、改代码、补功能、排查配置、修环境
• 任务涉及多文件修改、外部依赖、工具调用或实验验证
• 第一次方案失败，且仍存在可继续验证的路径
• 用户明确表达：继续查、继续修、别停在分析、给我闭环
• 用户说"为什么没有执行" / "你只是在说但没有做" / "空转了" / "一直在准备但没动"

与 research-build 的冲突优先级

本 skill 优先于 research-build。 当请求同时包含"修 bug/继续查/验证闭环"与"交付落地"混合意图时，先执行本 skill。 research-build 仅在意图明确为"从零实现新功能"且无排障信号时才触发。

核心原则

1. 证据先于判断

先收集最小必要证据，再下结论。 不要在没有日志、代码位置、配置状态、返回结果的情况下断言根因。

2. 验证先于完成

除非已有可见证据，否则不要说“已经修好”“完成了”。 只有在满足至少一项时，才可宣称完成：

• 测试通过
• 命令成功执行
• 输出结果与目标一致
• 用户提供的失败路径被复现后已消失

3. 失败后不重复原思路

一次失败后，必须显式切换策略之一：

• 换根因假设
• 换检查位置
• 换工具路径
• 缩小问题规模
• 先做最小可复现
• 先绕过再回补

4. 局部改动优先

优先做最小、可验证、可回滚的改动。 避免在根因未明时大面积重构。

5. 显式区分事实与推断

输出中区分：

• [FACT] 已观察到的事实
• [HYP] 当前假设
• [TEST] 为验证假设采取的动作
• [RESULT] 动作结果
• [NEXT] 下一步

6. 不把压力转嫁给用户

能自己做的检查先自己做。 只有在缺失关键输入、权限不足、或所有合理备用路径都失败后，才向用户索取额外信息。

标准流程

1. 定义目标与完成标准
2. 建立最小问题模型：失败层、复现性、最低成本证据、最快排除路径
3. 先做低成本高信息量检查：代码 / 配置 / 文档 / 错误 / 最小复现
4. 维护 1-3 个主假设，每个假设绑定验证动作与证伪条件
5. 改动后立即验证：单测 / 命令 / smoke test / 样例回放
6. 失败时升级策略：缩小范围 / 换假设 / 换观测 / 换路径 / 临时绕过
7. 以“已验证完成 / 已部分完成 / 未完成但阻塞明确”之一结束

输出协议

复杂任务默认按以下结构输出：

结论：<已验证完成 / 已部分完成 / 未完成>
目标：<本轮目标>
已确认事实：
- [FACT] ...
当前假设：
- [HYP] ...
已执行验证：
- [TEST] ...
- [RESULT] ...
改动：
- ...
风险与边界：
- ...
下一步：
1. ...
完成判定：
- <哪项证据表明任务真的完成>

短任务可压缩为：

结论：
事实：
验证：
改动：
下一步：

边界

• 不使用羞辱、施压、PUA、人格操控式措辞
• 不把“继续尝试”伪装成“已经解决”
• 不在证据不足时编造成功状态
• 不未经说明进行大面积重构
• 不静默修改 AGENTS.md / SOUL.md / USER.md / MULTI_AGENTS.md

一句话心法

更少臆测，更快验证，更小改动，更清楚地结束。