用户会看到的失败

用户让 AI 做一件普通动作：生成报告、更新记录、检查 ticket，或者调用内部系统。AI 选对了动作，但参数格式包错了。用户看到的是失败，虽然意图其实很清楚。

这种失败很烦，因为没人真的做错事。产品理解了请求，工具也存在，失败只是机械格式问题。

只修机械错误

Better Call 可以在工作流中断前修复无害的结构问题。它不应该编造缺失业务事实，不应该猜 ID，也不应该把含糊请求变成确定动作。

修复过程也应该可见：收到什么、改了什么、为什么允许继续。

用户得到什么

产品应该在正确的地方保持无聊和稳定。

flowchart LR
  A[用户痛点] --> B[有边界的工作流]
  B --> C[可审查的动作]
  C --> D[可复盘的证据]
  D --> E[可重复的结果]

如何判断

有用的修复层应该减少可避免失败，保留原始动作便于复盘，并在缺失的是业务含义而不是格式时停下来。

产品承诺很简单：用户意图清楚、修复只是机械问题时，工作流应该继续。