（回撤功能需要记录所有操作，图片是保存在数组中的操作记录。）

在vscode中TREA插件的帮助下，实现了回撤功能，插件调用的大模型是默认的DaouBao-seed-1.6。

不过，虽然模型根据我写的任务计划生成了代码，看起来非常不错，但事后看，尽管这些代码确实有用，但还远没有达到直接能用的程度。

我没有将代码直接自动插入到文件中，也没有复制拷贝，而是选择用手输入。这样做是为了在输入的过程中熟悉代码，有时能直接判断出生成的代码能不能用，做相应的调整。这个过程很快，因为本身就没有多少代码，再一个TREA本身也有代码补充功能。

我觉得最有趣的一点是，大模型会模仿整个文件的代码风格，这一点非常好，会非常便于理解。

写的任务计划中，有许多地方是考虑不周的，但大模型似乎意识到了这一点，生成的代码没有严格按照计划，但更好地完成了任务。

回撤任务主要有三个操作：移动(move)，发牌(call)，收牌(gather），在第一次的调用中，生成的代码就实现了所有的功能（不一定能运行），所有需要插入代码的地方，都生成了代码。

所以大体来说，大模型对于写代码，帮助还是很大的，它能快速生成一个“框架”，而如果没有大模型，这些东西都是需要自己写，也是很麻烦的。尽管代码细节上存在问题，但有了框架的存在，在思考问题的时，就能更快速地聚焦到核心问题点，省去了很大的麻烦。

不过有一点值得注意，就是一旦一个问题在初次任务中没有正确回答，在后续的继续提问中，可能也很难再回答好，特别是许多情况下，大模型会非常自信的反馈各种情况，并提出解决对策，但很可能从一开始，它对问题的理解就是错的，这就很有误导性。所以，如果几次下来，模型的回答都不理想，干脆换个模型问问（有几次想解决一些细节问题，模型的回答不理想，就去问Grok，Grok的深入浅出能力似乎更强一些）。

后续补充

后续在测试的过程中，想到一个问题，在gather回撤时，只考虑了回撤完再执行一次redoMove或者redoCall，而没考虑另一种情况，就是发牌可能可能引起多次gather，也就是在发牌时，发出了多个A，而桌面恰好对应着多个2~13，于是引起连续收派（gather）。问题很好解决，只需要执行redoGather回撤时，把指令列表末尾连续的redoGather指令全部pop出来执行即可，最后再执行一次redocall。但这就遇到另一个麻烦的问题，原来的动画功能是靠简单的锁来顺序执行的，而解锁是放在动画末尾的回调中，而一旦多于两个动画，因为动画是异步执行的，就导致锁的失效，最终导致后续的代码无法正常执行。

很明显，要解决问题，必须用异步函数。先用豆包大模型写了一个方案，瞅了一眼代码，不满意，又换了DeepSeep V3.1又写了一个，感觉还是不太好，最后试试gemini（从一开始就应该用gemeni，一步到位），很不错。

一次发牌引起三次收牌，修复后的redoGather。