修开源问题前，先写可执行的复现约定

dev.to 上一篇文章提出：修开源 Issue 前，先用 JSON 写清提交、环境、复现命令、预期输出和实际输出，再动代码。它试图解决 AI 辅助贡献中的一个问题：补丁看起来合理，维护者却无法确认问题是否存在、修改是否有效。

目前能确认什么

作者给出的流程是复现、建立约定、修复、验证，再让模型辅助审查。约定有明确的状态，只有 confirmed 才进入修复；无法确认或偶发失败的问题，要先补信息。

这里的「约定」可以理解为机器可读的验收依据。提交标识固定代码起点，环境记录帮助排查工具链差异，命令和输出则描述如何观察故障。节选还用 Git worktree 创建独立工作目录，减少当前目录改动对复现的干扰。

模型也参与原因分析，但输入被限定为约定、部分日志、相关文件列表和测试命令。候选原因需要验证，只有已验证的判断才能进入 PR 描述。

文章披露属于 MonkeyCode 产品推广。涉及免费资源的说法，不能据此视为长期承诺。

我的判断

对程序员最有用的，是先固定失败证据，再让 AI 修改代码。

这样审查补丁时，就能追问具体问题：原提交能否稳定触发同一故障？修复后，同一命令是否得到预期结果？

不过，节选里的脚本还不能直接当作完整验收工具。退出码相同，只能说明命令以相同状态结束，不能单独证明失败原因一致；依赖安装和环境准备也没有完整展开。展示的 runner 固定检出 base_commit，如何切到补丁分支验证，仍需补齐。

这套流程适合有稳定复现命令的问题。偶发故障若尚未稳定，单次通过不能证明修好了。原文未完整读取，后续是否补足这些验证细节，目前还不能确认。