这真的不是危言耸听，这是真的骇人听闻。盘点一下我遇到大模型的智障行为，本文不定期更新。

大模型至今不了解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，现在在这方面，我有信心可以说，我可比大模型强多了。