Minimum viable change：让 AI 做最小可验证改动
Page card
- Part：Part 2 / 开发与 QA 进阶
- 适用角色：开发、QA
- 使用场景：让 AI 写代码、修 bug、补测试或处理 review comment
- 输出物：最小、可验证、可 review 的 change
Related jumps
Back to AI Workflow Sharing。相邻主题：Hypothesis loop · AI-assisted review · Agentic execution · Workflow design
Summary
重点：AI coding 的质量取决于 scope 和 success criteria 是否清楚。
好的 AI 改动应该是最小、可验证、能解释成功标准的，而不是顺手重构或扩大范围。
适用场景
- 修 bug
- 小 feature
- 处理 review comment
- 调整配置
- 补测试
- 修边界状态
工作方式
- 明确成功标准：什么命令通过、什么页面行为正确、什么 PR 状态可合并。
- 要求 AI surgical change：只碰必要文件，不顺手重构。
- 优先补一个能复现问题的 test，再修到 test pass。
- 改完必须给验证结果，而不是只说“已修改”。
- 如果验证受阻，要说明 blocker 和下一步，而不是跳过。
成功标准模板
Goal:
Scope:
Non-goals:
Files likely affected:
Test to add/update:
Verification command:
Remote validation:
可分享案例
- 修状态 guard：补充
ENDED/PAUSED等边界状态测试。 - 修 audio duration：加 test 覆盖
Infinity/NaN显示问题。 - 移除前端 validation：只回滚目标路径，不扩大到整个 PR。
可复用规则
没有验证结果的 patch 不算完成。 代码变更必须连接到明确的成功标准。
- 每一行改动都应能追溯到任务目标。
- 不为单次任务新增 speculative abstraction。
- PR summary 要写清楚改了什么、为什么、怎么验证。
- 常见验证命令应使用 code format，例如
pnpm typecheck、pnpm test、gh pr checks。
References
- The Art (and Science) of Reviewable PRs — 支撑“最小、聚焦、可回滚”的 PR 思路，适合映射到 AI 生成改动的 scope 控制。
- 8 pull request best practices for optimal engineering — 总结 PR 描述、范围控制、reviewer 体验等实践，可作为团队 checklist 参考。
- Workflow setup to make your coding agent ship small reviewable PRs incrementally — Reddit 讨论，直接对应“让 coding agent 产出小而可 review 的 PR”的实际经验。
- CI/CD for Evals: Running Prompt & Agent Regression Tests in GitHub Actions — 把 prompt/agent 变更纳入 CI 回归测试的例子，可用于扩展“可验证改动”的含义。