流萤简历实现AI失败不扣次，依赖预占机制与状态机设计

当一款AI产品宣称“失败不扣次”，这句简短承诺背后涉及的系统设计远比表面复杂。以简历生成工具“流萤简历”为例，其技术实现并非简单地在模型返回错误时跳过扣费，而是构建了一套完整的操作生命周期管理体系，涵盖请求身份识别、额度预占、状态追踪、故障恢复与结果校验等多个环节。

流萤简历的“失败不扣次”并非指所有失败尝试都不产生影响——例如频控限制仍会统计失败请求次数——而是特指成功消费账本（即真正计入已用额度）仅发生在结果合格且用户确认应用之后。这一区分至关重要：它将“服务调用行为”与“用户有效使用”解耦，使产品能在承担模型调用成本的同时，保障用户权益不受技术波动影响。

图1展示了该系统的状态流转逻辑：一次操作从“创建并预占”开始，进入Running状态；若模型或业务流程成功，则转入“合格结果与业务写入成功”分支；若失败或超时，则触发回收路径。关键在于，状态机中不存在“失败后再成功”的直接转换——已失败的操作键不会被重试，而是要求用户发起新请求（返回RETRY_NEW_KEY），确保每次操作身份唯一、结果确定。

为支撑这一机制，流萤简历将用户额度拆分为多个维度：总配额（quantity）、已用（used）、预占（reserved）、退款冻结（refundFrozen）与已撤回（revoked）。可用次数计算公式为：

> 可用次数 = Σ(每份grant的剩余额度) = quantity - used - reserved - refundFrozen - revoked

其中，“预占”是实现“失败不扣次”的核心设计。当用户发起请求时，系统在极短的数据库事务内完成账号加锁、过期清理、额度检查与预占操作；只有在模型返回结果并通过结构校验后，才开启另一事务将预占转为已用。这种“短临界区+长外部调用”的分离架构，既避免了数据库连接因等待大模型响应而长时间阻塞，也防止了并发请求因余额检查窗口期导致的超额消耗。

图2清晰呈现了这一流程：用户请求携带requestKey与输入摘要，服务端先执行短事务（查重、锁用户、预占+创建操作），随后异步调用模型服务；收到文本结果后，进行结构与标准校验；最终在另一短事务中完成reserved减1、used加1及结果持久化。整个过程强调原子性边界——模型调用本身不在事务内，但其前后状态变更均受事务保护。

为何要引入requestKey与输入摘要？这是为防止“键复用误判”。例如用户第一次润色段落A，第二次改写为段落B却误用同一key，若仅按key返回缓存结果，将导致输出错配；若无条件重跑，则同一操作身份可能产生两个副作用。通过摘要比对，系统能准确判断：相同key+相同输入→返回已有结果；相同key+不同输入→拒绝复用；相同key+已失败→提示新建任务。这保证了操作幂等性与结果一致性。

在结果交付层面，“HTTP 200”并不等于可用结果。流萤简历对模型输出设有多层校验：检查finish_reason是否为stop、内容类型是否合规、文本是否为空或截断（如达到token上限）、JSON结构是否可解析。尤其在简历生成场景中，系统默认以用户真实经历为事实依据，JD仅用于调整表达重点，绝不允许将岗位要求虚构为用户已具备技能——这一规则由解析器硬性约束，确保生成内容可信、可编辑。

值得注意的是，该设计并未回避成本问题。模型提供商可能已在推理完成后计费，但产品选择由自身承担不合格结果的成本，不向用户转嫁。这意味着“用户未扣次”不等于“服务商零成本”，而是产品方在体验与成本间做出的主动权衡。

图3展示了流萤简历的前端交互逻辑：润色建议区与原文并列呈现，底部“应用建议”按钮初始禁用，直至生成完成；用户可随时取消，此操作仅终止当前流程，不视为一次消耗。这种“生成可见、应用可选”的设计，与后端的预占-结算机制形成闭环——用户看到的是可控的交互，背后是严谨的状态管理。

在当前AI应用普遍采用“按调用计费”模式的背景下，流萤简历的实践提供了一种更用户友好的范式：将计费锚点从“请求发出”移至“结果可用且被采纳”。这不仅提升了容错能力，也倒逼产品方加强结果质量管控与流程健壮性设计。其技术路径——预占账本、唯一操作身份、状态机驱动、异步结算——具有通用参考价值，适用于各类需保障资源公平分配与操作可追溯性的AI服务场景。

此类设计难点在于平衡一致性与性能：数据库锁范围需足够小以支持高并发，又需足够强以防止额度超支；状态转换需明确无歧义，又要兼容网络延迟与第三方服务不稳定。流萤简历通过将关键决策前置到短事务、将耗时操作移出临界区、并以操作ID而非时间戳作为状态依据,在工程实践中给出了可行解。

随着AI服务从“能用”走向“好用”，用户对确定性与透明度的要求将持续提升。如何让每一次失败都“有迹可循、不伤余额”，将成为产品竞争力的重要一环。流萤简历的方案虽聚焦简历场景，其底层逻辑却指向一个更广泛的命题：在不可靠的分布式系统中，如何为用户提供可靠的服务契约。