好好的井底空间

换了新手机以后最苦恼的就是如何重新下载 Shadowrocket，风控越来越严格，折腾废了 3 个账号，终于在农历的大年初一，我又可以看见外面的花花世界了哈哈哈😉 1. Mac 上注册新的 Apple 账户：使用全新的手机号和邮箱，地区选择美国。这一步成功率非常高，几乎没有失败过；不放心的话，可以开美国节点的代理，Mac 里的地区也设置成美国，Chrome 设置语言为英文。 2. iPhone 上登录该账户： ① 重置 App Store：这一步卡了我好久啊😭每次一切换账号，美区就变成国区，快被逼疯了。具体方法就是在 Safari 中打开链接（itms-apps://itunes.apple.com/WebObjects/MZStore.woa/wa/resetAndRedirect?dsf=143441&cc=us），自动跳转至 App Store，完成重置和重定向。 ② 登录账号：没什么好说的，简单确认下还在美区就可以了。 3. 下载 Shadowrocket： ① 购买 App Store 礼品卡：我尝试过无数次按照常规流程绑定 PayPal，最终都宣告失败了，后面还是决定采取更稳妥的充值礼品卡的方式。选用的是 Pockyt Shop（https://shop.pockyt.io/pc/home），充值了 $3，获取到礼品卡号后转至 App Store 中进行兑换。 ② 下载软件：点击“获取”，会弹窗提示填写账单地址，我是找了一个【美国随机地址生成器】，这一步也没什么难度。 4. 胜利✌

最近 agent skills 这个名词很火啊，怎么能不掺和一下呢？ 从日常开发工作中挑选了一个非常流程化的场景——根据后端提供的 swagger 文档，在前端项目中写入所需接口及数据类型——进行试验。 简易的 Skills 本质上就是放在 .claude/commands/ 目录下的 Markdown 文件。文件名就是命令名，文件内容就是提示词。这次选中的场景比较简单，提示词自然也不复杂，借助 AI 用了半个小时就写好并测试通过了。大概包含了如下几块内容： 1. 核心流程： ① 用户输入：定义用户需要提供的内容，包含环境和所需接口 url； ② 数据获取：提示 AI 通过 curl 命令获取对应环境下的 swagger 文档； ③ 信息提取：给出示例脚本，告知 AI 需要获取的字段信息，例如后端定义的接口方法名称、HTTP 方法、请求参数、响应类型等； ④ 命名规则：强制 AI 使用提取到的字段信息组成方法名、类型名，确保前后端命名一致； ⑤ 类型转换：针对特殊字段进行特别的处理，例如 id 字段往往被后端声明为 Long 类型，而后在 VO 类的字段级别借助 @JsonSerialize 注解进行转换，以字符串的格式传给前端，故而需要特别定义来覆盖 swagger 文档中读取到的类型； ⑥ 冲突处理：例如出现重复命名时，必须中断并询问客户； 2. 代码生成位置： ① 接口方法代码存放位置； ② 接口类型代码存放位置； 3. 代码模板：给出几个典型案例； 4. 用户额外需求占位符 - $ARGUMENTS。 流程跑通后，选择了一个接口（总计需增加 32 行代码）进行耗时测试： 1. AI 生成代码： ① 编写 prompt：只包含 skill 命令 + 环境名 + 接口名，用时几乎可以忽略不计； ② AI 思考并编写代码：2 分 43 秒，期间多次申请操作权限，使用者需要持续在场响应； ③ 人工检查生成的代码：49 秒。 2. 人工开发代码：2 分 36 秒。当然，这其中是有 Copilot code completion 的功劳的。即使禁用了 AI，我也习惯借助  typeof-jsonc 等插件帮助写入类型字段，总体耗时差距不会太大。 以我目前对 AI 的理解，它能够大幅提效的主要场景还是集中在： 1. 自己不熟悉的领域...

亲爱的朋友，你有遇到过这样的场景吗？ 1. 希望严格遵循 React 哲学、维护单向数据流，于是状态提升提升再提升，提升到最后发现这个状态值似乎和当下组件没什么逻辑关联，只是它凑巧了，是共用这个状态值的那两个远房孙组件最近的共同父组件； 2. 写出一版提测了，产品经理指着页面说，“还是把这个统计数据移到上面那块展示吧，排版更好看一点，不难吧？”于是吭哧吭哧重写了组件树中所有被牵涉到的组件的 props，加班加点荣获了「效率低下」的美名，代码也被评价为「扩展性太差」； 3. 眼看着层层的 prop drilling 太反人类了，想想干脆祭出 useContext 吧，可转念又觉得大材小用、加剧耦合、倍感不值，只能背地里吐槽产品的设计毫无章法、后端的接口乱组数据，硬着头皮做他们的粘合剂； 4. 下定决心不能再被 best practice 捆绑了，放飞自我，就是天王老子来了也得是在直接使用到数据的组件里调用获取数据的接口，但是后端赶在天王老子之前来了，“你这一个页面里怎么能同时调用两次接口呢？会不会写前端啊？知不知道服务器压力有多大啊？” 前端已死，都去报名学习 AI 吧……呃，不是🚫 经人指点，在项目中封装了一个 Hook -- useSharedRequest，顾名思义，就是方便在多个组件间共享接口请求，但共享的不是接口返回的数据，而是这个请求的 promise。该 Hook 基于 ahooks 库的 useRequest 封装而来，写法完全一致，只需要在配置项中增加一个 shareKey 作为请求的唯一标识，就可以实现： 1. 在直接使用到数据的组件里调用获取数据的接口，保证组件逻辑内敛； 2. 同一页面多个组件调用相同接口时，只发送一次真实的网络请求，减轻后端压力； 3. 改造和维护成本极低，不管是接口替换还是组件层级变化，都不会牵扯到大面积修改。 基础用法如下图所示： 详细来讲， 1. 定义一个请求共享管理器类 RequestShareManager。 2. 在 RequestShareManager 中声明一个 Map<shareKey, Promise> 类型的私有属性 pendingRequests，用于存储正在进行中的请求。 3. 在 RequestShareManager 中实现...

目标安装机器是储能柜的 EMS 触控一体机，核心需求是：低内存、少空间、高性能。于是选定了 Tauri 框架进行构建。 大致步骤如下： 1. 安装 Rust 及配套工具链（下载速度慢的话可以考虑换国内镜像） 2. 安装 Visual Studio Build Tools（在 Rust 编译时要用到） 3. 安装 tauri-app 依赖 4. 执行 tauri init 命令进行配置初始化 5. 执行 tauri dev 命令启动开发模式 6. 执行 tauri build 命令生成桌面应用安装包 最后，安装包 3.7M，应用程序 7.1M，运行时内存占用 3.6M，基本满足需求😏 除了前两步卡住了一下，其它流程整体上还是 love and peace，但我有种不详的预感：我只在自己 Windows 系统的电脑上跑通了，但是据说真实的安装环境是 Linux 的😥可能后期跨平台构建和样式兼容的工作量要远大于现在吧？

话不多说，直接上效果图： 从 0 创建到 1 还是很容易的，从 1 优化到 100 就很耗时了。动画的流畅度，交互的灵敏度，边缘情况的特殊处理，每一步都是个坎儿啊！很遗憾 resize 的部分纠缠了很久也没有处理好，但其余的效果都达到了我的目标值。技能点 + 1 ~~~

  偷得浮生半日闲，画了一个思维导图，把一些 AI 相关的热门概念理一理。当然了，AI 的知识浩如烟海，我了解到的也只是沧海一粟，权当一个简陋的备忘录吧！