AI 首个补丁不是交付物：用真实 diff 给需求不确定性定价

明确结论

AI 生成的第一个补丁应被视为需求成本探针，而不是可直接合并的交付物。它把“这件事可能很复杂”的争论变成可检查的文件范围、测试难度、抽象边界和风险清单。

是否值得做，不能只看代码生成速度。真正的成本仍在人工验证、产品契约、隐私合规、发布与长期归属；只有团队能看懂、验证并愿意维护的变化，才是便宜的变化。

核心技术要点

• 探针必须受到明确约束：只做最小改动、沿用现有功能开关、不改变公开契约、补齐测试，并列出所有触及文件与已知风险。
• diff 的扩散范围是一种早期信号：如果一个展示字段牵动认证中间件、数据迁移或多个包，需求的真实边界已经超出最初描述。
• 测试是否容易补齐同样能暴露结构问题。无法在现有测试层验证的小变化，可能隐藏耦合、缺少可观测接口或需要新的产品决策。
• AI 只降低候选实现的探索成本；代码评审、回滚设计、支持负担与行为所有权不会随生成速度自动下降。

适用场景

• 后端字段已经存在，只需在既有界面展示或增加小范围筛选的产品请求。
• 有稳定测试与功能开关保护、可以快速验证影响面的成熟代码库。
• 产品与工程对需求规模判断分歧较大，需要用真实改动替代低置信度估算的场景。

实践建议

• 为探索型补丁设置短时限和不可越过的边界，并要求输出 diff、测试结果、风险和未解决问题；超出边界即停止，不继续堆代码。
• 评审先看行为契约和所有权，再看代码是否能运行。涉及授权、计费、隐私、合规或数据保留时，即使 diff 很小也按高风险变更处理。
• 把探针结果记录回需求：触及模块、需要的产品决定、上线与回滚条件、后续维护人。只有证据支持低风险时，才进入正式实现。

局限与风险

• 这是 GitHub 工程团队提出的决策框架，不是经过对照实验验证的通用效率定律；团队能力、代码库质量和工具权限会显著影响结果。
• 首个补丁可能遗漏跨服务影响、隐性数据契约和运行时风险，不能用“测试通过”替代架构、隐私或安全审查。
• 对目标仍在变化、缺少验收标准或不可安全回滚的需求，先生成代码可能制造锚定效应，反而让团队围绕错误方案讨论。

延伸阅读

原始资料来自 GitHub Engineering Blog。建议结合官方文档的最新版本核对具体 API、限制和配置。