我们AI智能获客系统有一个评论监控的功能，其功能是监控某个视频下的新增评论并对其进行高意向分析，再将数据入库。

因为有些赛道对于评论用户的时效性比较高，如果能够快速地发现这类用户并及时联系他，（发送评论的30分钟内）那么他成为客户购买产品的概率则会大大增加，反之如果你不能及时发现这类用户，很可能被同行抢先联系他，另外时间久了之后他的购买意愿也可能会下降。

这个接口有一个cron的参数，即cron表达式，正常来说我们应该每一轮执行结束之后发起一个回调，但是当时一方面还是自己经验太少了，另一方面是没有认真思考，没有认真设计，当时在周末，想着快速把需求做完。设计回调的时候没有针对每一轮结束之后发起回调，而是只设计了一个completed的回调，因此，如果不传cron的时候，则只会执行一轮，所以会在这一轮结束的时候发送回调（这也是因为我当时在本地测试的时候没有发现的原因，当时为了省事，想着这个只测一轮应该就行了，因此当时测试的时候并没有传递cron参数，所以当时并没有发现这个问题），而如果传cron参数，则会只在整个视频监控结束之后才会发送completed回调，因此这个completed回调很可能永远不会发送。因此就出现了下面的问题。

问题的开端

中台开发人员说任务的completed没有回调，然后我当时还是很迷惑，为什么会没有回调呢？因为我当时vibecoding预想的是评论抓取任务结束之后是有对应的回调并告知他这一轮的高意向用户的数据，但是这和我预想的完全不一样，后续我思索了一番，一开始感觉可能是报错了导致没有任务完成的completed，但是我心想，这不对，报错了会有failed的回调，于是，我先定位到具体的监控ID，根据监控id在线上服务器中找到对应的日志，我大概看了一下日志，确实没有回调completed，然后我让codex先分析了一下，当然这个问题不是特别大的问题，codex很快就分析出来了，他给出的原因也很简单，因为这是一个监控任务，需要持续监控抖音视频的评论，并且对评论分析，得出高意向用户数据。所以这里会有一个cron的参数，来配置多久来进行一次抓取的任务来抓取这个抖音视频下的新增评论，没有配置，则只会执行一次，配置了则按用户配置的cron表达式来定时执行。当时我看到这个没有回调completed的原因之后，当时的第一想法是把这个if去掉，

然后不管他有没有配置cron这个参数，抓取任务结束之后都会有completed的回调。之后我的mentor跟我一起分析了一下这个问题，从一个更高的视角来思考目前回调的状态的逻辑性问题，其实这是我的一个逻辑性问题，我的回调的状态的scope是以视频监控任务为准的，而不是以内部的每一个评论抓取任务为准。因此会出现这样的一个问题（有cron，则是整个监控任务完成之后会回调completed，没有cron，则是只会执行一轮，执行完一轮抓取任务之后就会回调completed）

知道了这样的一个原则性的问题之后，改起来也很简单，我们可以把所有的回调状态都改一下，改成以抓取任务为准即可，抓取完一轮就回调completed。这样确实可以解决这个问题，并且中台那边也不需要改。而后我们又想了另一种方案，保持当前的一个逻辑，我们添加一个success状态 的回调，在抓取任务成功之后会有这个回调，这样我们这边的改动就很小了，然后让中台那边修改一下代码，使用我们的success状态的回调，而不是之前的completed的回调。

其他

• 在完善项目可观测性的时候，我们通常要添加日志，日志需要分不同的等级，以及我们需要知道不同的内容属于哪种等级的日志，在开发期间，日志的等级通常是debug模式，而在生产环境，如果我们开debug模式，会积累大量的日志，并且可能很多日志并不是真正有用的，因此可以使用info等级的日志，并对debug等级的日志开启缓行缓冲区（即可以将固定的最近N条debug日志保存在内存中，如果出现了error，则会将他们写入磁盘，正常情况则不会写入磁盘），因此这样既可以保证不会产生大量的无用日志导致磁盘空间不断增长，也能在发生错误的时候捕获到详细的debug日志情况，用来排查问题。