kimi code 2.5 还是不如 cursor
一个 Bug,计数器被重置了，返回的序号变小，入库时唯一索引冲突了。 同样的代码，同样的提示词丢给他俩。 cursor 是这样的：
之后改完代码就正常了。
Kimi 是这样的：
最好自认为找到了一个原因，然后改了代码，啥作用没起。
via V2EX - 技术 (author: jedeft)
一个 Bug,计数器被重置了，返回的序号变小，入库时唯一索引冲突了。 同样的代码，同样的提示词丢给他俩。 cursor 是这样的：
我先定位这个 batch 接口里“日序号冲突”的生成逻辑，重点看 checkin_handler 和 checkin_day_seq ，确认为什么同一批次里会拿到重复序号，然后直接改代码并帮你验证。
已经定位到根因了：checkin_daily_counters.last_seq 可能落后于 checkin_records 里已有的最大 day_seq ，批量接龙时会重新分配到已存在的序号（比如又分到 1 ），触发唯一索引冲突。
我现在会在序号分配函数里增加“与历史最大序号对齐”的兜底，确保永不回退。
之后改完代码就正常了。
Kimi 是这样的：
我看到错误信息了。这是一个数据库唯一键冲突错误。让我查看一下相关的代码来理解问题。
我找到问题了！让我查看数据库模型中的唯一键定义：
现在我明白问题了！
让我检查一下是否有其他问题：
我发现问题了！ NextCheckinDaySeq 函数在同一个事务内循环调用时.....
让我再看一下
让我再确认一下
啊，我明白了
等等，我再看看
啊！我发现问题了！
这不是问题所在。让我再想想...
哦！我发现真正的问题了！
这应该没问题。
等等！我发现问题了！
啊！我想到了！
让我再仔细看一下... 哦！我发现问题了！
让我再想想... 啊！我知道了！
等等，不对。在同一个事务中，应该能读取到更新后的值。
模型看起来没问题。让我再仔细看一下问题...
让我再检查一下 handler 代码... 啊！我看到了真正的问题！
最好自认为找到了一个原因，然后改了代码，啥作用没起。
via V2EX - 技术 (author: jedeft)
