人工智能修复并不会因为听起来很自信而变得值得信赖。当它保留了已经使生产变更安全的工程工作部分时，它就变得值得信赖：证据、所有权、审查、测试和明确的合并决策。
这种区别很重要。使用正确上下文打开拉取请求的工具可以节省时间。默默地更改生产代码的工具要求团队接受新的操作风险。
从边界开始
第一个设计决策不是使用哪种模型。这是模型被允许做的事情。
对于大多数团队来说，安全边界如下所示：
- 人工智能可以检查生产信号。
- 人工智能可以将这些信号映射到代码。
- AI可以起草补丁。
- AI可以解释其推理。
- 工程师批准、编辑、拒绝或合并。
这仍然是一个强大的工作流程。它消除了事件响应中无聊的部分，同时又不会将责任从拥有系统的人身上移开。
为什么“修复它”是错误的默认设置
生产失败是混乱的。同样的错误可能意味着错误的部署、缺少护栏、需要背压的队列、客户数据边缘情况或上游提供商的行为与预期不同。
当系统从症状直接跳转到代码更改时，审阅者无需调查即可获得补丁。他们必须对补丁存在的原因进行逆向工程。这会减慢审查速度，并使自动化感觉有风险，即使代码是合理的。
更好的默认是证据优先：
显示生产行为，显示可疑的代码路径，显示建议的更改，并显示可能出现的错误。
最后一部分很重要。当证据不完整时，补救系统不应假装确定。它应该使不确定性变得可见。
控制点应保持人性化
团队应该在正常工作流程中保留一些决策。
所有权和范围
正确的代码所有者应该决定提议的修复是否适合服务边界。这可以防止狭隘的事件变成广泛的架构变化。
产品判断
有些故障在技术上很容易修复，但对产品敏感。在代码更改之前，支付重试错误、权限边缘情况或计费状态不匹配可能需要产品上下文。
测试置信度
人工智能可以建议测试，但工程师应该决定信心的含义。一项修复需要进行单元测试。另一个需要重播事件。另一个需要迁移检查和回滚路径。
合并审批
合并决策应该在团队现有的拉取请求流程中保持可见。这可以保持安全性、合规性和所有权政策的完整性。
人工智能绝对应该做什么
保持审批人性化并不意味着工作流程是胆怯的。人工智能应该接管人类经常重复的工作：
- 对相似的错误事件进行聚类，而不是展开五个单独的调查
- 将堆栈跟踪和嘈杂的日志汇总为一份可读的事件记录
- 查找最相关的存储库、文件、函数和所有者
- 将失败与最近的部署和代码更改进行比较
- 起草一个带有简单英语解释的最小补丁
- 添加建议的测试或审查检查
- 将非代码后续路由路由至 Jira、Linear 或 GitHub 问题
这就是节省时间的来源。审阅者从准备好的案例文件开始，而不是一堆断开的信号。
拉取请求是接口
对于工程团队来说，拉取请求已经是协商风险的地方。它包含差异、评论、CI、所有权和批准历史记录。人工智能修复应该使用该表面，而不是创建一个新表面。
有用的补救 PR 应包括：
- 引发调查的生产信号。
- 系统认为负责的代码路径。
- 建议的补丁。
- 补丁背后的原因。
- 已运行或应该运行的测试。
- 置信水平和任何假设。
这种结构为审稿人提供了具体的评估内容。他们可以不同意诊断，改进补丁，或者在证据有力时快速合并它。
简单的政策模型
团队可以从三个策略级别开始。
仅草稿
系统可以创建拉取请求，但不能自动请求审查。对于评估信号质量的团队来说，这是良好的第一步。
审查就绪
当证据充足时，系统可以打开拉取请求、分配所有者并请求审查。这是大多数团队应该追求的默认值。
自动合并受约束的更改
该系统只能合并符合严格策略的狭窄、可逆的更改。这应该很少见、有记录并且易于禁用。
大多数组织不需要从第三级开始。它们在第二级获得有意义的价值，因为昂贵的部分通常是诊断和初稿。
警惕虚假信心
故障模式并不是抽象意义上的“人工智能写出糟糕的代码”。更尖锐的失效模式是一个带有薄弱证据的抛光补丁。
审阅者应该能够判断系统是否找到了根本原因，或者只是找到了附近的文件。良好的工作流程揭示了从生产信号到代码更改的链条。薄弱的工作流程将这条链隐藏在自信的摘要后面。
如果证据薄弱，该工具应该这样说，并将问题作为调查而不是解决方案进行处理。
好看的是什么样的
良好的人工智能修复感觉就像高级工程师在审核前完成了准备工作。拉取请求并不神奇。它的组装得非常好：
- 该问题已进行重复数据删除
- 相关日志汇总
- 代码路径被命名为
- 补丁很小
- 推理是可见的
- 审稿人仍然负责
这就是平衡。让AI压缩调查。不要让它抹去工程判断力。
