瓦力

自从去年11月份开始探索AI开发以来，使用了多个AI插件以及AI编辑器。既有惊喜又有折磨，最近手里的纯AI开发项目刚完结，梳理一下这一路经历。

业务开始需求相对简单，搜索条件也比较单一，例如：根据订单号OrderNo查询对应订单。随着业务需求的升级，需要支持的查询条件也越来越多，组合查询、额外条件查询等需求升级，搜索上也要适配同步升级。

最近引入一个开源的AI项目进行二次开发，在我的工作本上启动开发很正常，在我之前老工作本上得启动多次才能成功，在我的一个同事工作本上发现根本启动不起来

初步学习Flutter、HarmonyOS NEXT混合开发，混合开发架构中，平台特性抽象层的设计质量直接影响后续维护成本。建议在项目初期建立统一的平台差异处理规范。

针对各种手机的屏幕自适应是APP开发的刚性需求，本项目使用了 flutter_screenutil 版本 5.5.3+2 来实现屏幕适配，确保应用在不同尺寸的设备上都能保持良好的UI效果。

AI辅助开发并不是银弹，它现在更像一个有知识没想法的天才少年，你需要告诉它思路和方向，它才可以很好工作。需要人去持续点拨、引导，有时还是需要人亲自上手。

市面上主流APP都存在定位上报的诉求，例如抖音、美团等。不过也存在简单和复杂的区别，本文主要从需求开始一步一步分析落地。

用户在频繁操作中，无论是进入详情页还是操作页，再次返回列表后，表格恢复到了初始状态。用户连贯操作不顺畅，用户提出要优化，有些操作需要刷新并保持原始操作位置，有些操作需要刷新重置

做的是物流相关的业务，蓝牙打印属于核心环节。主要涉及蓝牙连接打印设备，构建打印模板，构建打印队列，打印配置。

最近开发了两个工具性小项目，本身在需求上没有登陆、退出、鉴权一系列功能。然而临近交付，客户又提出一点小小的安全要求，要有登录、退出，又要超时退出。这种在临交付之前的既要又要，让人措手不及

Iframe应用最关键的因素就是同源，突破浏览器安全限制。其次就是把显示、交互、通讯控制在自己手里，才能优雅内嵌。

一直以来路由的使用都比较简单，随着业务场景的增多以及业务流程的优化，复杂的应用场景越来越多。经过现实的反复捶打，复盘开始...☺☺☺

Blue鲸产品生态做的好，Leader看的很巴适。追求又快又好的准则，开始Blue鲸二次开发，有的功能改造适配、没有的功能开发，一种拆散重组式缝合怪诞生了。

项目是个物流项目，随着业务需求的迭代，地图功能上的使用也是由浅入深。主要由高德地图应用为基础，从一个小白的角度摸索开发及实现业务落地，中间可能走了不少弯路，不过也是成长的过程。

一直进行Vue2.0项目、React16项目的维护开发，Node版本稳定在v14.17.6。最近针对某个社区新项目做二次开发，把Node版本升级到v18.20.2，node-sass兼容性问题无法解决

应用上线一段时间后，在客户交流使用过程中发现，客户会频繁截图分享订单详情页面到微信群中和管理员、付款方核对订单支付状态、金额等信息。而截图只能截一屏，多频率会截取两张图才能完全表达清楚信息。

Flutter APP交付前，因为逐渐接入部分生产数据进行测试，开发与生成环境分离迫在眉睫。从访问限制、启动方式、配置差异等方面优雅分离环境。先后应用两个方案的实践，最终应用了侵入性最小的方案。

旧版概览在设计上过于追求颗粒度，缺乏业务关联性和时效性。随着业务演进，客户日常使用场景覆盖不全，业务模块冗余、零散等问题暴露出来。在“业务导向、技术相辅”的思路下开始整改。

业务上是动态渲染n个主机节点池信息，选择某个磁盘后显示配置下拉框，选中当前选择磁盘的配置。遇到场景问题是单选后右侧配置下拉框2s+才能出现，初步定位是“React需要深度比较对象来找出差异“

Flutter开发的一个体系的APP上线试用了，经过一段时间试用趋于稳定，准备上架各大应用市场。咨询了第三方上架协助，费用高且针对Flutter开发的审核改造开发方自己处理。最终决定自己来搞。