常规步骤
分类、抽取、校验、路由和修复，并不总是需要整套系统里最昂贵的模型。
模型成本与隐私
只在真正需要的地方使用大模型。
Flev 工作流可以把常规、结构化步骤路由到本地或私有小模型，同时保留强模型处理复杂推理。
可复盘路由
团队应该能看到哪一步用了哪个模型、为什么需要 fallback、谁能批准模型变更。
小模型就绪
Better Call 证据显示：3,625 个 granite4.1:3b BFCL v4 case 上，工具调用准确率从 73.4% 提升到 83.8%。
一次 release pipeline 在依赖和 Docker build 变更后失败。团队需要判断应该重试、打 patch、rollback，还是更新 runbook。
01
诊断简报
已确认
依赖安装已经成功，镜像 push 前失败；失败点在 Docker build 阶段。
可能原因
构建上下文里不再包含 Dockerfile 预期的 runtime artifact。
缺失证据
在批准 patch 前，需要检查上一次成功运行的 artifact 列表和 Dockerfile diff。
建议下一步
在 Docker build 前增加 artifact 显式检查，并把验证命令写进 runbook。
02
证据表
| 来源 | 看到什么 | 如何影响判断 |
|---|---|---|
| CI step log | Install 完成，Docker build 因缺少 runtime artifact 失败。 | 排除 package install 是主要失败点。 |
| Repository diff | Build script 修改了输出目录，但 Dockerfile 没有同步更新。 | 支持 patch 计划，而不是盲目重试。 |
| 上一次成功运行 | 镜像 build 前，artifact 曾经出现在旧路径。 | 说明 runbook 应该验证 artifact 位置。 |
03
Runbook 补丁
- Docker build 前列出预期 runtime artifact 路径。
- 如果 artifact 缺失，停止 release，并检查 build output 变更。
- 只有在 artifact 路径和 Dockerfile 一致后，才重试 pipeline。
- 记录修复点属于 script、Dockerfile，还是 release configuration。
04
审批边界
只读
检查 CI 日志、diff、run history、Kubernetes events 和已有 runbook。
需要审批
开 PR、push patch、publish package、deploy、rollback 或修改集群状态。
永不自动
生产部署、凭证变更、破坏性集群命令，或客户可见沟通。
Flev DevOps
从你的失败路径开始
发送一条失败工程路径，我们帮你收敛最小可购买试点。
这不是需求文档表演。目标是给出足够上下文，让双方判断一个 7 天诊断冲刺是否能产出有用结果。