1、截至目前，四款应用问题如下，加粗内容暂未修复：
1.DoitWith
-不包含任何Todo的分组下会显示“该分组暂无待办”，但底下还有半截分隔线，需要和正常的Todo条目下的分隔线格式一致
-设置-关于，DoitWith下面的小字和开屏上的小字是否一致？以设置-关于中的小字为准
-在Todo页面，没有“下一步”的Todo，在标题下显示“仅此一步”
-在已完成Todo页面，有下一步的Todo，在标题下显示“包含下一步”，没有“下一步”的Todo，在标题下显示“仅此一步”
-考虑到后续可能要和Mac版数据打通/同步（通过CloudKit，两个App绑定同一个iCloud Container），趁早将应用的数据持久化方式由Core Data改成SwiftData，和DoitWith for Mac的数据持久化方式保持一致，仅外观设置使用UserDefaults保存
-当天到期的Todo，早上九点推送通知
-添加小组件，小组件上显示当天到期的Todo，信息包括所在分组、标题、下一步
2.DoitWith for Mac
-调整新建分组、添加和编辑Todo窗口的视觉效果，部分图标和文字太小
-设置-关于页面下方增加“近期更新”区域，由Cursor总结近期更新了哪些功能
3.ChatWith
-清除后台后，再打开应用秒闪退，无法使用
-在与支持深度思考的模型对话时，可以看到思考内容区域，但看不到具体的思考内容
-发送消息后立刻显示在对话界面内，现在好像是在AI有响应后才会显示
-虽然可以看到Tavily已经联网获取了一些链接，但AI回答内容好像没有结合Tavily搜索结果
-参考链接引用10条，参考链接区域默认折叠，可展开
4.ChatWith for Mac
-关于页面的“初始版本发布”放到最上边
-优化上传附件和图片后的显示效果，比如取消附件和图标的红叉需要改小一些
2、近期的重点在于对齐移动版和Mac版的现有功能，修复明显问题，首先是DoitWith移动版，将数据持久化方式由Core Data改成SwiftData，步骤包括创建SwiftData模型文件，更新PersistenceController.swift、更新TodoData.swift、更新所有视图文件，删除旧的Core Data文件，修改过程中发现虽然Composer 1模型的修改速度非常快，但修改后出现多个语法错误，未能自动检测出来
3、接下来测试功能，让Cursor修复问题，首先是待办页的空状态提示，“暂无任务”改成“暂无待办”，“添加任务开始使用”改成“添加待办或分组以开始使用”，另外待办页无待办时，这些文字上方会显示一条分割线，需要去掉，出现分割线的原因是，以前在无待办时，List里仍有一个底部占位Section（Spacer高度200），该Section上方会出现分割线，修改之后，仅在有待办或分组时显示底部占位Section
4、然后测试添加、完成、修改、删除、搜索Todo和分组，测试发现问题如下：
1.不包含任何Todo的分组下会显示“该分组暂无待办”，但底下还有半截分隔线，需要和正常的Todo条目下的分隔线格式一致
2.在Todo页面，没有“下一步”的Todo，在标题下显示“仅此一步”
3.在已完成Todo页面，有下一步的Todo，在标题下显示“包含下一步”，没有“下一步”的Todo，在标题下显示“仅此一步”
5、之前遇到过的同一分组内的Todo无法通过拖动调整顺序的问题，这次测试未能复现，可能在修改数据持久化方式之后也给解决了？
6、继续优化ChatWith移动版，主要针对之前测试遇到的问题，包括：
1.在与支持深度思考的模型对话时，现在可以看到思考内容区域，但看不到具体的思考内容，只能看到“思考中…”的提示
2.用户发送消息后，需要立刻显示在对话界面内，现在好像是在AI有响应后才会显示
3.虽然可以看到Tavily已经联网获取了一些链接，但AI回答内容好像没有结合Tavily搜索结果
4.参考链接引用由5条加到10条，并且参考链接区域默认折叠，可展开
7、首轮修改之后，上述问题只有4已经被修复，换用内置的Kimi K2试一下，卡在分析问题的过程中，等了一段时间也没有对代码进行实际的修改，然后切换到Composer 1，修改速度很快，并且解决了“看不到具体的思考内容”、“回答内容未结合Tavily搜索结果”的问题，再次测试，要求进行如下修改：
1.思考内容区域要整合到AI消息区域中，即 最上面是思考区域（如果支持深度思考的话），然后是回答内容、参考链接，并且这三块要对齐
2.用户问题发送之后，对话界面应该立刻跳到新问题的位置，现在好像还需要手动往上划一下才能看到？
8、再次测试，上述问题好像也已经修复，但应用非常卡顿，可能是添加了太多调试信息导致的，后面再去掉，先继续用Composer 1尝试修复“清除后台后，再打开应用秒闪退”的问题，这次修改涉及生命周期管理、错误回复、超时保护、友好错误提示等，再次测试，应用直接无法正常启动了，要求Cursor清理所有的调试信息，并检查语法错误，首次启动速度是快了一点儿，但依然没有解决清除后台后无法启动的问题
9、决定换个思路，在ChatWith for Mac的基础上，适配一个iOS版，先让Curosr评估了下，首先，核心业务逻辑100%兼容，且有部分Flutter依赖已支持iOS，需要适配的部分包括部分原生平台代码、UI布局、几个macOS平台的特定功能（比如拖拽、粘贴、word文档和PDF文档解析），Cursor给出了完全兼容（使用条件编译和抽象层）和最小化适配两个方案，决定采纳方案1，希望这样可以减少后续对单独某个功能在Mac和iOS端的重复修改
10、由于存在代码隔离机制，macos和ios是独立的目录和Xcode项目，另有lib统一管理两个平台共用的代码，在后续测试时需要打开.xcworkspace文件，而非.xcodeproj文件，并且在修改共享的代码时要注意平台兼容性
11、分析的很简单，但实际操作时反复出错，比如因为权限问题不能创建项目文件，因为网络问题不能运行pod install等等，按照Cursor提供的文档手动创建项目后，又提示创建的项目不正确，反复修改了一段时间，仍未能修复
12、使用Cursor中的Codex插件检查该版本iOS应用的构建失败问题，几次修改后可以正常构建，但同样出现了ChatWith移动版存在的“清除后台后再打开应用秒闪退”的问题，结合Device Logs，Codex认为可能是一些依赖导致的崩溃，于是先暂时将其在iOS上禁用，避免启动时注册崩溃，多次修改后依然未能解决，而且基于ChatWith for Mac修改的iOS版应用在界面上还是Mac版的样子，完全没有适配移动设备，可能将使用Flutter开发的桌面版应用改为移动版并没有Cursor说的那么简单
13、用Codex，结合Device Logs检查一下“清除后台后再打开应用秒闪退”和首次打开时启动速度很慢的问题，也进行了多次反馈和调整，甚至还暂时去掉了可能导致崩溃的SwiftFlutterSecureStoragePlugin，即flutter_secure_storage依赖，但还是不管用
14、换个思路，从应用的首次启动速度入手，Codex加上了首屏耗时分析，包括First frame: startup=26145ms build=7611ms raster=11ms total=8631ms，针对这一问题进行多次修改，包括把启动阶段的初始化拆到首帧后执行、把设置读取和服务配置的初始化延后到首帧之后、把原生启动页改成橙色背景+标题和副标题以跳过白屏、去掉启动阶段的首帧调试输出等，首屏耗时变成了flutter: First frame: startup=18011ms build=4065ms raster=5ms total=4074ms
15、然后按照Codex的建议，删除App，运行flutter clean、flutter pub get，再重新构建，解决构建错误等等，首次启动可以正常启动，但启动速度比之前更慢了，而且清除后台后无法启动的问题依然存在，后面还得继续修改