- Composer 模型速度极快（比同等智能模型快 4 倍，大多数响应在 30 秒内完成），在纯智能基准上略逊于顶级模型（如 GPT-5 或 Claude Sonnet 4.5），但速度优势显著，适合快速迭代和日常开发。
- 我在做数据统计这个需求的时候，就是从前天晚上就已经把所有的代码好了，花了很多去调整这个图表的样式，因为在这个图表上既有柱状图也有也有这个曲线图，它是一个比较复杂的图标，大概花了两三个小时，调整了一下兼容性的问题，基本上调整的差不多了，然后今天今天再测了一个数据case，在测试的时候发现又出现了这种性问题，我思考了一下，就是兼用性这个问题，我想把它在这个图表上调好，要耗费大量的时间要花很多很多时间，且我认为这是一个比较通用型的问题，也就是别人也经常碰到，所以我判断是这个组件对于比较复杂的图标支持不太好。从A组键换到B组件，这个组件本身就支持比较复杂的图标，也就是一个图表上既有柱状图也有曲线图。所以我要说的是，做一个任务规划很重要，那么规划的是什么呢？规划的就是这个任务的难点以及不确定的点，对于这个任务来说就是那么画比较复杂的图形，就是一个难点，我们应该作为一个提前探索的部分。
- 客户端的难点就是相互联动， 比如我有个按钮叫删除视频， 那么我只要内存中和数据库中把数据删了就行了， 实际不行， 因为播放器还需要播放当前视频，那么我就需要重新绑定当前的视频片段 或者干脆就直接退出去。关联性过强
- 开发过程中，口径尽量保持简单， 比如客户端 ，用的 iOS android ，而服务器端 IOS 和ANDROID 那么调试的时候就会浪费个 5分钟10分钟的 每次有人问我应该用什么，所以规则尽量明确简单。
- 把事情想清楚要比立即去做更有意义， 根据价值去做事 ， 最近发现 mac 打ios 的包变得更慢了， 需要20分钟， 而且还贼贵，一个月要60多美金， 把打包的事情放在了云上， 开发人员多的时候是好事，能保证流程统一，但是现在开发人员就我一个人 未必是一个好事，所以我想改成本地打包 本地跑CICD 流程，我翻了下 actions 记录一周也就7次，我把这个事情搞了可能要好几个小时。有点得不偿失，还有更多和用户相关的问题等着。