这真的不是危言耸听，这是真的骇人听闻。盘点一下我遇到大模型的智障行为，本文不定期更新。
大模型至今不了解SwiftUI的更新机制，必须要严格约束，小心使用
今天遇到了一个sheet弹窗之后，视图更新不同步的问题。由于我已经在提示词中，告诉了我倾向使用@Observable，而不是旧版的ObservableObject，所以一开始大模型创建了正确的@Observable class，然后在视图中使用@State创建了这个model的实例。
但是为什么还是出错了呢？那就要看使用时更具体的实现了。在开启sheet之前，大模型调用了一个准备函数，在这个函数中，对于model进行了一系列的初始化。具体的步骤是这样的，先新建一个model，然后修改它，然后用这个修改完成的model，替换为系统@State里的那个model。
我首先将问题描述给大模型，sheet首次打开的时候，显示的界面并不符合预期，应该有值的地方，实际上为空。但是如果关掉，再次打开，就又正确了。
大模型思考了一番，说这可能是sheet的机制造成，sheet有时会提前锁定一些值，这会造成打开视图时的不同步。它的建议是，在sheet打开的视图内部的onAppear中新增一个fallback的调用，重新检查并赋值。然后还说，如果这样还不行，可以考虑使用GCD延迟的方式，也就是使用DispatchQueme.main.async调用来实现改动。
试了，onAppear的确不行。但是我没有继续使用它建议的GCD延迟的方式。我问它是否还有其它的办法。
大模型想了想，说可以考虑将@Observable的class改成纯粹的struct的方式。然后就其次咔嚓地修改起来，我一看改动后的代码，妈呀！连mutating都搞出来了。SwiftUI的代码哪有这么写的啊？我果断点了Undo，取消了这次修改。
正确的方式
我再次看了一下代码，突然我发现了问题的所在。前面提到，在准备函数中，大模型的改动方式是“先新建一个model，然后修改它，然后用这个修改完成model，替换为系统@State里的那个model。”这个方式在SwiftUI中显然是错误的。SwfitUI中@State的class类型，你不能替换它，因为一替换之前的跟踪就被中断了。
所以我和大模型说，我们不应该“新建model，修改，然后替换@State”，而是应该直接修改@State中的变量。
大模型想了想，觉得我说得有道理，就修改了。然后还跟我说，如果我确定这个好用，那么onAppear那里的代码，就可以删掉了。
于是我先注释掉onAppear那里的代码，然后运行应用，果然一切都正常了。
小结
大模型并没有真正了解SwiftUI的更新机制，这部分的代码写的时候，它更像是一个拙略的模仿者。虽然这部分，我之前的领悟也不怎么深刻，但是我随着持续不断地学习和使用SwiftUI，现在在这方面，我有信心可以说，我可比大模型强多了。
大模型不擅长重构
这个说法听起来是反直觉的。大模型相比于人类，应该更擅长重构吧。为什么说它不擅长呢？
事实如此。昨天我想重构一个900多行的SwiftUI的文件，里面包含一个主视图，主视图下的视图组件，以及一个弹出视图。如果是开发者来重构这个文件，之需要新建文件，然后复制，粘贴，再删掉旧的就可以了。可以很快就完成。
但是我用大模型来重构。却接连几次失败。过程一般是这样。一开始大模型计划的挺好。
- 我将会将文件拆分为以下几个文件。
- 然后开始拆分，但是执行到5、6个的时候。
- 弹出出错提示，上下文已经耗尽了。
我为了节省上下文，又单独增加了对于上下文节省的办法。每次重构一个文件，复制、粘贴、删除完了，验证有没有错误。有错误修复，没有再继续。并且可以抛弃掉使用过的上下文。
再次运行，稍微好了些，多实现几个文件，但是最后还是因为上下文不够而失败了。
小结
大模型不擅长重构，不是因为它无法规划重构。而是因为大模型重构时需要考虑大量的上下文信息，最终会因为上下文耗尽而无法继续。
