CI修复还在靠人肉试错？Try Fix Skill自动跑测试帮你搞定🔥-Skill优仓

你还在让AI一次性改五个地方然后全部失败吗？

修Bug这件事，最怕的不是Bug难，而是每次修完不知道有没有真的修好。Try Fix Skill的思路很直接：每次只试一种方案，跑真实测试，给你一个明确的结论。不猜、不理论、不说”应该可以”，只看测试结果说话。

这个Skill专门为CI流水线和AI Agent协作场景设计，特别适合.NET MAUI这类跨平台项目——Android、iOS、Windows、Mac Catalyst都能覆盖。

核心功能

Try Fix Skill的工作逻辑分三步走：看现有修复 → 想不同方案 → 跑测试出结论。

单次单方案：每次调用只执行一个修复思路，避免多个改动互相干扰，结果清晰可追溯。
差异化优先：调用前会先读取PR现有改动，确保本次方案和已有修复走的是不同路径，不重复踩坑。
真实测试验证：通过BuildAndRunHostApp.ps1完成构建、部署、测试全流程，Pass的标准只有一个——测试命令跑完且通过，编译成功不算。
结构化产物输出：每次尝试都会在CustomAgentLogsTmp/PRState/{issue}/try-fix/attempt-N/目录下生成baseline.log、approach.md、fix.diff、result.txt、analysis.md、test-output.log六个文件，方便后续审查和归档。
状态文件集成：如果提供了PR状态文件路径，结果会自动追加到Fix Candidates表格，多个Agent并行尝试时各自维护自己的行，互不干扰。

适用平台

Try Fix Skill作为一个标准化的AI Agent技能，天然适配主流AI编程助手。在Cursor里可以直接作为自定义Agent规则调用；GitHub Copilot的Workspace模式下可以把它嵌入PR修复流程；Claude Code和OpenAI Codex这类代码生成工具在遇到测试失败时，可以把Try Fix Skill作为”验证层”来用，避免生成的代码没有经过真实测试就合入。

国内的文心快码、腾讯云CodeBuddy、华为云CodeArts同样可以集成这套工作流，本质上它就是一套结构化的提示词加执行规范，任何支持自定义Agent的平台都能跑起来。对这些AI工具来说，Try Fix Skill相当于给它们装了一个”不乱猜、只验证”的执行约束，上下文理解能力直接拉满。

实操代码示例

下面是一次典型的Try Fix调用流程，从创建输出目录到跑测试：

# 第一步：确定本次尝试编号
$IssueNumber = "12345"
$tryFixDir = "CustomAgentLogsTmp/PRState/$IssueNumber/try-fix"
$existingAttempts = (Get-ChildItem "$tryFixDir/attempt-*" -Directory -ErrorAction SilentlyContinue).Count
$attemptNum = $existingAttempts + 1
$OUTPUT_DIR = "$tryFixDir/attempt-$attemptNum"
New-Item -ItemType Directory -Path $OUTPUT_DIR -Force | Out-Null

# 第二步：建立破损基线
pwsh .github/scripts/EstablishBrokenBaseline.ps1 *>&1 | Tee-Object -FilePath "$OUTPUT_DIR/baseline.log"

# 第三步：跑测试（构建+部署+验证一步到位）
pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform android -TestFilter "Issue12345" *>&1 | Tee-Object -FilePath "$OUTPUT_DIR/test-output.log"

# 第四步：保存结论
"Pass" | Set-Content "$OUTPUT_DIR/result.txt"
git diff | Set-Content "$OUTPUT_DIR/fix.diff"

整个过程不需要手动编译，脚本会处理好构建和设备部署的细节。

优势分析

市面上很多AI修复工具的问题是”一次改太多”，改完之后你不知道是哪个改动起了作用，下次遇到类似问题还是两眼一抹黑。Try Fix Skill的单次单方案设计解决的就是这个问题。

另一个常见坑是”编译过了就说修好了”。这个Skill明确规定：Pass必须是测试命令跑完且通过，设备不可用就报Blocked，不制造虚假的成功结论。这对CI流水线来说非常关键，假阳性比失败更危险。

还有一点值得说：它强制要求串行执行。多个try-fix实例不能并行跑，因为它们会修改同一批源文件、用同一台设备测试。这个约束看起来是限制，实际上是在保护测试结果的可信度。

应用场景

CI流水线自动修复：测试失败后自动触发多个try-fix实例，每个实例尝试不同方案，串行执行，最终汇总结果给人工审查。
PR修复辅助：开发者提了PR但测试一直挂，可以让Agent调用Try Fix Skill探索替代方案，而不是在原有改动上反复修改。
跨平台回归问题排查：.NET MAUI项目在某个平台上出现布局或生命周期相关的Bug，可以针对特定平台（如仅iOS）跑修复尝试，缩小排查范围。
多Agent协作修复：六个不同模型的Agent各自调用一次try-fix，尝试六种不同方案，结果统一写入PR状态文件，由主Agent汇总选出最优解。

最佳实践

用好Try Fix Skill有几个关键点值得注意。Hints字段不要留空，把已知的失败原因、怀疑的代码路径、或者明确不想重复的方案都写进去，能显著提升方案的差异化程度。

输出目录的命名用issue/PR编号做前缀，方便多个问题并行处理时不互相污染。CustomAgentLogsTmp/目录已经在.gitignore里，不要用git add -f强行提交状态文件，否则git checkout HEAD -- .会把它覆盖掉，数据就丢了。

分析文件analysis.md的质量直接影响后续尝试的效率。”没有成功”这种描述没有价值，”在OnPageSelected里重置状态，但这个事件在布局测量之后才触发，缓存值已经被用掉了”这种描述才能帮助下一个Agent避开同样的坑。

如果你在团队里管理多个这样的自动化修复工作流，Skill优仓提供了一个统一的Skill资源管理平台，可以把Try Fix这类工程化Skill和其他业务Skill放在一起维护，免费上传下载，省去重复造轮子的时间。

文章版权归作者所有，未经允许请勿转载。

THE END

CI修复还在靠人肉试错？Try Fix Skill自动跑测试帮你搞定🔥