第八十四章：第一次当老板，我先赔了一次交付

何川打来电话时，我正在拎着打包的晚饭往回走。

塑料袋有点烫，我把它换到另一只手，接起电话。

“你看一下后台。”他说，“小孟那边一批文件还没出来，记录却多了一倍。”

我脚步停下来。

“什么记录？”

“任务，还有那个用量。我们重试了一次，原来那批好像也在跑。”

路边一辆车过去，声音很响，我往里让了让，先确认他们有没有继续点。

何川说暂时没动，等我回复。

“好，我马上看。先别再提交，我确认完给你一个时间。”

挂电话以后，我提着饭加快脚步。

第一次当老板，晚餐依然没有得到特殊待遇。

---

九月的那批任务，前几次处理都还顺。

文件量比演示多，我做过排队，也留了用量提醒，觉得至少基础链路能撑住。甚至在下午还给小璇发消息，说晚上可以按原计划吃饭。

她临时有自己的安排，我们把那顿改到之后，反而让我多出一点做事的时间。

我当时还觉得这晚挺宽裕。

打开后台以后，才知道宽裕只是我没看见事情正在发生。

同一批素材有两组任务，提交时间相隔不久。一组已经处理了大半，另一组又排进来，列表里完成和等待交错着，连我自己看第一眼都要停下来分辨。

我先查结果有没有损坏。

已经完成的文件还在，问题不是全部失败。我把受影响的任务先圈出来，暂停这一批进一步的重复处理，保留日志和当前状态，再看用量记录。

那一栏也被记了两次。

它还只是试点里的待核对用量，没有直接从客户账户扣钱，但客户看到的确实像自己为同一件事付了两遍。

更麻烦的是，他们看不清哪些结果能用，剪辑排期已经被卡住了。

我最先怀疑的是外部服务回调重发。

沿着记录查下去，却发现每组任务内部都对得上。旧经验让我知道回调要防重，偏偏这次重复发生在更前面：提交那一步。

我盯着两组不同的请求标识，心里沉了一下。

它们在系统眼里，是两次合法的新请求。

---

小孟后来把当时的操作说了一遍。

提交以后页面等了很久，没有明确结果。他以为没成功，按提示重试。第二次回来了新的任务列表，他过了一会儿再看，原先那组也出现了。

我让他不用继续试，自己拿测试材料重现。

第一遍没成功。

第二遍也没。

心里越着急，页面越正常，像故意挑我最需要证据的时候表现良好。

我想起伟源前两天说周末有空，可以帮我按实际使用方式点一轮。他已经发过一份短反馈，里面有一条我当时没有放到最前：网络慢时，用户不清楚提交有没有发生。

我把当前现象和脱敏后的操作过程发给他，先问方不方便看。

他过了一阵回复，可以看十来分钟，让我别只重试模型服务，先把提交响应延迟模拟出来。

我照着试，问题终于出现。

任务在服务端已经建立，页面没及时收到成功信息，重试时又生成了新的请求标识。此前做的防重只认同一个标识，当然不会挡住这次“新请求”。

我看着代码，半天没说话。

这不是我不知道幂等。

是我知道这个词，却没把用户按重试的那一刻算进去。

伟源又问了一句：如果用户确实想拿同一份素材重新做一次，怎么区分？

我原本准备按文件判断的思路又停住了。

同样的素材可以有新的任务，不能粗暴地把所有相同文件拦掉。需要区分正在恢复同一次提交，还是用户明确发起了新的一次处理。

他看我捋顺，说自己得先去忙，后面怎么改由我再验证。

我说谢谢，没有再往他那边塞一整晚的责任。

测试老师点出了题眼，卷子仍然是我自己的。

---

我给何川回电话时，已经能说明影响范围。

哪些任务重复，哪些结果可以先用，用量怎么核正，剩下的需要多久。我一项项说，尽量不用“应该”“大概没事”这种听完还得继续猜的词。

他听完问：“今天能不能都交？”

我看着剩余数量和处理速度，没有立刻答应。

“有一部分可以先给你，剩下的按现在判断要到明天。我不想先说今晚全好，半夜再让你等。”

电话那边安静了几秒。

“我们有一条明早要给客户。”

我让他指出那一条，先确认已有结果是否可用，再把确实缺的部分排到前面，告诉他我什么时候给第一批确认。

何川没有骂人，但语气已经明显冷下来。

“阿雷，这个东西要是让我比以前更担心，后面就很难继续。”

我说这次是我这边的问题，会按实际影响承担相应成本，具体减免和补交时间整理成文字，不让他靠记一通电话。

说完以后，盯着手机，心里很难受。

以前出问题，最怕领导问为什么。现在没人问我为什么还没下班，只有一个客户，需要我为他的明天负责。

桌上的饭已经凉了。

我先吃了几口，又给小璇发消息，说明在处理什么，今晚可能会晚，明天约好的安排要到上午确认后才能给她准确答复。

她回收到，让我别不吃饭。

没有一句“你忙吧”就默认她会无限等。第二天如果做不到，我得自己提前说。

---

修复先分成眼前和后面两部分。

眼前把重复任务与客户用量核清，已有结果按明确编号整理，给客户一个能直接对应的清单。确实重复消耗的成本，我承担，不能因为机器真的跑了两遍，就算到客户的操作失误上。

接着修提交过程。

同一次提交的标识留住，网络不确定时先查状态，再决定怎样继续。页面不再用一个笼统的失败提示引导用户重新制造一批任务；真正要新做一次，则让它成为清楚的新操作。

我又把任务和结果展示核了一遍。

处理完成的不能混在等待里，让人靠刷新猜；需要重试的也要说明是哪一项，不是一句失败就让整批重新来。

这些道理我以前讲过很多次，轮到自己的产品，仍然会在赶进度时漏掉一块。

我没再花时间骂自己怎么这么蠢，把能复现的条件留下，逐项验证。慢响应、重复点击、中途退出再回来、同一素材发起不同任务，都过了一遍。

到后来，眼睛有点发涩，我起身洗脸，回来重新看交付记录。

越到最后，越不能因为想赶紧结束，就把“看起来好了”当成“已经核过”。

第一批确认发出去，何川回复收到，让小孟先取用。

过了一会儿，小孟发来一句：“这几条可以，名字也对上了。”

我靠回椅背，终于缓了口气。

但那口气还没完全呼完，小孟又打来电话，说其中一条的片长跟他手上最新那版不一致。

我立刻坐直，先问是文件导错，还是后面改过片长。

他那边也在翻记录，过了一会儿说，是客户刚改了时长，自己着急，把新旧两版混在一起看了。

我没有顺势说一句“看吧，这回不是我的问题”。

原本他们就因为列表乱而额外花了时间，这时候再让他自己去证明是哪边记错，对交付没有帮助。

我们各自把手里的版本念了一遍，确认真正要赶的是哪一条。我把已经修好的版本和新改的需求分开放，告诉他这次先按已确认的结果取用，新增变化要重新看，不会混进事故补交里悄悄覆盖。

小孟嗯了一声，停了停，说自己也有点乱。

“我也是。”我说。

电话那边笑了一下，很短。

那晚我们没有因为共同熬夜就突然成了知己。他还有片子要赶，我还有错误要收。但至少聊到后来，大家都开始对着同一份东西说话，不再各自在慌乱里猜。

确认完，他说先去忙了。

我把刚才那条记录补好，才发现手边的水杯已经空了很久。

---

第二天上午，我按约给出剩余交付时间，并把本次修正和费用安排发过去。

何川对其中一项提出异议，觉得我们漏算了他们重新核对的时间。我没有说软件已经修好就不该再谈，跟他把实际影响对了一遍，最终确认一个双方接受的处理办法。

那部分钱落到自己的表格里，真的会疼。

原先想象中这一单做完能剩下的数字，被我划掉重算。

我第一次很直观地看见，错误不仅会占用夜晚，也会直接吃掉原本就不厚的结余。

杜姐听我说完，让我把对应的记录留好，别只记住心疼。

我说留了。

后来小孟把按时交出去的那条成片发给我看，征得他们同意以后，我才打开确认。这次没再拿分析结果当主角，而是从头到尾看完了那段视频。

音乐放进去，很自然。

如果没人告诉观看的人，他不会知道背后曾经多出一批任务，不会知道一个剪辑师等着结果，一个程序员坐在桌前反复核对。

我看完，给小孟回了收到，说这条相关的记录会按最终确认的版本保存。

然后坐着发了一会儿呆。

公司只有我一个人的时候，出了问题没有地方往后躲，可也没有人能替我宣布这件事到此为止。我可以因为熬了夜，觉得自己已经足够辛苦，客户却只能根据东西到底有没有交出来判断。

我把那天原本准备加的两个新功能往后挪了挪，给已经确认要补的检查留出时间。

又给何川发了一段很短的观察安排，告诉他接下来几批我会核哪些部分，什么时候汇总，遇到相同现象先怎样保留信息。

发之前删掉了两句“以后绝不会再有这种问题”。

这句话比修复代码快得多，也比我能做到的范围大得多。

何川隔了一阵回，说知道了，先看接下来用的情况。

没有原谅大会，也没有夸我负责。

我把回复看完，重新打开要检查的那一页。

下午跟小璇见面时，人还有点疲惫。她没让我从头做一次事故汇报，先看我把饭吃了，才问客户那边怎么样。

我说交完了，后面还得继续观察，合作没停，但信任要一点点补回来。

她嗯了一声，说昨天发消息讲清楚了，她这边也好安排。

我抬头看她。

这句很普通的反馈，让我比“没关系”更安心一点。

工作出了错，并不意味着我必须顺便把生活也拖进一场没人知道多久结束的等待。

吃完饭，我们去附近走了一会儿。我没有一直盯着手机，只在事先说好的时间看了一次，确认没有新的异常，把屏幕锁掉。

回到办公桌以后，我把这次的问题写成一页记录。没有堆满术语，也没有写成证明自己多辛苦的故事。

用户做了什么，系统为什么判断错，影响了谁，已经怎么处理，后面由什么来发现类似问题。

写完，我把负责人的名字填进去。

还是我。

不过这一次，后面终于跟上了几项不用靠我记性维持的检查。